Penny Drop, VoP, Open Banking & 4 More: The Real Bank Account Verification Methods, Compared

Seven different methods exist for verifying a bank account before money moves. No single one covers every country, every risk event, or every buyer type. The teams that get verification right don't pick one method — they layer them by destination and decision point. This guide explains what each method actually does, where it works, where it fails, and how to combine them into a workflow that holds up under audit.

The question every payment-handling team eventually asks: what's the right way to verify a bank account? The honest answer is that there is no single right way — there are seven different ways, each evolved for a specific banking infrastructure, regulatory regime, and risk tolerance. Penny drop works brilliantly in India and breaks the moment you try to use it cross-border. EU Verification of Payee is mandatory across the SEPA zone and useless outside it. US ACH validation has been transformed by the 2026 Nacha rules. Open Banking gives the deepest data but requires customer consent — which doesn't work when you're paying a vendor.

This article compares the seven methods that any team handling payments, vendor onboarding, or KYB workflows will encounter. The framing throughout is operational: which method to use when, what each one costs in latency and money, and where each one fails. The closing section explains how they layer into a single workflow rather than competing as alternatives.

One pattern shapes the entire article — methods are not interchangeable. A team using only penny drop is exposed in 40 countries where penny drop can't reach. A team using only VoP is exposed in every market outside the EU. The strongest verification architecture combines methods by jurisdiction and risk event, with registry-sourced entity verification as the universal backstop that covers gaps the others leave.

The 7 methods at a glance

Before the deep-dives, the comparison table. Most operational decisions come back to which row matches your destination country and your risk tolerance.

The most important pattern in that table: only Method 7 (registry) covers the full breadth of countries. Methods 1–5 are powerful but jurisdiction-bound. Method 6 requires customer consent, which makes it unsuitable for verifying third parties like vendors and suppliers.

1. Penny drop

Penny drop is the original bank account verification method, still the dominant approach across India and used by Trustpair and several other vendor-verification platforms as one input among many. The mechanic is simple: send a token amount (typically ₹1, or $0.01 equivalent) to the account being verified. If the deposit credits successfully, the account exists and is able to receive funds. Most penny-drop implementations also return the registered account holder name from the receiving bank's response, enabling a name match.

Where penny drop wins: in India, it has become the gating control for nearly every digital disbursement. RBI, SEBI, and IRDAI have all referenced or required penny-drop verification in regulatory circulars covering lending, mutual funds, and insurance flows. The cost economics are unbeatable for domestic verification — a ₹1 deposit costs cents, which is sustainable at high volume. Indian fintechs running penny drop catch wrong account numbers in seconds where the same error caught post-disbursal could mean a six-month recovery process.

Where penny drop fails: cross-border. Penny drop relies on a working payment rail between the verifying party and the receiving bank. Domestic rails (UPI, IMPS, NEFT in India; ACH in the US; SEPA Instant in the EU) make the method cheap and fast. International rails don't. A penny drop attempting to verify a Brazilian account from a UK fintech would have to route through correspondent banking, take days, and cost orders of magnitude more than the domestic version. The method also doesn't address entity verification — it confirms an account exists but does not confirm the company behind it is legitimate. For markets without modern instant-payment infrastructure, penny drop either doesn't work or isn't worth the operational cost.

2. Verification of Payee (VoP)

Verification of Payee is the EU's regulated answer to name-to-account verification. Since October 9, 2025, every euro-area Payment Service Provider has been required to offer VoP under the EU Instant Payments Regulation. Non-euro EU countries follow by July 9, 2027. The mechanism: before a SEPA Credit Transfer or Instant Credit Transfer is sent, the payer's PSP queries the receiving PSP for a name match against the registered account holder. The response returns one of four results — Match, Close Match, No Match, or Unable to Verify.

Where VoP wins: it is the only verification method that is both regulated and pre-payment across the entire SEPA zone. The mandatory rollout means it works at every euro-area bank without bilateral integration. Sub-second response times. No customer-side consent. Covers individuals and businesses with the same mechanism.

Where VoP falls short: the "Close Match" result is the operational landmine. It surfaces when the legal name on file differs from what was entered (Ltd vs Limited, abbreviations, accented characters, name order). A Close Match is not approval — it is the moment for manual review. Teams that auto-approve on Close Match defeat the purpose of the check. VoP also confirms only the name-to-IBAN match. It does not verify that the company behind the account is real, active, or properly registered. For full verification, VoP needs a registry layer on top.

For the regulatory detail, see MonitorPay's complete guide to VoP.

3. Confirmation of Payee (CoP)

The UK's Confirmation of Payee operates through Pay.UK over Faster Payments and CHAPS. Coverage was expanded dramatically under the Payment Systems Regulator's Specific Direction 17, which extended CoP requirements to approximately 400 PSPs and building societies. As of October 31, 2024, coverage reaches 99% of all CHAPS and Faster Payments transactions. The functional similarity to VoP is intentional — both schemes evolved to solve the same operational problem within their respective regulatory regimes.

Where CoP wins: the UK is one of the few major markets where bank-level name-to-account verification is regulator-mandated. The PSR's APP fraud reimbursement rules — which came into force October 2024 — increase the operational stakes for any PSP not running CoP, since reimbursement liability for fraudulent transfers now sits with the sending bank.

The operational gotcha most non-UK payers miss: CoP results return to the bank initiating the payment, not directly to the corporate sender. A treasury team sending UK payments through a non-UK bank that doesn't expose CoP results to corporate clients has no visibility into the match status. The fix: use a verification provider that calls the CoP service directly and returns the result inline to your AP workflow, regardless of which bank originates the payment.

4. ACH account validation

US ACH account validation is the youngest of the major regulated methods, in the sense that the Nacha rules requiring it are recent. Phase 1 of Nacha's 2026 risk management amendments took effect March 20, 2026 for high-volume originators (≥6 million ACH entries in 2023). Phase 2 extends to all non-consumer originators on June 22, 2026. Both require documented, risk-based monitoring including verification that bank account information is real and owned by the named entity, not just self-reported.

The mechanic varies by provider. Real-time account validation services (FedNow's account validation, RTP, or commercial providers like GIACT and Plaid's IDV) query US banks directly or work through Early Warning Services' EWS Data Mesh to confirm routing/account validity, account status, and name-to-account matching.

Where US ACH validation wins: it is increasingly the bank-side standard for high-volume originators. Most fraud monitoring programs that pass Nacha examiner review now include real-time ACH validation as the technical control, layered with EIN verification at the entity level. (See the Nacha 2026 implementation guide.)

Where it falls short: US-only. For non-US companies paying US suppliers, ACH validation needs to be paired with EIN verification — the IRS-records-backed entity check that confirms the business exists and is registered. ACH validation also does not address International ACH Transactions (IAT entries) which carry separate OFAC screening obligations.

5. NPCI Name Enquiry / UPI ID validation

India's verification infrastructure operates through the National Payments Corporation of India (NPCI). Three related methods exist, and each has different cost-and-accuracy tradeoffs.

• Penny drop (covered above) — the traditional approach, requires actual transfer.
• UPI ID validation — queries a supplier's Virtual Payment Address (VPA) against NPCI's database, returning name, bank, and IFSC code. No ₹1 transfer needed. Faster and cheaper than penny drop, but requires the supplier to have an active VPA.
• NPCI Name Enquiry API — submits account number + IFSC + a name; NPCI returns whether the name matches the holder on record. Live with select banks. The cleanest verification method available in India for high-volume corporate use.

A workflow trick that experienced Indian fintechs use: any IFSC-and-account-number combination can be converted into a synthetic VPA in the format account@ifsc.ifsc.npci. That synthetic VPA can then be validated through standard UPI ID lookup, returning the holder name without making a payment. This gives many of the operational benefits of penny drop with none of the rail or cost overhead.

Where NPCI wins: at scale, in India, NPCI Name Enquiry is the cleanest verification mechanism available — binary yes/no on name match, fast, cheap, official. For B2B verification, pairing NPCI name enquiry with PAN (Permanent Account Number) validation gives both bank-level and entity-level confidence.

Where it falls short: same as the others — country-bound. NPCI methods do not work outside India. For Indian suppliers receiving cross-border payments, the verification must originate from a provider with NPCI access; otherwise, the falls-back path is correspondent banking with all its latency and cost.

6. Open Banking AIS verification

Open Banking — through the Account Information Service (AIS) standard defined in PSD2 — enables a regulated third party to query a customer's bank account directly with the customer's consent. The TPP receives read-only access to account data: balance, transaction history, registered holder name, and account identifiers. Coverage is strongest across the EU and UK, with roughly 2,200+ banks accessible through AIS connections; selected non-EU markets (Brazil under Open Finance, parts of APAC) have built equivalent frameworks.

Where Open Banking wins: for verifying your own customer's account, it is the deepest method available. The customer authenticates directly with their bank, granting consent for read access. Your platform then receives verified account data straight from the bank — no name matching uncertainty, no manual review required for close matches. Lending, financial onboarding, account-aggregation services, and consumer-facing fintech apps all use AIS for this reason.

Where Open Banking fails: the customer consent requirement makes it structurally unsuitable for verifying third parties — vendors, suppliers, marketplace sellers, payees not in a direct relationship with the verifying party. You cannot ask a supplier to log into their own bank account every time they update their bank details with your AP team. For B2B vendor verification, the customer-consent model is the wrong mechanism entirely.

One additional limit: AIS is read-only. It confirms account access but does not perform an entity-level verification of the underlying company. For full vendor verification, AIS still needs a registry layer to confirm the business itself is real. For the broader picture of how AIS fits into a jurisdiction-by-jurisdiction verification strategy, see MonitorPay's cross-border bank account verification guide.

7. Registry-sourced verification

Registry-sourced verification operates at a different layer from the previous six methods. Where the others confirm a bank account, registry verification confirms the entity — the legal business behind the account. Public business registries exist in 200+ countries, and most modern KYB and verification platforms query them directly to confirm that a supplier is registered, in good standing, has the claimed tax identifier, and isn't dormant or dissolved.

The data registry verification returns typically includes: legal entity name, registration number, tax ID (VAT, EIN, CNPJ, RFC, RUC, CUIT, USCC, depending on country), registered address, directors/officers, beneficial ownership, corporate group structure, financial filings status, and operational status. For markets where bank-level verification (methods 1-5) isn't accessible to non-resident payers, registry-sourced verification is the strongest control available.

Where registry verification wins: universal coverage. Bank-level methods are jurisdiction-bound; registries exist almost everywhere. This makes registry verification the universal backstop in any layered architecture — the method that catches gaps the bank-level methods can't address. It is also the only method that addresses shell-company fraud, beneficial ownership opacity, and entity-status changes that occur between onboarding and the next payment.

Where registry verification falls short: it does not confirm bank account ownership. A registry can tell you that "Acme Logistics Ltd" exists and is in good standing in the UK. It does not confirm that the specific IBAN you've been given belongs to Acme. For complete verification, registry data layers onto bank-level verification — not as a replacement.

This is also the layer where MonitorPay does its deepest work. With direct integrations into 200+ government registries covering 600M+ companies, registry verification fills the coverage gap that bank-level methods leave open — and pairs with bank-level methods in markets where both are available. For an in-depth example of how registry-sourced entity verification defeats fraud variants that bank-level methods can't catch, see MonitorPay's analysis of vendor email compromise versus business email compromise.

Which method to use when

The 7 methods are not interchangeable. The right one depends on what you're verifying, where the destination is, and what risk you're trying to control. The matrix below is the practical guide.

One pattern is consistent across every row: registry verification appears in every scenario. Either as the primary method (where bank-level access is unavailable) or as the backstop (where entity-status risk needs to be controlled). This is why the strongest verification architectures are layered — no team can rely on a single method.

The layered approach

The framing that puts this all together: think of verification as a two-axis problem. On one axis is jurisdiction — which country's banking infrastructure does the receiving account sit in. On the other axis is verification depth — bank-level (account exists, name matches) versus entity-level (the company is real, in good standing, the directors are who they claim, beneficial ownership is documented).

A single verification method can address one axis or the other, but not both. Bank-level methods (1-5) are jurisdiction-specific by design. Registry verification (7) is universal but operates one layer above the bank account. Open banking (6) is deep but consent-gated.

The architectures that work in production combine these. A typical mid-market AP team paying suppliers across 20+ countries deploys: method 2 or 3 or 4 or 5 depending on the destination for the bank-level check, plus method 7 as the universal entity layer. Onboarding triggers both. Bank-detail change requests trigger both again. Continuous monitoring then watches both for status changes between payments.

This is the architecture MonitorPay's product was built around — and the reason a single API can replace what would otherwise require seven separate integrations. See the cross-border verification guide for the country-by-country breakdown of what each method looks like in practice, and the continuous monitoring article for why static verification is insufficient.

What this means for your tech stack

Translating the layered approach into architecture, a verification layer that holds up in production needs three properties — each addressing one part of the multi-method problem.

• Routing logic that picks the right method per destination. The verification call for a German supplier is not the same as the call for an Indian one. Your verification layer needs to know which method to invoke based on the destination country, currency, and account format — and to do it without forcing your AP system to make that decision. Hard-coding seven different integrations in your application code is how teams end up with verification logic scattered across the codebase and impossible to maintain.
• A unified response schema so downstream systems don't have to learn seven different shapes. Each underlying method (VoP, CoP, ACH validation, NPCI, penny drop, AIS, registry) returns data in a different format. A production verification layer normalises these into a single response shape — the same field names and the same status taxonomy regardless of which method ran under the hood. This is what lets your AP system, ERP, or onboarding flow have one decision tree instead of one per method.
• A fallback chain when the primary method is unavailable. Bank-level methods occasionally fail — connectivity issues, rate limits, scheme outages. The verification layer should automatically degrade to the next-best method (typically registry verification as the universal backstop) rather than blocking the entire payment flow. Audit-ready logs should record which method was actually used, not just the final decision.

These three properties are why most teams find it cheaper to integrate one verification platform that handles the routing internally than to build and maintain seven separate integrations. The platform pays for itself the first time a new market gets added without an engineering project.

Common pitfalls — what teams get wrong

The five operational patterns that show up most often when a verification system fails in production. Each is a specific way smart teams misuse otherwise solid methods.

1. Auto-approving on VoP "Close Match"

The Close Match result was designed as a manual review signal — the moment when a human checks whether the name discrepancy is benign (Ltd vs Limited) or material (different legal entity entirely). Teams under pressure to move payments fast configure their AP system to auto-approve Close Match alongside Match. This is the most common single failure mode in EU SEPA verification. It is also the easiest variant for a fraudster to exploit: register a shell company with a name that fuzzy-matches the real supplier, and every VoP check returns Close Match. The fix is procedural — Close Match must trigger callback verification, not auto-approval.

2. Treating Open Banking as a vendor verification method

Open Banking AIS is powerful for verifying your own customer's account. It is structurally wrong for verifying a supplier or vendor. Vendor verification requires that you confirm a third party's account without their active participation in the verification flow — exactly the case Open Banking does not handle, because it requires the account holder's authenticated consent. Teams that build vendor onboarding flows around Open Banking discover this when their supplier acquisition stalls: vendors will not log into their own bank every time they update payment details with your AP team. Use the right tool: bank-level verification (VoP, CoP, ACH, NPCI) plus registry-sourced entity verification.

3. Layering two methods that confirm the same thing

Redundancy without depth is a real anti-pattern. Running both VoP and a separate name-matching service against the same EU account does not catch any fraud the first method missed — both methods confirm the same fact (name matches IBAN at the receiving bank). What looks like a defense-in-depth strategy is actually duplicate cost. Real layering combines methods at different layers: VoP at the account layer plus registry verification at the entity layer. The methods catch different attacks because they verify different things.

4. Skipping registry verification for "well-known" suppliers

Procurement teams that have worked with a supplier for five years assume the supplier's legal status hasn't changed. Most of the time, they are right. But corporate group changes, acquisitions, dissolutions, registration lapses, and director changes happen constantly across any vendor portfolio of meaningful size. A supplier that was in good standing at onboarding can become an inactive registration months later — and no bank-level verification will surface this. Registry verification is the only method that catches entity-status drift, which is why continuous monitoring exists. Trusting onboarding-era checks for an entire commercial relationship is the gap that mature fraud monitoring closes.

5. Running penny drop where the rail doesn't reach

Penny drop only works when there is a functioning payment rail between the verifying party and the receiving bank. Domestic rails (UPI, IMPS, ACH, SEPA Instant) make it cheap and fast. Cross-border, the same operation has to route through correspondent banking — which means days of latency, fees that dwarf the verification's cost, and unpredictable failure modes. Teams that try to extend their domestic penny-drop workflow to international suppliers usually end up with manual exceptions for the very markets where verification matters most. The fix is to route by destination: penny drop or NPCI for India, ACH validation for the US, VoP for the EU, CoP for the UK, registry verification as the backstop everywhere else.

Frequently Asked Questions