---
title: "Neobank tech stack in 2026: what to build vs buy, layer by layer"
seoTitle: "Neobank tech stack: what to build vs buy in 2026"
description: "The 8 layers of a neobank tech stack, which to build and which to buy, a 4-question decision test, and a year-one stack for a five-person team."
date: "2026-10-05"
updated: "2026-10-05"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "What technology does a neobank need?"
    a: "A neobank needs eight layers: a customer app, a ledger for balances, onboarding with KYC and KYB, accounts customers can deposit into, payment rails for money in and out, FX, fraud and risk controls, and admin and operations tools. Cards are a ninth layer for most consumer neobanks. Each layer can be built in house or bought from a provider."
  - q: "Should a neobank build its own ledger?"
    a: "Most neobanks should own their ledger, either built in house or on a ledger product they control. Provider balances are not customer balances. Your ledger is the record of what each customer can spend, what is pending, and what is held. It is also the only place where card spend, deposits, and payouts from different providers come together."
  - q: "Why do neobanks buy money movement instead of building it?"
    a: "Money movement needs licenses or registrations, bank relationships, rail access, compliance programs, and audits in every market. Building that takes years per country. Buying it from a provider such as BlindPay gets accounts in, payouts out, FX, and compliance checks through one API, so the team spends its time on the product customers see."
  - q: "How do you avoid vendor lock-in in a neobank stack?"
    a: "Keep your own ledger and customer records, map provider objects to your own IDs, and put each provider behind an internal interface. Store webhook events and quote details in your database. With that in place, adding a second provider for one corridor means a new adapter, not a rewrite of your product or your balances."
  - q: "What does a year-one neobank stack look like for a small team?"
    a: "A five-person team typically builds the mobile app, the ledger, and an admin panel, and buys everything regulated. That means one provider for accounts, payouts, FX, and KYC such as BlindPay, a card issuing provider if cards are in scope, a support tool, and monitoring. Engineering time goes to onboarding, the send flow, and reconciliation."
  - q: "How much does it cost to build vs buy neobank infrastructure?"
    a: "Building regulated layers costs licenses, legal work, bank partnerships, and a compliance team before the first customer. Buying turns that into platform and usage fees. On BlindPay, plans start at $499 per month, US virtual accounts cost $1.50 per month each, and per-transaction fees appear in each live quote before you execute a payment."
---

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](/resources/more/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](/resources/more/what-is-stablecoin-infrastructure) 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.

| Layer | Build or buy | Why | Typical options |
| --- | --- | --- | --- |
| Customer app | Build | It is your product and your brand | Your team, native or cross-platform |
| Ledger | Build or buy, but own it | It holds the truth about every balance | In-house double-entry ledger or a ledger vendor |
| Onboarding and KYC/KYB | Buy the checks, build the screens | Checks need data sources and audit trails | BlindPay KYC/KYB in the API, KYC vendors |
| Accounts | Buy | Account numbers come from banks | BlindPay US virtual accounts, partner banks |
| Payment rails | Buy | Rail access needs bank relationships and licenses | BlindPay payins and payouts |
| FX | Buy | Rates come from liquidity providers | BlindPay live quotes |
| Fraud and risk | Mix | Rules are yours, monitoring tools are bought | Your rules plus a monitoring vendor |
| Admin and operations | Build, light | Internal tools change weekly | Internal admin panel, provider dashboards |
| Cards | Buy | Issuing needs a BIN sponsor and processor | Card issuing providers |

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](https://www.fincen.gov/money-services-business-msb-registration), 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](https://www.nacha.org/content/what-is-ach). 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](/resources/more/stablecoin-api-webhooks-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.

| Layer | Year-one choice | Owner |
| --- | --- | --- |
| Customer app | React Native app plus a web dashboard | Engineers, product lead |
| Ledger | Double-entry tables in Postgres, one journal per customer | Engineer 1 |
| KYC/KYB | BlindPay customers API, hosted terms of service | Engineer 2, compliance lead |
| Accounts | BlindPay US virtual accounts | Engineer 2 |
| Money in and out | BlindPay payins and payouts, Pix and SPEI first | Engineer 1 |
| FX | BlindPay live quotes, own fee added through partner fees | Founder, product lead |
| Cards | Deferred to month 6, card issuing provider shortlist | Founder |
| Risk | Provider screening plus 10 internal rules on the ledger | Compliance lead |
| Ops | Admin panel, BlindPay dashboard, a help desk tool | Compliance lead |

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](https://www.federalreserve.gov/paymentsystems/regii-about.htm) 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](/docs/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](/pricing), and per-transaction fees show up in each quote. If you also need a card program or managed balances, [the neobank infrastructure comparison](/resources/more/best-stablecoin-infrastructure-for-neobanks-2026) 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](/docs/introduction).