PSD2 – Can your transaction risk analysis and strong customer authentication comply?

February 23, 2017 the European Banking Authority (EBA) released the Final Report of the Draft Regulatory Technical Standards on Strong Customer Authentication and Common Secure Communication for the Payment Services Directive 2 (PSD2).

This final report heralded a welcome change in the EBA’s position on the exemption to Strong Customer Authentication (SCA) based on transaction risk analysis. At first glance, this exemption looks quite tough to qualify for – but fortunately, RSA^® Fraud & Risk Intelligence Suite has operationally been helping its customers prevent fraud in harmony with current EBA expectations.

The major issue facing the financial industry was that the August 2016 Consultation Paper did not allow risk-based SCA. Instead, it defined a limit of €10, beyond which SCA for every transaction was mandatory. In essence, the frictionless customer experience that risk-based authentication provided was in danger of being eliminated. More than 220 responses to the consultation paper helped bring transaction risk analysis back to the final report. The EBA has allowed a new exemption based on transaction risk analysis – and now that the Final Report is out we can take a closer look at what we have to work with.

SCA Facts

Fundamentally, SCA is intended to secure the end user and help reduce fraud when accessing their account online, and performing payments or other actions online, which can be linked to fraud. Fraud is continuously changing. This includes not only new threats, but the new methods fraudsters are employing, such as leveraging social media to stay in the game. Thus, the financial services industry needs innovative and tested security products to keep fraud in check.

SCA is defined by the PSD2 as using at least two elements of: knowledge (e.g., PIN/password), possession (e.g., smart phone, hardware token), and inherence (e.g., biometrics). SCA itself also needs to be secure, so that its elements:

• cannot be disclosed (i.e., PINs/passwords need to be masked on screen) ^{[Chapter 2, Article 6]}
• cannot be replicated (i.e., device data can’t be copied to another device) ^[2,7]
• have low false positives (i.e., biometric methods need to perform well) ^[2,8]
• are independent (i.e., compromise of one element doesn’t compromise the others) ^[2,9,1]

Special attention is required for multipurpose smartphones and tablets to mitigate the risk of device compromise. Separate secure execution environments are required to secure the payment and the strong customer authentication. ^[2,9,3,a] The EBA doesn’t preclude achieving this in a single app combining payments and authentication, or two separate apps, such as an online banking app and a separate authentication app. Furthermore, the apps need to assess whether the device has been altered or compromised (e.g., jailbreak, rooted, emulator detection capabilities). ^[2,9,3,b]

The SCA process needs to confirm to the user the transaction amount and payee during the authentication ^[2,5,1,a], then create an authentication code or token specific for the transaction amount and the payee ^[2,5,1,b], such that it:

• is resistant to forgery ^[2,4,2,c]
• does not disclose its source elements ^[2,4,2,a]
• is used only once ^[2,4,1]
• cannot be used to generate a new code based on previous codes ^[2,4,2,b]

When authentication fails, institutions cannot identify which element of knowledge, possession, or inherence was incorrect. ^[2,4,3,a] Multiple authentication failures (maximum of five) result in a temporary or permanent account block; the user needs to be notified of a block and be provided a secure method to reverse the block. ^[2,4,3,b] User sessions need to timeout after five minutes of inactivity. ^[2,4,3,d]

Fixed exemptions for SCA

The exemptions for SCA are controversial, because of the need to find a balance between security, fraud reduction, innovation, competition, user-friendliness and accessibility, and at the same time, have guidelines that are clear and unambiguous. Across the EU there is a wide range of banking cultures, from existing strong customer authentication to single factor authentication, low fraud to high fraud, and given the PSD2 also introduces open banking to third parties this balance becomes more difficult to manage.

The SCA exemptions include a range of fixed rules, including:

• viewing only the balance ^[3,10,1,a] or last 90 days of transactions ^[3,10,1,b]
  • first time viewing the balance or transactions requires SCA ^[3,10,2,a]
  • after 90 days since last SCA need to authenticate again ^[3,10,2,b]
• contactless card transactions less than €50 ^[3,11,a]
  • SCA required again when accumulated contactless transactions value exceeds €150 or five transactions ^[3,11,b]
• card transactions at parking meters and toll gates ^[3,12]
• payments from and to accounts owned by the same user ^[3,14]
• payments to a previously created beneficiary ^[3,13,1,a]
  • creating or changing the beneficiary requires SCA ^[3,13,2,a]
• series of payments of the same amount to the same beneficiary ^[3,13,1,b]
  • the first payment, creating or changing the beneficiary requires SCA ^[3,13,2,b]
• low value transactions less than €30 ^[3,15,a]
  • SCA required when accumulated transaction value exceeds €100 or five transactions ^[3,15,b]

Transaction Risk Analysis

Beyond the fixed exemptions for SCA, the Final Report provides an exemption based on transaction risk analysis ^[3,16,1] allowing for risk-based authentication. However, the EBA has specified transaction thresholds up to €500 based on fraud rates where this exemption can apply. This means that the transaction risk analysis solution needs to perform to the specified fraud rates or risk-based authentication cannot be used. ^[3,16,2,a]

Transaction risk analysis needs, at a minimum, to include the following in the risk assessment: ^{[1,2,3],[1,2,4],[3,16,c]}

• abnormal spending behavioral patterns
• payment history of the user and the user population
• location of payer
• location of payee account
• lists of compromised or stolen authentication elements
• payment amount
• known fraud scenarios
• unusual information about the device or software
• signs of malware infection

It is clear to me, though, that a transaction risk analysis system needs to provide a lot more than the functions in this list in order to achieve the required fraud rates.

The reference fraud rates are calculated by the total value of the transactions for each payment type over a 90-day history: ^[3,16,d]

Note this is totaling the value, not the number, of transactions. The reference fraud rates are equivalent to fraud basis points divided by 100.

The reference fraud rates achieved are used to determine up to what threshold the exemption can apply. ^[3,16,b]

For example, if a bank achieves a three basis-point fraud rate for card-not-present (CNP) transactions the bank qualifies for a transaction risk analysis exemption for SCA on CNP transactions up to €250.

Monitoring SCA and Fraud Rates

A financial institution’s SCA methods must be documented, tested and audited by its independent auditor ^[1,3,1], including ongoing reporting of the fraud rates, to evaluate compliance to use the exemption for SCA. ^[3,16,e]

The financial institution’s fraud rate reports need to:

• be provided on at least a 90-day basis ^[3,17,1]
• be separated for each payment instrument ^[3,17,1]
• include the total value of fraudulent payment transactions ^[3,17,1,a]
• include the total value of all payment transactions ^[3,17,1,a]
• contain the observed fraud rates ^[3,17,1,a]
• contain a breakdown of payment totals with SCA and exempted ^[3,17,1,a]
• indicate the average transaction value with breakdown of SCA and exempted ^[3,17,1,b]
• list the number of transactions with exemptions and percentage to total number of transactions. ^[3,17,1,c]

When the observed fraud rates exceed the reference rates for 180 days, then the transaction risk analysis threshold needs to be lowered, or if below the lowest reference rate, the exemption can no longer be used. ^[3,18,1] The exemption may be re-instated when the observed fraud rate has been restored below the reference rate for 90 days. ^[3,18,2]

Conclusions

The financial services industry demanded transaction risk analysis in combination with SCA to maintain the frictionless customer experience. The EBA has conceded and allowed this in their Final Report. However, it seems at first glance the exemption reference fraud rates are quite restrictive, and the threshold maximum of €500 might be considered to be below the risk appetite of some in the industry. The EBA has the opportunity in the future to review and update the fraud rates, if necessary. ^[6,32] Transaction Risk Analysis defined with the thresholds and reference fraud rates does, however, provide what the EBA was tasked to do – provide a level playing field, and be legally acceptable.

RSA has observed a renewed industry interest in digital banking and card solutions not only in preparation for PSD2, but also the development of 3D Secure version 2.0. RSA is focused on building authentication methods that help customers determine how they can meet the requirements of SCA, while maintaining a user-friendly and frictionless customer experience. There will now be a new focus on the performance of the transaction risk analysis fraud detection rates, and of risk analysis tools used.

The RSA® Fraud & Risk Intelligence Suite has been providing risk based authentication and transaction risk analysis for more than a decade. Learn more about RSA’s Fraud & Risk Intelligence platform here.

Follow us on Twitter @RSAFraud @n8close

The post PSD2 – Can your transaction risk analysis and strong customer authentication comply? appeared first on Speaking of Security - The RSA Blog.