Payments Academy
Duplicate payment investigation 1 NOW Duplicate payment investigation 2 Retry dilemma 3 Parties in the duplication 4 Worked 5 Return and root cause 6 Investigation data A duplicate payment investigation starts when the same payment has been sent twice Step 1 of 6 Duplicate payment investigation 1 NOW Duplicate payment investigation 2 Retry dilemma 3 Parties in the duplication 4 Worked 5 Return and root cause 6 Investigation data A duplicate payment investigation starts when the same payment has been sent twice Step 1 of 6
The retry dilemma 1 Duplicate payment investigation 2 NOW Retry dilemma 3 Parties in the duplication 4 Worked 5 Return and root cause 6 Investigation data Why duplicates happen is that a payment system must choose between two risks, and it usually chooses the wrong one under pressure. Step 2 of 6 The retry dilemma 1 Duplicate payment investigation 2 NOW Retry dilemma 3 Parties in the duplication 4 Worked 5 Return and root cause 6 Investigation data Why duplicates happen is that a payment system must choose between two risks, and it usually chooses the wrong one under pressure. Step 2 of 6
Parties in the duplication 1 Duplicate payment investigation 2 Retry dilemma 3 NOW Parties in the duplication 4 Worked 5 Return and root cause 6 Investigation data The parties are the debtor bank, which sent the duplicate, the creditor bank, which credited both payments, the beneficiary, who received twice the amount, Step 3 of 6 Parties in the duplication 1 Duplicate payment investigation 2 Retry dilemma 3 NOW Parties in the duplication 4 Worked 5 Return and root cause 6 Investigation data The parties are the debtor bank, which sent the duplicate, the creditor bank, which credited both payments, the beneficiary, who received twice the amount, Step 3 of 6
Worked example of a duplicate 1 Duplicate payment investigation 2 Retry dilemma 3 Parties in the duplication 4 NOW Worked 5 Return and root cause 6 Investigation data How the investigation runs is shown by a worked example. Step 4 of 6 Worked example of a duplicate 1 Duplicate payment investigation 2 Retry dilemma 3 Parties in the duplication 4 NOW Worked 5 Return and root cause 6 Investigation data How the investigation runs is shown by a worked example. Step 4 of 6
Return and root cause 1 Duplicate payment investigation 2 Retry dilemma 3 Parties in the duplication 4 Worked 5 NOW Return and root cause 6 Investigation data On success the duplicate is returned, the beneficiary is paid once, the debtor is debited once, and the case closes with the root cause recorded, so the retry is fixed. Step 5 of 6 Return and root cause 1 Duplicate payment investigation 2 Retry dilemma 3 Parties in the duplication 4 Worked 5 NOW Return and root cause 6 Investigation data On success the duplicate is returned, the beneficiary is paid once, the debtor is debited once, and the case closes with the root cause recorded, so the retry is fixed. Step 5 of 6
Investigation data 1 Duplicate payment investigation 2 Retry dilemma 3 Parties in the duplication 4 Worked 5 Return and root cause 6 NOW Investigation data The data the investigation needs is the identifiers of both payments Step 6 of 6 Investigation data 1 Duplicate payment investigation 2 Retry dilemma 3 Parties in the duplication 4 Worked 5 Return and root cause 6 NOW Investigation data The data the investigation needs is the identifiers of both payments Step 6 of 6

Exception workflow, step by step.

0:00 / 6:32 Step 1 of 6

Investigation: the duplicate payment

Cross-border investigations, Lesson 7 of 10, Narration 6:32, D06 Cross-border payments

ReconciliationISO 20022pacs.002

What you will learn

Your objective. By the end of this lesson, you will be able to explain investigation: the duplicate payment. A duplicate payment investigation starts when the same payment has been sent twice, and the beneficiary has been paid twice, or the debtor has been debited twice, and the bank must recover one of the payments without.

Why it matters. Takeaway: retries must reuse the same identifier so the receiver can deduplicate, and duplicates must be caught by reconciliation on day one.

Chapter objective: Finding a missing MT103, a missing MT202 COV, and every other cross-border failure

Key learning points

  • Duplicate payment investigation
  • The retry dilemma
  • Parties in the duplication
  • Worked example of a duplicate
  • Return and root cause
  • Investigation data

Key terms

Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.

ISO 20022: An international standard for financial messaging that defines XML message formats for payments, securities and trade.

pacs.002: An ISO 20022 message one financial institution sends to another to report the status of a payment instruction.

Exception investigation workflow showing Investigation: the duplicate payment.

Practise this lesson

Exercise

A company in Berlin pays a supplier in Madrid EUR 38,000 on Monday at 10:00, gets no confirmation, and sends it again at 10:30 with a new reference. Work out the duplicate investigation.

Use the identifiers to prove the two payments are for the same obligation, then camt.056 to request the return of the second payment.

  1. What to do. State when the duplicate is returned and what caused it.

Correct result. The Madrid bank credits the supplier twice, the supplier reports it Tuesday, the Berlin bank sends camt.056, the supplier agrees, and EUR 38,000 is returned by pacs.004 on Wednesday; the cause was a retry with a new reference.

Why. A duplicate is a retry that used a new identifier, and the fix is to reuse the identifier.

Check your understanding

Practice question

Why does a retry with a new identifier create a duplicate payment?

Takeaway and next step

What to remember

Takeaway: retries must reuse the same identifier so the receiver can deduplicate, and duplicates must be caught by reconciliation on day one.

Follow EUR 38,000 through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "Investigation: the charges discrepancy".

Transcript and full text

Show transcript

A duplicate payment investigation starts when the same payment has been sent twice, and the beneficiary has been paid twice, or the debtor has been debited twice, and the bank must recover one of the payments without disturbing the other. A duplicate is usually caused by a retry: the sender did not receive a confirmation, assumed the payment had failed, and sent it again, or a system resent a payment after a timeout, and the receiving bank processed both copies because they carried different identifiers. Source: SWIFT CBPR+ usage guidelines; ISO 20022 pacs.002 and pacs.004 definitions; Bank for International Settlements, payment system glossaries. Why duplicates happen is that a payment system must choose between two risks, and it usually chooses the wrong one under pressure. If the system does not retry, a payment that was lost stays lost, and the customer complains. If the system does retry, a payment that was actually sent may be sent twice, and the beneficiary is paid twice. The correct design is to retry with the same identifier, so the receiving bank can deduplicate, but many systems retry with a new identifier, so the receiving bank sees two different payments and processes both. The duplicate is therefore a design failure as much as an operational one, and the investigation must find whether the retry used the same identifier, because that decides whether the receiving bank could have prevented it. The parties are the debtor bank, which sent the duplicate, the creditor bank, which credited both payments, the beneficiary, who received twice the amount, and the intermediary banks, which forwarded both. The enquiry messages are pacs.028 to ask the status of each payment, and camt.056 to request a return of the duplicate, and in the legacy MT world MT192 to request cancellation and MT199 to enquire. The answer to the camt.056 is camt.029, which states whether the return was accepted or rejected, and the beneficiary agreement is needed for a return after the money has been credited, which is why a duplicate that is found quickly, before the beneficiary spends the money, is far easier to recover than one found a week later. How the investigation runs is shown by a worked example. The Madrid bank credits the supplier EUR 38,000 twice, once at 11:00 and once at 11:30, and the supplier, who is honest, tells the Berlin company on Tuesday. The Berlin bank sends camt.056 to the Madrid bank on Tuesday, asking for the return of the second payment, the Madrid bank asks the supplier, the supplier agrees, and the Madrid bank returns EUR 38,000 by pacs.004. The total elapsed time was two days, the supplier was paid correctly once, and the case closes with a note that the duplicate was caused by a retry with a new reference, and the Berlin bank fixes its retry to reuse the same identifier. On success the duplicate is returned, the beneficiary is paid once, the debtor is debited once, and the case closes with the root cause recorded, so the retry is fixed. On failure the beneficiary has already spent the duplicate, or refuses to return it, and then the recovery is a legal claim, not a payment message, and the bank may have to absorb the loss if the error was its own, because the customer will not accept that a bank error has cost them EUR 38,000. The most expensive failure is a duplicate that is never detected, because the beneficiary says nothing, and the debtor discovers it at month end, by which time the money is gone and the recovery is a dispute, not a return. The data the investigation needs is the identifiers of both payments, the UETRs, the amounts, the value dates, and the references, and the proof that the two payments are for the same obligation. The identifier is the field that matters most, while two payments with different UETRs are two payments that the receiving bank could not have known were the same, and the investigation must say which one it is. A BA must require retries to reuse the same identifier, must specify the deduplication check at the receiving bank, and must specify the duplicate detection in reconciliation, because a duplicate that is caught by reconciliation on day one is a return, while a duplicate caught at month end is a dispute. Edge cases show the depth. A duplicate where the two payments went through different routes, one by cover and one by serial, must be traced through both routes, and the investigation must not assume they are the same payment just because the amounts match. A duplicate where the beneficiary has already used the money to pay its own supplier cannot be returned in full, and the recovery may be a partial return, or a commercial agreement to offset the next invoice. A duplicate in an instant payment system is harder, because the payment is final in seconds, and the return must be requested immediately, before the beneficiary spends it, so the detection must be in real time, not at end of day. The effect on the bank is a loss until the duplicate is recovered, and a root cause that must be fixed, because a retry that creates duplicates will create them again. The effect on the customer is a supplier paid twice, and a debtor debited twice, and the customer will blame the bank even if the customer sent the duplicate themselves, because the bank should have prevented it. The effect on operations is a duplicate detection control, in reconciliation and in real time, and a queue of duplicates that must be worked the same day, because a duplicate found on day one is a return, and a duplicate found on day ten is a legal claim. What a BA, PO or SME must understand is that a duplicate is a retry that used a new identifier, and the fix is to reuse the identifier and to deduplicate on receipt. The requirement must name the retry rule, the deduplication check, the duplicate detection in reconciliation, and the camt.056 return flow. The test is to send one payment twice, with the same identifier and with a different identifier, and to check that the first is deduplicated and the second is caught by reconciliation, because if neither is caught, the control does not exist. Further reading: SWIFT CBPR+ usage guidelines; ISO 20022 camt.056 and pacs.004 definitions. Last reviewed 7 November 2026.

A duplicate payment investigation starts when the same payment has been sent twice, and the beneficiary has been paid twice, or the debtor has been debited twice, and the bank must recover one of the payments without disturbing the other. A duplicate is usually caused by a retry: the sender did not receive a confirmation, assumed the payment had failed, and sent it again, or a system resent a payment after a timeout, and the receiving bank processed both copies because they carried different identifiers. Source: SWIFT CBPR+ usage guidelines; ISO 20022 pacs.002 and pacs.004 definitions; Bank for International Settlements, payment system glossaries.

Why duplicates happen is that a payment system must choose between two risks, and it usually chooses the wrong one under pressure. If the system does not retry, a payment that was lost stays lost, and the customer complains. If the system does retry, a payment that was actually sent may be sent twice, and the beneficiary is paid twice. The correct design is to retry with the same identifier, so the receiving bank can deduplicate, but many systems retry with a new identifier, so the receiving bank sees two different payments and processes both. The duplicate is therefore a design failure as much as an operational one, and the investigation must find whether the retry used the same identifier, because that decides whether the receiving bank could have prevented it.

The parties are the debtor bank, which sent the duplicate, the creditor bank, which credited both payments, the beneficiary, who received twice the amount, and the intermediary banks, which forwarded both. The enquiry messages are pacs.028 to ask the status of each payment, and camt.056 to request a return of the duplicate, and in the legacy MT world MT192 to request cancellation and MT199 to enquire. The answer to the camt.056 is camt.029, which states whether the return was accepted or rejected, and the beneficiary agreement is needed for a return after the money has been credited, which is why a duplicate that is found quickly, before the beneficiary spends the money, is far easier to recover than one found a week later.

How the investigation runs is shown by a worked example. The Madrid bank credits the supplier EUR 38,000 twice, once at 11:00 and once at 11:30, and the supplier, who is honest, tells the Berlin company on Tuesday. The Berlin bank sends camt.056 to the Madrid bank on Tuesday, asking for the return of the second payment, the Madrid bank asks the supplier, the supplier agrees, and the Madrid bank returns EUR 38,000 by pacs.004. The total elapsed time was two days, the supplier was paid correctly once, and the case closes with a note that the duplicate was caused by a retry with a new reference, and the Berlin bank fixes its retry to reuse the same identifier.

On success the duplicate is returned, the beneficiary is paid once, the debtor is debited once, and the case closes with the root cause recorded, so the retry is fixed. On failure the beneficiary has already spent the duplicate, or refuses to return it, and then the recovery is a legal claim, not a payment message, and the bank may have to absorb the loss if the error was its own, because the customer will not accept that a bank error has cost them EUR 38,000. The most expensive failure is a duplicate that is never detected, because the beneficiary says nothing, and the debtor discovers it at month end, by which time the money is gone and the recovery is a dispute, not a return.

The data the investigation needs is the identifiers of both payments, the UETRs, the amounts, the value dates, and the references, and the proof that the two payments are for the same obligation. The identifier is the field that matters most, while two payments with different UETRs are two payments that the receiving bank could not have known were the same, and the investigation must say which one it is. A BA must require retries to reuse the same identifier, must specify the deduplication check at the receiving bank, and must specify the duplicate detection in reconciliation, because a duplicate that is caught by reconciliation on day one is a return, while a duplicate caught at month end is a dispute.

Edge cases show the depth. A duplicate where the two payments went through different routes, one by cover and one by serial, must be traced through both routes, and the investigation must not assume they are the same payment just because the amounts match. A duplicate where the beneficiary has already used the money to pay its own supplier cannot be returned in full, and the recovery may be a partial return, or a commercial agreement to offset the next invoice. A duplicate in an instant payment system is harder, because the payment is final in seconds, and the return must be requested immediately, before the beneficiary spends it, so the detection must be in real time, not at end of day.

The effect on the bank is a loss until the duplicate is recovered, and a root cause that must be fixed, because a retry that creates duplicates will create them again. The effect on the customer is a supplier paid twice, and a debtor debited twice, and the customer will blame the bank even if the customer sent the duplicate themselves, because the bank should have prevented it. The effect on operations is a duplicate detection control, in reconciliation and in real time, and a queue of duplicates that must be worked the same day, because a duplicate found on day one is a return, and a duplicate found on day ten is a legal claim.

What a BA, PO or SME must understand is that a duplicate is a retry that used a new identifier, and the fix is to reuse the identifier and to deduplicate on receipt. The requirement must name the retry rule, the deduplication check, the duplicate detection in reconciliation, and the camt.056 return flow. The test is to send one payment twice, with the same identifier and with a different identifier, and to check that the first is deduplicated and the second is caught by reconciliation, because if neither is caught, the control does not exist. Further reading: SWIFT CBPR+ usage guidelines; ISO 20022 camt.056 and pacs.004 definitions. Last reviewed 7 November 2026.

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.