Why PISPs should not be required to perform AML checks toward PSUs

According to PSD2, a payment initiation service provider (PISP) represents a payment institution, and thus falls under the Anti-Money Laundering (AML) and Anti-Terrorist Financing (ATF) regulations. Yet, for many market participants, the setup of these checks from PISP’s side is not clear. I think this is an interesting topic that hasn’t been explored enough. It’s important to note that this article focuses on PISPs that provide only payment initiation services. Going forward, I will try to present some arguments from legal and technical perspectives and market experience, as well as to draw an analogy with similar business models. 

First, let’s see the scope of AML/ATF regulations. Their role is to combat money laundering, financing of terrorism and these regulations are designed to prevent the financial market from being misused for these purposes. AML/ATF checks should be performed when establishing a business relationship, when carrying out occasional transactions, when there is a suspicion of money laundering or terrorist financing, when there are doubts about the veracity or adequacy of previously obtained customer identification data, etc. Typical AML and ATF flows are familiar to any business that has a bank account and includes the following checks:

• Know Your Customer (KYC), including identity and address checks;
• Customer Due Diligence (CDD) ongoing checks;
• Sanctions Lists checks;
• Politically Exposed Persons checks;
• Transaction monitoring checks.

In the payment flow, PISP can interact directly with both payment service user (PSU – payer) and merchant (payee). It can have an agreement with either one of them or both. Taking into account that PISP plays the role of intermediary between the two entities, it should be decided on whom PISP should conduct the AML checks. 

It’s important to understand what type of service is performed by PISP and its role in the payment flow. PISP provides payment initiation services by receiving instruction from PSU, via merchant’s platform, and generating a payment order. Taking into account that PISP is not in possession of funds, it sends the payment order to account servicing payment service provider (ASPSP) where PSU’s funds are stored. The payment order is authorized by PSU using authentication credentials provided by ASPSP in compliance with strong customer authentication (SCA) and dynamic linking requirements.

To summarize all of the above – PISP is responsible for generating payment orders based on request from PSU and does not influence the execution of the payment. The payment order simply represents information about PSU’s wish to initiate the payment. 

The card processing company plays a very similar role to PISP’s in the payment flow during card payments. Interestingly, card processing companies do not conduct AML/ATF checks towards PSU – only towards merchants (if needed). 

Let me list the similarities between PISP and card processors in regard to the steps during the payment flows: 

• Both PISP and card processors are relying on credentials issued to PSU by the respective ASPSP:
  • PISP – authentication credentials issued by ASPSP; 
  • Card processors – card details issued by ASPSP (i.e. PAN, CVV/Expiration Date, PIN, 3D Secure credentials);
• Both types of credentials fall under SCA and dynamic linking requirements according to PSD2;
• In both cases PSU should authorize execution of the payment transaction;
• For both types of payment flows, ASPSP will be handling verification of PSU authentication credentials or card details before executing the payment transaction.

PISP and card processor have similar roles, yet the latter has even slightly more power – it can be in possession of PSU’s funds, most often has access to authentication data (card details), including PAN/CVV/PIN/etc. Now the question is – if card processor, a company that has similar roles as PISP, does not conduct AML checks on PSUs, why should PISP be required to do it? 

Requiring PISPs to conduct AML checks toward PSUs comes with ‘inconsistencies’ in legal and market conditions:

1. According to PSD2 [Article 66. 3 (f)], PISP should not request from the PSU any data other than those necessary to provide the payment initiation service;              
2. According to PSD2 [Article 66. 3 (g)], PISP should not use, access or store any data for purposes other than for the provision of the payment initiation service as explicitly requested by the payer;
3. Such requirement contradicts Article 5(1)(c) of the General Data Protection Regulation (GDPR) on the principle of data minimisation;
4. As mentioned above, similar business models employed by card processors do not fall under the AML/ATF requirements in regard to PSUs;
5. PISPs do not open payment accounts, are not in possession of PSU’s funds, and they rely on PSU authentication procedures set by ASPSP during the payment flow.

ASPSP is the entity that has direct contact and closest relationship with PSU, based on the agreement and the services it provides. ASPSP opens and maintains PSUs’ payment accounts, holds their funds, and most importantly – conducts strong customer authentication during payments. Taking into account that ASPSP already performs AML/ATF checks toward PSU, such checks performed also by PISP will be a duplication of effort, increasing payment flow duration and customers’ frustration. 

Besides, obliging PISPs to conduct AML checks toward PSUs comes with significant barriers to providing payment initiation services, taking into account that such requirements:

• undermine the very principle of “fair competition among all payment service providers” postulated in PSD2 (PISPs are subject to stricter requirements in comparison with card processors);
• will not “allow for the development of user-friendly, accessible and innovative means of payment” (a PSD2 requisite);
• will not “ensure technology and business-model neutrality” (likewise, a PSD2 requirement);
• will cause PSU’s dissatisfaction, and lead to increased abandonment during the payment process.

In the real-world scenario, lengthy due diligence checks towards PSU during the payment flow will result in abandonment at checkout and, at best, switching to alternative payment methods, i.e. cards or even cash. Imagine being required to upload a picture of your passport every time you want to pay online for goods or services. Such requirements heavily increase the costs of offering payment initiation and third party services in general, resulting in barriers to enter the market. Thus, the approach of obliging PISPs to conduct AML checks toward PSUs would lead to Open Banking forfeiting its initial goal of encouraging innovation and even more, the massive investments made so far would all be in vain.

New market players, such as PISPs and AISPs, already face a lot of obstacles in regard to bad quality of PSD2/Open Banking APIs, incomplete documentation, limited testing facilities, lack of fallback channels, requests of multiple PSU consents, application of SCA without transitional period, and many more. Such obstacles significantly delay the consumption of TPP services by PSUs. Additional uncertainty in regard to application of AML/ATF checks for TPP will definitely slow down Open Banking adoption by the market. Actually, these are the main reasons why payment initiation services have such low volumes in the UK – even 2 years after Open Banking APIs went live.

As regards the AISP use case – it’s an even more mixed up situation. The AML/ATF regulations consider AISP an entity obliged to apply AML/ATF measures and controls, by virtue of it being a payment service provider under PSD2. Yet, PSD2 exempts AISPs from complying with AML/ATF requirements (Article 33(1) exempts AISPs from the application of Article 5(1)(k)). In light of the above-described reasons on why conducting AML checks on PSUs should not apply to PISPs, it’s even more questionable why AISPs – entities which do not participate in the payment flow at all – should be subject to AML/ATF requirements towards PSUs.

Written by Dmitrii Barbasura, Founder and CEO at Salt Edge

About Salt Edge 

Salt Edge – a financial API platform with PSD2 and open banking solutions. The company has two main vectors of activity: enabling third parties to get access to bank channels via a unified gateway, and developing the technology necessary for banks to become compliant with the directive’s requirements. ISO 27001 certified and AISP licensed under PSD2, the company employs the highest international security measures to ensure stable and reliable connections between financial institutions and their customers. The company is integrated with 3800+ financial institutions in 70+ countries.

More information: www.saltedge.com

Phone number: +1-437-886-3969

E-mail: press@saltedge.com