Key points of this lesson, in order.
Investigations and reason codes
What you will learn
Your objective. By the end of this lesson, you will be able to explain investigations and reason codes. An investigation is the process of finding out what happened to a payment that has not arrived, has arrived for the wrong amount, or has arrived with the wrong information, and it is the most common exception task in.
Why it matters. The investigation starts with the customer reporting the problem, and the operations team then traces the payment using the UETR, the gpi tracker, the SWIFT messages, and the correspondent account statements.
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
- Investigation: process of finding out
- Reason codes
- Investigation produces prevention record
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.
Return: A payment that is sent back to the sender after settlement because it cannot be credited to the beneficiary.
Exception investigation workflow showing Investigations and reason codes.
Practise this lesson
Exercise
Scenario: you are an investigations analyst. A customer payment of USD 10,000 was sent from London to a beneficiary in Brazil on 3 November 2026 via the cover method: an MT103 went direct to the beneficiary bank and an MT202 COV went through the correspondent chain to cover the funds. The beneficiary bank says it received the MT103 but has not received the funds. The MT202 COV cannot be found. Investigate: trace what should have happened, identify where the MT202 COV should be now, list the investigation messages to send, and state what to tell the customer.
The payment chain: ordering bank NatWest London (NWBKGB2L), sender correspondent JPMorgan Chase New York (CHASUS33), intermediary Citibank New York (CITIUS33), beneficiary bank Banco do Brasil Sao Paulo (BRASBRRJ). The MT103 was sent direct from NatWest to Banco do Brasil on 3 November with reference PAY20261103. The MT202 COV was sent from NatWest to JPMorgan with the same reference and the field 21 related reference PAY20261103. JPMorgan should have sent an MT202 COV onward to Citibank, and Citibank should have sent an MT202 COV onward to Banco do Brasil. The value date was 3 November 2026. Today is 5 November 2026. The customer has called twice asking where the money is.
- What to do. Write the investigation plan: the expected path of the MT202 COV with each hop, the exact investigation message to send to each bank (MT192, MT196, MT199 or MT299, with the field 21 reference and the field 79 narrative), and the message to send to the customer. Then state the most likely cause and the next step if the MT202 COV is still not found.
Correct result. Expected path: NatWest to JPMorgan (MT202 COV, 3 November), JPMorgan to Citibank (MT202 COV, 3 November), Citibank to Banco do Brasil (MT202 COV, 3 November), Banco do Brasil credits the beneficiary on value date 3 November. Investigation steps: send an MT192 (request for cancellation is not right here; use MT199 free format) to JPMorgan asking whether it received the MT202 COV with reference PAY20261103 and whether it sent it onward to Citibank, quoting field 21 PAY20261103 and field 79 with the full payment details. Send the same MT199 to Citibank asking whether it received the MT202 COV from JPMorgan and whether it sent it onward to Banco do Brasil. Send an MT199 to Banco do Brasil confirming it holds the MT103 and asking whether it has received any cover. Most likely cause: the MT202 COV was stopped at JPMorgan or Citibank because the field 21 related reference did not match the MT103 reference, or because the cover amount did not match, so the receiving bank held it pending investigation. Next step if still not found: ask JPMorgan for a copy of the MT202 COV it sent, check the UETR on the gpi tracker, and if the funds are confirmed held at an intermediary, request a recall or a re-send of the cover with the correct reference. Tell the customer: the instruction reached the beneficiary bank but the funds are held at an intermediary bank, we have raised investigations with all three banks, and we will update you by end of day 6 November. Worked reasoning: in the cover method the MT103 and the MT202 COV travel separately, so the beneficiary bank can hold the instruction while waiting for funds. The investigation must follow the cover chain hop by hop, because the break could be at any hop. Field 21 is the link between the MT103 and the MT202 COV; if it does not match, the banks cannot pair them.
Why. Hint 1: in the cover method, always investigate the cover chain separately from the instruction, because they travel different routes. Hint 2: field 21 is the link between the MT103 and the MT202 COV; a mismatch there is the most common cause of a missing cover. Hint 3: the UETR on the gpi tracker shows the status of the payment at each bank, so check it before sending investigation messages. The worked explanation shows the investigation discipline: trace the expected path first, then ask each bank in the chain the same question with the same reference, and tell the customer what is known and when the next update will come.
Check your understanding
Practice question
Which of the following best describes investigations and reason codes?
Takeaway and next step
What to remember
An investigation that ends with the payment found but no lesson learned is a missed opportunity, and the analyst who closes the loop is the analyst who improves the product.
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 "Recalls: asking for the money back".
Transcript and full text
Show transcript
An investigation is the process of finding out what happened to a payment that has not arrived, has arrived for the wrong amount, or has arrived with the wrong information, and it is the most common exception task in cross border operations. The investigation starts with the customer reporting the problem, and the operations team then traces the payment using the UETR, the gpi tracker, the SWIFT messages, and the correspondent account statements. The investigation can take days, because each bank must respond, and because the banks are in different time zones and speak different languages. The analyst must design the investigation process to be systematic: log the query, trace the payment, contact the right bank, record the response, and update the customer at each step. Reason codes are the standardised language of investigations, and the analyst must know the most important ones. In the SWIFT system, return and reject reason codes include AC01 for incorrect account number, AC04 for closed account, AC06 for blocked account, AM05 for duplication, BE05 for unknown beneficiary, and MD07 for end customer deceased. In the ISO 20022 system, the same reasons are carried in the pacs.002 and pacs.004 messages with a code and a description, and in the camt.029 resolution of investigation. In the gpi tracker, the status codes show whether the payment is accepted, in progress, credited, rejected or returned. The analyst must be able to read all three sets of codes and to translate them into plain language for the customer. The investigation message flow in ISO 20022 is worth knowing in detail. When a bank needs to investigate a payment, it can send a camt.056 cancellation request, if it wants the payment returned, or it can send a query using an MT199 or MT999 free format message. The receiving bank responds with a camt.029 resolution of investigation, which says what was found and what action was taken. The camt.029 carries the original UETR, the status, and a description of the resolution. The analyst must ensure that the system can send and receive camt.056 and camt.029, that it links them to the original payment by UETR, and that it records the outcome. A system that cannot process a camt.029 cannot close an investigation, and the investigation will sit open indefinitely. If the investigation finds that the account number was wrong because the customer copied it from an old invoice, the fix is to update the invoice template. If it finds that the payment was delayed because the intermediary bank stopped it for a compliance query, the fix is to improve the originator information. If it finds that the payment was returned because the beneficiary bank had changed its BIC, the fix is to update the bank directory. The analyst should review the investigation data regularly, should identify the repeat causes, and should propose the fixes. An investigation that ends with the payment found but no lesson learned is a missed opportunity, and the analyst who closes the loop is the analyst who improves the product. The most common investigation scenarios, and the ones the analyst must design for, are: the payment has not arrived, the payment arrived for the wrong amount, the payment arrived with the wrong reference, the payment was returned but the customer does not know why, and the payment was sent twice. A payment that has not arrived is traced through the gpi tracker and the correspondent statements. A payment that arrived for the wrong amount is checked against the charge deductions at each bank. A payment that arrived with the wrong reference is matched by UETR and amount. A payment that was sent twice is checked for duplication, reason code AM05, and the duplicate is recalled. The analyst should write a runbook for each scenario, with the steps, the messages to send, and the expected timeline. The investigation service level is part of the product, and the analyst must specify it. The first response to the customer should be within two business days, with an update on what has been found so far. The investigation should be resolved within fifteen business days, with regular updates in between. If the investigation is not resolved within fifteen days, it should be escalated to a senior manager, and the customer should be told. The analyst must ensure that the system tracks the age of each investigation, that it alerts when an investigation is approaching its deadline, and that it reports the average resolution time by reason and by corridor. An investigation that is not tracked is an investigation that will be forgotten, and a forgotten investigation is a customer who will leave. There is a specific investigation that deserves attention: the investigation into a payment that the beneficiary says never arrived, but the tracker says was credited. This is usually a case where the payment was credited to the wrong account, or where the beneficiary is looking at the wrong account, or where the credit is shown under a different reference. The analyst must design the investigation to check the beneficiary account, the value date, and the reference, and to obtain a confirmation from the beneficiary bank that the credit was made. The confirmation should be in writing, with the account number, the amount, and the value date, so that the customer can be shown proof. A verbal confirmation is not enough, because the customer needs evidence, and the bank needs an audit trail. The analyst should also know that investigations have a cost, and that the cost is usually borne by the bank that caused the problem. If the sending bank made an error, it bears the cost of the investigation. If the beneficiary bank made an error, it bears the cost. If the customer made an error, the customer may be charged a fee for the investigation. The analyst must include the cost allocation in the requirements, and must ensure that the customer is told upfront whether an investigation will be charged for. A customer who is charged for an investigation into a bank error will complain, and rightly so. A customer who is told upfront that an investigation into their own error will cost a fee will accept it.
An investigation is the process of finding out what happened to a payment that has not arrived, has arrived for the wrong amount, or has arrived with the wrong information, and it is the most common exception task in cross border operations. The investigation starts with the customer reporting the problem, and the operations team then traces the payment using the UETR, the gpi tracker, the SWIFT messages, and the correspondent account statements. The investigation can take days, because each bank must respond, and because the banks are in different time zones and speak different languages. The analyst must design the investigation process to be systematic: log the query, trace the payment, contact the right bank, record the response, and update the customer at each step.
Reason codes are the standardised language of investigations, and the analyst must know the most important ones. In the SWIFT system, return and reject reason codes include AC01 for incorrect account number, AC04 for closed account, AC06 for blocked account, AM05 for duplication, BE05 for unknown beneficiary, and MD07 for end customer deceased. In the ISO 20022 system, the same reasons are carried in the pacs.002 and pacs.004 messages with a code and a description, and in the camt.029 resolution of investigation. In the gpi tracker, the status codes show whether the payment is accepted, in progress, credited, rejected or returned. The analyst must be able to read all three sets of codes and to translate them into plain language for the customer.
The investigation message flow in ISO 20022 is worth knowing in detail. When a bank needs to investigate a payment, it can send a camt.056 cancellation request, if it wants the payment returned, or it can send a query using an MT199 or MT999 free format message. The receiving bank responds with a camt.029 resolution of investigation, which says what was found and what action was taken. The camt.029 carries the original UETR, the status, and a description of the resolution. The analyst must ensure that the system can send and receive camt.056 and camt.029, that it links them to the original payment by UETR, and that it records the outcome. A system that cannot process a camt.029 cannot close an investigation, and the investigation will sit open indefinitely.
If the investigation finds that the account number was wrong because the customer copied it from an old invoice, the fix is to update the invoice template. If it finds that the payment was delayed because the intermediary bank stopped it for a compliance query, the fix is to improve the originator information. If it finds that the payment was returned because the beneficiary bank had changed its BIC, the fix is to update the bank directory. The analyst should review the investigation data regularly, should identify the repeat causes, and should propose the fixes. An investigation that ends with the payment found but no lesson learned is a missed opportunity, and the analyst who closes the loop is the analyst who improves the product.
The most common investigation scenarios, and the ones the analyst must design for, are: the payment has not arrived, the payment arrived for the wrong amount, the payment arrived with the wrong reference, the payment was returned but the customer does not know why, and the payment was sent twice. A payment that has not arrived is traced through the gpi tracker and the correspondent statements. A payment that arrived for the wrong amount is checked against the charge deductions at each bank. A payment that arrived with the wrong reference is matched by UETR and amount. A payment that was sent twice is checked for duplication, reason code AM05, and the duplicate is recalled. The analyst should write a runbook for each scenario, with the steps, the messages to send, and the expected timeline.
The investigation service level is part of the product, and the analyst must specify it. The first response to the customer should be within two business days, with an update on what has been found so far. The investigation should be resolved within fifteen business days, with regular updates in between. If the investigation is not resolved within fifteen days, it should be escalated to a senior manager, and the customer should be told. The analyst must ensure that the system tracks the age of each investigation, that it alerts when an investigation is approaching its deadline, and that it reports the average resolution time by reason and by corridor. An investigation that is not tracked is an investigation that will be forgotten, and a forgotten investigation is a customer who will leave.
There is a specific investigation that deserves attention: the investigation into a payment that the beneficiary says never arrived, but the tracker says was credited. This is usually a case where the payment was credited to the wrong account, or where the beneficiary is looking at the wrong account, or where the credit is shown under a different reference. The analyst must design the investigation to check the beneficiary account, the value date, and the reference, and to obtain a confirmation from the beneficiary bank that the credit was made. The confirmation should be in writing, with the account number, the amount, and the value date, so that the customer can be shown proof. A verbal confirmation is not enough, because the customer needs evidence, and the bank needs an audit trail.
The analyst should also know that investigations have a cost, and that the cost is usually borne by the bank that caused the problem. If the sending bank made an error, it bears the cost of the investigation. If the beneficiary bank made an error, it bears the cost. If the customer made an error, the customer may be charged a fee for the investigation. The analyst must include the cost allocation in the requirements, and must ensure that the customer is told upfront whether an investigation will be charged for. A customer who is charged for an investigation into a bank error will complain, and rightly so. A customer who is told upfront that an investigation into their own error will cost a fee will accept it.
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.