Core banking integration engineering that classifies every interface by direction and authority before designing it, because a read can be retried and a write changes the authoritative record of the institution.
Integration programmes are specified as connecting to the core, as though that were one activity. A balance enquiry, a transaction history query, a posting, a customer detail update and a process initiation are five different engineering problems with five different failure modes.
Classify every interface to the core by what it does to the authoritative record. The classification determines the design, the testing, the failure handling and the governance, and almost nothing else does.
Reads and writes are designed the same way
So a retry that is safe on one is a duplicate on the other.
Every channel connects to the core directly
Multiplying load, dependencies and release coupling.
The interface inventory is incomplete
And the undocumented ones are in use.
Transaction state is inconsistent across systems
The core posted it and the channel does not know.
Batch dependency is treated as a defect
Rather than as a business definition to model.
The fast path is the unsupported one
Direct table access that voids support and breaks on upgrade.
The core team hears about it late
And they have a veto, exercised at the worst moment.
Nobody owns the integration end to end
Two system owners and a gap between them.
List every interface to your core and mark each one read or write. Then check whether the write interfaces have idempotency, a defined unknown state and an enquiry path. In most estates the reads are numerous and well understood, the writes are fewer and were built with the same assumptions as the reads, and at least one of them will create a duplicate if it is retried after a timeout. That list takes a day to assemble and it identifies the integrations that can cause a financial loss.
The core banking team is a stakeholder with a different objective to the programme. Their job is that the core keeps running and keeps posting. They are usually consulted after an architecture has been approved, and they are usually right.
Establishing what the core can provide, through which interface, at what volume and in what window is a conversation worth having in week one. It frequently removes an option the business case assumed, and it is far cheaper to hear then.
Step 1
Assess the core platform, its interfaces and its constraints
Step 2
Discover the existing interfaces from evidence, not documentation
Step 3
Agree the access envelope with the core team
Step 4
Classify every required interface by direction and authority
Step 5
Design the data contracts per interface
Step 6
Design the adapter layer so the core has few consumers
Step 7
Decide the batch, event and request pattern per flow
Step 8
Design write paths with idempotency and an unknown state
Step 9
Build reconciliation into every write flow from the start
Step 10
Test the failure paths, including timeout and partial outcomes
Step 11
Validate against the core under realistic load, in a window agreed
Step 12
Monitor availability, latency, failures, drift and batch completion
Ask the core team what they would refuse, and why. Before the architecture is drawn, not after. Which access mechanisms they will not support, which volumes they cannot absorb, which windows are untouchable, and what would void their vendor position. The answers usually remove at least one option the business case assumed and identify at least one existing connection they want gone. Both are cheaper to know in week one, and the conversation also converts the core team from a late objector into a participant.
Grouped by what each part guarantees. The reconciliation group is the one that makes the rest trustworthy, and it is the one most often added after a problem.
Access and adapters
Legacy system adapters for the mechanisms the core actually supports, including the ones nobody enjoys working with
API enablement in front of the core, giving consumers a modern contract without modifying the platform
Middleware connectivity across existing integration infrastructure rather than beside it
Secure file transfer where that remains the supported mechanism, treated as a real integration with real controls
Protocol and format translation, with the translation layer kept free of business logic
Data and transaction services
Account and customer data integration, with the core as the authoritative source and every copy marked as derived
Balance and posting interfaces, with the freshness bound stated and visible to consumers
Transaction services with idempotency, a defined unknown state and an enquiry path
Non-financial update flows with an ordering guarantee and a conflict policy
Process initiation with status visibility, since a started process the caller cannot observe is the worst case
Batch and event patterns
Batch modernisation where the pattern is wrong, and batch retention where the business definition genuinely is a cycle
Change capture where the core supports it, and scheduled extraction where it does not
Event integration for what is genuinely event-driven, published once and consumed many times
Cut-off and business date handling as data, on the model described on our Banking Data Platform Engineering page
Reconciliation and operations
Reconciliation designed into every write flow rather than added after the first break
Drift detection between the core and any system holding a derived copy
Interface monitoring with a named owner, per interface, agreed before go-live
Operational runbooks for the failure paths, written by the people who will be called
The third column is the point of the table. These consumers are usually given the same interface, and they have genuinely different requirements for freshness, authority and volume.
| Consumer | What it asks of the core | What it actually needs |
|---|---|---|
| Digital banking channels | Balances, history, transfers | Low latency reads and safe, idempotent writes |
| Customer servicing | Account detail, changes, requests | Write ordering and a conflict policy |
| Lending systems | Account setup, disbursement, servicing | Reliable write with a confirmed outcome |
| Payment processing | Posting, balance check, status | Idempotency, and the unknown state handled |
| Customer 360 | Party, account and relationship data | Completeness, not latency |
| Branch and assisted channels | Everything, interactively | Availability during business hours above all |
| Operational reporting | Volume extracts, periodically | A window that does not disturb the cycle |
The architecture question that matters least is which middleware. The one that matters most is whether each interface has an agreed contract, because almost every integration incident traces back to an expectation that was never written down.
What each interface contract has to settle
Authentication and authorisation: how each side proves who it is, and what happens when a credential or certificate expires
Error semantics: what each error means, which are retryable, and what the caller is expected to do about each one
Retries and idempotency: whether a repeated call is safe, and how the two sides agree that it is the same call
Observability: what each side logs, with a shared correlation identifier so one transaction can be followed across both
Reconciliation: how the two sides confirm they agree, on what cycle, and who investigates a difference
Change management: notice periods, versioning and who is informed before anything changes
And volume and timing: the expected rate, the peak, and the windows in which it may or may not run
What each architectural layer contributes
An API gateway and adapter layer presenting the core’s capability as a contract, with the access envelope enforced here
Integration middleware or a service layer carrying orchestration and transformation, kept free of business logic
Message queues and event streaming for asynchronous flows, with ordering guarantees where sequence matters
Secure file transfer as a first-class integration where that is the supported mechanism, with completeness controls
Legacy protocol handling for the mechanisms the core actually offers, isolated so consumers never see them
Hybrid connectivity, since the core is frequently on-premises and the consumers increasingly are not
And reconciliation running across the boundary continuously rather than at period end
Pick one write interface and ask how you would know if it had silently failed. Not failed loudly, failed silently: a timeout recorded as a failure that actually posted, a partial batch, a record rejected by the core and never retried. If the answer depends on somebody noticing a complaint or a month-end break, the interface has no reconciliation and the institution is relying on the absence of evidence. That is the question worth asking of every write interface before anything new is added.
Which regulatory, resilience, change management and data protection requirements apply to a given interface, and what approvals are required, are determined by your compliance, risk, audit and security functions, based on your operating markets. We do not interpret those requirements and this page does not state which apply to you.
Technology supports a control framework. It does not independently establish one.
Integrity and consistency
- The core treated as authoritative, with every other copy marked derived and carrying a stated freshness
- Idempotency on every write path, treated as a control rather than an engineering preference, since a duplicate posting is a loss event
- Reconciliation across the boundary as a continuous control with categorised differences and owned breaks
- Ordering guarantees where sequence determines an outcome, implemented rather than assumed
Access and protection
- Access to the core scoped to the adapter layer rather than granted per consuming application, which is the main reason the layer exists
- Credentials, certificates and keys inventoried with owned expiry, because this is the most common avoidable integration outage
- Encryption in transit and at rest, with the path to and from the core treated as part of the protected surface
- Data minimisation on every interface, since an interface returning more than the consumer needs is an exposure that grows with every new consumer
Change and ownership
- A named owner per interface on both sides, agreed before go-live rather than established during an incident
- Change control linking the core’s release cycle to every consumer, so a core upgrade is a planned event for all of them
- Versioning with a notice period, including for internal consumers who assume none is needed
- Any unsupported access path recorded as a time-limited risk acceptance with an owner and a replacement plan
Resilience and audit
- Defined behaviour when the core is unavailable, per interface and per consumer, as described on our Digital Banking Platforms page
- Load and rate limiting enforced in the adapter, so no single consumer can degrade the core for everybody
- Audit trails over every write, every unknown outcome and its resolution, and every access to the interface
- Retention of integration logs sufficient to investigate a transaction after the fact, which is frequently longer than engineering defaults
Integration monitoring reports availability and response time, which describe the pipe. What matters is whether the two systems still agree, whether anything is in an unresolved state, and whether the cycle completed.
| Failure | How it presents |
|---|---|
| A write posted and was recorded as failed | A duplicate, after somebody retries |
| A file arrived short | The job succeeded and records are missing |
| A derived copy drifted | Two balances, and a complaint |
| One consumer is degrading the core | Everybody slows down and nobody knows why |
| Unknown outcomes accumulating | Resolved manually, slowly, with no process |
| A certificate expired | A clean outage with a trivial cause |
| An undeclared direct connection appeared | Load with no owner and no contract |
| The batch finished late | Downstream consumers started on stale data |
The outcomes below follow from three choices: classify every interface by direction and authority, give the core few consumers rather than many, and build reconciliation into every write flow.
More reliable connectivity, measured per interface rather than per platform, with a named owner on each
Reduced integration complexity, through an adapter layer rather than a connection per consuming application
Data consistency that can be demonstrated, because drift against every derived copy is measured
Digital services enabled faster, since a new consumer integrates to a contract rather than to the core
Operational visibility across interfaces, unknown outcomes, reconciliation and batch completion
A core that is less loaded and less coupled, which is also the largest reduction available in the cost of any future core change
Unsupported access paths identified, owned and on a plan rather than quietly permanent
We will take your interface inventory and establish four things: which interfaces write to the authoritative record, which of those are safe to retry, where derived copies drift, and which access paths are unsupported. You get the findings whether or not we build anything.
CaliberFocus engineers core banking integration that classifies every interface by direction and authority before designing it, because a read can be retried and a write changes the authoritative record. We agree the access envelope with the core team first, give the core few consumers through an adapter layer, use supported interfaces, and build reconciliation into every write flow.
- Every interface classified as read or write before it is designed
- Idempotency and a defined unknown state on every write path
- An adapter layer so the core has few consumers rather than many
- Reconciliation across the boundary as a continuous control
Security & Compliance
