The Payment Services Directive (PSD2) and its Logging Requirements

The Payment Services Directive (Directive (EU) 2015/2366, PSD2) has been hailed as a game-changer that will transform the payment services landscape in Europe. While this outspoken enthusiasm reflects the deep changes it will bring, it sometimes fails to note that the increased freedom and elimination of market entry barriers is carefully counterbalanced with a robust regulation of the security of those services, thus making compliance a non-trivial matter. While working on our product and advisory projects, we have seen a wide range of practices but probably the one of the most misunderstood aspects is the mythical tamper-free logging.

Logging is, of course, crucial in any information system, allowing the administrators to monitor real-time activity, use advanced predictive analytics to diagnose problems, and, if disaster strikes, to do a post-mortem and outline the lessons learnt from the investigated incident. The Directive, its implanting acts, and the European Banking Authority (EBA) guidance (European Banking Authority Guidelines on the security measures for operational and security risks of payment services under Directive (EU) 2015/2366 (PSD2)) go beyond that. We will look what compliance entails, and the key functions of logs.

Logging Consent and PSD2

The consent of the payer is crucial in many respects (see e.g. article 65 of the PSD2), and it needs to be carefully logged for the payment services provider (PSP) to prove its compliance. The classical case is when the payer gives its PSP consent to check account balances (see art. 65, par. 1, b), but his extends to many other cases, some of which come under the new General Data Protection Regulation (GDPR)

Logging Access to Security Credentials

The PSD2 is pretty explicit about the need to protect security credentials, and PSPs need to demonstrate that no unauthorized access has taken place (see article 70 of the PSD2 and Guideline 4.13 of the EBA). A clear way to do that is to log all access to passwords and other means of authentication in such a way that those logs cannot be deleted and show that only legitimate access has taken place. The inability to delete logs is the thorny issue in this part. This can be done either using organizational measures like restricting access, or technological ones such as leveraging a blockchain whereby tampering is immediately obvious.

Logging when Specific Events Took Place

Under art. 69, the payer has the obligation to inform its PSP is case of loss, theft or misappropriation or unauthorized use of the payment instrument. Under art. 70, the PSP needs to prevent the use of this payment instrument once notified. It is of crucial importance therefore to know the moment of this notification, and to clearly shows actions taken. All these facts are contained in logs and should be issued a qualified time stamps in case they are brought before court. Another example of proving when an event took place is that under art. 72 the burden of proof for a contested transaction lies on the PSP. The way to prove proper authentication, authorization, and correct execution and recording is through uncompromised logs of all these activities. Again, a combination between business process alignment and information system features is needed to ensure this.

Logging Information for Regulators

A final reason for having a state-of-the-art logging system is that PSPs simply need to collect, store, and present some information by law. For example, under art. 23 of the Directive’s implementing act (2018/389 EU), PSP need to monitor and present accurate data for regulators. Logging its collection and storage access proves that it is indeed compliant with requirements.

Logging for Forensics

The ability to monitor system activity in real-time, define and measure KPIs, investigate incidents and engender evolutionary organizational learning is crucial for establishing and maintaining a high level of information security. Apart from its business value, it is also required to demonstrate PSD2 compliance. The EBA Guideline 8.2 specifically asks for that. As recently as two weeks ago, the investigation into hacking the US election showed the importance of this.

What type of logs do we need then?

While both the directive and its implementation acts are somewhat blurry, the European Banking Authority issued Guidelines on those, explicitly stating the need to provide integrity of all information assets (Guidelines 4.3 and 4.7). The challenge here lies in controlling users with elevated access who may easily delete crucial logs to cover the tracks of their wrongdoing. This operational and compliance risk may be mitigated in a number of way, ranging from the robust to the naïve. A simple approach would be simply to restrict access to “trusted” users, realizing that a “trusted” system administrator may turn rogue or that regulators may not necessarily agree with your evaluation. A second approach is to store logs away from the application, so that the application administrator has no access. Still, another of his colleagues does have access and in small tightly-knit teams this spells problems. What we recommend is using technological solutions that make tampering with the data impossible. Our own product uses a blockchain to ensure data integrity beyond compromise and goes well beyond that in achieving compliance, but there are several other less sophisticated approaches that may work as well.

Probably the key to maintaining state-of-the-art information security and complying with the PSD2 is to devise a solution which by its very nature makes fraud nearly impossible, leveraging both advanced technologies such as the blockchain and advanced machine learning, together with streamlining and optimizing business processes. Apart from mitigating legal risks, getting information security right will also seep into operations, eventually generating a competitive advantage and working towards the bottom line.