Minute-by-minute timeline for one cross-border payment

A cross-border payment is the longest timeline in payments, and the example below is a real USD 85,000 payment from a customer of Bank A in London to a supplier at Bank B in Singapore, sent on Monday 9 November 2026, through correspondent banking, with the serial method, so the payment passes through Bank A, an intermediary Bank C in New York, and Bank B. The messages are a pain.001 from the customer, a pacs.008 from Bank A to Bank C, a pacs.008 from Bank C to Bank B, pacs.002 status reports at each step, and camt.053 statements at the end. Source: SWIFT, Cross-border Payments and Reporting Plus usage guidelines; ISO 20022, pacs.008 and pacs.002; Bank for International Settlements, Committee on Payments and Market Infrastructures. At 09:00 on Monday 9 November the customer of Bank A submits a pain.001 for USD 85,000 to the supplier in Singapore, with the supplier account, the remittance reference for invoice INV-2026-2041, and the charge arrangement OUR, so the supplier receives the full amount. At 09:30 Bank A debits the customer account USD 85,000 plus a fee of USD 25, so the total debit is USD 85,025, and credits its USD nostro account at Bank C in New York. At 10:00 Bank A sends a pacs.008. At 10:30 Bank C validates the pacs.008, screens it, debits the Bank A vostro account USD 85,000, and credits its own nostro account at Bank B in Singapore. At 11:00 on Monday Bank C sends a pacs.008. At 11:30 Bank B receives the pacs.008. At 12:30 Bank B sends a pacs.002 with status ACCC to Bank C, confirming the creditor account was credited, and Bank C forwards the pacs.002. At 13:30 Bank A receives the pacs.002, matches it to the original pacs.008 by the end to end identifier, and sends a confirmation to the customer, stating that the supplier was credited USD 85,000 on Monday 9 November, with the value date of Monday 9 November. The payment took 4 hours and 30 minutes from submission to confirmation, and the supplier received the full amount, because the charge arrangement was OUR. The parties and the systems are the customer, Bank A as debtor agent, Bank C as intermediary agent, Bank B as creditor agent, and the SWIFT network that carries the pacs.008 messages. The customer initiates and receives the confirmation. Bank A validates, screens, debits and sends. Bank C validates, screens, debits the vostro and credits the nostro, and forwards. Bank B validates, screens, credits and reports. The serial method means the payment passes through each bank in turn, and each bank deducts its charge only if the arrangement allows it, which, under OUR, it does not, so the supplier receives the full amount, and Bank A pays the intermediary charges separately. Failure at each hour has a different cause and a different recovery, and the recovery can take days. At 10:30, if Bank C rejects the pacs.008, because a field is missing, Bank C sends a pacs.002 with status RJCT, Bank A receives it, releases the customer debit, and tells the customer to correct the instruction. At 11:30, if Bank B finds the supplier account closed, Bank B returns the payment with a pacs.004, reason code AC04, and the funds travel back through Bank C to Bank A, which credits the customer, a process that can take two days. Each failure is reported by a pacs.002 or a pacs.004, and the customer must be told the status, not left to guess. The effect on the bank, the customer and operations is that a cross-border payment is a chain, and the chain is only as strong as its weakest link. For the bank, a cross-border payment uses nostro liquidity, carries correspondent credit risk, and requires screening at every bank in the chain, so the cost is higher and the failure rate is higher. For operations, the payment is a case that must be tracked across banks, time zones and value dates, and the investigation, when it is needed, uses the SWIFT gpi tracker, the pacs.002 reports and the nostro statements, with the end to end identifier as the key that links them all. For a business analyst, product owner or subject matter expert, the test is to draw this timeline for any cross-border payment and to name the bank, the message, the status, the posting, the charge and the deadline at each hour. Ask what happens when a bank in the chain rejects, returns or holds the payment, and how long the return takes. Ask how the nostro accounts are funded, what the cut-offs are in each time zone, and how the gpi tracker is used. The SWIFT CBPR+ usage guidelines and the ISO 20022 pacs.008 and pacs.002 message definitions are the sources for the messages, and the Bank for International Settlements is the source for the correspondent banking model. Two mistakes are common in cross-border payment design. The first is to promise same day credit when the chain includes a bank in a different time zone that has already passed its cut-off, and the customer will complain that the promise was broken. The second is to choose the wrong charge arrangement, so the supplier receives less than the invoice amount, and the supplier complains, and the customer must send a second payment for the shortfall, paying a second fee. The correct design is to state the method, the charge arrangement, the value date and the tracker at the point of initiation, to fund the nostro before the payment is sent, and to report every status change to the customer, so that a payment that takes a day is still a payment the customer can trust. Takeaway: a USD 85,000 cross-border payment from London to Singapore moves from pain.001 at 09:00 to supplier credit at 12:00 London time, through Bank A, intermediary Bank C and Bank B, by the serial method, with pacs.008 at each step, pacs.002 with status ACCC, and charge arrangement OUR so the supplier receives the full amount. Every hour has a bank, a message, a posting and a status, and a failure at any bank returns the funds through the chain. Further reading: SWIFT, Cross-border Payments and Reporting Plus usage guidelines; ISO 20022, pacs.008 and pacs.002; Bank for International Settlements, Committee on Payments and Market Infrastructures. Last reviewed 7 November 2026.