Key points of this lesson, in order.
Why cross border payments fail
What you will learn
Your objective. By the end of this lesson, you will be able to explain cross border payments fail. Most cross border payments arrive without a problem, but a small percentage fail, and the failures matter out of proportion to their number because each failure involves a customer who is waiting for money, a supplier.
Why it matters. Most cross border payments arrive without a problem, but a small percentage fail, and the failures matter out of proportion to their number because each failure involves a customer who is waiting for money, a supplier who has not been paid, or a salary that has not arrived.
Chapter objective: Learner handles cross-border exceptions, including missing information, wrong beneficiary details, value date errors, and duplicate payments, and writes clear investigation and repair actions. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.
Key learning points
- Cross border payments arrive
- Cost of a failure
- Wrong account recovery
- Scale of exceptions
Key terms
Liquidity: Cash or assets that a bank can use immediately to meet payment obligations. Banks manage liquidity by forecasting inflows and outflows, funding nostro and settlement accounts, and using central bank...
Exception: A payment that cannot be processed normally and needs manual handling, investigation or repair. Exceptions arise from missing data, failed screening, account errors or system faults.
Capture: The step in a card transaction where the merchant collects the authorised amount from the issuer, usually when goods are shipped.
Exception investigation workflow showing Why cross border payments fail.
Insights and practice scenarios
Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.
Practise this lesson
Exercise
Scenario: you are an operations analyst. A customer calls and says: "I sent a payment yesterday and I do not know where it is. The status says ACSP. What does that mean and where is my money?" The payment is a USD 10,000 cross-border payment sent on 3 November 2026. The gpi tracker shows the status ACSP at the sender correspondent bank. Explain the status, trace where the payment is, and tell the customer what happens next and when.
Payment status codes: ACTC means technical validation passed. ACCP means accepted for processing. ACSP means accepted, settlement in progress. ACSC means settlement completed on the debtor account. ACCC means settlement completed on the creditor account, the only code that confirms the beneficiary was credited. RJCT means rejected. PDNG means pending. The gpi tracker shows ACSP at JPMorgan Chase, the sender correspondent. The payment was sent on 3 November with value date 3 November. Today is 4 November. The beneficiary bank has not yet confirmed receipt.
- What to do. Explain the status ACSP in plain language. Trace where the payment is now. State what happens next, the expected timeline, and what to do if the status does not change by tomorrow.
Correct result. ACSP means accepted, settlement in progress. In plain language: the payment has passed validation, the sending bank has accepted it, and the funds are moving through the correspondent chain, but the beneficiary has not yet been credited. Where the payment is now: the payment is at JPMorgan Chase, the sender correspondent, which has accepted it and is processing the onward settlement to the next bank in the chain. What happens next: JPMorgan will send the funds onward to the next correspondent or to the beneficiary bank, and the status will change to ACSC when the debtor account is debited, then to ACCC when the beneficiary is credited. Expected timeline: for a USD cross-border payment sent on 3 November with value date 3 November, the beneficiary should be credited by end of day 4 November. If the status is still ACSP on 5 November, send an investigation message (MT199) to JPMorgan asking for the status of the payment with the UETR and reference, and check whether the payment is held for a compliance check or because the next bank has not confirmed receipt. Tell the customer: your payment is in transit, it has been accepted by our correspondent bank and is being settled, the beneficiary should receive it by end of tomorrow, and we will update you if the status does not change. Worked reasoning: ACSP is a normal intermediate status, not an error. The payment is not lost; it is in the settlement process. The key is the timeline: if the status does not advance within one business day, investigate.
Why. Hint 1: ACSP means settlement is in progress, not that the payment has settled. Hint 2: only ACCC confirms the beneficiary was credited; ACSP and ACSC do not. Hint 3: if the status does not change within one business day, investigate with the bank that last confirmed the payment. The worked explanation shows the status analysis discipline: explain the code in plain language, trace where the payment is, give the expected timeline, and state the trigger for investigation.
Check your understanding
Practice question
A cross-border payment is stopped because the beneficiary name closely matches a sanctions list entry. What should the bank do first?
Takeaway and next step
What to remember
A payment that is stopped for a compliance query can take a week or more to resolve, and the customer may have no idea why it is stopped, because the bank cannot always disclose the reason for a compliance hold.
Build a cross-border payment like the one in this lesson and watch the chain, the charges, and the final amount change.
Open the Cross-Border Payment Configurator →
Builds on "A complete cross border payment: putting it together".
Transcript and full text
Show transcript
Most cross border payments arrive without a problem, but a small percentage fail, and the failures matter out of proportion to their number because each failure involves a customer who is waiting for money, a supplier who has not been paid, or a salary that has not arrived. The reasons for failure fall into a few clear groups, and the analyst must know them because each group has a different handling process. The first group is bad data, a wrong IBAN, a wrong BIC, a wrong account number, a misspelled beneficiary name, or a missing address. The third group is liquidity and limits, a nostro account with insufficient balance, a payment above a bank's limit, or a payment submitted after the cut off. The fourth group is technical failure, and it is the group that analysts most often overlook. A message that fails schema validation, a system that is down, a file that is corrupted, or a connection that is lost can all stop a payment. A pacs.008 that is missing a mandatory field will be rejected by the receiving bank's system, and the rejection will be reported as a pacs.002 with a reason code, but the root cause is a system error, not a business error. The analyst must therefore distinguish a business exception, such as a wrong account number, from a technical exception, such as a schema failure, because the fix is different. A business exception is fixed by correcting the data. A technical exception is fixed by correcting the system. A payment that is rejected on day one and returned on day three has cost the bank three days of work and the customer three days of waiting. A payment that is stopped for a compliance query can take a week or more to resolve, and the customer may have no idea why it is stopped, because the bank cannot always disclose the reason for a compliance hold. A payment that is sent to the wrong account can be very hard to recover, especially if the beneficiary has already withdrawn the funds. The analyst must design the payment capture to prevent the failures that can be prevented, must design the exception handling to resolve the failures that cannot be prevented, and must design the customer communication to keep the customer informed throughout. The scale of exceptions is also a measure of the quality of a payment operation. A bank that processes a million cross border payments a year with a one percent exception rate has ten thousand exceptions to handle, which is a large operations team. A bank that reduces the exception rate to half a percent has halved its operations cost and doubled its customer satisfaction. The analyst contributes to that reduction by improving the validation, by clarifying the customer instructions, by fixing the data that causes repeat failures, and by analysing the exception data to find the root causes. It is the most valuable source of insight into what is wrong with the payment product, and the analyst who reads it regularly will find the improvements that matter most. Prevention is cheaper than cure, and a payment that is validated at entry is a payment that does not become an exception. IBAN validation with the MOD 97 check, BIC validation against the SWIFT directory, account number format checks, confirmation of payee where it is available, and mandatory field validation will catch most of the errors that cause rejects, before the payment is sent. The analyst should measure the reject rate by reason code, should identify the top three reasons, and should fix the capture screen to prevent them. A reject rate that falls month after month is the sign of a payment product that is getting better, and the analyst can take credit for it. The exception taxonomy that the analyst should use has five categories: reject, return, recall, investigation, and technical failure. A reject is stopped before the funds move. A return is stopped after the funds have moved and the money comes back. A recall is a request to return a payment that has already been credited. An investigation is a query about a payment that has not arrived or has arrived incorrectly. A technical failure is a system error that prevents the payment from being processed. Each category has its own messages, its own reason codes, its own timeline, and its own handling process, and the analyst must design for all five, not just for the ones that are most common. The analyst should also understand the difference between an exception and a query. An exception is a payment that has failed or is at risk of failing, and it needs action. A query is a request for information about a payment, and it may not mean the payment has failed. A customer who asks where their payment is has raised a query, not an exception, but if the query reveals that the payment is stuck, it becomes an exception. The system must therefore handle both, must log every query, must link the query to the payment by UETR, and must escalate a query to an exception when the payment is found to be delayed or incorrect. A query that is not logged is a query that cannot be measured, and a query that cannot be measured cannot be improved. Finally, the analyst should know that exceptions are where the customer relationship is won or lost. A customer who has a payment exception and is kept informed, is given a clear timeline, and receives the money or a clear explanation, will stay with the bank. A customer who has a payment exception and hears nothing for a week, is given conflicting information by different people, and is charged a fee without explanation, will leave. The exception handling process is therefore not an operations afterthought. It is a customer service product, and the analyst must design it from the customer's point of view, not from the bank's point of view. That is the standard that this chapter, and this whole part of the course, has been building towards.
Most cross border payments arrive without a problem, but a small percentage fail, and the failures matter out of proportion to their number because each failure involves a customer who is waiting for money, a supplier who has not been paid, or a salary that has not arrived. The reasons for failure fall into a few clear groups, and the analyst must know them because each group has a different handling process. The first group is bad data, a wrong IBAN, a wrong BIC, a wrong account number, a misspelled beneficiary name, or a missing address. The third group is liquidity and limits, a nostro account with insufficient balance, a payment above a bank's limit, or a payment submitted after the cut off.
The fourth group is technical failure, and it is the group that analysts most often overlook. A message that fails schema validation, a system that is down, a file that is corrupted, or a connection that is lost can all stop a payment. A pacs.008 that is missing a mandatory field will be rejected by the receiving bank's system, and the rejection will be reported as a pacs.002 with a reason code, but the root cause is a system error, not a business error. The analyst must therefore distinguish a business exception, such as a wrong account number, from a technical exception, such as a schema failure, because the fix is different. A business exception is fixed by correcting the data. A technical exception is fixed by correcting the system.
A payment that is rejected on day one and returned on day three has cost the bank three days of work and the customer three days of waiting. A payment that is stopped for a compliance query can take a week or more to resolve, and the customer may have no idea why it is stopped, because the bank cannot always disclose the reason for a compliance hold. A payment that is sent to the wrong account can be very hard to recover, especially if the beneficiary has already withdrawn the funds. The analyst must design the payment capture to prevent the failures that can be prevented, must design the exception handling to resolve the failures that cannot be prevented, and must design the customer communication to keep the customer informed throughout.
The scale of exceptions is also a measure of the quality of a payment operation. A bank that processes a million cross border payments a year with a one percent exception rate has ten thousand exceptions to handle, which is a large operations team. A bank that reduces the exception rate to half a percent has halved its operations cost and doubled its customer satisfaction. The analyst contributes to that reduction by improving the validation, by clarifying the customer instructions, by fixing the data that causes repeat failures, and by analysing the exception data to find the root causes. It is the most valuable source of insight into what is wrong with the payment product, and the analyst who reads it regularly will find the improvements that matter most.
Prevention is cheaper than cure, and a payment that is validated at entry is a payment that does not become an exception. IBAN validation with the MOD 97 check, BIC validation against the SWIFT directory, account number format checks, confirmation of payee where it is available, and mandatory field validation will catch most of the errors that cause rejects, before the payment is sent. The analyst should measure the reject rate by reason code, should identify the top three reasons, and should fix the capture screen to prevent them. A reject rate that falls month after month is the sign of a payment product that is getting better, and the analyst can take credit for it.
The exception taxonomy that the analyst should use has five categories: reject, return, recall, investigation, and technical failure. A reject is stopped before the funds move. A return is stopped after the funds have moved and the money comes back. A recall is a request to return a payment that has already been credited. An investigation is a query about a payment that has not arrived or has arrived incorrectly. A technical failure is a system error that prevents the payment from being processed. Each category has its own messages, its own reason codes, its own timeline, and its own handling process, and the analyst must design for all five, not just for the ones that are most common.
The analyst should also understand the difference between an exception and a query. An exception is a payment that has failed or is at risk of failing, and it needs action. A query is a request for information about a payment, and it may not mean the payment has failed. A customer who asks where their payment is has raised a query, not an exception, but if the query reveals that the payment is stuck, it becomes an exception. The system must therefore handle both, must log every query, must link the query to the payment by UETR, and must escalate a query to an exception when the payment is found to be delayed or incorrect. A query that is not logged is a query that cannot be measured, and a query that cannot be measured cannot be improved.
Finally, the analyst should know that exceptions are where the customer relationship is won or lost. A customer who has a payment exception and is kept informed, is given a clear timeline, and receives the money or a clear explanation, will stay with the bank. A customer who has a payment exception and hears nothing for a week, is given conflicting information by different people, and is charged a fee without explanation, will leave. The exception handling process is therefore not an operations afterthought. It is a customer service product, and the analyst must design it from the customer's point of view, not from the bank's point of view. That is the standard that this chapter, and this whole part of the course, has been building towards.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.