Misdirected Payments: How to Prevent Sending Money to the Wrong IBAN

Misdirected payments occur when money is sent to the wrong bank account — either because the sender entered an incorrect IBAN, because bank details were changed by fraud, or because a system error routed the payment to a stale account. Once the payment clears, recovering the funds depends entirely on the cooperation of the beneficiary bank and the account holder. This guide covers the scale of the problem, the most common root causes, and a layered prevention framework for finance teams and payment system operators.

How Common Are Misdirected Payments?

Misdirected payments are significantly underreported because many are resolved quietly between banks. The data that exists points to a substantial problem:

• UK Finance reported that in 2023, UK banks processed over 200,000 reported misdirected payment cases under the Contingent Reimbursement Model (CRM) code, representing losses exceeding £340 million.
• The European Banking Authority (EBA) estimates that 2–4% of SEPA Credit Transfers contain a discrepancy between the stated beneficiary name and the IBAN — not all of these are fraud, but all represent a potential misdirection risk.
• In B2B contexts, a single misdirected payment can represent hundreds of thousands of euros. The median value of a misdirected corporate payment in the EBA's 2023 review was €47,000 — significantly higher than the €800 median for consumer payments.

The Five Root Causes of Misdirected Payments

Understanding why misdirected payments happen is prerequisite to preventing them. Most cases fall into one of five categories:

1. Manual transcription error: The payer copies an IBAN by hand — from a printed invoice, a verbal communication, or a screenshot — and introduces a typo. A single transposed digit produces an IBAN that may pass MOD-97 (if the check digits still work) or may fail (if the check digit catches the error). Either way, the payment goes somewhere the sender did not intend.
2. Stale bank details in ERP or supplier master: The supplier changed banks six months ago and notified the buyer, but the ERP record was never updated. The payment goes to the old account, which may be closed (leading to a return) or may still be open under the old bank (leading to a difficult recovery).
3. IBAN spoofing / BEC fraud: An attacker substitutes the legitimate IBAN with a fraudulent one. The payer believes they are paying the correct supplier. This is covered in more depth in the IBAN spoofing guide.
4. System integration error: A data migration, API mapping bug, or configuration error routes a payment to the wrong field in a payment file. IBAN fields are truncated, padded, or concatenated incorrectly — a problem common when migrating from legacy domestic account formats to IBAN.
5. Similar IBAN lookup collision: In supplier databases with thousands of entries, two IBANs that differ by only one or two characters can be accidentally conflated by search or autocomplete functions that do a fuzzy match rather than an exact match.

What Happens After a Misdirected Payment?

The recovery process for misdirected payments depends on the payment network and the jurisdiction:

• SEPA Credit Transfer: The payer's bank can submit a recall request via the SEPA recall mechanism (the Recall/R-transaction in the SEPA rulebook). The beneficiary bank has 15 business days to respond. If the beneficiary consents to return the funds, the money is returned. If not, the payer must pursue a civil claim.
• SEPA Instant: The payment is irrevocable once processed. There is no standard recall mechanism for instant payments. SWIFT gpi's instant recall is supported by some banks but not universally.
• SWIFT wire: SWIFT gpi's payment cancellation request (gCCT) can be used. The beneficiary bank has up to 48 hours to respond. Cross-border recovery involving multiple correspondent banks can take weeks.
• Fraud cases (BEC/spoofing): Many jurisdictions have mandatory reimbursement rules for APP fraud. In the UK, the Payment Systems Regulator mandated that banks must reimburse APP fraud victims up to £85,000 from October 2024. EU member states are implementing equivalent rules under PSD3.

The practical lesson: recovery is uncertain and time-consuming. Prevention is the correct investment.

Prevention Framework: Five Layers

Layer 1 — Validate at Data Entry

Every IBAN that enters your system — from a supplier submission form, an invoice, or an API payload — must be validated immediately at the point of entry. Validation means:

• Format check: valid country code, alphanumeric only
• Length check: correct length for the stated country
• MOD-97 check: check digits consistent with the IBAN body
• BIC lookup: bank embedded in the IBAN is a registered institution

The ibanchecker.cash IBAN checker performs all four checks in real time. For automated validation at data entry, integrate the ibanchecker.cash API into your supplier portal or ERP intake form. Reject IBANs that fail any check before they reach your payment queue.

Layer 2 — Supplier Master Data Hygiene

A validated IBAN that was correct at onboarding can become misdirected if the supplier changes banks and your record is not updated. Establish a supplier master data process:

• Re-validate all supplier IBANs on a quarterly schedule. Run the full supplier list through the bulk IBAN checker — any IBAN that now returns a different bank name than when first recorded requires human review.
• Flag IBANs for accounts that have been inactive for more than 12 months. Dormant accounts are frequently closed, which will cause a payment to be returned — but not always immediately, and not always with clear reason codes.
• Require suppliers to re-confirm bank details annually via a secure channel (authenticated portal, not email).

Layer 3 — Payment Instruction Verification

Before any payment instruction is dispatched, verify that the IBAN in the instruction matches the IBAN in your validated supplier master record — character for character, not as a fuzzy match. Build this comparison into your payment approval workflow:

• Exact IBAN match required between payment instruction and supplier master record. Any discrepancy halts the payment and routes it to a review queue.
• The approver sees the bank name alongside the IBAN, not just the raw string. A bank name that is unfamiliar or geographically inconsistent should trigger scrutiny.
• For payments above a threshold, require the second approver to independently look up the supplier IBAN in the master record — not just to click "approve" on the submitted instruction.

Layer 4 — ERP and Integration Validation

System integration errors produce misdirected payments at scale — a single misconfigured field mapping can misdirect hundreds of payments before anyone notices. Safeguards:

• Validate IBAN fields in your payment file generation logic. If your ERP exports a SEPA XML pain.001 file, validate every <IBAN> element before submitting the file to the bank.
• Run integration tests that include deliberately malformed IBANs. Your pipeline should reject the file, not silently strip the invalid IBAN or replace it with a null value.
• After any migration or mapping change, run a sample payment batch with known test IBANs before enabling production traffic.

Layer 5 — Confirmation of Payee (CoP / VoP)

For eurozone payments, the EU Instant Payments Regulation (2024/886) mandates Verification of Payee (VoP) for euro instant credit transfers from January 2025. For UK payments, CoP has been live since 2020. Both systems check that the name provided by the payer matches the name registered to the IBAN at the receiving bank — before the payment is sent.

CoP/VoP is the most powerful misdirection prevention available for covered payment types. For payment types not covered by CoP/VoP, the four layers above are the primary controls. See the PSD2 payee verification guide for a detailed breakdown of how CoP and VoP work and which payment types they cover.

ERP Integration for Automated Prevention

Most large ERP systems (SAP, Oracle, Microsoft Dynamics) allow custom validation hooks at the vendor master record level. The integration pattern:

1. On vendor record creation or IBAN field update: call the ibanchecker.cash API with the submitted IBAN.
2. Store the returned bank name, BIC, and validation timestamp alongside the IBAN in the vendor record.
3. At payment run: compare the bank name in the payment instruction against the stored value. If they differ, block the payment and log the discrepancy.
4. Surface the bank name to the payment approver in the approval screen — not just the IBAN string.

The API returns results in under 100 ms and processes up to 100 IBANs per bulk call — fast enough for real-time vendor master validation and batch pre-payment checks alike. No IBAN data is stored by the API — compliant with GDPR data minimization requirements.

Last updated: June 2026