How to build a core banking system
What a core banking system does, the ledger and controls at its heart, the systems around it, and an order to build or modernise it in.
What a core banking system does
A core banking system keeps customers' accounts and balances, books every transaction to a ledger, applies interest and fees, and feeds payments, cards and reporting. It is the system of record a bank cannot afford to get wrong.
Few teams build a full core from scratch. Most build around one: back-office consoles with maker-checker, product configuration, card controls and analytics that the core vendor does not provide.
The modules you need
Most teams need all of these in the end. The phased plan below sets the order.
Customers and accounts
Customer records, accounts, mandates and who may act on each account.
Ledger
Double-entry postings for every movement, with balances derived from the entries.
Product configuration
Interest, fees, limits and terms set per product and version.
Payments
Incoming and outgoing payments through local schemes, with screening and limits.
Cards
Card issuing, controls and disputes, usually through an issuer processor.
Back-office console
Staff actions on accounts and customers, with maker-checker on anything sensitive.
End of day and interest
Accruals, interest, fees and statements run on schedule.
Regulatory reporting
Data for returns, liquidity and capital reports.
How the parts fit together
- 01
Immutable ledger
Postings are never edited. Corrections are new entries, so every balance can be explained.
- 02
Products as versioned configuration
A product change applies from a date and never rewrites history.
- 03
Maker-checker everywhere it matters
Limit changes, manual postings and customer changes need a second person.
- 04
Event stream
Every posting and change published as an event for payments, fraud and reporting.
- 05
Resilience
Recovery targets per service, tested failover and backups.
Data model sketch
- 01
Customer and party
People and companies, with identifiers, KYC status and relationships.
- 02
Account
Product, currency, status, holders and mandates.
- 03
Posting
Debit and credit entries with time, value date and source.
- 04
Product version
Rates, fees and terms in force from a date.
- 05
Approval
Who made and who checked each sensitive change.
Systems it has to talk to
- 01
Payment schemes
Local instant, batch and card schemes, often through a payment hub.
- 02
Card processor
Issuing, authorisation and disputes.
- 03
KYC and screening
Onboarding checks and ongoing sanctions screening.
- 04
General ledger and reporting
Finance and regulator reporting.
- 05
Digital channels
Mobile and web banking through a secure API layer.
Rules to design for
Which rules apply depends on your market and product.
- 01
Banking regulation
Licensing, capital, liquidity and reporting rules set by the banking regulator.
- 02
Operational resilience
DORA in the EU and technology risk rules elsewhere, such as Singapore's MAS TRM guidelines.
- 03
Payments and SCA
PSD2 in the EU and UK, with strong customer authentication and refund rules.
- 04
AML and sanctions
Monitoring and screening on accounts and payments.
- 05
Card data
PCI DSS where card data is handled.
From prototype to production
Build in this order so something real is in users' hands early.
- 01
Clickable prototype
The back-office console and product setup, tried by operations staff.
- 02
Ledger and one product
The ledger, accounts and one product live with maker-checker and reconciliation.
- 03
Payments and cards
Payment scheme and card processor integrations.
- 04
More products and migration
More products, reporting and moving accounts from the old core.
What drives the cost
These decide most of the budget. For a number based on your own scope, use the cost tool. OceanLab bills $30-50/hr or per milestone.
- 01
Build or wrap
Building around a vendor core costs far less than replacing it.
- 02
Products
Each product brings its own rules, accruals and statements.
- 03
Payment schemes
Each scheme needs certification and testing.
- 04
Migration
Moving live accounts with balances that must match to the cent.
- 05
Resilience requirements
Recovery targets and testing set by the regulator.
Product builds that match this guide
Keelstone - Core Banking Back-Office Console with Maker-Checker
Designed and built a clickable back-office console for a Singapore bank's deposit operations: holds and blocks, limit changes, fee waivers, payment repairs and end-of-day, with every money-moving change going through maker-checker approval.
Njia - Branch & ATM Analytics with Cash Forecasting and CIT Planning
Designed and built a clickable analytics console for a Kenyan bank's branch, ATM and agent network: footfall, queue waits against the service charter, ATM uptime by cause, 14-day cash forecasts and cash-in-transit orders with two-person approval.
Pasje - Card Issuing and Card Controls Ops Console
Designed and built a clickable ops console for an Amsterdam fintech's Visa debit cards: find any card, see why an authorisation was declined, freeze, block or replace a card, and work the dispute queue against scheme deadlines - without staff ever seeing a full card number.
Two ways to work with OceanLab
Project build
We design and build the system as one project. It starts with a clickable prototype your team tries before any production code is written. Pay per milestone (outcome-based) or hourly at $30-50/hr, depending on role and seniority.
Embedded engineers
Our engineers join your team on a flexible monthly retainer. Part-time is fine and it runs month to month, with hours that overlap the US, UK and Europe, the Middle East, and Australia and Asia. Outcome-based or $30-50/hr.
Questions
Should we replace our core?
Often not first. Building consoles, product configuration and APIs around the existing core gets most of the benefit, and the core can be replaced later behind the same interfaces.
How do you make sure balances are right?
With an immutable double-entry ledger, daily reconciliation against schemes and accounts, and no edits to postings, only correcting entries.
What does maker-checker cover?
Anything that moves money manually, changes limits or changes a customer's details. One person makes the change, a second approves it, and both are logged.
