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
The OBIE is fully supportive of measures taken by the EBA to ensure that firms remove obstacles to the provision of account information and payment initiation services. Our Customer Experience Guidelines (CEG) are an example of how we have built on the work of the EBA in reducing unnecessary friction in open banking customer journeys. We are concerned that certain provisions of the proposed AML guidelines could have the effect of increasing friction unnecessarily, and therefore potentially reduce customer adoption of open banking and PSD2-enabled products and services.
OBIE recognises the importance of having mechanisms in place that enable detection and prevention of money laundering and terrorist financing. Having considered the EBA draft guidelines on money laundering and terrorist financing risk factors, and more specifically the obligations on TPPs, we would like to raise the following key points:
TPPs and the customer relationship:
Whilst draft Guideline 18 appears to distinguish only between Account Information Services Providers (AISPs) and Payment Initiation Services Providers (PISPs), the reality is more nuanced than that. There are various PISP business models, with a number focused specifically on e-commerce transactions. In the e-commerce model, there are three distinct interactions, firstly between the merchant and the PISP, secondly, between the merchant and the customer (i.e. Payment Service User or PSU), and lastly, between the PISP and the PSU. It is our understanding that in these circumstances the PISP would have conducted appropriate due diligence when entering into an ongoing business relationship with the merchant as it is the merchant who is the primary customer of the PISP. When interacting with the PSU, it is anticipated that the PISP will often operate under a single payment service contract in order to facilitate an efficient payment initiation service, with minimum PSU engagement. This does not create an ongoing relationship between the PISP and the PSU. The PISP will also not hold the PSU’s funds and there will be no ongoing information or statementing obligations between the PSU and PISP. This is the case even where payment initiation services are in fact regularly used by a PSU, as PISPs will not usually expect the contract to have any element of duration. In such cases, each payment initiation is independent and self-contained, and PISPs cannot predict whether a further payment initiation service, involving the same or a different merchant, will ever be required by that PSU.
Additionally, whilst PISPs may be involved in transfers of more than €1000, that involvement does not mean that PISPs will be the firm actually ‘carrying out’ the transfer of funds. While PISPs will provide connectivity between a PSU and ASPSPs for the purposes of initiating a payment, the transfer of funds itself is carried out by the ASPSP.
It is therefore generally the position that e-commerce PISPs do not enter a business relationship with PSUs and do not carry out occasional transactions on their behalf. As such, neither head a) or b) of Article 11 of the ALMD applies and these PISPs should not be required to conduct due diligence on PSUs. In any event, due to the instant nature of most PISP/PSU relationships, the opportunity to perform even simplified due diligence (SDD) may be practically challenging in an e-commerce scenario. In order to effectively carry out SDD, the PISP may be required to introduce new steps within their customer journey to gather information, which could result in significant, additional friction and potential journey abandonment, defeating the aim of PSD2 to promote innovation and competition in the payments sector. We are concerned that a blanket application of SDD for all PISP payments could impact the uptake on PISP services and we would be interested to see a more tailored and proportionate approach to the application of these guidelines to PISP services.
It would be helpful if the guidelines differentiated between the different business model types in order to determine whether the individual guidelines and the overarching KYC requirements can be practically applied, recognising instances where it would be impractical to do so. When considering the nature of PISP payments, we would expect that the ASPSP of the PSU (the payer) would also be performing similar KYC checks and it would be useful to understand what additional expectations are required from the PISP and their utility from a MLTF perspective.
Transaction monitoring:
The draft Guidelines identify specific instances when TPPs would need to analyse particular transactions by considering factors such as payment amounts and geographic location.
For PISPs, due to the nature of their interaction with the PSU, as described above, this may be particularly challenging. Once a PISP submits a payment order to the ASPSP on behalf of the PSU, the relationship effectively comes to an end. Requiring the PISP to monitor the PSU sending different amounts from different bank accounts, as contemplated in guideline 18.4 (a), may prove to be difficult or impossible for most PISPs operating under a single payment service contract. Similar challenges may arise in the context of AISP services. Whilst an AISP will have access to account information from a variety of PSU payment accounts, the level of scrutiny anticipated in the guidelines may be difficult for a number of reasons. Firstly, different AISPs will require different types and quantity of data to support their service offerings. The level of detail of the account information they receive will also impact the type of transaction monitoring they could apply. For AISPs offering a balance-only aggregation service, it may not be feasible to perform transaction monitoring at all. AISPs that require a richer data set for their service may still find it challenging to perform transaction monitoring due to regulatory constraints to their service. For example, the requirement for 90 day re-authentication, or the possible revocation of consent by the PSU, may hamper their ability to get up-to-date transactional data. This activity may also result in significant additional costs for AISPs in order to implement the appropriate technology to monitor transactions effectively. This is also unnecessary since transaction monitoring will take place in the domain of the ASPSP. Whilst some AISPs may have access to rich data sets this will only be the case for as long as a PSU provides their consent. Furthermore, the ability of any AISPs to access and view transactions can be limited by the PSU at any time. ASPSPs, however, will have uninhibited access to transaction data for as long as accounts remain open. Given this mismatch of access rights and the obligations incumbent on ASPSPs to monitor transactions, a blanket requirement on AISPs to undertake transaction monitoring should be reconsidered.
OBIE would welcome a more tailored approach which considers the issues we have raised. While TPPs are obliged entities under the AMLD5, we would expect that their obligations are proportionate and aligned to their service offering, the level of information they are able to obtain, and the practical requirements of meeting the necessary obligations.
We would welcome the opportunity to discuss these points with you. Please contact Alan Ainsworth (alan.ainsworth@openbanking.org.uk) if you would like to do so.
Question 1: Do you have any comments with the proposed changes to the Definitions section of the Guidelines?
n/aQuestion 2: Do you have any comments on the proposed amendments to Guideline 1 on risk assessment?
n/aQuestion 3: Do you have any comments on the proposed amendments to Guideline 2 on identifying ML/TF risk factors?
n/aQuestion 4: Do you have any comments on the proposed amendments and additions in Guideline 4 on CCD measures to be applied by all firms?
n/aQuestion 5: Do you have any comments on the amendments to Guideline 5 on record keeping?
n/aQuestion 6: Do you have any comments on Guideline 6 on training?
n/aQuestion 7: Do you have any comments on the amendments to Guideline 7 on reviewing effectiveness?
n/aQuestion 8: Do you have any comments on the proposed amendments to Guideline 8 for correspondent banks?
n/aQuestion 9: Do you have any comments on the proposed amendments to Guideline 9 for retail banks?
n/aQuestion 10: Do you have any comments on the proposed amendments to Guideline 10 for electronic money issuers?
n/aQuestion 11: Do you have any comments on the proposed amendments to Guideline 11 for money remitters?
n/aQuestion 12: Do you have any comments on the proposed amendments to Guideline 12 for wealth management?
n/aQuestion 13: Do you have any comments on the proposed amendments to Guideline 13 for trade finance providers?
n/aQuestion 14: Do you have any comments on the proposed amendments to Guideline 14 for life insurance undertakings?
n/aQuestion 15: Do you have any comments on the proposed amendments to Guideline 15 for investment firms?
n/aQuestion 16: Do you have any comments on the proposed amendments to Guideline 16 for providers of investment funds and the definition of customer in this Guideline?
n/aQuestion 17: Do you have any comments on the additional sector-specific Guideline 17 on crowdfunding platforms?
n/aQuestion 18: Do you have any comments on the additional sector-specific Guideline 18 on account information and payment initiation service providers?
The Open Banking Implementation Entity (OBIE) is a body which creates open API standards that enable firms throughout Europe to meet their PSD2 regulatory requirements for the provision of open banking services. We are therefore well-placed to understand the impact on both Account Servicing Payment Service Providers (ASPSPs) and Third Party Providers (TPPs) of new regulatory requirements and guidance.The OBIE is fully supportive of measures taken by the EBA to ensure that firms remove obstacles to the provision of account information and payment initiation services. Our Customer Experience Guidelines (CEG) are an example of how we have built on the work of the EBA in reducing unnecessary friction in open banking customer journeys. We are concerned that certain provisions of the proposed AML guidelines could have the effect of increasing friction unnecessarily, and therefore potentially reduce customer adoption of open banking and PSD2-enabled products and services.
OBIE recognises the importance of having mechanisms in place that enable detection and prevention of money laundering and terrorist financing. Having considered the EBA draft guidelines on money laundering and terrorist financing risk factors, and more specifically the obligations on TPPs, we would like to raise the following key points:
TPPs and the customer relationship:
Whilst draft Guideline 18 appears to distinguish only between Account Information Services Providers (AISPs) and Payment Initiation Services Providers (PISPs), the reality is more nuanced than that. There are various PISP business models, with a number focused specifically on e-commerce transactions. In the e-commerce model, there are three distinct interactions, firstly between the merchant and the PISP, secondly, between the merchant and the customer (i.e. Payment Service User or PSU), and lastly, between the PISP and the PSU. It is our understanding that in these circumstances the PISP would have conducted appropriate due diligence when entering into an ongoing business relationship with the merchant as it is the merchant who is the primary customer of the PISP. When interacting with the PSU, it is anticipated that the PISP will often operate under a single payment service contract in order to facilitate an efficient payment initiation service, with minimum PSU engagement. This does not create an ongoing relationship between the PISP and the PSU. The PISP will also not hold the PSU’s funds and there will be no ongoing information or statementing obligations between the PSU and PISP. This is the case even where payment initiation services are in fact regularly used by a PSU, as PISPs will not usually expect the contract to have any element of duration. In such cases, each payment initiation is independent and self-contained, and PISPs cannot predict whether a further payment initiation service, involving the same or a different merchant, will ever be required by that PSU.
Additionally, whilst PISPs may be involved in transfers of more than €1000, that involvement does not mean that PISPs will be the firm actually ‘carrying out’ the transfer of funds. While PISPs will provide connectivity between a PSU and ASPSPs for the purposes of initiating a payment, the transfer of funds itself is carried out by the ASPSP.
It is therefore generally the position that e-commerce PISPs do not enter a business relationship with PSUs and do not carry out occasional transactions on their behalf. As such, neither head a) or b) of Article 11 of the ALMD applies and these PISPs should not be required to conduct due diligence on PSUs. In any event, due to the instant nature of most PISP/PSU relationships, the opportunity to perform even simplified due diligence (SDD) may be practically challenging in an e-commerce scenario. In order to effectively carry out SDD, the PISP may be required to introduce new steps within their customer journey to gather information, which could result in significant, additional friction and potential journey abandonment, defeating the aim of PSD2 to promote innovation and competition in the payments sector. We are concerned that a blanket application of SDD for all PISP payments could impact the uptake on PISP services and we would be interested to see a more tailored and proportionate approach to the application of these guidelines to PISP services.
It would be helpful if the guidelines differentiated between the different business model types in order to determine whether the individual guidelines and the overarching KYC requirements can be practically applied, recognising instances where it would be impractical to do so. When considering the nature of PISP payments, we would expect that the ASPSP of the PSU (the payer) would also be performing similar KYC checks and it would be useful to understand what additional expectations are required from the PISP and their utility from a MLTF perspective.
Transaction monitoring:
The draft Guidelines identify specific instances when TPPs would need to analyse particular transactions by considering factors such as payment amounts and geographic location.
For PISPs, due to the nature of their interaction with the PSU, as described above, this may be particularly challenging. Once a PISP submits a payment order to the ASPSP on behalf of the PSU, the relationship effectively comes to an end. Requiring the PISP to monitor the PSU sending different amounts from different bank accounts, as contemplated in guideline 18.4 (a), may prove to be difficult or impossible for most PISPs operating under a single payment service contract. Similar challenges may arise in the context of AISP services. Whilst an AISP will have access to account information from a variety of PSU payment accounts, the level of scrutiny anticipated in the guidelines may be difficult for a number of reasons. Firstly, different AISPs will require different types and quantity of data to support their service offerings. The level of detail of the account information they receive will also impact the type of transaction monitoring they could apply. For AISPs offering a balance-only aggregation service, it may not be feasible to perform transaction monitoring at all. AISPs that require a richer data set for their service may still find it challenging to perform transaction monitoring due to regulatory constraints to their service. For example, the requirement for 90 day re-authentication, or the possible revocation of consent by the PSU, may hamper their ability to get up-to-date transactional data. This activity may also result in significant additional costs for AISPs in order to implement the appropriate technology to monitor transactions effectively. This is also unnecessary since transaction monitoring will take place in the domain of the ASPSP. Whilst some AISPs may have access to rich data sets this will only be the case for as long as a PSU provides their consent. Furthermore, the ability of any AISPs to access and view transactions can be limited by the PSU at any time. ASPSPs, however, will have uninhibited access to transaction data for as long as accounts remain open. Given this mismatch of access rights and the obligations incumbent on ASPSPs to monitor transactions, a blanket requirement on AISPs to undertake transaction monitoring should be reconsidered.
OBIE would welcome a more tailored approach which considers the issues we have raised. While TPPs are obliged entities under the AMLD5, we would expect that their obligations are proportionate and aligned to their service offering, the level of information they are able to obtain, and the practical requirements of meeting the necessary obligations.
We would welcome the opportunity to discuss these points with you. Please contact Alan Ainsworth (alan.ainsworth@openbanking.org.uk) if you would like to do so.