Name Matching: The Key to Ensuring High-Performance VoP Services

With the European Payment Council’s (EPC) Verification of Payee (VoP) scheme coming into effect in October 2025, payment service providers (PSPs) face a major challenge: securing SEPA transfers (both standard and instant SCTs) while preserving a seamless customer experience.

At the core of this challenge lies the name matching engine, responsible for comparing a beneficiary’s name with the associated bank account details. When configured properly, it strikes the right balance between regulatory compliance, operational efficiency, and customer experience. When poorly designed, it creates an avalanche of false positives, unnecessary payment rejections, and a heavy operational burden for PSPs’ corporate clients.

What the EPC Requires (and What It Doesn’t)

The EPC Rulebook mandates two key requirements for VoP checks:

A VoP response in under five seconds, especially for instant SCTs.
Four standardized outcomes: Match, Close Match, No Match, Not Applicable.

But crucially, the Rulebook does not prescribe how name matching should be performed. No required scoring methods, thresholds, or algorithms. The responsibility falls entirely on PSPs: if a fraud slips through, they must reimburse their customers.

This methodological gap drives many providers to adopt a defensive approach—multiplying alerts “just in case” to reduce liability risk. Yet this defensive bias has unintended consequences: more unnecessary alerts, more friction in customer journeys, and higher operational costs for corporates.

Lessons from the UK’s Confirmation of Payee (CoP)

The UK offers a useful precedent. Launched in 2020, the Confirmation of Payee (CoP) scheme imposed strict name matching rules, leaving little flexibility for PSPs. The result was rigid engines based on exact matching and basic fuzzy logic.

From day one, the shortcomings were evident: a high rate of false positives, operational delays, and weakened trust. A 2023 pilot by Pay.UK revealed that for every genuine fraud detected, the system generated five false positives. Meanwhile, APP fraud—the very threat CoP was designed to curb—continued to rise.

The conclusion is clear: overly strict name matching does not enhance security. It creates noise, slows down payments, and diverts resources away from detecting real fraud.

The Impact on Corporate Clients

In daily operations, false positives frequently affect legitimate payments, such as:

An Italian law firm registered as “Avv. G. Bianchi” but paid under “Studio Legale Bianchi & Associati.”
A Spanish franchisee making payments under the franchisor’s name.
A Dutch SME using “KPN NV” instead of its full legal name.

For corporates, this translates into real costs: delayed payments, added workload for accounting teams, strained supplier relationships, and even contractual penalties. At scale—especially in high-volume sectors—a rigid engine becomes a commercial barrier. This is where PSPs can differentiate: offering a VoP solution that intelligently handles complex cases while minimizing false positives becomes a decisive competitive advantage.

Sis ID VoP Suite: Technology Driving High-Performance Name Matching

The EPC Rulebook defines deliberately basic name matching rules, particularly for corporate entities. Many market solutions stick to these minimum standards, resulting in low match rates (often around 40%). The impact is immediate: degraded customer journeys and poor VoP adoption.

Sis ID VoP Suite takes a different approach. By analyzing real-world datasets provided by PSP clients, Sis ID has developed a name matching engine designed for complexity, capable of handling:

Word inversions
Abbreviations and initials
Extra or irrelevant characters
Spelling variations

This pragmatic approach is a game-changer: on realistic test scenarios built from representative Western European beneficiary data, Sis ID’s system achieved over 80% relevant matches—compared to less than 30% for engines limited to standard rules.

Beyond raw performance, Sis ID VoP Suite places customization at the heart of the solution. Matching rules can be finely tuned (down to the BIC level) through an intuitive business-user interface. They can be tested under real conditions, validated before rollout, and exported to meet compliance and audit requirements.

Among the many configurable parameters is the ability to define a list of “gray words.” These are terms that carry meaning in beneficiary names and should therefore be retained during preprocessing, but they are not strong enough on their own to trigger a full MATCH result.

Practical example: For a given activity, the terms “SUPPLY” and “LIMITED” are defined as gray words.

A beneficiary account is registered as “DUBLINELECTRICITY SUPPLY LIMITED”

Case 1: If the payer enters “DUBLIN ELECTRIC SUPPLY LIMITED,” the engine will return CLOSE MATCH—indicating a plausible but partial match.
Case 2: If the payer enters “DUBLIN ELECTRICITY” with the same bank details, the engine will return MATCH.

This configuration ensures gray words are treated as optional, reducing false rejections and avoiding unnecessary breaks in the payment journey—critical to maintaining a smooth and reliable customer experience.

Ready to See the Results on Your Own Data?

Back to blog