Neobank platform architecture: cloud-native core banking

Traditional banks run on legacy mainframe or on-premises core banking systems (Temenos T24, FIS Profile, Finastra Fusion) that were designed in the 1970s–1990s. These systems are difficult to modify, expensive to scale, and slow to integrate with modern APIs. Neobanks are built on cloud-native microservices architectures from day one — using Kubernetes, event-driven patterns, managed cloud services, and API-first integration. This architectural difference translates to 10× lower cost-to-serve (McKinsey estimate), weeks-not-months product iteration cycles, and the ability to offer real-time features (instant notifications, sub-second balance updates) that legacy systems cannot support.

The financial ledger is the immutable record of every financial event — every credit, debit, hold, and release. It is the source of truth for account balances, transaction history, and regulatory reporting. It is the most critical component because errors in the ledger directly affect customer money: incorrect balances, failed reconciliations, and regulatory reporting failures all originate from ledger inconsistencies. Modern neobank ledgers use event-sourcing patterns (append-only event log) and double-entry bookkeeping to ensure every transaction balances and the full audit trail is preserved forever.

Most neobanks should start with a BaaS platform (Mambu, Thought Machine, or similar) to get to market quickly and prove the business model before investing in a custom core. BaaS platforms provide a pre-built ledger, account management, payment connectors, and in some markets, a banking licence wrapper. The trade-off is higher unit cost at scale and less customisation flexibility. Neobanks that reach significant scale and have unique product requirements (like Monzo and Starling) have built their own cores, but this requires 12–24 months of engineering investment and deep financial systems expertise.

Neobanks build a payment orchestration layer that abstracts multiple payment rails (SEPA, FPS, ACH, SWIFT, card networks) behind a unified internal API. The orchestrator handles rail selection (based on currency, speed, cost), idempotency (ensuring a payment is submitted exactly once even on retries), state machine management (tracking payment lifecycle from creation to settlement), and reconciliation (matching internal ledger entries against correspondent bank statements). Most neobanks use a combination of direct rail connections (for their primary market) and payment aggregators (Railsr, Modulr, or Stripe Treasury) for secondary markets.

DORA (Digital Operational Resilience Act) is an EU regulation that came into force in January 2025, requiring financial entities to maintain robust ICT risk management, conduct regular digital operational resilience testing (including TLPT — threat-led penetration testing), manage third-party ICT provider risk, and report ICT-related incidents to regulators within strict timeframes. For neobanks, DORA mandates specific architecture decisions: comprehensive incident detection and classification systems, documented recovery time objectives tested through exercises, contractual DORA requirements flowed down to cloud providers and BaaS vendors, and a dedicated ICT risk management framework with board-level oversight.

Neobank ledger databases require strong ACID guarantees, high write throughput, and append-only semantics. Common choices are: PostgreSQL (used by many European neobanks including Starling) for its mature ACID compliance and strong community; CockroachDB or Google Spanner for globally distributed deployments requiring strong consistency across regions; and event store databases (EventStoreDB) for pure event-sourcing implementations. NoSQL databases like MongoDB or DynamoDB are typically not suitable for the ledger core due to consistency trade-offs, though they may be used for non-critical account metadata or product configuration.

KYC (Know Your Customer) and AML (Anti-Money Laundering) are handled through a combination of third-party services and internal systems. KYC onboarding uses document verification APIs (Onfido, Jumio, Persona) for identity document checks and liveness detection. Sanctions screening integrates with Dow Jones, Refinitiv, or ComplyAdvantage for PEP and sanctions list checks. Ongoing transaction monitoring uses specialist AML engines (Featurespace, NICE Actimize, or open-source alternatives) that apply rule-based and ML-based detection to flag suspicious activity. Flagged transactions trigger a Suspicious Activity Report (SAR) workflow that feeds into regulatory reporting.

The primary scalability challenges are: ledger write throughput at peak (end-of-month salary payments, Black Friday spending spikes) requiring careful database sharding or multi-region write strategies; payment idempotency at scale (ensuring retried payments don't result in duplicate transactions); real-time balance calculation for millions of accounts concurrently; event-driven notification delivery (millions of push notifications per second during peak); and AML transaction monitoring latency (screening must complete before transaction authorisation, adding latency pressure). Kubernetes-based auto-scaling handles most compute scaling, but database and payment idempotency require architecture-level design.