Response to consultation on draft Guidelines under Articles 17 and 18(4) of Directive (EU) 2015/849 on customer due diligence and ML/TF risk factors
Go back
ETPPA welcomes the opportunity to comment on the EBA Guidelines on revised money laundering and terrorist financing (ML/TF) risk factors. However, the ETPPA has some fundamental concerns on the scope of the implied AML requirements for AISPs and PISPs and does therefore in the first part of its response (Section I, below) raise these general concerns and explain why AISPs (Section I.A, below) and PISPs (Section I.B, below) should not be covered by the scope of the Anti-Money Laundering (“AML”) requirements and guidelines.
In the second part of its response (Section II, below), ETPPA comments on those specific requirements and drafting suggestions for the proposed Guideline 18 that should be taken into account to ensure business neutrality, if the EBA was to include the AML requirements in their guidelines for AIS and PIS providers.
Additionally we note that the EU Commission is currently consulting on an AML action plan. We would request that the AML guidelines are not finalised until the conclusion of the Commission’s consultation - particularly given the contention around whether AIS and PIS were intended to be included as obliged entities, or whether this was the unintentional result of cross referencing between PSD2, CRD and AMLD.
Executive Summary:
AISPs do not have any relation to financial transactions, they do not conduct financial activities. Therefore, they should not be subject to AML obligations. In any event, it should be clarified for AISPs in particular (e.g. in Guideline 18.15) - that a sufficient Simplified Customer Due Diligence (SDD) would consist in deriving the name of the account holder from his account, while ASPSPs are obliged to provide that information according to Article 36 RTS 389/2018.
This principle applies to any TPP: They rely on the Strong Customer Authentication (“SCA”) procedures of the ASPSP in line with Article 97 PSD2 to authenticate payers, and shall be able to rely on ASPSPs also for access to the identification details such as the name of the account-holder, where required.
The “customers” of PISPs are the online-merchants (the payees), not the account holders (the payers). Proposed Guideline 18.8 wrongly suggests otherwise, in conflict with the current practice, and needs to be rectified. PISPs may reasonably be obliged to conduct SDD on their customers, the online-merchants.
General comments on the scope of AML requirements for AISP and PISP
All ‘Financial Institutions’ are subject to the anti-money laundering requirements. ‘Financial Institutions’ are defined as those carrying out one or more of the listed activities set out in points 2 to 12, 14 and 15 of Annex 1 to the Capital Requirements Directive (CRD, Directive EU 2013/36 EU). Point 4 of the Annex to CRD previously included payment services as defined under PSD1 (Directive 2007/64 EC). PSD2 (Article 113, Directive 2015/2366 EU) updated Point 4 of CRD to include the new list of payment services in PSD2, which includes AIS and PIS and brought these services into the scope of AML, possibly without intent or at least without a thorough investigation of its unintended consequences.
ETPPA believes that before a specific consultation on the detailed AML guidelines for AIS and PIS providers is launched, there should be a more fundamental discussion, as to whether there is a need to include these services into the scope of the AML requirements. The EBA consultation acknowledges that they and other ESAs ‘consider that the ML/TF risk associated with their activities is limited’. However, it continues then to propose some actions for AISPs and PISPs which would prove extremely burdensome, and go beyond what these businesses would usually do to provide open banking services:
As part of their CDD processes, PISPs and AISPs should ensure that their AML/CFT systems are set up in a way that alerts them to unusual or suspicious transactions. Even without holding significant information on the customer, PISPs and AISPs should use their own, or third party typologies, to detect unusual transactional activity.
PISPs and AISPs should apply CDD measures to their customers.
Each time an account is added, the AISP should ask the customer whether the account is his own account, a shared account, or a legal entity’s account to which the customer has a mandate to access (e.g.: an association, a corporate account).
A. ETPPA’s concerns on impacts of AML application to Account Information Service Provider (AISP) businesses
1. No risk that money-laundering or terrorist financing can occur through an AISP platform
ETPPA agrees with the objective of the EU’s Fourth Anti-Money Laundering Directive (4MLD) to restrict the flow of illicit finance by setting minimum common regulatory standards for Member States. Whilst the purpose of AML requirements is to restrict the flow of illicit finance, AML legislation also focuses on the idea that firms should take a risk-based approach to ensure proportionate duties on participants, striking a balance between regulating to protect the financial system and onerous administrative duties for legitimate businesses.
However, as the EBA acknowledged in its Consultation Paper (Guideline 18.2 lit. b), AISPs do not provide payments and are not involved in the payment chain. They are simply technical information service providers that do not generate, control or influence any of the information they deal with, but that are merely providing technical access to this information. AISP had been categorized as “Technical Service Providers” (TSP) in the sense of Article 3 lit. j PSD1, being out of scope and for that reason also not subject to AML regulations. The judgement that AISP are mere technical service providers has not changed, and there was no discussion on AML duties in the run-up to PSD2, either. The reason to include AISPs into PSD2 was to protect them against obstruction, but not from any perceived or alleged AML risks, as they do not deal with funds in any way. While PSD2 in Article 66(3) a) explicitly prohibits PISPs from holding at any time the payer’s funds in connection with the provision of the service, the corresponding Article 67 PSD2 for AISPs does not even contain any provision of that sort for AISPs, as it has been correctly assumed based on the non-transactional nature of the service that AISPs do not handle customers’ funds at any point. Hence, the ML/TF risks do not arise, as AIS do not rely on any transaction or any handling of funds.
Without the ill-conceived reference in Article 113 PSD2, AISPs would not fall under the AML Directive, because they do not perform any “financial activity” in the sense of Article 2 AML-Directive. AISPs do not fulfill any of the criteria mentioned in Article 2 AML-Directive apart from being listed in Annex I to PSD2 as “payment service provider”, which should have been qualified as “for the purposes of PSD2” to clarify that this does not make them financial service providers (as they remain technical services).
Further, Article 2 para. 3 AML Directive allows Member States to exclude from the scope of the AML Directive persons engaged in financial activities only on a limited basis, which are understood to pose a little risk of ML/TF, subject to further conditions. As AISPs do not perform any financial activities, it must be assumed that their services pose even lesser risk of ML/TF and their right for an exemption from the scope of the AML Directive is even more justified than for entities occasionally engaged in financial activities. EBA should consider recommending to Member States to use the exemption from Article 2 para 3 AML Directive to exclude AISPs from the scope of the Directive, especially considering the inherent limited ML/TF risk associated with AIS (Guideline 18.2) (see Section I.A.4 for further explanation).
AISPs are only permitted (legally and technically) to access account information for the purposes of providing account information services i.e. presenting the data back to the PSU. either the AISP nor the AISP’s customer can conduct financial transactions on a bank account from within the AISP environment. Application of AML requirements to AISPs would not have the effect of restricting the flow of illicit finance as there is no basis for money laundering or terrorist financing to occur via an AISP platform. AML obligations properly sit with the financial institution (i.e. the bank/ASPSP), which provides the accounts in relation to which an AISP provides information services; this is where the transactions take place and where the relevant business relationship with the customer exists. The risks identified by EBA in the Guidelines (18.4-18.7) are related to transactions / operations that have already occurred on the customers’ accounts held by ASPSPs and as such must have been subject to the ASPSPs’ AML control mechanisms. As a result, those risks cannot be assigned to AIS, as it merely aims at consolidating account information and providing it to the customer to use or share with third party providers (“TPPs”), but they have to be assigned to operations performed by ASPSPs who are the first in line to identify and report the risks accordingly at the moment of their occurrence.
For example, when the customer “transfers fund from different accounts to the same payee that give grounds to suspect that the customer is trying to evade specific thresholds using various payment accounts” (Guidelines, 18.4 lit. b), the banks through their AML checks should have already identified the risk and there should be no need for a repeated AML check, as only this would be in line with the principle of avoidance of repeated customer identification procedures (Recital 35 AML Directive).
AISPs enable customers to share data - and only data - with their selected service providers, including TPPs. Data itself is neutral and not a means for money laundering, or any transaction at all. When a customer selects an AISP, and consents for its AISP to retrieve specific data from its ASPSP, there are essentially three parties that hold the exact same data: the regulated ASPSP, the TPP, and the AISP. It is clear that holding the data is not indicative of facilitating money laundering, nor is the act of sharing that data a means to money laundering.
Last but not least, Art. 97 (1) lit a PSD2 requires a Strong Customer Authentication (“SCA”) for any access to account with the help of an AIS. Accordingly, the identity of the PSU is necessarily being established and authenticated for every AISP under PSD2 in a secure and reliable fashion already, so there is no need for additional identity checks on top. The ASPSP has the duty to check and confirm the identity of the account holder when (a) opening the account and (b) issuing the personalized security credentials, namely according to Article 11 lit a AML-Directive (2015/849 EU) and in line with Article 24 of the Delegated Regulation 389/2018 EU (“RTS”). Hence, when AISPs rely on these personalized security credentials for authentication in line with Article 97 (5) PSD2, the identity of the account holder is being established with the same degree of certainty that applies for ASPSPs. Accordingly, there is no need for additional checks by AISPs, which cannot produce additional security or transparency.
2. AML related requirements will dissuade customer take-up of AIS and provide limited value at high cost
AISPs are required to gain the customer’s, i.e. the end-user’s, explicit consent to access a customers payment accounts in order to provide account information services. , AISPs must clearly inform the customer of what data they are accessing and for what purpose. If AISPs were subject to AML measures, this subjects AISPs to disclose to the end-customer that they will be using their data to fulfill the additional transaction monitoring for anti-money laundering and counter terrorism financing.
3. Data collection for the purposes of AML is incompatible with PSD2
PSD2 Article 67(2)(f) states that AISPs “must not use, access or store any data for purposes other than for performing the account information service explicitly requested by the payment service user, in accordance with data protection rules.”
The EBA Guidelines appear asking AISPs to “ensure that their AML/CFT systems are set up in a way that alerts them to unusual or suspicious transactional activity.”
This is effectively asking AISPs to serve a separate purpose - to be watchdogs for illegal money flows through the banks - is disproportionate, contrary to existing law, and was never initially outlined as an objective of PSD2. Under PSD2 and GDPR (data minimization), these companies must only use data strictly to provide the services customers request.
To require AISPs to do transaction monitoring would, as noted above, require explicit customer consent as well as disclosure as to the purpose of additional transaction monitoring. It could imply that AISPs would also need to build brand new systems to process their customers’ transaction data and detect suspicious transactions.
If AISPs were required to monitor all transactions on the customer account this would be equivalent to asking AISPs to police the entire banking ecosystem. For customers with multiple bank accounts, this means an AISP is therefore burdened with monitoring the transactions across all the accounts and banks to which they are connected. This is beyond the scope of PSD2, and beyond the service an AISP provides. It is also redundant, considering that the transactions should be verified as regards their AML compliance by the entities that actually perform the transactions, namely, ASPSPs. It is burdensome, and counter to PDS2 both from a role and responsibility perspective, as well as stifling the ability for customers to access innovative services. It is also an additional cost layer, which performs a redundant purpose, as all transactions on the accounts are already being monitored by the banks’ that perform the transactions in question.
Furthermore, because AISPs are required to re-authenticate the customer’s consent every ninety (90) days under current rules, via SCA, most AISPs only have 90 days’ worth of transactional data on which to perform a deeper level of transaction monitoring. This limited data set stymies the ability to perform robust fraud recognition.
AISPs are unlikely to identify fraudulent activity in relation to their read-only access to the data, because their checks could not run in real time, but only after the transaction has been fulfilled (before that, it is not visible for the AISP, who is only at the receiving end after the transaction has been executed). AISPs therefore cannot provide any notification before a transaction order has been completed. They could discover suspicious activity only after the fact. The AML checks in the real time should be run by ASPSPs who actually carry out the transactions. The double-check of the same transaction would contradict the principle of avoidance of repeated customer identification procedures (Recital 35 AML Directive) and it would lead to delays and inefficiency.
This would be a belated duplication of the work already being done by the banks, in vain and at an additional cost. There is a real risk of an increase in the number of false positives, as an AISP could only send out a suspicious activity notification. Considering the limitations of no real-time analysis, as well as an increase in false positives, these notifications would serve no purpose but still increase the costs of investigation and reconciliation.
Bank-owned AISPs would simply refer to the checks of the bank, avoiding the redundancies, while non-bank AIPS would have to add an additional layer of redundant and belated checks, reducing their attractiveness and competitiveness. For these reasons, requiring AISPs to perform transaction monitoring for suspicious AML/CTF activity is redundant and costly and has a negative impact on the number of competitive AISP actors in the market.
4. AISP Authorization Requirements do not include AML/CTF Controls
We believe it was the original intention for AISPs to be carved out of these obligations. Article 33 (1) PSD2 specifically exempts AISPs from Article 5 (1) lit (k) PSD2, i.e. as part of their license application, AISPs do not have to submit a description of their AML control mechanisms. By explicitly exempting AISPs from having to detail AML/CTF controls from the AISP authorization requirements, it is clear that no such obligations were intended to apply to AISPs.
To continue to require AISPs to perform AML/CTF checks is in conflict with Article 33 (1) PSD2. The ETPPA concludes that no such obligations were intended to apply to AISPs: Where internal AML/CTF control mechanisms are not required as part of the AISP application process, no obligation exists. In the legislative process, this exemption was created specifically to reflect the fact that AISPs do not control or influence the flow of funds, or engage in any financial activity, and therefore should not be subject to AML rules.
This can be construed as a specification to Article 2 (3) AML-Directive, which foresees the exemption of “financial activities” with a very limited or only occasional scope. In case of AISP, there is no financial activity at all, so they should be exempted a fortiori. Article 33 (1) PSD2 could thus be understood as lex specialis to Article 2 (3) AML-Directive, foreseeing a statutory exemption under EU law.
5. Disproportionate
PSD2/Open Banking was introduced to increase innovation and competition – providing consumers with more choice and options. Any application of AML requirements to AISPs is counterproductive to the purpose of this regime. Some AISPs will not be able to continue to operate with the compliance overhead of AML requirements, and others simply won’t get off the ground due to the additional cost layers resulting from both the AML/CTF checks as well as the heavier touch transaction monitoring obligations. This will make it incredibly difficult for small businesses and consumers to effectively and efficiently access and use new and disruptive AIS.
As a specific example, implementing identification and verification checks into the sign-up flows of AISPs will have a negative impact on customer adoption of new products and services affecting the future viability and success of these businesses, and ultimately of the open banking regime. And this needs to be contrasted with bank-owned AISPs that may rely on the AML checks already performed by their bank. Accordingly, bank-owned AISPs would gain a competitive advantage, despite the fact that non-bank AISPs perform the same SCA authentication, resulting in the same certainty about the identity of the PSU.
Articles 25 et seq AML-Directive provide for the performance of identity checks by third parties, and bank-owned AIPS rely on this. The same should be the case for non-bank AISPs, independent of whether they have a contract with the ASPSP:
First, Art. 67 (4) PSD2 says “the provision of AIS shall not be dependent on the existence of a contractual relationship between the ASPSP and the AISP for that purpose”.
And second, because of Article 97 (5) PSD2, the ASPSP has already the statutory duty to allow the AISP to rely on his security credentials and the authentication procedures for the SCA. Accordingly, with that statutory duty, no additional contractual arrangement is necessary, and ASPSP would be obliged to provide all information required under Article 27 AML-Directive. As a result, no second 8and redundant) identification is required with the first identification already being fully accessible.
The result is that for any use of AIS, the identification has already been done and can be authenticated via SCA – hence no need for additional checks burdened upon the AISP. See for that purpose Recital 35 AML-Directive: “In order to avoid repeated customer identification procedures, leading to delays and inefficiency in business, it is appropriate, subject to suitable safeguards, to allow customers whose identification has been carried out elsewhere to be introduced to the obliged entities.”
6. Onerous and redundant
In the interest of reducing the overall burden of regulation on participants, we believe that a number of the requirements of AML regulations are already satisfied prior to an AISP consuming transaction data from a financial institution. For example, banks will have already conducted customer due diligence measures on account holders using AISP services, meaning that further checks are ‘doubling up’.
In nearly all cases the bank is best placed to undertake the appropriate checks and monitor transactions for suspicious behavior. Requiring an AISP to perform the same measure the bank has already taken is redundant and would serve no purpose other than burdening AISPs with unnecessary overhead costs and compliance.
One of the objectives of the AML-Directive is to balance the objective of protecting society from crime against the need to create a regulatory environment that allows companies to grow their businesses without incurring disproportionate compliance costs. Any onerous and redundant double-up compliance on an AISP would be counter to the objectives of the AML-Directive, and would also negatively impact competition and customer choice and convenience.
To avoid the double-up compliance and to prevent “delays and inefficiency in business” (Recital 35 AML-Directive), the obliged entities are allowed to rely on CDD performed by third parties. It is therefore our understanding that also AISPs are allowed to rely on ML/TF checks performed by the banks and, based on Article 27 AML Directive, they are entitled to obtain from the banks the necessary information concerning the compliance with customer due diligence requirements. AISPs should not be required to perform repeated compliance checks, as they are ill-equipped to perform a comprehensive and reliable AML control, especially considering their limited access to customers’ data and the non-transactional nature of their services.
7. Risk Self-Assessment
While the AML-Directive requires Member states to ensure application of the CDD requirements from the Directive, it also leaves a room for obliged entities to “determine the extent of such measures on a risk-sensitive basis” (Article 13 para. 2 AML Directive). Also EBA in the Guidelines (18.9-18.10) confirms that AISPs (and PISPs) should identify and assess the ML/TF risks and determine an adequate extent of CDD measures.
While performing the risk self-assessment, obliged entities must take into account a number of variables, as laid out in Annex I AML-Directive. Based on Annex I, AIS pose low (if any) AML risk:
The purpose of an account / relationship (Annex I (i) AML-Directive) is non-transactional and not related to holding customers’ funds
The level of assets to be deposited or the size of transaction (Annex I (ii) AML-Directive) cannot be assessed, as AIS do not include any transaction.
Against this background, the regularity or duration of the business relationship ((Annex I (iii) AML-Directive) of AISPs with their customers would be irrelevant.
Hence, if AISPs were to perform a risk self-assessment, they would most likely come to the conclusion that their AIS pose no ML/TF risk and only limited (if any) CDD measures are required.
8. Unintended consequences
We understand from the European Commission that the unqualified inclusion of AIS activities in Article 113 PSD2, and the application of AML requirements, may have been probably a drafting inaccuracy, caused by the blanket use of references in PSD1 (which did not have the concept of account information services in its definition of ‘payment services’) as references also for PSD2. This construct triggered automatic implications for the definition of ‘payment services’ in the list of activities subject to mutual recognition in Annex I to Directive 2013/36/EU and, as a result, for the definition of ‘financial institution’ in the AML-Directive. The unintended consequences of this are now showing and need to be avoided.
9. Conclusion regarding AISP AML Requirements
Data is neutral and therefore holding the data is not indicative of facilitating money laundering, nor is the act of sharing that data, subject to customer consent, a means to prevent money laundering. An AISP simply consolidates and makes that data available for sharing; therefore there is no risk of an AISP facilitating money laundering. AISPs do not monitor transactions unless requested by their customers.
PSD2 foresees that AISPs should have a limited role as a conduit, with minimal processing of data (principle of necessity). To fulfill AML/CTF compliance on transaction monitoring would be in direct violation with this PSD2 “light touch” requirement. The additional expense and burden on AISPs to comply runs counter to promoting competition, contradicting the desired outcomes of PSD2.
AISP authorization requirements do not include AML/CTF controls, and it is clear that no such obligations were intended to apply to AISPS. Continued AML/CTF control obligations are both harmful to competition, as well as burdensome and redundant. Moreover, other “financial activities” with a higher risk of money laundering have been exempted from AML/CTF requirements, see for example Article 2 (3) AML-Directive or Article, and Article 12 AML-Directive on electronic money, whilst AISP are not engaging in any financial activities, in the first place.
It is for these reasons that ETPPA strongly believes that AISPs should be removed from the scope of AML requirements. AML requirements for AISPs would not serve the purpose for which they were intended, and be disproportionate to the risk (there is none) of any money laundering or terrorist financing occurring through AISP platforms, as well as burdensome and redundant.
B. ETPPA Concerns on impact of AML application to Payment Initiation Service Providers (PISP) businesses
The PSD2 regulated activity of ‘payment initiation services’ has been designed specifically to protect innovative PISPs in their market access and ability to compete with incumbent payment providers such as banks and card schemes. Many of the arguments for removing AML obligations from AISPs apply equally to PISPs.
More specifically, the AML-Directive does not provide a legal basis for subjecting PISPs to the obligation of performing a CDD on each payment initiation. The AML Directive foresees in Article 11 CDD only for some cases, chiefly when (a) establishing a business relationship or (b) when carrying out an occasional transaction (above a certain threshold). The typical PIS business model does not fulfill these provisions, as PISPs do not have a “business relationship” with the account-holders (PSUs) in the sense of Article 11 lit a AML-Directive, and they do not “carry out” any transactions in the sense of Article 11 lit b AML-Directive.
EBA itself highlights that “PISPs, although being involved in the payment chain do not execute themselves the payment transactions and do not hold payment service user’s (PSU) funds” (Point 18.2 of the proposed Guidelines). Consequently, the only remaining basis for the CDD for PISPs is Article 11 (e) AML Directive, which requires CDD “when there is a suspicion of money laundering or terrorist financing, regardless of any derogation, exemption or threshold”. This would mean that PISPs would not have to perform CDD on a regular basis for all payment initiations, but only exceptionally to those payment initiation operations that raise suspicion of ML/TF.
And to the extent PISPs are being subject to CDD obligations, the following key considerations apply:
2. Duplicate and redundant PISPs customer due diligence on each end-customer.
CDDs on the account-owners would involve requesting name and address from each customer, storing these details, and using a paid-for electronic ID verification system. This would make it de facto impossible for PISPs to provide services. An end-user uses a PIS on an ad-hoc basis, when interacting with and paying a merchant. In those instances, PIS will be one of several payment methods in the merchant’s “check-out” section. The end-user will want to pay in a quick and safe way. Inserting a CDD-process (i.e., halting the customer and asking for a copy of their passport) as part of the payment flow will, compared to other payment methods, make it a relatively speaking unacceptably onerous procedure to pay , which will mean many end-users, having initially chosen to pay with PIS, will drop out of the process and not complete the payment. This from a merchant perspective could mean unacceptably low conversion for PIS as a payment method.
It is actually one of the key PISP characteristics that customers do not have to open an additional account and do not have a balance with the PISP, but use their existing bank account for paying online. This also allows customers to easily use different PISPs with different merchants depending on the available check-out options, which is a crucial requirement to allow for competition in the provision-of-PIS-market.
Most importantly, for every payment initiation there is already the ASPSP performing CDD on the account owner as per Art. 11 AML-Directive. The PISPs relies on that identification via the dynamic SCA that the ASPSP has to perform for any transaction according to Article 97 (2) PSD2. Accordingly, there is already a complete, secure and consistent identification and authentication for every transaction already in place, making any additional checks on the account owner redundant and pointless.
3. Requiring additional due diligence for each end customer is inconsistent with PSD2.
According to Article 66 (3) lit g PSD2, a PISP should not use, access or store any data for purposes other than for the provision of PIS. This stands in contrast to additional AML checks on the identity of the account owner.
If AML obligations vis-a-vis the end-user were imposed on PISPs, then the PISP would have to access these data related to the identity of the payer as held by the ASPSP. This would either have to be accessible via the customer-facing interfaces (or fallback), or be provided by the ASPSP in its TPP-facing “dedicated” interface. In other words, if the PISP needed more identification data on the account owner, his only available source would be the account-servicing bank that has this information and would have to provide it to the PISP. This would be redundant, as the ASPSPs has already performed these checks when opening the account and issuing the personalized security credentials in the sense of Article 97 PSD2, and the PSU authenticates himself on that basis via SCA according to Article 97 (2) PSD2 – so the same information would be gathered twice with no additional gain or insight.
4. Unlevelled playing field between PISPs and card processors/ schemes
In a merchant context, an account-owner (i.e. the end-customer of the products) has a 'one-off' interaction with the PISP, in the same way as a customer paying by card has a 'one-off' interaction with whichever card-acquirer happens to be serving the merchant (not the account-owner). As explained above, imposing AML obligations vis-a-vis the end-user would put PISPs at an unlevelled playing field with the card payment services they are competing with, thereby frustrating the PDS2 mandate to increase competition.
It is also duplicative and redundant (as the customer already performs SCA with his bank to confirm his payment) and would due to the deterioration of conversion rate render PIS as a merchant-facing payment method worthless. Card processors do not perform AML on payment service users at the check-out. However, unlike PISPs, Card processors can be in possession of a payment service user’s authentication data (card details including PAN/CVV/PIN). PISPs rely on authentication procedures set by the bank during the payment flow, Article 97 (5) PSd2, so are inherently at a far lower risk of being used to commit fraud.
5. Obliging PISPs to conduct AML checks on end customers is a significant barrier to providing payment initiation services.
These requirements undermine the very principle of “fair competition among all payment service providers” postulated in PDS2, Article 98 (2) lit c: PISPs are subject to stricter requirements in comparison to card processors who have a similar business model. Not only will it not “allow for the development of a user-friendly, accessible, and innovative means of payment”, Article 98 (2) lit e PSD2, it will not “ensure technology and business-model neutrality”, Article 98 (2) lit d PSD2, both of which are PSD2 requisites. It goes further to damage competition, as it will cause payment service user dissatisfaction and lead to increased abandonment during the payment process.
6. Disproportionate and burdensome
Moreover, unlike other payment service providers (banks, money remitters, e-money institutions), who come into possession of funds during the provision of their services, pure PISPs are not part of the flow of funds (according to Article 66 (3) lit a PSD2, PISPs are not allowed to hold the payer’s funds). A pure PISP does not execute the payment, but simply offers software by which the payment order is transmitted by the PSU to his bank. The funds move directly from the customer’s bank to the payee's bank. As PSD2 states in Recital 31: “When exclusively providing payment initiation services, the payment initiation service provider does not at any stage of the payment chain hold the user’s funds”.
Hence, as a minimum, the scope of AML checks should be limited to the customer of the PISPs, namely the online-merchant and payee. This is the approach taken by authorities so far, which is consistent with the objectives of the AML-Directive. First, because it refers to the “business relationship” of PISPs in the sense of Article 11 lit a AML-Directive. And second, this may actually add to the overall security of the system, because PISPs could help to prevent AML risks on the side of the merchant via their business relationship. Ensuring that PISPs take appropriate measures to verify who the beneficiaries of end-users payments are and for what purposes the merchant is obtaining the PISP’s service will likely fulfill the objectives of the AML-Directive, better than conducting redundant CDD on the end-users (which have already been performed by the ASPSPs). This is what is currently already taking place in practice, and there have been no complaints about this approach.
PISPs cannot be obliged to perform CDD on both, their customers (the payees) as well as the account-owners (the payers), at the same time. For that reason, we believe that PISPs should only be obliged to perform CDD on their customers, which is the online-merchant (payee). This approach has been proven to be effective and efficient in practice and it is in line with the wording and purpose of the AML-Directive (and PSD2). Contrarily, imposing on PISPs conducting CDD on account-owners would be impractical and pointless as well as against the AML rules.
7. Conclusions regarding AML requirements for PIS Providers
It is for these reasons that the ETPPA strongly believes that PISPs are not subject to AML requirements regarding the account holders. Such AML requirements would not serve the purpose for which they were intended and be disproportionate to the risk (there is none) of any money laundering or terrorist financing occurring through PISPs’ platforms, as well as burdensome and redundant.
C. Overall conclusions
We therefore object to the draft EBA Guidelines and plead to exclude AISP and PISP from their scope, to enable a further discussion of the matter.
In any event, the proposed Guidelines would have to be adapted as set out below, in Section II.
II. Specific comments on EBA Guidance for PISPs under AML in the Point 18 of the proposed Guidelines
If the EBA were to include the AML requirements for AIS and PIS providers in Point 18 of the Guidelines, ETPPA would like to emphasize the following points that should be taken into consideration:
The sector-specific Guidelines for AISPs and PISPs should remain risk and principle based and as a minimum do not exclude certain business models by making statements that rule out any market practice. The market for AIS and PIS services in particular is still in an early stage of development and many business models may yet arise to address a particular market need.
Comments on Draft Guideline 18.2
Despite our fundamental concerns (see Section I, above), the ETPPA nevertheless welcomes the wording of Section 18.2 which states that
“the inherent ML/TF risk associated with PISP and AISP is limited due to the fact that :
a) PISPs, although being involved in the payment chain do not execute themselves the payment transactions and do not hold payment service user’s (PSU) funds;
b) AISPs are not involved in the payment chain and do not hold payment service user’s funds.”
Comments on Draft Guideline 18.8
Guideline 18.8 (a) is incorrect: PISPs do not have a contractual relationship with the account holders (payment service users); PISP “customers” are the online-merchants
The proposed guideline 18.8 is wrong to state that the “customer”, for whom Customer Due Diligence (CDD) should be performed, was the account holder.
The customer of PISPs is the online-merchant. The PISP does not have a contractual relationship with the account holder. PISPs, as a rule, have a software service contract with the online-merchant, who integrates the PIS software as a payment option (or payment alternative) into his online-shop, offering account owners to rely on that software in order to initiate a payment with their bank and to provide proof of this successful initiation to the online-merchant, see Recital 27 PSD2:
“In particular, payment initiation services in the field of e-commerce have evolved. Those payment services play a part in e-commerce payments by establishing a software bridge between the website of the merchant and the online banking platform of the payer’s account servicing payment service provider in order to initiate internet payments on the basis of a credit transfer.”
The online-merchants pay a fee for the possibility to rely on the PIS software, offering its use to their customers. Account-owners also do not pay any fees to the PISP, and they offset the costs of the online-merchant via their purchasing prices paid to the latter. There may be a software using contract between the online-merchant and the PSU, but there is no payment-related contract or business relationship between the PISP and the PSU.
Accordingly, the account owner is not the “customer” of the PISP in the sense of AML. The PISP does not establish a “business relationship” with the account owner in the sense of Art. 11 (a) AML-Directive. CDD, therefore, cannot refer to the account owner.
This has been confirmed by the ESAs in charge of licensing PISPs: While PISPs need to provide a documentation of their internal AML control mechanisms under Art. 5 (1) lit k PSD2, this has not referred to the identification of account-owners, but to the identification and CDD of online-merchants.
This point makes a very important difference in practice: Account owners are currently able to rely on PIS software without any prior identification to the PISP. They can use the software “ad-hoc”, without prior registration. This is a core feature of PISPs, and would be entirely disabled if CDD would be applied to account owners (to whom PISPs have no direct access). So far, this has not been the case – and there is no legal basis for it in the AML-Directive.
If AML requirements were to be applied to PISPs, they should be limited to what is strictly necessary and avoid any duplicate AML requirements that are already conducted by the ASPSP. They need to take into account who is the “customer” of the PISPs, which normally is the merchant (i.e. the payee), rather than the end user (i.e. the payer). As set out above, this approach is consistent with the objectives of the AML-Directive. Ensuring that PISPs take appropriate measures to verify who the beneficiaries of end-user payments are and for what purposes the merchant is obtaining the PISP’s service is likely to better fulfill the objectives of the AML-Directive, than PISPs conducting redundant and pointless CDD on end-users (which have already been performed by the ASPSPs running their accounts and providing for the SCA in line with Article 97 (2) PSD2).
To ensure business neutrality, the guidelines should distinguish between the different business models where AML requirements for PISPs would be limited to the merchant provided that:
a) the merchant is the PISP customer based on a contractual relationship between the PISP and the merchant,
b) the end-user is not the PISP’s customer, but the customer of the bank
c) the PISP simply provides a software tool, which the online-merchant then offers to his contractual partner, the payer (account owner), who may use it instead of other ways to pay
d) under the general AML obligations the PISP may, where possible, undertake monitoring to spot suspicious patterns of transactions and report these as necessary.
Only the merchant would be, in that typical and normal business model, the customer of the PISP with whom it has a contractual relationship that “has an element of duration” in the sense of Article 3 (13) AML-Directive. The merchant (payee) is the “customer” subject to CDD, not the payer. The PISP would then still perform transaction monitoring on all flows based on its general AML obligations, but he would not perform CDD on the account owner. The Guidelines should therefore state that
For PISPs: The customer is the online-merchant (the payee) that is offering the PIS software as a payment alternative, e.g. on his website or in his online-shop;
Only in exceptional cases, where the PISP has a direct and enduring contractual relationship with the account holder (the payer) in the sense of Article 3 (13) of the AML-Directive, the latter may be regarded as the “customer” of the PISP.]
Comments on draft Guideline 18.10 and 18.15
Simplified Customer Due Diligence
To the extent that TPPs are obliged to realize a CDD, ETPPA agrees with the fact that due to the limited risk of their activities, the simplified customer due diligence (CDD) should be the norm. As written in Point 18.10 “In most cases, the low level of inherent risk associated with these business models means that SDD (simplified due diligence) will be the norm”.
Point 18.15 of the proposed Guidelines helpfully develops this idea, apparently based on the principle of the risk self-assessment enshrined in Article 13 (2) of the AML-Directive (see above Section I.A.7). We welcome these clarifications, which refer to the way that the TPP (here: the AISP) may identify the account-owner under a lighter SDD-regime, namely:
“a) Relying on the source of funds as evidence of the customer’s identity where the payment account details of the customer are known, and the payment account is held at an EEA-regulated payment service provider;
b) Postponing the verification of the customer’s identity to a certain later date after the establishment of the relationship. In that case, firms should ensure that their policies and procedures set out at what point CDD should be applied;
c) Assuming the nature and purpose of the business relationship;”
Point (a) seems to refer to the fact that the ASPSP has already conducted the CDD for the opening of the account as well as for the issuing of the personalized details for the SCA, see Article 24 RTS, Article 97 PSD2. Hence, the information required is already available at the ASPSP, whilst the account owner authenticated himself towards the bank (and towards the AISP, Article 97 (5) PSD2). SDD would then consist in the fact that ASPSPs share the identity with the ASPSP via the PSD2- compliant interfaces, i.e. the consumer-facing interfaces (or fallback), or the dedicated interfaces, or both (see Article 31 RTS for the choice that is available). As pointed out above, the performance of the SDD via a the ASPSP is in line with Article 25 AML-Directive, and the ASPSP should be obliged to divulge the required data to the AISP according to Article 27(1) AML-Directive, in line with Article 67 (3) PSD2, Article 38 (1) lit a RTS (“the same information from designated payment accounts and associated payment transactions made available to the payment service user when directly requesting access to the account information”).
There is indeed already a legal obligation on ASPSPs to divulge all available data to AISPs, also on the identity of the account holder, if that is required for their services. And Article 27 (1) AML-Directive recognizes this as a reliable and sufficient source for AML purposes.
Point (b) seems to refer to Article 14 (2) AML-Directive, which allows the initiation of the services before CDD. This allows the AISP to start his service first and access the account information during the initiation, which then would allow him, according to the rules set out above, to derive and confirm the required information directly from the account itself, i.e. without a separate or additional identification procedure. This avoids a duplicate identification, and enables to rely on the SCA in line with Article 97 PSD2 as is currently the case.
Point (c) seems to refer to Article 13 (3) AML-Directive, allowing AISPs to make reasonable assumptions on the nature and purpose of the business, in consideration of the very low (or non-existing) risk involved with AISP, effectively reducing the SDD for AISP to obtaining the name of the account-holder.
However, since PISPs do not have to conduct CDD/SDD on the account owner altogether (see above), these considerations refer to AISPs in particular, not PISPs. And considering the very low risk of AIS, the EBA should clarify the consequences of the above, namely the fact that AISPs will as a rule not be required to conduct any additional SDD apart from obtaining the name of the account holder form his account (a). This could be clarified as follows:
“On that basis, considering the fact that they pose no significant ML/TF risk, AISP would normally not conduct their own separate identification of the account-holder. Instead, they may rely on the Strong Customer Authentication to be performed in line with Article 97 PSD2, and limit the identification of their customers to obtaining his name, which ASPSPs are legally obliged to provide via their PSD2-compliant interfaces in line with Article 36 RTS 389/2018”.
The same would apply to PISPs where they are, in exceptional cases, subject to SDD of the account-owner (instead of the merchant).
***
Question 18: Do you have any comments on the additional sector-specific Guideline 18 on account information and payment initiation service providers?
ETPPA RESPONSE - EBA AML GUIDELINESETPPA welcomes the opportunity to comment on the EBA Guidelines on revised money laundering and terrorist financing (ML/TF) risk factors. However, the ETPPA has some fundamental concerns on the scope of the implied AML requirements for AISPs and PISPs and does therefore in the first part of its response (Section I, below) raise these general concerns and explain why AISPs (Section I.A, below) and PISPs (Section I.B, below) should not be covered by the scope of the Anti-Money Laundering (“AML”) requirements and guidelines.
In the second part of its response (Section II, below), ETPPA comments on those specific requirements and drafting suggestions for the proposed Guideline 18 that should be taken into account to ensure business neutrality, if the EBA was to include the AML requirements in their guidelines for AIS and PIS providers.
Additionally we note that the EU Commission is currently consulting on an AML action plan. We would request that the AML guidelines are not finalised until the conclusion of the Commission’s consultation - particularly given the contention around whether AIS and PIS were intended to be included as obliged entities, or whether this was the unintentional result of cross referencing between PSD2, CRD and AMLD.
Executive Summary:
AISPs do not have any relation to financial transactions, they do not conduct financial activities. Therefore, they should not be subject to AML obligations. In any event, it should be clarified for AISPs in particular (e.g. in Guideline 18.15) - that a sufficient Simplified Customer Due Diligence (SDD) would consist in deriving the name of the account holder from his account, while ASPSPs are obliged to provide that information according to Article 36 RTS 389/2018.
This principle applies to any TPP: They rely on the Strong Customer Authentication (“SCA”) procedures of the ASPSP in line with Article 97 PSD2 to authenticate payers, and shall be able to rely on ASPSPs also for access to the identification details such as the name of the account-holder, where required.
The “customers” of PISPs are the online-merchants (the payees), not the account holders (the payers). Proposed Guideline 18.8 wrongly suggests otherwise, in conflict with the current practice, and needs to be rectified. PISPs may reasonably be obliged to conduct SDD on their customers, the online-merchants.
General comments on the scope of AML requirements for AISP and PISP
All ‘Financial Institutions’ are subject to the anti-money laundering requirements. ‘Financial Institutions’ are defined as those carrying out one or more of the listed activities set out in points 2 to 12, 14 and 15 of Annex 1 to the Capital Requirements Directive (CRD, Directive EU 2013/36 EU). Point 4 of the Annex to CRD previously included payment services as defined under PSD1 (Directive 2007/64 EC). PSD2 (Article 113, Directive 2015/2366 EU) updated Point 4 of CRD to include the new list of payment services in PSD2, which includes AIS and PIS and brought these services into the scope of AML, possibly without intent or at least without a thorough investigation of its unintended consequences.
ETPPA believes that before a specific consultation on the detailed AML guidelines for AIS and PIS providers is launched, there should be a more fundamental discussion, as to whether there is a need to include these services into the scope of the AML requirements. The EBA consultation acknowledges that they and other ESAs ‘consider that the ML/TF risk associated with their activities is limited’. However, it continues then to propose some actions for AISPs and PISPs which would prove extremely burdensome, and go beyond what these businesses would usually do to provide open banking services:
As part of their CDD processes, PISPs and AISPs should ensure that their AML/CFT systems are set up in a way that alerts them to unusual or suspicious transactions. Even without holding significant information on the customer, PISPs and AISPs should use their own, or third party typologies, to detect unusual transactional activity.
PISPs and AISPs should apply CDD measures to their customers.
Each time an account is added, the AISP should ask the customer whether the account is his own account, a shared account, or a legal entity’s account to which the customer has a mandate to access (e.g.: an association, a corporate account).
A. ETPPA’s concerns on impacts of AML application to Account Information Service Provider (AISP) businesses
1. No risk that money-laundering or terrorist financing can occur through an AISP platform
ETPPA agrees with the objective of the EU’s Fourth Anti-Money Laundering Directive (4MLD) to restrict the flow of illicit finance by setting minimum common regulatory standards for Member States. Whilst the purpose of AML requirements is to restrict the flow of illicit finance, AML legislation also focuses on the idea that firms should take a risk-based approach to ensure proportionate duties on participants, striking a balance between regulating to protect the financial system and onerous administrative duties for legitimate businesses.
However, as the EBA acknowledged in its Consultation Paper (Guideline 18.2 lit. b), AISPs do not provide payments and are not involved in the payment chain. They are simply technical information service providers that do not generate, control or influence any of the information they deal with, but that are merely providing technical access to this information. AISP had been categorized as “Technical Service Providers” (TSP) in the sense of Article 3 lit. j PSD1, being out of scope and for that reason also not subject to AML regulations. The judgement that AISP are mere technical service providers has not changed, and there was no discussion on AML duties in the run-up to PSD2, either. The reason to include AISPs into PSD2 was to protect them against obstruction, but not from any perceived or alleged AML risks, as they do not deal with funds in any way. While PSD2 in Article 66(3) a) explicitly prohibits PISPs from holding at any time the payer’s funds in connection with the provision of the service, the corresponding Article 67 PSD2 for AISPs does not even contain any provision of that sort for AISPs, as it has been correctly assumed based on the non-transactional nature of the service that AISPs do not handle customers’ funds at any point. Hence, the ML/TF risks do not arise, as AIS do not rely on any transaction or any handling of funds.
Without the ill-conceived reference in Article 113 PSD2, AISPs would not fall under the AML Directive, because they do not perform any “financial activity” in the sense of Article 2 AML-Directive. AISPs do not fulfill any of the criteria mentioned in Article 2 AML-Directive apart from being listed in Annex I to PSD2 as “payment service provider”, which should have been qualified as “for the purposes of PSD2” to clarify that this does not make them financial service providers (as they remain technical services).
Further, Article 2 para. 3 AML Directive allows Member States to exclude from the scope of the AML Directive persons engaged in financial activities only on a limited basis, which are understood to pose a little risk of ML/TF, subject to further conditions. As AISPs do not perform any financial activities, it must be assumed that their services pose even lesser risk of ML/TF and their right for an exemption from the scope of the AML Directive is even more justified than for entities occasionally engaged in financial activities. EBA should consider recommending to Member States to use the exemption from Article 2 para 3 AML Directive to exclude AISPs from the scope of the Directive, especially considering the inherent limited ML/TF risk associated with AIS (Guideline 18.2) (see Section I.A.4 for further explanation).
AISPs are only permitted (legally and technically) to access account information for the purposes of providing account information services i.e. presenting the data back to the PSU. either the AISP nor the AISP’s customer can conduct financial transactions on a bank account from within the AISP environment. Application of AML requirements to AISPs would not have the effect of restricting the flow of illicit finance as there is no basis for money laundering or terrorist financing to occur via an AISP platform. AML obligations properly sit with the financial institution (i.e. the bank/ASPSP), which provides the accounts in relation to which an AISP provides information services; this is where the transactions take place and where the relevant business relationship with the customer exists. The risks identified by EBA in the Guidelines (18.4-18.7) are related to transactions / operations that have already occurred on the customers’ accounts held by ASPSPs and as such must have been subject to the ASPSPs’ AML control mechanisms. As a result, those risks cannot be assigned to AIS, as it merely aims at consolidating account information and providing it to the customer to use or share with third party providers (“TPPs”), but they have to be assigned to operations performed by ASPSPs who are the first in line to identify and report the risks accordingly at the moment of their occurrence.
For example, when the customer “transfers fund from different accounts to the same payee that give grounds to suspect that the customer is trying to evade specific thresholds using various payment accounts” (Guidelines, 18.4 lit. b), the banks through their AML checks should have already identified the risk and there should be no need for a repeated AML check, as only this would be in line with the principle of avoidance of repeated customer identification procedures (Recital 35 AML Directive).
AISPs enable customers to share data - and only data - with their selected service providers, including TPPs. Data itself is neutral and not a means for money laundering, or any transaction at all. When a customer selects an AISP, and consents for its AISP to retrieve specific data from its ASPSP, there are essentially three parties that hold the exact same data: the regulated ASPSP, the TPP, and the AISP. It is clear that holding the data is not indicative of facilitating money laundering, nor is the act of sharing that data a means to money laundering.
Last but not least, Art. 97 (1) lit a PSD2 requires a Strong Customer Authentication (“SCA”) for any access to account with the help of an AIS. Accordingly, the identity of the PSU is necessarily being established and authenticated for every AISP under PSD2 in a secure and reliable fashion already, so there is no need for additional identity checks on top. The ASPSP has the duty to check and confirm the identity of the account holder when (a) opening the account and (b) issuing the personalized security credentials, namely according to Article 11 lit a AML-Directive (2015/849 EU) and in line with Article 24 of the Delegated Regulation 389/2018 EU (“RTS”). Hence, when AISPs rely on these personalized security credentials for authentication in line with Article 97 (5) PSD2, the identity of the account holder is being established with the same degree of certainty that applies for ASPSPs. Accordingly, there is no need for additional checks by AISPs, which cannot produce additional security or transparency.
2. AML related requirements will dissuade customer take-up of AIS and provide limited value at high cost
AISPs are required to gain the customer’s, i.e. the end-user’s, explicit consent to access a customers payment accounts in order to provide account information services. , AISPs must clearly inform the customer of what data they are accessing and for what purpose. If AISPs were subject to AML measures, this subjects AISPs to disclose to the end-customer that they will be using their data to fulfill the additional transaction monitoring for anti-money laundering and counter terrorism financing.
3. Data collection for the purposes of AML is incompatible with PSD2
PSD2 Article 67(2)(f) states that AISPs “must not use, access or store any data for purposes other than for performing the account information service explicitly requested by the payment service user, in accordance with data protection rules.”
The EBA Guidelines appear asking AISPs to “ensure that their AML/CFT systems are set up in a way that alerts them to unusual or suspicious transactional activity.”
This is effectively asking AISPs to serve a separate purpose - to be watchdogs for illegal money flows through the banks - is disproportionate, contrary to existing law, and was never initially outlined as an objective of PSD2. Under PSD2 and GDPR (data minimization), these companies must only use data strictly to provide the services customers request.
To require AISPs to do transaction monitoring would, as noted above, require explicit customer consent as well as disclosure as to the purpose of additional transaction monitoring. It could imply that AISPs would also need to build brand new systems to process their customers’ transaction data and detect suspicious transactions.
If AISPs were required to monitor all transactions on the customer account this would be equivalent to asking AISPs to police the entire banking ecosystem. For customers with multiple bank accounts, this means an AISP is therefore burdened with monitoring the transactions across all the accounts and banks to which they are connected. This is beyond the scope of PSD2, and beyond the service an AISP provides. It is also redundant, considering that the transactions should be verified as regards their AML compliance by the entities that actually perform the transactions, namely, ASPSPs. It is burdensome, and counter to PDS2 both from a role and responsibility perspective, as well as stifling the ability for customers to access innovative services. It is also an additional cost layer, which performs a redundant purpose, as all transactions on the accounts are already being monitored by the banks’ that perform the transactions in question.
Furthermore, because AISPs are required to re-authenticate the customer’s consent every ninety (90) days under current rules, via SCA, most AISPs only have 90 days’ worth of transactional data on which to perform a deeper level of transaction monitoring. This limited data set stymies the ability to perform robust fraud recognition.
AISPs are unlikely to identify fraudulent activity in relation to their read-only access to the data, because their checks could not run in real time, but only after the transaction has been fulfilled (before that, it is not visible for the AISP, who is only at the receiving end after the transaction has been executed). AISPs therefore cannot provide any notification before a transaction order has been completed. They could discover suspicious activity only after the fact. The AML checks in the real time should be run by ASPSPs who actually carry out the transactions. The double-check of the same transaction would contradict the principle of avoidance of repeated customer identification procedures (Recital 35 AML Directive) and it would lead to delays and inefficiency.
This would be a belated duplication of the work already being done by the banks, in vain and at an additional cost. There is a real risk of an increase in the number of false positives, as an AISP could only send out a suspicious activity notification. Considering the limitations of no real-time analysis, as well as an increase in false positives, these notifications would serve no purpose but still increase the costs of investigation and reconciliation.
Bank-owned AISPs would simply refer to the checks of the bank, avoiding the redundancies, while non-bank AIPS would have to add an additional layer of redundant and belated checks, reducing their attractiveness and competitiveness. For these reasons, requiring AISPs to perform transaction monitoring for suspicious AML/CTF activity is redundant and costly and has a negative impact on the number of competitive AISP actors in the market.
4. AISP Authorization Requirements do not include AML/CTF Controls
We believe it was the original intention for AISPs to be carved out of these obligations. Article 33 (1) PSD2 specifically exempts AISPs from Article 5 (1) lit (k) PSD2, i.e. as part of their license application, AISPs do not have to submit a description of their AML control mechanisms. By explicitly exempting AISPs from having to detail AML/CTF controls from the AISP authorization requirements, it is clear that no such obligations were intended to apply to AISPs.
To continue to require AISPs to perform AML/CTF checks is in conflict with Article 33 (1) PSD2. The ETPPA concludes that no such obligations were intended to apply to AISPs: Where internal AML/CTF control mechanisms are not required as part of the AISP application process, no obligation exists. In the legislative process, this exemption was created specifically to reflect the fact that AISPs do not control or influence the flow of funds, or engage in any financial activity, and therefore should not be subject to AML rules.
This can be construed as a specification to Article 2 (3) AML-Directive, which foresees the exemption of “financial activities” with a very limited or only occasional scope. In case of AISP, there is no financial activity at all, so they should be exempted a fortiori. Article 33 (1) PSD2 could thus be understood as lex specialis to Article 2 (3) AML-Directive, foreseeing a statutory exemption under EU law.
5. Disproportionate
PSD2/Open Banking was introduced to increase innovation and competition – providing consumers with more choice and options. Any application of AML requirements to AISPs is counterproductive to the purpose of this regime. Some AISPs will not be able to continue to operate with the compliance overhead of AML requirements, and others simply won’t get off the ground due to the additional cost layers resulting from both the AML/CTF checks as well as the heavier touch transaction monitoring obligations. This will make it incredibly difficult for small businesses and consumers to effectively and efficiently access and use new and disruptive AIS.
As a specific example, implementing identification and verification checks into the sign-up flows of AISPs will have a negative impact on customer adoption of new products and services affecting the future viability and success of these businesses, and ultimately of the open banking regime. And this needs to be contrasted with bank-owned AISPs that may rely on the AML checks already performed by their bank. Accordingly, bank-owned AISPs would gain a competitive advantage, despite the fact that non-bank AISPs perform the same SCA authentication, resulting in the same certainty about the identity of the PSU.
Articles 25 et seq AML-Directive provide for the performance of identity checks by third parties, and bank-owned AIPS rely on this. The same should be the case for non-bank AISPs, independent of whether they have a contract with the ASPSP:
First, Art. 67 (4) PSD2 says “the provision of AIS shall not be dependent on the existence of a contractual relationship between the ASPSP and the AISP for that purpose”.
And second, because of Article 97 (5) PSD2, the ASPSP has already the statutory duty to allow the AISP to rely on his security credentials and the authentication procedures for the SCA. Accordingly, with that statutory duty, no additional contractual arrangement is necessary, and ASPSP would be obliged to provide all information required under Article 27 AML-Directive. As a result, no second 8and redundant) identification is required with the first identification already being fully accessible.
The result is that for any use of AIS, the identification has already been done and can be authenticated via SCA – hence no need for additional checks burdened upon the AISP. See for that purpose Recital 35 AML-Directive: “In order to avoid repeated customer identification procedures, leading to delays and inefficiency in business, it is appropriate, subject to suitable safeguards, to allow customers whose identification has been carried out elsewhere to be introduced to the obliged entities.”
6. Onerous and redundant
In the interest of reducing the overall burden of regulation on participants, we believe that a number of the requirements of AML regulations are already satisfied prior to an AISP consuming transaction data from a financial institution. For example, banks will have already conducted customer due diligence measures on account holders using AISP services, meaning that further checks are ‘doubling up’.
In nearly all cases the bank is best placed to undertake the appropriate checks and monitor transactions for suspicious behavior. Requiring an AISP to perform the same measure the bank has already taken is redundant and would serve no purpose other than burdening AISPs with unnecessary overhead costs and compliance.
One of the objectives of the AML-Directive is to balance the objective of protecting society from crime against the need to create a regulatory environment that allows companies to grow their businesses without incurring disproportionate compliance costs. Any onerous and redundant double-up compliance on an AISP would be counter to the objectives of the AML-Directive, and would also negatively impact competition and customer choice and convenience.
To avoid the double-up compliance and to prevent “delays and inefficiency in business” (Recital 35 AML-Directive), the obliged entities are allowed to rely on CDD performed by third parties. It is therefore our understanding that also AISPs are allowed to rely on ML/TF checks performed by the banks and, based on Article 27 AML Directive, they are entitled to obtain from the banks the necessary information concerning the compliance with customer due diligence requirements. AISPs should not be required to perform repeated compliance checks, as they are ill-equipped to perform a comprehensive and reliable AML control, especially considering their limited access to customers’ data and the non-transactional nature of their services.
7. Risk Self-Assessment
While the AML-Directive requires Member states to ensure application of the CDD requirements from the Directive, it also leaves a room for obliged entities to “determine the extent of such measures on a risk-sensitive basis” (Article 13 para. 2 AML Directive). Also EBA in the Guidelines (18.9-18.10) confirms that AISPs (and PISPs) should identify and assess the ML/TF risks and determine an adequate extent of CDD measures.
While performing the risk self-assessment, obliged entities must take into account a number of variables, as laid out in Annex I AML-Directive. Based on Annex I, AIS pose low (if any) AML risk:
The purpose of an account / relationship (Annex I (i) AML-Directive) is non-transactional and not related to holding customers’ funds
The level of assets to be deposited or the size of transaction (Annex I (ii) AML-Directive) cannot be assessed, as AIS do not include any transaction.
Against this background, the regularity or duration of the business relationship ((Annex I (iii) AML-Directive) of AISPs with their customers would be irrelevant.
Hence, if AISPs were to perform a risk self-assessment, they would most likely come to the conclusion that their AIS pose no ML/TF risk and only limited (if any) CDD measures are required.
8. Unintended consequences
We understand from the European Commission that the unqualified inclusion of AIS activities in Article 113 PSD2, and the application of AML requirements, may have been probably a drafting inaccuracy, caused by the blanket use of references in PSD1 (which did not have the concept of account information services in its definition of ‘payment services’) as references also for PSD2. This construct triggered automatic implications for the definition of ‘payment services’ in the list of activities subject to mutual recognition in Annex I to Directive 2013/36/EU and, as a result, for the definition of ‘financial institution’ in the AML-Directive. The unintended consequences of this are now showing and need to be avoided.
9. Conclusion regarding AISP AML Requirements
Data is neutral and therefore holding the data is not indicative of facilitating money laundering, nor is the act of sharing that data, subject to customer consent, a means to prevent money laundering. An AISP simply consolidates and makes that data available for sharing; therefore there is no risk of an AISP facilitating money laundering. AISPs do not monitor transactions unless requested by their customers.
PSD2 foresees that AISPs should have a limited role as a conduit, with minimal processing of data (principle of necessity). To fulfill AML/CTF compliance on transaction monitoring would be in direct violation with this PSD2 “light touch” requirement. The additional expense and burden on AISPs to comply runs counter to promoting competition, contradicting the desired outcomes of PSD2.
AISP authorization requirements do not include AML/CTF controls, and it is clear that no such obligations were intended to apply to AISPS. Continued AML/CTF control obligations are both harmful to competition, as well as burdensome and redundant. Moreover, other “financial activities” with a higher risk of money laundering have been exempted from AML/CTF requirements, see for example Article 2 (3) AML-Directive or Article, and Article 12 AML-Directive on electronic money, whilst AISP are not engaging in any financial activities, in the first place.
It is for these reasons that ETPPA strongly believes that AISPs should be removed from the scope of AML requirements. AML requirements for AISPs would not serve the purpose for which they were intended, and be disproportionate to the risk (there is none) of any money laundering or terrorist financing occurring through AISP platforms, as well as burdensome and redundant.
B. ETPPA Concerns on impact of AML application to Payment Initiation Service Providers (PISP) businesses
The PSD2 regulated activity of ‘payment initiation services’ has been designed specifically to protect innovative PISPs in their market access and ability to compete with incumbent payment providers such as banks and card schemes. Many of the arguments for removing AML obligations from AISPs apply equally to PISPs.
More specifically, the AML-Directive does not provide a legal basis for subjecting PISPs to the obligation of performing a CDD on each payment initiation. The AML Directive foresees in Article 11 CDD only for some cases, chiefly when (a) establishing a business relationship or (b) when carrying out an occasional transaction (above a certain threshold). The typical PIS business model does not fulfill these provisions, as PISPs do not have a “business relationship” with the account-holders (PSUs) in the sense of Article 11 lit a AML-Directive, and they do not “carry out” any transactions in the sense of Article 11 lit b AML-Directive.
EBA itself highlights that “PISPs, although being involved in the payment chain do not execute themselves the payment transactions and do not hold payment service user’s (PSU) funds” (Point 18.2 of the proposed Guidelines). Consequently, the only remaining basis for the CDD for PISPs is Article 11 (e) AML Directive, which requires CDD “when there is a suspicion of money laundering or terrorist financing, regardless of any derogation, exemption or threshold”. This would mean that PISPs would not have to perform CDD on a regular basis for all payment initiations, but only exceptionally to those payment initiation operations that raise suspicion of ML/TF.
And to the extent PISPs are being subject to CDD obligations, the following key considerations apply:
2. Duplicate and redundant PISPs customer due diligence on each end-customer.
CDDs on the account-owners would involve requesting name and address from each customer, storing these details, and using a paid-for electronic ID verification system. This would make it de facto impossible for PISPs to provide services. An end-user uses a PIS on an ad-hoc basis, when interacting with and paying a merchant. In those instances, PIS will be one of several payment methods in the merchant’s “check-out” section. The end-user will want to pay in a quick and safe way. Inserting a CDD-process (i.e., halting the customer and asking for a copy of their passport) as part of the payment flow will, compared to other payment methods, make it a relatively speaking unacceptably onerous procedure to pay , which will mean many end-users, having initially chosen to pay with PIS, will drop out of the process and not complete the payment. This from a merchant perspective could mean unacceptably low conversion for PIS as a payment method.
It is actually one of the key PISP characteristics that customers do not have to open an additional account and do not have a balance with the PISP, but use their existing bank account for paying online. This also allows customers to easily use different PISPs with different merchants depending on the available check-out options, which is a crucial requirement to allow for competition in the provision-of-PIS-market.
Most importantly, for every payment initiation there is already the ASPSP performing CDD on the account owner as per Art. 11 AML-Directive. The PISPs relies on that identification via the dynamic SCA that the ASPSP has to perform for any transaction according to Article 97 (2) PSD2. Accordingly, there is already a complete, secure and consistent identification and authentication for every transaction already in place, making any additional checks on the account owner redundant and pointless.
3. Requiring additional due diligence for each end customer is inconsistent with PSD2.
According to Article 66 (3) lit g PSD2, a PISP should not use, access or store any data for purposes other than for the provision of PIS. This stands in contrast to additional AML checks on the identity of the account owner.
If AML obligations vis-a-vis the end-user were imposed on PISPs, then the PISP would have to access these data related to the identity of the payer as held by the ASPSP. This would either have to be accessible via the customer-facing interfaces (or fallback), or be provided by the ASPSP in its TPP-facing “dedicated” interface. In other words, if the PISP needed more identification data on the account owner, his only available source would be the account-servicing bank that has this information and would have to provide it to the PISP. This would be redundant, as the ASPSPs has already performed these checks when opening the account and issuing the personalized security credentials in the sense of Article 97 PSD2, and the PSU authenticates himself on that basis via SCA according to Article 97 (2) PSD2 – so the same information would be gathered twice with no additional gain or insight.
4. Unlevelled playing field between PISPs and card processors/ schemes
In a merchant context, an account-owner (i.e. the end-customer of the products) has a 'one-off' interaction with the PISP, in the same way as a customer paying by card has a 'one-off' interaction with whichever card-acquirer happens to be serving the merchant (not the account-owner). As explained above, imposing AML obligations vis-a-vis the end-user would put PISPs at an unlevelled playing field with the card payment services they are competing with, thereby frustrating the PDS2 mandate to increase competition.
It is also duplicative and redundant (as the customer already performs SCA with his bank to confirm his payment) and would due to the deterioration of conversion rate render PIS as a merchant-facing payment method worthless. Card processors do not perform AML on payment service users at the check-out. However, unlike PISPs, Card processors can be in possession of a payment service user’s authentication data (card details including PAN/CVV/PIN). PISPs rely on authentication procedures set by the bank during the payment flow, Article 97 (5) PSd2, so are inherently at a far lower risk of being used to commit fraud.
5. Obliging PISPs to conduct AML checks on end customers is a significant barrier to providing payment initiation services.
These requirements undermine the very principle of “fair competition among all payment service providers” postulated in PDS2, Article 98 (2) lit c: PISPs are subject to stricter requirements in comparison to card processors who have a similar business model. Not only will it not “allow for the development of a user-friendly, accessible, and innovative means of payment”, Article 98 (2) lit e PSD2, it will not “ensure technology and business-model neutrality”, Article 98 (2) lit d PSD2, both of which are PSD2 requisites. It goes further to damage competition, as it will cause payment service user dissatisfaction and lead to increased abandonment during the payment process.
6. Disproportionate and burdensome
Moreover, unlike other payment service providers (banks, money remitters, e-money institutions), who come into possession of funds during the provision of their services, pure PISPs are not part of the flow of funds (according to Article 66 (3) lit a PSD2, PISPs are not allowed to hold the payer’s funds). A pure PISP does not execute the payment, but simply offers software by which the payment order is transmitted by the PSU to his bank. The funds move directly from the customer’s bank to the payee's bank. As PSD2 states in Recital 31: “When exclusively providing payment initiation services, the payment initiation service provider does not at any stage of the payment chain hold the user’s funds”.
Hence, as a minimum, the scope of AML checks should be limited to the customer of the PISPs, namely the online-merchant and payee. This is the approach taken by authorities so far, which is consistent with the objectives of the AML-Directive. First, because it refers to the “business relationship” of PISPs in the sense of Article 11 lit a AML-Directive. And second, this may actually add to the overall security of the system, because PISPs could help to prevent AML risks on the side of the merchant via their business relationship. Ensuring that PISPs take appropriate measures to verify who the beneficiaries of end-users payments are and for what purposes the merchant is obtaining the PISP’s service will likely fulfill the objectives of the AML-Directive, better than conducting redundant CDD on the end-users (which have already been performed by the ASPSPs). This is what is currently already taking place in practice, and there have been no complaints about this approach.
PISPs cannot be obliged to perform CDD on both, their customers (the payees) as well as the account-owners (the payers), at the same time. For that reason, we believe that PISPs should only be obliged to perform CDD on their customers, which is the online-merchant (payee). This approach has been proven to be effective and efficient in practice and it is in line with the wording and purpose of the AML-Directive (and PSD2). Contrarily, imposing on PISPs conducting CDD on account-owners would be impractical and pointless as well as against the AML rules.
7. Conclusions regarding AML requirements for PIS Providers
It is for these reasons that the ETPPA strongly believes that PISPs are not subject to AML requirements regarding the account holders. Such AML requirements would not serve the purpose for which they were intended and be disproportionate to the risk (there is none) of any money laundering or terrorist financing occurring through PISPs’ platforms, as well as burdensome and redundant.
C. Overall conclusions
We therefore object to the draft EBA Guidelines and plead to exclude AISP and PISP from their scope, to enable a further discussion of the matter.
In any event, the proposed Guidelines would have to be adapted as set out below, in Section II.
II. Specific comments on EBA Guidance for PISPs under AML in the Point 18 of the proposed Guidelines
If the EBA were to include the AML requirements for AIS and PIS providers in Point 18 of the Guidelines, ETPPA would like to emphasize the following points that should be taken into consideration:
The sector-specific Guidelines for AISPs and PISPs should remain risk and principle based and as a minimum do not exclude certain business models by making statements that rule out any market practice. The market for AIS and PIS services in particular is still in an early stage of development and many business models may yet arise to address a particular market need.
Comments on Draft Guideline 18.2
Despite our fundamental concerns (see Section I, above), the ETPPA nevertheless welcomes the wording of Section 18.2 which states that
“the inherent ML/TF risk associated with PISP and AISP is limited due to the fact that :
a) PISPs, although being involved in the payment chain do not execute themselves the payment transactions and do not hold payment service user’s (PSU) funds;
b) AISPs are not involved in the payment chain and do not hold payment service user’s funds.”
Comments on Draft Guideline 18.8
Guideline 18.8 (a) is incorrect: PISPs do not have a contractual relationship with the account holders (payment service users); PISP “customers” are the online-merchants
The proposed guideline 18.8 is wrong to state that the “customer”, for whom Customer Due Diligence (CDD) should be performed, was the account holder.
The customer of PISPs is the online-merchant. The PISP does not have a contractual relationship with the account holder. PISPs, as a rule, have a software service contract with the online-merchant, who integrates the PIS software as a payment option (or payment alternative) into his online-shop, offering account owners to rely on that software in order to initiate a payment with their bank and to provide proof of this successful initiation to the online-merchant, see Recital 27 PSD2:
“In particular, payment initiation services in the field of e-commerce have evolved. Those payment services play a part in e-commerce payments by establishing a software bridge between the website of the merchant and the online banking platform of the payer’s account servicing payment service provider in order to initiate internet payments on the basis of a credit transfer.”
The online-merchants pay a fee for the possibility to rely on the PIS software, offering its use to their customers. Account-owners also do not pay any fees to the PISP, and they offset the costs of the online-merchant via their purchasing prices paid to the latter. There may be a software using contract between the online-merchant and the PSU, but there is no payment-related contract or business relationship between the PISP and the PSU.
Accordingly, the account owner is not the “customer” of the PISP in the sense of AML. The PISP does not establish a “business relationship” with the account owner in the sense of Art. 11 (a) AML-Directive. CDD, therefore, cannot refer to the account owner.
This has been confirmed by the ESAs in charge of licensing PISPs: While PISPs need to provide a documentation of their internal AML control mechanisms under Art. 5 (1) lit k PSD2, this has not referred to the identification of account-owners, but to the identification and CDD of online-merchants.
This point makes a very important difference in practice: Account owners are currently able to rely on PIS software without any prior identification to the PISP. They can use the software “ad-hoc”, without prior registration. This is a core feature of PISPs, and would be entirely disabled if CDD would be applied to account owners (to whom PISPs have no direct access). So far, this has not been the case – and there is no legal basis for it in the AML-Directive.
If AML requirements were to be applied to PISPs, they should be limited to what is strictly necessary and avoid any duplicate AML requirements that are already conducted by the ASPSP. They need to take into account who is the “customer” of the PISPs, which normally is the merchant (i.e. the payee), rather than the end user (i.e. the payer). As set out above, this approach is consistent with the objectives of the AML-Directive. Ensuring that PISPs take appropriate measures to verify who the beneficiaries of end-user payments are and for what purposes the merchant is obtaining the PISP’s service is likely to better fulfill the objectives of the AML-Directive, than PISPs conducting redundant and pointless CDD on end-users (which have already been performed by the ASPSPs running their accounts and providing for the SCA in line with Article 97 (2) PSD2).
To ensure business neutrality, the guidelines should distinguish between the different business models where AML requirements for PISPs would be limited to the merchant provided that:
a) the merchant is the PISP customer based on a contractual relationship between the PISP and the merchant,
b) the end-user is not the PISP’s customer, but the customer of the bank
c) the PISP simply provides a software tool, which the online-merchant then offers to his contractual partner, the payer (account owner), who may use it instead of other ways to pay
d) under the general AML obligations the PISP may, where possible, undertake monitoring to spot suspicious patterns of transactions and report these as necessary.
Only the merchant would be, in that typical and normal business model, the customer of the PISP with whom it has a contractual relationship that “has an element of duration” in the sense of Article 3 (13) AML-Directive. The merchant (payee) is the “customer” subject to CDD, not the payer. The PISP would then still perform transaction monitoring on all flows based on its general AML obligations, but he would not perform CDD on the account owner. The Guidelines should therefore state that
For PISPs: The customer is the online-merchant (the payee) that is offering the PIS software as a payment alternative, e.g. on his website or in his online-shop;
Only in exceptional cases, where the PISP has a direct and enduring contractual relationship with the account holder (the payer) in the sense of Article 3 (13) of the AML-Directive, the latter may be regarded as the “customer” of the PISP.]
Comments on draft Guideline 18.10 and 18.15
Simplified Customer Due Diligence
To the extent that TPPs are obliged to realize a CDD, ETPPA agrees with the fact that due to the limited risk of their activities, the simplified customer due diligence (CDD) should be the norm. As written in Point 18.10 “In most cases, the low level of inherent risk associated with these business models means that SDD (simplified due diligence) will be the norm”.
Point 18.15 of the proposed Guidelines helpfully develops this idea, apparently based on the principle of the risk self-assessment enshrined in Article 13 (2) of the AML-Directive (see above Section I.A.7). We welcome these clarifications, which refer to the way that the TPP (here: the AISP) may identify the account-owner under a lighter SDD-regime, namely:
“a) Relying on the source of funds as evidence of the customer’s identity where the payment account details of the customer are known, and the payment account is held at an EEA-regulated payment service provider;
b) Postponing the verification of the customer’s identity to a certain later date after the establishment of the relationship. In that case, firms should ensure that their policies and procedures set out at what point CDD should be applied;
c) Assuming the nature and purpose of the business relationship;”
Point (a) seems to refer to the fact that the ASPSP has already conducted the CDD for the opening of the account as well as for the issuing of the personalized details for the SCA, see Article 24 RTS, Article 97 PSD2. Hence, the information required is already available at the ASPSP, whilst the account owner authenticated himself towards the bank (and towards the AISP, Article 97 (5) PSD2). SDD would then consist in the fact that ASPSPs share the identity with the ASPSP via the PSD2- compliant interfaces, i.e. the consumer-facing interfaces (or fallback), or the dedicated interfaces, or both (see Article 31 RTS for the choice that is available). As pointed out above, the performance of the SDD via a the ASPSP is in line with Article 25 AML-Directive, and the ASPSP should be obliged to divulge the required data to the AISP according to Article 27(1) AML-Directive, in line with Article 67 (3) PSD2, Article 38 (1) lit a RTS (“the same information from designated payment accounts and associated payment transactions made available to the payment service user when directly requesting access to the account information”).
There is indeed already a legal obligation on ASPSPs to divulge all available data to AISPs, also on the identity of the account holder, if that is required for their services. And Article 27 (1) AML-Directive recognizes this as a reliable and sufficient source for AML purposes.
Point (b) seems to refer to Article 14 (2) AML-Directive, which allows the initiation of the services before CDD. This allows the AISP to start his service first and access the account information during the initiation, which then would allow him, according to the rules set out above, to derive and confirm the required information directly from the account itself, i.e. without a separate or additional identification procedure. This avoids a duplicate identification, and enables to rely on the SCA in line with Article 97 PSD2 as is currently the case.
Point (c) seems to refer to Article 13 (3) AML-Directive, allowing AISPs to make reasonable assumptions on the nature and purpose of the business, in consideration of the very low (or non-existing) risk involved with AISP, effectively reducing the SDD for AISP to obtaining the name of the account-holder.
However, since PISPs do not have to conduct CDD/SDD on the account owner altogether (see above), these considerations refer to AISPs in particular, not PISPs. And considering the very low risk of AIS, the EBA should clarify the consequences of the above, namely the fact that AISPs will as a rule not be required to conduct any additional SDD apart from obtaining the name of the account holder form his account (a). This could be clarified as follows:
“On that basis, considering the fact that they pose no significant ML/TF risk, AISP would normally not conduct their own separate identification of the account-holder. Instead, they may rely on the Strong Customer Authentication to be performed in line with Article 97 PSD2, and limit the identification of their customers to obtaining his name, which ASPSPs are legally obliged to provide via their PSD2-compliant interfaces in line with Article 36 RTS 389/2018”.
The same would apply to PISPs where they are, in exceptional cases, subject to SDD of the account-owner (instead of the merchant).
***