System design deep dive: SWIFT connectivity inside a bank

A bank connects to SWIFT through Alliance Access and Alliance Gateway, which together form the bank's SWIFT interface. Alliance Access is the application that creates, validates, and stores SWIFT messages, while Alliance Gateway is the secure communication layer that connects the bank to the SWIFT network over dedicated lines. The payment engine does not talk to SWIFT directly. Instead it hands a formatted message to an integration layer, which places it on an internal queue, and a connector picks it up, performs final checks, and delivers it to Alliance Access. This separation protects the payment engine from SWIFT outages and keeps message handling in one controlled place. Message flow is asynchronous and queue based. The payment engine writes the message to a persistent queue, often a middleware queue with guaranteed delivery, and the SWIFT connector consumes it in order. Each message carries a unique reference, a priority, and a delivery deadline. If Alliance Access is busy, messages wait in the queue rather than being lost, and the queue depth is monitored continuously. A typical large bank sends 100,000 to 300,000 SWIFT messages per day, with peaks above 500 messages per second during the morning settlement window, so the queue and connector are sized to drain bursts within minutes rather than hours. When SWIFT is unavailable, the store and forward design keeps the bank running. Messages accumulate safely in the outbound queue, and the connector retries the connection at short intervals, usually every 30 to 60 seconds, with alerts raised after five minutes of continuous failure. No message is deleted until Alliance Access confirms receipt with a positive acknowledgement, and the payment status remains sent pending acknowledgement until that confirmation arrives. If a message is rejected by SWIFT, the negative acknowledgement is routed back to the payment engine, which moves the payment to a repair queue with the exact error code. This design means a network outage delays payments but never loses them. Before a message reaches SWIFT, it passes through parsing and validation in several layers. The payment engine validates business rules such as currency, amount, and beneficiary details. Alliance Access then validates the message against SWIFT standards, checking field formats, mandatory fields, character sets, and the rules for the specific message type. An MT103, for example, must contain a valid value date, a correctly formatted amount, and a beneficiary account that matches the expected pattern. Invalid messages are rejected before transmission, logged with the field and error code, and returned for repair. This layered validation keeps the bank's error rate low and protects its reputation with correspondent banks. Every message is recorded in a message log table that acts as the single source of truth for SWIFT traffic. Each row stores the message reference, message type, sender, receiver, direction, timestamp, priority, and the full message text in its original format, together with the acknowledgement status. The log supports fast lookup by reference or by business date, and it is retained for at least seven to ten years to meet regulatory requirements. Operations teams use it to prove that a payment was sent, to investigate a missing payment, and to reconcile SWIFT traffic against the payment engine. Without this log, cross border investigation would be slow and uncertain. Worked example with real numbers: a bank in Singapore has 3,000 payments a day to send through SWIFT, and it runs a centralised connectivity model where its payment hub sends all messages through one SWIFT Alliance Gateway, which connects to SWIFTNet. The bank also has a service bureau as a fallback, which can send 500 messages a day if the gateway fails, so urgent payments can still go out. The centralised model saves the bank the cost of three separate gateways, one per business line, which would have cost EUR 180,000 a year, while the single gateway costs EUR 70,000, a saving of EUR 110,000 a year, and the operations team is one team, not three. Failure and recovery: the gateway fails when its certificate expires, because SWIFTNet requires a valid certificate, and a certificate that expires at midnight will stop all messages at midnight, so the bank must monitor certificate expiry 90 days ahead, with alerts at 90, 30 and 7 days, and a renewal process that is tested. The recovery is to renew the certificate, to restart the gateway, but the payments that were due at midnight will be a day late, and the bank must tell its customers. A bank that does not monitor certificate expiry will discover the failure when its customers complain, and the BA must require the monitoring, the alerts and the renewal test, because a certificate is a silent failure that gives no warning on the day it expires. For a business analyst, product owner or subject matter expert, the SWIFT connectivity requirement must name the centralised model, the gateway, the service bureau fallback, the certificate lifecycle, and the queue monitoring. The RMA authorisation must be held per correspondent BIC, and the requirement must state that a new correspondent cannot be paid until the RMA is in place, because a payment sent without RMA will be rejected by SWIFTNet, and the customer will be told the payment failed for a reason the bank should have prevented. A connectivity design without RMA and certificate management is a design that will fail on a predictable date.