# EU Instant Payments Regulation’s October 9, 2025 payee-verification mandate: why banks and payment apps need liability-based fraud controls

Nathan Lawson · October 3, 2026

> EU banks and payment apps must verify payees before authorizing in-scope euro transfers, applying fraud controls to IBAN-name mismatches from October 9, 2025.

| Takeaway | Detail |
| --- | --- |
| Run Verification of Payee before authorizing each in-scope euro credit transfer. | For every payment confirmed to be in scope, providers must run and record Verification of Payee before authorization. |
| Treat an IBAN-name mismatch or close match as a fraud-control trigger. | A mismatch or close match is a reason to pause release and apply proportionate fraud checks, not proof that the recipient or transaction is illegitimate. |
| PSP Verifying Payee duties have applied since October 9, 2025. | Since October 9, 2025, payment service providers in euro-area Member States have had to offer Verification of Payee for credit transfers. |
| A correctly performed Verification of Payee does not eliminate liability for a warned payer. | If a PSP runs the check correctly, it is not liable when the customer receives the warning and pays anyway. |

This guide explains the Verification of Payee requirements facing banks and payment apps covered by the EU mandate. It shows how to use name-to-IBAN checks within broader, proportionate fraud controls without treating a match or mismatch as proof of legitimacy.

![modern European glass bank atrium beneath cool overcast](https://static.mm-ais.com/article-images-ai/eu-instant-payments-regulation-s-october-ai-e6631a8b.jpg)
modern European glass bank atrium beneath cool overcast

## Check the name before releasing the transfer

When a customer initiates a euro credit transfer in a bank or payment app, the interface captures the beneficiary name exactly as entered and the supplied IBAN, then submits both values to the Verification of Payee (VoP) service before the transfer is authorized. The VoP mechanism compares the payer-entered beneficiary name against the name associated with that IBAN at the recipient's bank, returning a result of match, close match, or mismatch. This section alone explains the payment-time mechanism: Verification of Payee compares the payer-entered beneficiary name with the name associated with the supplied IBAN.

Show the returned result to the customer before release and preserve the result and customer response in the payment record. The evidence should capture whether the outcome was a match, close match, or mismatch and whether the payment proceeded. A close match or mismatch should prompt a pause and proportionate fraud checks, not be treated as proof that the recipient or transaction is illegitimate. Do not describe a name-to-IBAN comparison as verification of the recipient’s identity or intent.

Before implementation, check the provider’s applicable rule, scheme documentation, and official EU legal text to confirm whether the service and transfer are in scope. Sebastienrousseau.com reports that euro-area payment service providers have had to offer Verification of Payee on credit transfers since 9 October 2025, but the precise scope and any applicable pricing or liability conditions should be verified against the official rules. For each transfer confirmed to be in scope, run and record the check before authorization.

A PSP that runs the check correctly is not liable when a warned customer pays anyway; a PSP that failed to run it risks liability, as noted by wiki.private.law. Verification of Payee tells the payer whether the name matches the IBAN, but it may not stop the payment. If payment service providers fail to deliver accurate results through the VoP service, liability falls on them, per trustpair.com. The operational winner is a recorded Verification of Payee result combined with risk-based fraud controls, not VoP alone.

Verification of Payee helps prevent misdirected payments and certain forms of APP fraud, as it verifies that the recipient's name matches the account details provided before a transfer is authorized, according to sumsub.com. However, it cannot by itself establish that the recipient or transaction is legitimate. The check should be one control point among layered defenses, with the recorded result informing whether additional fraud checks are warranted before the transfer is released.

![Check the name before releasing the transfer — EU Instant Payments Regulation’s October 9,](https://static.mm-ais.com/article-images-pixabay/eu-instant-payments-regulation-s-october-76eeaa11.jpg)

## Separate the date claim from liability evidence

The October 9, 2025 date appears in sebastienrousseau.com as the day euro-area payment service providers had to offer Verification of Payee on credit transfers, but this is a sourced claim that should be verified against the official EU legal text before asserting precise scope or liability timing.

Regarding liability, wiki.private.law states that a provider that performed the check correctly is not liable when a warned customer proceeds anyway. Trustpair.com states that liability may fall on a provider that fails to deliver accurate VoP results. These sources support a narrower conclusion: providers should document both accurate execution and the warning shown to the customer, while verifying the applicable legal and scheme rules before treating either circumstance as determinative.

| Date Evidence | Liability Evidence |
| --- | --- |
| sebastienrousseau.com: October 9, 2025 obligation start | wiki.private.law: correct check = no liability for warned customer proceeding |
| Verify against official EU legal text before asserting scope | trustpair.com: failure to deliver accurate results = provider liability |

Separating the date claim from liability evidence matters because the obligation date and the liability standard are distinct regulatory elements. A provider cannot assume that simply being compliant with the October 9, 2025 deadline eliminates all liability exposure; the accuracy and proper execution of the check itself determines liability under the trustpair.com standard.

Use the payment-time workflow described above: preserve the VoP result, the warning shown, the customer’s response, and the provider’s subsequent fraud-control decision. A mismatch or close match should prompt proportionate review rather than an automatic block, while wiki.private.law’s described protection applies specifically where the check was performed correctly and the warned customer proceeded.

Do not conflate the presence of a VoP check with transaction legitimacy. The check confirms whether the name matches the IBAN, but it does not establish that the recipient or transaction is legitimate. Layered controls remain necessary, and the liability framework depends on both the accuracy of the check and the documented customer response to any warnings.

![Separate the date claim from liability evidence — EU Instant Payments Regulation’s October 9,](https://static.mm-ais.com/article-images-pixabay/eu-instant-payments-regulation-s-october-ba115653.jpg)

## Choose layered controls over VoP alone

Verification of Payee (VoP) alone is useful, but it is not a complete fraud control. Bank of Cyprus describes VoP as a way to compare the beneficiary name supplied by the payer with the name associated with the beneficiary account. That check can identify a name-account inconsistency; it does not, by itself, examine the wider circumstances in which the payment is being made. A matching result therefore supports the name-account association without establishing that the recipient is the intended beneficiary or that the transaction is legitimate.

By contrast, VoP combined with proportionate, risk-based fraud controls can assess relevant context around the payment and account. The additional review may consider signals available to the provider, such as unusual changes in the customer’s payment pattern, newly added payees, repeated or high-risk instructions, inconsistent customer behavior, or other indicators identified by the provider’s fraud framework. These signals should inform a documented decision rather than create an unsupported automatic rule. The operational winner is a recorded VoP result combined with risk-based fraud controls.

Before launch, define what the interface and operations staff will do for each close match or mismatch. For example, the product might pause the transfer and prompt the customer to re-enter or confirm the beneficiary details, require step-up confirmation, or route the case to human review. The action should fit the provider’s risk framework and the evidence presented. A close match should not be presented as a definitive fraud finding, but it should be treated as a reason to pause and apply proportionate checks. A mismatch should likewise trigger review rather than being converted automatically into either acceptance or rejection.

Record the control outcome for every in-scope transfer. The record should identify the VoP result, including whether it was a match, close match, mismatch, or unavailable result, together with the risk-based checks performed, the resulting action, and any human decision. If the customer confirms, changes, or abandons the transfer, record that choice as well. This creates an auditable link between the result shown to the customer and what the provider did next.

Test the workflow with both a clean match and a close match or mismatch. Confirm that the result is captured before authorization, that the prescribed pause or review occurs, and that the final customer choice is preserved. A transfer with no recorded VoP result leaves the provider without evidence that the required check was completed; a recorded result without the decision trail is similarly incomplete. The control is therefore not just whether VoP runs, but whether its output is connected to a documented, proportionate fraud decision.

![Choose layered controls over VoP alone — EU Instant Payments Regulation’s October 9,](https://static.mm-ais.com/article-images-pixabay/eu-instant-payments-regulation-s-october-8b0b6728.jpg)

## Measure exposure with a worked transfer

Consider a fictional method example, not a reported case. A customer enters the beneficiary name “Marta Silva,” an IBAN, and a transfer amount of 1,240. Before the transfer can be released, the provider should document three control points: first, the exact name and IBAN submitted for verification; second, the result actually returned, including whether it was a match, mismatch, or close match; and third, what happened next—did the customer edit the details, proceed with the transfer, or abandon it. This creates an auditable trail of both the control operation and the customer-facing outcome without treating the verification result as proof that the recipient is legitimate.

The result should determine the next control step rather than serve as a final judgment. A mismatch or close match is a reason to pause the transfer and apply proportionate fraud checks, such as reviewing the payment context or confirming the beneficiary details through an appropriate independent channel. A matching result does not by itself establish that the recipient or transaction is legitimate; it reports only the relationship between the submitted name and the IBAN. Bank of Cyprus describes the service as a beneficiary-name and account-name comparison, so providers should verify any additional control requirements against applicable rules and their own fraud framework.

For exposure measurement, the worksheet should separate direct principal at risk from operational costs. In this example, the amount attempted is 1,240, and the principal exposed if the transfer reaches the wrong account is 1,240. That is an exposure measure, not a forecast of loss and not an assertion that the fictional transfer was fraudulent. The worksheet should then identify the cost of a false alert—staff handling time, customer communications, and any associated case-management effort—without assigning a monetary value unless the provider has measured it.

Other expenses may include investigation time, delayed processing, customer remediation, and controls added to address the observed failure mode. These amounts should be recorded as unquantified operational costs until the provider’s own records support an estimate. A useful review compares the 1,240 principal exposure with the documented handling cost of each alert, but it should not combine them into a single figure without stating assumptions. The control is effective when the provider can show that the required check was run and recorded before authorization, and can explain how a mismatch or close match changed the transaction’s handling.

![Measure exposure with a worked transfer — EU Instant Payments Regulation’s October 9,](https://static.mm-ais.com/article-images-pixabay/eu-instant-payments-regulation-s-october-d249a379.jpg)

## Apply the rule without overclaiming

**If the transfer’s legal scope is uncertain,** determine whether its currency, payment type, provider role, or jurisdictional treatment places it within the EU Verification of Payee requirement before treating October 9, 2025 as the controlling compliance date. Consult the official EU legal text and applicable national or scheme guidance, and document the interpretation. The available sources support a broad implementation date—one summary says euro-area payment service providers have had to offer the service since that date—but they do not resolve every scope question, particularly at operational boundaries.

**If the check is unavailable or its result cannot be recorded,** follow a documented fallback and escalation path before authorization. The record should identify why the check could not be completed, who handled the exception, what alternative control was applied, and whether authorization was approved through an authorized route. Do not label the payment “verified” on the basis of incomplete evidence. This rule prevents a system outage, an integration failure, or a missing audit entry from becoming an implicit pass.

**If Verification of Payee returns a mismatch or close match,** pause the payment and apply the provider’s proportionate fraud checks. Those checks may include confirming the beneficiary through a trusted channel, reviewing the customer’s transaction history and instructions, checking for payment-diversion indicators, and escalating higher-risk cases for manual review. Bank of Cyprus describes account-name matching as a way to avoid errors and fraud, while Sumsub presents it as a prevention tool rather than proof of the recipient’s identity. Accordingly, a warning creates a decision point; it does not establish on its own that the transfer is fraudulent or legitimate.

**If the result is an exact match,** retain the recorded result and continue the provider’s ordinary authorization controls, but describe the outcome narrowly: the name associated with the supplied IBAN matches the name entered for that payment. Do not translate that result into a conclusion that the person or business receiving the funds is authentic, that the underlying invoice is valid, or that the transfer is free from fraud. The match is evidence about one name-and-account comparison, not comprehensive verification of the transaction.

**If a customer asks to proceed after a warning,** make the decision under the provider’s documented exception process rather than treating customer insistence as resolution. Present the result clearly, apply the required fraud review, record the customer’s instruction and the authorized decision, and follow any applicable scheme or national rules. A provider should be able to reconstruct not merely that a result was displayed, but why the payment proceeded after the warning and which control owner approved it.

## What to do next

| Step | Action | Why it matters |
| --- | --- | --- |
| 1 | Identify each euro credit transfer handled by a payment service provider in a euro-area Member State and confirm whether it falls within the Verification of Payee mandate. | Verification of Payee duties apply to in-scope euro credit transfers, so scope must be determined before payment authorization. |
| 2 | Run Verification of Payee before authorizing every transfer confirmed to be in scope, and record the result. | The check must occur before authorization, with the completed result retained as part of the provider’s control process. |
| 3 | Compare the payer’s supplied recipient name with the name linked to the recipient IBAN, and classify the outcome as a match, mismatch, or close match. | A mismatch or close match requires a measured response and is not itself proof that the recipient or payment is illegitimate. |
| 4 | When Verification of Payee returns a mismatch or close match, pause release of the funds and apply proportionate fraud checks before allowing authorization to proceed. | Pausing and further checks help distinguish an innocent name discrepancy from attempted fraud without treating the result as conclusive. |
| 5 | Present the payer with clear information about any name discrepancy and the resulting payment hold before deciding whether to proceed, cancel, or correct the recipient details. | A correctly performed check does not eliminate liability for a warned payer, making timely, understandable disclosure essential. |
| 6 | Document the verification outcome, any warning given, the proportionate checks applied, and the final authorization decision. | A consistent record demonstrates that the PSP performed Verification of Payee correctly and supports its position on liability. |

## Frequently Asked Questions

**Does an IBAN-name mismatch prove that the recipient or payment is fraudulent?**

No, a mismatch or close match is a fraud-control trigger and a reason to pause release and apply proportionate checks, not proof that the recipient or transaction is illegitimate.

**When must a bank or payment app check the payee before releasing an in-scope transfer?**

It must run and record Verification of Payee before authorizing the credit transfer.

**What information does a bank or payment app submit for Verification of Payee?**

It submits the beneficiary name exactly as entered by the customer together with the supplied IBAN.

**What happens when Verification of Payee identifies a close match?**

The provider should pause release of the payment and apply proportionate fraud checks.

**Does correctly performing Verification of Payee remove the bank’s liability if the customer ignores the warning?**

No, if the provider runs the check correctly and the warned customer pays anyway, the provider is not liable.

**Are all payment transactions automatically covered by the Verification of Payee requirement?**

No, the requirement applies to in-scope euro credit transfers, and the guide covers banks and payment apps subject to the EU mandate.

## Quick answers

| What must providers do for every payment confirmed to be in scope? | Providers must run and record Verification of Payee before authorization. |
| --- | --- |
| How should an IBAN-name mismatch or close match be handled? | It should trigger a pause in release and proportionate fraud checks, not be treated as proof that the recipient or transaction is illegitimate. |
| Since when have PSP Verification of Payee duties applied? | PSP Verification of Payee duties have applied since October 9, 2025. |
| Does correctly performed Verification of Payee eliminate liability for a warned payer? | No; if the PSP runs the check correctly, it is not liable when the customer receives the warning and pays anyway. |
| What does the interface submit to the Verification of Payee service? | It submits the beneficiary name exactly as entered and the supplied IBAN. |

Also worth reading: **Instant merchant payouts: $1M Instant Payments (FedNow) vs Venmo Myth**: [Instant merchant payouts: $1M Instant](https://l0t.me/blog/instant-merchant-payouts-1m-instant-payments-fednow-vs-venmo-myth.php) · **Instant Payments in Lithuania: From T+2 Cards to A2A Seconds**: [Instant Payments in Lithuania: From](https://l0t.me/blog/instant-payments-in-lithuania-from-t2-cards-to-a2a-seconds.php) · **Faster business payments: 10-second Instant Payments (FedNow) vs Wire**: [Faster business payments: 10-second Instant](https://l0t.me/blog/faster-business-payments-10-second-instant-payments-fednow-vs-wire.php)

### Related reading

- [US Senate Gridlock Over Digital Payments: Stablecoin Regulation Fuels Partisan Clash](https://l0t.me/blog/us_senate_gridlock_over_digital_payments_stablecoin_regulat.php)
- [Faster business payments: 10-second Instant Payments (FedNow) vs Wire](https://l0t.me/blog/faster-business-payments-10-second-instant-payments-fednow-vs-wire.php)
- [Instant Payments in Lithuania: From T+2 Cards to A2A Seconds](https://l0t.me/blog/instant-payments-in-lithuania-from-t2-cards-to-a2a-seconds.php)
- [Instant Payment Fraud Prevention: 300ms FedNow Silent Score vs Step-Up](https://l0t.me/blog/instant-payment-fraud-prevention-300ms-fednow-silent-score-vs-step-up.php)
- [Decoding UK Crypto Regulations After Political Shift](https://l0t.me/blog/decoding_uk_crypto_regulations_after_political_shift.php)
- [Tariff Evasion Fuels US Crypto Regulation](https://l0t.me/blog/tariff_evasion_fuels_us_crypto_regulation.php)

### Latest

- [Faster business payments: 10-second Instant Payments (FedNow) vs Wire](https://l0t.me/blog/faster-business-payments-10-second-instant-payments-fednow-vs-wire.php)
- [Tap to pay fraud: Phone vs Plastic vs Chip Cut 60% Loss 2026](https://l0t.me/blog/tap-to-pay-fraud-phone-vs-plastic-vs-chip-cut-60-loss-2026.php)
- [Instant merchant payouts: $1M Instant Payments (FedNow) vs Venmo Myth](https://l0t.me/blog/instant-merchant-payouts-1m-instant-payments-fednow-vs-venmo-myth.php)

Canonical: https://l0t.me/blog/eu-instant-payments-regulations-october-9-2025-payee-verification-mandate-why-banks-and-payment-apps-need-liability-based-fraud-controls.php
Markdown: https://l0t.me/blog/eu-instant-payments-regulations-october-9-2025-payee-verification-mandate-why-banks-and-payment-apps-need-liability-based-fraud-controls.php/index.md