System design deep dive: building a payment hub

A payment hub is built around five core components that work in sequence. Orchestration controls the flow, deciding which steps a payment needs and in what order, based on its type, currency, and destination. Routing picks the best rail or correspondent for the payment, using cost, speed, and cut off rules. Transformation converts the payment from the channel format into the hub's internal format and then into the format the destination expects. Validation checks the payment against business rules, sanctions lists, and format standards. Enrichment adds missing data, such as the beneficiary bank details, the charges, or the FX rate. Each component is a separate service, so it can be scaled, updated, and tested independently. The hub connects to more than twenty downstream systems, including the core banking system, SWIFT, domestic clearing systems, card schemes, fraud platforms, sanctions screening, FX engines, and the customer notification service. Each connection is built as an adapter that translates between the hub's canonical model and the downstream system's own format, so the hub itself never depends on the quirks of any single system. Adapters are isolated, so a failure in one downstream system does not block payments going to the others, and each adapter has its own queue, timeout, and retry policy. A typical hub processes one to three million payments per day, with peak rates of 3,000 to 5,000 per second, and the adapter layer is what lets it absorb that volume without coupling every system to every other. The canonical data model is the heart of the hub, because it gives every payment a single consistent shape no matter where it came from. It defines one field for the debtor, one for the creditor, one for the amount, and one for each reference, with clear rules for what is mandatory and what is optional. Channels map their own fields into this model on entry, and adapters map it out again on exit, so adding a new channel or a new rail means writing two mappings instead of rebuilding the hub. The model is versioned, so a change to a field does not break existing mappings, and every mapping is tested against thousands of sample payments before it goes live. Adding a new payment rail to a hub follows a standard pattern. First the team defines the rail's cut off times, value dates, message format, and limits, and records them in the routing and configuration tables. Then they build or reuse an adapter that converts the canonical model into the rail's format and handles its acknowledgements and error codes. Then they add the rail to the routing rules, initially for a small percentage of traffic, such as 5 percent, and monitor success rates, response times, and error codes for several days. Only when the new rail performs as well as the existing rails is it opened to full traffic. This gradual rollout limits the blast radius of a bad configuration and gives operations time to learn the new rail. Hub performance and resilience depend on active active data centres, where two sites both process live traffic at the same time. Payments are distributed across the sites by a load balancer, and each site holds a full copy of the configuration, the routing rules, and the in flight payment state, replicated in near real time with a lag of under one second. If one site fails, the load balancer moves its traffic to the other site within 30 seconds, and no payment is lost because every state change is written to both sites before it is acknowledged. The hub is load tested at 150 percent of peak volume, and a full site failure is rehearsed at least twice a year, so the team knows the failover works before it is needed for real.