Simulate a payment going wrong. Pick a scenario and walk the timeline: what happens, in which system, and how it gets resolved.
Payment Rejected
Trigger. The pacs.008 fails CBPR+ validation at the London bank because the creditor address in Singapore is incomplete, so SWIFT rejects the message before it is sent.
Step 1 of 6 shown
T+0s Customer submits payment (Customer Channel) USD 25,000 to Singapore supplier, invoice INV-8841, beneficiary address missing the postal code.
T+2s Hub validates instruction (Payment Hub) Hub flags the missing postal code but allows the payment to continue to screening with a warning.
T+5s Screening passes (Screening) No sanctions or fraud match, payment is released for routing.
T+8s SWIFT validation fails (SWIFT) pacs.008 fails CBPR+ validation, the creditor address does not meet the structured address rule.
T+9s Payment rejected (Payment Hub) Hub marks the payment rejected, returns a pacs.002 with reason code BE04 for missing creditor address.
T+1h Customer notified (Customer Channel) Customer receives a message asking for the full beneficiary address so the payment can be corrected and resent.
Resolution. Operations contact the customer the same day and ask for the full beneficiary address with postal code. The customer supplies the complete address, the payment is corrected in the hub and resent as a new pacs.008 the next morning. The payment reaches the Singapore supplier one business day late, and the bank waives the repeat sending fee as a goodwill gesture for the delay.
Lesson. Structured address data is mandatory under CBPR+, and a missing postal code is enough to reject a payment before it leaves the bank. Validate the full beneficiary address at the channel before the payment reaches SWIFT, so the customer can fix it while the instruction is still in front of them.
Delayed Payment
Trigger. The USD nostro account in New York has insufficient funds at the SWIFT cut off, so the correspondent bank queues the payment until the London bank funds the account.
Step 1 of 6 shown
T+0s Payment sent to SWIFT (SWIFT) pacs.008 for USD 25,000 leaves London for the correspondent bank in New York.
T+30s Correspondent receives payment (Correspondent Bank) Correspondent checks the nostro balance and finds only USD 8,000 available.
T+1m Payment queued (Correspondent Bank) Payment is queued for funding and the London bank is alerted to the shortfall.
T+2h Treasury funds nostro (Payment Hub) London treasury transfers USD 30,000 to the New York nostro account.
T+2h 5m Payment released (Correspondent Bank) Correspondent releases the queued payment onward to Singapore.
T+3h Payment settles in Singapore (Beneficiary Bank) Supplier account is credited the same day, three hours later than planned.
Resolution. Treasury monitors the nostro balance during the day and tops it up as soon as the alert arrives, so the queued payment is released within two hours. The payment still settles on the same value date, and the customer is told of the delay through tracking. Treasury then raises the minimum nostro balance for the USD account to prevent a repeat of the shortfall.
Lesson. Cross-border payments depend on nostro liquidity, and a shortfall at the correspondent will queue a payment even when every other stage is ready. Monitor nostro balances intraday, set alerts before the balance runs low, and fund the account before the SWIFT cut off so payments are not delayed.
Returned Payment
Trigger. The beneficiary bank in Singapore cannot credit the payment because the supplier account was closed the previous week, so it returns the funds with a pacs.004.
Step 1 of 6 shown
T+0s Payment settles in Singapore (Settlement) USD 25,000 settles between the correspondent and the creditor agent.
T+5m Beneficiary bank checks account (Beneficiary Bank) Creditor agent finds the supplier account was closed on 28 October 2026.
T+10m Credit fails (Beneficiary Bank) Bank cannot post the credit and prepares a payment return.
T+15m pacs.004 sent (Beneficiary Bank) Bank sends a pacs.004 return with reason AC04 for closed account.
T+1h London bank receives return (Payment Hub) Hub matches the return to the original payment and credits the customer account.
T+2h Customer contacted (Customer Channel) Customer is told the payment was returned and is asked for the correct supplier account.
Resolution. The London bank credits USD 25,000 back to the customer account on the same day the return arrives without delay, less any charges the correspondent deducted. The customer contacts the supplier, obtains the new account number, and sends a fresh payment the next day. The bank records the return reason AC04 and closes the original payment as returned, not as completed.
Lesson. A return is not a failure of the payment system, it is the correct handling of an unpayable credit. Always confirm the beneficiary account is still open before sending a large payment, especially to a supplier you have not paid recently, and keep the return reason code so the customer knows exactly what to fix.
Duplicate Payment
Trigger. The customer channel retries a payment after a timeout and sends the same instruction twice, so the hub receives two identical USD 25,000 payments for the same invoice.
Step 1 of 6 shown
T+0s Customer submits payment (Customer Channel) Customer sends USD 25,000 for invoice INV-8841 and the channel shows a loading screen.
T+10s Channel times out (Customer Channel) The screen times out, the customer thinks the payment failed and submits it again.
T+12s Second instruction arrives (Payment Hub) Hub receives a second instruction with the same amount, beneficiary and invoice reference.
T+13s Duplicate check runs (Payment Hub) Hub compares amount, beneficiary, reference and time window and flags the second instruction as a likely duplicate.
T+14s Second payment held (Payment Hub) Second payment is held for review and the first payment continues normally.
T+30m Operations confirm duplicate (Payment Hub) Operations confirm the second payment is a duplicate and cancel it before it reaches SWIFT.
Resolution. Operations cancel the duplicate instruction before it reaches SWIFT, so only one USD 25,000 payment is sent to Singapore. The customer is told that the first payment succeeded and the second was stopped as a duplicate. The channel team adds a clear success message and a warning not to resubmit after a timeout, and the hub duplicate window is kept at 24 hours for the same amount and beneficiary.
Lesson. A timeout is not proof a payment failed, and resubmitting creates a duplicate that can debit the customer twice. Use idempotency keys so a retry returns the original result instead of creating a new payment, and show the customer a clear status after a timeout instead of leaving them to guess.
Payment Timeout
Trigger. The payment hub calls the screening engine and receives no reply within 30 seconds, so the payment stalls at screening with no status update for the customer.
Step 1 of 6 shown
T+0s Payment reaches screening (Screening) Hub sends the USD 25,000 payment to the screening engine for checks.
T+30s No reply received (Payment Hub) Screening engine does not reply within the 30 second timeout and the hub marks the call as timed out.
T+31s Payment held safely (Payment Hub) Hub holds the payment in screening state and does not release it without a screening result.
T+5m Retry succeeds (Screening) Hub retries the screening call and the engine returns a clear result.
T+6m Payment released (Payment Hub) Payment is released for routing and continues to SWIFT normally.
T+10m Customer tracking updated (Customer Channel) Tracking view updates from screening to sent, and the customer sees the payment is moving again.
Resolution. The hub retries the screening call once after the timeout and receives a clear result, so the payment continues without manual work. The failed call is logged with its timing, and the screening team checks why the engine was slow. The customer sees a short delay in tracking but the payment still reaches Singapore on the same value date, so no compensation is needed.
Lesson. Never release a payment without a screening result, even when the screening system is slow. Hold the payment safely, retry with a clear limit, log the timeout, and keep the customer informed. A timeout is a system delay, not a reason to skip a control that protects the bank and the customer.
Clearing System Outage
Trigger. The local clearing system in Singapore goes down for two hours during the business day, so payments that should clear before the cut off are held in a queue.
Step 1 of 6 shown
T+0s Payments arrive for clearing (Clearing) Ten payments, including the USD 25,000 supplier payment, arrive for the Singapore clearing cycle.
T+5m Clearing system fails (Clearing) The clearing system stops responding and the operator declares an outage.
T+10m Payments queued (Payment Hub) Hub holds the payments in a queue and alerts operations to the outage.
T+1h Operator gives update (Clearing) Clearing operator confirms the system will return within one hour and the cut off will be extended.
T+2h System restored (Clearing) Clearing system returns and the queued payments are processed in order.
T+2h 30m Payments settle (Settlement) All ten payments settle, including the USD 25,000 payment, on the same value date.
Resolution. The clearing operator extends the cut off time so the queued payments can still settle on the same value date once the system returns. Operations monitor the queue, keep customers informed through tracking, and confirm each payment settles in order. The bank reviews its contingency plan and confirms the alternative clearing route that would be used if the outage had lasted past the extended cut off.
Lesson. A clearing outage does not mean the payments are lost, it means they wait in a queue until the system returns. Know the operator contingency plan, the extended cut off rules and the alternative route before an outage happens, and tell customers early so they can plan around the delay instead of chasing the bank.