Enterprise integration across banking applications, operational systems and business workflows, built on decisions about who owns each piece of data rather than on middleware selection.
Integration moves data. It does not settle who is right about it. When two systems hold a different customer address, an interface between them produces the wrong address more quickly and in more places, and the institution now has a data problem with a technology project attached to it.
Every one of these has a right answer for your institution. The cost of not deciding is not that the integration fails. It is that it works, and propagates the ambiguity everywhere.
Point-to-point connections nobody inventoried
An unknown interface cannot be changed or removed.
The same customer, six identifiers
So every integration carries its own matching logic.
Two-way synchronisation between two owners
Which is a corruption mechanism with a schedule.
Manual extracts and spreadsheets in the path
A process step that depends on one person.
A source team changed a field
The most common cause of integration failure.
Freshness nobody states
So the data is either trusted wrongly or not at all.
Failures that are visible only downstream
Discovered by the team that needed the data.
A canonical model project in its second year
Delivering agreement nobody is waiting for.
Pick the customer address field and ask which system owns it. If more than one answer comes back, or the answer is that it depends on the channel, the institution has an ownership problem that no integration platform will fix. The same question applied to five or six commonly disputed fields produces a more accurate picture of integration maturity than any architecture assessment, and it can be done in a morning.
Integration programmes commonly run in the opposite order: a platform is selected, patterns follow from what the platform does well, and ownership is settled per interface by whoever builds it.
That sequence produces an estate where the technology is modern and the data is still contested. We work the other way, which is slower to start and considerably faster to finish.
Step 1
Inventory the integration estate, including the undocumented parts
Step 2
Map data flows to the business processes that depend on them
Step 3
Establish ownership per data element with the business
Step 4
Define direction, freshness and conflict policy per element
Step 5
Resolve customer and party identity before anything else
Step 6
Design a domain data model, not an enterprise one
Step 7
Select the pattern per flow: API, event, batch, file or capture
Step 8
Design failure behaviour and reprocessing for each interface
Step 9
Build with contract tests between producer and consumer
Step 10
Validate with reconciliation, not with a successful run
Step 11
Deploy with freshness published and failure alerting owned
Step 12
Retire what the new flow replaced, deliberately
Ask how many conflicts your existing synchronisations resolved last month. If the number is unavailable, conflicts are being resolved silently and data is being discarded without a record. The fix is a log line and an alarm, which is an afternoon of work, and it converts an invisible data integrity risk into a measurable one. The volume usually surprises people.
Grouped by what each part does. The contract and quality group is what distinguishes an integration estate that can be changed from one that can only be added to.
Application integration
Application-to-application integration across your banking, servicing, CRM, finance and operational systems
API integration and the development of internal API products where the same data is needed by several consumers
Event-driven integration, where the producer publishes a change and consumers subscribe rather than being connected individually
Workflow integration, so a business process that crosses systems has one view of its state
Enterprise service connectivity through your existing middleware, or through its replacement, per our Integration Platform Modernization page
Data movement
Operational data synchronisation between systems, with direction, freshness and conflict policy stated per element
Change data capture from source systems where that is the right pattern and the schema coupling is acknowledged
Batch and file integration, modernised where it should be and made observable where it should stay
Feeds into your analytical platform, which our Banking Data Platform Engineering page builds. We move the data to it, that page turns it into a product
Reference and master data distribution from a stated owner outward
Identity and contracts
Customer and party identity resolution, so downstream integrations stop implementing their own matching
Domain data models, versioned, with documented differences between domains
Interface contracts with contract testing between producer and consumer
Schema change governance, so a producer change cannot silently break a consumer
Quality and operations
Validation at the boundary, so bad data is rejected where it enters rather than propagated
Reconciliation between source and target on counts and values
Data quality exception handling with a queue, an owner and an age
Freshness publication per feed, as section 7 describes, and monitoring per section 8
Reprocessing and replay, so a failed run can be corrected without manual repair
Each of these is a familiar integration. What makes them hard is not the connection. It is the question each one forces about who owns what, and that question is listed alongside.
Customer 360 data exchange
Assembling a single operational view of a customer across products, channels and systems.
CRM integration
Keeping relationship, contact and interaction data aligned between the CRM and the systems that actually transact.
Loan and servicing data synchronisation
Moving data between origination, servicing, collections and the systems of record across the life of a facility.
Finance and ERP integration
Feeding the general ledger and finance systems from operational sources, and returning what finance determines back.
Compliance and regulatory data exchange
Assembling data for compliance functions and for regulatory submission processes.
Operational workflow connectivity
Giving a process that crosses several systems one view of its own state.
Feeds to the analytical platform
Moving operational data to the platform where it becomes a reporting and analytics product.
Ask who decides that two customer records are the same person. If the answer is the matching logic, rather than a named business owner who set the rules, then a consequential judgement is being made by code nobody reviews. In banking that judgement can combine two people’s financial lives or split one person’s, and both outcomes reach the customer. It belongs to a person, documented, with the engineering implementing their decision.
There is no single correct integration pattern, and estates that standardise on one end up forcing flows into a shape that does not suit them. We select per flow, and the selection criteria matter more than the technology.
The patterns and when each is right
Synchronous API
When the consumer needs an answer now and can wait a moment for it. Wrong when the consumer only needs to know eventually, because it creates an availability dependency nobody wanted.
Event publication
When several consumers care about the same change and the producer should not need to know who they are. The best default in most banking estates, and the one that requires the most discipline about contracts.
Change data capture
When the source cannot publish events and will not build an interface. Right often, and coupled to the source schema, as section 4 sets out.
Batch and file
When the volume is large, the consumer works on a cycle, and nothing needs to be current. Still the correct answer for a great deal of banking data, and the thing to make observable rather than to replace on principle.
Request and response messaging
When the work is asynchronous but a specific reply is needed, including where a queue absorbs a difference in availability between two systems.
Platform components
API gateway and management, where internal API products are the pattern
Event streaming or message brokers, with retention long enough to replay
Integration middleware, existing or replaced, per our Integration Platform Modernization page
Movement tooling for batch and capture workloads
A schema or contract registry, which is what makes event estates maintainable
Secure file transfer, because files will still be part of the estate
And hybrid connectivity, since the systems are not all in one place and will not be
Integration governance is mostly the enforcement of decisions made elsewhere. Where those decisions have not been made, the integration layer ends up making them by accident, which is the failure mode this whole page is about.
Data ownership
Recorded per element, with the owning function named.
Schema governance
Versioned contracts, compatibility rules, consumer visibility.
Access control
Who may read and write each flow, least privilege, reviewed.
Encryption
In transit and at rest, with managed keys, per your standards.
Lineage
Where a value came from and what happened to it on the way.
Reconciliation
Source against target on counts and values, on a cycle.
Retention and privacy
Applied to the copies integration creates, not only the originals.
Change management
Interface change governed, tested and communicated to consumers.
Integration monitoring is normally built for the team that runs the pipes: job status, throughput, error counts. The team that depends on the data needs something different and rarely has it.
What every consumer of a feed should be able to see without asking
How fresh this data is right now, as a published figure rather than a schedule that may or may not have run
Whether the last load was complete, which is a reconciliation statement rather than a success flag
And whether there is a known problem affecting it, so a consumer can stop making decisions on data that is being corrected
What the integration team monitors, which is a different list
Data freshness and synchronisation delay per flow, against the bound that was stated
Failed jobs and runs, with an alarm on the run that did not start as well as the one that failed
Throughput and latency per interface, trended, since a flow that is slowing is a capacity warning
Integration errors by type and by interface, because errors cluster at the weakest interface
Data quality exception volumes by source and by rule
Reconciliation results and break ageing between source and target
Conflict resolutions in any remaining two-way synchronisation, per section 3
Schema change events and contract test failures, which are the leading indicator of the next incident
Manual interventions and reprocessing volume, which point at the interface to fix next
And completion of the business processes that depend on these flows, because a dashboard of healthy interfaces beside a process that is not completing means the integration is working and the outcome is not
Ask a business consumer of any feed how fresh they believe their data is. Then ask the integration team. The two answers differ in most institutions, and the gap is where decisions are being made on assumptions. Publishing freshness per feed is a small engineering change and it ends that entire category of dispute, including the one that happens during an incident when nobody can agree what the data was showing.
Outcomes depend on your estate and on how much of the ownership work has already been done. These are the changes the work is aimed at.
Each contested data element has one owner, one direction of flow and a stated freshness bound
Two-way synchronisations are either removed or have a conflict policy somebody chose and can see firing
Customer identity is resolved once, so integrations stop implementing their own matching
Consumers can see freshness and completeness without asking, and stop making private judgements about trust
A source schema change fails a build instead of breaking a consumer in production
Bad data is rejected where it enters, with an owned exception queue, rather than cleaned in six places
Reprocessing is a routine capability rather than an incident
Manual extracts and spreadsheet steps come out of the critical path
And the estate is inventoried, which makes every subsequent change estimable
Bring us one integration that keeps causing problems, or a single customer view that nobody trusts, and we will map the flows behind it, identify which ownership decisions are missing, and define a first piece of work with an acceptance test you can check yourself.
CaliberFocus builds enterprise integration for banks on decisions about who owns each piece of data rather than on middleware selection. We establish ownership, direction, freshness and conflict policy per element, resolve customer identity once, select the integration pattern per flow, validate at the boundary, and publish freshness so consumers know what to trust.
- One owner and one direction for every contested data element
- Customer identity resolved once instead of in every interface
- Contract tests and a schema registry so changes fail a build, not production
- Freshness and completeness published per feed
Security & Compliance
