Primary tabs

Deutsche Bank

Broadly we agree with the general considerations, however, there are some points where amendment is required to ensure they are effective, risk based and proportionate:

1. Linked Transactions

We welcome the addition of the definition related to linked transactions, but we believe “6 months” is not a realistic timeframe to consider transactions to be linked.

A timeframe of this length, which would also capture monthly recurring payments, would require a significant IT infrastructure build and would introduce incremental complexities into the production environment of market participants.

If 6 months remains as the guideline, we would expect that the majority of payment service providers (PSPs) when acting as PSP of the payer will not make use of the exemption (i.e. the interpretation provided in the guidelines would effectively render the exemption provided for in the Regulation obsolete).

However, intermediary PSPs are not, and would not be, free to decide whether to apply the exemption. Where the payer’s PSP is established inside the EEA to a payee’s PSP established outside the EEA, the payer’s PSP may in principle send transactions not exceeding EUR 1000, unless linked, without the payer’s address. As a result, in such cases intermediary PSPs are legally required to check whether this transaction is linked in order to determine, whether that transaction contains all regulatory required information. Intermediary PSPs would not “benefit from this exemption” but instead are required to take it into account when determining whether sufficient information has been transmitted to them.

If intermediary PSPs must consider transactions in a timeframe of six months as potentially linked, one conceivable reaction might be that intermediary PSPs would, as a matter of principle, not accept transactions without full information in the respective scenarios.

To avoid these impacts our suggested wording for the section would be as follows:

13. Transfers of funds must be considered as being “linked” if they are sent from the same payment account to the same payment account in a short time-frame (3-5 working days).

2. SEPA Direct Debits (SDD)

In principle, direct debits are (in the same way as credit transfers) in scope of FTR 2015, since direct debits qualify as “transfers of funds” (Art 3 (9) (b)).

We understand that because of the general decision taken on scope and approach the guidelines do not comment on what (and how) requirements must be observed and fulfilled by which PSP at the respective process steps of SDD.

However, FTR 2015’s requirements have been formulated to reflect the processing of credit transfers (starting with a customer instructing its PSP to execute a transfer, that PSP then executing the transfer and thereby being required to ensure proper transmission of required information, etc.). As the actual processing of SDD is very different to the execution of credit transfers, different interpretations currently exist in the industry on how FTR 2015’s requirements should be applied. Therefore, we would welcome further guidance, in particular in relation to the specific requirements the payee’s PSP must observe when sending a collection.

When applying FTR 2015 requirements (directly) to the specifics of the private law SDD scheme, this – pursuant to our interpretation – leads to the following requirements and open questions:

a. Collections

The payee initiates the SDD via the payee’s PSP that sends the collection through a “Cash Settlement Mechanism” (e.g. a payment market infrastructure, automated clearing house, or other mechanism) to the payer’s PSP.

The collection itself is not a transfer of funds; instead it is a payment instruction as the funds are only moved on settlement day. FTR 2015, however, clearly differentiates between a “transfer of funds” and the “instruction to a transfer” and does not impose any obligations in regard to the latter. Furthermore, the information transmission requirements of Art 4 (et sqq.) are imposed on the PSP of the payer, whereas the collection is sent by the PSP of the payee. Accordingly, when applying FTR 2015 (directly), the payee’s PSP has no FTR 2015-related requirements to fulfil when sending a collection.

However, taking into account the background and purpose of FTR 2015, and the legislator’s intention to have direct debits falling under the scope of the regulation, we understand that one might consider an “analogue application” of FTR 2015 requirements for collections.

If this were the case, the payee’s PSP, when sending a collection (first “analogue application” as it is an instruction and not a transfer), would have to comply with the information transmission requirements of Art 4 (“second analogue application” as the transmission requirements are imposed on payer’s PSP and not on payee’s PSPs). When applying the requirements of Art 4 on the payee’s PSP – and in particular when taking into account the verification requirements of Art 4 (4) and (5) – one would have to apply the information transmission requirements inversely.

In other words, the payee’s PSP would have to ensure that depending on the scenario (i) the name, account number and address of the payee and (ii) the name and account number of the payer are transmitted with a collection.

Under no circumstances could it be argued that the payee’s PSP has to ensure the transmission of the payer’s address when submitting the collection, as this line of reasoning would contravene the entire thought process taken to argue that the payee’s PSP has to observe information transmission requirements when sending a collection.

b. Debit of the payer’s payment account

On settlement day, the payer’s PSP debits the payer’s account (if the correct conditions are met, including sufficient credit etc.). However, the payer’s PSP only debits the payment account of the payer and does not initiate a payment transaction to the payee. Therefore, the payer’s PSP is not required to ensure that certain information accompanies a transfer to the payee as there is not, in fact, a “transfer” to the payee.

c. Settlement

The inter-bank settlement is out of scope of FTR 2015.

We would ask that the ESAs provide clarification on (i) whether FTR 2015 requirements – in particular in relation to the processing of Collections – must be applied analogously. Should this be the case the ESAs should (ii) confirm the above interpretation and consequences this has on the processing of SDD.
We agree in principle with the expectations on intermediary PSPs and PSPs of payees that are detailed in Chapter II, but have certain concerns that we would like to highlight and/or clarify:

We understand that the aim of FTR 2015’s is to ensure full traceability of transfer of funds at each step in the transaction chain. It therefore puts in place a comprehensive framework starting with the requirement to ensure that certain information is transmitted and retained end-to-end with a transfer, requiring the implementation of effective procedures to detect missing / incomplete information, and the requirement to take steps in relation to PSPs that repeatedly fail to provide required information (including regulatory reporting).

It is this comprehensive framework and the reasons for missing / incomplete information in transfer of funds that must be considered when both (i) implementing risk-appropriate effective procedures to detect missing / incomplete information on the payer and the payee, and (ii) deciding on whether to execute, suspend or reject a transfer of funds that is missing regulatory required information. In this context it is relevant to note that:

1. The requirement to ensure that regulatory required information on the payer and on the payee is transmitted with a transfer is imposed on the payer’s PSP and not the payer.
2. Accordingly, in case information is missing or incomplete this does not per se point to an ML/TF attempt but instead would normally mean that the payer’s PSP has either (i) a technical data transmission issue (e.g. corrupt database, or interface problems), or (ii) is not sufficiently checking and ensuring that all necessary information is indeed transmitted in the necessary field as a result of a different understand, or lack of awareness of FTR 2015’s requirements (this could be especially pertinent for PSPs from outside of the EEA). Both root causes are unrelated to the individual payment transaction and a potential ML/TF attempt.
3. If indeed the payer’s PSP was assisting in, or itself conducting an ML/TF attempt, it would most likely – as initiator / processor of the transfer – ensure that information is contained in the transfer as expected in order to not raise suspicion. That information might be deliberately incorrect, however, subsequent PSPs in the transaction chain would not be able to detect this.

1. Real-time vs. ex-post monitoring

We understand that Art 7 (1) and (2) as well as Art 11 (1) and (2) respectively must be read in conjunction. Whereas, pursuant to Art 7 (1) / Art 11 (1), intermediary and payee PSPs are required to detect whether the regulatory required information in relation to the payer and payee has been transmitted in the designated data fields required by the conventions of the respective scheme, using admissible characters and inputs, Art 7 (2) / Art 11 (2) details the scenario-specific information that must be transmitted on the payer and payee in these designated data fields. Regulatory required information in relation to the payer and payee that is not transmitted in the designated data fields (as required by the conventions of the respective scheme used) is – for the purpose of FTR 2015 – not sufficiently provided by the sending PSP.

This approach would require intermediary and payee PSPs to conduct “meaningful character checks” (as per market practice today under the in essence identical requirement of the preceding regulation) on the designated data fields to check whether regulatory required information on the payer and the payee has been transmitted.

However, the guidelines appear to go beyond this interpretation, with implications for determining if and when a real-time monitoring must be but in place. In addition, and as explained above, we believe that the root causes on why regulatory required information is missing in a transfer must be taken into account as well.

We therefore believe that for the purpose of FTR 2015 real-time monitoring should be considered – if at all - only in exceptional circumstances. It should be deemed sufficient to meet the requirements of the Regulation, if monitoring is targeted to address the root causes of the payer’s PSP failing to include required information.). Furthermore, the appropriateness of a PSP’s ex-post monitoring activities should be taken into account in conjunction with the PSP’s effective risk-based additional steps procedures for dealing with other PSPs repeatedly failing to provide required information (see below “5. Additional Steps”).

We would therefore recommend that in particular provision 24 and 25 is amended as follows:

“24/25. Effective procedures may include a combination of ex-post and real-time monitoring. Where PSPs do not routinely monitor transactions in real time they should consider targeted real-time monitoring if their ex-post monitoring suggests this. In line with a PSP’s risk-based approach real-time monitoring

 may be targeted to transfers of funds from a PSP based in a country associated with high ML/TF risks that is repeatedly failing to provide required information on the payer without good reason

 or, alternatively, and depending on the effectiveness of a PSP’s ex-post monitoring, on transfers of funds that present a higher ML/TF risk.

A PSP shall determine the appropriate approach and indicators based upon their risk-based methodology, thereby also considering the effectiveness of its additional steps procedures (see paragraphs 54-58).”

2. Decision whether to execute, reject or suspend

As explained above, missing or incomplete information does not per se point to an ML/TF attempt but instead indicates quite different root causes. Therefore, neither the type of information missing, nor the fact that a transfer is from a high risk country should give– rise to suspicion of an ML/FT attempt for the purpose of FTR 2015. Considering the comprehensive framework put in place by FTR 2015, the decision on whether to execute, reject or suspend a transfer should be taken on the basis of whether the respective PSP repeatedly fails to provide the regulatory required information (please also see 5 below).

3. Repeated Failure Definition

We appreciate the ESA’s intention to allow PSPs to react with a high degree of flexibility when deciding whether another PSP is repeatedly failing. However, we believe that the guidelines should aim for a maximum of harmonization in this regard and provide detailed requirements.

The potential consequences attached to repeated failures are significant. Different interpretations and approaches by PSPs should therefore be avoided. If a differentiated approach is allowed to develop, PSPs that apply higher standards and monitor more comprehensively would identify and treat other PSPs as repeatedly failing more often. In the case of intermediary PSPs a possible result will be that (i) repeatedly failing payer PSPs will route their transactions via other intermediary PSPs instead of adjusting their behaviour, and (ii) intermediary PSPs applying this best practice will incur a competitive disadvantage.

Furthermore, repeated failures must be reported to the respective local competent authorities. Pursuant to today’s applicable Regulation (EC) No 1781/2006 several local competent authorities have set detailed repeated failure definitions and corresponding reporting requirements resulting in a fragmented regulatory landscape (i.e. the FCA has specified that 10 transactions with missing information in a quarter should be the criteria applied to be a repeated failure, which will have significant impacts on large PSPs who may make thousands of transactions a day).

Should the guidelines remain as they are and not provide a detailed, specific definition of repeated failures, local competent authorities will continue to set their own specific requirements. As a result (i) the industry would (continue to) be faced with a fragmented regulatory landscape and, (ii) payer PSPs regularly failing to provide required information could be encouraged to route their transactions via intermediary PSPs located in countries with less stringent repeated failure definitions.

4. Reporting

We agree with the general requirement to report an identified repeated failure within one calendar month (or earlier if required by local law) to the competent local authority. For the same reasons explained above (2. Repeated Failure Definition) we would welcome a clarification on the relevant period of time within which failures should be counted to determine whether another PSP repeatedly failed.

We would suggest that the relevant period of time for counting and assessing whether another PSP repeatedly failed to provided required information shall be 3 months (on a cyclic basis). As a result failures would, consistently be counted, assessed and – where repeated – reported on a quarterly basis. This is already the approach adopted e.g. in Germany under the current regulation.

5. Additional Steps / Steps to be taken

Art 8 (2) and Art 12 (2) could be interpreted as determining an exhaustive list of steps PSP must take and excluding the possibility of any additional, interim steps. Therefore, we appreciate the clarification that the additional steps that must be taken in relation to PSP repeatedly failing to provide regulatory required information should be risk-based.

It would be helpful if final guidelines could further elaborate on this aspect. Currently, provisions 54 to 58 could still despite clarifying that the steps should be risk-based, be interpreted as requiring a PSP to reject any further transfers of funds after issuing just two warnings.

Such an automatic escalation, following two issuing of warnings would, be neither risk-based, nor appropriate in most cases:

1. As elaborated above, the root-cause for missing information in a payment transaction is likely that the sending PSP has either (i) technical data transmission issues or (ii) is not sufficiently checking and ensuring that all necessary information is indeed transmitted in the necessary field as a result of a deviating interpretation or unawareness of the requirements. Both root causes are unrelated to the individual payment transaction and a potential AML/TF attempt.

2. Therefore, an in-principle rejection of all transfers of funds from that PSP, irrespective of whether these transfers actually contain all regulatory required information, is not appropriate.

It should be noted that once (as a matter of principle) all future transfers are rejected the next escalation step to restrict or terminate the business relationship (“…as a last step…”) can logically only refer to non-payment transaction related business interactions. I.e. applying enhanced due diligence measures [58], would not have an impact on the requirement to reject all transfers of funds (irrespective whether they contain all required information or not).

It should further be noted, that no guidance is provided (neither in FTR 2015 nor in the draft guidelines) if and when transfers could actually be accepted again.

3. Instead of rejecting all transfers (thereby partly cutting the PSP off its access to payment transactions) an appropriate next escalation step would e.g. be to (i) monitor all transfers received from that PSP on a real-time basis, and (ii), as a matter of principle, to reject all transfers with missing/incomplete information.

4. Such a proportionate approach, would contribute to a change in behaviour of the PSP repeatedly failing to provide regulatory required information and address the root cause. In addition, this way the aim of FTR 2015 to ensure full transparency at each step in the transaction chain would actually be better served.

In this context it is relevant to note that an in-principle rejection of all transfers of funds would be in contradiction to the terms and conditions of Payment Market Financial Infrastructures that in case of RTGS are owned and operated by Central Banks.

Furthermore, it should be noted that depending on the definition of repeated failures it might be appropriate to distinguish between (i) the reporting of repeated failures and (ii) the need to take additional steps because of a repeated failure (as defined). For instance, if a PSP is considered as repeatedly failing if it sends in a quarter 10 transactions with missing or incomplete information it might still be disproportionate to take additional steps if that PSP is responsible for very high transaction volumes.

In light of this we would suggest rewording guidelines 54 to 58 as follows:

54. Where a PSP repeatedly fails to provide information required by Regulation (EU) 2015/847, the PSP of the payee must take steps to address this. These steps should be risk-based and should take into account the number of transactions with missing information as a proportion of total transactions for that PSP.

55. The steps listed in Art 8 (2) and Art 12 (2) and that may initially include the issuing of warnings and setting of deadlines before ultimately the entire business relationship with that PSP must be terminated are non-exhaustive. Further interim steps, appropriate to the risk, may be taken.

56. In particular, before as a matter of principle rejecting all future transfers of funds form that PSP (irrespective of whether these transfers actually contain all regulatory required information) the PSP should consider, whether the risk could also be addressed by carrying out real-time monitoring of all transactions received from that PSP and by rejecting as a matter of principle those transfer of funds where regulatory required information is missing.

57. When considering the appropriate step, a PSP may take into consideration the repeatedly failing PSP’s attitude to responding to request for information and the issuance of warnings. In addition, in particular where the sending PSP is a respondent bank from a third country, the PSP should consider whether it can manage the risk in other ways, including through the application of enhanced due diligence measures in line with Article 19 of Directive (EU) 2015/849.
We are largely in agreement with the provisions for intermediary PSPs, however we do have some concerns regarding the way they might be understood and therefore would suggest re-phrasing them slightly.

Intermediary PSPs (as well as payee’s PSPs) must check: whether the information on the payer and the payee, as required in the specific scenario, has been transmitted to them by the preceding PSP in the transaction chain; and that the information has been captured in the designated fields on the payer / payee of the messaging or payment and settlement system used (i.e. regulatory required information not transmitted in the designated data fields is – for the purpose of FTR 2015 – not sufficiently provided by the sending PSP. Furthermore, intermediary PSPs can only check (by way of a meaningful character check) whether information has been transmitted in the designated fields and if that information is not obviously meaningless (e.g. “my customer” etc.).

We would therefore amend provision 59 and 60 as follows:

59. Intermediary PSPs should satisfy themselves that their systems and controls enable them to comply with their duty to ensure that all information on the payer and the payee that accompanies a transfer of funds is retained with that transfer.

Intermediary PSPs are not required to check whether regulatory required information on the payer / payee incorrectly might have been transmitted in fields other than the respective designated data fields of the messaging or payment and settlement system used by the sending PSP. Accordingly, the requirement imposed on intermediary PSPs to ensure that all information received on the payer and the payee is retained with that transfer relates only to the information provided to / received by the intermediary PSP in the designated data fields.

Intermediary PSPs, when executing the transfer to the next PSP in the transaction chain, must then ensure that this information on the payer and payee is transmitted by them in the designated data fields of the messaging or payment and settlement system used.

60. Intermediary PSPs, when executing the transfer to the next PSP in the transaction chain, should only use payment or messaging systems that permit the onward transfer of all information on the payer or the payee (provided to / received by the intermediary PSP in the designated data fields), irrespective of whether this information is required by Regulation (EU) 2015/847.
Name-Number-Check Requirement

The description of the verification requirements the PSP of the payee must conduct is helpful, however, depending on the interpretation of the verification requirements of Art 7 (3) and (4) in certain scenarios a “name-number-check” might be required. This check / this verification would, however, have been “deemed to have taken place” already, if the conditions of Art 7 (5) are met. We would therefore welcome clarification if and when the conditions of Art 7 (5) are met.

Pursuant to Art 7 of FTR 2015, the payee’s PSP is required to (i) detect whether regulatory required information is transmitted in the designated fields and (ii) verify the accuracy of the information received on the payee in certain scenarios. We understand that, in instances where the payment is to be credited to a payee’s payment account (and the payee’s PSP has no reasonable grounds for suspecting money laundering or terrorist financing) pursuant to Art 7 (1) to (4) FTR 2015:

 for all intra-EEA payments, a name-number-check is not required (Art 7 (3) in combination with para (2) (a), however;

 a name-number-check might be required (unless Art 7 (5) applies) for payments exceeding EUR 1000 (or that are “linked” above EUR 1000) where the PSP of the payer is established outside the EEA (Art 7 (3) in combination with para (2) (b)).

However, pursuant to Art. 7 (5) such a verification check is, in principle, not required if the identity of the payee has already been sufficiently verified (e.g. if the customer has been properly KYC’ed in an ongoing customer relationship).

In this context we would welcome clarification as to what information contained in a payment message the payee’s PSP shall determine whether the preconditions are met for Art. 7 (5) to apply (i.e. determination if the payee’s identity is already sufficiently known (“verified”).

 Either based on the transmitted account number (as a result, whenever the transmitted account number matches an existing account where the account holder has been undergone proper KYC checks, the payment amount could be credited to that account without a name-number-check requirement).

 Or based on the transmitted payee’s name (as a result, the name would effectively have to be matched with the account number, which would raise a question around what should be done in case of conflict).

In particular when comparing Art 7 (5) with the corresponding Art 4 (5) on the payer’s PSP verification requirements side, we understand that the intention and requirements of FTR 2015 are as follows:

1. Funds are only to be moved by the payer’s PSP if the payer is sufficiently known to the payer’s PSP and, correspondingly, the payee shall only be credited by the payee’s PSP if the payee is sufficiently known to the payee’s PSP.

2. This requirement applies to all individual transfers, however, in case of an ongoing customer relationship it is not necessary to verify the payer’s / payee’s identity for each single transfer of funds again before executing / crediting but instead PSPs may rely on their existing proper KYC processes and information.

In line with this logic, we understand that the payee’s PSP is allowed to determine that it sufficiently “knows the payee’s identity” on the basis of the transmitted payee’s account number only and as such the payee’s PSP would have to:

1. check whether the transmitted payee’s payment account number matches an existing customer’s account number;

2. should this be the case, and if the respective customer (identified by the account number) has been properly KYC’ed;

3. the payee’s PSP may credit this customer’s account.

This approach would ensure that only a properly known (“verified”) account holder would be credited. If the credited account holder was not the recipient actually intended by the payer (i.e. the payee’s account number was misspelled by the payer or the payer by mistake inserted a wrong payee’s account number in the payment instruction), a potential money-laundering or terrorist financing attempt by the payer would in any case have failed.

In addition, this interpretation of the regulatory requirements of FTR 2015 and approach would also be in line with civil liability rules put in place by the Payment Service Directives (PSD) 1 and 2, which allows for execution of payments based solely on account numbers (ensuring respective consistency).
Matt Holmes
D