Wanneer teams Verification of Payee plannen, denken ze aan de aanvragende kant: een klant voert een naam en IBAN in, en de bank controleert dit voordat het geld wordt verstuurd. Maar die controle werkt alleen omdat de bank van de begunstigde antwoordt. Die bank is de beantwoordende PSP — en binnen het schema moeten de meeste instellingen beide rollen vervullen.
Aanvragend versus beantwoordend
De aanvragende PSP stelt de vraag 'komt deze naam overeen met dit IBAN?' namens een betaler. De beantwoordende PSP ontvangt die vraag over een van haar eigen rekeninghouders en antwoordt met een gestandaardiseerde uitkomst. Als u klantrekeningen aanhoudt, zullen andere banken u die vraag stellen — u moet dus in staat zijn te antwoorden.
Naleving is meestal tweezijdig
VoP aanbieden aan uw betalers (aanvragend) en verzoeken over uw klanten beantwoorden (beantwoordend) zijn twee verschillende bouwtrajecten. Plan voor beide, niet alleen voor het deel dat de gebruiker ziet.
Wat een beantwoordende PSP moet implementeren
- 1 Verificatieverzoeken van andere PSP's binnen het schema veilig ontvangen.
- 2 De gevraagde naam vergelijken met uw rekeninghoudergegevens, inclusief het afhandelen van gedeeltelijke overeenkomsten.
- 3 De gestandaardiseerde uitkomst teruggeven (overeenkomst, gedeeltelijke overeenkomst, geen overeenkomst, niet van toepassing) met de juiste schemacode.
- 4 Snel en betrouwbaar antwoorden — latentie en beschikbaarheid maken deel uit van de verplichting.
Beide rollen via één verbinding
Het opbouwen en onderhouden van responder-infrastructuur — matchinglogica, uptime, schemaberichten — is een aanzienlijke inspanning. Door te werken met een provider die al is aangesloten op het SEPA VoP-schema, dekt u zowel de aanvragende als de beantwoordende rol via één integratie. RoxPay is aangesloten op het SEPA-schema en geeft gestandaardiseerde uitkomsten terug met de BIC van de beantwoordende bank, zodat één verbinding verificatie in heel Europa mogelijk maakt.