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

PAY-001: Duplicate payment instruction

Payment processing

Business problem. A corporate customer submits the same payment instruction twice after a slow channel response. Both requests reach the payment platform.

Messages. pain.001, pacs.008, pacs.002

Happy path. Same idempotency key returns the original payment reference; a new key can create a distinct payment subject to duplicate controls.

Negative paths. Same key with altered payload; retry after timeout; duplicate detected after downstream submission; concurrent requests.

Recommended solution. This scenario is covered in depth in the Payment Exception Q&A bank (QA 22, QA 27, QA 34). The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Matching case in the Payment Exception Q&A bank. This scenario is covered in depth in the Payment Exception Q&A bank. The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Source status: Independently authored practice scenario

PAY-002: Timeout after submission with unknown outcome

Payment processing

Business problem. The channel times out after submitting a payment. It is unclear whether the payment engine accepted or executed it.

Messages. pain.001, pacs.002, camt.056

Happy path. A status enquiry resolves the original transaction without creating another payment.

Negative paths. Engine accepted but response lost; connector timed out; status store lag; duplicate retry.

Recommended solution. This scenario is covered in depth in the Payment Exception Q&A bank (QA 11, QA 14, QA 28, QA 36). The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Matching case in the Payment Exception Q&A bank. This scenario is covered in depth in the Payment Exception Q&A bank. The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Source status: Independently authored practice scenario

PAY-003: Insufficient funds at execution time

Payment processing

Business problem. A future-dated payment was accepted when submitted, but the account has insufficient available funds on execution date.

Messages. pain.001, pacs.002

Happy path. Sufficient funds at execution leads to normal processing; otherwise follow the agreed retry or reject policy.

Negative paths. Funds arrive during retry window; partial funding; account frozen; balance service unavailable

Recommended solution. Separate instruction acceptance from execution eligibility. Recheck available balance and applicable overdraft rules at execution. Apply configured retry, reject or expiry policy and notify the customer with a meaningful reason.

Source status: Independently authored practice scenario

PAY-004: Payment accepted but downstream clearing rejects it

Payment processing

Business problem. The payment platform accepts a customer instruction, but the clearing participant rejects the resulting interbank message.

Messages. pacs.008, pacs.002, camt.054

Happy path. A valid clearing acceptance progresses the payment; a rejection moves it to a defined rejected state with accounting treatment.

Negative paths. Late rejection; duplicate status; unknown reason code; response cannot be correlated.

Recommended solution. This scenario is covered in depth in the Payment Exception Q&A bank (QA 4). The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Matching case in the Payment Exception Q&A bank. This scenario is covered in depth in the Payment Exception Q&A bank. The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Source status: Independently authored practice scenario

PAY-005: Payment cancellation requested after processing has started

Payment processing

Business problem. A customer requests cancellation after the instruction has left the bank's payment engine.

Messages. camt.056, camt.029, pacs.004

Happy path. Cancellation accepted before irrevocable settlement stops or recalls the payment according to scheme rules.

Negative paths. Already settled; beneficiary credited; request rejected; response delayed; payment cannot be identified

Recommended solution. Check the payment's durable state and scheme rules before deciding whether cancellation is possible. If eligible, initiate the appropriate cancellation request and await the counterparty response. Never promise cancellation or reverse funds solely because a request was sent.

Source status: Independently authored practice scenario

PAY-006: Payment return after original settlement

Payment processing

Business problem. A beneficiary-side institution returns a payment after the original transfer has settled.

Messages. pacs.004, pacs.008

Happy path. Return is linked to the original transaction and credited according to the bank's return policy.

Negative paths. Partial return; return amount mismatch; missing original reference; duplicate return; return after account closure.

Recommended solution. This scenario is covered in depth in the Payment Exception Q&A bank (QA 5, QA 7, QA 8). The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Matching case in the Payment Exception Q&A bank. This scenario is covered in depth in the Payment Exception Q&A bank. The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Source status: Independently authored practice scenario

PAY-007: Payment routed to an unavailable correspondent

Payment processing

Business problem. A cross-border payment selects a correspondent that is temporarily unavailable or no longer supports the required currency/route.

Messages. pacs.008

Happy path. Eligible primary route is selected; approved fallback route is used when configured.

Negative paths. Stale directory; alternate route unavailable; route changes after compliance screening; liquidity insufficient

Recommended solution. Re-evaluate routing against current eligibility, currency, country, service, cut-off, cost and liquidity data. Use an approved alternate route only if policy permits; otherwise queue or reject with a transparent reason.

Source status: Independently authored practice scenario

PAY-008: Ambiguous payment status across systems

Payment processing

Business problem. The channel shows pending, the payment engine shows processed, and the ledger has no matching posting.

Messages. pacs.002, camt.054, camt.053

Happy path. All systems converge to a consistent state based on authoritative events.

Negative paths. Out-of-order events; duplicate event; missing ledger posting; stale cache

Recommended solution. Define a canonical payment state model and authoritative source for each state transition. Correlate records across systems, identify the missing event, and place the item in an exception queue if state cannot be safely inferred.

Source status: Independently authored practice scenario

PAY-009: Partial batch failure

Payment processing

Business problem. A file contains hundreds of transactions. Some pass validation while others fail due to invalid beneficiary or account data.

Messages. pain.001, pain.002, pacs.008

Happy path. Valid items progress when partial processing is permitted; rejected items receive item-level reasons.

Negative paths. File control sum mismatch; one invalid item under all-or-nothing policy; duplicate file; late repair

Recommended solution. Define file-level and transaction-level acceptance separately. Validate each transaction, apply the agreed all-or-nothing or partial-processing rule, return itemised outcomes and ensure accepted items are not resubmitted when rejected items are repaired.

Source status: Independently authored practice scenario

PAY-010: Future-dated payment falls on a non-processing day

Payment processing

Business problem. A customer selects an execution date that is a bank holiday for one participant in the payment chain.

Messages. pain.001, pacs.002

Happy path. Valid date follows documented calendar and adjustment rules.

Negative paths. Calendar changes after submission; different participant calendars; cut-off missed on adjusted date

Recommended solution. Apply the correct scheme, currency, debtor bank, creditor bank and clearing calendars. Determine whether to move execution to the previous or next eligible business day, reject, or retain the requested date according to product rules.

Source status: Independently authored practice scenario

PAY-011: Payment cut-off extension request

Payment processing

Business problem. A corporate client asks the bank to extend its same-day payment cut-off by one hour.

Messages. Rail-specific payment messages

Happy path. Extended window is enabled only for eligible rails, currencies, customers and operating dates.

Negative paths. Clearing closes earlier; liquidity unavailable; sanctions team coverage ends; batch/reconciliation windows collide.

Recommended solution. This scenario is covered in depth in the Payment Exception Q&A bank (QA 3). The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Matching case in the Payment Exception Q&A bank. This scenario is covered in depth in the Payment Exception Q&A bank. The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Source status: Independently authored practice scenario

PAY-012: Peak volume growth threatens throughput

Payment processing

Business problem. New customers are forecast to increase daily volume and peak TPS materially.

Messages. Not message-specific, include rail-specific payloads

Happy path. The platform meets throughput and latency targets under agreed peak and stress profiles.

Negative paths. Dependency saturation; queue growth; retry storm; database contention; failover capacity insufficient

Recommended solution. Build a capacity model using average, peak and burst volumes, payload sizes, dependency latency and retry amplification. Load-test the complete chain and define scaling thresholds and degradation behaviour.

Source status: Independently authored practice scenario

PAY-013: High repair rate in a remittance file

Payment processing

Business problem. Most transactions in a remittance file require manual repair because key data is missing or inconsistent.

Messages. pain.001, pain.002, pacs.008

Happy path. Clean items process automatically; repairable items enter controlled work queues; irreparable items are rejected.

Negative paths. Repeated defect; repair changes payment meaning; queue exceeds SLA; duplicate after resubmission

Recommended solution. Segment defects by root cause and source. Improve upstream validation and enrichment, provide actionable repair guidance, prioritise by SLA and prevent repaired items from losing original traceability.

Source status: Independently authored practice scenario

PAY-014: Optional field required by downstream reporting

Payment processing

Business problem. A message field is optional under the message schema, but a regulatory or management report needs the information.

Messages. Relevant pain/pacs message and reporting schema

Happy path. Field is populated from a trusted source or handled through an explicit exception policy.

Negative paths. No source value; conflicting sources; invalid derivation; downstream rejects missing data

Recommended solution. Distinguish scheme-level optionality from product, regulatory and internal data requirements. Define source, derivation, validation, defaulting and exception policy; do not invent values to satisfy reporting.

Source status: Independently authored practice scenario

PAY-015: Country-specific reject reason and privacy

Payment processing

Business problem. A reject reason must be configured differently by country because the bank must not expose sensitive account information.

Messages. pacs.002, pain.002

Happy path. Customer receives an accurate, permitted explanation while Operations retains sufficient diagnostic detail.

Negative paths. Unknown code; language mismatch; internal reason accidentally exposed; code mapping changes

Recommended solution. Maintain internal diagnostic detail separately from customer-visible reason text. Apply jurisdiction-specific disclosure rules, localised descriptions and consistent mapping to external scheme codes.

Source status: Independently authored practice scenario

PAY-016: Batch booking versus individual booking

Payment processing

Business problem. A corporate customer wants one account debit for a batch, while Operations needs transaction-level traceability.

Messages. pain.001, camt.053, camt.054

Happy path. Customer statement and bank ledger follow agreed booking policy while retaining item-level detail.

Negative paths. Partial batch failure; return of one item; fee posting; aggregate amount mismatch

Recommended solution. Clarify product, accounting, statement and reconciliation needs. Define whether the ledger posts one aggregate entry, individual entries or both through linked accounting events. Ensure totals and transaction references reconcile.

Source status: Independently authored practice scenario

PAY-017: Correspondent chain has missing or outdated data

Cross-border

Business problem. A cross-border instruction lacks a valid intermediary or correspondent relationship for the selected currency.

Messages. pacs.008, pacs.009

Happy path. Complete eligible chain is selected and message agents are populated consistently.

Negative paths. Conflicting BICs; expired relationship; unsupported currency; route changes mid-processing

Recommended solution. Validate the full correspondent chain against approved, effective-dated reference data. Determine whether data can be derived safely from an authorised source; otherwise repair or reject before release.

Source status: Independently authored practice scenario

PAY-018: Cover payment return while customer payment status is unclear

Cross-border

Business problem. A cover leg is returned, but the related underlying customer credit transfer may have a different processing state.

Messages. pacs.008, pacs.009, pacs.004, pacs.002

Happy path. Both legs are tracked independently and reconciled to the intended settlement outcome.

Negative paths. Cover returned but customer leg credited; customer leg rejected; missing linkage; partial amount.

Recommended solution. This scenario is covered in depth in the Payment Exception Q&A bank (QA 7). The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Matching case in the Payment Exception Q&A bank. This scenario is covered in depth in the Payment Exception Q&A bank. The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Source status: Independently authored practice scenario

PAY-019: Intermediary bank selected incorrectly

Cross-border

Business problem. A payment is routed through an intermediary that cannot serve the destination or currency.

Messages. pacs.008, pacs.009

Happy path. A valid intermediary is selected or the payment is held for repair.

Negative paths. Incorrect priority rule; stale reference data; unsupported service; invalid agent sequence

Recommended solution. Trace the route decision and compare the selected intermediary with the bank's routing policy, currency capability, country restrictions, settlement relationship and effective-dated reference data.

Source status: Independently authored practice scenario

PAY-020: Cross-border payment tracking across multiple banks

Cross-border

Business problem. A customer cannot determine where a payment is while it travels through multiple institutions.

Messages. pacs.002

Happy path. Customer sees a coherent timeline with source and timestamp for each status.

Negative paths. Missing UETR; duplicate status; institution does not report; conflicting statuses

Recommended solution. Use a persistent end-to-end tracking reference such as UETR where applicable, propagate it through participating messages and maintain status events with timestamps and source institutions.

Source status: Independently authored practice scenario

PAY-021: FX quote expires before execution

Cross-border

Business problem. A customer accepts an FX quote but payment processing is delayed beyond the quote validity window.

Messages. Payment messages plus internal FX quote contract

Happy path. Payment executes using a valid accepted quote or is paused for a new quote/consent.

Negative paths. Quote service unavailable; rate changes; liquidity shortfall; duplicate quote consumption

Recommended solution. Bind quote ID, currency pair, amount, rate, expiry and execution conditions to the payment. Revalidate at execution and obtain fresh customer consent if the rate or amount changes beyond agreed tolerance.

Source status: Independently authored practice scenario

PAY-022: Instant cross-border payment has asynchronous legs

Cross-border

Business problem. The domestic leg is accepted, but the destination system has not yet confirmed beneficiary credit.

Messages. Rail-specific instant messages, status/confirmation messages

Happy path. End-to-end completion is reported only when required leg confirmations are received.

Negative paths. Destination timeout; sender debited but no beneficiary credit; delayed confirmation; duplicate callback

Recommended solution. Model each rail leg separately with an overall orchestration state. Apply scheme-specific timeout and confirmation rules, avoid duplicate sending, and trigger investigation/compensation only under defined rules.

Source status: Independently authored practice scenario

PAY-023: Cross-border instant payment fails after sender debit

Cross-border

Business problem. The sender's account is debited, but the receiving system reports a technical failure or no final response.

Messages. Scheme-specific payment and status messages

Happy path. Customer is credited at destination or funds are returned/adjusted under the defined scheme process.

Negative paths. Late success after timeout; return and success race; duplicate compensation; ledger posting failure.

Recommended solution. This scenario is covered in depth in the Payment Exception Q&A bank (QA 10, QA 36). The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Matching case in the Payment Exception Q&A bank. This scenario is covered in depth in the Payment Exception Q&A bank. The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Source status: Independently authored practice scenario

PAY-024: Compliance screening threatens instant payment SLA

Cross-border

Business problem. Sanctions, AML or fraud checks may take longer than the rail's processing window.

Messages. Payment message plus internal screening decision

Happy path. Payment proceeds only after required controls pass; holds/rejections are explicit and auditable.

Negative paths. Screening service unavailable; potential match; false positive; timeout; changed beneficiary data.

Recommended solution. This scenario is covered in depth in the Payment Exception Q&A bank (QA 12, QA 23). The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Matching case in the Payment Exception Q&A bank. This scenario is covered in depth in the Payment Exception Q&A bank. The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Source status: Independently authored practice scenario

PAY-025: Remittance information is lost during transformation

Cross-border

Business problem. Structured remittance details are truncated or flattened when translating between payment formats or intermediaries.

Messages. pain.001, pacs.008

Happy path. Required remittance data is preserved or a controlled exception is raised.

Negative paths. Length overflow; unsupported characters; multiple invoice references; intermediary strips data

Recommended solution. Map structured and unstructured remittance fields with explicit length, character-set and preservation rules. Validate truncation and ensure critical references survive the full chain.

Source status: Independently authored practice scenario

PAY-026: Mandate missing or invalid

SEPA Direct Debit

Business problem. A creditor submits a collection without a valid mandate or with mismatched mandate details.

Messages. pain.008, pacs.003, pacs.002, pacs.004

Happy path. Valid mandate supports collection; invalid or revoked mandate is not collected.

Negative paths. Mandate revoked after file creation; account changed; duplicate mandate reference; evidence unavailable

Recommended solution. Validate mandate existence, status, creditor identifier, debtor account, signature/consent evidence and scheme-specific requirements before collection submission. Route invalid mandates to repair or reject.

Source status: Independently authored practice scenario

PAY-027: Creditor pre-notification sent late

SEPA Direct Debit

Business problem. A creditor intends to collect on a planned date but the debtor was not notified within the agreed or scheme-required timeframe.

Messages. pain.008

Happy path. Collection proceeds only when notice requirements are met or a valid agreed exception applies.

Negative paths. Notification delivery failure; changed amount/date; customer disputes notice

Recommended solution. Validate pre-notification timing against the mandate, scheme rules and any agreed alternative period. Reschedule or obtain valid agreement where permitted; do not assume file submission itself is notification.

Source status: Independently authored practice scenario

PAY-028: Creditor wants to stop a collection before submission

SEPA Direct Debit

Business problem. A creditor identifies an incorrect collection before it has been submitted to its PSP.

Messages. pain.008

Happy path. Collection is removed from the outgoing submission set.

Negative paths. File already generated; batch partially submitted; duplicate collection recreated

Recommended solution. Use the creditor-side revocation process while the collection remains within the creditor's control. Cancel the instruction, preserve audit evidence and prevent file generation or resubmission.

Source status: Independently authored practice scenario

PAY-029: Cancellation requested after submission but before settlement

SEPA Direct Debit

Business problem. The creditor discovers an error after the collection has been submitted into the payment chain.

Messages. camt.056, camt.029

Happy path. Accepted cancellation prevents the collection from proceeding under applicable rules.

Negative paths. Cancellation arrives too late; counterparty rejects; original settles while request is in flight

Recommended solution. Check scheme rules and current state. Submit a request for cancellation through the appropriate channel if still eligible, track acceptance/rejection, and do not assume the request itself stops settlement.

Source status: Independently authored practice scenario

PAY-030: Collection reversal after settlement

SEPA Direct Debit

Business problem. A creditor identifies an error after a Direct Debit has already settled.

Messages. pacs.004

Happy path. Reversal is processed as a separate linked financial event.

Negative paths. Partial reversal; reversal deadline missed; original already refunded; duplicate reversal

Recommended solution. Use the applicable reversal mechanism within scheme rules and deadlines. Create a linked reversal transaction, validate amount/reason and ensure the original settlement record remains intact.

Source status: Independently authored practice scenario

PAY-031: Debtor requests refund for an authorised collection

SEPA Direct Debit

Business problem. A debtor asks their bank to refund an authorised SDD Core collection within the applicable scheme period.

Messages. camt.056, camt.029, pacs.004

Happy path. Eligible request is handled within scheme rules and customer receives a clear outcome.

Negative paths. Request outside timeframe; disputed authorisation; amount mismatch; account closed

Recommended solution. Validate scheme, collection date, authorisation status and request timeframe. Apply the relevant refund right and bank process, then reconcile the refund separately from the original collection.

Source status: Independently authored practice scenario

PAY-032: Debtor claims an unauthorised collection

SEPA Direct Debit

Business problem. A debtor disputes a collection as lacking valid authorisation.

Messages. Scheme-specific refund/claim messages

Happy path. Claim is resolved according to scheme and legal rules; eligible refund is processed.

Negative paths. Mandate evidence incomplete; claim submitted after deadline; identity/account mismatch

Recommended solution. Capture the claim, investigate mandate evidence and apply the applicable scheme/legal timeframe and burden-of-proof process. Protect the customer while retaining a complete audit trail.

Source status: Independently authored practice scenario

PAY-033: Different participant calendars produce conflicting dates

SEPA Direct Debit

Business problem. A collection's due date is a business day for one participant but a non-processing day for another.

Messages. pain.008

Happy path. Submission, inter-PSP settlement and debtor debit dates satisfy the applicable rules.

Negative paths. Unexpected national holiday; calendar update after scheduling; timezone boundary

Recommended solution. Calculate each milestone against the relevant participant and scheme calendar. Apply scheme-specific business-day definitions and date adjustment rules, and retain the calendar version used.

Source status: Independently authored practice scenario

PAY-034: Collection rejected, returned or refused

SEPA Direct Debit

Business problem. A collection does not complete and stakeholders use the terms reject, return and refusal interchangeably.

Messages. pacs.002, pacs.004

Happy path. Each exception type is represented accurately and handled according to scheme rules.

Negative paths. Wrong reason mapping; duplicate event; late event; inconsistent customer language

Recommended solution. Classify the event by initiator, lifecycle stage and scheme definition. Map each event to its correct status, reason code, accounting action and customer/creditor notification.

Source status: Independently authored practice scenario

PAY-035: MT-to-MX transformation needs a value not present in source

Architecture and data

Business problem. A legacy MT message lacks an explicit value required by the target ISO 20022 message.

Messages. MT103, MT202 COV, pacs.009

Happy path. Target message is produced only when mandatory values are sourced or validly derived.

Negative paths. Conflicting reference data; no derivation; legacy field ambiguity; unsupported use case

Recommended solution. Do not fabricate a value. Identify whether the target value can be derived from trusted contextual data, such as settlement arrangement or correspondent relationship. Document derivation rules, confidence and exception handling.

Source status: Independently authored practice scenario

PAY-036: HTTP 200 returned but payment not completed

Architecture and data

Business problem. A client interprets an HTTP 200 response as proof that the payment has settled.

Messages. OpenAPI contract, payment messages downstream

Happy path. Client can distinguish request receipt, acceptance, processing, rejection and completion.

Negative paths. Async callback lost; status polling too frequent; client treats pending as success

Recommended solution. Define API response semantics precisely. A synchronous 200 may mean request accepted or resource created, not final payment completion. Return a payment resource/reference and status; use asynchronous status events or enquiry for later lifecycle updates.

Source status: Independently authored practice scenario

PAY-037: Sequential versus parallel payment controls

Architecture and data

Business problem. A payment passes through several checks, and the team wants to reduce latency without weakening controls.

Messages. Internal orchestration/API events

Happy path. All mandatory controls complete with a recorded decision before release.

Negative paths. One service timeout; conflicting outcomes; late negative result after release; stale input data

Recommended solution. Map dependencies and data requirements. Run independent checks in parallel where safe; retain mandatory sequencing where one result or enrichment is needed by another. Define aggregation and fail policy.

Source status: Independently authored practice scenario

PAY-038: Canonical model loses source semantics

Architecture and data

Business problem. Different channels send similar but non-identical payment fields and the canonical model collapses meaningful distinctions.

Messages. pain.001, pacs.008, pacs.009

Happy path. Canonical model supports required products without losing information needed for downstream mapping.

Negative paths. Identifier collision; unsupported extension; optional source data dropped; round-trip mismatch

Recommended solution. Define a canonical model that preserves business semantics, source provenance and scheme-specific extensions. Avoid mapping distinct identifiers into one generic field without documented rules.

Source status: Independently authored practice scenario

PAY-039: Payment event arrives twice or out of order

Architecture and data

Business problem. A message broker redelivers an event or delivers status updates out of order.

Messages. pacs.002

Happy path. Each financial or state-changing event has one effective application.

Negative paths. Duplicate delivery; out-of-order update; consumer restart; poison message

Recommended solution. Make consumers idempotent and state transitions version-aware. Store event IDs, aggregate sequence/version and processed outcome. Ignore duplicates and prevent older events from overwriting newer state.

Source status: Independently authored practice scenario

PAY-040: Reconciliation finds unmatched debit and clearing record

Architecture and data

Business problem. The bank's ledger contains a debit but no corresponding clearing confirmation, or vice versa.

Messages. camt.053, camt.054, camt.056, pacs.004

Happy path. Matched items close automatically; unmatched items enter controlled investigation.

Negative paths. Late statement; missing reference; FX difference; duplicate posting; partial settlement

Recommended solution. Reconcile using stable identifiers, amount, currency, date and participant references. Classify timing differences versus true breaks, age exceptions and prevent duplicate financial correction.

Source status: Independently authored practice scenario

PAY-041: Requirement says 'make payments faster'

Product and BA

Business problem. A stakeholder asks for faster payments without specifying customer outcome, scope or measurable target.

Messages. Not message-specific

Happy path. Requirement is measurable and testable, with scope and exclusions agreed.

Negative paths. Stakeholders disagree on 'faster'; speed conflicts with fraud controls; external rail cut-off limits

Recommended solution. Clarify the business problem, user journey, baseline, target SLA, eligible rails, volumes, risk controls and dependencies. Convert the goal into measurable functional and non-functional requirements.

Source status: Independently authored practice scenario

PAY-042: New regulatory limit changes product routing

Product and BA

Business problem. A regulatory or scheme rule changes a transaction limit, but the bank also has customer-specific limits and risk controls.

Messages. Rail-specific message and rule configuration

Happy path. Eligible payments are accepted within all applicable limits; breaches receive the correct outcome.

Negative paths. Conflicting limits; effective-date transition; legacy standing orders; channel inconsistency

Recommended solution. Separate scheme maximum, regulatory obligation, bank product limit and customer-level risk limit. Determine precedence, effective date, grandfathering, channels, currencies and exception handling. Validate against official current rules.

Source status: Independently authored practice scenario

PAY-043: Vendor says a feature is supported

Product and BA

Business problem. A vendor demo shows a capability, but it may not cover the bank's exact use case, jurisdiction or exception path.

Messages. Depends on feature

Happy path. Capability is accepted only when evidence meets documented criteria.

Negative paths. Demo uses mocked data; feature requires custom code; country variant unsupported; roadmap item presented as available

Recommended solution. Translate the requirement into demonstrable acceptance scenarios. Ask the vendor to show configuration, negative paths, audit, volume, resilience, support model and upgrade impact. Record gaps and workarounds.

Source status: Independently authored practice scenario

PAY-044: Mobile channel submits incomplete beneficiary data

Payment initiation & channels

Business problem. A retail customer initiates a payment but the channel omits a beneficiary address required for a particular destination or payment type.

Messages. pain.001

Happy path. Complete, valid instruction is accepted and assigned a payment reference.

Negative paths. Address partially populated; unsupported characters; beneficiary changed after approval

Recommended solution. Validate requirements by rail, destination and product. Use trusted beneficiary data only where policy permits; otherwise request correction before submission. Return field-specific guidance and preserve the draft.

Source status: Independently authored practice scenario

PAY-045: Customer changes beneficiary after payment authorisation

Payment initiation & channels

Business problem. A user edits beneficiary details after a payment has been authorised but before release.

Messages. API contract, rail-specific payment message

Happy path. Unchanged authorised instruction proceeds; material change triggers required controls.

Negative paths. Concurrent edit; approval token replay; beneficiary change after release

Recommended solution. Treat material changes as a change to the authorised payment intent. Re-run risk and validation checks and obtain re-authorisation where required. Record before/after values and prevent unauthorised mutation.

Source status: Independently authored practice scenario

PAY-046: Corporate file uploaded twice with different file names

Payment initiation & channels

Business problem. A corporate user uploads the same payment file twice, but the filenames differ.

Messages. pain.001, pain.002

Happy path. A genuinely new file is accepted; duplicate file is blocked or referred according to policy.

Negative paths. Same file with altered whitespace; same transactions in a new file; partial previous processing

Recommended solution. Use business-level duplicate detection based on file identity, control totals, transaction identifiers and customer policy. Do not rely only on filename. Quarantine ambiguous duplicates for review.

Source status: Independently authored practice scenario

PAY-047: Payment approval limit differs from execution limit

Payment initiation & channels

Business problem. A corporate payment is approved under a user entitlement, but the account or product limit is lower.

Messages. API, payment initiation message

Happy path. Payment proceeds when all applicable authorisation and limit controls pass.

Negative paths. Limit changes after approval; split payments; group approval threshold reached

Recommended solution. Evaluate user authority, account limits, product limits, channel limits and scheme limits independently. Apply the strictest relevant constraint and explain the failed control.

Source status: Independently authored practice scenario

PAY-048: Beneficiary account format is valid but account is closed

Payment validation & enrichment

Business problem. A payment passes structural validation, but the beneficiary account is no longer able to receive funds.

Messages. pacs.002, pacs.004

Happy path. Eligible account proceeds; closed account follows defined reject/return handling.

Negative paths. Verification service unavailable; account closes after check; stale confirmation

Recommended solution. Separate format validation from account/service eligibility. Use available account verification or scheme response, and handle closure through the relevant reject/return process rather than treating syntax as proof of reachability.

Source status: Independently authored practice scenario

PAY-049: Name-check result is inconclusive

Payment validation & enrichment

Business problem. A beneficiary name check returns a close match rather than a clear match or mismatch.

Messages. API/name-check response, payment message

Happy path. Customer proceeds, edits or cancels according to policy and receives an understandable result.

Negative paths. Service timeout; transliteration differences; joint account; business trading name

Recommended solution. Apply the jurisdiction's and product's confirmation-of-payee policy. Present clear customer choices where permitted, retain evidence and avoid silently changing beneficiary details.

Source status: Independently authored practice scenario

PAY-050: Fraud engine returns a high-risk score after payment approval

Fraud & financial crime

Business problem. A payment is approved by the customer but a later fraud signal raises its risk before release.

Messages. Internal risk decision, rail-specific payment message

Happy path. Payment is released only when required fraud controls pass.

Negative paths. Risk service timeout; score changes; customer cannot complete step-up; late signal after release

Recommended solution. Bind risk decisions to the payment version and execution stage. Apply hold, step-up authentication, reject or release policy. Reassess if material payment attributes change.

Source status: Independently authored practice scenario

PAY-051: Potential sanctions match requires investigation

Fraud & financial crime

Business problem. A screening engine identifies a possible match against a sanctions list.

Messages. Internal screening event, payment status response

Happy path. False positive is cleared by authorised review; confirmed match follows legal and policy requirements.

Negative paths. List update during processing; partial match; duplicate alerts; SLA breach.

Recommended solution. This scenario is covered in depth in the Payment Exception Q&A bank (QA 23, QA 24). The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Matching case in the Payment Exception Q&A bank. This scenario is covered in depth in the Payment Exception Q&A bank. The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Source status: Independently authored practice scenario

PAY-052: Screening service is unavailable

Fraud & financial crime

Business problem. A mandatory screening dependency is unavailable during payment processing.

Messages. Internal service/API events

Happy path. Payment proceeds only where policy permits and required controls have completed.

Negative paths. Partial outage; timeout; circuit breaker opens; queued payments become stale

Recommended solution. Apply the control-specific fail-open/fail-closed policy. Queue or reject affected payments safely, alert Operations and prevent un-screened release where prohibited.

Source status: Independently authored practice scenario

PAY-053: Clearing acknowledgement is delayed beyond expected window

Clearing & settlement

Business problem. The bank submits a payment but receives no acknowledgement within the expected service window.

Messages. pacs.008, pacs.002

Happy path. Acknowledgement arrives and processing continues based on its business status.

Negative paths. Late acknowledgement after timeout; duplicate acknowledgement; no response ever arrives

Recommended solution. Retain a submitted/awaiting-response state, correlate by message and transaction references, perform status enquiry or operational investigation, and avoid blind resubmission.

Source status: Independently authored practice scenario

PAY-054: Settlement amount differs from submitted payment amount

Clearing & settlement

Business problem. A settlement report contains an amount that differs from the expected payment or batch total.

Messages. camt.053, camt.054

Happy path. Expected gross/net amounts reconcile within documented tolerances.

Negative paths. Unexplained short settlement; currency mismatch; fee not disclosed; partial settlement.

Recommended solution. This scenario is covered in depth in the Payment Exception Q&A bank (QA 1). The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Matching case in the Payment Exception Q&A bank. This scenario is covered in depth in the Payment Exception Q&A bank. The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Source status: Independently authored practice scenario

PAY-055: Clearing system sends duplicate status reports

Clearing & settlement

Business problem. A scheme adapter receives the same status message more than once.

Messages. pacs.002

Happy path. One effective state transition and one required financial effect occur.

Negative paths. Same status with different message ID; duplicate after restart; conflicting status sequence

Recommended solution. Deduplicate by message/event identity and transaction reference. Make status handling idempotent and ensure no repeated ledger posting or customer notification.

Source status: Independently authored practice scenario

PAY-056: Net settlement position creates a liquidity shortfall

Clearing & settlement

Business problem. The bank's projected net debit position exceeds available settlement liquidity.

Messages. Settlement reports, internal liquidity events

Happy path. Settlement obligations are met within scheme rules and approved liquidity limits.

Negative paths. Unexpected outflow; delayed inflow; intraday credit unavailable; forecast data stale

Recommended solution. Forecast position using payment queues, expected inflows/outflows, settlement cycles and available funding. Apply liquidity alerts, prioritisation and contingency funding under Treasury policy.

Source status: Independently authored practice scenario

PAY-057: Settlement calendar differs from customer-facing date

Clearing & settlement

Business problem. A customer is shown an execution date that differs from the interbank settlement date.

Messages. Rail-specific messages and calendar rules

Happy path. Customer receives a transparent date/status aligned to the product definition.

Negative paths. Timezone boundary; holiday; delayed clearing; beneficiary bank posting delay

Recommended solution. Represent requested execution, bank processing, clearing settlement and beneficiary availability as separate concepts. Display the correct customer promise for the product and rail.

Source status: Independently authored practice scenario

PAY-058: Return message has no usable original reference

Returns & investigations

Business problem. A returned payment arrives but its original transaction reference is missing or malformed.

Messages. pacs.004, pacs.008

Happy path. Strong match is linked automatically; ambiguous return is held for review.

Negative paths. Two candidate originals have same amount/date; partial return; currency differs

Recommended solution. Attempt controlled matching using approved secondary attributes, confidence thresholds and time windows. Do not auto-match ambiguous cases; route them to investigation and suspense handling.

Source status: Independently authored practice scenario

PAY-059: Customer disputes a payment they do not recognise

Returns & investigations

Business problem. A customer reports an unfamiliar debit that may be a card, direct debit, standing order or credit transfer.

Messages. camt.053, camt.054

Happy path. Correct case type is opened and routed to the appropriate team.

Negative paths. Customer gives incomplete details; transaction is pending; payment was authorised by another account user

Recommended solution. Identify the payment instrument and transaction type first. Apply the correct dispute, recall, refund or fraud process; secure evidence and explain the next steps.

Source status: Independently authored practice scenario

PAY-060: Cancellation request and return arrive close together

Returns & investigations

Business problem. A payment cancellation request is in flight when a return is independently received.

Messages. camt.056, camt.029, pacs.004

Happy path. One valid financial outcome is applied and both event histories are retained.

Negative paths. Return processed first; cancellation accepted late; duplicate credit; conflicting counterparty messages

Recommended solution. Correlate both events to the original payment and apply a deterministic state model. Prevent duplicate customer credits and reconcile the cancellation outcome with the return financial event.

Source status: Independently authored practice scenario

PAY-061: Ledger posting succeeds but payment status update fails

Reconciliation & accounting

Business problem. The core ledger records a debit, but the payment platform remains in an earlier state because the status event failed.

Messages. camt.053, camt.054

Happy path. Ledger and payment status converge without duplicate debit.

Negative paths. Outbox unavailable; replay repeated; ledger reference missing; partial commit

Recommended solution. Use durable posting references and recoverable event publication. Reconcile ledger and payment state, replay the missing event idempotently and alert on aged inconsistency.

Source status: Independently authored practice scenario

PAY-062: Nostro statement contains an unexplained debit

Reconciliation & accounting

Business problem. Treasury receives a correspondent statement entry that cannot be matched to an expected payment or fee.

Messages. camt.053, MT940, camt.054

Happy path. Matched entries close; unexplained items remain visible as breaks with ownership.

Negative paths. Value date mismatch; correspondent fee; FX difference; duplicate statement; missing payment reference

Recommended solution. Parse the statement, match against expected settlement and fee records, classify unmatched items, and investigate with the correspondent. Do not create an assumed payment record to force a match.

Source status: Independently authored practice scenario

PAY-063: Payment is returned after customer account has closed

Reconciliation & accounting

Business problem. A valid return is received after the original customer account has been closed.

Messages. pacs.004

Happy path. Return funds are safely accounted for and not credited to an invalid account.

Negative paths. Account closure incomplete; replacement account exists; legal restriction; return cannot be matched

Recommended solution. Apply the bank's closed-account return policy and legal/accounting controls. Route funds to an approved suspense or unclaimed-funds process where appropriate, notify relevant teams and preserve traceability.

Source status: Independently authored practice scenario

PAY-064: API schema changes introduce a breaking field rename

Data & integration

Business problem. A downstream consumer expects an existing field name, but a new API version changes it.

Messages. OpenAPI/JSON schema, internal events

Happy path. Existing consumers continue to work during the agreed migration window.

Negative paths. Unknown consumer; old client remains after deprecation; dual-write mismatch

Recommended solution. Use explicit API versioning and compatibility policy. Prefer additive evolution; provide deprecation period, consumer impact assessment, contract tests and migration plan.

Source status: Independently authored practice scenario

PAY-065: Character encoding changes beneficiary name

Data & integration

Business problem. A beneficiary name contains characters not supported by a downstream rail or legacy interface.

Messages. ISO 20022 text fields, rail-specific character rules

Happy path. Name is represented according to supported character rules with traceability.

Negative paths. Lossy transliteration; unsupported script; truncation; two names collapse to same representation

Recommended solution. Apply documented character-set rules and transliteration only where permitted. Preserve the original customer-provided value, record transformed value and ensure the transformation does not change identity meaning.

Source status: Independently authored practice scenario

PAY-066: Payment identifier is reused across systems with different meanings

Data & integration

Business problem. An internal transaction ID is mistakenly mapped to an end-to-end reference or instruction ID.

Messages. pain.001, pacs.008, pacs.009

Happy path. Each identifier retains its meaning and is propagated where required.

Negative paths. Identifier truncation; non-unique values; intermediary replacement; retry creates new ID incorrectly

Recommended solution. Define identifier semantics and lifecycle clearly. Maintain separate fields for internal ID, instruction ID, end-to-end ID, transaction ID, UETR and clearing references; map only according to standards and use case.

Source status: Independently authored practice scenario

PAY-067: New scheme rule changes mandatory data and validation

Product & regulatory change

Business problem. A payment scheme publishes a rulebook update that changes a required field or processing deadline.

Messages. Scheme-specific message version and rulebook

Happy path. New rule is applied from its effective date with backward handling where required.

Negative paths. Mixed-version traffic; delayed participant adoption; historical payment replay

Recommended solution. Perform rule impact analysis across channels, canonical model, validation, mapping, clearing adapters, operations, customer terms and reporting. Implement effective-dated rules and parallel testing.

Source status: Independently authored practice scenario

PAY-068: Bank introduces a new instant payment product

Product & regulatory change

Business problem. A bank wants to launch an instant payment service with 24/7 availability and customer-facing confirmation.

Messages. Rail-specific instant payment messages

Happy path. Eligible payments complete within product and scheme commitments.

Negative paths. Weekend incident; liquidity shortage; participant outage; fraud spike; delayed confirmation

Recommended solution. Define supported segments, rails, limits, liquidity, fraud controls, uptime, cut-offs, customer journey, dispute handling and operating model. Validate scheme participation and end-to-end readiness before launch.

Source status: Independently authored practice scenario

PAY-069: Customer requests a payment limit increase

Product & regulatory change

Business problem. A customer requests a higher daily payment limit for a new business need.

Messages. Internal servicing/API event

Happy path. Approved limit is applied within authorised scope and effective time.

Negative paths. Social engineering; temporary increase expires; joint approval absent; downstream cache stale

Recommended solution. Assess customer segment, risk profile, authentication, fraud controls, regulatory constraints, account mandate and operational capacity. Apply a controlled, effective-dated limit change with approval and monitoring.

Source status: Independently authored practice scenario

PAY-070: Payment queue grows during downstream outage

Operations & resilience

Business problem. A clearing connector outage causes payment backlog and threatens cut-off deadlines.

Messages. Rail-specific messages, internal queue events

Happy path. Queued payments resume in a controlled order without duplicates and within scheme constraints.

Negative paths. Repeated connector retries; queue storage pressure; expired payments; partial replay

Recommended solution. Apply queue prioritisation, back-pressure and controlled recovery. Identify payments at risk of missing cut-off, communicate impact, prevent retry storms and reconcile all queued items after restoration.

Source status: Independently authored practice scenario

PAY-071: Disaster recovery switches payment processing to secondary site

Operations & resilience

Business problem. A primary data centre fails while payments are in-flight.

Messages. All relevant messages and internal events

Happy path. Processing resumes within approved RTO/RPO and no payment is lost or duplicated.

Negative paths. Replication lag; split brain; external acknowledgements arrive at old site; DNS/client retries

Recommended solution. Fail over using tested recovery procedures that preserve durable state, sequence, idempotency keys, message acknowledgements and ledger consistency. Reconcile in-flight items before resuming full throughput.

Source status: Independently authored practice scenario

PAY-072: Manual repair changes beneficiary account details

Operations & resilience

Business problem. An operator corrects an account number in a payment repair queue.

Messages. Internal repair event, downstream payment message

Happy path. Authorised correction is validated and released with complete audit evidence.

Negative paths. Unauthorised change; screening not rerun; operator session timeout; wrong payment selected

Recommended solution. Apply role-based access, maker-checker for sensitive fields, validation, reason capture and full before/after audit. Re-run screening and routing after any material beneficiary change.

Source status: Independently authored practice scenario

PAY-073: Customer receives contradictory notifications

Customer experience & reporting

Business problem. The customer receives a payment-success notification followed by a rejection notification due to asynchronous event ordering.

Messages. Internal status events, customer API

Happy path. Customer receives one accurate message per meaningful state transition.

Negative paths. Late event; duplicate webhook; notification provider retries; status correction

Recommended solution. Define notification eligibility by authoritative payment state and event version. Suppress stale or contradictory messages, correct the customer promptly and retain notification history.

Source status: Independently authored practice scenario

PAY-074: Customer asks for proof of payment

Customer experience & reporting

Business problem. A corporate customer needs evidence that a payment was processed, but the bank's portal only shows a generic completed status.

Messages. pacs.002, camt.054

Happy path. Customer receives evidence accurately describing the achieved milestone.

Negative paths. No beneficiary confirmation; intermediary status missing; status later corrected

Recommended solution. Define evidence levels: instruction received, accepted, sent, clearing accepted, settled, beneficiary credited where known. Provide an appropriate confirmation document/status with timestamp and reference, without overstating what the bank can prove.

Source status: Independently authored practice scenario

PAY-075: Intraday liquidity forecast ignores queued outgoing payments

Liquidity & Treasury

Business problem. Treasury's forecast uses settled balances but does not include payments waiting in the release queue.

Messages. Internal payment/settlement events

Happy path. Forecast reflects expected intraday obligations and available liquidity.

Negative paths. Stale queue snapshot; duplicate inclusion; uncertain incoming funds; cut-off shifts

Recommended solution. Incorporate committed, queued, expected and settled flows with confidence categories. Model release scenarios and refresh forecasts as queue priority or status changes.

Source status: Independently authored practice scenario

PAY-076: Correspondent imposes a new intraday credit limit

Liquidity & Treasury

Business problem. A correspondent reduces the bank's available intraday credit, potentially constraining payment routing.

Messages. pacs.008, pacs.009

Happy path. Payments route only within available and approved funding capacity.

Negative paths. Limit update arrives late; alternative route costs more; no substitute correspondent

Recommended solution. Update liquidity and route eligibility controls, quantify affected corridors and currencies, assess alternative correspondents and prioritise critical payments under policy.

Source status: Independently authored practice scenario

PAY-077: Structured address migration affects payment validation

ISO 20022 & standards

Business problem. A scheme or bank adopts structured or hybrid postal-address requirements and legacy customer records are incomplete.

Messages. Relevant pacs/pain message version and address structures

Happy path. Compliant address data is transmitted in the required structure.

Negative paths. Legacy free-text address; country-specific rules; incomplete town/postcode; mixed versions

Recommended solution. Assess data capture, cleansing, enrichment, message version, validation, downstream storage and customer remediation. Do not fabricate address components; define transition and exception rules.

Source status: Independently authored practice scenario

PAY-078: Remittance information exceeds message limits

ISO 20022 & standards

Business problem. A corporate payment includes extensive invoice details that exceed the receiving rail's supported remittance capacity.

Messages. pain.001, pacs.008

Happy path. Required remittance data is transmitted within scheme limits or alternative agreed mechanism is used.

Negative paths. Multiple invoices; special characters; intermediary truncation; structured data unsupported

Recommended solution. Determine required business references, supported structured/unstructured elements and truncation rules. Preserve essential data through approved supplementary channels or references, and alert the customer when information cannot be carried.

Source status: Independently authored practice scenario

PAY-079: Payment status mapping differs between scheme and bank model

ISO 20022 & standards

Business problem. A scheme uses status and reason combinations that do not map one-to-one to the bank's internal status model.

Messages. pacs.002, pain.002

Happy path. Internal state accurately reflects the scheme event while retaining original code.

Negative paths. Unknown future code; code combination invalid; file-level versus item-level status

Recommended solution. Create a governed mapping matrix by message, status, reason, transaction scope and lifecycle stage. Preserve raw scheme values alongside normalised internal values.

Source status: Independently authored practice scenario

PAY-080: Major requirement change after most of the sprint is complete

Professional Masterclass / Agile Delivery

Business problem. A business owner requests a material change after most of the sprint work has been developed and tested.

Messages. User story, acceptance criteria, change request, API/data contracts where impacted

Happy path. Approved change is delivered in a controlled increment, or explicitly deferred with rationale.

Negative paths. Urgent regulatory change; request invalidates work already completed; dependency team unavailable; scope cannot fit without quality compromise

Recommended solution. Clarify the business driver, urgency and whether the request is a defect, regulatory obligation or new scope. Map impacts to stories, APIs, data, downstream systems, test coverage, dependencies and sprint goal. Present options to the Product Owner: defer, swap scope, split a safe increment, or re-plan the sprint/release. Obtain an explicit decision and update backlog, traceability and stakeholders.

Source status: Independently authored practice scenario

PAY-081: Two senior stakeholders demand mutually exclusive outcomes

Professional Masterclass / Stakeholder Management

Business problem. Two senior business owners insist that opposite behaviours are both essential for the same feature.

Messages. Decision record, process model, prioritisation matrix, acceptance criteria

Happy path. A single agreed rule or configurable policy is approved with clear ownership.

Negative paths. Stakeholders refuse to decide; one preference breaches regulation; requirements can be segmented by customer type

Recommended solution. Understand the outcome each stakeholder is trying to achieve. Make the conflict explicit, quantify customer, regulatory, operational and revenue impact, assess effort and dependencies, and facilitate a decision using agreed product objectives and decision rights. Escalate unresolved trade-offs to the accountable sponsor rather than choosing by hierarchy.

Source status: Independently authored practice scenario

PAY-082: Everything in the backlog is labelled high priority

Professional Masterclass / Prioritisation

Business problem. A backlog contains many items all marked high, making sprint selection impossible.

Messages. Product backlog, WSJF or agreed scoring model, dependency map

Happy path. A ranked backlog with rationale and explicit trade-offs is agreed.

Negative paths. Urgent new item arrives; estimates uncertain; stakeholders game scores; dependencies force non-obvious sequencing

Recommended solution. Re-establish prioritisation criteria: regulatory deadline, customer impact, risk reduction, revenue, strategic alignment, dependency criticality, effort and cost of delay. Use a transparent scoring method and validate sequencing with the PO and stakeholders.

Source status: Independently authored practice scenario

PAY-083: Stakeholders cannot articulate what they need

Professional Masterclass / Requirements Engineering

Business problem. A sponsor asks for a digital capability but describes only a desired screen or solution, not the business problem.

Messages. Problem statement, process map, business rules, user stories, acceptance criteria

Happy path. Stakeholders agree on the problem, scope, measurable outcome and validated requirements.

Negative paths. Different user groups have different needs; hidden manual work; policy exceptions; unspoken controls

Recommended solution. Start with outcomes and current pain points. Interview users, observe the process, review data and policies, map AS-IS and TO-BE, identify actors, rules, exceptions, controls and measures of success. Validate the proposed solution with prototypes or examples before writing requirements.

Source status: Independently authored practice scenario

PAY-084: Developer says an approved requirement is technically infeasible

Professional Masterclass / Feasibility & Solution Design

Business problem. A delivery team challenges a signed-off requirement because of platform constraints or a dependency limitation.

Messages. NFRs, interface contract, architecture decision record, revised acceptance criteria

Happy path. An achievable option is selected while preserving the essential business outcome.

Negative paths. No option meets the original deadline; vendor limitation; workaround increases operational risk

Recommended solution. Ask for the specific constraint and evidence. Work with architecture, engineering and business to identify alternatives, trade-offs, phased delivery or process changes. Compare each option against the original outcome, risk, cost, performance and compliance. Rebaseline only after accountable approval.

Source status: Independently authored practice scenario

PAY-085: Delivered feature works as documented but fails business expectations

Professional Masterclass / UAT & Acceptance

Business problem. UAT users reject a feature even though development followed the approved story and acceptance criteria.

Messages. User story, acceptance criteria, RTM, defect/change record

Happy path. The gap is classified correctly and resolved or accepted through a documented decision.

Negative paths. Business expectation was never captured; acceptance criteria were incomplete; feature is technically correct but operationally unusable

Recommended solution. Compare the original business objective, approved requirements, acceptance criteria, process model and actual behaviour. Classify the gap as implementation defect, ambiguous requirement, missed exception, changed expectation or new scope. Agree severity and release decision, then update tests and traceability.

Source status: Independently authored practice scenario

PAY-086: New requirement arrives after UAT sign-off, immediately before release

Professional Masterclass / Scope & Change Control

Business problem. A previously unrecorded requirement is raised on the eve of deployment.

Messages. Change request, defect record, release checklist, regression evidence

Happy path. Release proceeds only with a documented risk decision and adequate validation.

Negative paths. Mandatory regulatory gap; change cannot be tested in time; rollback cannot restore data; workaround available

Recommended solution. Triage whether it is a defect, safety/compliance issue or new scope. Assess customer impact, regulatory necessity, data migration, regression scope, rollback and deployment risk. Present go/no-go options to the release authority. Defer non-critical scope; postpone or hotfix only with evidence and governance.

Source status: Independently authored practice scenario

PAY-087: UAT feedback mixes defects, usability preferences and new features

Professional Masterclass / Defect Management

Business problem. Testers submit many comments, including broken functionality, cosmetic preferences and new capability requests.

Messages. Defect taxonomy, acceptance criteria, UAT log

Happy path. Critical defects are fixed and retested; enhancements are prioritised separately.

Negative paths. Disagreement on severity; cosmetic issue masks accessibility problem; repeated feedback indicates a systemic design gap

Recommended solution. Define classification criteria and review each item with business, QA and product. Defects are failures against agreed requirements; enhancements change scope; usability issues are assessed against usability standards and impact. Prioritise by severity, user impact and release risk.

Source status: Independently authored practice scenario

PAY-088: API returns success but downstream business transaction is incomplete

APIs & Integration / Production Support

Business problem. A payment API returns a successful HTTP response, but a downstream order, account or case record is not created.

Messages. OpenAPI contract, request/response, webhook/event, payment status messages where applicable

Happy path. The downstream transaction is created exactly once or the payment is placed in a controlled recovery state.

Negative paths. Callback lost; event consumer failed; payload mapping error; timeout; duplicate retry; DB constraint failure

Recommended solution. Determine what the response contract promises: receipt, validation, acceptance or completion. Trace correlation IDs across gateway, service, event bus, downstream consumer and database. Inspect payload, response body, webhook delivery, retries, dead-letter queues and persistence. Reconcile financial effects before retrying.

Source status: Independently authored practice scenario

PAY-089: Integration passes in test but fails in production

APIs & Integration / Environment Management

Business problem. An API integration behaves correctly in SIT/UAT but fails after production deployment.

Messages. OpenAPI, OAuth2/mTLS, logs and distributed traces

Happy path. Root cause is isolated to a configuration, data, capacity or environment difference and corrected safely.

Negative paths. Production-only data shape; expired certificate; rate limit; DNS/firewall; secret rotation; different feature flag

Recommended solution. Compare environment configuration, endpoint, credentials, certificates, firewall/network routes, scopes, payload versions, feature flags, data quality, rate limits and downstream versions. Use production-safe telemetry and a controlled reproduction. Assess rollback/containment before making changes.

Source status: Independently authored practice scenario

PAY-090: Data differs between UI, API payload and database

APIs & Integration / Data Mapping

Business problem. A user sees one value in the UI, the API transmits another, and the persisted record contains a third.

Messages. JSON schema, field mapping, SQL evidence, audit events

Happy path. The authoritative value is identified and all layers are corrected or reconciled consistently.

Negative paths. Rounding; timezone conversion; stale cache; field truncation; asynchronous update; duplicate record

Recommended solution. Trace one affected record using a stable identifier. Compare UI state, request payload, API transformation, validation/defaulting, service logs, database write and read model/cache. Check timezone, decimal precision, encoding, mapping, stale cache and transaction boundaries.

Source status: Independently authored practice scenario

PAY-091: Source data is correct but management report is wrong

Data & Reporting / Reconciliation

Business problem. Operational screens show correct transactions, but a downstream report has missing or incorrect totals.

Messages. Data dictionary, SQL, ETL mappings, report specification

Happy path. Report totals reconcile to agreed source population and business definitions.

Negative paths. Late-arriving records; duplicate join; timezone cutoff; excluded status; currency conversion; refresh failure.

Recommended solution. This scenario is covered in depth in the Payment Exception Q&A bank (QA 21). The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Matching case in the Payment Exception Q&A bank. This scenario is covered in depth in the Payment Exception Q&A bank. The material below adds the end-to-end flow, the messages involved, the structured control points and the acceptance criterion.

Source status: Independently authored practice scenario

PAY-092: Critical production incident: rollback versus hotfix

Professional Masterclass / Production Incident

Business problem. A live service is failing and technology recommends rollback while the business wants service restored immediately.

Messages. Incident record, transaction logs, deployment/change record, reconciliation evidence

Happy path. Service is restored through an approved recovery path and affected transactions are reconciled.

Negative paths. Rollback risks data loss; hotfix untested; partial processing; duplicate transactions; dependent systems inconsistent

Recommended solution. Stabilise first: assess customer, financial, operational, security and regulatory impact; stop or limit harmful processing if necessary; preserve evidence; identify decision owner. Compare rollback, feature disablement, traffic diversion and hotfix based on data integrity, reversibility, validation and recovery time. Communicate status and maintain incident log.

Source status: Independently authored practice scenario

PAY-093: Customer funds are affected but root cause is unknown

Professional Masterclass / Incident & RCA

Business problem. Customers report debits or credits that do not match displayed payment status, while the technical cause is not yet known.

Messages. Payment references, ledger entries, scheme statuses, incident evidence

Happy path. Financial exposure is bounded, affected customers are identified and remediation is controlled.

Negative paths. Unknown in-flight state; delayed external confirmation; multiple rails; partial batch impact; duplicate compensation risk

Recommended solution. Prioritise customer and financial containment. Identify affected population and value, stop duplicate or unsafe processing, preserve transaction evidence, reconcile ledger and external payment records, arrange approved customer remediation and run parallel technical RCA.

Source status: Independently authored practice scenario

PAY-094: Pre-production data mismatch appears shortly before go-live

Professional Masterclass / Release Management

Business problem. SIT and UAT passed, but pre-production testing reveals a data mismatch close to release approval.

Messages. Test evidence, SQL reconciliation, data mapping, release checklist

Happy path. Mismatch is resolved and regression evidence supports go-live, or release is formally deferred.

Negative paths. Only certain customer segments affected; production data differs; fix requires migration; workaround creates manual risk

Recommended solution. Assess whether the mismatch is representative, reproducible and release-critical. Compare environment data, mappings, reference data, migration scripts and configuration. Quantify affected journeys and records. Delay or proceed only through formal risk acceptance with a safe mitigation and rollback plan.

Source status: Independently authored practice scenario

PAY-095: QA capacity is insufficient for a fixed release date

Professional Masterclass / Quality & Test Strategy

Business problem. The release date is fixed but QA resources cannot execute the full planned test suite.

Messages. Test strategy, RTM, defect severity model, release checklist

Happy path. Critical controls and high-risk journeys are tested with evidence; residual risk is accepted explicitly.

Negative paths. Critical tester unavailable; environment instability; high defect rate; dependencies not testable

Recommended solution. Reassess risk-based coverage with QA and product. Protect critical payment, security, regulatory, data integrity and regression paths. Identify automation, parallel execution, scope reduction or release phasing. Make residual risk explicit to release authority.

Source status: Independently authored practice scenario

PAY-096: Stories repeatedly spill over into the next sprint

Professional Masterclass / Backlog Management

Business problem. Multiple user stories remain unfinished at sprint end because they are too large, unclear or dependency-heavy.

Messages. User stories, estimation, DoR/DoD, dependency board

Happy path. Stories are smaller, testable and completed with more predictable flow.

Negative paths. PO refuses to split; integration dependency unavailable; unplanned production support consumes capacity

Recommended solution. Review historical spillover causes, story size, acceptance clarity, external dependencies, team capacity and hidden work. Split vertically into independently testable value increments, refine definition of ready/done and forecast using actual throughput.

Source status: Independently authored practice scenario

PAY-097: Team delivers every sprint but business outcomes do not improve

Professional Masterclass / Product Outcomes

Business problem. Delivery metrics show completed stories, but customer conversion, processing time or operational workload remains unchanged.

Messages. Product KPI tree, analytics events, process metrics, user feedback

Happy path. A measurable hypothesis is tested and backlog changes reflect observed outcomes.

Negative paths. Metric instrumentation missing; external factors distort results; adoption low; proxy metric misleading

Recommended solution. Reconnect backlog items to the product outcome and baseline metrics. Validate whether the problem was correctly defined, adoption barriers exist, process changes were omitted or the delivered capability misses the user need. Reprioritise based on measured outcomes.

Source status: Independently authored practice scenario

PAY-098: Business requests a shortcut that conflicts with a control

Professional Masterclass / Governance & Compliance

Business problem. A stakeholder asks to bypass a validation or approval to meet a deadline, but the control is required by policy or regulation.

Messages. Control matrix, policy, regulatory requirement, audit record

Happy path. A compliant option is implemented or the request is declined with rationale.

Negative paths. Urgent customer impact; policy interpretation disputed; compensating control proposed; temporary exception requested

Recommended solution. Identify the exact control obligation and risk owner. Explain the consequence, explore compliant alternatives such as controlled manual review or limited scope, and escalate to Compliance/Risk where interpretation is needed. Record the decision and prohibit unauthorised bypass.

Source status: Independently authored practice scenario

PAY-099: Regulatory requirement arrives after development is well advanced

Professional Masterclass / Regulatory Change

Business problem. A new regulatory obligation is published or interpreted while a release is already in progress.

Messages. Regulatory obligation register, control mapping, user stories, RTM

Happy path. Required changes are delivered by the applicable date with traceable evidence and operational readiness.

Negative paths. Ambiguous interpretation; delayed vendor change; multiple jurisdictions; transitional provisions

Recommended solution. Confirm applicability, legal interpretation, effective date and affected entities/products. Perform gap and impact analysis across process, data, controls, messages, reporting, customer terms and operations. Prioritise mandatory compliance, identify interim controls if legally acceptable and re-plan with governance.

Source status: Independently authored practice scenario

PAY-100: Client escalates angrily that the delivered process has disrupted operations

Professional Masterclass / Stakeholder Communication

Business problem. A client reports that a change has made a critical operational process harder or impossible.

Messages. Incident/change record, process map, communications log

Happy path. Client has a named owner, a safe workaround and a clear recovery timeline.

Negative paths. Conflicting accounts; contractual SLA breach; issue is caused by training or process change rather than defect

Recommended solution. Acknowledge impact without defensiveness, establish facts and immediate workaround, capture affected users/processes, compare before/after workflow and approved requirements, agree recovery owner and update cadence. Follow with root-cause and prevention actions.

Source status: Independently authored practice scenario

PAY-101: Project handover occurs without adequate knowledge transfer

Professional Masterclass / Knowledge Management

Business problem. A new BA or support team inherits a payment process with incomplete documentation and unavailable subject-matter experts.

Messages. Runbooks, process maps, interface catalogue, decision log, support matrix

Happy path. Receiving team can explain and execute key operational scenarios independently.

Negative paths. Critical SME unavailable; undocumented manual workaround; credentials/access missing; stale diagrams

Recommended solution. Establish service boundaries, process flows, system/context diagrams, data dictionary, known issues, operational runbooks, contacts, controls, SLAs and open decisions. Validate through reverse-shadowing and scenario walkthroughs; record gaps and risk owners.

Source status: Independently authored practice scenario

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