Strong Customer Authentication according to final RTS: are text messages inconsistent?

After adding some changes, last November the European Commission issued a final Regulatory Technical Standard (RTS), created by the European Banking Association for strong authentication under the new PSD2 directive. According to the final RTS document, a few important details have to be changed in the target architecture of the solution, that meets the requirements of the directive.

One of the key RTS changes (described in Article 32.) introduces a ban on redirections to the bank’s website in order to process strong authentication. This means that the strict OAuth2 standard will not be used by banks (the PolishAPI standard will therefore require a change in this matter). In practice, introducing such requirement will basically end the era of confirming payments via text messages.

 Read more  PSD2 RTS ebook – Regulatory Technical Standards for 2nd Payment Security Directive

Article 97. of the PSD2 directive imposes an obligation to use strong customer authentication (SCA) by the payment service provider. Essentially, this obligation applies every time user accesses account. RTS introduce several possible exemptions from this obligation, but every bank customer will have to get used to this procedure.

The strong authentication directive will define as authentication based on the use of at least two of the three elements: knowledge (something I know), possession (something that I have), feature (something that I am).

The requirements for SCA are defined both by the official PSD2 Directive and the RTS document, which is (under Article 98. of the Directive) a “technical standard for authentication and communication”. These requirements are described inter alia the articles: 6., 7., 8 and 9 of the final RTS document.

In addition to the requirements for strong authentication for further considerations, it is worth to highlight the requirements for dynamic binding, which are described in Article 5. of the RTS. Currently, when the payment service uses a remote channel, which is online banking, involves entering a code to confirm the transfer. The code is usually sent to us by the bank via text message, with added information about the amount and recipient of the payment.

This way of authentication process uses the messaging channel in two aspects. First is the “possession” authentication element. We receive the code that we enter into our online banking service. The second aspect of messages is the application of dynamic binding requirements. In this aspect, the text message contains information about the amount and beneficiary of the transfer.

The first aspect is compliant with RTS requirements. Article 7. imposes a requirement on the implementation of safeguards against unauthorized use and the replication of the “possession” element. Unauthorized use can be secured procedureally (blocking a telephone number in a bank at the customer’s request), and replication requires the cloning of a SIM card – which, however, is well-protected for such a possibility for many years now.

The second aspect of use, i.e. “dynamic binding”, is very doubtful. The text message does not meet the requirements of Article 5., point 2. The standard text message does not provide the information sent to it with neither confidentiality nor integrity. The dynamic binding requirements could be theoretically realized via the second channel, i.e. the internet banking site (which additionally implements “knowledge” authentication). However, will this channel still be used for this purpose due to the ban on redirections to the bank’s website?

 Read more  Open API and open banking – 7 products ideas

The situation described has put new challenges ahead of the banks. They will have to find ways to meet the requirements of the directive and RTS in the context of strong authentication and dynamic binding. The next challenge will be to think over the strategy and future of existing bank’s remote channels for contact with the customer.

Among many requirements that banks in the European Union will have to face, it is still necessary to use standards issued by international or European standardization organizations in communication with various service providers (TPP, AISP, PISP). When designing our APILOGIC solution, we based on OAuth2 with UMA profiles, OpenID Connect and FIDO standards. Thanks to the implementation of strong authentication (two authentication factors) and secure “dynamic binding” in one device, all the requirements of the directive and RTS have been met.

Thus, our product meets the requirements of both strong authentication and dynamic binding described in RTS.

 Read more: Biometric authentication, FIDO standards and our money security

In the light of new regulations, the biggest requirement for banks is the need to revise their business strategies. When we look at today’s services market, we can not help but notice that lightness and agility are winning today in the battle for the client. Some banks have already realised this. They open new business entities and supplement their API with additional functionalities, not only those related to PSD2 directive.

Will they be able to compete with fintechs in the context of customer service and acquisition? One issue puts them on a losing position. These are obligations towards lawmakers, with GDPR at the forefront. That much of legal restrictions do not apply to any company from the fintech industry.

Read more:  GDPR: 5 most important law changes and their consequences for banks.