Every founder who walks into our office with a neobank idea starts the conversation the same way: “We want an app like Revolut, but for [insert niche].” Fair enough. But what they’re usually picturing is the UI — the card design, the onboarding flow, the slick transaction feed. What they’re not picturing is the eight or nine layers of infrastructure sitting underneath that app, each one owned by a different vendor, each one capable of sinking the entire product if picked wrong.
We’ve built and supported neobank platforms for clients across the Middle East, Southeast Asia, and a couple of African markets at Speqto, and the pattern is always the same: the app is the easy 20%. The stack is the hard 80%. Here’s what actually goes into it.
1. The Ledger — Your Real Core Banking Engine
At the center of every neobank is a double-entry ledger that tracks who owns what money, down to the cent, at all times. This isn’t optional and it isn’t something you bolt on later. We’ve seen founders try to use their Postgres database as a “ledger” early on, and it works right up until reconciliation day, when numbers stop matching and nobody can explain why.
Purpose-built ledger systems like Mambu, Thought Machine’s Vault, or Treasury Prime exist precisely because getting this wrong is a compliance and audit nightmare, not just a bug. For one of our lending-focused neobank clients in the GCP region, we built a custom ledger on top of a BaaS provider’s core because off-the-shelf options didn’t support their multi-currency wallet structure. That decision alone added six weeks to the timeline — but it saved them from a rebuild a year later.
2. Banking-as-a-Service (BaaS) Partners
Unless you’re applying for your own banking license (expensive, slow, and usually unnecessary at launch), you’ll be riding on a sponsor bank’s license through a BaaS provider. Think Synapse (cautionary tale after its 2024 collapse froze user funds for months), Unit, Treasury Prime, or regional equivalents like Railsbank/Weavr in the UK/EU.
The lesson from Synapse’s failure isn’t “avoid BaaS” — it’s “audit your BaaS provider’s own banking relationships like your license depends on it, because it does.” We now insist every fintech client run a dependency map before signing: who’s the sponsor bank, what happens if that relationship ends, and where does the money actually sit.
3. KYC/AML and Onboarding
This is where user drop-off happens, and where regulators look first. Most neobanks stitch together an identity verification vendor (Persona, Onfido, Sumsub) with a fraud/risk scoring layer (Sardine, Alloy) and a sanctions screening tool. For a digital wallet client we worked with in Southeast Asia, we integrated Sumsub for document verification but layered a custom liveness check on top because local ID formats weren’t well supported out of the box. Don’t assume a single vendor covers your market — regional ID edge cases are where generic KYC stacks quietly fail.
4. Card Issuing and Payment Rails
If you’re issuing physical or virtual cards, you’re looking at Marqeta, Galileo, or Stripe Issuing. These handle card tokenization, authorization logic, and network connectivity to Visa/Mastercard. Separately, you need rails for moving money domestically — ACH equivalents, instant payment networks (UPI, FAST, SEPA depending on geography), and card networks for top-ups. These are rarely the same vendor, and the latency between them is often where “why didn’t my transfer go through” support tickets come from.
5. Compliance and Risk Engine
Transaction monitoring, AML case management, and regulatory reporting usually run as a separate layer — tools like ComplyAdvantage or NICE Actimize for larger players, or custom rule engines for smaller ones. We built a lightweight rules engine for one client rather than licensing an enterprise AML platform, simply because their transaction volume didn’t justify the cost yet. Right-sizing this layer matters more than founders expect.
6. Cloud Infrastructure and Security
AWS and GCP dominate here, mostly because of their financial services compliance certifications (PCI-DSS, SOC 2). Expect to spend real engineering time on encryption at rest/in transit, key management (AWS KMS, HashiCorp Vault), and network segmentation between your app layer and anything touching card data. PCI scope creep is the quiet budget-killer in every fintech build we’ve touched.
7. Frontend, Mobile, and Data Layer
React Native or Flutter for cross-platform mobile, Next.js or similar for web dashboards — this part looks like any other consumer app build. The real differentiator is the event-driven data pipeline underneath (Kafka or similar) feeding your analytics and fraud detection in near real time, because in banking, “we’ll check the dashboard tomorrow” isn’t good enough when fraud is happening right now.
The Real Takeaway for Founders
Picking vendors for each layer isn’t a one-time decision — it’s an ongoing architecture conversation, because your BaaS provider, card issuer, and compliance stack all need to talk to each other reliably at 2am on a Saturday. Most neobank failures we’ve seen weren’t product failures. They were integration failures between layers nobody stress-tested together.
If you’re mapping out your own stack and want a second pair of eyes before you commit to vendors, that’s a conversation worth having early — it’s a lot cheaper than a migration eighteen months in.
