Putting a supported interface in front of a core banking system

The core banking platform is not going to be replaced this decade. It is certified, audited, integrated with thirty other systems, and operated by a team that has run it for fifteen years.

Any proposal to migrate it is therefore either a multi-year programme or a proposal that has misunderstood the problem. Both are avoidable.

The three options, honestly

Screen-scraping. Fast to build, unmaintainable within a year. It breaks silently when a screen layout changes, nobody notices until a reconciliation fails, and the failure has no audit trail. Occasionally unavoidable as a short-term bridge, never as an architecture.

Direct database access. Faster and more dangerous. You have coupled yourself to the vendor's internal schema, which changes on upgrade schedules you do not control. A routine patch can break your integration without any change on your side.

A supported interface with an adapter layer. A narrow contract-tested adapter that owns all knowledge of the core's shape. Everything else in the estate talks to the adapter.

The third option costs more up front. It is the only one that survives the first upgrade.

What the adapter should own

• Every call the estate makes to the core, and nothing else
• Authentication, and the mapping of your service accounts to core operator IDs
• The translation between your domain vocabulary and the core's
• Retry, timeout and circuit-breaker behaviour
• A contract test suite that runs against a recorded-response fixture set
• An audit log of every call, retained on the same schedule as the core's own logs

The critical property: no application outside the adapter knows what the core looks like. When the vendor changes a field name, one component changes.

Build the contract tests before the integration

Record real responses from the core — anonymised, of course — and build a test suite that asserts the adapter's behaviour against them. This gives you:

• confidence to refactor the adapter without touching a live system
• a way to detect a breaking change during the vendor's upgrade, before cutover
• documentation that is executable, rather than a Word file nobody trusts

Test the failure paths too. Timeouts, partial responses and malformed records are where adapters actually break, and they are what you will meet at 2am.

Data consistency is a business decision

Read-only integration is comparatively easy. The moment you write, you own consistency.

The questions to settle before the first write:

• Is the core or your service the system of record for this field?
• What happens when your write succeeds and the subsequent read disagrees?
• Can a human correct the result, and is that correction audited?
• Does the core support idempotent operations, or can a retry duplicate a transaction?

Most core platforms offer an API precisely because they cannot guarantee this on your behalf. Confirming what yours actually supports, in writing, before designing around it, saves a redesign later.

Deal with the unknown dependencies

Every core estate has undocumented integrations. Batch jobs with hardcoded hostnames. A regulatory report that reads a view directly. A downstream system connected by a user nobody currently employs.

Discovery should produce a dependency list that is genuinely complete, including the parts the core team does not know about. Then classify each: migrate it, replace it, or accept it and monitor it.

The fourth category is the one that causes outages. "We did not know that existed" should not be a sentence anyone has to say during a migration wave.

What good looks like

• One contract test suite covering every core interaction
• A dependency inventory that includes the undocumented dependencies
• A documented position on which system owns each written field
• An upgrade rehearsal performed before the vendor's release, not after
• Monitoring on adapter latency and error rates, separate from business-level metrics

None of this is novel. It is the cost of integrating with a system you do not control, and it is the reason the cheapest-looking option is usually not the cheapest.