Een Verification of Payee-oplossing is de dienst die een begunstigdenaam controleert tegen de rekening achter een IBAN voordat een betaling wordt verstuurd. In de EU heet die controle Verification of Payee (VoP). Ze loopt op het SEPA-schema, gecoördineerd door de European Payments Council, en geeft een gestandaardiseerd antwoord in ruim minder dan een seconde. Horen de naam en de rekening niet bij elkaar, dan weet je dat voordat het geld vertrekt - niet erna.
Dat is het korte antwoord. Het nuttige antwoord is weten wat een VoP-dienst echt doet, wie er een nodig heeft en wat een werkende implementatie van een demo onderscheidt. Dat is wat dit artikel behandelt.
Wat een Verification of Payee-oplossing doet
Ze stelt namens jou een vraag. Je betaaldienstverlener (PSP) stuurt de naam die je hebt ingevoerd en het IBAN naar de PSP die de bestemmingsrekening aanhoudt. Die bank vergelijkt de twee namen volgens de matchingregels van het schema en stuurt een gestandaardiseerd resultaat terug. Niets over het bedrag, je saldo of de transacties van de begunstigde wordt gedeeld - alleen de naamvergelijking.
Een gesprek, geen database
Verification of Payee is geen opzoeking in een openbaar register van rekeninghouders. Gegevens van rekeninghouders zijn persoonsgegevens, en alleen de bank die de rekening aanhoudt kan bevestigen wie haar bezit. VoP is een bericht tussen twee banken, geleid via het SEPA-schema - daarom weegt bereik over het hele schema zwaarder dan de elegantie van één enkele integratie.
De vier uitkomsten die een VoP-dienst teruggeeft
- 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 klassieke signaal van een verkeerd ingetypte rekening of een factuuromleidingsfraude.
- Niet beschikbaar - de bank van de begunstigde kon op dat moment niet antwoorden. De betaling wordt niet geblokkeerd; de betaler wordt geïnformeerd en beslist.
De twee middelste uitkomsten leveren de meeste waarde op. Een bijna-overeenkomst is geen mislukking - het schema reikt je de juiste naam aan, zodat de volgende betaling netjes klopt. Een geen overeenkomst is geen systeemfout - de controle doet precies haar werk. En geen van de vier uitkomsten blokkeert een betaling: VoP informeert de betaler, die de beslissing houdt.
Wie een Verification of Payee-oplossing nodig heeft
Er zijn drie heel verschillende afnemers, en ze hebben drie verschillende dingen nodig.
- 1 Banken en PSP's - een schemeverplichting met een deadline. Het werk is een schemaproject: aansluiten op de routing- en directory-infrastructuur, de aanvraag- en antwoordberichten implementeren, de naam-matchingregels toepassen op je eigen rekeninggegevens als antwoordende PSP, en de uitkomst tonen in je kanalen als vragende PSP.
- 2 Fintechs en softwareleveranciers - een ingebouwde capaciteit. Bouw je betaalproducten of betaalsoftware, dan is VoP een functie die je klanten zullen verwachten, en het is meestal sneller om een aanbieder te bellen dan zelf tot het schema toe te treden.
- 3 Bedrijven - treasury, crediteurenadministratie, salarisadministratie en marktplaatsen - een dienst die je gebruikt. Je treedt niet toe tot het schema. Je verifieert één begunstigde in een dashboard, of je verifieert een heel betaalbestand vóór vrijgave, en je verifieert opnieuw wanneer de bankgegevens van een leverancier veranderen.
Voor een individuele betaler is de controle simpelweg de naamcontrole die je eigen bank je toont wanneer je een begunstigde instelt of betaalt. Je koopt haar niet, je gebruikt haar - en voor overboekingen in euro's moet ze gratis worden aangeboden.
Waar de verplichting vandaan komt
Verification of Payee is verplicht gesteld door de EU-verordening inzake instantbetalingen. PSP's in de eurozone moesten dit bij overboekingen in euro's sinds 9 oktober 2025 aanbieden, en PSP's in niet-euro EER-landen volgen uiterlijk 9 juli 2027. De verordening bepaalt de verplichting; het VoP-schema van de European Payments Council bepaalt de mechaniek. In de praktijk betekent dat de controle nu deel uitmaakt van de normale SEPA-betaalstroom in plaats van een optionele extra.
Eén detail is makkelijk te missen: de verplichting geldt voor overboekingen in euro's die de betaler elektronisch start, niet alleen voor instantbetalingen. Een standaard SEPA-overboeking heeft dezelfde controle nodig.
Wat een echte implementatie inhoudt
Ben je een PSP, dan is het eerlijke antwoord dat dit een project is, geen sprint. De onderdelen die er moeten staan zijn:
- Schemaconnectiviteit - toetreden tot het EPC-VoP-schema als vragende PSP, als antwoordende PSP, of beide.
- Een realtime-API die de vier gestandaardiseerde uitkomsten teruggeeft, met de geverifieerde naam bij een bijna-overeenkomst.
- Naam-matchinglogica toegepast op je eigen rekeninggegevens, zodat je vragen over je eigen rekeninghouders kunt beantwoorden.
- Een duidelijk resultaat in elk kanaal waarin een betaler een overboeking in euro's start - app, web en betaalinitiatie.
- Logging en bewaring, zodat je kunt laten zien wat er is gecontroleerd, wanneer, en wat er terugkwam.
Dat vanaf nul bouwen duurt maanden. De meeste PSP's halen hun datum sneller door een aanbieder te integreren die al op het SEPA-VoP-schema opereert, zodat één verbinding bereik over heel Europa geeft in plaats van één integratie per antwoordende bank.
Hoe je een VoP-dienst beoordeelt
- 1 Controleer het schema, niet het etiket. Zijn je betalingen eurobetalingen binnen SEPA, dan heb je het SEPA-VoP-schema nodig - een aanbieder die op een ander nationaal naamcontroleschema is aangesloten, is niet automatisch op het jouwe aangesloten.
- 2 Vraag naar het bereik. De antwoordende PSP is de enige partij die kan antwoorden, dus dekking over het schema is het belangrijkste getal.
- 3 Test de latentie in een sandbox. De controle zit in de betaalstroom, dus ze moet snel zijn - vraag een gemeten cijfer, geen belofte.
- 4 Sta erop dat de geverifieerde naam bij een bijna-overeenkomst wordt meegegeven. Een resultaat dat 'bijna-overeenkomst' zegt zonder de betaler de juiste naam te geven, laat hem gokken.
- 5 Let op alle vier de uitkomsten. Een dienst die 'niet beschikbaar' niet netjes kan teruggeven, blokkeert betalingen of verbergt storingen.
- 6 Controleer de audittrail. Je moet kunnen exporteren wat er is gecontroleerd, wanneer, en wat er terugkwam.
De driecontroletest
Neem een begunstigde die je goed kent en voer drie controles uit: de exacte juridische naam, een verkorte handelsnaam en een bewust verkeerde naam. Een goede dienst geeft overeenkomst, bijna-overeenkomst met de geverifieerde naam, en geen overeenkomst - in die volgorde, in minder dan een seconde, met alle drie de resultaten gelogd.
RoxPay levert schemaconforme Verification of Payee via één REST-API en een dashboard, met de gestandaardiseerde uitkomsten - overeenkomst, bijna-overeenkomst, geen overeenkomst en niet beschikbaar - in ruim minder dan een seconde, met de geverifieerde naam bij een bijna-overeenkomst en de BIC van de antwoordende bank, voor één betaling of een heel betaalbestand.