This article marks the final instalment of our Strong Customer Authentication overview series. Today, we’ll go over details related to APIs for payment service providers looking to meet SCA requirements.
In Chapter V of the SCA Regulatory Technical Standards (RTS), access interfaces (in other words, APIs) are the core topic of discussion.
Article 30 covers banks’ obligations related to APIs. Put simply, this article lays down the fact that banks are required to have APIs that accommodate various payment providers. Here are a few key mandatory details about these interfaces:
- The various payment providers that issue card-based payment instruments must be able to identify themselves towards the bank
- Banks must be able to securely communicate to request and receive information on designated payment accounts and associated payment transactions
- Payment initiation service providers must be able to securely communicate to initiate a payment order and receive all information accessible to the bank about the payment transaction at hand (including its initiation and execution)
Article 30 also makes clear that it’s a good idea to centralize authentication methods. This is so that various channels can use the same authentication methods as those used in internet banking and mobile banking (a bit more on this point below).
The third point of the article specifies that APIs must be documented and available to everyone. As described in the following point, if banks make a change in their documentation, it’s necessary for them to notify third parties three months prior to making the change.
Finally, Article 30’s fifth point states that third parties should be able to develop an application using a “testing facility”. In other words, these parties can ensure the security of the development and testing of their application through the use of a sandbox.
Convenient and Secure Access
Moving on to Article 32, the RTS states that a given API needs to be available and should have the same attributes as “the interfaces made available to the payment service user for directly accessing its payment account online” (put simply, internet and mobile banking). It’s essential that the API offers the same level of availability and performance – including support – as internet banking and mobile banking interfaces at all times.
In case a bank is unable to ensure the stability of a given API, there needs to be a backup interface in place. This is the requirement described in Article 33 of Chapter V. Typically, banks do this by temporarily allowing screen scraping on existing digital channels.
Secure Communication
For the purpose of identification, payment service providers use qualified certificates for electronic seals. An electronic seal consists of data in electronic form that is attached to or associated with other data to prove the latter’s origin and integrity.
Importantly, Article 34 of the RTS explains how third parties can come from anywhere. It’s necessary to focus on the authentication of the third party as well as end users, and this is done through the use of certificates (the end users authenticate through the Strong Customer Authentication process). The certificates are issued according to a standard, which is fully described in Article 3 (30) of Regulation (EU) No 910/2014.
A few quick facts about qualified certificates are as follows:
- Certificates for electronic seals must contain various details proving their validity (see Annex III for the complete list).
- It’s necessary to obtain a certificate from a local certification authority (CA).
- Certificates should also ensure secure communication between the parties.
Details of Data Exchange
The final section of Chapter V, Article 36, focuses on data exchanges. It declares that banks need to provide the same data through an API as they do through primary digital channels.
The article also states that in order to prevent too much traffic coming to a bank’s interface, third parties can access information from designated payment accounts held by account servicing payment service providers in the following two cases:
- When a user is active in their application.
- No more than four times within a 24-hour period during which a user isn’t active.
This legislation further secures bank interfaces and makes certain that users are presented with up-to-date data whenever they’re using a third-party interface.
.webp)
