In my previous blogs I have given you the basics of strong customer authentication (SCA) and explained how the exemptions could be used to minimise the disruption experienced by payment service users when making payments or accessing transaction information. In this blog, I will take a closer look at the details of the SCA obligations and explain why it’s not as simple as the much-mentioned two-factor authentication (2FA).
What is 2FA?
2FA is a form of multi-factor authentication that confirms users’ identities with a combination of two out of three different factors; knowledge (something they know); possession (something they have); inherence (something they are). Many payment service providers (PSPs) that offer online payment services will already have some form of this in place – whether that’s a combination of:
- the card (possession) and PIN (knowledge) for an ATM transaction;
- a password (knowledge) and one-time-passcode sent to a mobile phone (possession) for an online transaction; or
- a card (possession) and fingerprint (inherence) for a transaction on a mobile app.
Where SCA really separates from 2FA is in the security around it, notably authentication codes and dynamic linking.
What are authentication codes and dynamic linking?
As you would expect, the successful use of two factors to authenticate a payment will result in the generation of an authentication code. The Regulatory Technical Standards (the RTS) adds layers of additional obligations to the authentication code; it shouldn’t be possible to:
- forge the authentication code;
- figure out from the code which factors were used for the SCA; and
- generate a new code by knowing previous codes.
It then obliges the PSP to, in the case of remote transactions (ie. via online banking, for example, but not for transactions where the card has to be physically present such as at the cash machine), comply with the dynamic linking obligations, including that the payer is able to confirm both the amount of the transaction and the payee and that the code received by the payer is the same as the code accepted by the payment service provider.
The reason for this is to rebuff man-in-the-middle attacks where payment orders are intersected and changed. Accordingly, any change to the amount or the payee’s name must invalidate the authentication code generated in line with Article 5(1)(d) of the RTS. A key challenge for developers will be how to keep the code anonymous enough to make it unforgeable, yet definable enough to determine transactional details? One avenue is to define internal codes that pseudonymise transactional details, removing the risk of replication.
We’re an account information service provider (AISP)/payment initiation service provider (PISP), do the SCA obligations apply to the payment services we provide?
The obligation to apply SCA, as set out in regulation 100, applies to ‘payment service providers’, which includes AISPs and PISPs. However, while they are technically caught by the requirement, paragraph 4 allows them to rely on the SCA applied by the account servicing payment service provider (the ASPSP). It’s likely that most AISPs and PISPs will opt to rely on the SCA applied by the ASPSP to minimise the friction experienced by the customer in initiating a payment or accessing account information.
What are the transaction monitoring obligations?
Article 2 of the RTS requires that PSPs put a fraud transaction monitoring system in place that takes into account intelligence on compromised or stolen authentication elements and known fraud scenarios as well as signs of malware are/or tampering with the access device or software (where provided by the PSP). All PSPs have to have the transaction monitoring systems in place but it becomes particularly important in evidencing a sufficiently low risk of fraud where the PSP wants to avail of the transaction risk analysis exemption in article 18.
The payment account information exemption, Article 10, can only be relied on where sensitive payment data is not shown. What is sensitive payment data?
The PSRs defines “sensitive payment data” as:
information, including personalised security credentials, which could be used to carry out fraud; but in relation to account information services and payment initiation services does not include the name of an account holder or an account number.
Payment and e-money institutions will have had to provide details of how they protect sensitive payment data in their application for authorisation or re-authorisation (or registration/re-registration) so they will already have settled on their own interpretation of the term in the context of their business. However, if they are to avail of the Article 10 payment account information, PSPs should assess the information made available to AISPs and/or PISPs and note their rationale as to what should be seen and what should be hidden. ASPSPs have to strike a balance between this obligation and the rule that they must allow their customer accessing their account information through an AISP as much information as they would receive if accessing directly (see regulations 69 and 70).
Summary
SCA is one of a number of PSD2 obligations that require the compliance team to work closely with the PSP’s IT team because of the need to make technical changes to systems and processes. PSPs will have to assess how they approach the customer experience and utilise the exemptions to their fullest to ensure the user is not unnecessarily hindered. Compliance teams must help the IT team to understand what the regulator is looking for and assure themselves that the obligations have been met.
If you require any advice or guidance on SCA and how it relates to your business, please do not hesitate to contact me, or any of the team at fscom.
