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.

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”.

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.

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.

In early 2021, we took the next step in security certifications and penetration testing with SRC Gmbh of Germany. Having emerged from the banking industry, SRC functions as a central link between research, products and services.

Then, in late 2022, we took another step in our compliance journey with SOC2 - an audit framework designed by the American Institute of Certified Public Accountants (AICPA) - to ensure that we are constantly challenging ourselves when it comes to risk, business decisions, and customer satisfaction.