Zero to PSD2 in 8 Weeks
The European Commission’s Payment Services Directive 2 (PSD2) is helping to facilitate new opportunities and players within the payments market, but it is also creating substantial new obligations around security generally, and authentication specifically.
In short, unless an exception applies, moving forward, all online payments will require multi-factor authentication (Strong Customer Authentication or SCA). However, there are straight-forward exceptions to this somewhat cumbersome requirement. That said, in those instances where SCA is not required, there are still substantial reporting requirements to support and maintain the exception. And finally, the open API requirements of PSD2, are likely to open up additional threat vectors for fraudsters and bad actors, which need to be addressed.
In spite of these challenges, there are technology solutions, such as Simility, which can address each of these requirements seamlessly, avoiding the SCA requirement, reducing fraud and improving customer satisfaction.
Impacts of PSD2
PSD2 is a mandatory requirement by the European Commission to better regulate the EU payments industry while bringing new players into the payment market. A primary focus is on increasing the security of internet payments through strong customer authentication (SCA).
- PSD2 increases authentication requirements & friction for online transactions.
- PSD2 potentially increases financial institution (FI) threat exposure, bringing new, perhaps less security-conscious, third party providers (TPP) into the ecosystem via API.
The primary drivers for this EU Directive are improving payment security and reducing fraud in online payment transactions. Strong Customer Authentication is running on a slightly different timeline than the other parts of PSD2, with enforcement expected to start in late 2019.
There are two significant impacts from this directive. First, it dramatically expands the threat landscape by requiring all FIs to open up APIs to a huge ecosystem of unproven players. Second, it impacts costs and customer satisfaction by increasing the authentication requirements for online transactions.
Authentication Changes in the PSD2 World
Payment service providers must implement security measures which enable them to do the following:
- Apply SCA to every transaction; or,
- Avoid this SCA requirement, subject to specific conditions, based on the level of risk, the amount and the recurrence of the payment transaction and of the payment channel used for its execution.
What is SCA?
Strong Customer Authentication (SCA) is a mandatory method of authenticating online payments and/or customers, utilizing multiple factors, that will be required under PSD2 in 2019. In short, it requires the use of at least two of the following independent elements:
- Something that only the customer knows
For example, a password or PIN that is known only to the customer.
- Something that only the customer has or possesses
For example, a hardware token or mobile phone that is in the customer’s possession.
- Something that the customer is
For example, a fingerprint or facial recognition scan.
So, what’s wrong with that? The good news is, it should make it harder for fraudsters and criminals. The bad news is, it creates a substantial barrier for legitimate customer access as well…
Risk-Based Authentication – an Alternative to SCA
There are codified exceptions to the SCA requirements. These focus primarily on transactions where both the risk and the impact of fraudulent behavior is minimal. For example, paying a parking meter or checking an existing balance. The specific exclusions are as follows:
- Balance/recent payment history check
- Contactless POS
- Parking/Transport terminals
- Pre-defined list of trusted beneficiaries
- Subsequent recurring transactions
- Transfers between accounts of the same ownership
- Low-value transactions
- Below EUR 30 for a single transaction, and
- Below EUR 100 total since last SCA, and
- Below 5 Transactions since last SCA.
Avoid SCA Requirements for PSD2 compliance: Scenarios
In addition to the above list of exemptions, payment service providers shall be allowed not to apply strong customer authentication to transactions posing a low level of risk according to transaction monitoring mechanisms.
How one determines that a transaction poses a low level of risk can be a bit convoluted. In short, the service provider must track fraud rates such that it is able to characterize that the fraud rate for that type of transaction is below a pre-defined statutory limit and the amount of the transaction is below another pre-defined statutory limit. If those two elements are satisfied, the payment service provider must then perform a real time risk analysis against the transaction to exclude other fraud risks. When these three elements are satisfied, there is no need to apply strong customer authentication.
Here are the specifics for avoidance of SCA:
Transactions are “low level of risk” where:
(a) the fraud rate for that type of transaction is equivalent to or below the PSD2 limits1;
(b) the amount of the transaction does not exceed the relevant PSD22 limits; and
(c) payment service providers as a result of performing a real time risk analysis have not identified any of the following:
(i) abnormal spending or behavioral pattern of the payer;
(ii) unusual information about the payer’s device/software access;
(iii) malware infection in any session of the authentication procedure;
(iv) known fraud scenario in the provision of payment services;
(v) abnormal location of the payer;
(vi) high-risk location of the payee.
In performing this real-time risk analysis, payment service providers are to consider the previous, historical payment user information. This would include: previous spending patterns; payment transaction history; location of the payer and of the payee at the time of the payment transaction, and/or identification of abnormal payment patterns of the payment service user in relation to the user’s payment transaction history.
What else is required to avoid SCA?
In order to avoid applying strong customer authentication for every transaction, and remain compliant under PSD2, monitoring and recording of all fraud data is specifically required.
Under Article 21, in order to take advantage of the SCA exemptions, providers must record and monitor transaction data quarterly and make it available to the relevant authorities, including:
- Total value of all transactions, fraudulent transactions, and the resulting fraud rate, including a breakdown between SCA vs. exempted transactions;
- Average transaction value, including a breakdown between SCA vs. exempted transactions; and
- Number of exemptions applied in total and as a percentage.
Other PSD2 Implications
Next-gen omnichannel fraud prevention will become a necessity post-PSD2. With the open API requirements of PSD2, there is likely to be a convergence of fraudsters looking to exploit the new exposures and threat vectors created. The influx of third party providers into this historically closed ecosystem is most certainly going to be seen as a prime target and area of exploit for fraudsters and bad-actors. In order to address this new, potential gap, institutions need a new approach.
How can Simility help?
Besides meeting all the key PSD2 requirements around SCA or risk-based authentication, reporting and API protection – Simility can help customers get ready in less than 8 weeks – ensuring that they have enough time to test out the new aspects well before the late 2019 deadlines.
Simility allows its customers to take advantage of the exception to the SCA requirement in Article 18 and the reporting requirements under Article 21, obviating the need for SCA on every transaction.
Simility provides a transaction monitoring mechanism capable of identifying transactions “posing a low level of risk”, addressing all of the Article 18 requirements:
- Type and amount of transaction;
- Abnormal location, spending or behavior of the payer;
- Unusual information about the payer’s device/software access, including malware;
- Known fraud scenario in the provision of payment services;
- High risk location of the payee.
Simility also provides all of the reporting capabilities required under Article 21 to take advantage of the SCA exception
Moreover, Simility provides omnichannel fraud protection, leveraging AI and ML (supervised and unsupervised) to close the potential gaps created by the open API requirements of PSD2.
- Consume, analyze and correlate structured and unstructured data and actionable intelligence from all channels, including online, voice, device and third-party feeds;
- Utilize supervised and unsupervised machine learning, behavioral analytics, as well as natural language rules; and
- Leverage visualization, grouping, and fuzzy matching with embedded, closed-loop feedback on every determination.
Simility reduces authentication friction, in compliance with PSD2 and its reporting requirements, enabling customers to transact more quickly, while reducing fraud rates.
Contact us for more information.
1. Permissible fraud rates range between .005% and .13% depending upon the amount and type of transaction. 2. Permissible transaction amounts range between less than EUR 100 to less than EUR 500.
Latest posts by Eric Newman (see all)
- Accountability Matters: Why Firms Need to Step Up with Proactive Protection - October 10, 2019
- Addressing CNP Fraud to Reduce Chargebacks and Protect the Bottom Line - May 16, 2019
- Zero to PSD2 in 8 Weeks - May 23, 2018