As an issuer, you have little control over the OS updates of your customers, something that triggers quite a few issues when dealing with security. When scoping requirements, a good place to start is to define what you as an issuer want to protect. When it comes to PSD2 SCA, issuers must protect the transaction - or the challenge - and its authentication process. 

Security should thus be focused on this particular point, helping you as an issuer free yourself from the OS headache and potential additional costs. 

When looking at the basics of SCA, there are two points to look out for: 

• Is the separate execution environment natively provided and secure enough?
• How is the dynamic linking enforced? How is it secured? 

These two points alone can substantially drive your costs up depending on chosen solutions.

Mobile banking users are demanding, and issuers are constantly releasing new features that are either native to the app or delivered via an SDK. This is certainly the case with security solutions, and with the layering and multiplication of SDKs, maintenance can become an issue. 

Likely, as an issuer, you cannot do without an SDK, especially if the security service is externalised. In this case, it is important to source a “light” SDK when it comes to transaction and authentication security.

In order to reduce integration costs, particularly if you start an SCA project “from scratch”, you should ideally source a solution that natively provides both security AND multiple-factor authentication (MFA) methods in a single SDK. The methods should not be based on OTP by SMS, which remains a costly service to issuers.

Although SaaS can be seen as a preferred method to reduce the complexity and cost of an SCA project, some issuers opt for an on-premise SCA solution. We have noticed that the choice very much depends on the size of the organisation, its maturity, and its culture.  

Obviously, the more you bring in-house, the more it will cost in terms of integration and maintenance. Whatever the method of delivery, you have to pay attention to a few points: 

• What is the API? Is it based on the right technology? 
• Is the SDK well documented? Remember, with the right documentation, any engineer – regardless of seniority – should be able to rapidly get acquainted with the technology, which will speed up the time to market of the app.  
• What is the ecosystem of the security vendor?
• Are there any “connectors” or plans to have integration with other solutions? 

The ecosystem surrounding SCA is both rich and complex. When looking at SCA projects, there is rarely one solution that fits all use-cases.

When evaluating an SCA security solution provider, it is important to look into whether they have connections with: 

• Other multi-factor-authentication providers (this is important if you have already chosen a 2FA solution but needs security, or wants best-of-breed or specific solutions)
• Access Control Server providers
• Payment process providers who have built their own authentication servers 
• Antifraud solutions
• Banking-as-a-service vendors
  

Have you identified other sources of costs when it comes to SCA? Let us know!

At Okay, we designed the solution and our strategy to reduce costs as much as possible. To supplement such work, we are actively expanding our partner network as we strive to take the cost of integration out of the equation for our clients. 

— — —

This is the 6th article in a series about the challenges in the SCA industry.
Read the next article in the series Challenge 7 - SCA enrolment and re-enrolment, or go back to the previous article about Challenge 5- Innovative malware attacks.