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:

• The SIM swap attack: This is a type of account takeover fraud, where the criminal gets a new SIM card for a user. Often this only takes going to a phone store and saying “I lost my phone, can you give me a new SIM card for my number?” If the store does not check the ID properly, the criminal would end up with a valid SIM card for the phone number. Back in 2019, the CEO of Twitter had his Twitter account stolen with this method.
• Call centre phishing: In this attack, the criminals are calling into the call centre, claiming to be a customer who has lost their credit card or forgotten their password. The same criminal can make multiple calls to the same call centre, and continuously learning more about their victim. Call centre agents (at least for good companies) are trained to keep customers happy, so there are examples where they have sent credit cards to the criminal’s address.
• Attacks on changing your address or phone number through an app or website: This is an attack which can be done with malware, where the malware can call functions to change the address or phone number of the user, which can be used to impersonate the user or to take control of their account.

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.

— — —

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.