Transaction monitoring for PISPs and AISPs

Blog

Transaction monitoring for PISPs and AISPs

Where two forces collide

The introduction of the Revised Payment Services Directive (PSD2) coincided with that of the General Data Protection Regulation (GDPR) and 5th EU Anti-Money Laundering Directive (AMLD5). As a result, when (new) FSI players are thinking of entering and navigating the newly opened payments market, they must navigate three laws that differ greatly in goal and spirit. These two directives and one regulation form an intricate framework which occasionally generates conflict or contains aspects that have not yet fully been crystalized, creating what we call the “PSD2 Trilemma”. One of the topics that is impacted by the three laws is transaction monitoring. This first in-depth article of our blog series will specifically address the challenges faced by PISPs and AISPs when complying with AMLD5 transaction monitoring obligations.

Co-written by Maud Engelman & Niels Kohnstamm

The status quo

The revision of AMLD5 in January 2020 brought more extensive obligations for PSPs (and PISPs/AISPs in particular) to conduct ongoing monitoring of the business relationship, which includes the scrutiny of payment transactions. The European Banking Authority (EBA) stresses that PISPs and AISPs should comply to the provisions of AMLD5 and ensure that their AML/CFT systems are set up in such a way that unusual or suspicious transactional behavior is alerted.The Dutch Central Bank (DNB) adopted this vision and has translated it into a separate guideline for PISPs and AISPs respectively. Both EBA and DNB guidelines indicate that new forms of payment institutions created under PSD2 have a role as a gatekeeper within the payments ecosystem.2

PSD2 blog series overview

open in new window Learn more

The other side of the coin

In the discourse of the debate regarding the feasibility of the obligation for PISPs and AISPs to perform transaction monitoring, the European Third Party Providers Association (ETPPA) has brought forth several counter arguments against the vision of EBA and DNB.It argues that PISPs and AISPs should be (partially) exempted from transaction monitoring requirements because AISPs “do not conduct financial activities” and “PISPs do not themselves execute payment transactions”.

One way to approach the opposing views is to balance the spirit and goal of the law with the practical aspects of payment activities. As set out in the introductory article, PSD2 was intended to ensure legal certainty for consumers, merchants and companies within the payment chain and improve competition and innovation by opening payment markets to new entrants also echoing EU ambitions of the digital finance strategy of the EU. AMLD5 on the other hand is designed to prevent financial institutions being used for money laundering and terrorist financing purposes. Complying to the AML regulations has proven to be burdensome, costly, time consuming and more importantly often not that effective.The question is whether the interests of the AMLD5 weigh heavily enough to have it effectively function as a barrier for innovative parties to enter the payment ecosystem.

As mentioned, ETPPA highlighted the nature of both PISPs and AISPs within the financial system. In contrast to ASPSPs, they do not provide their customers with a payment account, nor are they actually in the flow of funds. It is therefore reasonable to question the extent to which they should be held responsible for monitoring unusual transactional behavior. Even more so because the actual transaction monitoring activities already lies with the ASPSPs that are in the flow of payments. Furthermore, considering that criminals will hide their illicit intentions, the power of detection of suspicious activity lies more with mining an extremely large pooled set of data as opposed to a small fraction (even if aggregated somewhat by an AISP).

The above considerations are especially onerous to AISPs, as they ‘merely’ provide technical access to customer account data. DNB recognizes these particular characteristics and has stated that, in the case of an AISP which solely provides consolidated data from multiple payment accounts, a limited form of transaction monitoring is acceptable.This does mean though that AISPs, contrary to PISPs and ASPSPs, will still have to monitor unusual transactions between aggregated payment accounts of a single Payment Service User (PSU). Therefore, AISPs still have to adhere to the requirements of creating a transaction monitoring framework, including policies, procedures, tooling and people to adequately perform transaction monitoring and alert handling. This is often too large a hurdle for a company that ‘merely’ aims to provide payment data analysis.

What lies ahead?

Although PISPs and AISPs are technically considered financial institutions under AMLD5, the arguments above showcase concerns in complying with their transaction monitoring obligations. Seeing what has already surfaced under PSD2, it is safe to say that more areas of friction will arise in the future. For example, consider a credit provider with AISP license, using an AISP application as part of the onboarding process. Before entering into a credit agreement, a one-time API call (i.e. an AISP service) will enable the party to obtain an overview of all applicant’s accounts, enabling a tailor made and quick offer. Should this one-time AISP call result in a transaction monitoring obligation of all accounts queried and does the relationship at that instance fall under the definition of a business relationship? If the applicant already has established a business relationship with the credit provider, should the data obtained through this API fall under yet established business relationship or on the basis of the AISP service that it provides? Despite efforts from regulators to provide guidance on this topic there are some granular, but very fundamental questions that require more clarity when navigating this particular field in the “PSD2 Trilemma”.

A potential avenue for a solution?

The requirement of transaction monitoring - although a clear necessity - appears to be a barrier for entry in particular for PISP and AISP services, but in general for PSPs without the actual effectiveness you would and actually may expect.6

Looking at recent developments with regard to transaction monitoring such as the Transactie Monitoring Nederland (TMNL) initiative shows that it is possible to find new and effective ways to combat money laundering by combining forces. This collaboration of 5 large Dutch banks that will result in joined analysis of transactional data is expected to improve the effectiveness of transaction monitoring while reducing costs and required resources.
As TMNL will not be open to PSPs for the coming years, should PSPs also join forces and build a similar utility perhaps on a national or even better pan-European scale? Just a thought…

1-Consultation paper, EBA JC/2019/87, 18.11 p. 133
2-DNB on post-event transaction monitoring process for payment service for PSPs, 09/2017:
https://www.toezicht.dnb.nl/en/binaries/51-236852.pdf
3-ETPPA response on EBA AML guidelines, 07/2020:
https://drive.google.com/file/d/1tKIhv8TmNE3GvMI0kkeE1IjmK-F5EZwx/view
4-https://eba.europa.eu/eba-supports-eu-commission%E2%80%99s-call-more-efficient-and-effective-framework-tackle-money-laundering-and
5-Transaction monitoring requirements for account information services, DNB, 11/2019:
https://www.toezicht.dnb.nl/3/50-237181.jsp
6-See under footnote 4

Did you find this useful?