Verification of Payee in 2027: how should businesses prepare payments?

01

Facts: what changes in Poland in 2027?

Regulation (EU) 2024/886 amends the EU rules for euro credit transfers. Payment service providers that offer ordinary euro credit transfers also have to offer instant euro credit transfers under the conditions set out in the Regulation. The duties are phased and the dates differ between euro-area and other Member States.

For payment service providers in non-euro Member States, including Poland, the European Central Bank gives 9 January 2027 as the deadline for receiving instant euro transfers and for the rule that the charge cannot exceed the charge for the corresponding ordinary transfer. The deadline for sending instant euro transfers and providing Verification of Payee is 9 July 2027.

These are regulatory duties for payment service providers, not a direct requirement for every Polish company to build VoP. The exact coverage of an account, currency, channel and payment type should be confirmed with the bank or other provider. This article was verified on 22 October 2026 and provides operational information, not individual legal, financial or banking advice.

02

Facts: how does Verification of Payee work?

Before a transfer is authorised, the payer’s provider sends a request to check whether the account identifier — usually the IBAN — corresponds to the supplied payee name. Under the European Payments Council rules, the response may be match, no match, close match or verification check not possible. A close match may return the name associated with the account so that the payer can assess the difference.

Verification is to be offered to the payer for ordinary and instant euro credit transfers, without a charge for the check itself. The result is displayed before approval, allowing the user to correct the data or make an informed decision about proceeding.

VoP reduces errors and some types of fraud involving substituted beneficiary details, but it does not validate the commercial purpose, the invoice, the identity of the person who sent a message or the legitimacy of a bank-account change. A data match is therefore not a guarantee that every aspect of the payment is safe.

03

Facts: the interbank standard and a company integration are different layers

The EPC published version 1.1 of its VoP scheme rulebook and version 1.1.1 of the inter-PSP API specification, effective from 20 September 2026. These documents describe message exchange between scheme participants, including request fields, response statuses, data meaning and transport security.

They do not mean that a business should connect its ERP directly to the EPC interbank API. A bank may expose VoP results through online banking, a host-to-host channel, its own API or a bulk-payment workflow. Response formats, multi-beneficiary handling and behaviour during an outage depend on the particular provider’s implementation.

A company should therefore start its technical specification with its bank’s documentation and business scenarios rather than assume that one EU-level interface automatically works in every finance system.

04

WEBee recommendation: clean the beneficiary master

False alerts are more likely where a system stores a trading name instead of the account holder’s full legal name, an outdated IBAN or parent-company details instead of the entity named on the account. Start with beneficiaries used in recent months and the highest-value payment relationships.

For each record, establish a data source, business owner and last-confirmed date. Do not change a name automatically based only on a close-match result. An additional identifier such as a VAT number or LEI is useful only if the bank and channel actually support it.

• store the account holder’s full legal name in a dedicated field;
• separate trading name, correspondence address and payment details;
• detect duplicate IBANs and multiple accounts for one beneficiary;
• record the source and approver of every new or changed account;
• review high-value and frequently used beneficiaries periodically;
• avoid retaining more personal data in logs than control and audit require.

05

WEBee recommendation: define a decision for every result

A VoP result should be part of the workflow, not another message that users routinely dismiss. Rules need to identify who may correct data, who approves an exception and when a payment is stopped. Define the treatment separately for a single transfer and an ERP payment batch.

The safest model preserves human control where the result is ambiguous. Automation can prepare the decision and evidence, but it should not independently ignore a warning or overwrite a beneficiary record using a single result.

• match — continue the normal approval while retaining limits and segregation of duties;
• close match — show the difference, suspend automatic approval and route the item for review;
• no match — block payment until details are confirmed through an independent channel;
• verification check not possible — retry or follow a documented fallback; never treat no result as a match;
• changed IBAN — require four-eyes approval and contact through a previously known channel;
• exception — record the reason, approver, time and payment identifier.

06

WEBee recommendation: test the ERP, payment files and bank API

Testing should cover the entire journey from beneficiary master to result posting. Check name length and encoding, national characters, overseas companies, joint accounts, branches, bulk beneficiaries, delayed responses and unavailable verification.

For payment batches, determine whether every item is verified, how the bank returns results and whether one error stops the whole batch. In a host-to-host or API integration, define correlation identifiers, idempotent retries, timeouts, versioning and an event trail. Do not expose full account details in general application logs.

Before production, run acceptance tests with finance, accounting, security and the online-banking administrator. Success criteria should include both a correct payment and the safe stopping and explanation of an exception.

07

WEBee recommendation: retain independent anti-fraud controls

Payment attacks often begin outside the bank, with a compromised mailbox, false invoice or urgent request to change an account. VoP should complement — not replace — segregation between payment creation and approval, limits, trusted-beneficiary controls and independent verification of changes.

A sound practice is to call a known person on a number held before the change, rather than a number supplied in the request. New accounts and high-value payments can require extra approval. Process metrics should cover close-match and no-match rates, exception resolution time, data changes and payments released despite a warning.

08

A 90-day preparation plan

Use the first weeks to inventory banks, accounts, currencies, channels and data sources. Ask each provider for its timetable, corporate-channel documentation, batch rules and test environment. Use those answers to design result handling, responsibilities and required system changes.

Next, clean a representative part of the beneficiary master, run integration tests and measure the number of exceptions. Expand automation only after that evidence is available. WEBee can map the payment workflow, structure requirements for the bank and ERP, design exception controls and support pre-release testing.

• days 1–30: scope, payment channels, process owners and data quality;
• days 31–60: bank specification, result scenarios, change controls and integration requirements;
• days 61–90: user and integration tests, training, fallback procedure and metrics;
• after launch: exception analysis, master-data corrections and permission reviews.