Design Patterns and What Good Looks Like

Several design patterns appear in almost every well built payment hub. The first is loose coupling, where each service does one job and communicates through well defined interfaces, usually APIs or events, so that one service can be changed or replaced without rebuilding the whole hub. The second is idempotency, which means that processing the same payment twice produces the same result as processing it once, so that retries after a failure never create a duplicate payment. This is critical, because networks fail and channels retry, and a duplicate payment is one of the worst things a bank can do to a customer. The third is the use of events, where a payment changing state publishes an event that other services can react to, such as the notification service sending a message to the customer when a payment is delivered. Resilience is designed in, not added later. A hub must keep working when a single service fails, so services are deployed across multiple servers, databases are replicated, and the engine can park payments safely and resume them when the failed service returns. Performance is also a design concern, because a hub that processes thousands of payments a second cannot afford a slow database query in the middle of the flow. Caching of reference data, asynchronous processing of non critical steps, and careful database design are all part of the answer. Security runs through everything, with encryption of data in transit and at rest, strict access controls, and audit logging of every action, because the hub handles the bank's most sensitive asset, its customers' money. For a BA, the practical takeaway is that hub requirements are never just about the happy path. The most important requirements are often about failure. What happens when the sanctions service is down, when a payment is duplicated, when a clearing system rejects a payment, when a value date is missed. A good BA writes these failure scenarios as clearly as the success scenarios, and tests them explicitly. They also understand that a hub is a long lived platform, so requirements should favour configuration over custom code, standard interfaces over bespoke ones, and clear ownership of each service. A hub built that way can evolve for a decade, while a hub built as a collection of hard coded exceptions becomes unmaintainable within a few years. A design pattern that good hubs follow is to apply common controls once, at the hub level, rather than in each engine. Sanctions screening, fraud screening, validation and enrichment are done once when the payment enters the hub, and the result is carried with the payment to whichever engine processes it. This avoids the cost and risk of each engine implementing its own screening, and it means a change to a screening rule takes effect for all payment types at once. A hub that screens in each engine separately will have inconsistent results: a payment that passes screening in the instant payments engine may fail in the high value engine, because the two engines use different lists or different versions of the same list. For a business analyst, the requirement is to define which controls are common and which are engine specific, and to test that a change to a common control takes effect everywhere. A design anti-pattern is to let each channel build its own payment logic. A bank that lets its mobile app, its corporate portal and its branch system each implement their own validation, their own routing and their own status reporting will have three different behaviours for the same payment, and three different sets of defects. The hub exists to prevent this: the channels send instructions to the hub, and the hub applies the same logic to all of them. A channel that bypasses the hub, for example by calling the clearing system directly, is a control failure, even if the payment itself succeeds, because it bypasses the screening, the validation and the audit trail. For a business analyst, the requirement is to define the channel contract: what a channel must send, what the hub returns, and what a channel must never do directly. Last reviewed 7 November 2026. Further reading: bank payment hub reference architectures; ISO 20022 message usage guidelines. Idempotency is easiest to understand through a failure. A corporate customer sends a payment of USD 100,000 through an API, and the network drops the response. The customer does not know whether the payment was created, so the system retries with the same idempotency key. The hub receives the retry, finds the key in its store, sees that the payment already exists, and returns the original result instead of creating a second payment. The customer is charged once, not twice. Without the key, the retry would create a duplicate, and the bank would have to reverse it, which takes days and damages trust. The BA must specify how long keys are stored, what happens when a key is reused with different details, and how the duplicate is detected if the key is missing. Resilience is tested by failure, not by design documents. Take a hub running in two data centres, each processing live traffic. One centre loses its database, and the load balancer moves all traffic to the surviving centre within 30 seconds. Payments in flight at the moment of failure are recovered from the replicated state, because every state change is written to both sites before it is acknowledged. The payments that were mid-processing are retried from their last known state, not from the beginning, so no payment is duplicated and none is lost. The BA should require a chaos test for this scenario, a planned failure of one centre during a peak period, because a failover that has never been tested is a hope, not a capability. The BA's job on design patterns is to turn principles into testable requirements. Loose coupling becomes a requirement that each service has a versioned API and that no service reads another service's database directly. Idempotency becomes a requirement that every money movement operation accepts an idempotency key and stores it for at least 24 hours. Event driven design becomes a requirement that every state change publishes an event with the payment reference, the old state, the new state and the timestamp. Each of these is verifiable in testing, and each one prevents a class of failure that is expensive to fix after go live.