Core banking
Building on top of a core banking system without destabilising it
The core is the one system nobody is allowed to slow down. Everything modern a bank or NBFC wants to launch has to reach it, and how you reach it decides whether the project is a quarter or a year.
The short answer
Integrate with a core banking system through its published service layer where one exists, and through a controlled batch or staging layer where it does not — never by querying core tables directly. The constraint that shapes every design is that the core cannot absorb unpredictable read load from a customer-facing channel.
Interfaces
How it actually exposes data.
The interfaces, the pitfalls, and how we handle each.
Vendor service layers
Finacle exposes services through its integration suite, Flexcube through published gateways, BaNCS through its own service catalogue. Each is versioned, licensed and change-controlled — availability of a specific service is a commercial and release question, not just a technical one.
ISO 20022 and SWIFT messaging
For payments and interbank flows, message standards are usually a cleaner contract than any vendor API, and they survive a core upgrade that would break a proprietary interface.
Batch files and end-of-day extracts
Still how a great deal of real integration happens. Perfectly legitimate for anything that does not need to be current to the second — and honest about latency in a way a badly-cached API is not.
A staging database or ODS
Where the core cannot serve reads at channel volume, an operational data store fed on a defined cycle carries the query load. This is the pattern that keeps the core stable, and it is usually the first thing we build.
What goes wrong
The failures that are not in the documentation.
Every one of these has cost somebody a release. They are the reason the design below looks the way it does.
Reading straight from core tables
It works in UAT and it is the single most common cause of a production incident on the core. Schema is undocumented, changes on vendor upgrade, and the load pattern of a customer-facing screen is nothing like a batch job. Every core team has a story about this.
Assuming a service exists because the brochure lists it
The vendor's catalogue describes the product. What is licensed, deployed and enabled at your bank is a smaller set, and finding out takes weeks of someone else's time. Confirm it before it is a dependency in a plan.
Designing as if the core is always available
Cores have maintenance windows and end-of-day processing during which they are unavailable or read-only. A channel that cannot degrade gracefully through EOD is a channel that is down every night by design.
Ignoring RBI outsourcing directions until security review
Where data may reside, who may access it, and what the bank must be able to audit are architectural constraints, not paperwork. Discovering them at the review stage means redesigning after the build.
Method
What we build in front of it.
- 01
Establish what is actually available
Licensed services, environments, test data and the release calendar. This is discovery work with the bank's core team, and its output changes the architecture — so it comes before the architecture.
- 02
Put a layer between the core and everything else
One integration layer owning authentication, retries, idempotency, caching and audit. Every channel talks to it; nothing talks to the core directly. It is also the only way to make a core upgrade a contained change.
- 03
Design for the degraded case first
What the customer sees during EOD, during a maintenance window, and when a service times out. Deciding this early produces a different and better system than adding it after a production incident.
- 04
Prove it under real load before launch
Against a core-like environment, at expected peak. The core team will require this, and they are right to.
Questions
What people ask before starting.
Next step
Need to connect to Core banking?
Bring the constraint everyone has been working around. Forty-five minutes with an engineer who has done this before is usually enough to tell you whether it is a week or a quarter.
- No sales deck
- An engineer on the call, not an account manager
- NDA before you share anything