Firstly, sorry for the delay in writing this and thank you @naji for reminding me. I’m an engineer in our Financial Crime and Security team.
Payments on the prepaid card are processed by an external card processor. Over a year ago we started the project of creating our own Mastercard processor. This will give us the freedom to do many things that are either more difficult or not possible with the third party processor. These are some of the things I’m looking forward to experimenting with (disclaimer: there is no timeline for these):
- Different card numbers on different interfaces on the card, e.g. a different card number on contactless and embossed on the front. This helps protect from fraud as details stolen from the contactless interface would be useless to a criminal.
- The ability to create virtual cards from within the app and use them online.
- Push notification > Click to approve 3D Secure flow
- “end to end” encryption of PINs (see below)
As a bank we look after a lot of sensitive data, including PANs (card numbers) and PINs and I’d like to share some information about how we will protect these.
We run hundreds of services in a microservices architecture but only a very small number of services will have access to raw PANs and PINs. This reduces the attack surface and makes it easy to focus efforts into layering lots of additional security measures around those services.
We are able to restrict the number of services that have access to raw PANs and PINs to a very small number because we tokenise all sensitive values. Essentially that means we replace the sensitive value for a “token” that can be passed around dozens of other services but can only be converted back into the raw value by one of the “maximum security” services.
Suppose a user enters their PIN into the app to authorise changing their phone number. The PIN is then sent over an encrypted connection to the internal API where it is forwarded to the phone number service which retrieves the PIN token from the PIN service and gets the tokenisation service to verify that they are the same.
This is perfectly secure, however as part of defence in depth it is prudent to layer an additional security measure that means that the phone service and internal API don’t have access to raw PINs.
The way we plan to do this is by giving the tokenisation service a public / private keypair and then the app will encrypt the PIN such that the internal API and phone service never see the raw PIN and the encrypted data can only be decrypted by the tokenisation service.
Next up I nominate Fred Jónsson