As a product manager of a SaaS or mobile application, you’ll already have a constant eye on ways to improve the security and user experience of your products. In digital financial services, and hence embedded finance, Strong Customer Authentication (SCA) is a big part of fulfilling these security and UX aims. In this article we’ll introduce you to some of the key concepts around SCA for financial application logins and digital payments, and provide some advice about best practice implementation in your embedded finance programme.

Strong Customer Authentication, hereafter SCA, is a requirement under the European Union’s Second Payment Services Directive (PSD2) for access to sensitive digital financial account information and making digital payment transactions. SCA requires the use of multiple forms of authentication, such as one-time codes, biometric authentication, or security tokens, in addition to ordinary username+password logins, to verify the identity of the user. By requiring SCA for logins and transactions, financial institutions protect against unauthorised access and maintain the security of financial transactions. 

SCA has been reported “successful in preventing more than 90% of fraudulent transactions”. [Gemalto (now Thales DIS), “2018 Data Breaches and Fraud Report,” ] 

In embedded finance, as the front-end interface for regulated financial services, your application will need to be set up to provide the UX steps and underlying systems to fulfil SCA multifactor challenges on logins and transactions.

To be “multifactor” an authentication must be done with factors from two different types as illustrated below:

Strong Customer Authentication in embedded finance

If your application has not enforced multifactor authentication for logins before, you’ll need to add it, at a minimum as a step-up requirement for users to gain access to those parts of your application where they view sensitive financial data. Similarly, while a normal (single-factor) login may be sufficient for users to perform non-financial actions in your application, when it comes to financial transactions (such as sending a bank transfer payment) your application will need to enforce extra checks.

When implemented well, SCA is not just about a regulatory checkbox. In addition to providing a big step up in security, SCA can also improve your application’s overall user experience by strengthening trust and confidence. This is especially important for applications with embedded finance features, as your users need a high degree of confidence that they can use your application to handle their sensitive financial information and move money safely, with the same expectations they would have of any traditional digital banking apps.

Let’s take a closer look at the benefits and best practices for implementing SCA in embedded financial services, and how you can ensure your application provides a secure and seamless user experience. If you have any questions about how to improve the security and user experience of current or planned embedded finance features in your application, reach out to Weavr and we’ll be happy to help.

What is Strong Customer Authentication?

SCA has become a critical component of digital financial services, and thus by extension a requirement of embedded finance applications across all devices and contexts. From the end user’s point of view, SCA is a requirement to provide multiple different forms of authentication when accessing their financial accounts or making online payments. This will include so-called knowledge factors like a password, a biometric (“inherence”) factor like a fingerprint or facial recognition, and possession factors – the most common being proof of possession of a unique mobile device via a one-time code.

Strong Customer Authentication in embedded finance

The purpose of SCA is to protect against fraud and unauthorised access to financial accounts. It makes it much harder for malicious users (or indeed unintended user or software actions) to gain access to someone’s financial information or make unauthorised transactions, as they would need to have multiple “factors” and use them in multiple steps in order to do so. This added layer of security is especially important in the world of embedded finance, where financial services are being integrated into a wide variety of non-financial apps and websites. In these scenarios, secure financial actions need to be taken both more frequently and beyond the traditional scope of a standalone banking or payments application.

Bank-like security… beyond traditional banking

By 2019, 95% of banks in the EU had implemented SCA. But SCA is not just for banks and traditional financial services – it applies wherever people make digital payments. Across the rapidly expanding frontier of innovative embedded finance use cases, SCA helps ensure the security and integrity of the financial transactions being conducted through non-financial front-end UX channels.

For example, if you are using a ride-sharing app that integrates with your bank account to facilitate payments, SCA helps to ensure that your financial information is protected against a wide variety of potential threats or vulnerabilities, so that customers can have a high degree of trust that the transactions being conducted are legitimate and transparently authorised by themselves.

Where do the SCA rules come from?

The Payment Services Directive 2 (PSD2) is a European Union regulation that aims to improve the security of online payments and provide more choice and competition in the payment industry. SCA sets out a series of rules intended to protect against fraud and unauthorised access to payment accounts. All payment service providers, including embedded finance applications, need to comply with the requirements of PSD2 and SCA.

PSD2/SCA requirements apply where both the sending PSP and receiving PSP (e.g. issuer and acquirer sides of a card transaction) are located in Europe. For now the UK still follows the EU standards. Because of the general security benefits, as well as the difficulty of creating systems which can selectively apply SCA dependent on EU locations of transaction actors, Weavr requires SCA checks to be applied to all relevant actions regardless of location / jurisdiction.

Strong Customer Authentication in embedded finance

What does SCA guard against?

A good implementation of SCA guards against a variety of digital financial risks or unauthorised access possibilities:

  • Fraud:
    SCA fights fraud by verifying the identity of the user before allowing a payment or login. The requirement for multifactor authentication protects against unauthorised transactions and thus against financial loss.
  • Account takeover:
    Security notifications and heightened user awareness around authorisation and authentication interactions with financial apps help to alert users and businesses against unauthorised access attempts. Even before a fraudulent payment is attempted, they can ensure timely security actions are taken, including preventing unauthorised changes to account information.
  • Phishing attacks:
    SCA can help to blunt the impact of phishing attacks because, even if a password is stolen, by requiring the user to provide multiple forms of authentication an attacker would still not be able to gain access to sensitive information or payment actions.
  • Man-in-the-middle attacks:
    Modern multifactor authentication methods used in SCA can help to prevent man-in-the-middle attacks, i.e. where attackers attempt to intercept digital communications to then gain unauthorised access to sensitive information. Such actions can be part of an automated malware attack aimed at compromising data of individuals or organisations.

In addition to the risks highlighted above, SCA also helps reduce unintentional user error: by enforcing steps into UX journeys that essentially ask “are you sure?” for payments and money movements, users are prompted to double check that everything is as they intended before making financial transactions.

Overall, SCA helps to protect against a wide range of payment risks and unauthorised access risks, making it an important tool for maintaining the security of financial transactions and protecting sensitive information.

When are SCA checks required?

Rules depend on the implementation scenario but, within the context of embedded finance programmes built with Weavr, we require (and are required to supervise / enforce) the following criteria in determining when to apply multifactor authentication for SCA:

  • Access to payment account information:
    Multifactor authentication for users to access sensitive financial information such as recent transactions, card numbers etc. This can be done at the time of login to the application or can be a “step up” required at the time the user navigates into a secure financial workflow in the application.
  • Payments:
    All money movements to third parties will require a secure multifactor authentication and authorisation, including:
    • Card payments (via 3D Secure online, and Chip + PIN in person)
    • Outbound wire transfers (OWTs)
    • Sends i.e. money movements between accounts and cards of different identities
  • Administrator access:
    Weavr and Innovators will apply multifactor authentication for SCA to logins and transactions which are done by administrators (support, etc) viewing payment account information and acting on behalf of account holders within the programme consent framework.

Exceptions
An array of SCA rules apply to when certain transactions can be exempted from SCA challenges, including different criteria for logins, 3DS card payments, and other transactions. As the details of the rules can be complex and are highly context-specific, we recommend you discuss SCA exemptions with Weavr within the context of your unique programme and use cases. There are currently no blanket SCA exemptions for embedded finance innovators, i.e. all product managers will need to put in place secure, well-designed, and compliant base features for SCA, and then any agreed exemptions are implemented within defined conditions on top of that solution.

What are the common methods of multifactor authentication used in SCA?

There are lots of possibilities, but we’ll cover the methods currently supported by Weavr for embedded finance applications:

  1. SMS:
    SMS-based multifactor authentication involves sending a one-time code via text message to the user’s mobile phone. This is a widely used method that is simple and easy to implement. One key downside is that any system relying on SMS can be vulnerable to SIM-swap attacks, in which an attacker takes over the victim’s phone number and thus receives the one-time code. In addition, SMS may not be available in all areas or may be subject to delays, which can impact the user experience.
  2. Twilio Authy push authentication:
    This is an alternative to SMS which involves the financial services provider sending a notification to the Twilio Authy application installed on the user’s device (mobile or desktop), which the user must confirm in order to complete the authentication process. This method is more secure than SMS, as it is less vulnerable to SIM swap attacks, and it also provides a more convenient user experience in terms of interacting with an “approve” dialogue box rather than having to manually input or copy-paste a one-time passcode. However, it does require the user to have the Authy app installed on their device, which may not be a preferred option for all users.
  3. Biometrics for mobile apps:
    Biometric authentication involves using the user’s unique physical characteristics, such as a fingerprint or facial recognition, to verify their identity. This method is convenient for users and can be more secure than other methods, as it is considered difficult to forge biometric data. However, it may not be suitable for all users, as some individuals may not have the necessary biometric capabilities on their device, or may have physical impairments that prevent these biometric features working as expected. 
Strong Customer Authentication in embedded finance

If an authentication was challenged with a “factor” of the same type, it would not satisfy SCA requirements, e.g. a password + a separate PIN (because both are just “something you know”). This is why “two-step authentication” is not strictly the same as “two-factor authentication” (2FA) or the term “multifactor” as we are using in this article.

In practice the “something you own” is usually checked via a one-time code, which is generated in a separate system from the ordinary password challenge and is only possible for the user to fetch from their pre-registered device(s). In cases where the user inputs a one-time passcode (OTP), it’s not just another password because the code is about proving you have access to the device that in turn is considered exclusive to your identity.

Product managers with embedded finance programmes will need to carefully evaluate the pros and cons of different SCA multifactor authentication methods to ensure that you are providing the best standard of security and best user experience possible. As there is no single “right answer” and the pros and cons are very dependent on your application and your users, you may wish to seek advice from a number of viewpoints, including both regulatory / compliance expertise and UX / design thinking.

Twilio Authy as a third-party authentication app for SCA

Using Twilio Authy for SCA in financial services is a simple and effective option to protect accounts and transactions from unauthorised access. Here are the steps your application end users can follow to start using Twilio Authy for SCA in your embedded finance flows:

1) Download the Authy app (free of charge) from the App Store or Google Play Store on your smartphone. Open the app and follow the prompts to create an account. This will involve entering your phone number and email address, as well as creating a strong password. (Ensure you do not lose access to this important Authy account. You may wish to install it on two different devices you control in case one gets broken or lost.)

2) Once you have created your account, you will need to set up Authy for use with your financial accounts. Your payments (etc) application will provide you with a link to confirm a connection with your Authy.

3) After confirming, each time you log into your financial accounts or make online transactions, in addition to the normal username+password login, you will be prompted to confirm/approve the action via a notification linking to a secure message that only be accessed via the Authy app on the device(s) you possess.

4) When using “push authentication” you can check and complete logins or payment confirmations conveniently with a couple of taps, without having to input or copy any passcodes manually.

In summary, by using Twilio Authy for SCA, you are adding an extra layer of security to your financial accounts and transactions. This helps to protect against unauthorised access and keeps your financial data and money safe.

Prototyping and testing new SCA features in your application

When developing new SCA features, product managers should consider a number of different angles to take on software prototyping, user acceptance testing, and ongoing QA:

  • Integration testing:
    This type of testing involves integrating the SCA feature with the rest of the app to ensure that it functions correctly, performs scalably, and does not cause any issues with the overall functionality of the wider application. It’s important also to integrate analytics and monitoring early in the process.
  • Functional testing:
    Focusing on the front end user experience, this type of testing involves verifying that the SCA feature performs its intended function, such as prompting for additional authentication when necessary and verifying the user’s identity. Ensure you have realistic testing setups that closely match how your customers actually interact with your application. It’s essential developers, BAs, and QAs work with clear shared documentation of the user stories / journeys, successful functionality, and expected exceptions around SCA in the context of your application.
  • Usability testing:
    Observation of real users interacting with the SCA feature to ensure that it is easy to use and understand.
  • Performance testing:
    Evaluation of performance of SCA features under different conditions, such as with a large number of users or high volume of requests, and with different device types.
  • Security testing:
    Specialist evaluation of the security of the SCA features, including actively looking for and closing off bugs and vulnerabilities.

As with any major set of new features in your application, it’s vital to conduct thorough testing of your SCA implementation / enhancements to ensure that the updated system is reliable and effective in protecting users while maintaining a high standard of performance and user experience.

Will customers understand what they need to do for SCA?

Fortunately, consumers have already become quite familiar with the UX of multifactor authentication in a number of common digital contexts, such as:

  • Online banking: anyone using mainstream bank or payment applications will already be using multifactor authentication to log in to accounts or make online transactions. According to the European Banking Authority, “69% of consumers prefer to use Strong Customer Authentication (SCA) when making online payments, as it helps to ensure the security of their transactions.” 
  • Email and social media: most of the leading email and social media platforms offer the option to enable multifactor authentication for added security. A 2019 survey by the National Cyber Security Alliance found that 44% of respondents used multifactor authentication for their email accounts and 34% used it for their social media accounts.
  • Non-financial mobile apps: a 2020 survey by Google found that 37% of respondents were familiar with multifactor authentication in day-to-day usage mobile apps including ecommerce, rising to 39% in a similar survey by LastPass in 2021.

Consumers are likely to be familiar with the process of setting up and using multifactor authentication in a variety of digital contexts, and this is especially the case where people expect to see these features for added security around banking and payments.

Finally, it’s worth noting that multiple factors for authentication and authorisation in financial services are one of the rare times that additional UX steps can actually help usability. In the words of the European Banking Authority: “While some consumers may initially find SCA to be inconvenient, it has been found to improve the overall user experience by increasing trust and confidence in the security of financial transactions.” [EBA Report on the implementation of the revised Payment Services Directive (PSD2) by national competent authorities and market participants” (2019)]

What challenges might users experience with SCA?

There are a few things that may confuse consumers or cause usability friction when adding SCA multifactor authentication to flows in your application, particularly if your users have not previously been using two-step or multifactor authentication in the non-financial areas of your application.

Awareness about new authentication steps

Some users may be confused by the need to provide multiple forms of authentication, such as a password and a one-time code sent to their phone, expecting a single factor only. To mitigate, ensure your application provides clear instructions in context on how to complete the authentication and authorisation steps. Work with UX designers and microcopy experts to make sure that the prompts your users see are easy to understand.

Interrupting the user flow

SCA may interrupt the user flow and cause frustration if it is required too frequently or at inconvenient times. Carefully design and document the common flows in the financial parts of your app so you can clarify when additional authentication is necessary, and ensure that the information for users is clear and positive about why they are being prompted for additional authentication.

Technical issues

Applications with embedded finance features can encounter technical issues in the chain of components for SCA, such as delays sending a one-time code or timeouts receiving an authentication response from the user’s client. To mitigate, product managers should work with developers and QA to look at detecting and resolving intermittent outages, while having fallback options in the case of longer duration or broader impact incidents.

Anticipating user challenges around SCA

A key principle of any software usability discussion is that not all users are the same. So when it comes to SCA, some customers will breeze through and love how you’ve implemented it, while others will feel like you’ve put a brick wall in front of them. 

When designing the details of how you’re implementing SCA in your embedded finance application, think ahead about who these particularly challenged users might be, and proactively plan how you will help them.

1) Elderly or less technologically confident users

Users who are not comfortable with technology or have difficulty using it may find SCA to be an additional usability problem. You’ll want to target common stumbling blocks in your UX flows with contextual tooltips, and where possible break down complex flows into simpler steps. While struggling users can include elderly folk, don’t stereotype by age group or generation: figure out how, when any users of your application have physical or cognitive impairments, they can still successfully complete tasks, and if necessary get an extra level of support.

2) Heavy users

Users who make a lot of online purchases or payments may find SCA to be a usability problem if it is required for every transaction. Some improvements which work for less confident users such as additional screens of information may have the opposite effect for high frequency, fast-moving users.

3) Users who can’t use the defaults

Whether or not your customers are familiar with SCA in other contexts such as online banking, they might not be able to use (or wish to use) the default multifactor authentication option in your application. This might be for a simple but hard to resolve reason such as having poor mobile phone signal when trying to receive SMSs. Consider what alternatives you can provide and whether you can offer users a way to personalise their settings.Pay close attention to support enquiries and complaints so you can help individual customers around issues caused by SCA, as well as feed back general improvement ideas into your product.

Creating application-specific end user support around SCA

Product managers with embedded finance programmes should ensure that, at the same time as adding and enhancing financial features in their application, they accompany this with good quality knowledgebase documentation for end users and with training for front-line customer support teams.

Here’s a suggested set of sections to add to your documentation around SCA:

  1. Introduction to SCA multifactor authentication:
    Provide customers with an overview of SCA multifactor authentication and why it is important for protecting their financial information.
  2. Setting up SCA multifactor authentication:
    Step-by-step instructions for customers on how to set up the available SCA multifactor authentication options, illustrated with your actual application screens.
  3. Using SCA multifactor authentication:
    For each commonly expected SCA flow such as “logging in securely” and “confirming a card payment”, offer users tailored instructions for completing the SCA multifactor authentication process.
  4. How SCA multifactor authentication makes our financial lives safer:
    It may be helpful to create a general introduction for customers about why SCA is required and how SCA multifactor authentication helps keep them safe, which can be linked to from terms and conditions, onboarding guides, and so on. This might fit with existing information you provide to customers around data protection, security, and acceptable use policies.
  5. Troubleshooting:
    Create short articles that are easy for users to search and browse, covering solutions to common issues that may arise when using SCA multifactor authentication, such as problems receiving a one-time code or difficulty using biometric authentication.
  6. FAQs:
    Similar to the troubleshooting section, consider an easily searchable, and search engine friendly repository of answers to common questions about SCA multifactor authentication, tailored to the functionality and jobs customers are getting done inside your specific application. Don’t worry if information overlaps with “main” guides: give your customers multiple ways to discover the information they need… you’d be surprised how many questions are solved through Google or another search engine rather than by tooltips or help articles within your application and website.
  7. Contact:
    Don’t forget to make it transparent and easy for your customers about how to get help, and provide clear expectations around the availability of support and speed of response they can reasonably expect.

Measuring successful implementation of SCA

Here are some KPIs that we recommend watching to detect any issues with your implementation of SCA, as well as measuring overall that your application is working as intended:

  • Conversion rate: the percentage of users who complete a desired action, such as making a purchase or logging in to their account. A decrease in the conversion rate could indicate that SCA is causing usability problems and preventing users from completing their desired actions.
  • Abandonment rate: the percentage of users who start a process but do not complete it. Spikes in the abandonment rate could indicate that something in the SCA process is causing some users to give up on the process.
  • Time to complete: the time it takes for users to complete a process can be a good indicator of usability, both in terms of averages / benchmarking, and watching for outliers. If the time to complete a process increases significantly after SCA is implemented, this could be for design reasons or technical performance. Try to replicate user environments that seem to have problems, and make it easy for your users to directly raise issues.
  • Customer satisfaction: regular or targeted feedback can be a good indicator of the overall quality of your user experience – and changes to that quality. Volume of customer support enquiries (segmented by reason, sentiment, user type etc) can also be a great indicator of where customers might be encountering issues. Again, by making it easier for customers to provide first-hand comments about your application, you can pinpoint improvement ideas very often faster than it would take to find the issue in formal QA testing.

Overall, it is important for any provider of embedded financial services to monitor these KPIs and look for any changes that could indicate an issue with the implementation of SCA. By diagnosing and addressing any issues promptly, Weavr can better support your team in ensuring that SCA is effective in protecting against unauthorised access and maintaining the security of financial transactions, while also providing a good user experience.

Conclusion: best practices for implementing SCA for embedded finance in your application

Here are some recommendations from Weavr when you’re implementing SCA for logins and digital payments in your application:

  1. Offer multiple authentication methods:
    By offering multiple authentication methods, such as a choice between one-time codes via SMS, and biometric authentication, you can give users more flexibility and make it easier for the greatest proportion of customers to be able to complete SCA flows in a convenient manner.
  2. Develop features that take account of different levels of risk:
    In a general sense, risk-based authentication and authorisation checks mean prompting for additional confirmation, and perhaps adding additional information for users, when factors such as the value of a transaction or the pattern of user behaviour suggest a higher risk, and seeking exemptions or changes of UX flow when the risk is lower. This is a complex area that’s worth discussing in terms of the specific use cases of your application and business model, but it is possible to design the frequency of SCA prompts to target great outcomes in both security and usability at the same time.
  3. Provide clear instructions and guidance:
    Make sure your application provides customers with clear instructions and guidance on how to complete SCA flows, both as general guides and in-application tips or prompts. You should also create troubleshooting steps for common issues. Prepare your support team to help users who may be unfamiliar with SCA or what they perceive as technical jargon, as well as anticipating key UX journeys or actions in  your application where confusion around SCA might present difficulties.
  4. Monitor analytics:
    Monitor user behaviour to identify patterns that may indicate a problem with SCA usability or technical performance, such as a decrease in conversion rate or an increase in UX journey abandonment rate. Ensure your team understands how SCA works so they can detect and address any issues promptly.
  5. Provide timely and knowledgeable support:
    Offer assistance to users who are having trouble with SCA usability, in real-time if possible. This can include guiding the user through the authentication process or troubleshooting steps, as well as providing reassurance and alternatives if their intended action is not working out. It’s also vital to ensure your support team is trained to identify suspicious signs of incoming support requests that might be an attacker impersonating customers and attempting to evade SCA checks.

When we establish your embedded finance programme, we’ll support your product and operations team in following these best practices to ensure that SCA is effective in protecting against unauthorised access and maintaining the security of financial transactions, while also providing a good user experience.

Want to know more?

Contact Weavr to set up a discussion about integrating embedded finance features into your application, and how we help you solve SCA requirements.

Copy link