Exercise: Trace One Payment Through Every Possible Failure Scenario (one USD cross-border payment traced through reject, return, recall, duplicate, timeout and outage, with what happens at each step)

The payment begins as a customer instruction for USD 85,000, sent by the Mumbai company through its corporate banking channel, with the beneficiary account at a bank in New York and the value date set for 6 November 2026. The bank validates the instruction, checks the balance, screens it against sanctions lists, and creates a pacs.008 message carrying the reference PAY2026110600881 and the end-to-end reference INV-5520. The customer account is debited by USD 85,000, the internal nostro ledger is debited by the same amount, and the pacs.008 is sent to the correspondent bank in New York. At this point the payment is in transit, and the bank waits for a pacs.002 acknowledgement confirming that the correspondent has accepted it. In the first failure scenario, the payment is rejected, because the beneficiary account number contains a typing error and fails validation at the beneficiary bank. The beneficiary bank sends a pacs.002 message with reason code AC01, meaning incorrect account number, and the correspondent bank forwards that rejection to the Mumbai bank. The Mumbai bank matches the pacs.002 to the original pacs.008 by reference, re-credits the customer account with USD 85,000, and notifies the customer that the account number was wrong and must be corrected. The customer supplies the correct account number, and the bank creates a new payment with a new reference, rather than resending the rejected one. In the second failure scenario, the payment is returned, because the beneficiary account was closed the previous week and the beneficiary bank cannot credit it. The payment reaches New York, the beneficiary bank finds the account closed, and it sends a pacs.004 message with reason code AC04, returning USD 85,000 less a USD 20 intermediary fee, so USD 84,980 comes back. The Mumbai bank matches the pacs.004 to the original payment, credits the customer with USD 84,980, posts the USD 20 fee to a charges account, and tells the customer that the supplier's account is closed and new account details are needed. The payment cannot proceed until the supplier provides a live account. In the third failure scenario, the payment is recalled, because the Mumbai company discovers it paid the wrong supplier and asks for the money back after the payment has already been credited. The bank sends a camt.056 cancellation request to the beneficiary bank, asking for USD 85,000 to be returned. The beneficiary bank contacts its customer, who agrees to return the funds, and it replies with a camt.029 accepting the recall and sends the money back. The Mumbai bank credits the customer account with USD 85,000 and closes the case. If the beneficiary had refused, the camt.029 would have recorded a rejection, and the bank would have told the customer that recovery must be pursued commercially. In the fourth, fifth and sixth failure scenarios, the same payment is duplicated, times out, and then faces a clearing system outage, and each event tests a different discipline. The duplicate arises when the corporate channel resubmits the file after a timeout, so reconciliation shows two USD 85,000 debits against one instruction, and the bank recovers the second payment through a pacs.004 return. After a later timeout the bank checks with the correspondent bank, confirms the original payment was received, and does not resend, so no second duplicate is created. Then a clearing outage delays settlement by three hours, and the bank holds the payment, tells the customer about the delay, and reconciles it against the settlement report once the system recovers, confirming it settled for USD 85,000 on the revised value date.