The Integration Landscape Inside a Bank

A typical large bank runs several hundred applications, and a single payment can touch twenty of them before it completes. The mobile app takes the instruction, the channel layer validates it, the payment hub routes it, the core banking system debits the account, the sanctions engine screens it, the fraud system scores it, the ledger posts it, and the data warehouse records it for reporting. A EUR 600 payment from a customer in Milan therefore creates work for teams that rarely speak to each other, yet all of them must agree on the amount, the currency, the value date, and the status. Integration is the discipline that keeps those twenty systems consistent. The landscape falls into layers, and each layer has a different job. The engagement layer holds the channels, such as mobile, internet banking, branch, and corporate host-to-host connections. The processing layer holds the payment hub, the core banking system, and the card processor. The control layer holds sanctions screening, fraud detection, anti-money laundering monitoring, and limits management. The finance layer holds the general ledger, the nostro reconciliation system, and regulatory reporting. The data layer holds the warehouse, the customer master, and the reference data that every other layer depends on for codes and calendars. Legacy systems shape the landscape more than any new design, because they hold the accounts and the history. A core banking system installed twenty years ago may still process millions of accounts reliably, but it may only accept batch files overnight and expose no real-time interface. A card system may run on a mainframe with a fixed message format that cannot be changed without a six-month project. The business analyst must therefore map what exists before proposing what should exist, and must design integration that works with the legacy estate rather than pretending it will be replaced. A realistic map names the system, its owner, its interface, and its constraints. Data consistency is the hardest problem in the landscape, because the same fact lives in many places. A customer address might be stored in the channel system, the core banking system, the customer relationship system, and the sanctions system, and each copy can drift. A payment amount might be stored in the hub, the ledger, and the warehouse, and a rounding difference of one cent can break reconciliation. Banks solve this by naming a system of record for each data item, so that only one system owns the customer address and only one system owns the account balance. Every other system copies from the owner and never edits its own copy. The cost of integration is often underestimated, because the work is invisible until it fails. Industry experience suggests that integration consumes between forty and sixty percent of the effort in a payment programme, far more than building the new feature itself. Each new connection needs a contract, a test environment, error handling, monitoring, and a support model. A bank that connects to a new payment scheme must also connect to its testing simulator, its certification process, and its incident management process. The lesson is to budget for integration from the start, and to treat every interface as a product with an owner, a version, and a service level.