VoP Response Codes and the Customer Journey: Match, Close-Match, No-Match in Your UI

The scheme hands you a graded answer, not a verdict. Whether that answer prevents fraud or just annoys your customer is decided entirely by what you do with it in the last screen before they hit send.

Verification of Payee has been live for euro-area payment service providers since 9 October 2025, and the engineering conversation has mostly been about the plumbing: routing to the right responding PSP, matching names in under five seconds, staying inside the instant-payment SLA. That work matters, but it is not where the product succeeds or fails. VoP returns a graded result — a full match, a close match, a no match, or a verification that could not be performed — and the scheme deliberately leaves the consequence to you. It is a warning mechanism, not a block. The payer can proceed regardless. So the real design question is not “did the name match” but “what do we show, and what do we let the customer do next, for each of those outcomes.” That is a product and risk decision, and it is where fraud prevention and friction actually collide.

What the scheme actually returns

Under the EPC Verification of Payee scheme, a name-and-IBAN request comes back with one of four outcomes. In the inter-PSP API these are carried in a partyNameMatch field with the values MTCH (match), CMTC (close match), NMTC (no match), and NOAP (verification not possible — the account cannot be checked, is unknown, or the responding PSP cannot answer). On a close match, and only on a close match, the responding PSP also returns the registered name of the account holder in a matchedName field, so the payer can see what the account is actually held under. That single conditional field is the crux of the whole customer-journey design, and I will come back to it.

One structural point worth internalising: a verification made against an identification code rather than a name cannot return a close match at all. The logic is graded only for names, because names are the thing that fuzzes. An account number either resolves or it does not. So the ambiguous middle — the part that generates the hard product decisions — exists only in the name-matching path, which is the path the overwhelming majority of retail payers will use.

Match and no-match are the easy ends

A full match needs almost nothing. Confirm quietly, let the payment proceed, do not congratulate the customer for typing a name correctly. The temptation to add a green tick and a reassuring sentence is worth resisting past the first release; the more ceremony you attach to a match, the more you train the customer to read the absence of ceremony as a problem, which corrodes the signal you actually care about.

A no match is the clearest warning the scheme can give, and it deserves a genuine interruption. Not a block — you are not permitted to block on VoP alone, and blocking would push customers to work around you — but a hard, unmissable warning that the name they entered does not correspond to the account, that this is a common feature of authorised push payment fraud, and that proceeding is their decision and their liability. The liability point is not decoration. Under the regime, a payer who authorises a transfer after being properly warned of a mismatch generally bears the loss if the money goes astray. Your warning screen is, in effect, the evidence that the warning was given, so it needs to be logged as carefully as it is worded.

Close-match is where the money is lost or saved

Close match is the outcome that separates a competent implementation from a negligent one. It means the name is nearly right — a missing middle name, “Rob” for “Robert”, a transposed word, a company entered as its trading name rather than its registered one. Some of these are the payer being slightly imprecise about a legitimate payee. Some of these are a fraudster who has got close enough to look plausible. The scheme helps you here by returning the registered name, and the correct design is to show it. “You entered J Smith Plumbing. This account is registered to John Smith Building Services Ltd. Is that who you meant to pay?” gives the payer the one piece of information that lets them make the call themselves.

The trap is treating close match as a soft match — a slightly less green tick — and waving it through. That converts the single most useful fraud signal the scheme produces into noise. The opposite trap is treating it as a no match and throwing up a fraud wall every time someone abbreviates a first name, which trains customers to click through warnings reflexively and abandons a measurable share of entirely legitimate payments. The right posture is a distinct third state: show the registered name, require an explicit acknowledgement, and make the friction proportional to your other risk signals rather than fixed. This is exactly the point where VoP handling should feed into, and draw from, your real-time fraud controls — a close match on a first-time payee to a high-risk destination is a different decision from a close match on an account the customer has paid for two years.

Mapping response to journey, deliberately

The response handling should be a single, auditable mapping from scheme outcome to UI state and permitted action, written down and owned, not scattered through front-end conditionals that nobody can reconstruct after an incident. The skeleton below is deliberately boring — it is the discipline of having exactly one place that decides, and logging the decision, that matters.

// Map an EPC VoP name-match response to a UI decision.
// The response is a warning input, never an authorisation to block.

type VopResponse = {
  partyNameMatch: 'MTCH' | 'CMTC' | 'NMTC' | 'NOAP';
  matchedName?: string; // present only when partyNameMatch === 'CMTC'
};

type UiDecision = {
  state: 'proceed' | 'confirm_name' | 'warn' | 'degraded';
  showRegisteredName?: string;
  requireAcknowledgement: boolean;
  logReason: string;
};

function decide(v: VopResponse, firstTimePayee: boolean): UiDecision {
  switch (v.partyNameMatch) {
    case 'MTCH':
      return { state: 'proceed', requireAcknowledgement: false,
               logReason: 'vop_match' };
    case 'CMTC':
      // Show what the account is actually registered under and
      // make the payer confirm it is who they meant to pay.
      return { state: 'confirm_name', showRegisteredName: v.matchedName,
               requireAcknowledgement: true,
               logReason: firstTimePayee ? 'vop_close_new_payee'
                                          : 'vop_close_known_payee' };
    case 'NMTC':
      return { state: 'warn', requireAcknowledgement: true,
               logReason: 'vop_no_match' };
    case 'NOAP':
    default:
      // Verification unavailable: neither reassure nor block.
      // State plainly that the name could not be checked.
      return { state: 'degraded', requireAcknowledgement: true,
               logReason: 'vop_not_possible' };
  }
}

The fourth branch, NOAP, is the one teams forget. Verification will sometimes be impossible — the responding PSP is unreachable within the SLA, the account is a type that cannot be checked, or the counterparty has opted out where permitted. The wrong responses are to silently treat it as a pass or to fall back to blocking. The honest UI says the name could not be verified this time, so the usual reassurance does not apply, and lets the payer proceed with that knowledge. Building for this branch is inseparable from getting the underlying sub-five-second matching architecture and the routing and verification mechanism right, because a slow or flaky verification path turns every timeout into a degraded-state screen your customers will learn to ignore.

The decision you are actually making

Every one of these mappings is a bet on where you would rather fail. Wave close matches through and you take the fraud loss and, increasingly, the liability that comes with a warning you buried. Wall off every near-miss and you take the abandonment, the support calls, and the slow erosion of a signal customers stop reading. The scheme gives every PSP the same four codes; the customer experience and the fraud numbers diverge entirely on how those four codes are handled. Non-euro PSPs still have until 9 July 2027 before VoP becomes mandatory for them, which is time to design this properly rather than time to defer it. The teams that treat the response mapping as a first-class product surface will quietly outperform the ones that treated it as an error handler.

A green tick is not a decision. Deciding what a customer may do after a close match is.