Wanneer teams de Verification of Payee plannen, stellen ze zich de aanvragende kant voor: een klant voert een naam en IBAN in, en de bank controleert die vóór verzending. Maar die controle werkt alleen omdat de bank van de begunstigde antwoordt. Die bank is de beantwoordende PSP — en in het schema moeten de meeste instellingen beide rollen spelen.
Aanvragend vs beantwoordend
De aanvragende PSP vraagt 'komt deze naam overeen met deze IBAN?' namens een betaler. De beantwoordende PSP ontvangt die vraag over een van zijn eigen rekeninghouders en antwoordt met een gestandaardiseerde uitkomst. Als u klantrekeningen aanhoudt, zullen andere banken het u vragen — dus u moet kunnen antwoorden.
Naleving is meestal tweezijdig
De VoP aan uw betalers aanbieden (aanvragend) en verzoeken over uw klanten beantwoorden (beantwoordend) zijn verschillende bouwwerken. Plan beide, niet alleen het gebruikersgerichte.
Wat een beantwoordende PSP moet implementeren
- 1 Verificatieverzoeken van andere PSP's in het schema veilig ontvangen.
- 2 De gevraagde naam matchen tegen uw rekeninghouderregistraties, inclusief het afhandelen van gedeeltelijke overeenkomsten.
- 3 De gestandaardiseerde uitkomst (overeenkomst, gedeeltelijk, geen overeenkomst, niet van toepassing) met de juiste schemacode teruggeven.
- 4 Snel en betrouwbaar antwoorden — latentie en beschikbaarheid maken deel uit van de verplichting.
Beide doen via één verbinding
Beantwoordingsinfrastructuur bouwen en onderhouden — matchinglogica, uptime, schemaberichten — is aanzienlijk. Opereren op een aanbieder die al met het SEPA-VoP-schema verbonden is laat u zowel aanvragen als beantwoorden afdekken via één integratie. RoxPay opereert op het SEPA-schema en geeft gestandaardiseerde uitkomsten terug met de BIC van de beantwoordende bank, zodat één verbinding de verificatie door heel Europa bereikt.