API call
Uw systeem roept onze REST API aan met de naam of identificator van de begunstigde en zijn IBAN.
BEDRIJF
Digiteal SA
BE 0630675588
LEI 9845000A44AB9CA60605
Rue Emile Francqui 6/9
1435 Mont-Saint-Guibert
Belgium
OVER DIGITEAL
VoP vs Confirmation of Payee: wat is het verschil?
Als u de ontwikkelingen in de betalingssector volgt, hebt u misschien al gehoord van Confirmation of Payee, of CoP, het Britse equivalent van VoP. Ze zijn verwant: hetzelfde fundamentele doel, maar andere regelgevende kaders.
Confirmation of Payee werd vanaf 2020 in het Verenigd Koninkrijk ingevoerd onder toezicht van de Payment Systems Regulator, of PSR. Het systeem dekt betalingen via Faster Payments en CHAPS. Het Verenigd Koninkrijk was een pionier op dit vlak, met meetbare resultaten: deelnemende banken meldden aanzienlijke dalingen van APP-fraude in de jaren na de invoering.
Verification of Payee (VoP) is de Europese versie, beheerd door de European Payments Council, of EPC, via haar VoP Rulebook. VoP dekt SEPA Credit Transfers, of SCT, en SEPA Instant Credit Transfers, of SCT Inst, en werd in oktober 2025 verplicht in de hele eurozone.
Daarnaast biedt SWIFT ook prevalidatiediensten aan voor grensoverschrijdende betalingen, maar de scope van VoP binnen SEPA is duidelijk afgebakend en wordt gedreven door regelgeving.
De bredere les is duidelijk: wereldwijd bewegen regelgevers in dezelfde richting. De verificatie van de naam van de rekeninghouder vóór de uitvoering van een betaling wordt een universele verwachting.
De regelgeving die VoP verplicht maakt
Verordening (EU) 2024/886, doorgaans de Instant Payments Regulation of IPR genoemd, verplicht alle Payment Service Providers, of PSP’s, die actief zijn in de EU om Verification of Payee aan te bieden voor zowel klassieke SEPA-overschrijvingen als instant SEPA-overschrijvingen.
Dit betekent:
- Als PSP moet u zowel VoP-aanvragen kunnen versturen, namens uw klanten die betalingen initiëren, als VoP-aanvragen kunnen beantwoorden wanneer iemand een van uw rekeninghouders probeert te betalen.
- De controle moet worden uitgevoerd vóór een overschrijving wordt uitgevoerd, niet erna.
- De regelgeving geldt ongeacht of de overschrijving standaard of instant is.
- Als initiërende PSP bent u aansprakelijk voor fraude als u geen VoP-controle uitvoert of als u uw klant bij twijfel geen waarschuwing toont vóór de betaling. In dat geval moet u uw klant terugbetalen.
De EPC heeft het technische VoP Rulebook gepubliceerd, dat de schemaregels, de ondersteunde dataformaten, de aanvaarde matchresultaten en de verplichtingen van elke deelnemer definieert. Naleving van het EPC-schema geeft een VoP-implementatie haar juridische en technische geldigheid.
Welke landen zijn betrokken, en wanneer?
De uitrol gebeurt in twee golven, afhankelijk van de valuta.
1. Golf 1: landen van de eurozone (20 lidstaten, deadline 9 oktober 2025)
Oostenrijk, België, Cyprus, Duitsland, Estland, Spanje, Finland, Frankrijk, Griekenland, Kroatië, Ierland, Italië, Litouwen, Luxemburg, Letland, Malta, Nederland, Portugal, Slovenië, Slovakije.
2. Golf 2: EU-lidstaten met een niet-euromunt (7 landen, deadline 9 juli 2027)
Bulgarije, Tsjechië, Denemarken, Hongarije, Polen, Roemenië, Zweden.
3. Buiten de EU: andere SEPA-landen
Landen zoals het Verenigd Koninkrijk, Zwitserland, Noorwegen, IJsland en Liechtenstein vallen binnen de scope van het EPC VoP-schema, maar zijn niet gebonden aan de deadlines van de EU-regelgeving. Hun adoptie hangt af van lokale wetgeving en van de vrijwillige aansluiting van hun PSP’s bij het EPC VoP Rulebook.
In de praktijk betekent dit: als uw bedrijf, uw klanten of de gebruikers van uw software betrokken zijn bij betalingen van of naar een rekening in de eurozone, is VoP vandaag al actief en verplicht.
Voor softwareontwikkelaars: waarom een VoP API integreren?
Als u software bouwt die raakt aan betalingen, bankrekeningen of leveranciersgegevens, dan is Verification of Payee niet het probleem van iemand anders: het is ook het uwe.
Denk aan de momenten waarop IBAN’s uw systeem binnenkomen:
- Een nieuwe leverancier wordt aangemaakt in uw ERP of accounts payable-platform.
- De salarisrekening van een werknemer wordt bijgewerkt in uw payrollsoftware.
- Een klant geeft zijn bankgegevens door voor een SEPA-domiciliëringsmandaat.
- Een terugbetaling of vergoeding wordt via uw platform geïnitieerd.
- Een betalingsbestand wordt voorbereid en naar de bank geëxporteerd.
Elk van deze momenten is een kans voor een foutief, frauduleus of toevallig verkeerd IBAN om het systeem binnen te komen. En elk van deze momenten is ook een kans waarop een VoP-controle dat kan voorkomen.
Uw gebruikers, zoals finance teams, boekhouders en treasury managers, verwachten niet dat ze IBAN’s manueel moeten controleren. Ze vertrouwen erop dat uw software hen helpt om veilig te werken. VoP integreren betekent dat uw product doet wat zij nodig hebben, op het juiste moment en zonder extra frictie.
De waardepropositie voor softwareontwikkelaars is drieledig:
- Regelgevende druk: uw PSP- en bankklanten zijn al verplicht om VoP te ondersteunen. Als uw software hun betalingsstromen voedt, maakt u deel uit van die veilige keten.
- Commerciële differentiatie: native VoP-verificatie aanbieden is een echte productdifferentiator, een functionaliteit waar finance buyers steeds vaker naar zullen vragen.
- Beperking van aansprakelijkheid: bij een fraude-incident zal de vraag worden gesteld: “Had uw software dit kunnen signaleren?” Een geïntegreerde VoP-controle is het antwoord.
Q&A: alles wat softwareontwikkelaars vragen over VoP-integratie
Welke types software vallen rechtstreeks binnen de scope?
Elke software die IBAN’s verzamelt, opslaat of verwerkt in een betalingscontext is relevant.
De meest voorkomende categorieën zijn:
- ERP-systemen: leveranciersmasterdata, betalingsruns.
- Accounts payable- en P2P-platformen: factuurverwerking, goedkeuringsflows voor betalingen.
- Payrollsoftware: beheer van bankrekeningen van werknemers.
- Treasury management-systemen: registers van bankrekeningen, betalingsinitiatie.
- E-invoicingplatformen: leveranciersportalen, beheer van remittance-informatie.
- Abonnements- en SaaS-facturatie: aanmaak van SEPA-domiciliëringsmandaten.
- Marketplaces en payout-platformen: uitbetalingen aan verkopers, affiliates of partners.
Als uw product een veld heeft met de naam “IBAN”, dan heeft VoP een use case.
Mijn software initieert niet rechtstreeks betalingen. Is VoP dan nog relevant?
Ja, en dat is een belangrijk punt. De waarde van Verification of Payee ligt niet alleen op het moment waarop de betaling wordt uitgevoerd. De verificatie van de naam van de begunstigde is minstens even waardevol wanneer een IBAN voor het eerst in uw systeem wordt ingevoerd.
Als uw software het IBAN van een leverancier, de bankrekening van een werknemer of de mandaatgegevens van een klant opslaat, bent u de eerste verdedigingslinie. Tegen de tijd dat een betaling wordt geïnitieerd, door uw software of door een externe bank, zit het IBAN al in het systeem en wordt het vaak impliciet vertrouwd.
Door VoP te integreren bij onboarding en datacaptatie, detecteert u frauduleuze of foutieve IBAN’s vóór ze problemen veroorzaken, niet erna.
Welke gegevens zijn nodig voor een VoP-aanvraag?
Een VoP-aanvraag vereist twee gegevens.
1. Het IBAN van de begunstigde
Het bankrekeningnummer waarop de betaling zal worden ontvangen.
2. Een verificatiereferentie
Ofwel:
- De naam van de begunstigde, bijvoorbeeld de volledige naam van een persoon of de officiële naam van een onderneming.
- Ofwel een erkende zakelijke identificator, zoals:
- Btw-nummer, of TXID.
- Legal Entity Identifier, of LEI.
- Bank Identifier Code, of BIC.
- SIREN / SIRET, voor Frankrijk.
- Certificate of Incorporation Number.
- D-U-N-S-nummer.
Verificatie op basis van de naam is de meest ondersteunde en aanbevolen aanpak. Verificatie op basis van een identificator kan nuttig zijn wanneer de exacte naam onzeker is, bijvoorbeeld bij de onboarding van een nieuwe B2B-leverancier waarbij het btw-nummer als primaire referentie wordt gebruikt.
Hoe ziet de API-respons er in de praktijk uit?
Hieronder staat een vereenvoudigd voorbeeld van een VoP API-call en respons met de API van Digiteal.
Request:
```bash
POST /api/v1/ibanAccountHolderVerification
{
"iban": "BE03130000000184",
"name": "Digiteal SA"
}
```
Response — Match:
```json
{
"vopMatchResult": { "result": "MATCH" },
"bankAccountHolder": { "name": "Digiteal SA" },
"bank": { "bic": "DIGEBEB2", "name": "DIGITEAL SA" }
}
```
Response — Close match (name provided: "Digiteal", missing the "SA" suffix):
```json
{
"vopMatchResult": { "result": "CLOSE_MATCH" },
"bankAccountHolder": { "name": "Digiteal SA" },
"bank": { "bic": "DIGEBEB2", "name": "DIGITEAL SA" }
}
```
Response — No match (name provided: "John Doe"):
```json
{
"vopMatchResult": { "result": "NO_MATCH" },
"bank": { "bic": "DIGEBEB2", "name": "DIGITEAL SA" }
}
```
Elke respons bevat ook een tijdstempel en een unieke request-id in de responseheaders, voor audittraildoeleinden.
Hoe moeten we elk resultaat in onze UX verwerken?
De aanbevolen aanpak houdt het evenwicht tussen veiligheid en gebruiksvriendelijkheid. VoP is ontworpen om te informeren, niet om automatisch te blokkeren.
| Resultaat | eAanbevolen UX-patroon |
|---|---|
| MATCH | Automatisch doorgaan: geen extra frictie nodig. |
| CLOSE_MATCH | Een waarschuwing tonen met het vastgestelde verschil. De gebruiker vragen om te bevestigen of te controleren vóór hij doorgaat. |
| NO_MATCH | De actie blokkeren of een verplichte manuele review opleggen, met een duidelijke uitleg waarom. |
| NO_AP | Aangeven dat verificatie voor deze rekening niet mogelijk was. Indien beschikbaar alternatieve verificatiemethoden toepassen. |
Een essentieel ontwerpprincipe: nooit stilzwijgend blokkeren en nooit onnodig alarmeren. Een close match op een bedrijfsnaam, omdat een gebruiker “Acme Corp” invoerde in plaats van “Acme Corporation”, is op zich geen fraudesignaal. Het is een uitnodiging om te controleren. Uw UX moet dat onderscheid duidelijk maken.
Equally important: always log the VoP result, even when the payment proceeds. This creates an audit trail that demonstrates due diligence, which becomes critical in the event of a dispute or investigation.
Hoe gaat VoP om met benaderende namen, afkortingen en speciale tekens?
Hier blijkt de intelligentie van een goede VoP-implementatie.
Het matchingalgoritme aan de kant van de uitgevende bank houdt rekening met een reeks vaak voorkomende variaties:
- Afkortingen van rechtsvormen, zoals SA, SRL, GmbH of Ltd, die al dan niet aanwezig kunnen zijn.
- Veelvoorkomende typefouten en omwisselingsfouten.
- Letters met accenten en hun equivalenten zonder accenten.
- Handelsnamen versus officiële juridische namen, afhankelijk van wat de bank geregistreerd heeft.
- Omkering van voornaam en familienaam bij natuurlijke personen.
Wanneer zo’n variatie wordt gedetecteerd, is het resultaat CLOSE_MATCH in plaats van MATCH. Zo kan uw systeem het verschil aan een menselijke reviewer tonen in plaats van de actie automatisch te blokkeren.
Een praktische opmerking: de kwaliteit van uw uitgaande data telt. Als uw leveranciersmasterdata slecht onderhouden is, met afgekorte namen, oude handelsnamen of ontbrekende juridische achtervoegsels, zult u meer close matches zien dan nodig. VoP-integratie is dus ook een kans om uw referentiedata te controleren en op te schonen.
Kunnen we een volledige leveranciersdatabase in bulk verifiëren?
Ja. Bulkverificatie is een van de krachtigste use cases voor softwareontwikkelaars.
Het typische scenario: een bedrijf heeft duizenden IBAN’s opgeslagen in zijn ERP of accounts payable-platform. Die zijn nooit systematisch gecontroleerd. Door een VoP API te integreren, kunt u een eenmalige of periodieke bulkcontrole van de volledige database aanbieden, waarbij verdachte records worden gemarkeerd vóór ze ooit in een betalingsrun terechtkomen.
Praktische aandachtspunten bij bulkverificatie:
- Het principe van betalingsintentie blijft gelden.
- Bulkcontroles worden doorgaans gerechtvaardigd als risicobeheersmaatregel in de context van komende betalingsoperaties.
- Rate limits en volumetarifering moeten met uw VoP-provider worden besproken.
- De output van een bulkcontrole moet een reviewworkflow voeden, niet automatisch records verwijderen. Menselijke beoordeling blijft nodig voor randgevallen.
Dit is een bijzonder sterke functionaliteit voor ERP-leveranciers en accounts payable-platformen, waar een workflow zoals “schoon uw bankgegevens van leveranciers op” een premiumaanbod op zich kan zijn.
Wat is de geografische dekking? En wat met IBAN’s buiten de eurozone?
Sinds oktober 2025 is VoP operationeel voor IBAN’s uit de eurozone, dus de 20 EU-lidstaten die de euro als munt hebben. Dit dekt het overgrote deel van het SEPA-betalingsvolume.
Voor IBAN’s uit EU-lidstaten buiten de eurozone, zoals Polen, Denemarken of Tsjechië, wordt verplichte compliance van kracht in juli 2027, maar sommige banken in die landen kunnen VoP al ondersteunen.
Voor IBAN’s uit SEPA-landen buiten de EU, zoals het Verenigd Koninkrijk, Zwitserland of Noorwegen, hangt de beschikbaarheid af van de deelname van de individuele bank aan het EPC VoP-schema.
Wanneer een VoP-controle wordt aangevraagd voor een IBAN waarvan de uitgevende bank nog niet op het schema is aangesloten, zal de respons NO_AP zijn, of not applicable. Uw systeem moet dit op een soepele manier verwerken: het betekent niet dat de betaling verdacht is, maar enkel dat verificatie momenteel niet beschikbaar is voor die rekening.
Hoelang duurt de integratie? Wat is de echte technische inspanning?
Het korte antwoord: maximaal enkele dagen.
De VoP API van Digiteal is een eenvoudige REST/JSON-interface met Basic Authentication. De kernintegratie, via één POST-endpoint, kan in elke moderne development stack worden geïmplementeerd.
Er zijn SDK’s beschikbaar voor onder meer Java, .NET, Python en PHP.
Wat VoP complex maakt om van nul op te bouwen, is niet de API-call zelf. Het is alles errond: registratie bij het EPC-schema en de EDS Directory Service, implementatie van de RVM-routeringslogica om voor elk IBAN de juiste bank te vinden, blijvende compliance met het EPC VoP Rulebook wanneer dat evolueert, het indienen van kwartaalrapporten met statistieken bij de EPC, en het beheer van certificering en conformiteitstests.
Door de API van Digiteal te integreren, wordt dat allemaal voor u geregeld. Uw engineeringteam schrijft de API-call en de UX-logica. Wij beheren de regelgevende infrastructuur.
Een sandboxomgeving is vanaf dag één beschikbaar voor integratietests. De overgang naar productie is eenvoudig, met toegewijde developersupport.
Wat is het businessmodel? Kunnen we dit monetiseren naar onze eigen klanten?
VoP-integratie kan op verschillende manieren worden gestructureerd, afhankelijk van uw productmodel.
Als inbegrepen functionaliteit
U absorbeert de API-kost en positioneert VoP als een vertrouwens- en veiligheidsfunctie die inbegrepen is in uw standaardaanbod. Dit versterkt de concurrentiepositie van uw product en kan churn verminderen door uw platform waardevoller te maken voor klanten met gevoelige financiële processen.
Als premium module
U biedt VoP aan als optionele add-on voor klanten die hun betalingsveiligheid willen verhogen. Dit is bijzonder relevant voor ERP- en accounts payable-platformen waarvan enterprise klanten zelf onder druk staan van hun compliance- en risicoteams.
Als gebruiksgebaseerde functionaliteit
Voor platformen met variabele betalingsvolumes, zoals marketplaces, payrollproviders of payout-platformen, kan een prijs per verificatie worden doorgerekend aan klanten, al dan niet met marge.
De ROI-berekening is eenvoudig: één vermeden frauduleuze overschrijving, vaak ter waarde van tienduizenden euro’s, dekt jaren aan VoP API-kosten. Wanneer u het zo kadert in een gesprek met een CFO, verandert de vraag van “is dit de moeite waard?” naar “waarom hebben we dit nog niet gedaan?”
Hoe werkt de VoP API van Digiteal?
Digiteal is een betalingsinstelling erkend door de Nationale Bank van België en ISO/IEC 27001:2022-gecertificeerd voor informatiebeveiligingsbeheer
Onze VoP-dienst is conform het VoP Rulebook van de European Payments Council, of EPC, en draait in een live productieomgeving met een SLA-gedekte beschikbaarheidsgarantie.
De verificatieflow
Vier integratiepunten in uw betalingscyclus
Klaar om Verification of Payee te integreren?
Neem contact op met ons team via het contactformulier op onze website om toegang tot de sandboxomgeving aan te vragen, uw API-credentials te ontvangen en uw integratiebehoeften te bespreken.
