Hub components: what a hub is and what it contains

A large bank rarely processes payments through one system. It may run one platform for SWIFT cross border payments, another for domestic high value clearing, a third for instant payments, and a fourth for bulk salary files. Each system has its own validation rules, its own sanctions screening, its own ledger posting logic and its own operations team. A corporate client sending a 2.5 million euro supplier payment from Frankfurt to Singapore may therefore touch four teams and three reconciliations before the money moves. That duplication is expensive, slow and risky, and it is the problem a hub exists to solve. A payment hub is a single central platform that receives payment instructions from every channel, applies common controls once, and then routes each payment to the right clearing system or correspondent bank. It does not replace the clearing systems themselves. It sits above them and orchestrates them. When a treasurer at a manufacturing company submits a pain.001 bulk file for 4,000 salary payments worth 18 million pounds through online banking, the hub validates, screens, enriches and routes every item, even though the final settlement may use Faster Payments for some items and CHAPS for others. The hub is where most payment requirements live, because a new payment type, a new country, a new clearing scheme or a new fraud rule is usually a hub change. A payment hub is not a payment gateway, and confusing the two causes real design errors. A gateway is a front door. It accepts a card payment or an online checkout request, encrypts the data, and passes it to an acquirer or processor for authorisation. It handles the merchant facing edge and very little else. A hub is the bank side engine room. It owns validation, screening, fraud checks, liquidity, routing, settlement, ledger posting and reconciliation for every payment type the bank supports. A gateway can feed a hub, but a gateway never replaces one. A payment hub is also not the same as enterprise platform architecture, even though the two ideas overlap. Enterprise platform architecture describes how all of a bank technology estate fits together, including customer relationship systems, core banking, data platforms, security services and integration layers. The payment hub is one platform inside that estate, with a defined boundary and a defined set of neighbours. It consumes customer and account data from core banking, calls shared sanctions and fraud services, and publishes events to the enterprise data platform, but it does not own those neighbours. Knowing where the hub ends is as important as knowing what it contains. Channels are the places where a payment starts: retail mobile and internet banking, corporate online banking, branch systems, call centres, host to host file transfers and APIs. The gateway, sometimes called the channel adapter or the intake layer, is the component that receives payment instructions from all channels and converts them into a single internal format. It performs the first line of defence: it validates the message structure, rejects malformed instructions, and checks that the payment is not a duplicate of one already received. Without a gateway, every channel would need its own validation and its own connection to every downstream component. Routing is the decision that sends each payment to the right rail or correspondent. The hub reads the destination country, the currency, the amount, the beneficiary bank identifier and the urgency, then consults routing tables that map those inputs to a clearing system or a correspondent bank. Static routing uses fixed rules, such as sending every payment in Japanese yen through the correspondent bank in Tokyo. Dynamic routing adds live conditions, such as cost, cut-off times and the liquidity available in each nostro account. Banks choose between correspondent and clearing by balancing cost, speed, reach and risk, and the routing table is reference data that must be versioned, tested and approved like code. This chapter maps the hub as eighteen components in payment flow order, from the channel where an instruction arrives to the audit trail where it is finally recorded. Each component follows the same four questions, so you can compare components fairly. What comes in, what does the component do, what goes out, and what happens if it fails. Learn that pattern and you can walk into any bank, hear a new product name, and still place it on the map. The names vary between vendors, but the jobs do not change. The component catalogue is taught in ch48s2, ch48s3 and ch48s4, and the day to day running of the hub is taught in ch48s9 Hub operations. The business case for a hub is measured in straight through processing, control and time to market. A bank that consolidates five payment silos into one hub sets itself targets such as raising straight through processing from 82 percent to 97 percent, cutting duplicate sanctions screening costs by a third, and launching a new instant payment product in months instead of years. These are illustrative targets for a business case, not measured results; a real business case must state its baseline, its assumptions and its source. Consider a bank processing 1.2 million payments a day worth 40 billion dollars. Even a one percent improvement in automation removes 12,000 manual interventions a day. That scale is why boards approve hub programmes, and why business analysts must understand them. Last reviewed 7 November 2026.