The cost of SCA Integration
Minimizing integration costs and total cost of ownership is a concern voiced by most issuers when implementing an SCA project. Of course, any IT project involves integration and integration costs. SCA is no different in that regard, but it does have its own cost drivers. In this article, we look at ways for issuers to reduce SCA integration costs as much as possible.
Focus on the transaction, not the app
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 to free yourself from the OS headache and potential additional costs.
Review PSD2 SCA fundamentals
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.
Avoid the SDK jam
Mobile banking users are demanding, and issuers are constantly releasing new features that are either native to the app or delivered in via an SDK. This is certainly the case with security solutions. 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 SMS, which remains a costly service to issuers.
On-premise or delivered from cloud?
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?
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. Although we are a young company, we are building our partner network as we strive to take the cost of integration out of the equation for our clients.