The previous chapters built the vocabulary. This one uses it. Six flows cover most of what a bank asks its messaging layer to do; for each, the question is the same: what must never happen, and which part of the middleware prevents it?

SWIFT is the cooperative network banks use to send each other payment instructions across borders. A bank connects to it through a gateway product, commonly SWIFT’s own Alliance Access, and SWIFT documents an MQ Host Adaptor through which the bank’s back office exchanges messages with Alliance Access over IBM MQ queues. The path is: payments hub → IBM MQ → Alliance Access → the SWIFT network → the correspondent bank.

The message format changed recently, and the change matters to middleware. ISO 20022 is an international standard for financial messages, carried as XML, with far richer structured data than the older SWIFT MT formats — full names and addresses in separate fields, purpose codes, remittance detail. On 22 November 2025 SWIFT ended the period in which the old and new formats coexisted for cross-border payment instructions: the MT103 customer transfer and MT202 bank transfer gave way to their ISO 20022 equivalents, pacs.008 and pacs.009, with a temporary SWIFT service converting stragglers’ old-format messages.

• What breaks: duplicates after a failure and resend — SWIFT messages carry a possible-duplicate flag precisely because this happens; a payment held for sanctions screening that nobody releases; a cut-off missed because a queue backed up.
• What the middleware must provide: persistent, exactly-once delivery to the gateway; message sizes large enough for ISO 20022’s richer content; and monitoring of the age of the oldest unsent payment against the cut-off, not just queue depth.

In India, large payments go through RTGS — Real Time Gross Settlement, the Reserve Bank of India’s system that settles each payment individually and immediately in central bank money, available around the clock since December 2020. Smaller transfers go through NEFT, the National Electronic Funds Transfer, which settles in half-hourly batches. Banks connect through the SFMS gateway — the Structured Financial Messaging System built by the Institute for Development and Research in Banking Technology (IDRBT).

One fact surprises people who learnt ISO 20022 from the SWIFT migration: the RBI published ISO 20022 message formats for its next-generation RTGS in January 2013, with IDRBT building the mapping and a converter for banks, so India’s domestic high-value system moved to the standard more than a decade before SWIFT’s cross-border cut-over. The wider Indian payments landscape is in payments.

Mobile and internet banking talk to the core through request/reply over IBM MQ. It works until the core is slow — month-end, a batch overrunning, a lock on a busy account — and then it produces the most expensive bug in bank middleware.

Two further defences belong in the design. Give request messages an expiry no longer than the channel is prepared to wait, so a request the channel has abandoned is discarded rather than executed — appropriate for enquiries, dangerous for payments, where the enquire-before-retry rule is safer. And make the channel’s message to the customer honest: “we could not confirm your payment — please check before trying again” is a middleware decision surfacing in the user interface.

A large share of mobile-banking traffic is reads: balances, recent transactions. Serving every one from the core is slow and, on many mainframes, directly billed. The pattern that fixes it has two names worth knowing: change data capture (CDC), which reads a database’s own change log and publishes each change as an event, and CQRS, command query responsibility segregation — writes go to the system of record, reads are served from a separate copy built for reading.

The UK’s Nationwide Building Society described its version publicly as a Speed Layer: changes captured from its Unisys mainframe flow into Kafka, stream processing shapes them, and read-optimised stores serve the mobile app. Its first use case alone removed about 7 million requests a year from a mainframe charged per request, according to Computerworld’s reporting and Nationwide’s own conference talk. The catch, which the design must own: the copy is always slightly behind the core, so anything that decides money — whether a payment can go — must still ask the core.

When a transaction posts, several systems need to know: the customer’s notification service, fraud, the loyalty programme, analytics. Wiring each to the core separately multiplies load and coupling. Publishing one “transaction posted” event to a topic, and letting each system subscribe, is the answer. Rabobank describes its version on the Apache Kafka project’s own list of users: a Business Event Bus on Kafka that powers, among other things, its customer alerts service, Rabo Alerts.

A card authorisation travels over the card network and the bank’s switch, not over IBM MQ — the switch is described in payments. But the fraud decision increasingly depends on a stream of recent events: where the card was used an hour ago, how many attempts in the last minute. Those features are computed continuously from Kafka topics so the scoring model can answer within the authorisation’s tight time budget.

The middleware question is a policy question in disguise: if the scorer is slow or down, does the payment fail open or fail closed? Approving without a score risks fraud losses; declining risks turning away every customer at once. The answer is the business’s to make, and must be written down before the first incident rather than improvised during it.

Capital markets use messaging differently: market data is published to thousands of subscribers and microseconds matter. That world grew its own products — TIBCO Rendezvous historically, and Solace, founded in 2001 to build messaging hardware appliances for capital markets, whose product is now Solace PubSub+. The exchange side is in trading and exchanges.