The European Banking Authority released the final draft of the Regulatory Technical Specifications for PSD2 this week. It contains several improvements and clarifications, but there are still a few areas that fall short of industry expectations.
After the release of the initial drafts, EBA received a multitude of comments and discussion from many organizations and software vendors. One of the top concerns was on the mandate for Strong Customer Authentication (SCA), which was defined traditionally as something you have, something you know, or something you are. Originally it was conceived to apply to any transaction over €10. The limit has been raised to €30, which is better, but still less than the recommended €50.
The revision also takes into account the innovations and benefits of risk-adaptive authentication. Risk-adaptive authentication encompasses several functions, including user behavioral analytics (UBA), two- or multi-factor authentication (2FA or MFA), and policy evaluation. Risk-adaptive authentication platforms evaluate a configurable set of real-time risk factors against pre-defined policies to determine a variety of outcomes. The policy evaluation can yield permit, deny, or “step-up authentication” required.
PSD2 RTS stipulates that banks (Account Servicing Payment Service Providers, or ASPSPs) must consider the following transactional fraud risk detection elements on a per-transaction basis:
- lists of compromised or stolen authentication elements;
- the amount of each payment transaction;
- known fraud scenarios in the provision of payment services;
- signs of malware infection in any sessions of the authentication procedure
Items 1-3 are commonly examined in many banking transactions today. The prescription to look for signs of malware infection is somewhat vague and difficult to achieve technically. Is the bank responsible for knowing the endpoint security posture of all of its clients? If so, is it responsible also for helping remediate malware on clients?
Furthermore, in promoting “continuous authentication” via risk-adaptive authentication, EBA states:
- the previous spending patterns of the individual payment service user;
- the payment transaction history of each of the payment service provider’s payment service user;
- the location of the payer and of the payee at the time of the payment transaction providing the access device or the software is provided by the payment service provider;
- the abnormal behavioural payment patterns of the payment service user in relation to the payment transaction history;
- in case the access device or the software is provided by the payment service provider, a log of the use of the access device or the software provided to the payment service user and the abnormal use of the access device or the software.
The requirements described above, from the PSD2 RTS document, are very much a “light” version of risk-adaptive authentication and UBA. These attributes are useful in predicting the authenticity of the current user of the services. However, there are additional attributes that many risk-adaptive authentication vendors commonly evaluate that would add value to the notion and practice of fraud risk reduction. For example:
- Geo-velocity
- IP address
- Time of day/week
- Device ID
- Device fingerprint
- Known compromised IP/network check
- User attributes
- User on new device check
- Jailbroken mobile device check
Now that limited risk analytics are included in the PSD2 paradigm, the requirement for SCA is reduced to at least once per 90 days. This, too, is in line with the way most modern risk-adaptive authentication systems work.
The PSD2 RTS leaves in place “screen-scraping” for an additional 18 months, a known bad practice that current Third Party Providers (TPPs) use to extract usernames and passwords from HTML forms. This practice is not only subject to Man-in-the-Middle (MITM) attacks, but also perpetuates the use of low assurance username/password authentication. Given that cyber criminals now know that they only have a limited amount of time to exploit this weak mechanism, look for an increase in attacks on TPPs and banks using screen-scraping methods.
In summary, the final draft of PSD2 RTS does make some security improvements, but omits recommending practices that would more significantly and positively affect security in the payments industry, while leaving in place the screen-scraping vulnerability for a while longer.