Steps of this lesson, in order.
Exceptions, returns, recalls and investigations
What you will learn
Your objective. By the end of this lesson, you will be able to explain exceptions, returns, recalls and investigations. No payment lifecycle is complete without exception handling, because a significant minority of payments will fail, be delayed, or need investigation.
Why it matters. For a business analyst, exception handling is where much of the real work lies.
Chapter objective: Learner walks a payment from initiation through validation, screening, clearing, settlement, and reconciliation, and identifies the controls and failure points at each stage of the lifecycle. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.
Key learning points
- No payment lifecycle
- Recall: sent in error
- Investigation process in cross border payments often
- Speed of resolution
- Repair, return or reject
- Good lifecycle
Key terms
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.
ISO 20022: An international standard for financial messaging that defines XML message formats for payments, securities and trade.
Creditor: The party that is owed money and receives a payment, such as a supplier, a seller or a service provider.
Animated payment lifecycle showing Exceptions, returns, recalls and investigations.
Practise this lesson
Exercise
Handle the exception described in this lesson the way the lesson prescribes.
Use the exception type, the reason code and the recovery path in this lesson.
- What to do. State what happened, what the correct action is, what must not be done, and what the post-incident review should capture.
Correct result. The correct action is the one the lesson prescribes for this exception type, with the right reason code and the right message. The payment must not be resent without checking whether it already settled, because that creates a duplicate.
Why. An exception handled wrongly is worse than the exception itself. A duplicate payment is a loss, and an unlearned exception will happen again.
Check your understanding
Practice question
Which of the following best describes exceptions, returns, recalls and investigations?
Takeaway and next step
What to remember
For a business analyst, exception handling is where much of the real work lies.
Run the exception from this lesson and follow the investigation to its resolution.
Open the Exception Investigation Simulator →
Builds on "Crediting the beneficiary and notification".
Transcript and full text
Show transcript
No payment lifecycle is complete without exception handling, because a significant minority of payments will fail, be delayed, or need investigation. A return occurs when the creditor agent cannot credit the payment and sends it back to the debtor agent, with a return code explaining the reason, such as account closed, beneficiary deceased, or invalid account number. A recall occurs when the debtor asks for a payment to be returned after it has been sent, for example because it was sent in error or for the wrong amount. A recall is a request, not a guarantee, and the creditor must agree to return the funds in most cases. An investigation occurs when a party asks where a payment is, why it is delayed, or why the amount received differs from the amount sent. The investigation process in cross border payments often uses SWIFT gpi or ISO 20022 status messages to trace the payment across banks. Each bank in the chain must respond to the investigation within a set time, and the response must state the status, the charges deducted, and the next action. In domestic payments, investigations are usually handled through the clearing system or through direct contact between banks. The speed of resolution depends on how well each bank has recorded the payment, and on whether the references are consistent across the chain. A payment with a clear, unique reference is far easier to investigate than one with a vague or missing reference. For a business analyst, exception handling is where much of the real work lies. You must document every return code, every recall flow, every investigation step, and the service levels for each. You must distinguish between a payment that can be repaired and resent, a payment that must be returned, and a payment that must be investigated before any action is taken. You must also ensure that the customer is kept informed throughout, because an unexplained delay is often more damaging than the delay itself. A lifecycle diagram that shows only the happy path is incomplete. A good lifecycle includes the unhappy paths, the owners, and the timelines for each. Worked example with real numbers: a customer sends EUR 15,000 to the wrong supplier on Monday, discovers the error on Tuesday, and asks Bank A to recall it. Bank A sends a camt.056 cancellation request on Tuesday, citing the original pacs.008 message identifier, the amount EUR 15,000 and the reason DUPL for a duplicate payment. Bank B sends a pacs.004 return for EUR 15,000 on Wednesday, Bank A credits the customer EUR 15,000 on Thursday, and Bank B sends a camt.029 resolution of investigation confirming the recall was accepted. Under the SEPA Credit Transfer Rulebook 2025, version 1. 1, effective 5 October 2025, a recall for a duplicate must be sent within 10 banking business days, and the beneficiary bank must respond within 15 banking business days. Failure and recovery: a return fails when the beneficiary account has insufficient funds, because the beneficiary already spent the money, and the recovery is a claim against the beneficiary, not a bank return, and the customer may need legal advice. A recall fails when the beneficiary refuses to return the funds, and the recovery is a formal investigation, a camt.029 with a negative outcome, and the customer is told the recall was refused and what the next steps are. A duplicate payment, where the same instruction was sent twice, is recovered by returning the duplicate with a pacs.004, reason code DUPL, and the customer is credited, with the original payment left in place. Each exception has its own message, its own timeline and its own owner. For a business analyst, product owner or subject matter expert, the test is to write the exception playbook for the product, with one row per exception type, and columns for the message, the reason code, the timeline, the owner, the customer message and the recovery. The ISO 20022 messages are the playbook: pacs.002 for rejections, pacs.004 for returns, camt.056 for recalls, camt.027 for claims non-receipt, camt.029 for resolutions, and camt.087 for value-date corrections, and the requirement must name the message and the reason code for each exception. A requirement that says exceptions are handled, without naming the message, the code and the timeline, will produce an operations team that improvises, and an improvising operations team is a complaint waiting to happen.
No payment lifecycle is complete without exception handling, because a significant minority of payments will fail, be delayed, or need investigation. A return occurs when the creditor agent cannot credit the payment and sends it back to the debtor agent, with a return code explaining the reason, such as account closed, beneficiary deceased, or invalid account number. A recall occurs when the debtor asks for a payment to be returned after it has been sent, for example because it was sent in error or for the wrong amount. A recall is a request, not a guarantee, and the creditor must agree to return the funds in most cases. An investigation occurs when a party asks where a payment is, why it is delayed, or why the amount received differs from the amount sent.
The investigation process in cross border payments often uses SWIFT gpi or ISO 20022 status messages to trace the payment across banks. Each bank in the chain must respond to the investigation within a set time, and the response must state the status, the charges deducted, and the next action. In domestic payments, investigations are usually handled through the clearing system or through direct contact between banks. The speed of resolution depends on how well each bank has recorded the payment, and on whether the references are consistent across the chain. A payment with a clear, unique reference is far easier to investigate than one with a vague or missing reference.
For a business analyst, exception handling is where much of the real work lies. You must document every return code, every recall flow, every investigation step, and the service levels for each. You must distinguish between a payment that can be repaired and resent, a payment that must be returned, and a payment that must be investigated before any action is taken. You must also ensure that the customer is kept informed throughout, because an unexplained delay is often more damaging than the delay itself. A lifecycle diagram that shows only the happy path is incomplete. A good lifecycle includes the unhappy paths, the owners, and the timelines for each.
Worked example with real numbers: a customer sends EUR 15,000 to the wrong supplier on Monday, discovers the error on Tuesday, and asks Bank A to recall it. Bank A sends a camt.056 cancellation request on Tuesday, citing the original pacs.008 message identifier, the amount EUR 15,000 and the reason DUPL for a duplicate payment. Bank B sends a pacs.004 return for EUR 15,000 on Wednesday, Bank A credits the customer EUR 15,000 on Thursday, and Bank B sends a camt.029 resolution of investigation confirming the recall was accepted. Under the SEPA Credit Transfer Rulebook 2025, version 1. 1, effective 5 October 2025, a recall for a duplicate must be sent within 10 banking business days, and the beneficiary bank must respond within 15 banking business days.
Failure and recovery: a return fails when the beneficiary account has insufficient funds, because the beneficiary already spent the money, and the recovery is a claim against the beneficiary, not a bank return, and the customer may need legal advice. A recall fails when the beneficiary refuses to return the funds, and the recovery is a formal investigation, a camt.029 with a negative outcome, and the customer is told the recall was refused and what the next steps are. A duplicate payment, where the same instruction was sent twice, is recovered by returning the duplicate with a pacs.004, reason code DUPL, and the customer is credited, with the original payment left in place. Each exception has its own message, its own timeline and its own owner.
For a business analyst, product owner or subject matter expert, the test is to write the exception playbook for the product, with one row per exception type, and columns for the message, the reason code, the timeline, the owner, the customer message and the recovery. The ISO 20022 messages are the playbook: pacs.002 for rejections, pacs.004 for returns, camt.056 for recalls, camt.027 for claims non-receipt, camt.029 for resolutions, and camt.087 for value-date corrections, and the requirement must name the message and the reason code for each exception. A requirement that says exceptions are handled, without naming the message, the code and the timeline, will produce an operations team that improvises, and an improvising operations team is a complaint waiting to happen.
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.