How Systems Connect

APIs, or application programming interfaces, are the modern way for systems to talk to each other in real time. When a customer checks a balance on a mobile app, the app calls an API on the core banking system and gets an answer in less than a second. When a corporate customer submits a payment through a banking portal, the portal calls the payment hub API. APIs are fast and interactive, which makes them ideal for customer-facing services and for real-time payments. Their trade-off is that both systems must be available at the same moment, and a badly designed API can expose sensitive data if it is not properly secured with authentication, encryption, and rate limits. MQ messaging is the workhorse for payment processing inside a bank. Instead of one system calling another directly, it places a message on a queue, and the receiving system picks it up when it is ready. This decoupling means the sender does not need to wait for the receiver, and a message is never lost if the receiver is briefly down. IBM MQ is the most common product in this space, and it is used for the critical path between the hub, the payment engines, and core banking. The trade-off is complexity. Queues need monitoring, dead letter queues need management, and tracing a payment across five queues requires good logging. For payments, that reliability is worth the effort. File transfers are the oldest connection type and are still essential for bulk payments. A large company that pays 50,000 employees sends a single file containing all 50,000 salary instructions, usually over SFTP, which is a secure file transfer protocol. The bank picks up the file, validates every line, and processes the payments in a batch. Files are also used for statements, regulatory reports, and reconciliation data. Their trade-off is speed. A file is processed as a batch, so an error on line 40,000 is only found after the whole file is read. Banks accept this because files are simple, cheap, and easy for corporate customers to produce from their payroll systems. SWIFT Alliance Access and Alliance Gateway are the specialist connections that link a bank to the SWIFT network. Alliance Access is the software that sits inside the bank and creates, validates, and stores SWIFT messages such as MT103 payment instructions and MT202 bank-to-bank transfers. Alliance Gateway is the component that connects Alliance Access to the SWIFT network itself, handling the secure transmission and the acknowledgements. Together they form the bank gateway to more than 11,000 financial institutions worldwide. The trade-off is cost and specialisation. SWIFT connectivity needs dedicated hardware, annual fees, and staff who understand SWIFT message standards, but no bank can do international payments without it. Host-to-host connections are direct links between a bank and a large corporate customer, built for high-volume straight-through processing. A multinational company with a treasury system sends payment instructions directly to the bank over a secure leased line or a virtual private network, often using the ISO 20022 format or a host-to-host file protocol. The bank returns status updates and statements over the same link. These connections suit companies that send thousands of payments a day and want full automation with no manual file upload. The trade-off is setup effort. Each host-to-host connection is custom-built, takes weeks to establish, and needs ongoing maintenance when either side changes its systems.