Unexplained Nostro Debit and a Duplicate Redemption

The pattern strongly suggests a duplicate payment. Two payments were sent with the same reference, the bank statement shows a USD 2.4m debit, the ledger shows only one payment, and the client confirms it received the redemption twice. The reconciliation system matched on amount and value date rather than end-to-end reference, so the duplicate was not identified at release.

Immediate actions:

1. Do not send any further payments on the same reference.
2. Contact the correspondent bank immediately and request a recall of the duplicate debit, quoting the bank reference, payment date, amount and beneficiary.
3. Ask the client to return the duplicate amount voluntarily and confirm in writing. If the client refuses, escalate to legal.
4. Check the available USD balance before allowing the FX settlement to proceed. If the duplicate has already reduced the balance, the FX settlement may create an overdraft. Do not stop the FX trade unless funding is genuinely at risk; instead arrange intraday liquidity or a temporary overdraft.
5. Record the event in the operational risk system and notify compliance and finance.
6. Preserve the payment files, audit trail and reconciliation evidence.

The FX settlement should not be stopped automatically, because stopping a valid settlement can create a separate fail. The priority is to recover the duplicate and manage liquidity.

Several weaknesses are exposed:

• Matching logic: the system matches on amount and value date, not on a unique end-to-end reference. Two payments with the same amount and date can therefore match to one ledger entry.
• No duplicate payment screening at the point of release. A rule blocking a second payment with the same beneficiary, amount and reference within a defined window would have caught it.
• No intraday reconciliation. The duplicate was found only on Monday morning; a same-day bank statement or real-time balance check might have caught it on Friday.
• Possible manual release without four-eyes. The file should have been checked against the authorised payment instruction.
• The ledger and bank statement cut-offs may not have been aligned, so the second payment appeared as an unexplained debit rather than a duplicate.
• The reconciliation break was not aged or escalated over the weekend.

The control owner should test a sample of payments for unique references and duplicate detection, and confirm that reconciliation covers all payment rails.

Escalation: notify the head of operations, finance, compliance and the operational risk committee. If the client is regulated or the amount is material, consider whether the firm's operational risk event policy requires external notification. Record the gross loss, any recovery and the net loss.

Remediation:

• Implement a unique end-to-end payment reference for every payment and require the bank to quote it.
• Add duplicate detection at the payment gateway and in the reconciliation engine.
• Change reconciliation matching to reference-first, amount-second.
• Introduce intraday balance and exception reporting for large payments.
• Require four-eyes release for payments above a threshold.
• Reconcile the client money and redemption account daily and investigate any unexplained debit the same day.
• Add a recall procedure with the correspondent bank, including contact details and template letters.
• Test the new controls for three months and report to the risk committee.

The root cause should be classified as a failed control, not simply human error, because the matching design allowed the duplicate to pass.