Verification of Payee Moved the Risk. It Did Not Fix the Data.

An invoice arrives from a supplier of four years. The amount is routine, the contact is the same as always, the account details have not changed. The payment goes out, the Verification of Payee (VoP) check returns Match, and nothing is flagged. 

The company had been removed from the register eleven weeks earlier. The entity named on the invoice no longer existed, and payments were still reaching an account carrying its name. 

The VoP response was correct. It was also silent on the only fact that mattered. 

What a Match asserts, and what it does not 

Under the scheme, the payee's institution compares the name submitted in the request against the data it holds for that account and returns one of a defined set of responses: Match, Close Match, No Match, or verification not possible. The payer's institution passes that response on. 

Something is missing from that response set. There is no dimension in which the answer can express whether the entity behind the account still exists, and this is not an oversight. The scheme states its own scope plainly: it verifies whether an account number belongs to the intended counterparty, and is not to be used as a form of identification of a legal person for other purposes. 

So the check answers one question with precision. Is this account held by the party the payer named. It has no view on a second question that sounds almost identical. Is that party still a business. 

Fraud and failure divide along the same line. Where account details are substituted, the response is a mismatch, the payer is warned, and the decision to continue is recorded. Where the counterparty itself is the problem, whether it was never a registered business, is no longer one, or is the latest in a chain of companies wound up leaving debts behind, the payment produces no signal at all. 

The category that leaves no trace 

Fictitious suppliers are a long-standing category in accounts payable fraud, and forensic practice resolves them the way it always has, by checking the counterparty against the business register. 

The legitimate version of the same event is far more common, and harder to see for that reason. Suppliers are acquired and invoices begin arriving from a parent. Divisions are sold and contracts novate to the buyer. Groups restructure and the name on the remittance advice changes while the goods, the contacts and the relationship stay the same. Security researchers note that impersonation attempts cluster around these events, because a merger or an acquisition makes an identity change look like routine administration. 

What separates the genuine restructure from the impersonation is never the name. Both present a new one, plausibly explained. 

Names are not identifiers

A company name is not unique across jurisdictions, and nothing prevents an entity being registered under a name already in use elsewhere. The registration number, with the jurisdiction that issued it, is what identifies a company. Everything else is a label attached to it. 

The scheme anticipated the gap. VoP allows an identification code, a Legal Entity Identifier or a VAT number, in place of the name, and on those codes no close match is possible: the result is Match or No Match. Whether the route is available at all depends on the responding institution supporting that code, and the scheme defines a distinct response for the case where it does not. 

Which leaves the anchor to be held where the relationship is recorded. A counterparty tied to a registration can be tested at any point: does the registration exist, is it still active, does the name still correspond to it. A counterparty known only by a name cannot be tested, because there is nothing to test it against. 

What registry data has to carry 

Three properties matter once verification has to support identity over time. 

Status as well as existence, checked on a cadence rather than at onboarding alone. A supplier verified when the relationship began and never rechecked is a record of something that used to be true. 

The registered name returned alongside the result rather than instead of it, together with any other names the register holds against that registration. A supplier invoicing under a recorded variant is not thereby a different company, and downstream systems need a string to store and compare rather than a verdict. 

Normalisation of legal form designations across languages. The scheme's own matching recommendations devote real attention to stripping diacritics, punctuation and honorifics before comparison, a recognition that formatting variance produces mismatches meaning nothing. The same problem arrives one layer earlier, in how a legal form is abbreviated or translated in the record itself, and it has to be resolved country by country rather than by one global rule. 

Since no algorithm or threshold is prescribed, tolerance is better set by the system consuming the answer than inherited from the one producing it. Onboarding a supplier and releasing a payment file are not the same risk decision. 

The question underneath the question 

VoP asked whether the name matches the account. It was the right question, it is being answered at scale across the euro area, and it closes a route to fraud previously invisible at the moment of payment. 

The older question sits underneath it and remains open. Is this counterparty still the business the relationship was formed with, and is it a business at all. That one is not answered anywhere in the payments chain. It is answered in the register, or it is not answered. 

Open Automation's Global Biz Verify API queries official business registries across a growing global footprint, confirming that a registration exists and remains active and returning the company name as recorded by the register, with localised legal form designations normalised and a matching threshold each customer sets for itself. Available on AWS Marketplace with pay-per-call pricing and no commitments, and on other major cloud marketplaces on request. Learn more at open-automation.io/global-biz-verify-api.

Open Automation | Sponsored feature