End-to-End Payment Platform Design

Designing a payment platform from scratch starts with the business requirements, not with the technology. The architect first asks what the platform must do, who will use it, which payment types it must support, and which markets it must serve. A platform for a retail bank in India needs UPI, NEFT, RTGS, IMPS, and card payments, while a platform for a European merchant needs SEPA, cards, and wallets. The architect also asks about volumes, because a platform that processes one hundred payments a day is designed very differently from one that processes ten million. These answers shape every later decision. The core components of a payment platform form a clear set of layers. At the top are the channels, such as internet banking, mobile banking, branch systems, and application programming interfaces for corporate clients. Below the channels sits the payment hub, which receives instructions from every channel and routes them to the right processing engine. The engines handle the business logic for each payment type, such as validation, sanctions screening, and limit checks. Below the engines sit the gateways and connectors that talk to the external clearing systems, card schemes, and correspondent banks. A shared set of services, such as customer data, account data, and audit logging, supports all the layers. Data flow through the platform follows a consistent pattern that a business analyst must understand. A payment instruction enters through a channel, where it is captured and validated for basic completeness. The hub enriches the instruction with customer and account data, checks limits and cut-off times, and decides which engine should process it. The engine applies the business rules, including sanctions screening, fraud checks, and fee calculation, and then sends the payment to the clearing system through a gateway. The gateway translates the internal message format into the external format, such as ISO 20022, and handles the response. Every step writes to an audit log, so the full journey of a payment can be reconstructed later. A complete architecture walkthrough helps to make these layers concrete. Imagine a customer in Mumbai who sends 50,000 rupees to a supplier in Singapore using the mobile banking app. The app sends the instruction to the payment hub through an application programming interface. The hub checks that the account has enough money and that the payment is within the customer's daily limit. The cross-border engine then checks the sanctions lists, applies the exchange rate from rupees to Singapore dollars, and calculates the fee. The gateway converts the instruction into a pacs.008 customer credit transfer under CBPR+, carrying a UETR, and sends it to the correspondent bank. The pacs.008 is the right message here, because this India to Singapore payment is a cross-border customer credit transfer under the CBPR+ ISO 20022 arrangement, and MT103 stopped being used for cross-border payments when coexistence ended on 22 November 2025. A pacs.009 cover is only needed if the funds travel separately from the instruction. The hub tracks the payment status and updates the mobile app when the supplier confirms receipt. The business analyst plays a central role in platform design, and it is not a purely technical job. The BA documents the business rules for each engine, such as the validation rules, the limit rules, and the fee rules. The BA defines the message formats and the data mappings between the internal systems and the external clearing systems. The BA also writes the non-functional requirements, including the response time targets, the availability targets, and the disaster recovery plan. An architect can draw the boxes, but it is the BA who fills each box with the rules that make the platform work, and that is why platform projects need strong payments BAs.