Named receiving details after Verification of Payee: a design guide for collections

For years, many platforms collected customer funds through pooled accounts and matched each payment to a customer by its reference. Payers saw one name on the receiving account, often the platform's or its provider's. That model is under pressure. In the euro area, payers' banks now check the payee's name against the account identifier before a transfer is sent. A mismatch is shown to the payer.

This guide explains what changed and how to design receiving details and collections around it.

What Verification of Payee is

The EU Instant Payments Regulation requires payment service providers to offer a Verification of Payee (VoP) service to payers who send euro credit transfers, both standard and instant. According to the European Central Bank, providers in euro-area Member States have had to offer it since 9 October 2025. Providers in non-euro Member States have until 9 July 2027. The service is free of charge to the payer.

Before the payer authorises a transfer, their provider checks the payee name they entered against the account identifier. The result is one of four types: a match, a close match (with the actual name shown), no match, or a result where verification was not possible. The payer can still proceed, but they are warned.

The European Payments Council's Verification of Payee scheme rulebook entered into force on 5 October 2025. It gives providers a common way to exchange these checks.

Why it matters beyond the euro

The Financial Action Task Force revised Recommendation 16 in June 2025. The revision requires financial institutions to use tools that protect against fraud and error, such as verification of the recipient's account details, and to standardise the information that travels with cross-border payments. It takes effect by the end of 2030. VoP is the EU's version of a direction that is spreading across payments.

What it means for receiving details

The question a payer's bank now asks is simple: does the name on this account match the name the payer typed? That has consequences for how platforms present receiving details:

• Pooled details with a platform name. If a customer gives their payer an account in the platform's name, and the payer types the customer's name, the result may be "no match" or "close match". Payers may abandon the payment or contact support.
• Named details. Receiving details shown in the end customer's own name tend to match when the payer types that name. They also make reconciliation easier, because each account maps to one customer.
• References still matter. Even with named details, invoice numbers and payment references are how a business matches a payment to an order.

Which structure is available depends on the provider, the currency and the market. It is a programme design decision, not a front-end setting.

Collections design checklist

1. Decide who the account holder is. Is the end customer the named holder, or does the platform collect on the customer's behalf? This is a regulatory question as well as a user-experience one.
2. Separate own-name and third-party flows. Money a customer sends to themselves from their own bank account is a different flow from money a customer's clients send them. Third-party collections usually need business onboarding, extra review and explicit approval.
3. Write the "no match" playbook. Tell customers what payers will see and how to share their receiving details correctly.
4. Reconcile on more than one field. Match on account, amount, reference and payer name, and keep a queue for exceptions.
5. Plan for closures. When a customer leaves, decide what happens to late payments to their receiving details, and tell payers in good time.

Where Axora fits

Axora's Local Accounts & Collections module supports receiving details for approved programmes. On live programmes, own-name EUR receiving by SEPA Credit Transfer and SEPA Instant, and own-name GBP receiving by Faster Payments, are available; CHAPS may be enabled per account on request. EUR, GBP and USD are programme currencies, enabled for each approved account and market. Collecting from third parties is available only for approved business customers outside the EU, after review.

Next steps

• Local Accounts & Collections
• Explore Axora products: Platform
• See solutions by business type: Solutions
• For developers: Developers
• Talk to us: Contact