Confirm the payee name before an agent pays

An autonomous agent that disburses to an IBAN can confirm the number is valid, which bank it belongs to, and that it is reachable over SEPA — and still pay the wrong person. None of those checks look at who owns the account. The control that does is Verification of Payee (VoP): it compares the name you intend to pay against the account holder behind the IBAN, and returns one of five verdicts. One paid call — GET /iban/verify-name — gives an agent that answer before the transfer leaves.

The problem: a valid IBAN is not the right beneficiary

The dominant fraud against payment automation is not a forged account number; it is a correct account number that belongs to the attacker. In an authorized push payment (APP) scam — invoice redirection, business email compromise, supplier impersonation — the victim is induced to send money to an account that passes every structural and reachability check, because it is a real, reachable account. It just is not the payee’s.

An agent that screens for sanctions and resolves SEPA reachability but never confirms the name is exactly the target this fraud is built for. The holder’s name is not data an LLM can derive or hold: it lives inside the inter-PSP EPC scheme, behind bank data, and changes per account. It has to be queried at pay time.

Why this is now a regulatory expectation, not a nicety

Verification of Payee is mandatory across the euro area since 9 October 2025 under the EU Instant Payments Regulation (Regulation (EU) 2024/886). Every payment service provider in the eurozone must offer a name check against the IBAN before executing a SEPA credit transfer — standard or instant — and the requirement extends to non-euro EU PSPs by 2027. The scheme itself is defined by the EPC Verification of Payee Rulebook.

For an agent preparing a SEPA transfer, that means the payee check is no longer an optional anti-fraud layer — it is the step the rails now assume happened.

The call: a name verdict in one of five bands

GET /iban/verify-name takes an iban and a name — a person or a company — and returns a VerifyNameResult. The field the agent branches on is name_match, one of five bands:

On a close_match, and only then, the response carries suggested_name — the corrected holder name — so the agent can fix the beneficiary before sending rather than abandoning a transfer that was right except for a typo:

{
  "iban_valid": true,
  "name_match": "close_match",
  "bic": "COBADEFFXXX",
  "suggested_name": "Erika Mustermann",
  "coverage": { "supported": true, "country": "DE", "reason": null }
}

A no_match never returns a name. The scheme — and this endpoint — disclose just enough to correct a near-miss, never enough to enumerate who holds an account.

Reading the verdict honestly

The endpoint is deliberate about the difference between “the answer is no” and “there is no answer”:

• unavailable is a 200, not an error. The payee bank being unreachable, or the account being closed, is a successful verdict — the question was answered. An outage of our provider is a 503, where the agent is not charged. Treat unavailable as “could not confirm,” and apply your own hold policy; do not treat it as a match.
• not_supported is a free pre-filter. Countries outside the VoP scheme are resolved locally (provenance snapshot), so no paid network call is spent on a country that cannot be checked. The agent learns the check is not possible without paying for a round trip that could never return.
• Per the x402 golden rule, the agent pays for the answer to its question. unavailable and not_supported are both answers → 200. The 4xx/5xx range is reserved for requests the service genuinely cannot process (a missing parameter, a provider outage).

Where it sits in the x402 loop

VoP is the last identity check before the money moves. The agent’s loop:

1. Discover the endpoint and call it; receive the 402.
2. Pay — sign the chosen rail and replay the request.
3. Verify — read name_match, and suggested_name on a close match.
4. Branch — proceed on match; correct and re-confirm on close_match; stop on no_match; apply a hold on unavailable; fall back to your own policy on not_supported. Only then pay the beneficiary through your rails.

Each paid call follows the same x402 pattern as every Invoket endpoint. The Quickstart walks the whole discover → 402 → pay → replay cycle with runnable snippets. Price and accepted rails are not pinned in this article — they are served live by the catalog; see the endpoint reference for the current figure.

Verifying a list, not just one pair

When the input is a batch — a payout run, a new-supplier file, an onboarding sweep — POST /iban/verify-name/batch verifies many name/IBAN pairs under one x402 settlement instead of one settlement per row. The cost is one settlement per call regardless of how many pairs it carries, which is what makes a pre-payment name check workable across a whole vendor file rather than a per-row toll.

How it fits with the other IBAN checks

VoP answers a different question from the other IBAN endpoints, and the three are complementary, not interchangeable:

• GET /iban/resolve — is the number valid, which bank and BIC owns it, and is it reachable over SEPA? (See Verify a bank account before an agent pays it.)
• GET /iban/screen — is the bank sanctioned, and what is the jurisdiction risk? (See Screen a beneficiary IBAN before your agent pays it.) Screening looks at the institution, not the name.
• GET /iban/verify-name — does the name match the account holder? This is the only one of the three that addresses APP fraud.

Used for what it is — a name-against-holder verdict at pay time — VoP is the control that stops an autonomous agent from paying a structurally perfect IBAN that belongs to the wrong person. For the full field reference and error codes, see the GET /iban/verify-name documentation; for how agents discover and call Invoket endpoints, see For agents.