Security and trust are fundamental needs for payments.  For this reason the European Commission introduced with PSD2, its new directive on payment services, a general rule on the use of the strong customer authentication (SCA). In this article, we’ll briefly analyze what SCA is, its impact on market operators like banks and merchants and the indirect effects it has on fraud detection and identity management solutions providers.

Strong Customer Authentication (SCA)

SCA is based on the use of two or more authentication factors categorized as knowledge -something only the user knows, possession -something only the user possesses- and inherence -something only the user is. These elements must be independent so that the breach of one doesn’t compromise the reliability of the others. The method of authentication must also be designed in such a way as to protect the confidentiality of the authentication data. PSD2 uses SCA as a synonym for two-factor authentication or multi-factor authentication, so we will do the same. The SCA is mandatory in the following situations:

• Each time a payer accesses their payment account online.
• Each time a payer initiates an electronic payment transaction.
• Each time a payer carries out any action through a remote channel which may imply a risk of payment fraud or other abuse.

PSD2 also offers some exceptions to the required use of the SCA, but let’s focus at the moment on the impacts that it will have in the payments value chain.

Issuing banks and SCA

Issuing banks are heavily impacted in several ways because they must implement what is stated in the regulatory technical standards for strong customer authentication and common and secure open standards of communication (RTS SCA) :

• They must verify that the authentication devices provided to their customers are compliant to the specific PSD2 requirements regarding the generation and display of dynamic authentication codes. This is a unique code generated for each transaction, and it’s bound to the amount and to the recipient of the payment so that in case  one of them changes, the code is no longer valid and must be generated again. Many one-time password (OTP) devices, for example, are outdated and fail to meet these requirements.
• Issuers must ensure that all the existing authentication procedures are ready for the SCA, i.e. to accept and manage (at least) two authentication factors. This is an issue only for remote payments by card, since remote bank transfers are already compliant. Requiring SCA on remote payments by card because it is a really disruptive regulatory innovation. It may reduce the sales conversion rate for merchants by adding more friction to the checkout process.
• To avoid as much as possible having to resort to the SCA, issuers are expected to implement everything necessary to take advantage of the related exceptions: fraud rate calculation, monitoring of transactions, communication flow to the authority, etc.

The exceptions related to payments provided by PSD2 are:

• Contactless payments at point of sale, where the individual amount of the transaction does not exceed EUR 50; the cumulative amount of previous transactions of the same type from the date of the last application of SCA does not exceed EUR 150; or the number of consecutive transactions of the same type since the last application of SCA does not exceed five.
• Electronic payment transactions at unattended terminals for transport fares and parking fees.
• Credit transfers where the payer and the payee are the same natural or legal person and both payment accounts are held by the same account servicing payment service provider.
• Payments where the payee is included in a list of trusted beneficiaries previously created by the payer.
• Recurring transactions, i.e. a series of transactions with the same amount and with the same payee, starting from the second transaction;
• Low-value transactions, where the amount of the transaction does not exceed EUR 30 and the cumulative amount of previous transactions initiated since the last application of SCA does not exceed EUR 100 or the number of such transactions initiated since the last application of SCA is lower or equal to five.
• Secure corporate payment processes and protocols.
• Electronic payments flagged as not risky by a transaction risk analysis (see below the paragraph dedicated to fraud detection).

Even if a bank could use the SCA whenever it deems it necessary, taking advantage of the exceptions is essential to avoid worsening the user experience (UX) in payments. Efficient anti-fraud mechanisms are therefore essential to make the payment experience as friction-less as possible. Otherwise, the risk is losing appeal to users/customers and, in the long run, losing market share.

You can find the entire RTS SCA at the following address.

Acquiring banks with SCA

For acquirer banks the benefits of PSD2 should be greater than costs. The enhancement of the fraud detection systems of the issuing banks should decrease the amount  of fraud in the value chain, reducing the fraud risk exposure of acquirers. The benefits of fraud reduction are expected to outweigh the technical or technological changes required to update acquirers’ information systems to manage SCA.

Merchants under SCA

The risk exposure for online merchants will be significantly impacted by SCA by decisions that are largely outside of their control. If SCA is not required, the status quo will prevail. However, the impact of SCA on the UX of merchants’ sites and their conversion rate is likely to be heavy. In other words, the impact for a merchant will depend mainly on the way issuing banks fight fraud and in the way they will implement the authentication process (i.e. the authentication factors used).

Another important thing to evaluate in order to understand the impact on merchants is how they integrate with their payment service provider (PSP). The trade-off between implementation costs/security and conversion is clear. For API-based integrations that are server-to-server (S2S), merchants will be able to do their best to improve the user experience of SCA. However, in case of hosted payment page (HPP) integrations merchants won’t be able to do anything else than rely on the way the PSP developed the payment page and the authentication process.

Fraud rate SCA exception

Some exceptions exist that banks can use to avoid using SCA. One of these exceptions is closely related to fighting fraud. We’re talking about transaction risk analysis (TRA), a real time risk analysis that must be executed on each payment transaction. In short, the TRA must check to ensure the following conditions:

• No risk flags exist related to the payer, like abnormal spending or behavior pattern, unusual or high-risk location or anomalies in the use of devices/software access.
• No known fraud scenarios or malware infection are present.

For remote electronic payments by card or by credit transfer, the bank can avoid using SCA if its fraud rate related to the amount of the transaction is lower than the threshold stated in the scoring table annexed to the RTS SCA.

For example, an issuing bank requested to authorize a remote electronic payment by card of an amount of EUR 217, must compare its own fraud rate with the threshold stated in the table specific for this type of payment and related to the amount. If the bank’s fraud rate is higher, the bank must use the SCA. For payments higher than the maximum amount (EUR 500), this exception is no longer valid and SCA is mandatory.

If these conditions are not met, the bank must use SCA. Otherwise, it’s up to the bank to decide to use it or not. This makes fighting fraud effectively essential for the relationships between all the subjects involved: banks, merchants and customers since high fraud rates will necessitate SCA and likely result in a decrease in the conversion rate for online merchants. Therefore, it’s fair to assume that banks will invest a lot in fraud detection and specialized fraud solution providers will have a lot of opportunities to increase their business.

Identity authentication

While PSD2 mandates SCA to authenticate customers there are still identity authentication problems that exist. For starters, credential-based authentication methods don’t make us completely confident in a person’s identity. Account takeover (ATO) fraud, for example, relies on stolen identities. Furthermore, authentication factors do not all have the same level of security. They offer different levels of trust even if they belong to the same data class. For example, both behavioral biometrics and biological biometrics are related to inherence but it’s undoubtedly easier to simulate someone else’s keystroke dynamics than their fingerprints.

SCA just increases the level of trust in a person’s identity, but nothing more. It offers a good level of security, but not the best one. For this reason, other ways of authenticating identity are being studied, like the Trusted Identity Corroboration Model (TICM). It’s based on curated credentials like SCA augmented with analytics to provide a greater level of trust in the accuracy of the identity claim.

There are also more advanced identity authentication systems like identity corroboration hubs and continuous adaptive risk and trust assessment (CARTA) systems, but those are beyond the purview of this article. In general, the authentication of a person’s identity is far from being a closed issue.

Big opportunity for fraud vendors

PSD2 is a big opportunity to fight fraud in the whole in the payment industry. In the near term, one can expect merchants to press for improved fraud prevention solutions at merchant bank to reduce pressure from SCA on their conversion rates.  In the medium and long term identity authentication and fraud solution providers will benefit from the business opportunities generated by the impact of SCA implementation. It is likely that merchants will encourage banks to adopt effective tools and procedures in the fight against fraud and identity theft to preserve smooth UX and minimize the use of SCA as much as possible.