How to build a neobank in 2026: layers, partners, stack

Building a neobank means picking one customer group and one money problem, deciding which regulated partner holds the money, then assembling the layers under the app: identity checks, accounts, a ledger you own, money in, money out and, later, cards. Most teams build the app and the ledger and buy the regulated layers.

The institution behind a neobank holds the accounts, and the app owns the customer, the screens and the fees. The contrast with a traditional bank is in stablecoin neobank vs traditional neobank.

What are the layers of a neobank, and who provides each?

A neobank has nine layers. Two are built in house almost every time, six are bought, and one is mixed. Each row names the status your app has to turn into a screen.

The nine layers, who is regulated at each, and the status the app must handle

On Lumx, identity, accounts, wallet, money in and money out sit behind one API, and each status in the table is a webhook event the docs list, so the app runs on events instead of polling. The card layer comes from the card program you contract.

Start with one market and one money action

"Everyone who needs a bank" is not a market. "Brazilian freelancers paid by US clients" is. Name the three money actions your customer does most, since those decide the rails, and the rail sets how fast money lands. Brazil runs on Pix (Brazil's instant payment system, run by the Central Bank). Mexico runs on SPEI (Mexico's interbank transfer system, run by Banxico). Colombia runs on Bre-B (Colombia's instant payment system, run by the Banco de la República) and PSE (Colombia's online bank-transfer network).

Rails by market, with settlement times from the Lumx docs (read November 1, 2026)

FEDWIRE is the Federal Reserve's same-day wire. ACH on Lumx is credit (push) only, with no ACH debit. PSE only collects, so a Colombian neobank pays out on Bre-B or ACH Colombia. Bre-B payments are capped by the Banco de la República at 1,000 UVB per transaction, which is COP 12,110,000 in 2026 (Circular Reglamentaria Externa DSP-465, Asunto 18, numeral 3.2, as updated on March 31, 2026), so plan a second rail for larger invoices. The operator map shows who runs each rail.

On Lumx, BRL, MXN and USD accounts are requested in the accounts list when you create the customer, and rails are on the coverage page.

Decide who is regulated before you write code

There are three routes. You can hold your own charter, which takes years and heavy capital. You can run on a licensed institution that holds the accounts and carries the regime, which is how most launch. Or you can embed regulated providers per function and keep only the product.

What changes is which entity holds customer money and which obligations stay with you. Fund custody is in where neobanks hold customer funds, and the Brazilian case in the Brazil neobank license guide. A stablecoin balance is not a bank deposit: US deposit insurance covers deposits at insured banks (FDIC, Deposit Insurance at a Glance), so "your savings are insured" cannot be the promise on that screen.

The three routes, by who holds the money and what stays with you

Your neobank needs a licensed institution behind the regulated activity it performs, a bank or a payment institution you contract, and Lumx is not that institution. Lumx serves neobanks that operate through a licensed partner, so a neobank can be a customer without its own authorization from the Central Bank of Brazil. Lumx is not a bank. Lumx US OP LLC, in Wyoming, is a FinCEN-registered Money Services Business (see FinCEN's MSB registration page). In Brazil, services are provided by Lumx Sociedade Prestadora de Serviços de Ativos Virtuais Ltda, which has applied for the authorization and operates under the Article 88 transition regime of Central Bank of Brazil Resolution 520 of 2025. Your own obligations stay yours.

Verify every customer with KYC and KYB

No money moves until you know who the customer is. KYC (know your customer, the verification of an individual) asks for a tax ID, an identity document, a liveness check and proof of address. KYB (know your business, the verification of a company and its owners) adds formation documents, plus an identity document and proof of address for every representative and every owner above 25%. The review depends on the supported countries tier.

A missing document comes back as an RFI (request for information, a compliance hold that asks for a document before a transaction clears), and the app has to say which.

Limits come with the tier, and a transaction over a limit is rejected with TRANSACTION_LIMIT_EXCEEDED.

Default limits by verification tier, in USD (read November 1, 2026)

Business customers: onboarding business users.

On Lumx, a customer accepts the terms of service on a hosted page, then completes verification on the link returned on the customer. KYC Standard and KYB each target one business day once documents are in, as targets, not commitments. Reading the customer with includeTransactionLimits=true returns the used and remaining amounts per transaction type. KYC runs on Sumsub, and Chainalysis screens the blockchain side.

Give each customer an account and a wallet

Customers need account details to give an employer or a client, and a balance that holds between deposit and withdrawal: a virtual account in the customer's name and a custodial wallet.

Each user has to be a customer of their own. Pooling users' money in one account breaks the visibility that sanctions screening and monitoring depend on, and providers prohibit it. The structure that works, one customer with one wallet and one set of accounts per user, is laid out in named virtual accounts for B2B collections.

On Lumx, creating a customer provisions a wallet on every supported network, enabled once the customer is approved, and the accounts you requested enter their own verification. BRL, MXN, EUR and GBP accounts activate right after the customer is approved, and USD takes up to one business day, so subscribe to account.active instead of guessing.

The accounts sit in the customer's name at a banking partner, and the wallet is custodial: BitGo is the custodian, and each customer's wallet is fully segregated, with no omnibus account.

BRL accounts are named, so on a Pix payout the recipient sees the customer as the payer, not Lumx, and Lumx takes no fee out of the amount that reaches the recipient on Pix, SPEI or Bre-B. The account types are on the named virtual accounts page and the wallet model on the custodial wallets page.

Build money in, money out and your own ledger as one flow

A deposit has to land, convert if needed and appear in the balance. A withdrawal can be priced at execution or against a locked quote, then converts and arrives.

An on-ramp moves from AWAITING_FUNDS through trading to SUCCESS. An off-ramp goes from the wallet to a destination registered under the customer and ends in SUCCESS or a failure. A withdrawal larger than the balance fails with an insufficient-balance error, so check your ledger first.

I would build the ledger before the first screen. A provider's balance says what the provider holds for a customer, and your ledger says what the customer can spend after holds and fees. The two will disagree on the first day a payout is pending, and a neobank with only the provider's number explains that gap one ticket at a time. I would also launch on one corridor, because every extra rail adds a settlement window, a cut-off and a failure state.

The order: ledger and onboarding, accounts and wallets, money flows, cards. Matching your ledger to the provider's transactions is covered in virtual account reconciliation.

On Lumx, an autoconversion rule on a BRL, MXN, USD, EUR or GBP account converts every deposit to USDC or USDT with no call per deposit, so a rule converts every deposit at market, and a one-off transaction can carry a locked quote. Webhooks on onramp.success, offramp.success and transfer.success keep the ledger in step. A payout to a US bank has cut-offs of 2:00 PM ET for ACH and 3:00 PM ET for FEDWIRE and SWIFT.

Where do cards fit in a neobank?

A card is its own workstream, with an issuer, a program and dispute handling. It comes after the account because it needs a funded balance. Buy it: the card layer comes from a card issuer or program manager you contract, and your ledger decides the available balance at each authorization. Limit a withdrawal to the balance minus what pending authorizations commit, and keep that check in your app.

On Lumx, a neobank can carry a stablecoin card: the balance behind the card is topped up with a local-currency deposit that converts to stablecoin in the customer's wallet, and a withdrawal to a bank account is an off-ramp the platform starts through the API.

What drives the cost and the timeline of a neobank build?

Three choices set both. The first is the route: an own charter adds capital and years, a licensed institution adds a contract and a partner review, and embedded providers add one integration per function. The second is the number of markets, since each adds a rail, a regime and support hours. The third is cards, which add an issuer, a program and dispute handling. No public source gives a reliable cost or timeline range across these routes, and the spread is too wide to quote one, so ask each partner for its own review times and fees. Revenue lines include interchange on card spend, margin on conversion, transfer fees and subscriptions, and your partners decide which you can use.

On Lumx, the pricing model is a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding, and no published plans. No pre-funding means no capital parked in settlement accounts abroad before a transaction, not an empty wallet. The standard agreement has a monthly minimum, waived during a ramp-up period. An API integration takes two to three weeks to go-live, and the customer also uses the Lumx dashboard. Your own revenue comes from a partner fee, a rate in basis points, a flat amount or both, added to each on-ramp or off-ramp and sent to a wallet you choose. A locked quote includes it, so the customer sees one price.

When building a neobank is the wrong move

Skip it if the product is a feature, not a bank: one payout flow inside an app you already run needs a payments integration.

• Skip it if you cannot name the customer's three money actions.

• Skip it if you plan to launch five markets at once.

• Skip it if you would pool other people's money in one account, which providers will not take.

• Skip it if you need to promise deposit insurance, which a stablecoin balance cannot carry.

What this looks like on Lumx for a neobank

Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.

Take a neobank for Brazilian freelancers paid by US clients. The app creates each as a customer with BRL and USD accounts, and the USD details go to the client. When the wire lands, an autoconversion rule turns it into USDC in the wallet, and onramp.success posts the credit to the ledger. A withdrawal goes out as a Pix off-ramp to the freelancer's own destination, and the partner fee on it is the app's revenue. Every freelancer is a customer, so nothing pools.

The rails and settlement times are on the global payments page, and the compare page sets providers side by side.

Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Kumiko SHIMIZU on Unsplash.