Banking
THE PSD2 FINAL RTS: 10 THINGS YOU NEED TO KNOW
THE PSD2 FINAL RTS: 10 THINGS YOU NEED TO KNOW
Published by Gbaf News
Posted on March 16, 2017
Global Banking and Finance Review
Company
Published by Gbaf News
Posted on March 16, 2017
Tom Hay – Head of Payments at Icon Solutions
The wait is over. The European Banking Authority (EBA) has recently published its ‘final’ draft Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and common and secure communication under PSD2. PSD2 and particularly the SCA aspect has the potential to dramatically change not just the payments sector but the wider banking market and has been the subject of heated discussions and aggressive lobbying.
The market has therefore been waiting with bated breath to view and digest the finalised standards. The final RTS provides clarity on a number of ambiguities contained in the draft version and covers a great deal of ground. However, like a Christopher Nolan movie it still leaves you hanging with unanswered questions at the end.
With the document standing at more than 150 pages it can be difficult to identify the major points and key changes from the draft version. To help, here’s a distillation of the paper, covering ten points we believe the market needs to heed:
The RTS does not provide definitions of the interfaces needed. Luckily some industry groups (e.g. Berlin Group) have come together to define common standards, and the European Retail Payments Board (ERPB) has convened working groups to facilitate this process. It’s up to the banks to define their own interfaces, but at least they will have some de-facto standards to base them on.
Rationale 32 says that “screen scraping will no longer be allowed”, but something that looks a lot like screen scraping is still allowed. TPPs using this interface must digitally sign the messages to identify themselves, which is at least a step forward; however, other security holes associated with screen-scaping remain. Note that if a bank provides a “dedicated” (API) interface, TPPs must use it.
It is up to the bank to authenticate their customer. Recital 14 now says that “PIS Providers have the right to rely on the authentication procedures provided” by the bank, there is no right in the opposite direction. Therefore, PISPs (Payments Initiative Service Providers) must pass control to the bank to authenticate the customer – the PISP can’t apply its own authentication, then tell the bank to “just do it”.
Article 4.1 says that “The authentication code shall be accepted only once”. This is fine for a single payment initiation, but the RTS allows TPPs to initiate a series of payments, and to retrieve account information, with SCA applied only the first time. Presumably the original authorisation code must be presented for all subsequent accesses, but this is not compatible with the “only once” provision in 4.1.
For payment transactions, the authentication code has to be dynamically linked to the transaction details. There’s a possible gap because the amount and payee are dynamically linked, but not the payment reference. In cases where the reference determines the beneficiary, such as credit card payments, this could become a security vulnerability.
This is the area of the RTS that has changed most, and has become more practical. Changes include:
Whereas the previous draft mandated real time fraud detection to prevent, detect and block fraudulent payments, the final draft allows for a more nuanced risk analysis approach, with high risk transactions being blocked for suspected fraud, and low risk transactions potentially bypassing SCA. There is also a specific approach with clearer reporting and processing procedures.
The final draft still says that ASPSPs (account servicing payment service providers), effectively banks, must provide AIS with the same information from designated payment accounts and associated payment transactions made available to the payment service user when directly accessing the information, “provided that this information does not include display of sensitive payment data”. “Sensitive” is still not defined, leaving it to the bank to decide what to redact.
The EBA has put aside its doubts and firmly mandated the use of Digital Certificates (or “qualified certificates for electronic seals or website authentication”, as the regulation would have it) issued under Regulation 910/2014, aka eIDAS. Given the extended timeline for enforcement of the RTS – November 2018 being the earliest date, with serious discussion of April 2019 – there is still time for organizations to step up and put the required infrastructure in place to move eIDAS from dream to reality.
Unless a card transaction falls under one of the exemptions, it must go through SCA. Vendors have rushed out solutions such as Dynamic CVV, where the CVV on the card changes regularly. Using this as one of the SCA components proves possession, which along with knowledge satisfies the ‘two-factor’ requirement. It looks like 3d-Secure 2.0 will be sufficient to allow SCA exemptions to be applied, but if the transaction is not exempt, it’s up to the issuer to drive the SCA process.
The previous draft specified that multi-purpose devices (mobile phones and the like) had to use a Trusted Execution Environment (TEE) for security. TEE is a well-defined, tried and tested standard, but it seems the EBA has caved into pressure from organizations lobbying for non-standard (and in some cases less secure) solutions. The RTS now mandates a ‘Secure Execution Environment’ which has no current industry definition, so mobile security effectively becomes a free for all again. Caveat emptor!
What next?
The RTS has yet to be adopted by the European Commission, so there is still an opportunity for lobbying by Member States and industry groups and organizations. Be that as it may, it’s clear that no further significant clarifications will be forthcoming from the EBA. It’s now up to banks, TPPs and other payment service providers to get on with implementation, guided by national authorities, industry groups, compliance officers and technology experts. The “access to account” services specified in PSD2 Articles 65-67 have to be available from Jan 2018, and even though the security and communications standards in the RTS do not become mandatory until the end of the “transitional” period, there’s sufficient clarity to start moving in that direction prior to the mandate.
If you would like more information on the matter, you can read our ‘Fast Track to PSD2’ whitepaper.
Tom Hay – Head of Payments at Icon Solutions
The wait is over. The European Banking Authority (EBA) has recently published its ‘final’ draft Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and common and secure communication under PSD2. PSD2 and particularly the SCA aspect has the potential to dramatically change not just the payments sector but the wider banking market and has been the subject of heated discussions and aggressive lobbying.
The market has therefore been waiting with bated breath to view and digest the finalised standards. The final RTS provides clarity on a number of ambiguities contained in the draft version and covers a great deal of ground. However, like a Christopher Nolan movie it still leaves you hanging with unanswered questions at the end.
With the document standing at more than 150 pages it can be difficult to identify the major points and key changes from the draft version. To help, here’s a distillation of the paper, covering ten points we believe the market needs to heed:
The RTS does not provide definitions of the interfaces needed. Luckily some industry groups (e.g. Berlin Group) have come together to define common standards, and the European Retail Payments Board (ERPB) has convened working groups to facilitate this process. It’s up to the banks to define their own interfaces, but at least they will have some de-facto standards to base them on.
Rationale 32 says that “screen scraping will no longer be allowed”, but something that looks a lot like screen scraping is still allowed. TPPs using this interface must digitally sign the messages to identify themselves, which is at least a step forward; however, other security holes associated with screen-scaping remain. Note that if a bank provides a “dedicated” (API) interface, TPPs must use it.
It is up to the bank to authenticate their customer. Recital 14 now says that “PIS Providers have the right to rely on the authentication procedures provided” by the bank, there is no right in the opposite direction. Therefore, PISPs (Payments Initiative Service Providers) must pass control to the bank to authenticate the customer – the PISP can’t apply its own authentication, then tell the bank to “just do it”.
Article 4.1 says that “The authentication code shall be accepted only once”. This is fine for a single payment initiation, but the RTS allows TPPs to initiate a series of payments, and to retrieve account information, with SCA applied only the first time. Presumably the original authorisation code must be presented for all subsequent accesses, but this is not compatible with the “only once” provision in 4.1.
For payment transactions, the authentication code has to be dynamically linked to the transaction details. There’s a possible gap because the amount and payee are dynamically linked, but not the payment reference. In cases where the reference determines the beneficiary, such as credit card payments, this could become a security vulnerability.
This is the area of the RTS that has changed most, and has become more practical. Changes include:
Whereas the previous draft mandated real time fraud detection to prevent, detect and block fraudulent payments, the final draft allows for a more nuanced risk analysis approach, with high risk transactions being blocked for suspected fraud, and low risk transactions potentially bypassing SCA. There is also a specific approach with clearer reporting and processing procedures.
The final draft still says that ASPSPs (account servicing payment service providers), effectively banks, must provide AIS with the same information from designated payment accounts and associated payment transactions made available to the payment service user when directly accessing the information, “provided that this information does not include display of sensitive payment data”. “Sensitive” is still not defined, leaving it to the bank to decide what to redact.
The EBA has put aside its doubts and firmly mandated the use of Digital Certificates (or “qualified certificates for electronic seals or website authentication”, as the regulation would have it) issued under Regulation 910/2014, aka eIDAS. Given the extended timeline for enforcement of the RTS – November 2018 being the earliest date, with serious discussion of April 2019 – there is still time for organizations to step up and put the required infrastructure in place to move eIDAS from dream to reality.
Unless a card transaction falls under one of the exemptions, it must go through SCA. Vendors have rushed out solutions such as Dynamic CVV, where the CVV on the card changes regularly. Using this as one of the SCA components proves possession, which along with knowledge satisfies the ‘two-factor’ requirement. It looks like 3d-Secure 2.0 will be sufficient to allow SCA exemptions to be applied, but if the transaction is not exempt, it’s up to the issuer to drive the SCA process.
The previous draft specified that multi-purpose devices (mobile phones and the like) had to use a Trusted Execution Environment (TEE) for security. TEE is a well-defined, tried and tested standard, but it seems the EBA has caved into pressure from organizations lobbying for non-standard (and in some cases less secure) solutions. The RTS now mandates a ‘Secure Execution Environment’ which has no current industry definition, so mobile security effectively becomes a free for all again. Caveat emptor!
What next?
The RTS has yet to be adopted by the European Commission, so there is still an opportunity for lobbying by Member States and industry groups and organizations. Be that as it may, it’s clear that no further significant clarifications will be forthcoming from the EBA. It’s now up to banks, TPPs and other payment service providers to get on with implementation, guided by national authorities, industry groups, compliance officers and technology experts. The “access to account” services specified in PSD2 Articles 65-67 have to be available from Jan 2018, and even though the security and communications standards in the RTS do not become mandatory until the end of the “transitional” period, there’s sufficient clarity to start moving in that direction prior to the mandate.
If you would like more information on the matter, you can read our ‘Fast Track to PSD2’ whitepaper.
Explore more articles in the Banking category
