EBA verduidelijkt een aantal belemmeringen voor derden-betalingsdienstaanbieders

Author info

Op 4 juni 2020 heeft de Europese Bankautoriteit (EBA) een advies gepubliceerd over bepaalde belemmeringen voor het aanbieden van derden-betalingsdiensten in het kader van de tweede richtlijn betalingsdiensten (PSD2). Deze richtlijn is sinds begin 2018 van toepassing en voegt een aantal nieuwe betalingsdienstaanbieders toe aan het betalingslandschap van de EU, namelijk aanbieders van rekeninginformatiediensten (AISP's) en aanbieders van betalingsinitiatiediensten (PISP's). Deze zogenaamde derde-partijaanbieders (TPP's) moeten zich kunnen aansluiten bij de betalingsdienstaanbieders (ASPSP's) van hun gebruikers, meestal een bank, om hun diensten te kunnen verlenen. Om een dergelijke verbinding tot stand te brengen, zijn veilige toegangsinterfaces nodig. 

De EBA heeft al regelgevende technische normen geformuleerd voor sterke klantauthenticatie (SCA) en gemeenschappelijke en veilige communicatie (CSC). Deze vereisen ASPSP's die speciale interfaces hebben geïmplementeerd om ervoor te zorgen dat er geen belemmeringen worden gecreëerd voor het verstrekken van rekeninginformatie of betalingsinitiatiediensten. In de normen is echter niet volledig gespecificeerd hoe dit in de praktijk moet worden geoperationaliseerd en welke marktpraktijken als belemmeringen kunnen worden beschouwd. 

Met dit nieuwe advies wil de EBA een aantal zaken verduidelijken om klanten in staat te stellen gebruik te maken van de nieuwe en innovatieve betaaldiensten die TPP's aanbieden. De bevoegde autoriteiten in de lidstaten moeten nu maatregelen nemen om ervoor te zorgen dat de ASPSP's die onder hun toezicht staan, zonder belemmeringen interfaces aanbieden die aan de eisen voldoen.

In deze blogpost gaan we kort in op dit advies om te zien wat het in de praktijk betekent.

1. Authenticatieprocedures

AISP's en PISP's moeten kunnen vertrouwen op de authenticatieprocedures die door de ASPSP's aan hun gebruikers worden verstrekt. Alle ondersteunde authenticatieprocedures moeten daarom ook aan de AISP's en de PISP's ter beschikking worden gesteld. Indien een bank haar gebruikers bijvoorbeeld toestaat in te loggen op het platform voor onlinebankieren met behulp van biometrische gegevens, dient deze optie ook beschikbaar te zijn wanneer de gebruiker zich via de AISP of de PISP authenticeert. Vanuit technisch oogpunt kan dit de ondersteuning van ontkoppelde authenticatie of app-to-app redirection naar de authenticatie-app van de ASPSP en een veilige overdracht van de authenticatiestatus vereisen.

Het niet aanbieden van alle authenticatieopties die beschikbaar zijn voor gebruikers aan PISP's en AISP's zou dan als een obstakel worden beschouwd. Het omleiden of ontkoppelen mag ook geen onnodige wrijving veroorzaken - bijvoorbeeld door extra stappen voor de gebruiker te creëren. Het sturen van de gebruiker via een omleiding van de mobiele browser naar de app of het handmatig (her)openen van apps zou onnodige wrijving opleveren. 

2. Verplichte omleiding

Omleiding (‘redirection’) wordt door veel TPP's gezien als een obstakel, omdat het beperkt is tot browsers en mobiele apps, en dus beperkt het de manier waarop betalingen kunnen worden geïnitieerd. Volgens de EBA is een dergelijke omleiding alleen een obstakel als andere authenticatiemogelijkheden aan de gebruiker worden aangeboden en niet aan de PISP of AISP ter beschikking worden gesteld. Als een bepaalde authenticatieoptie de enige oplossing is die de ASPSP aan haar gebruikers biedt, is zij niet verplicht om andere benaderingen aan de PISP's of AISP’s aan te bieden. Als de ASPSP echter bijvoorbeeld onmiddellijke betalingen op het verkooppunt aan haar gebruikers zou aanbieden, zou zij haar gebruikers ook in staat moeten stellen onmiddellijke betalingen met hetzelfde bedrag te initiëren met behulp van de diensten van een PISP.

3. Meerdere authenticaties

Voor de authenticatieprocedure met AISP's of PISP's mogen niet meer SCA's nodig zijn dan voor de procedure met alleen de gebruiker en zijn ASPSP. In het geval van PISP's waarbij de noodzakelijke informatie wordt overgedragen, zou één enkele SCA moeten volstaan om de betaling in gang te zetten. Het vereisen van meer SCA's in een dergelijk scenario zou dus een obstakel vormen. Alleen onderbouwde veiligheidsargumenten - zoals een vermoeden van fraude - zouden hier meerdere SCA's moeten rechtvaardigen. Wanneer niet alle informatie wordt overgedragen - bijvoorbeeld wanneer de te debiteren rekening door de gebruiker bij de ASPSP moet worden geselecteerd - kunnen meerdere authenticaties worden gerechtvaardigd. Ook bij het combineren van AIS en PIS kunnen meerdere SCA's nodig zijn. 

4. 90 dagen herauthenticatie

Gebruikers moeten zich ten minste om de 90 dagen opnieuw authenticeren met hun ASPSP. Sommige AISP's hebben hun bezorgdheid hierover geuit, met het argument dat als hun gebruikers accounts hebben bij meerdere ASPSP's, zij om de 90 dagen door SCA’s voor alle accounts zouden moeten gaan om de AISP's hun diensten te laten leveren. 

Hier herinnert de EBA de AISP's eraan dat zij in de eerste plaats de hele tijd SCA moeten uitvoeren. Een uitzondering in de regelgevende technische normen staat hen toe om geen SCA uit te voeren wanneer ze slechts een beperkte reeks gegevens tonen, maar zelfs dan moeten ze nog steeds elke 90 dagen opnieuw authenticeren. Om de wrijving tot een minimum te beperken, ondersteunt de EBA het gebruik van de uitzondering, maar handhaaft zij het herauthenticatieprincipe van 90 dagen. Herauthenticatie moet worden uitgevoerd door de ASPSP, maar dit kan worden gedelegeerd aan de TPP.

5. Selectie van de rekening

Er zijn enkele gevallen gemeld waarin de gebruiker zijn IBAN handmatig moet invoeren wanneer hij van de AISP of PISP naar het domein van de ASPSP gaat. Een dergelijke handmatige invoer kan volgens de EBA worden beschouwd als een obstakel. ASPSP’s zouden bijvoorbeeld de gebruiker van de AISP in staat kunnen stellen om via de interface een lijst van de accounts van de gebruiker op te vragen, zodat de gebruiker het juiste account kan selecteren in plaats van deze handmatig in te voeren. Ook in het geval van omleiding zou de selectie van een account mogelijk kunnen worden gemaakt op het domein van de ASPSP na authenticatie. Dit betekent echter niet dat een PISP toegang zou moeten krijgen tot de lijst van alle accounts van de gebruiker, aangezien dit buiten het bereik zou vallen. 

6. Extra controles om toestemming te geven

De technische regelgevingsnormen hebben al duidelijk gemaakt dat ASPSP's die hun gebruikers om extra toestemming vragen om gebruik te kunnen maken van de diensten van een TPP, een obstakel vormen. De TPP zelf moet bij het gebruik van de dienst de toestemming van de gebruiker krijgen en er is dus geen tweede controle van de toestemming door de ASPSP nodig. 

7. Extra registraties

De eis dat TPP's bij elke ASPSP een extra registratieproces moeten doorlopen, wordt beschouwd als een obstakel. Er kan enige registratie nodig zijn om de hier vereiste beveiligde communicatie tot stand te brengen, maar dit moet beperkt blijven tot wat technisch noodzakelijk is en niet verder gaan. Een preregistratie van de TPP met zijn contactgegevens bij een ASPSP zou dan als een obstakel worden beschouwd. 

8. Conclusie 

Het advies van de EBA geeft een paar welkome verduidelijkingen over de vragen die na de implementatie van de PSD2 zijn gebleven. Het is duidelijk dat sommige ASPSP's aarzelden om zich open te stellen voor TPP's, en deze aarzeling heeft geleid tot belemmeringen die verhinderen dat TPP's hun volledige potentieel bereiken.

Uiteindelijk betalen de gebruikers de prijs voor die obstakels, omdat het gebruik van TPP's omslachtiger wordt gemaakt dan nodig is. Met de verduidelijkingen van de EBA zullen enkele van de meest urgente obstakels nu moeten worden weggenomen, wat de TPP's en hun gebruikers ten goede zal komen.

Heeft u nog vragen over deze mening of over uw betalingsdiensten? Neem dan contact op met Timelex.