How the players interact, a single payment story

Consider a simple example. A company in London owes a supplier in Singapore ten thousand US dollars for goods received. The company, as debtor, instructs its bank, the debtor agent, through online banking to send the payment. The debtor agent validates the instruction, checks the balance, screens the supplier against sanctions lists, debits the company account, and creates a pacs zero zero eight message. Because the debtor agent does not have a direct account with the supplier bank, it sends the message through SWIFT to an intermediary bank in New York, which holds US dollar accounts for both banks. The intermediary bank receives the instruction, checks it, deducts its charges if allowed, and forwards it to the creditor agent in Singapore. The creditor agent receives the payment, checks the supplier account, credits the amount, and notifies the supplier. Behind the scenes, the interbank settlement has moved through correspondent accounts and, where needed, through the central bank settlement system. The clearing house or SWIFT network has provided the messaging infrastructure, the scheme rules have defined the message format and the timelines, and the regulators have set the compliance standards that each bank has followed. The supplier can now reconcile the payment against the invoice using the remittance information in the message. This story shows why the ecosystem matters. A delay at any point, a wrong account number, a sanctions hold at the intermediary, a missed cut off at the creditor agent, can all delay the supplier payment and affect the business relationship. A business analyst who can tell this story, name each player, and explain what each player does is able to diagnose problems quickly, write requirements that reflect reality, and communicate with operations, compliance, and technology teams in a common language. That shared understanding is the real value of learning the ecosystem. Worked example with real numbers: a single EUR 50,000 payment from a manufacturer in Lyon to a supplier in Munich, traced end to end, shows every player in one story. The manufacturer, the debtor, instructs a pain.001 through the Bank A channel at 09:00. Bank A, the debtor agent, validates, screens and debits EUR 50,000 at 09:15, and sends a pacs.008 through STEP2 at 09:30. STEP2, the clearing house, clears at 14:00, and T2, the central bank settlement system, settles at 16:00 in central bank money. Bank B, the creditor agent, credits the supplier EUR 50,000 at 16:30, and sends a pacs.002 with status ACCC. One payment, seven players, and each one did a different job. Failure and recovery: if the manufacturer IBAN is wrong, the payment is rejected at initiation, and no other player is involved. If STEP2 rejects the pacs.008, Bank A must correct and resend before the cut-off. If T2 cannot settle, because Bank A cannot fund its net debit, the cycle is at risk, and treasury must fund it. If Bank B finds the supplier account closed, it returns the payment with a pacs.004, reason code AC04, and the manufacturer is refunded. Each failure sits with a different player, and the story is the investigation tool: the analyst asks which player failed, what message proves it, and what the recovery is, and the answer is found in the pacs.002, the pacs.004 or the pain.002. For a business analyst, product owner or subject matter expert, the test is to tell this story for any payment, naming every player, every message, every posting and every deadline, without notes, in under five minutes. If the analyst cannot tell the story, the requirement will have gaps, because the gaps are the players the analyst forgot. The ISO 20022 messages are the script: pain.001 for initiation, pacs.008 for the bank to bank instruction, pacs.002 for status, pacs.004 for returns, and camt.053 for the statement, and the requirement must map each player to its message and its posting. A payment story that names only the customer and the bank is a story with the middle missing, and the middle is where payments fail.