Verification of Payee op SEPA is een naamcontrole die tussen twee banken plaatsvindt voordat een betaling in beweging komt. U voert een naam van een begunstigde en een IBAN in; uw betaaldienstverlener (PSP) vraagt de PSP die dat IBAN aanhoudt of de naam bij de rekeninghouder past; het antwoord komt terug in een gestandaardiseerd formaat, meestal in minder dan een seconde. Niets over het bedrag, uw saldo of de transacties van de begunstigde wordt gedeeld - alleen de naamvergelijking.
Dat is het hele idee. Wat het laat werken in tientallen landen en duizenden banken, is dat het een schema is en geen product: een gemeenschappelijk rulebook, gemeenschappelijke berichtformaten en een gemeenschappelijke set uitkomsten die elke deelnemende PSP bereid is te spreken.
Waarom 'SEPA' het belangrijke woord is
SEPA - de Single Euro Payments Area - is het betalingsgebied waar euro-overboekingen, automatische incasso's en instantbetalingen één set regels volgen. Verification of Payee is voor datzelfde gebied gebouwd, op IBAN's, en wordt gecoördineerd door de European Payments Council (EPC), het orgaan dat de SEPA-rulebooks onderhoudt. Het VoP-schema van de EPC bepaalt hoe een aanvraag wordt geformatteerd, hoe een antwoord wordt geformatteerd, welke uitkomstcodes bestaan en hoe PSP's elkaar vinden.
Daarom is VoP niet hetzelfde als een naamcontrole in Britse stijl, en daarom is een aanbieder die op het ene schema is aangesloten niet automatisch op het andere aangesloten. Als uw betalingen eurobetalingen binnen SEPA zijn, is het SEPA-schema het schema dat op u van toepassing is.
Een schema, geen database
Er is geen centrale lijst van rekeninghouders waarin namen kunnen worden opgezocht. De enige bank die gezaghebbend kan zeggen wie een IBAN aanhoudt, is de bank die het aanhoudt. VoP is daarom een gesprek tussen PSP's, geleid via het schema - geen opzoeking in een gedeeld register.
Hoe de controle tussen twee banken reist
- 1 De betaler voert een naam van een begunstigde en een IBAN in zijn bankapp of in zijn ERP-betaalbestand in.
- 2 De aanvragende PSP stuurt een verificatieaanvraag met de ingevoerde naam en het IBAN.
- 3 Het schema leidt de aanvraag naar de PSP die de rekening aanhoudt - de antwoordende PSP - met behulp van de routeringsinformatie die in de directory van het schema is gepubliceerd.
- 4 De antwoordende PSP vergelijkt de ingevoerde naam met de naam die op de rekening staat, volgens de naamvergelijkingsregels van het schema.
- 5 Een gestandaardiseerd antwoord komt terug bij de aanvragende PSP, die de betaler de uitkomst toont voordat de betaling wordt geautoriseerd.
Twee details zijn in de praktijk belangrijk. Ten eerste is de antwoordende PSP de enige partij die kan antwoorden - daarom weegt dekking over het hele schema zwaarder dan de elegantie van één enkele integratie. Ten tweede zijn de aanvraag en het antwoord machine-tot-machineberichten, zodat de controle kan lopen op één betaling in een app of op elke regel van een leveranciersbetaalbestand.
De vier uitkomsten die u terugkrijgt
- Overeenkomst - de ingevoerde naam komt overeen met de rekeninghouder. Het resultaat met het laagste risico; ga verder met het gebruikelijke vertrouwen.
- Bijna overeenkomst - de naam lijkt erop maar is niet identiek: een ontbrekende tweede voornaam, initialen in plaats van een volledige voornaam, een handelsnaam tegenover een geregistreerde naam. Het antwoord bevat de geverifieerde naam, zodat de betaler die kan bevestigen of corrigeren.
- Geen overeenkomst - de naam hoort niet bij dat IBAN. Dit is een geldig antwoord, geen technische fout, en het is het klassieke signaal van een verkeerd ingevoerde rekening of factuuromleidingsfraude.
- Niet beschikbaar - de antwoordende PSP kon op dat moment niet antwoorden. De betaling wordt niet geblokkeerd; de betaler wordt geïnformeerd en beslist.
De middelste twee zijn waar de waarde zit. Een bijna overeenkomst is geen mislukking - het is het schema dat u de juiste naam aanreikt, zodat de volgende betaling netjes overeenkomt. Een 'geen overeenkomst' is geen systeemfout - het is de controle die precies haar werk doet.
Wat 'payee checker' en 'payee checking service' echt betekenen
Mensen zoeken naar een payee checker of een payee checking service in de verwachting van een website waar ze een naam en een IBAN kunnen invoeren en een antwoord krijgen. Zo werkt het niet, en het is de moeite waard om duidelijk te zijn over waarom: gegevens van rekeninghouders zijn niet openbaar, en geen enkele derde partij kan gezaghebbend bevestigen wie een IBAN aanhoudt. De controle is naar haar aard bank-tot-bank. Wat u als betaler kunt doen, is de verificatie gebruiken die uw eigen PSP biedt op het moment dat u een begunstigde instelt of betaalt. Wat u als bedrijf kunt doen, is diezelfde controle over een heel betaalbestand laten lopen voordat u het vrijgeeft.
Wat implementatie in de praktijk inhoudt
Voor een PSP is het implementeren van VoP op SEPA een schemaproject, geen functiesprint. In grote lijnen betekent het aansluiten op de routerings- en directory-infrastructuur van het schema, de aanvraag- en antwoordberichten implementeren, de naamvergelijkingsregels als antwoordende PSP op uw eigen rekeninggegevens toepassen en de uitkomst als aanvragende PSP in uw kanalen tonen. Het werk is goed begrepen, maar het raakt kernbetalingsstromen, dus het wordt meestal in fasen gepland in plaats van in één keer aangezet.
Voor een bedrijf - treasury, crediteurenadministratie, loonadministratie - is de implementatie veel lichter. U treedt niet toe tot het schema. U roept een VoP-dienst aan die er al mee verbonden is, via uw bank of via een API, en u koppelt het resultaat aan het punt waarop betalingen worden goedgekeurd. Het praktische patroon is om het hele betaalbestand vóór vrijgave te verifiëren en opnieuw te verifiëren wanneer de bankgegevens van een leverancier veranderen, in plaats van bij elke run elke opgeslagen begunstigde te controleren.
Waar de verplichting vandaan komt
De EU-Verordening instantbetalingen maakte Verification of Payee verplicht voor PSP's in het eurogebied vanaf 9 oktober 2025, en voor PSP's in niet-euro-EER-staten tegen 9 juli 2027. De verordening stelt de verplichting; het EPC-schema stelt de mechaniek. In de praktijk betekent dat de controle nu deel uitmaakt van de normale SEPA-betalingsstroom in plaats van een optionele extra - en dat ze betalers kosteloos moet worden aangeboden.
RoxPay levert Verification of Payee op het SEPA-schema via één REST-API en een dashboard, en geeft de gestandaardiseerde uitkomsten - overeenkomst, bijna overeenkomst, geen overeenkomst en niet beschikbaar - in ruim minder dan een seconde terug, met de geverifieerde naam bij een bijna overeenkomst, zodat betalers kunnen bevestigen in plaats van gokken.