Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
According to RTS when API is provided TPPs must stop using classic online banking access. This unintentionally puts TPPs at mercy of ASPSPs when it comes to API quality. Experts expect that many ASPSPs will provide very low quality APIs due to lack of intrinsic motivation and limited technical resources. This may force existing TPPs out of the market as they have contractual QoS obligations which they won't be able to meet with classic online banking access forbidden and APIs not performing equally well.
PROPOSAL
(all three together apply)
1) Add explicit statement that TPPs should be allowed to continue using classic online banking access IF the ASPSP provided API does not meet or exceed the quality of the existing online banking with regard to reliability, data availability coverage, access speed, and authentication scenarios available.
2) Add obligation for ASPSPs to implement all new online banking features on top of their own API. This is a very good engineering practice anyway. By making it obligatory we can technically force API quality in the long term.
3) Introduce the transition period of 3 years during which both classic and API-based access is allowed to give ASPSPs time to mature the APIs while giving TPPs time to smoothly migrate to API usage.
RATIONALE
PSD2 is asking ASPSPs to provide the API for other companies so those companies can revolutionize payments in Europe. However, this revolution can be severely limited by the quality of banking API-s. Many banks have no intrinsic motivation to provide high quality API-s.
According to regulation the API should be at least of the quality of existing online banking. Realistically though, this is not enforceable by TPPs.
FinTech companies feel that most API-s will be erroneous, slow, unreliable, missing selected data, under-documented and flaky. FinTech companies may struggle to provide any meaningful service on top of the future banking API-s. At the same time the classic way of doing things (screen scraping") is aimed to be illegal once ASPSP provides the API. This puts PISPs and AISPs at the mercy of ASPSPs which undermines the very purpose of the PSD2."
There exists a very established security practice of asking for one-time-passwords ONLY for binding" actions like money-moving, ordering a new product or agreeing to a new ToS. Thus end-users learned to be very careful when providing OTPs.
Requiring OTPs ("authentication codes" as RTS calls them) ALSO for viewing or reading data blurs the line between the two and unintentionally DECREASES holistic security of the ecosystem. End-user psychology is a key factor in understanding security trade-offs. If end-users will be asked for OTP (authentication codes) for "trivial" actions they will become careless when providing them.
PROPOSAL
Do not require authentication code for read-only API access. This can be added as one of the exemptions."
Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
ISSUEAccording to RTS when API is provided TPPs must stop using classic online banking access. This unintentionally puts TPPs at mercy of ASPSPs when it comes to API quality. Experts expect that many ASPSPs will provide very low quality APIs due to lack of intrinsic motivation and limited technical resources. This may force existing TPPs out of the market as they have contractual QoS obligations which they won't be able to meet with classic online banking access forbidden and APIs not performing equally well.
PROPOSAL
(all three together apply)
1) Add explicit statement that TPPs should be allowed to continue using classic online banking access IF the ASPSP provided API does not meet or exceed the quality of the existing online banking with regard to reliability, data availability coverage, access speed, and authentication scenarios available.
2) Add obligation for ASPSPs to implement all new online banking features on top of their own API. This is a very good engineering practice anyway. By making it obligatory we can technically force API quality in the long term.
3) Introduce the transition period of 3 years during which both classic and API-based access is allowed to give ASPSPs time to mature the APIs while giving TPPs time to smoothly migrate to API usage.
RATIONALE
PSD2 is asking ASPSPs to provide the API for other companies so those companies can revolutionize payments in Europe. However, this revolution can be severely limited by the quality of banking API-s. Many banks have no intrinsic motivation to provide high quality API-s.
According to regulation the API should be at least of the quality of existing online banking. Realistically though, this is not enforceable by TPPs.
FinTech companies feel that most API-s will be erroneous, slow, unreliable, missing selected data, under-documented and flaky. FinTech companies may struggle to provide any meaningful service on top of the future banking API-s. At the same time the classic way of doing things (screen scraping") is aimed to be illegal once ASPSP provides the API. This puts PISPs and AISPs at the mercy of ASPSPs which undermines the very purpose of the PSD2."
Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?
ISSUEThere exists a very established security practice of asking for one-time-passwords ONLY for binding" actions like money-moving, ordering a new product or agreeing to a new ToS. Thus end-users learned to be very careful when providing OTPs.
Requiring OTPs ("authentication codes" as RTS calls them) ALSO for viewing or reading data blurs the line between the two and unintentionally DECREASES holistic security of the ecosystem. End-user psychology is a key factor in understanding security trade-offs. If end-users will be asked for OTP (authentication codes) for "trivial" actions they will become careless when providing them.
PROPOSAL
Do not require authentication code for read-only API access. This can be added as one of the exemptions."