Neobank tech stack in 2026: what to build vs buy, layer by layer

A neobank tech stack has eight core layers: customer app, ledger, onboarding and KYC, accounts, payment rails, FX, risk, and operations tools, with cards as a common ninth. Most teams in 2026 build the app and the ledger and buy the regulated layers. BlindPay covers accounts, money in, money out, FX, and KYC through one API.

The hard part is not listing the layers. It's deciding which ones are worth your team's time. This guide gives each layer a build or buy call, a four-question test for edge cases, and a year-one stack for a five-person team. It is part of the how to build a neobank series.

Key takeaways

• Build what customers see and what makes you different: the app, pricing, and your ledger.
• Buy what needs licenses, bank relationships, or audits: accounts, rails, KYC tooling, cards.
• Your ledger is the one layer you can't outsource in spirit. Provider balances are not customer balances.
• Put every provider behind your own interface and IDs. That is your lock-in insurance.
• A five-person team can launch on three or four providers plus its own app and ledger.

What are the layers of a neobank tech stack?

Eight layers carry the product. Each one has a clear job.

1. Customer app. Mobile and web screens, notifications, in-app support.
2. Ledger. Balances, pending and held amounts, transaction history per customer.
3. Onboarding and KYC/KYB. Identity checks, business verification, sanctions screening.
4. Accounts. Account details customers can share to receive money.
5. Payment rails. Money in (deposits) and money out (payouts) over ACH, wire, Pix, SPEI, SEPA, and others.
6. FX. Rates and conversion between currencies.
7. Fraud and risk. Transaction monitoring, limits, disputes.
8. Admin and operations. Back office, case management, reporting.

Cards sit next to these as a separate program with its own provider. What stablecoin infrastructure is zooms into the stablecoin side of layers 4 to 6.

Which layers should you build, and which should you buy?

Build the layers that shape the customer experience. Buy the layers that carry regulatory weight.

The pattern holds for most teams: own the experience and the record, rent the regulated plumbing.

How do you decide build vs buy for a specific layer?

Ask four questions. Two or more "yes" answers to the first two means build. Otherwise, buy.

1. Differentiation. Would a customer notice and care if this layer were better than a competitor's?
2. Time to market. Can you build it in weeks, not quarters, without blocking launch?
3. Compliance burden. Does running it require a license, bank partner, or audit you don't have?
4. Cost at scale. At your year-three volume, does a vendor fee clearly exceed the cost of a team running it?

A "yes" on question 3 is usually decisive on its own. In the US, a business that transmits money registers with FinCEN as a money services business, filing Form 107 within 180 days and renewing every two years, and many states require their own money transmitter licenses on top. Buying from a registered provider doesn't remove your own obligations, but it removes years of setup from your launch plan.

Why is money movement usually bought?

Because each rail is its own project. ACH runs under the Nacha Operating Rules. Pix runs under Banco Central do Brasil rules. SPEI runs under Banco de México. SWIFT needs correspondent relationships. A team that builds money movement builds one integration, one bank partnership, and one compliance program per rail and per country.

A payments API collapses that into one integration:

• Accounts in. BlindPay issues US virtual accounts in each customer's own name, with routing and account numbers, accepting ACH, wire, and SWIFT. Each deposit becomes a payin that delivers USDC or USDT to the linked wallet.
• Payouts out. One payout endpoint covers Pix, SPEI, ACH, RTP, wire, SEPA, ACH Colombia, Transfers 3.0, and SWIFT (POBO/COBO). New corridors are new bank account types, not new integrations.
• FX. Quotes lock the rate and fees for 5 minutes before you execute.
• Compliance. KYC, KYB, and sanctions screening run inside the same API.

What does non-custodial design change in the stack?

It changes what you reconcile. In a custodial model, the provider holds a balance for you and you reconcile your ledger against it. In a non-custodial payout model, the provider executes one authorized transaction at a time and holds no standing balance of yours in between.

BlindPay operates as a non-custodial payment processor for payouts from customer-controlled wallets: you authorize the exact amount and BlindPay executes that single transaction. If a payout can't be delivered after the stablecoins are collected, BlindPay refunds them to the quote's refund wallet, or the sending wallet. On Pix and other non-USD local rails the refund is automatic, while USD payouts are refunded after an operator review. Optional managed wallets (beta) are custodial when you choose them.

For the ledger, that means two sources to match: your own entries and the provider's events. Webhooks and reconciliation shows how to match them.

What is a realistic year-one stack for a five-person team?

Illustrative example. Five people: two engineers, one product and design lead, one compliance and operations lead, one founder on partnerships and sales.

Engineering time goes to three things: the onboarding funnel, the send flow with a clear quote screen, and daily reconciliation. Everything else is configuration.

How do you avoid vendor lock-in?

Treat every provider as an adapter behind your own interface.

1. Own the IDs. Map each provider's customer, account, and payout IDs to your own.
2. Store the events. Save every webhook and quote you receive, with timestamps.
3. Keep your ledger independent. Balances come from your journal, not from provider APIs.
4. Abstract the verbs. Your code calls "create payout", not a vendor's method name.
5. Read the exit terms. Check data export, notice periods, and how customer KYC records move.

KYC is the stickiest layer. Compliance approvals rarely transfer between providers, so a switch often means re-verifying customers. Plan corridors per provider rather than assuming one vendor forever.

What are the common build vs buy mistakes?

• Building rails to save fees. The fee you avoid is smaller than the licensing and bank work you take on.
• Buying the ledger and forgetting to own it. If a vendor's dashboard is your only balance record, you can't audit yourself.
• Building KYC screens and checks together. Build the screens. Buy the checks.
• Picking cards first. Cards add a BIN sponsor, a processor, and disputes. Launch money in and out first unless cards are the product.
• No sandbox discipline. Run every flow on a development instance, including failures, before production keys.

Card issuers that fall under the Federal Reserve's Regulation II face interchange limits, while certain small issuers are exempt. That is why card economics depend on which bank sponsors the program, a decision to make with your card provider, not your payments API.

How does BlindPay fit the buy side?

BlindPay is one vendor for four regulated layers: accounts, money in, money out, and FX, with KYC, KYB, and sanctions screening in the same API. It is registered with FinCEN as a money services business and backed by Y Combinator (W25).

For the build side, BlindPay gives your engineers a REST API, an OpenAPI 3.1 spec, and official SDKs for Node.js, Python, Go, PHP, and Swift (SDKs). Signed webhooks feed your ledger. Development instances use a test token and auto-approve KYC, so you can test the whole stack before real money moves. Plans start at $499 per month on the pricing page, and per-transaction fees show up in each quote. If you also need a card program or managed balances, the neobank infrastructure comparison shows which providers pair with BlindPay.

What to do next

List your eight layers, mark each one build or buy with the four-question test, and name an owner. Then open a development instance and map your first three screens to API calls with the BlindPay introduction.