_INDUSTRY-ANALYSIS/
Why Modern Fintechs Layer a Ledger Under Their Core Banking System
By Formance Staff
Ledger
Payments
Regulation
Loading article content
Loading table of contents
Loading author
Premier FX had no internal system of record. When the firm collapsed, 167 customers were exposed to losses because client money sat in Barclays accounts that were treated as the ledger itself but were not reconciled to it.
That's the question every growing fintech eventually runs into: should your core banking system double as your source of truth for money movement, or should a modern ledger sit underneath it as the system of record?
Finance asks engineering, "Where is this customer's money right now?" Engineering cannot answer without pulling core data and Payment Service Provider (PSP) dashboards, then running a reconciliation script. The month-end close drags into a week, and the board still wants provable numbers before the next raise.
Regulators now require fintechs to have daily reconciliation rules and the ability to distinguish funds without delay, even as product teams push for new-market launches. The system you built to track money is now the bottleneck for the close, reporting, and expansion. You have to decide whether to keep extending your core banking system or layer a modern ledger underneath it as a purpose-built system of record.
A core banking system manages financial products, customer accounts, balances, fees, interest accrual, and statements. It applies fee rules, runs end-of-day batch cycles, and generates legally binding account statements.
For fintechs, core banking often arrives through a Banking-as-a-Service (BaaS) provider. The fintech distributes products under its own brand through middleware that abstracts a sponsor bank's licensed banking layer and deposit accounts.
Whether owned or rented, the core banking layer is the system every other product and process depends on, which is exactly where the problems start.
Core banking alone leaves three gaps for growing fintechs: vendor lock-in, per-rail reconciliation, and integration debt.
Vendor lock-in blocks new product launches. When your team wants to launch a new wallet product or credit line, most core banking systems have limited or no native support for wallet hierarchies, multi‑rail routing, or asset‑agnostic balance management. You are blocked until the vendor ships the capability or you pay for custom work. A June 2025 KPMG report found that vendor lock-in remains a significant risk in core banking modernization, with institutions tied to single vendors by high switching costs and proprietary technologies.
The engineering team maintains reconciliation scripts across every payment rail (Automated Clearing House (ACH), Wire, Real-Time Payments (RTP), Society for Worldwide Interbank Financial Telecommunication (SWIFT), and card networks). Each rail carries its own settlement timing, failure modes, and data formats, and reconciling across them ends up outside the core banking system and inside your own engineering stack.
Premier FX shows what happens when per-rail reconciliation gaps spill over into safeguarding. The FCA's Final Notice found that Premier FX failed to safeguard client money properly and that the Barclays accounts it used were not operated or designated in line with safeguarding requirements, effectively treating external bank accounts as the ledger with no single internal system of record.
Each new market adds local payment networks, local Anti-Money Laundering (AML) rule sets, local Know Your Customer (KYC) providers, and local regulatory reporting obligations. The core banking system accumulates integration work with every new provider, and the reconciliation burden grows alongside it.
Faced with these gaps, many teams reach for the same workaround: building their own ledger inside the application.
Teams build homegrown ledgers when the core banking system gives them no unified place to record money movement across every system. It is the most common response to the reconciliation and multi-rail gaps above.
Nearly every homegrown mini-core ledger starts the same way: an application database table with a balance column gets updated by UPDATE statements from application code. At low volume, there is no failure signal. Balance drift and reconciliation breakage arrive later, when product complexity has grown enough that replacing the homegrown ledger requires migrating live financial data. The next scenario walks through exactly how that breakage shows up.
Your payments service records a $500 deposit to a user's account by incrementing a balance field in the application database. Your rewards service, maintained by a different team, credits a $20 bonus to the same user by writing to a separate rewards_balance table. Your reporting pipeline sums both tables nightly to compute the user's total balance at $520.
Now a refund of the original deposit fires. The payments service decrements the balance by $500, bringing it to $0. The rewards service has no awareness of the refund, so rewards_balance still shows $20.
The reporting pipeline computes $20 as the total balance. The user's actual balance should be $20 (the bonus stands), but the payments service shows $0, and the rewards table shows $20 with no connection between the two services. If an auditor asks "What is this user's balance and how did it get there?" no single system can answer.
In double-entry accounting, every deposit, bonus, and refund posts through a single system of record. Formance Ledger expresses these postings in Numscript, a purpose-built language for money that both engineering and finance teams can read:
send [USD/2 50000] (
source = @world:bank:checking
destination = @users:1234:available
)send [USD/2 2000] (
source = @platform:rewards:pool
destination = @users:1234:available
)send [USD/2 50000] (
source = @users:1234:available
destination = @world:bank:checking
)The balance is derived from the posting history. $500 in, $20 in, $500 out leaves $20. The refund and the reward are both visible in one audit trail. There is no second table to drift and no reporting pipeline to reconcile.
Without double-entry structure, your early-stage shortcut becomes a fragile mini-core. Reconciliation scripts patch over balance drift, multiple code paths touch money, and the month-end close requires engineering to debug before finance can certify. A modern ledger eliminates core banking failures.
A modern ledger is an immutable, double-entry, transaction-level system of record for money movements, distinct from a full core banking system. Its bounded responsibility is to record postings, derive balances from those postings, and maintain a complete audit trail. It is the one place every connected source posts to.
Five invariants define the ledger's contract and give finance and engineering one provable source of truth for every balance the business reports.
The ledger answers one question: across every provider and internal system, what is the provably correct balance right now? Recording postings and not running products is what separates the ledger from the core banking system.
In a modern ledger‑first architecture for fintech and embedded finance, the modern ledger sits beneath the existing core banking system or BaaS as the system of record for money movements, while the core continues to own product logic and customer lifecycle.
| Responsibility | Core Banking System | Modern Programmable Ledger |
| Product definitions (deposits, loans, cards) | Owns | Does not cover |
| Customer lifecycle (open, maintain, close) | Owns | Does not cover |
| Interest accrual and fee rules | Owns | Does not cover |
| Legally binding statements | Owns | Does not cover |
| Double-entry postings for all money movements | Partial (own accounts only) | Owns across all sources |
| Immutable transaction log | Operational records may be updated over time | Append-only by design |
| Cross-provider balance reconciliation | Does not cover | Owns |
| Regulatory-grade traceability across rails | Does not cover | Owns |
| Multi-asset support (fiat and digital assets) | Typically fiat only | Asset-agnostic |
The core banking system continues to own product logic, customer lifecycle, interest calculation, and fee rules.
A connectivity layer (the integration tier between external providers and the ledger) translates each provider's native webhooks, files, and API formats into a single canonical posting schema, normalizes every money movement, and writes it to the ledger. The connectivity layer ingests postings from the core banking system, banks, PSPs, and the card processor. Balance queries for funding decisions resolve at the ledger, and reconciliation runs against external statements at configurable intervals throughout the day.
When you add a new bank partner or switch PSPs, the connectivity layer absorbs the new source and you do not have to restructure the ledger. When a core emits or consumes events, the ledger beneath stays consistent regardless of which core produced the event. The same pattern supports multiple cores and external providers behind one ledger.
Formance Ledger is purpose-built for this architecture. It is an open-source, programmable accounting database that records postings with immutability, double-entry enforcement, and a regulatory-grade audit trail, and a separate Connectivity module ingests data from PSPs, banks, and digital asset providers.
Layer a purpose-built modern ledger underneath your existing core banking system. Replacing a core is a multi-year program; adding a ledger beneath it removes the reconciliation burden without disrupting product logic. Building more core-like logic in-house means owning reconciliation scripts and audit trails for fund attribution forever, and most teams do not have the resources to build a double-entry ledger platform from scratch.
A purpose-built ledger lets you keep your existing core (and any future cores) while standardizing correctness underneath. Formance replaces the homegrown reconciliation layer that breaks at scale, turning month-end close from an engineering dependency into a finance task. Open source matters because retaining control over the ledger avoids the lock-in that creates future migrations.
Liberis, an embedded finance platform for SMBs, shows the under-the-core pattern in production. Bundled transactions and split mechanisms across multiple partners made reconciliation difficult at scale across 14 countries. With Formance as the ledger, Liberis reported 0 reconciliation errors across those countries, freeing the team to ship products instead of patching their reconciliation pipeline.
Stripe and Block built their own ledgers; most companies should not. The engineering hours spent maintaining a homegrown ledger build are hours not spent shipping the products your customers are paying for.
Start with one rail. Route its postings through Formance Ledger alongside your existing core, and watch the reconciliation gap on that rail close before you touch anything else. The Formance Ledger docs walk through the under-the-core setup end-to-end.
FedNow makes settlement instant and irrevocable. Learn how to handle retry logic, ledger design, reconciliation, and fraud controls on real-time rails.
An engineering framework for evaluating payment processors on idempotency, failover, ledger, reconciliation, and compliance.