Neobank Architecture Guide: 6 Layers Every Digital Bank Must Engineer Correctly

In July 2025, the UK's Financial Conduct Authority fined Monzo £21 million for failures in AML controls. As the bank underwent exponential growth, its financial crime controls failed to keep pace. Monzo had accounts opened with implausible addresses. Their ongoing transaction monitoring had gaps. High-risk customers weren't subject to enhanced due diligence proportional to their risk profile.

If you have a neobank of your own, failure to prepare the architecture for scaling early on can put you at risk of similar regulatory pushback and even direct losses to your clients.

A neobank's architecture is made up of several layers, including the licensing model that determines what you build versus operate through a sponsor bank or BaaS provider, the core banking system (ledger, accounts, products), the KYC and identity pipeline, card issuing infrastructure, payment rails orchestration, and compliance as embedded engineering infrastructure. Each layer has a build-versus-integrate decision that changes as the neobank scales.

Let’s look at what each layer contains, the build-versus-integrate decision at each stage, and what specifically breaks when the decision gets made incorrectly.

Our specialist neobank developers, with proven experience helping financial institutions scale successfully in similar projects, can provide valuable insight and practical development.

View capabilities.

Layer 0: The Licensing Mode

Before writing a line of neobank code, the licensing model needs to be decided. This will determine which parts of the architecture you own, which you operate through a third party, and what regulatory obligations attach to every subsequent engineering decision.

BaaS sponsor-bank model (e-money institution or program manager)

Major fintech firms use this model, allowing their neobank to operate under the license and FDIC or DGS insurance of a partner bank.

The bank holds deposits, provides access to payment rails, and maintains the core regulatory compliance framework. This means the neobank just builds the product layer, which is composed of things like the mobile app, the UX, the product features, and the brand.

Chime is one of the better-known examples of this and uses The Bancorp Bank and Stride Bank. Most US neobank startups launch under this model.

Using BaaS licensing means your engineering team can stay smaller, with the tradeoff being that your vendor dependency risk runs higher.

E-money institution license (EU/UK)

The EMI holds an e-money license from a national regulator like the FCA, BaFin, and the Central Bank of Ireland.

With this licence, it can issue electronic money, provide payment services, and maintain payment accounts, but cannot take deposits that count toward capital requirements or make loans from its own balance sheet.

This is a good starting point, especially if you are validating your concept before moving to a full banking license.

Full banking license

If a neobank holds a full banking license, it basically means that it can operate as a bank without any external assistance.

You can hold deposits, make loans, and directly participate in payment systems.

Architecturally, this does mean that you need to operate your own core banking system.

You also own the full regulatory stack, which means you need an AML compliance program and have to maintain capital requirements.

The engineering scope expands significantly, but so does your product capability.

Related Reading: Beyond DevOps in Fintech: Engineering Culture and Agility

Layer 1: Core Banking

The core banking system manages the accounting and product logic of the neobank:

• Every debit, credit, fee, and interest accrual in your ledger.
• Account structures (current accounts, savings pots, sub-accounts).
• Product rules (overdraft limits, savings rates, spending controls).
• The balance state that every other system queries.

There are three different approaches that exist.

1. White-label BaaS platform (Mambu, Thought Machine Vault, Pismo, Temenos Infinity)

Cloud-native core banking systems provide a pre-built ledger, product configuration engine, and API surface.

In this case, your product rules get configured rather than coded.

Speed is the biggest benefit, as time to market runs 3 to 6 months versus 12 to 24 months for a custom build. 

Be prepared for the fact that your product differentiation will be bound by what the platform's configuration model supports, though.

2. Custom ledger with BaaS rails

Here, the neobank builds its own double-entry ledger while using BaaS provider APIs for regulated banking services, like deposit-holding and payment network access.

You get maximum control over the accounting layer and product logic, while everything related to regulation runs through the partner bank.

There is definitely a higher engineering investment here, but you get a lower long-term vendor dependency.

3. Full custom build

For a full custom build, you will need to create in-house ledgers, accounts, product engines, and payment processing.

This option only works if you have full banking licenses that must operate their own core by regulatory necessity.

We don’t recommend this option for MVPs due to the excessive overhead it creates. Instead, we recommend that you start with one of the above options and gradually move over as the need arises.

Layer 2: Identity and KYC

KYC is one of the most compliance-critical layers of a neobank and the one that most commonly sees being under-engineered.

The Monzo fine traces directly to KYC implementation failures.

KYC as a state machine

A customer's identity verification status isn't binary (verified/not verified). It moves through states with defined transitions and regulatory requirements at each step:

INITIATED → DOCUMENT_SUBMITTED → DOCUMENT_VERIFIED → LIVENESS_CHECK

         → SANCTIONS_SCREENING → RISK_SCORING

         → APPROVED / REJECTED / PENDING_EDD / SUSPENDED

Each state has specific entry conditions, permitted exits, and regulatory requirements at the transition.

A customer whose document verification passes basic checks but whose sanctions screening returns a potential match must not proceed to APPROVED, but instead to PENDING_EDD (Enhanced Due Diligence review).

A customer applying with an implausible address should fail document verification entirely.

If the KYC state machine permits that transition without validating address plausibility, the failure is architectural.

Ongoing KYC

The FCA's criticism of Monzo wasn't only about initial onboarding, but also about monitoring. 

Things like large, unusual deposits, changes in transaction patterns, or connections to high-risk jurisdictions should trigger re-verification or EDD.

This requires an ongoing KYC event stream where every significant transaction event evaluates against the customer's risk profile.

Changes in risk level need to trigger state transitions. For example, they might move from APPROVED_STANDARD to APPROVED_EDD_REQUIRED to SUSPENDED_PENDING_REVIEW.

Third-party KYC providers in the architecture

Most neobanks integrate with specialist identity verification providers like Jumio, Onfido, Veriff, or Sumsub. These assist with document capture, liveness detection, and database screening.

That leaves you to own the state machine that interprets the provider's result and determines the next state. The provider's output is an input to the KYC state machine.

Layer 3: Card Issuing

Card issuing seems simple, but beneath the surface, it requires a card processor, a BIN sponsor, the payment network, and the neobank's authorization and dispute management systems.

• BIN sponsorship: A Bank Identification Number (BIN) consists of the first six digits of a card number, identifying the issuing bank. A neobank without a banking license must use a BIN sponsor, typically the same institution as the sponsor bank in the BaaS model.
• Card processor: They manage the card lifecycle and handle transaction authorization. Marqeta, i2c, and Galileo serve the majority of neobanks.
• The authorization window: Card authorization must be completed within 100 to 200 milliseconds from the card network's perspective. The neobank's authorization system receives the request, checks the available balance, evaluates fraud rules, and returns a decision, and requires a dedicated high-performance service.
• Dispute and chargeback management: Disputes flow through the card network's chargeback process. The neobank must respond with evidence within scheme-defined windows, typically 20 to 45 days, requiring a separate dispute management system.
• Virtual versus physical cards: These carry different lifecycle states. Virtual cards activate immediately. Physical cards require activation at first use. Card lifecycle management tracks state (ordered, in production, in transit, active, frozen, and terminated).

Layer 4: Payment Rails Orchestration

A neobank's payment capability runs across several rails. Each of these rails will be accessed differently depending on previous decisions like the licensing model and stage of the neobank's development.

The rails a consumer neobank typically needs:

• ACH covers standard and same-day transfers for direct deposits (the most important inbound payment for consumer neobanks), bill payments, and account-to-account transfers.
• Real-time payments via FedNow or RTP handle instant transfers between institutions.
• Wire transfers via Fedwire handle large-value transfers, primarily for business neobanks.
• International transfers via SWIFT or SEPA apply to neobanks with cross-border payment ambitions, requiring correspondent banking relationships or a third-party provider.

The orchestration layer

The payment orchestration layer receives payment instructions from users, determines the appropriate rail based on amount, speed requirement, and recipient, submits to the rail through the sponsor bank or direct connection, and tracks payment state through to settlement.

Your payment state, which is usually something like initiated, submitted to rail, pending settlement, or settled, needs to be modeled explicitly.

A direct deposit that arrives at the ACH network doesn't appear in the user's available balance until the sponsor bank confirms the credit, which may differ from the moment the ACH credit message arrives. Collapsing these states into a single "received" status just won’t work.

Layer 5: Compliance as Infrastructure

The Monzo fine is a very clear example of what happens when compliance is treated as a process owned by a compliance team rather than infrastructure owned by the engineering organisation.

At a small scale, a compliance team can manually review flagged transactions, conduct enhanced due diligence, and manage suspicious activity reporting. But when you start servicing millions of accounts, making several transactions a week, the same manual processes fail.

Transaction monitoring as an event-driven system

Transaction monitoring needs to be able to evaluate all account activity against AML risk indicators continuously.

This means it needs to consider structuring (splitting large transactions to avoid reporting thresholds), unusual transaction patterns for the account's profile, transactions to or from high-risk jurisdictions, and sudden changes in transaction volume or value.

The best way to do this is to set everything up as an event-driven service subscribed to the payment event stream.

This allows you to evaluate every transaction in near-real time against a rule engine and, increasingly, an ML model.

On top of all of that, you can set up your alerts to generate automatically, triage by risk score, and route to the compliance team only when they exceed a defined threshold.

Your compliance team just needs to review genuine exceptions.

Sanctions screening

Every customer onboarding event and every payment instruction must screen against current sanctions lists in a variety of different regions, all while running payment instructions. 

The sanctions screening service integrates via API with providers like Refinitiv World-Check, Dow Jones, or LexisNexis Risk Solutions.

SAR filing pipeline

When a transaction or pattern exceeds the threshold for a Suspicious Activity Report, the neobank must file with FinCEN (US), the National Crime Agency (UK), or the jurisdiction's equivalent.

Filing has regulatory timing requirements, typically within 30 to 60 days of identifying the suspicious activity, and must include specific documented evidence.

To do this efficiently, you need to engineer your evidence collection, investigation routing, regulatory filing generation, and submission tracking.

This is often referred to as the compliance-as-infrastructure principle

The Architecture Evolution: From MVP to Scale

Neobank architecture evolves as your product scales, regulatory obligations change, and strategic differentiation clarifies.

Like with Monzo, the correct architecture for a 10,000-customer MVP differs materially from the correct architecture for a licensed bank at five million customers.

• Stage 1: MVP (0 to 50,000 customers): BaaS sponsor-bank model. Third-party KYC provider with a basic state machine. White-label card processor (Marqeta or i2c). Core banking through the BaaS platform or a lightweight custom ledger. Compliance via third-party transaction monitoring SaaS (ComplyAdvantage, NICE Actimize).
• Stage 2: Growth (50,000 to 500,000 customers): Begin replacing vendor dependencies where they limit product differentiation. Custom KYC state machine with preferred identity providers. Own dispute management system. Direct card processor integration rather than through BaaS abstraction. Begin building an internal transaction monitoring rule engine.
• Stage 3: Scale (500,000 or more customers, or licensed bank): Custom core banking (for licensed banks) or heavily configured BaaS integration. Full compliance infrastructure. Direct payment network participation where licensing permits.

Your goal gradually shifts from getting your product on the market as soon as you can with as little overhead as possible before validating your concept, to building operational resilience.

Related Reading: How Fintechs Can Scale Engineering Cheaply and Sustainably

The Architecture Reference Table

There is a characteristic build-versus-integrate pattern that varies by stage, for each of the layers that we have discussed above.

The Most Common Neobank Architecture Mistakes

Each of the six layers produces a characteristic failure mode when it is built incorrectly.

• Building a custom core banking system before product-market fit: Months of engineering investment in a custom ledger before the product has validated any meaningful user adoption is a massive risk, since you may pivot. A configurable platform is the better choice at the start.
• Designing KYC as a UI flow rather than a state machine: A form that calls a KYC provider API and stores a "verified" flag has no ongoing monitoring, no EDD trigger, no sanctions re-screening. Instead, you need a state machine.
• Building the authorization service in the main application backend: Card authorization must complete within 200 milliseconds. A synchronous call from the app backend through multiple middleware layers into a card processor API can’t do this under production load like a dedicated low-latency service with its own scaling profile can.
• Treating compliance systems as the compliance team's problem: Compliance infrastructure must be engineered with automated processing, rule engines, and human review reserved for genuine exceptions.
• Starting with full custom development to avoid vendor lock-in: Building everything from scratch creates years of infrastructure engineering before any product reaches users. We recommend that you build custom where genuine differentiation requires it. Integrate everywhere else, and migrate to custom implementations as you need to.

Who Builds This

Neobank engineering teams typically need core banking engineers who understand double-entry ledger design and account lifecycle management.

They can also benefit from dedicated KYC/AML engineers who have built state machines, transaction monitoring rule engines, and SAR filing pipelines.

The important thing is to get people who have worked on similar projects before, so you can rest assured that they understand the technical nuances of the financial technology industry and that they understand the heavy regulations of the industry.

At Trio, we maintain a pre-vetted bench of engineers with neobank and digital banking production experience across all layers.

Since they don’t need to be assessed from the ground up and simply need to be hand-picked based on your requirements, they can be placed in 3 to 5 days.

Request a consult.