|
|
The API interface must allow PSPs to rely on all authentication methods and processes issued by the ASPSP to PSUs and AISPs/PISPs cannot be prevented from using the ASPSP-issued PSU credentials.
An ASPSP will need to be able to demonstrate, amongst other criteria, that their API interface has been widely used for at least 3 months by PSPs to benefit from a fallback-exemption under the RTS.
The identification and authentication journey, facilitated by the API interface, is a critical component as it has a key impact on the experience of the PSU.
The range of authentication methods and processes (e.g. redirection, embedded, decoupled/redirect and decoupled/embedded - see slide 6&7 for overview) and the design of those to enable SCAshould be supported by the API initiatives.
The API initiatives should define specifications that support all SCA methods and processes and should not only support the redirection method – thus a spectrum of options would be supported. This will enable an ASPSPto implement one, or more, authentication method and process in a standardised uniform way within the framework of the API initiative and to facilitate market choice.
The spectrum of options and the decision of the ASPSP to implement one or more authentication method(s) inherently involves trade offs between risk, liability, space to innovate, business models etc. For example an API interface that allows the PSP to be able to securely transmit the ASPSP-issued PSU credentials (e.g. decoupled/embedded) is more likely to be widely used by PSPs. It however trades off the fact that the PSU will be required to communicate their ASPSP-issued credentials to the PSP.