The "Thin Core" Banking Architecture

Building modern ledgers on top of legacy cores. Why you should use the bank only for settlement and keep product logic in your own ledger.

Neobanks and fintechs often partner with sponsor banks running legacy cores (FIS, Jack Henry, Fiserv). These cores are mainframe-based, batch-oriented, and slow. The "Thin Core" architecture dictates that the fintech should treat the legacy core only as a settlement gateway, maintaining the "System of Record" and product logic in its own modern, internal ledger.

Decoupling Product from Settlement

The Thick Layer (Fintech): Holds the user balance, transaction history, and business rules (e.g., "Round up change to savings"). It responds to the App UI instantly.

The Thin Layer (Bank Core): Only receives the net settlement instructions or aggregated files.

Benefit: You can iterate on features (e.g., creating a "Crypto Pocket") without asking the legacy bank to update their 40-year-old COBOL schema.

Synchronization Strategies

The Shadow Sync: Every transaction in the internal ledger is queued to be synced to the core.

Reconciliation: Since the Internal Ledger allows overdrafts or features the Core doesn't understand, the reconciliation process ensures the aggregate funds in the Core match the aggregate user liabilities in the Internal Ledger.

Frequently Asked Questions

What happens if the Core is down?

In a Thin Core architecture, the app keeps working. You verify funds against your internal ledger. You queue the sync message and retry when the Core is back up.

Is this risky?

It creates a "Ledger Skew" risk. You might approve a transaction that the Core later rejects (e.g., account frozen). You must build logic to handle these "Post-Auth Declines."

Related Guides