It’s an age-old fairytale – Goldilocks, a story of a little girl who wanders into the home of three bears, finds three bowls of porridge and tastes all three. One’s too hot. One’s too cold. But the last is just right. We’ll soon experience a similar tale that when it comes to implementing Strong Customer Authentication (SCA) for PSD2. With many different options that range in security level, user experience and cost, to succeed, banks are faced with a reality of needing to find a solution that’s just right. But unlike the Goldilocks example, banks don’t get multiple “tries”

Delivering and maintaining a good user experience is the top concern for implementing SCA requirements for PSD2 according to a Deloitte survey of 90 European banks [1]. Not a surprising stat as PSD2 and Open Banking are all about making the European financial industry more customer-centric – while ensuring a secure environment. Enabling secure, easy digital payments will be paramount to success in an industry on the brink of digital disruption.

With SCA, extra levels of authentication will be required for online transactions (i.e. not just a password). Two of the following are needed – something you know, something you own, or something you are – and the authentication code must attach to the specific transaction amounts and payees to prevent transaction tampering (aka dynamic linking).

A bank’s SCA solution cannot create too much friction for the customer. Especially for low-risk scenarios like a customer transferring some nominal funds – they won’t react too kindly if they’re now made to carry around say a keychain-sized token to use to generate and enter a long code for every small transaction.

Nor can a bank’s SCA be too transparent for the customer. In some low-risk cases, SCA isn’t required by the Regulatory Technical Standards (RTS) if Transaction Risk Analysis (TRA) is in place. Behind-the-scenes TRA is critical to fighting the most sophisticated of threats – and in a user-friendly way. Invisible-to-the-user adaptive authentication detects anomalies in real-time, only stepping up authentication if risk elevates. Here, if uninformed, customers who aren’t asked for step-up authentication in low-risk cases may mistakenly conclude their payments aren’t secure at all.

Instead,a bank’s SCA needs to deliver just the right amount of friction – aka positive friction to reassure customers that safeguards are in place to fight cybercrime and fraud. When SCA is required, deploy easy, yet secure methods, like mobile one-time-passwords (OTP), push notifications (verify with one tap) or biometrics. And, when coupling TRA with SCA, having a strong customer journey is key to foster trust and adoption. Customers should be notified that their identity is verified and transactions are secure even when step-up authentication isn’t required.

So, how can you implement PSD2-enabling solutions like dynamic linking, independent elements, RASP, SCA, and TRA in a way that’s just right? And how can you deploy in a way that won’t proliferate IT complexity? To answer these two questions, join us for the next in our PSD2 readiness webinar series where we’ll drill down into the how – aka the technical to help you deliver optimal PSD2.

Register for the webinar here >>. Bring your burning questions. See you there!

[1] Deloitte (2018). European PSD2 Survey Voice of the Banks. [online] Deloitte, pp.33-34. Available at: [Accessed 25 Oct. 2018].