The process of onboarding new customers for financial services varies greatly across Europe and the world. In many countries, the required procedure is that you first fill in your personal details on a website, then go through a camera session with a company representative or AI-based system. Here you have to present your ID card or passport and show that you’re actually alive, and not just an image on a screen. Smartphones with built-in cameras help greatly in this process, but when looking at security, there are multiple points of potential weakness:

1. When you start the KYC process, it is important that KYC occurs on the same device the process was initiated on, ensuring that the account created is for the correctly identified person.
2. During the KYC itself, it is important to check for artificially generated images and video. “Deepfakes” are a great example of a potential threat, as the technology continues to improve and becomes more easily accessible. 
3. After the KYC is done, it is important that the identity established is properly secured for the next time the user needs to be identified (but we will get back to this in the next section).

As you can imagine, sitting through a KYC procedure is often considered inconvenient to the new customer. More so, there is also an associated cost for the company doing the onboarding. This is why it’s important to limit the number of KYCs, and to choose a vendor which can do it in a fast and efficient manner. 

Because our world of SCA is so closely linked to KYC, we have entered into some partnerships with next generation KYC providers. By initiating a third party KYC procedure through reputable and experienced companies, it is possible to reduce customer drop-offs, maximise revenue, and comply with regulations.

Ultimately, doing KYC while onboarding a new customer may seem like a semi-normal task. However, it is important to not take this step lightly, as such a procedure becomes critical during re-enrollment. Namely if you’re a bank or eWallet provider, as your customers typically have a monetary balance on their account, which makes exploiting the re-enrollment process a tempting target. 

To read more about this topic, see our previous post on re-enrollment and magic links.

In cryptography, the definition of a trust anchor is “an authoritative entity for which trust is assumed and not derived”. The most common way to represent such a trust anchor is with a ‘certificate’. As such, the security of the validation process depends upon the authenticity and integrity of this certificate. 

Here is an example of how certificates work with a web browser:

Certificates are hierarchical; they start with a root certificate and can have multiple intermediate certificates (‘branches’) before the certificate that identifies your web site. Each public certificate has a corresponding private key, which can be used to derive new certificates and to verify the public certificate. The way this works is too complex to get into in this post, but what is important to know is that it all comes down to trusting the private root key and the chain between the root certificate and your certificate. 

Remember, each certificate is derived from the previous, between the root certificate and your certificate. And, most importantly, should the security of the root certificate be broken, the security of your website and any other certificate derived from the root would then also be suspect.

With Okay, we follow a similar process when a new device is enrolled. Once the KYC is done, we know that the user has been identified. This allows the SDK to create a new local private key and public certificate that is used to identify the device, linking the device with the identity of the user. The public certificate is then transferred to the Okay back-end so that we can verify that we’re communicating with the correct device. The generated private key becomes the new trust anchor for the device, and is used to identify the installation.

With the trust anchor being the key part when it comes to identifying the device (and by extension the user), the security of the trust anchor is essential. After all, if the generated private key for the device can be copied somewhere, then the associated identity would also be copied.

So how can you ensure such security, when your application is supposed to work on both supported and unsupported devices, from a variety of suppliers? When it comes to using Okay, you don’t have to assume that your users are all using up-to-date supported smartphones, with the latest set of security updates. That’s because we work under the assumption that the device already has root-level malware, allowing us to build the security needed to protect against worst-case scenarios. 

The three most relevant security mechanisms that Okay’s SDK offer for this are:

• A white-box encryption solution for secure storage where the secure storage is re-encrypted on each use. This means that the sensitive private key is only visible in memory for a short period of time, and that it is not stored in any unencrypted format. We also don’t have to trust any secure key storage mechanism provided by a potentially unpatched operating system.
• A strong hardware fingerprint is used both as input to the encryption of the secure storage and to verify the possession of the device.
• For Android, we’ve also implemented a code-block transfer mechanism so that the executable code required to implement basic cryptography functionality can be transferred just-in-time. This also lets us avoid depending on an assumed untrustworthy mobile operating system.

Remember, while protecting the trust anchor might sound like a lot of work, the trust anchor is the key factor in protecting access to payment accounts!

In most of the world, the link between KYC, SCA, and your personal identity is unfortunately quite weak. Ultimately, it is up to each regulated financial institution to establish their own SCA and KYC procedures, and then prove the security of them to the relevant financial authorities. 

As lovers of security, we in Okay are happy to help you with this, together with our partners. We understand that having every company set up their own KYC is not very efficient, mainly because it means that a lot of effort is repeated. 

Avoiding this duplication is one of the reasons why the EU started working on the idea of an EU-wide digital identity eWallet. With a first-round launch estimated for 2030, widespread adoption is still far into the future. But, as we’ve seen here in the Nordics, having pervasive eID platforms removes a lot of friction for citizens who want to use a new service.  

As we look further into the future, we’ll surely see a lot more discussion surrounding various national and international eID efforts. So if you’re interested in this topic, be sure to follow our posts on LinkedIn as we continue to watch and discuss the digital revolution unfolding in the world of online payments, Open Banking, and identity authentication and security.