Okay LogoOkay Logo
Go back to Okay blog

Auditing and Documenting

First published: 07/11/2019

updated: 14/04/2021

artifact

While documentation has already been a long-time requirement, the RTS has created new challenges for anyone involved in payments. Here we find a number of new articles that are more demanding than ever before when it comes to authorisation documentation.

Article 3: Review of the security measures

To begin with, implementation of security measures are now required to be documented, tested, and audited by independent auditors:

Article 3:  The implementation of the security measures referred to in Article 1 shall be documented, periodically tested, evaluated and audited in accordance with the applicable legal framework of the payment service provider by auditors with expertise in IT security and payments and operationally independent within or from the payment service provider.

Article 1 & 2: Fraud Scenarios

Another new requirement is that the documentation is supposed to take into account existing fraud scenarios, and that the integrity and confidentiality of authentication tokens have to be proven. This can be seen in article 1, where some of the requirements to be documented are the mechanisms that aim to “protect the confidentiality and the integrity of the payment service user's personalised security credentials”.

Furthermore, according to article 2, you are supposed to take into account “(c) known fraud scenarios in the provision of payment services”.

Article 22: General requirements

Another article that touches on documentation requirements is article 22, which states in paragraph 3: “Payment service providers shall fully document the process related to the management of cryptographic material used to encrypt or otherwise render unreadable the personalised security credentials.

This is of course particularly important when you are using a smartphone to do payments.

Okay & PROSA Security

The systems used for secure customer authentication (SCA) and transaction security are only a part of what is required to be documented. But as a software vendor, this is the part that we are interested in. As a payment services vendor or merchant, it is important to be able to document the entire process, so we believe it is important to choose a vendor that can document even the stringent requirements listed above.

In our latest round of formal documentation evaluation, we did the following:

  1. First, we cooperated with an expert on security analysis, PROSA Security. PROSA creates tools that enable formal proofs of integrity, authenticity and confidentiality of protocols and complex computer systems. The tools can also do automatic and semi-automatic attack simulations so that we could easily see what would happen with e.g. a man-in-the-middle type attack on a part of the process.
  2. In addition to the tools, Prosa helped us through the “Prosa process”, which is used for creating a model of the software solution, formalising security requirements, analysing threats, and creating a complete risk analysis. 
  3. After completing the risk analysis, the result was a report that was analysed by an accredited evaluation institute, SRC Gmbh
  4. The end result was a successful evaluation.

We believe this is the level of documentation and evaluation that payment service providers will have to provide in the future.

As a side note: Many software vendors only rely on penetration testing. We believe this to be insufficient when proving the security of a software solution. Penetration testing can show that the security is bad, but it is incapable of showing that the security is good, as you cannot assess whether the penetration testing is sufficient by itself. There is only one way to prove that a solution is actually secure: performing a formal analysis of the said solution.