ESBG responds that there should be an objective for ad-hoc exchange of fraudulent data
>> See the .pdf version
ESBG welcomes the opportunity to review and comment on these draft Guidelines.
ESBG believes that the objectives are going in the right direction in general. Nevertheless, the following two objectives are missing:
First, ESBG believes that here should be an objective for an ad-hoc exchange of fraudulent data (fraudulent or fake) such as ID documents, names, IBANs, phone numbers, addresses and other information that could be used to commit fraud) between PSPs, ideally via competent authorities.
Second, ESBG is of the opinion that there should be an objective for an automated reporting possibility to law enforcement without the need for a thorough or immediate investigation (an 'ITIL'-like distinction between incident management and problem management).
Besides, we would like to make the following remarks:
As per Guideline 2.7, PSPs need to submit the required data to the competent authority following the procedures defined by the competent authority. In order to prevent fragmented approaches across Europe, and in order to assist PSPs that operate across multiple countries, all competent authorities should have the same and uniform procedures on how to perform the reporting. For example, in addition to setting the content, the EBA could publish some additional ITS on the format and data exchange (between Competent Authorities and between Competent Authorities and Payment Service Providers) for fraud reporting.
ESBG believes that only gross fraud is a relevant indicator in tracking fraud and underlying trends. Net fraud is more an indicator of PSPs individual capabilities to recover fraud from various sources including insurances and seems hence not relevant in tracking the underlying fraud. Therefore we believe only gross fraud should be reported.
ESBG is always in favour of proportionality in regulation, and as such welcomes EBA's recital 12 in section 2 on subject matter, scope and definitions. The recital states 'The Guidelines are subject to the principle of proportionality, which means that all payment service providers within the scope of the guidelines are required to be compliant with each Guideline, but the precise requirements, including frequency of reporting, may differ between payment service providers, depending on their size, business model and complexity of their activities'. However, ESBG would welcome more clarity on this aspect. More specifically, how and by whom will this principle of proportionality be executed, on what aspects, and what will be the exact differences? Can additional proportionality criteria be expected from this recital 12?
ESBG would like to remind the EBA the fact that PSPs are required to provide payment statistics under the Payment Statistics Regulation EU1409/2013 of the ECB of 28 November 2013 on payments statistics (ECB/2013/43). Under the headings of 'Total Payments Transactions' the same data is being requested in this particular reporting, effectively requiring PSPs to report the same data twice.
With respect to Guideline 1.1, ESBG is of the opinion that the types of fraud b and cdo not occur because of vulnerabilities or weaknesses in in PSPs payment systems, but that are a result of some form of relationship between a Payment Services User (PSU) and a fraudster. Consequently, and as they involve transactions that have been properly authorised, there is no way PSPs could possibly identify those transactions as fraudulent and prevent them from happening. As such, requiring PSPs to report fraud that is beyond their control can have a possible negative impact on both the PSPs fraud rate and possible exemptions from strong customer authentication under the RTS on SCA and CSC. Regardless, ESBG recognises that the commented types of fraud should be classified as fraud under PSD2 in relation to other actions that can be to prevent them to happen.
In order to address your question in more detailed terms, ESBG would like the following definitions to be clarified, for the avoidance of any doubt and misinterpretations:
What is the exact definition of a delayed debit card – how much delay is sufficient for that classification? ESBG also observes that some items seem to be missing from the Guidelines:
Rules to identify or to avoid the impact of double reporting, especially for card transactions, seem to be missing; also, paragraph 46 is not completely clear.
There are no rules provided to identify or to avoid the impact of later corrected volumes and/or values, for example due to different reporting periods.
There is no distinction between the various counterparties, like differentiation between AISPs or PSPs or a distinction between PSPs with a banking license and PSPs without a banking license.
As remittances can cover both cash-in as well as cash-out transactions, the introduction of cash into or the extraction of cash out of these cycles are relevant as well.
With respect to the structure, ESBG is wondering whether it is an option to combine all separate tables into one flat structure as this allows also the possibility to slice and dice the data across the various dimensions.
No, ESBG does not agree.
It is true that the legal basis for these Guidelines resides on article 96(6) PSD2, which is directly related to the legislative mandate for the issuance of Guidelines for major incident reporting on article 96(1-5) PSD2. As such, if we relate both issues, it could be understood that the Guidelines on major incident reporting cover single incidents that are considered impactful (major) and therefore need to be promptly reported, while these Guidelines cover periodic reporting of fraud data with the objective of gathering statistics and insight on fraud under PSD2-related activities. That is, the Guidelines on fraud reporting requirements would actually include the fraud resulting from the major incidents reported under the other Guidelines, plus every other minor incident that has caused fraud on the PSP. In conclusion, taking into account that (i) incidents affecting AISPs can cause fraud and (ii) account information services are included in the Guidelines on major incident reporting, these Guidelines on fraud reporting requirements should include AISPs.
At the same time, article 96(6) mentions “statistical data on fraud relating to different means of payment", neither explicitly discarding account information services nor mentioning payment initiation services only. Therefore, it could be that fraud itself can occur not only during a payment transaction, but also within the relationship between PSUs and AISPs. Examples of fraudulent activities through AISPs can include phishing, hacking, identity theft or any sort of data breach or leakage. Any of these fraudulent activities can cause major problems on PSUs, even though they often cannot be measures in a quantitative way.
So, AISPs with loose controls could be the originator of the majority of fraudulent cases and volumes and therefore this should be identified as soon as possible. As this is currently not addressed in these draft Guidelines ESBG recommends that either AISPs should report their relation to fraudulent transactions separately, or these should be reported via PSPs at least as separate channels as defined in Annex 2 and 3.
We disagree with the rationale behind the exclusion of attempted fraud from reporting requirements. As the EBA admits on rationale 25, capturing data on attempted fraud would enable competent authorities to assess the effectiveness of the internal controls of the PSP in blocking transactions before they are executed. In support of this rationale, one of our Member's internal fraud reports show that attempted fraud currently accounts for as much as 98.89% of all gross fraud. Also backing that inclusion of attempted fraud, as rationale 27 states, “under the EBA's RTS on SCA and CSC, all PSPs shall have risk and fraud monitoring systems in place to enable them to block any suspicious payment as foreseen by PSD2". As this is expected to be already in place with the entry into force of the PSD2, and taking into account that most PSPs already report attempted fraud internally, the additional burden that this requirement would impose on PSPs is not large enough to justify the application of the proportionality criteria. The inclusion of attempted fraud would substantially improve the information the competent authorities and the EBA could work with in order to achieve the objectives behind these Guidelines. That is, the inclusion of attempted fraud would allow competent authorities to get information about the effectiveness of the security processes applied by PSPs, which would not be otherwise possible only taking into account executed fraud. This would also assist in identifying trends in fraud attempts which are very useful and insightful for knowledge exchange on fraud prevention across entities and across borders, and it could also prevent fraudsters to perform small 'test' transactions in 'test-markets' before deploying their modus operandi in other markets.
As mentioned in our observations under Question 1, ESBG believes that the reporting of net fraudulent payment transactions does not contribute to the overarching goal of fraud reporting as it rather is an indication of an individual PSP's capability to recover fraud from regardless source than that it is an indication of the underlying fraud. Besides, it is worth noting that this recovery can be a very lengthy process and as such, the recovery and the reporting of it can take place in another period than that over which the underlying fraud was reported, which may lead to misinterpretations of the data. For example, a lot of fraud could happen during the Christmas shopping season as due to high transaction volumes fraud could slip through, indicating high fraud levels in the relevant annual or quarterly report, whilst any recovery would be offset in the reporting over the next year or quarter.
If regardless of the above, the EBA insists on keeping both notions of fraud in, ESBG would recommend the EBA to make clear distinctions between recovered, covered by insurance or burdened by customers in other to get better views.
In relation to the frequency of reporting, even though ESBG can agree with the exemption from quarterly reporting for small payment institutions, we recognise that it can create a significant information gap for a considerable time. The reporting obligations are not sophisticated and these can contribute to many insights when fraud modus operandi prevail. Due to the fact that the first annual report will take place in 2020H1, while the PSD2 enters into force on 13th of January of 2018, there will be almost two years where competent authorities will receive no information from small payment institutions. Although the RTS on SCA and CSC will not be applicable, fraud activities may be significant during those two years. Therefore, we consider that an intermediate solution must be found as to, for example, require small PSPs to report on a quarterly basis until the first reporting period in 2020H1. From that point onward they could be exempted from the quarterly reporting due to the rationale presented.In general, with respect to the frequency of the reporting, ESBG agrees with the frequency of the high-level reporting as indicated in the Annexes 2 and 3, but ESBG disagrees with respect to the frequencies for ad hoc fraud cases and data exchanges.
As per Guideline 3.3, the payment services provider should submit their data within the timelines set by the respective competent authorities. Also with respect to this Guideline we would like to repeat our remark as stated in our response to Question 1, namely that in order to prevent fragmented approaches across Europe, and in order to assist PSPs that operate across multiple countries, all competent authorities should have the same and uniform procedures on how to perform the reporting, for example in terms of content and formats but also in terms of communication channels.Further, ESBG would like to observe that the differentiation between the various Geographies only increases filter-logic which may confuse interpretations. If everything is reported under Geo 3, the filtering can take place elsewhere.
ESBG is not of the opinion that an acceptable compromise has been reached, as it is especially unclear on the PSP-payee side where to deduct the 'double' reporting (only very high level possible for Geo 3 indications, but not for the other two regions as there will be no country breakdown. Besides, different data quality and interpretation ambiguities as well as different time delays between payer's and payee's PSPs might lead to different numbers and therefore to unclear double counting calculations.
An improvement could be that only the PSP who represents the payer should provide the information, but amended with the counterparty information as outlined in our answer under question 2.
We do, at this point in time, not consider it necessary to distinguish between payment transactions made by consumer or other PSUs, as the breakdown of data proposed by the EBA already reflects the data necessary to achieve the objectives behind these Guidelines (i.e. assess the effectiveness of legal and regulatory requirements, identify trends and potential risks, and assess security incidents and emerging fraud trends and threats). Currently neither our internal nor external fraud reporting mechanisms include this distinction as it does not provide valuable insight on measures against fraud, so the distinction suggested on this question would cause an unnecessary burden with no clear benefits. Also, currently this distinction cannot be made when both consumers and others are using the customer interface (also known as screen scraping).
However, going forward, this issue could become more relevant. From the moment TPPs start using dedicated interfaces, it can be possible to distinguish between consumers and other PSUs. ESBG Members believe that in these circumstances a distinction will be beneficial because higher fraud rates could be expected on transactions made by other PSUs compared to transactions made by Members' own customers. EBA is expected to provide respective definitions though (for example 'no representative of any legal entity').