Strong Customer Authentication (SCA) forms part of the European regulation known as the second Payment Services Directive (PSD2). SCA helps to reduce fraud and make online payments more secure by taking a risk-based approach to authentication before a transaction can be processed. The waters of regulation cloud over a little when it comes to transaction risk analysis (TRA), but let’s tackle what we call progressive security first.
The concept of progressive security is demonstrated best by looking at transaction risk. For instance, buying a coffee requires a low level of authentication, whereas buying a car requires a much higher level of authentication. The updated PSD2 regulation mandates that Strong Customer Authentication is required for “customer-initiated” online payments within Europe, so transaction security is being increased to counter fraud. This means methods of authentication need to be simple to use, fast to implement and incredibly secure.
For instance, here at ieDigital, we adhere to SCA standards for high levels of secure data transfer and customer authentication, and progressive security is a principle that’s built into our digital banking engagement platform, Interact. You can, for example, see your account balance without logging in at all. If you have the app running on your phone and you’ve agreed that you’d like to see the balance before login, this is the lowest level of security. It’s still secure, but the security is absent. Behind the scenes, the app is securely connecting to a server, with all data being encrypted. More detailed transactions require a passcode. If you want to make a payment, you have to provide a passcode and perhaps answer a question, and eventually you progress to a strong credential, which would be a biometric or a one-time password.
So, what’s transaction risk analysis?
With SCA mandated as part of European regulation, the requirement is for more robust measures to counter fraud. An interesting but little-known fact (apart from us geeks, of course) about SCA and PSD2 is that the regulation gives the payment providers a fair amount of leeway on when SCA must be applied. In the regulation, this is called transaction risk analysis (TRA – sorry for yet another acronym). Basically, this is a form of real-time progressive security whereby the system is allowed to compute the risk of a transaction based on a number of factors. The computation combines these risk-based factors to determine if SCA is required.
This is interesting because the whole point of SCA in the regulation is to mandate strong authentication to protect the end consumer from fraud. Without careful oversight, TRA could be a get-out clause for the providers.
One would think that payment providers would want to eliminate fraud even more than end users, but while this may be the ethical stance of most providers, the fact is that the more payments they take, the more money they make. The cost of fraud is significant, but the cost of difficult security mechanisms that result in a reduction in payment transaction volume is higher. People gravitate to easier ways of making a payment. If the security makes it difficult (“I forgot my password”), then the payment isn’t taken, resulting in lost revenue to the payment service provider.
The open question is whether this part of the regulation will create a perverse incentive for a payment provider to use a TRA algorithm that results in more payment transactions, but fewer SCA challenges – and whether that also results in a higher fraud rate. I’m sure fraud rate geeks will enjoy doing the future statistics required to answer this question!
