Banking integration is the engineering that connects a bank’s core ledger to everything around it – payment rails and messaging networks, customer-facing channels, CRM, risk and finance systems, regulatory reporting, and the data platforms that feed them all. In most industries, an integration that occasionally loses a record is an inconvenience. In a bank, it’s a reconciliation break, a misstated balance or a finding in the next audit, and that’s why integration in banks and payments firms is shaped as much by control requirements as by technology.
In this article, I’ll go through the integration estate of a typical bank or payments firm, domain by domain, along with the patterns and risks that come with each. Then I’ll turn to the regulatory and audit demands that set banking apart, the long move from overnight batch to real-time processing, and how to modernize around a core system that nobody can afford to break. Along the way, I’ll draw on two pieces of eProxim’s own published work in financial services.
The shape of a bank’s integration estate
Most banks run on a core banking system that’s older than almost everything connected to it. It holds the accounts, the balances and the posting rules, and it is the system of record for money in a very literal sense. Around it sit dozens or hundreds of other systems – many of them added through acquisitions or regulatory programs – and each one needs some part of what the core knows: payment hubs, card processors, lending platforms, digital banking, CRM, fraud detection, the general ledger, data warehouses and reporting tools.
Nobody really designs the resulting estate. It accumulates. A new channel needs balances, so someone builds a point-to-point link. A regulator asks for a new report, so an extract gets added to the nightly batch. Each decision is reasonable on its own, and together they produce a web of dependencies in which nobody can say with confidence what would break if a particular file arrived late. So integration work in a bank is as much about understanding and taming this inheritance as it is about building anything new.
Integration domains, patterns and risks
The domains below turn up in some form in nearly every bank and payments firm. The patterns are typical (they aren’t universal), and the risks are the ones that most often turn into incidents or audit findings.
| Domain | Typical systems | Common integration patterns | Characteristic risks |
|---|---|---|---|
| Core banking | Deposit and loan ledgers, posting engines | Batch files, message queues, vendor APIs, change data capture | Fragile batch windows, limited API coverage, change freezes |
| Payments | Payment hubs, clearing and settlement links, card processing | Standards-based messaging, real-time APIs, queued file exchange | Duplicate or lost payments, cutoff times, format migration |
| Channels | Online and mobile banking, branch, contact center | APIs over a service layer, cached balances and transactions | Stale balances, load spikes, inconsistent views across channels |
| CRM and onboarding | CRM platform, KYC and identity verification, document management | API synchronization, event-driven updates, workflow orchestration | Conflicting customer records, no clear system of record for customer data |
| Risk and fraud | Fraud scoring, AML monitoring, credit risk engines | Real-time event streams, scheduled bulk feeds | Slow decisions, incomplete data, alerts nobody can explain |
| Finance and GL | General ledger, finance reporting, treasury | Batch postings, journal interfaces, reconciliation jobs | Breaks between the subledgers and the GL, month-end bottlenecks |
| Data and regulatory reporting | Warehouse or lakehouse, reporting tools, regulatory submission | Extracts, CDC pipelines, API layers over systems of record | Gaps in lineage, inconsistent definitions, late or restated reports |
Two things follow from the table. First, the same customer, account or transaction shows up in almost every row, so system-of-record decisions are a long way from being a detail. They decide whether the bank can answer a simple question – what a customer’s balance was at a given moment, say – the same way in every channel and every report. Second, the risks cluster around timing and completeness much more than around connectivity. Getting two systems to talk to each other is rarely the hard part. The hard part is proving that they agree.
Payments and messaging standards
For most banks, payments are the most demanding domain, because they combine high volume, hard deadlines and money that can’t be casually recalled. A single payment may touch a channel, a fraud check, a sanctions screen, the core ledger, a payment hub and an external clearing or messaging network before it settles, and every one of those steps has to be traceable afterward.
Messaging standards are what make this manageable. ISO 20022, the most significant of them today, defines a common model and structured formats for financial messages, and many payment systems and cross-border messaging networks have been moving to it. Its value for integration is richer, structured data – parties, purposes and remittance information carried in defined fields, instead of being squeezed into free text. That richness is also what makes it hard. Systems built around older, shorter formats can truncate or lose data in translation, and a migration that maps the new fields correctly at the edge, only to throw them away in the core, gains very little. A bank approaching a messaging migration should treat it as an integration program that spans every system touching a payment, and resist the temptation to see it as a format conversion in one gateway.
The engineering principles for payment integration are the familiar ones, applied without compromise. Every message needs a stable identifier, and every consumer has to handle duplicates idempotently, because retries are inevitable and a duplicate payment is the most expensive kind of duplicate there is. Ordering assumptions have to be explicit. And failures should land in a queue that people actually watch, with a clear owner – they shouldn’t be retried silently until a cutoff has passed.
Regulatory and audit demands
Banks operate under a heavy and varied regulatory load, which differs by country, charter and business line, and integration teams rarely need to become experts in every regime. What they do need to understand is the demands those regimes place on systems, because the same demands come up almost everywhere, and they shape integration design directly.
Traceability is the first. A bank has to be able to show where a figure came from: which transactions, from which source systems, through which transformations, into which report. Supervisory expectations for risk data aggregation and reporting – the Basel Committee’s principles commonly known as BCBS 239, for example – have made data lineage an explicit concern for larger banks. Integrations that transform data without logging what they did, or that overwrite records without keeping history, make that lineage impossible to reconstruct.
Reconciliation is the second. Every interface that carries balances or transactions should be reconciled routinely, with control totals compared between source and target, and every break investigated and explained. In a bank, this goes well beyond a quality measure you can take or leave. It’s how the institution demonstrates that its books are complete and accurate. Reconciliation should be designed into an integration from the start, with the counts and amounts it will compare decided at the same time as the mappings.
Data residency and privacy make up the third. Customer data may be subject to rules about where it can be stored and processed, and those rules affect integration choices – which cloud regions a middleware platform may use, whether a SaaS CRM may hold certain fields, and how logs containing personal data are retained and masked. Operational resilience is a fourth theme, and a growing one, with regimes such as the European Union’s Digital Operational Resilience Act raising expectations for how financial institutions manage technology risk and third-party dependencies. For integration teams, that means documented failure modes, tested recovery, and a clear picture of which external services a critical process depends on.
In practice, all of this adds up to a set of defaults: immutable audit logs, retained message history that supports replay, reconciliation for every financial flow, data classification applied before any data is moved, and access controls on integration platforms that are as strict as those on the systems they connect. The specific obligations vary by jurisdiction, and they should be confirmed with the bank’s compliance and legal teams – never simply assumed.
From overnight batch to real time
For decades, banking settled much of its work in overnight batches. The approach has real strengths: it’s predictable, it’s easy to reconcile, and it’s forgiving of systems that can’t process continuously. But its weaknesses have grown with volumes and expectations. Batch windows shrink as transaction counts rise, customers expect to see their balances move the moment they act, and a batch failure discovered at six in the morning leaves very little time to recover.
We saw how far that shift can go when a global financial-technology provider brought eProxim in. Its platform is the system of record for moving money between one of the world’s largest banks and that bank’s correspondent network of more than 16,000 institutions – receiving, matching, processing and returning hundreds of millions of transactions a day. At the bank’s volume, squeezing settlement into a few overnight hours had become impossible, and its clients wanted to see their balances move in real time. We went after the real constraint. The two most expensive operations in transaction processing – finding an account record and updating it – are both bound by disk, so we designed an event-driven settlement hub on an in-memory data grid. The bank’s entire client-account dataset was held in memory and partitioned across processing nodes, so each transaction was routed to wherever its account already lived, processed in place, and written to disk asynchronously, which meant durability never throttled throughput. Running on eight commodity servers, the hub cleared the bank’s entire interbank flow at a sustained 240,000 transactions per second. That proved real-time settlement across the correspondent network, and it proved that the multi-hour nightly batch window could be retired. We also architected a multi-grid topology so throughput would keep scaling beyond network limits, and on the strength of that result, the provider moved to full build-out with eProxim as its architects.
I wouldn’t conclude from this that every bank needs an in-memory grid. What it does show is that the bottleneck in batch-era systems is usually structural – rooted in how records are found and updated – and that real-time processing becomes possible once the architecture tackles that bottleneck head-on, instead of trying to make the old process run faster.
Not every flow should become real time, and a sensible modernization program picks its targets. Customer-visible balances, payments, fraud decisions and notifications usually benefit the most. Regulatory reporting, some finance postings and bulk data loads often stay in batch, sometimes by design, because a defined cutoff is exactly what that process needs. The goal is to give each flow the timing it actually requires, and abolishing batch on principle has nothing to do with it.
Modernizing without risking the core
The core banking system is the one component that can’t be allowed to fail, which makes it both the most important thing to change and the most dangerous. Successful programs tend to have one thing in common: they modernize around the core before they modernize the core itself.
The first step is usually an integration layer that decouples consumers from the core. Instead of every channel and system reading from the core directly, they consume services or events published by a layer that sits in front of it. eProxim’s work for a global post-trade financial-services firm took this route in a related setting: brittle point-to-point links across many systems of record were replaced with a secure enterprise API layer, with MuleSoft orchestration for aggregation, scheduling, error handling and monitoring. The resulting platform generates more than 25 million reports a month, both on demand and on schedule, for institutional customers that include investment managers, broker-dealers and custodian banks. The point for banks is that a well-designed service layer lets the systems behind it change without every consumer having to change at the same time.
From there, the patterns are well established. Change data capture, or event publishing from the core, lets new systems react to changes without putting query load on the ledger. Read models built from those events serve the channels and analytics, so heavy reads never touch the core. The strangler approach moves capabilities out of the legacy estate one at a time, each behind the same interface, so a migration can stop or reverse at any step. And parallel running – old and new paths processing the same transactions, with a reconciliation comparing their results – gives you evidence before anything is switched over.
Throughout all of this, the discipline that matters most is reversibility. Every change should have a rollback path that has actually been tested; a rollback plan that exists only on paper doesn’t count. Cutovers should be timed around the business calendar, steering clear of month-end, quarter-end and peak payment days. And every new integration should arrive with its monitoring, reconciliation and runbook already in place, because in a bank, the first week of production is the worst possible time to find out what an alert should say.
Related reading
- Integration reconciliation reports: proving two systems agree
- Idempotent webhooks: duplicates, retries and out-of-order events
- How to scope integration work in a statement of work
How we approach it at eProxim
eProxim’s engineering comes from regulated, high-volume production systems, payments among them, so idempotency, audit trails, observability and rollback plans are built into our work from the start – we don’t bolt them on later. We designed the real-time settlement hub that cleared a global bank’s interbank flow at 240,000 transactions per second, across more than 16,000 correspondent institutions, and proved that its nightly batch window could be retired, and we were the architects of the build-out that followed. For a post-trade financial-services firm, we replaced brittle point-to-point links with an enterprise API layer that now supports more than 25 million reports a month. We work across the integration layer, and we don’t sell a banking platform, which leaves us free to recommend whichever pattern fits each flow.
To see how we approach enterprise integration for banks, payments firms and the partners who serve them, or to talk through a modernization you’re planning, contact our team.