Scenario Library
23 reusable scenarios. The same scenario powers lessons, diagrams, quizzes, simulators and capstones, so the story never changes between sections.
SC-01: MT103 serial payment missing field 57A
Serial customer credit transfer · United Kingdom to Singapore, SWIFT · USD 25000 · Meridian Bank London to Harbour Bank Singapore
Messages. MT103
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103. The same payment today travels as a pacs.008. Northgate Trading instructs Meridian Bank London to pay USD 25,000 to Bright Logistics at Harbour Bank Singapore for invoice INV-1187. Meridian Bank validates the instruction, debits the customer account, and sends a complete MT103 with field 57A naming Harbour Bank. Harbour Bank screens the payment, credits Bright Logistics on the value date, and confirms receipt. Both banks reconcile their nostro entries the same day and the payment closes without exception.
What went wrong. Northgate Trading instructs the same USD 25,000 payment, but the MT103 omits field 57A, so the receiving bank cannot tell which bank holds the beneficiary account. The payment is held for repair while operations contact Meridian Bank to confirm the account with institution. The value date slips by one day, Bright Logistics queries the delay, and Meridian Bank must send a corrected MT103 before Harbour Bank can credit the beneficiary account.
Root cause. The payment instruction was created without the beneficiary bank, because the template did not require field 57A when the receiver was assumed to be the beneficiary bank. Recovery. Operations contact the originating bank, obtain the correct field 57A value, repair the MT103, and resend it with the original reference and UETR.
Reconciliation. The nostro debit matches the Harbour Bank statement, the beneficiary credit matches the MT103 amount, and the payment closes with a one day delay recorded.
Source status: illustrative
SC-02: Choosing serial vs cover for a USD payment
Customer credit transfer, routing decision · United Kingdom to Australia, SWIFT · USD 48000 · Meridian Bank London to Pacific Rim Bank Sydney
Messages. MT103, MT202 COV
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103 with an MT202 COV for the cover leg. The same payment today travels as a pacs.008 with a pacs.009 COV for the cover leg. Coral Supplies instructs Meridian Bank London to pay USD 48,000 to Pacific Rim Bank Sydney for goods received. Meridian Bank compares serial and cover routing, chooses cover because it is faster and keeps customer data on the MT103 route, and sends the MT103 and the MT202 COV with matching references. Harbour Bank settles the cover funds, Pacific Rim Bank matches both legs, credits Coral Supplies on the value date, and both banks reconcile without a break.
What went wrong. Coral Supplies instructs the same USD 48,000 payment, but Meridian Bank chooses serial routing without checking the intermediary cut off time, so the payment arrives after the Harbour Bank cut off. The funds are held overnight, Pacific Rim Bank cannot credit Coral Supplies on the value date, and the supplier queries the delay. Meridian Bank must explain the routing choice, fund the payment next day, and record the delay as a routing exception.
Root cause. The routing decision did not check the intermediary cut off time, so a serial payment missed the settlement window and was held overnight. Recovery. Operations select the cover route for the next payment, update the routing table with cut off times, and resend the payment with a revised value date.
Reconciliation. The nostro debit matches the cover settlement, the beneficiary credit matches the MT103 amount, and the payment closes with a one day delay recorded.
Source status: illustrative
SC-03: Cover settlement through another clearing system
Cover payment with clearing system settlement · United Kingdom to Switzerland, SWIFT and clearing · EUR 125000 · Meridian Bank London to Alpine Bank Zurich
Messages. MT103, MT202 COV
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103 with an MT202 COV for the cover leg. The same payment today travels as a pacs.008 with a pacs.009 COV for the cover leg. Helvetia Holdings instructs Meridian Bank London to pay EUR 125,000 to a supplier at Alpine Bank Zurich. Meridian Bank sends the MT103 directly to Alpine Bank and the MT202 COV through a clearing system via Harbour Bank Singapore. The clearing system settles the cover funds on the value date, Alpine Bank matches the MT103 to the cover, credits the supplier, and confirms receipt. Meridian Bank reconciles the clearing and nostro entries the same day with no break.
What went wrong. Helvetia Holdings instructs the same EUR 125,000 payment, but the clearing system rejects the MT202 COV because the settlement account is wrong. The MT103 reaches Alpine Bank, but the cover funds do not arrive, so Alpine Bank holds the payment and cannot credit the supplier. Meridian Bank must correct the settlement account, resend the cover, and explain the delay to Helvetia Holdings while the supplier waits for funds.
Root cause. The MT202 COV named a settlement account that the clearing system did not recognise, so the cover was rejected before settlement. Recovery. Operations correct the settlement account from the standing settlement instruction, resend the MT202 COV, and confirm settlement with the clearing system.
Reconciliation. The clearing settlement matches the MT103 amount, the beneficiary credit matches the cover, and the payment closes with a one day delay recorded.
Source status: illustrative
SC-04: Same correspondent used by sender and beneficiary
Serial payment with shared correspondent · United Kingdom to Singapore, SWIFT · USD 75000 · Meridian Bank London to Harbour Bank Singapore
Messages. MT103
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103. The same payment today travels as a pacs.008. Bright Logistics instructs Meridian Bank London to pay USD 75,000 to a supplier at Harbour Bank Singapore. Meridian Bank finds it already holds a nostro account at Harbour Bank, which is also the beneficiary bank, so it sends a single MT103 with no intermediary. Harbour Bank screens the payment, debits the Meridian Bank nostro, credits the supplier on the value date, and confirms receipt. Meridian Bank reconciles the nostro debit the same day and the payment closes without exception.
What went wrong. Bright Logistics instructs the same USD 75,000 payment, but Meridian Bank routes it through a different correspondent by mistake, adding an unnecessary intermediary and an extra day. The payment reaches Harbour Bank late, the supplier queries the delay, and Meridian Bank pays an extra intermediary fee. Operations must correct the routing table, refund the extra fee, and reissue the payment through the direct nostro route.
Root cause. The routing table did not recognise that the beneficiary bank was also the correspondent, so an extra intermediary was added by mistake. Recovery. Operations correct the routing table to mark Harbour Bank as a direct correspondent, refund the extra fee, and resend through the direct route.
Reconciliation. The nostro debit matches the Harbour Bank statement, the beneficiary credit matches the MT103 amount, and the payment closes with the extra fee refunded.
Source status: illustrative
SC-05: Corporate MT101 initiation followed by bank generated MT103 and MT202 COV
Bulk corporate initiation with cover · United Kingdom to Singapore, SWIFT · USD 92000 · Meridian Bank London to Harbour Bank Singapore
Messages. MT101, MT103, MT202 COV
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103 with an MT202 COV for the cover leg. The same payment today travels as a pacs.008 with a pacs.009 COV for the cover leg. Northgate Trading sends an MT101 file to Meridian Bank London with ten payments totalling USD 92,000 to suppliers in Singapore. Meridian Bank validates the file, screens each payment, and creates one MT103 and one MT202 COV for each payment that needs cover. Harbour Bank settles the cover funds, each beneficiary bank matches its MT103 to the cover and credits the beneficiary, and Meridian Bank sends a status report confirming all ten payments settled on the value date.
What went wrong. Northgate Trading sends the same MT101 file, but one payment of USD 8,400 has a wrong beneficiary account number, so Meridian Bank rejects that item and processes the other nine. Northgate Trading must correct the account number and resend the failed item in a new MT101 file. The supplier queries the missing payment, and Meridian Bank must explain that the item was rejected at validation and was not sent to the beneficiary bank.
Root cause. The beneficiary account number in one MT101 item failed validation, so the bank rejected that item while processing the other nine. Recovery. Operations notify Northgate Trading of the rejection, obtain the corrected account number, and process the item in a new MT101 file.
Reconciliation. Nine payments reconcile in full, the tenth payment reconciles after it is resent with the corrected account, and the file closes with no break.
Source status: illustrative
SC-06: Beneficiary bank with multiple correspondents and SSI selection
SSI selection for a beneficiary bank · United Kingdom to Australia, SWIFT · AUD 64000 · Meridian Bank London to Pacific Rim Bank Sydney
Messages. MT103
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103. The same payment today travels as a pacs.008. Coral Supplies instructs Meridian Bank London to pay AUD 64,000 to a supplier at Pacific Rim Bank Sydney, which has two correspondents for Australian dollars. Meridian Bank checks the standing settlement instruction, which names Harbour Bank Singapore as the preferred correspondent for AUD, and sends the MT103 through Harbour Bank. Harbour Bank forwards the payment and settles the funds, Pacific Rim Bank credits the supplier on the value date, and Meridian Bank reconciles without a break.
What went wrong. Coral Supplies instructs the same AUD 64,000 payment, but the standing settlement instruction for Pacific Rim Bank has expired, so Meridian Bank uses an old correspondent that no longer holds an AUD account. The payment is rejected by the intermediary, the supplier is not paid on the value date, and Meridian Bank must obtain the updated SSI, correct the routing, and resend the payment through Harbour Bank Singapore.
Root cause. The SSI for Pacific Rim Bank had expired, so the bank used an old correspondent that no longer held an AUD account and the payment was rejected. Recovery. Operations obtain the updated SSI from Pacific Rim Bank, correct the routing, and resend the payment through Harbour Bank Singapore.
Reconciliation. The nostro debit matches the new correspondent statement, the beneficiary credit matches the MT103 amount, and the payment closes after resending.
Source status: illustrative
SC-07: Sender does not know beneficiary correspondent
Payment where the sender lacks correspondent details · United Kingdom to Switzerland, SWIFT · CHF 88000 · Meridian Bank London to Alpine Bank Zurich
Messages. MT103
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103. The same payment today travels as a pacs.008. Helvetia Holdings instructs Meridian Bank London to pay CHF 88,000 to a supplier at Alpine Bank Zurich, but it does not know the correspondent of Alpine Bank and leaves the routing blank. Meridian Bank looks up Alpine Bank in its correspondent directory, selects Harbour Bank Singapore as the intermediary for Swiss francs, and sends the MT103 through Harbour Bank. Alpine Bank receives the funds, credits the supplier on the value date, and Meridian Bank reconciles without a break.
What went wrong. Helvetia Holdings instructs the same CHF 88,000 payment, but Meridian Bank has no correspondent entry for Alpine Bank, so the payment cannot be routed and is held for repair. The supplier queries the delay, and Meridian Bank must contact Alpine Bank to obtain its correspondent details, add the entry to the directory, and then release the payment through the new correspondent.
Root cause. The correspondent directory had no entry for Alpine Bank, so the sending bank could not select an intermediary and the payment was held. Recovery. Operations contact Alpine Bank, obtain its correspondent details, add the entry to the directory, and release the payment.
Reconciliation. The nostro debit matches the new correspondent statement, the beneficiary credit matches the MT103 amount, and the payment closes after release.
Source status: illustrative
SC-08: MT103 containing fields 56A and 57A
Serial payment with intermediary and account with institution · United Kingdom to Australia, SWIFT · USD 31000 · Meridian Bank London to Pacific Rim Bank Sydney
Messages. MT103
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103. The same payment today travels as a pacs.008. Coral Supplies instructs Meridian Bank London to pay USD 31,000 to a supplier at Pacific Rim Bank Sydney. Meridian Bank creates an MT103 with field 56A naming Harbour Bank Singapore as the intermediary and field 57A naming Pacific Rim Bank as the account with institution. Harbour Bank forwards the MT103 to Pacific Rim Bank, which credits the supplier on the value date and confirms receipt. Meridian Bank reconciles the nostro debit the same day and the payment closes without exception.
What went wrong. Coral Supplies instructs the same USD 31,000 payment, but the MT103 swaps fields 56A and 57A, naming Pacific Rim Bank as the intermediary and Harbour Bank as the account with institution. Harbour Bank cannot forward the payment correctly, the MT103 is held for repair, and the supplier is not paid on the value date. Meridian Bank must correct the two fields, resend the MT103, and record the repair as an operational error.
Root cause. The MT103 named the beneficiary bank as the intermediary and the intermediary as the account with institution, so the payment could not be forwarded correctly. Recovery. Operations correct fields 56A and 57A to their proper values, resend the MT103, and confirm the beneficiary credit.
Reconciliation. The nostro debit matches the intermediary statement, the beneficiary credit matches the MT103 amount, and the payment closes after the corrected MT103 is sent.
Source status: illustrative
SC-09: Forwarding through another SWIFT participant
Payment forwarded by a non correspondent participant · United Kingdom to Singapore, SWIFT · USD 57000 · Meridian Bank London to Pacific Rim Bank Sydney
Messages. MT103
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103. The same payment today travels as a pacs.008. Northgate Trading instructs Meridian Bank London to pay USD 57,000 to a supplier at Pacific Rim Bank Sydney, with which Meridian Bank has no direct account. Meridian Bank sends the MT103 to Harbour Bank Singapore, a SWIFT participant that forwards the payment to Pacific Rim Bank and settles the funds from its nostro account. Pacific Rim Bank credits the supplier on the value date, Harbour Bank confirms to Meridian Bank, and Meridian Bank reconciles the nostro debit without a break.
What went wrong. Northgate Trading instructs the same USD 57,000 payment, but Harbour Bank has no valid RMA to receive MT103 messages from Meridian Bank, so the MT103 is blocked at the SWIFT network and never reaches Harbour Bank. The supplier is not paid, Northgate Trading queries the delay, and Meridian Bank must obtain the RMA authorisation, then resend the MT103 through Harbour Bank.
Root cause. Harbour Bank had no valid RMA to receive MT103 messages from Meridian Bank, so the message was blocked at the network and never delivered. Recovery. Operations request the RMA authorisation from Harbour Bank, confirm it is granted, and resend the MT103 through Harbour Bank.
Reconciliation. The nostro debit matches the forwarding bank statement, the beneficiary credit matches the MT103 amount, and the payment closes after resending.
Source status: illustrative
SC-10: Centralised SWIFT connectivity within a banking group
Group payment hub with central SWIFT connection · United Kingdom to Singapore, SWIFT group hub · USD 110000 · Meridian Bank London to Harbour Bank Singapore
Messages. MT103, MT202 COV
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103 with an MT202 COV for the cover leg. The same payment today travels as a pacs.008 with a pacs.009 COV for the cover leg. Northgate Trading instructs Meridian Bank London to pay USD 110,000 to a supplier at Harbour Bank Singapore. Meridian Bank London sends the instruction to the group payment hub, which validates and screens it, creates the MT103 and MT202 COV, and sends both through the central SWIFT connection. Harbour Bank matches the instruction to the cover, credits the supplier on the value date, and confirms receipt. The hub updates the status, Meridian Bank reconciles the group nostro, and the payment closes without exception.
What went wrong. Northgate Trading instructs the same USD 110,000 payment, but the central SWIFT gateway is down for maintenance, so the hub cannot send the MT103 and the payment is queued. The supplier queries the delay, and the hub must hold the payment in the queue, retry the gateway when it returns, and send the MT103 with the original value date adjusted to the next business day.
Root cause. The central SWIFT gateway was down for planned maintenance, so the group hub could not send the MT103 and the payment was queued. Recovery. Operations hold the payment in the hub queue, retry the gateway when it returns, and send the MT103 with a revised value date.
Reconciliation. The group nostro debit matches the Harbour Bank statement, the beneficiary credit matches the MT103 amount, and the payment closes after the gateway returns.
Source status: illustrative
SC-11: Missing RMA authorisation
Payment blocked by missing RMA · United Kingdom to Australia, SWIFT · AUD 29000 · Meridian Bank London to Pacific Rim Bank Sydney
Messages. MT103
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103. The same payment today travels as a pacs.008. Coral Supplies instructs Meridian Bank London to pay AUD 29,000 to a supplier at Pacific Rim Bank Sydney through Harbour Bank Singapore. Meridian Bank creates the MT103, checks RMA authorisation, and finds it holds no RMA to send MT103 to Harbour Bank, so the payment is blocked before sending. Operations request the RMA, Harbour Bank grants it, Meridian Bank releases the MT103, Pacific Rim Bank credits the supplier, and Meridian Bank reconciles the nostro debit without a break.
What went wrong. Coral Supplies instructs the same AUD 29,000 payment, but operations override the RMA block and try to send the MT103 without authorisation, so the SWIFT network rejects the message and returns an error. The payment is not delivered, the supplier is not paid, and Meridian Bank must withdraw the override, obtain the RMA properly, and resend the MT103 through Harbour Bank Singapore.
Root cause. An operator overrode the RMA block and sent the MT103 without authorisation, so the network rejected the message and it was never delivered. Recovery. Operations withdraw the override, request the RMA from Harbour Bank, confirm it is granted, and resend the MT103.
Reconciliation. The nostro debit matches the intermediary statement, the beneficiary credit matches the MT103 amount, and the payment closes after resending with the RMA in place.
Source status: illustrative
SC-12: Multiple intermediaries in SSI
Payment through two intermediaries from SSI · United Kingdom to Switzerland, SWIFT · EUR 76000 · Meridian Bank London to Alpine Bank Zurich
Messages. MT103
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103. The same payment today travels as a pacs.008. Helvetia Holdings instructs Meridian Bank London to pay EUR 76,000 to a supplier at Alpine Bank Zurich, whose standing settlement instruction names two intermediaries for euro settlement. Meridian Bank creates an MT103 with Harbour Bank Singapore as the first intermediary and sends it through the chain in the order stated in the SSI. Each intermediary forwards the payment and settles the funds, Alpine Bank credits the supplier on the value date, and Meridian Bank reconciles without a break.
What went wrong. Helvetia Holdings instructs the same EUR 76,000 payment, but the second intermediary in the SSI has closed its euro account, so it cannot forward the payment and returns it to Harbour Bank. The supplier is not paid on the value date, and Meridian Bank must obtain an updated SSI, remove the closed intermediary, and resend the payment through the remaining intermediary.
Root cause. The second intermediary named in the SSI had closed its euro account, so it could not forward the payment and returned it to the first intermediary. Recovery. Operations obtain an updated SSI from Alpine Bank, remove the closed intermediary, and resend the payment through the remaining intermediary.
Reconciliation. The nostro debit matches the remaining intermediary statement, the beneficiary credit matches the MT103 amount, and the payment closes after resending.
Source status: illustrative
SC-13: Field 72 differences between MT103 and MT202 COV
Cover message field 72 handling · United Kingdom to Singapore, SWIFT · USD 43000 · Meridian Bank London to Harbour Bank Singapore
Messages. MT103, MT202 COV
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103 with an MT202 COV for the cover leg. The same payment today travels as a pacs.008 with a pacs.009 COV for the cover leg. Northgate Trading instructs Meridian Bank London to pay USD 43,000 to Bright Logistics at Harbour Bank Singapore using a cover payment. Meridian Bank creates an MT103 with field 72 stating the cover indicator for the beneficiary bank, and an MT202 COV with field 72 carrying the cover link and the MT103 reference. Harbour Bank matches the two field 72 values, links the cover to the customer payment, credits Bright Logistics on the value date, and Meridian Bank reconciles without a break.
What went wrong. Northgate Trading instructs the same USD 43,000 payment, but the MT202 COV field 72 omits the MT103 reference, so Harbour Bank cannot link the cover to the customer payment and holds both messages for investigation. Bright Logistics is not paid on the value date, and Meridian Bank must send a corrected MT202 COV with the reference in field 72 before Harbour Bank can release the funds.
Root cause. The cover message field 72 omitted the MT103 reference, so the beneficiary bank could not link the cover to the customer payment and held both messages. Recovery. Operations send a corrected MT202 COV with the MT103 reference in field 72, and Harbour Bank matches the two messages and releases the funds.
Reconciliation. The nostro debit matches the cover settlement, the beneficiary credit matches the MT103 amount, and the payment closes after the corrected cover is sent.
Source status: illustrative
SC-14: Multiple cover messages and reference reconciliation
Multiple covers for one customer payment · United Kingdom to Australia, SWIFT · USD 150000 · Meridian Bank London to Pacific Rim Bank Sydney
Messages. MT103, MT202 COV
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103 with an MT202 COV for the cover leg. The same payment today travels as a pacs.008 with a pacs.009 COV for the cover leg. Coral Supplies instructs Meridian Bank London to pay USD 150,000 to a supplier at Pacific Rim Bank Sydney. Meridian Bank splits the cover into two MT202 COV messages of USD 75,000 each for liquidity reasons, with both carrying the same MT103 reference and UETR. Harbour Bank settles both covers, Pacific Rim Bank reconciles the two covers against the MT103, confirms the total equals USD 150,000, credits the supplier, and Meridian Bank reconciles both nostro debits without a break.
What went wrong. Coral Supplies instructs the same USD 150,000 payment, but only one of the two MT202 COV messages arrives, so Pacific Rim Bank holds the MT103 because the total cover is only USD 75,000. The supplier is not paid in full, and Meridian Bank must trace the missing cover, find it was delayed by the intermediary, and resend it before Pacific Rim Bank can credit the supplier in full.
Root cause. One of the two MT202 COV messages was delayed by the intermediary, so the beneficiary bank held the MT103 because the total cover did not match the amount. Recovery. Operations trace the missing cover with the UETR, confirm it was delayed, and resend it to the beneficiary bank.
Reconciliation. Both covers reconcile to the MT103 amount, the beneficiary credit matches the full amount, and the payment closes after the second cover arrives.
Source status: illustrative
SC-15: UETR tracking across the full chain
End to end tracking with UETR · United Kingdom to Singapore to Australia, SWIFT gpi · USD 68000 · Meridian Bank London to Pacific Rim Bank Sydney
Messages. pacs.008, pacs.002
Positive path. Northgate Trading instructs Meridian Bank London to pay USD 68,000 to a supplier at Pacific Rim Bank Sydney. Meridian Bank creates a pacs.008 with a new UETR and sends it through Harbour Bank Singapore to Pacific Rim Bank. Each bank sends a pacs.002 status update carrying the same UETR, so Northgate Trading can track the payment at every step. Pacific Rim Bank credits the supplier on the value date, sends a final status, and Meridian Bank reconciles with a full tracking history.
What went wrong. Northgate Trading instructs the same USD 68,000 payment, but Harbour Bank creates a new UETR when it forwards the pacs.008, so the tracking chain breaks and Meridian Bank cannot link the Pacific Rim Bank status to the original payment. Northgate Trading sees only the first status, queries the missing updates, and Meridian Bank must ask Harbour Bank to resend the status with the original UETR to restore the tracking chain.
Root cause. Harbour Bank created a new UETR when forwarding the pacs.008, so the tracking chain broke and later status updates could not be linked to the original payment. Recovery. Operations ask Harbour Bank to resend the status updates with the original UETR, and the tracking chain is restored for the customer.
Reconciliation. The nostro debit matches the statement, the beneficiary credit matches the pacs.008 amount, and the tracking history is complete after the correction.
Source status: independently verified
SC-16: Preferred correspondent route unavailable, alternative routing
Alternative routing after preferred route fails · United Kingdom to Singapore, SWIFT · USD 54000 · Meridian Bank London to Harbour Bank Singapore
Messages. MT103
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103. The same payment today travels as a pacs.008. Bright Logistics instructs Meridian Bank London to pay USD 54,000 to a supplier at Harbour Bank Singapore. Meridian Bank finds its preferred direct route is unavailable because the nostro account is under maintenance, so it selects Pacific Rim Bank Sydney as the alternative intermediary from the approved routing table. Pacific Rim Bank forwards the MT103 to Harbour Bank, which credits the supplier on the revised value date, and Meridian Bank reconciles the alternative nostro debit without a break.
What went wrong. Bright Logistics instructs the same USD 54,000 payment, but Meridian Bank uses an unapproved alternative route without checking the routing table, so the payment goes to a bank with no relationship to Harbour Bank and is returned. The supplier is not paid, Meridian Bank pays a return fee, and operations must select the approved alternative route, resend the payment, and record the error as a routing breach.
Root cause. The bank used an unapproved alternative route, so the payment went to a bank with no relationship to the beneficiary bank and was returned. Recovery. Operations select the approved alternative route from the routing table, resend the payment, and record the breach for audit.
Reconciliation. The nostro debit matches the approved intermediary statement, the beneficiary credit matches the MT103 amount, and the payment closes after resending.
Source status: illustrative
SC-17: TIPS instant payment timeout and expiry
Instant payment timeout in TIPS · Italy to Germany, SCT Inst and TIPS · EUR 18500 · Alpine Bank Zurich to Meridian Bank London
Messages. pacs.008, pacs.002
Positive path. Delta Exports instructs Alpine Bank Zurich to pay EUR 18,500 instantly to a supplier at Meridian Bank London through TIPS. Alpine Bank checks its dedicated cash account, creates a pacs.008, and sends it to TIPS, which reserves the funds and forwards the payment to Meridian Bank. Meridian Bank does not respond within the timeout, so TIPS expires the payment, releases the reserve, and sends a pacs.002 reporting the timeout. Alpine Bank notifies Delta Exports and records the timeout.
What went wrong. Delta Exports instructs the same EUR 18,500 instant payment, but Alpine Bank sends it without checking the TIPS balance, so TIPS rejects the payment for insufficient funds before it reaches Meridian Bank. The supplier is not paid, Delta Exports queries the failure, and Alpine Bank must fund its dedicated cash account from its main cash account and resend the payment as a new instant payment.
Root cause. Alpine Bank sent the pacs.008 without checking its TIPS dedicated cash account balance, so TIPS rejected the payment for insufficient funds. Recovery. Operations fund the dedicated cash account with a camt.050 liquidity transfer, confirm the balance, and resend the payment as a new instant payment.
Reconciliation. The liquidity transfer reconciles, the resent payment settles in TIPS, and the beneficiary credit matches the pacs.008 amount.
Source status: independently verified
SC-18: UPI payment failure and refund
UPI failure with refund to the payer · India, UPI · INR 12500 · Harbour Bank Singapore to Pacific Rim Bank Sydney
Messages. pacs.008
Positive path. Ananya Sharma uses her bank app to pay INR 12,500 to a merchant through UPI. Her bank debits her account and sends the payment to the UPI switch, which routes it to Pacific Rim Bank Sydney, but the switch times out while waiting for confirmation. The payment is marked as failed, Harbour Bank refunds the full INR 12,500 to Ananya Sharma within the scheme time limit, and she receives a notification of the failure and the refund with the transaction reference.
What went wrong. Ananya Sharma makes the same INR 12,500 UPI payment, but the merchant claims the payment succeeded and asks her to pay again, while her bank shows the payment as failed. Ananya Sharma risks paying twice, so Harbour Bank must check the UPI status, confirm the payment failed and the refund was made, and give her a reference she can show the merchant to prove the first payment did not succeed.
Root cause. The merchant claimed a failed UPI payment had succeeded, so the payer risked paying twice for the same purchase. Recovery. Operations check the UPI status, confirm the payment failed and the refund was made, and give the payer a reference to show the merchant.
Reconciliation. The debit and the refund match in full, the merchant receives no duplicate payment, and the case closes with no break.
Source status: independently verified
SC-19: Card chargeback after duplicate charging
Duplicate card charge and chargeback · United Kingdom, Visa · GBP 320 · Meridian Bank London to Pacific Rim Bank Sydney
Messages. pacs.008
Positive path. Sarah Chen buys goods for GBP 320 from an online merchant using her Meridian Bank London card, but the merchant submits the transaction twice by mistake, so she is charged GBP 320 twice. Sarah Chen contacts Meridian Bank, which confirms the duplicate, raises a chargeback for one charge through Visa, and Pacific Rim Bank debits the merchant and returns the funds. Meridian Bank credits GBP 320 to Sarah Chen, who sees one charge and one credit on her statement, and the case closes.
What went wrong. Sarah Chen reports the same duplicate GBP 320 charge, but the merchant defends the chargeback by claiming Sarah Chen made two separate purchases, so the chargeback is initially rejected. Sarah Chen must provide evidence that only one delivery was received, Meridian Bank must resubmit the chargeback with the delivery evidence, and Visa must rule in her favour before the GBP 320 is finally credited to her account.
Root cause. The merchant claimed the cardholder made two separate purchases, so the first chargeback was rejected even though only one delivery was received. Recovery. Operations resubmit the chargeback with delivery evidence showing one delivery, and Visa rules in favour of the cardholder.
Reconciliation. The duplicate charge is reversed in full, the cardholder is credited GBP 320, and the case closes with no break.
Source status: illustrative
SC-20: SEPA direct debit return and refund
SEPA direct debit return with refund · Germany, SEPA Direct Debit Core · EUR 180 · Alpine Bank Zurich to Meridian Bank London
Messages. pain.008, pacs.003, pacs.004
Positive path. Delta Utilities sends a pain.008 file to Alpine Bank Zurich to collect EUR 180 from a customer at Meridian Bank London under a SEPA direct debit mandate. Alpine Bank creates a pacs.003, Meridian Bank debits the customer on the collection date, and the customer disputes the amount as wrong. Meridian Bank returns the direct debit with a pacs.004 and refunds EUR 180 to the customer, Alpine Bank debits Delta Utilities, and the creditor is notified of the return.
What went wrong. Delta Utilities sends the same EUR 180 direct debit, but the mandate reference is wrong, so Meridian Bank rejects the pacs.003 before debiting the customer and returns it as a reject. Delta Utilities is not paid, the customer is not debited, and Delta Utilities must obtain the correct mandate reference from the customer, correct the pain.008 file, and resubmit the collection with the valid mandate.
Root cause. The pacs.003 carried a wrong mandate reference, so the debtor bank rejected the collection before debiting the customer account. Recovery. Operations obtain the correct mandate reference, correct the pain.008 file, and resubmit the collection with the valid mandate.
Reconciliation. No debit and no credit were made for the rejected collection, the corrected collection settles in full, and the case closes with no break.
Source status: independently verified
SC-21: Cover arriving before the customer payment message
Cover payment arriving before the customer instruction · United Kingdom to Australia, SWIFT · USD 62000 · Meridian Bank London to Pacific Rim Bank Sydney
Messages. MT202 COV, MT103
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103 with an MT202 COV for the cover leg. The same payment today travels as a pacs.008 with a pacs.009 COV for the cover leg. Northgate Trading instructs Meridian Bank London to pay USD 62,000 to a supplier at Pacific Rim Bank Sydney. Meridian Bank sends the MT202 COV first, so the cover funds reach Pacific Rim Bank before the MT103 arrives. Pacific Rim Bank holds the unmatched cover in a suspense account and waits for the customer instruction. The MT103 arrives one hour later with the same reference and UETR, the bank matches them, screens the payment, and credits the supplier on the value date. Meridian Bank reconciles the nostro debit with no break.
What went wrong. Northgate Trading instructs the same USD 62,000 payment, but the MT103 is delayed by a network outage and does not arrive for two business days. Pacific Rim Bank holds the cover funds in a suspense account and cannot credit the supplier, who queries the missing payment. Operations contact Meridian Bank to chase the MT103, and Meridian Bank resends it with the original reference and UETR. The bank matches the resent MT103 to the held cover and credits the supplier two days late.
Root cause. The MT202 COV reached the beneficiary bank before the MT103, so the cover could not be matched to a customer instruction and was held in suspense. Recovery. Operations hold the cover in a suspense account, chase the MT103 from the originating bank, match the two messages on arrival, and then credit the beneficiary.
Reconciliation. The nostro debit matches the cover settlement, the suspense entry is reversed when the beneficiary is credited, and the payment closes with a two day delay recorded.
Source status: illustrative
SC-22: Customer payment message arriving before the cover
Customer instruction arriving before the cover funds · United Kingdom to Australia, SWIFT · USD 54000 · Meridian Bank London to Pacific Rim Bank Sydney
Messages. MT103, MT202 COV
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103 with an MT202 COV for the cover leg. The same payment today travels as a pacs.008 with a pacs.009 COV for the cover leg. Coral Supplies instructs Meridian Bank London to pay USD 54,000 to a supplier at Pacific Rim Bank Sydney. The MT103 reaches Pacific Rim Bank first, so the bank holds it as pending cover and waits for the funds. The MT202 COV arrives later the same day through Harbour Bank Singapore with the same reference and UETR. Pacific Rim Bank matches the cover to the MT103, screens the payment, and credits the supplier on the value date. Meridian Bank reconciles the nostro debit with no break.
What went wrong. Coral Supplies instructs the same USD 54,000 payment, but the MT202 COV is rejected by Harbour Bank because the settlement account is wrong, so the cover never arrives. Pacific Rim Bank holds the MT103 as pending cover until the two business day timeout expires, then returns the instruction to Meridian Bank with the reason. Meridian Bank corrects the settlement account, resends the cover and the MT103 with a revised value date, and the supplier is paid three days late.
Root cause. The MT202 COV named a settlement account that the intermediary did not recognise, so the cover was rejected and the MT103 waited past the cover timeout. Recovery. Operations correct the settlement account from the standing settlement instruction, resend the MT202 COV and the MT103 with a revised value date, and confirm settlement with the clearing system.
Reconciliation. The nostro debit matches the cover settlement, the pending cover hold is released when the cover arrives, and the payment closes with a three day delay recorded.
Source status: illustrative
SC-23: Non-connected BIC forwarding through another SWIFT participant
Payment forwarded through a connected SWIFT participant · United Kingdom to Switzerland, SWIFT · EUR 47000 · Meridian Bank London to Alpine Bank Zurich
Messages. MT103
Positive path. This scenario is set before the CBPR+ migration, so the payment travels as an MT103. The same payment today travels as a pacs.008. Helvetia Holdings instructs Meridian Bank London to pay EUR 47,000 to a supplier at Alpine Bank Zurich, which holds no RMA with Meridian Bank. Meridian Bank sends the MT103 to Harbour Bank Singapore, a SWIFT participant that holds RMA with both Meridian Bank and Alpine Bank. Harbour Bank forwards the MT103 to Alpine Bank and settles the funds from its nostro account. Alpine Bank credits the supplier on the value date, and Meridian Bank reconciles the nostro debit with no break.
What went wrong. Helvetia Holdings instructs the same EUR 47,000 payment, but Meridian Bank sends the MT103 directly to Alpine Bank Zurich without checking RMA, so the SWIFT network blocks the message and it never arrives. The supplier is not paid on the value date, and Meridian Bank must obtain the forwarding route, resend the MT103 through Harbour Bank Singapore, and explain the delay to Helvetia Holdings while the supplier waits for the funds.
Root cause. Alpine Bank Zurich held no RMA with Meridian Bank London, so a direct MT103 could not be delivered and the payment had to be forwarded through a connected participant. Recovery. Operations select Harbour Bank Singapore as the forwarding bank, confirm its RMA with both banks, and resend the MT103 through Harbour Bank.
Reconciliation. The nostro debit matches the forwarding bank statement, the beneficiary credit matches the MT103 amount, and the payment closes after the forwarded payment is credited.
Source status: illustrative