Visit Website →
← Back to blog

Catch Fake Bank Details: Risk Based Verification for AP Teams

September 7, 2026
Catch Fake Bank Details: Risk Based Verification for AP Teams

Risk-based verification means running a real-time check that matches a payee's name against their IBAN before a payment leaves your system, then routing the result through fixed rules instead of manual guesswork. The action is simple: turn on name+IBAN checking at the point of payment, and build a triage rule for every outcome the check returns. Everything else in this guide explains how to make that work without slowing down your payment runs.

TL;DR:

  • Running real-time name and IBAN checks helps detect invoice redirection fraud by verifying if the payee name matches the account at the moment of payment.
  • Banks' tolerance settings significantly affect results, with strict matching increasing manual reviews for close matches and lenient settings risking overlooked mismatches.
  • It is crucial to re-verify payment details whenever account information changes and schedule bulk re-checks before large payment runs to avoid delays.
  • Log all verification outcomes and decisions, including timestamps, responses, and human reviews, to ensure audit readiness and transparency.
  • Prioritize high-value suppliers for initial verification efforts, confirm account details offline for close matches, and clearly communicate process changes to suppliers beforehand.
Vopify
Verify Payee Details Before Payment
Vopify checks a payee’s name against their IBAN in real time, helping AP teams reduce misdirected payments and fraud risk.
Explore Vopify

Table of Contents

What Is Risk-Based Verification and How Does the Check Work?

A name+IBAN check, often called Verification of Payee (VoP), works through a request and response cycle that takes seconds, not days. Your system sends the payee's IBAN and the name on your invoice or supplier record. That request routes through a directory to the bank that actually holds the account, which compares the submitted name against its own records and sends back a structured answer.

The EPC's VOP scheme rulebook defines four possible outcomes, each with its own operational meaning:

  • Match — the name and IBAN line up exactly. Safe to proceed automatically.
  • Close match — the responding bank returns a matchedName that's similar but not identical (a missing middle name, a trading name versus a legal name). This needs a human look before the payment clears.
  • No match — the name does not correspond to the account holder on file. Stop the payment and investigate.
  • Verification not possible — the responding bank can't confirm either way, often because of a system outage or a bank that hasn't fully implemented the scheme.

The check happens at the account-holding bank because that's the only party with the actual account record, according to Digiteal's breakdown of the VoP process. That's also why tolerance settings matter so much: a bank that does strict character-for-character matching will flag far more "close match" results than one that tokenizes names and allows for abbreviations, which means two banks can return different verdicts for the same real-world account.

Why Accounts Payable Teams Can't Skip This Check

Invoice-redirection fraud almost always follows the same pattern: a criminal intercepts or spoofs an invoice, swaps the bank details, and waits for accounts payable to pay the fake account before anyone notices. A real-time name+IBAN check catches this at the exact moment it would otherwise succeed, because the payee name on the fraudulent account rarely matches the supplier's registered name.

Invoice fraud interrupted by account verification

The trade-off is operational noise. Supplier master-data that doesn't exactly match what's on file at the bank generates close-match results that need manual review, and research on VoP's impact on finance teams shows this friction usually traces back to outdated or informal name entries rather than actual fraud.

There's also a liability dimension. Under the Instant Payments Regulation, how a payer's PSP displays and handles a mismatch affects who bears responsibility if a payment goes to the wrong account. Skipping the check, or ignoring a no-match warning, shifts risk squarely onto your organization.

Pro Tip: Run a one-time audit of your top 50 suppliers by payment volume and compare the name on file against their legal registration. You'll usually find the close-match noise before it finds you.

How to Build a Risk-Based Verification Workflow

Getting this right is less about the technology and more about sequencing. Here's a workable order of operations for rolling out real-time name+IBAN checks.

  1. Lock down the account-holder name field at onboarding. Capture the exact legal name as it appears on the bank account, not a trading name or an abbreviation pulled from an email signature.
  2. Validate IBAN structure before submission. Catch typos and formatting errors (wrong country code, wrong check digits) before they ever reach a verification request.
  3. Choose your integration mode based on volume. A dashboard works for occasional single checks. Bulk CSV upload handles supplier onboarding waves or pre-payment sweeps across your whole vendor file. API access, when available for high-volume programmatic use, suits teams verifying continuously as part of an ERP workflow.
  4. Re-verify on every bank detail change. A supplier changing accounts is one of the most common fraud vectors, so treat any update as a new check, not an edit to trust blindly.
  5. Apply decision rules by result type, and don't leave any outcome undefined:
    • Match: proceed automatically, no human touch needed.
    • Close match: route to a reviewer who checks the matchedName against the invoice and supplier record before releasing payment.
    • No match: block the payment, flag the supplier record, and open an investigation.
    • Verification not possible: log it, allow the payer to proceed at their own documented risk, but watch for repeat occurrences from the same counterparty bank.

Timing matters as much as the rules themselves. Real-time checks work best when they happen as close to data entry as possible, meaning the onboarding form or the ERP supplier-edit screen, not a batch job that runs after the payment file is already built. For high-value payment runs, add a bulk re-check of the whole batch a day before execution, catching any supplier that changed details since the last individual verification.

Pro Tip: If your team processes payments in batches, schedule the bulk re-check the night before the run, not the morning of. It gives you a buffer to resolve close matches without holding up payroll or supplier deadlines.

Response time expectations matter for scheduling. Checks that run against live payment networks typically return in under two seconds per record, which means even a bulk file of several thousand suppliers finishes well within a normal processing window.

Running an Audit-Ready Verification Program

A verification program only holds up under scrutiny if you can show what happened, when, and why. That means treating logging as a first-class part of the workflow, not an afterthought bolted on after an incident.

Record these fields for every single check:

  • The request ID and timestamp
  • The submitted name and IBAN
  • The matchedName returned for close-match results, per the EPC's API specification
  • The result code (Match, Close match, No match, Not possible)
  • The human decision and who made it, if the result required review
Metric to monitorWhy it matters
No-match rate by supplier segmentSpikes often signal fraud attempts or systemic data drift
Close-match rateHigh rates usually point to master-data quality, not fraud
Verification-not-possible frequencyRecurring NOAP from one counterparty bank may signal a connectivity issue on their end
Average response latencySlower responses can bottleneck bulk payment runs

Write down your name-matching tolerance policy in plain language, not just in configuration settings. Documenting how you handle abbreviations, transliteration, and edit distance gives you something concrete to point to if a payment dispute ever reaches an auditor or regulator. For no-match results, escalate to a hold, confirm the account out-of-band with the supplier through a channel other than email, and run it against your sanctions and AML screening before releasing any funds.

What I'd Tell a Team Starting From Zero

Start with your highest-risk, highest-value suppliers, not your whole vendor file at once. Clean their master data first: exact legal names, current IBANs, no shortcuts. That single move removes most of the close-match noise before it ever reaches a reviewer.

What I'd Tell a Team Starting From Zero — overview diagram

Calibrate your tolerance settings deliberately. Too strict, and you'll bury your team in manual reviews for suppliers who are perfectly legitimate. Too loose, and you'll wave through the mismatches you built this whole program to catch.

Tell your suppliers the process is changing before you flip the switch. A short heads-up about exact-name requirements saves a dozen confused calls later.

— David

Verify Payments Before They Leave, Not After

A Verification of Payee service runs the exact check this guide describes: submit a name and IBAN, get a real-time match result back on supported networks in under two seconds. You don't sign a contract or wait on a lengthy setup process to start using it.

Vopify

Finance and accounts payable teams use a VoP service three ways: single checks for one-off supplier or customer verifications through a dashboard, bulk CSV upload when onboarding a batch of vendors or sweeping a whole supplier file before a big payment run, and API access for teams that want verification built directly into their ERP or payment workflow. Coverage spans SEPA countries across the Eurozone, plus several other countries in Asia, so most cross-border AP teams can run the same check regardless of where a supplier banks. Check whether your payment corridors are covered on the coverage page, or upload a sample supplier CSV through the IBAN verification tool to see how many close matches turn up in your own vendor file before you commit to anything.

Where to Go Deeper

The rules and mechanics behind name+IBAN verification are laid out in a handful of primary documents worth bookmarking:

Sources