Enrolment and re-enrolment are both critical stages in the SCA process. If the enrolment of a client is compromised in any way, all SCA challenges for that client can be compromised. That makes enrolment and re-enrolment the most security-sensitive part of the customer relationship. Let’s take a closer look at these two stages.
Issuers, banks, and eMoney wallet providers have all made one thing clear: A lot of the security focus is on user enrolment, and in particular re-enrolling users. When talking about enrolment and re-enrolment security, a good place to start is to look into some actual fraud scenarios:
In these three attack scenarios, the criminal focuses on the re-enrolment phase. Attacks on re-enrolment are typically made to gain access to an existing account. A typical goal for these attacks is to get access to an existing account to steal all or part of that balance. Attacks on enrolment, on the other hand, typically target financial institutions that offer loans, or take out a loan in somebody else’s name. In both enrolment and re-enrolment use cases, the attackers target the know-your-customer (KYC) routines of a company.
A useful way to think of enrolment security is that when enrolling or re-enrolling a user on a device, you create a security (trust) anchor. As long as that anchor is intact, it can be used to verify the device. This anchor can thus be used as one of the two authentication factors required to do SCA. If the anchor is lost, or the security of the anchor is in question, you might have to do a re-enrolment, as you might be left with just a single factor, which is not enough to do SCA.
In the PSD2 text itself the word “enrol” is not mentioned, but it is mentioned in Article 21 of the RTS, where there is a requirement that “The association via a remote channel of the payment service user’s identity with the personalised security credentials and with authentication devices or software shall be performed using strong customer authentication.” Of course, using SCA would make both of the scenarios I described not be a concern. But, how exactly can one do SCA if the user has lost their device?
At Okay, we focus on protecting the process around the SCA challenge itself (e.g from malware), not the know-your-customer process. Amongst the examples listed above, the Okay solution would only provide protection in the third case by making sure that the user intended to change their address or personal information. However, we recognise that enrolment and re-enrolment is a must-have for issuers. To facilitate this need, Okay has decided to strengthen our customer’s KYC through a partnership strategy.
One of the companies we partner with is Boku. An example of what Boku can help with is protecting against the SIM card swap by letting issuers check that the SIM card in use has not been replaced within a given period of time. E.g, they can refuse to allow possession of a phone number to authenticate the user if the SIM card has been replaced within the last week. This is a strong protection against this type of attack, as that one week gives a victim who’s had their SIM card replaced enough time to notice that their phone is no longer working and report the issue to their telecom provider.
Feel free to explore more of how Okay protects the SCA process and our partners. If you would like to know more about how the Okay solution works, ask for an online demo today.
Unlock updates, insights, and exclusive content delivered to you.
— — —
This is the 7th article in a series about the challenges in the SCA industry.
Read the next article in the series Challenge 8 - SCA for corporate transactions, or go back to the previous article about Challenge 6 - The cost of SCA Integration.