Response to consultation on draft implementing technical standards for uniform reporting under the Single Euro Payments Area Regulation
1. Do you perceive that the reporting requirements adequately cater for the situation where the PSP has already reported the same data to the authorities?
In principle, multiple messages should be avoided. We would prefer a single data flow. This is especially important with regard to definitions in order to avoid different interpretations. To avoid duplication and ensure data minimisation, reporting under the various applicable (local) laws and regulations should be streamlined (e.g. scope of application, definitions).
The values which must be reported in template 01.00 are nearly the same as those banks already must report in the B4 statistics (part of the Payment Statistic) to their national bank. We do not see any additional value to report the same content in two different reports, because the new Template 01.00 contains less information than the existing B4.
2. Do you consider the reporting requirements proposed in templates S 01.00 and S 02.00 to be suitable for carrying out a robust analysis and to strike an appropriate balance with the competing need to avoid excessive reporting burden for the industry?
In the EACB’s view, the reporting requirements proposed in templates S 01.00 and S 02.00 are not suitable for carrying out a robust analysis and don’t strike an appropriate balance with the competing need to avoid excessive reporting burden for the industry.
Comments on template S 01.00:
- Items 050–160 and 290–400: The differentiation is not covered by the regulation or by previous statistics. The categorisation is also not meaningful as important areas such as bulk payments by customers are not covered and the restriction to non-paper-based is too narrow. ECB statistics should be used as a guidance.
- Items 410–440: OUR is prohibited in the EU/EEA. Therefore, 100% would be shown here under “share” (410–440)
- Items 450–480: All SEPA SCT transactions are share-transaction – see 0010
In particular, the last block in S01 relating to the breakdown of transaction costs is not the focus of data collection for SEPA payment schemes.
Comments on template S 02.00:
- Template 02.00 goes too much into detail. As reported by some EACB members, most banks don’t have different prices for instant payments delivered via different online channels. The splitting up of transactions by fee options does not bring any added value from our perspective.
- Item 0030–0220: Is not covered by the regulation and seams to lead to inappropriate costs.
- Items 0070–0100: Price differentiation in the EU/EEA is not permitted, so therefore these items are not required.
- When credit transfer charges are bundled with other services, it is not possible to identify the dedicated part for credit transfer and the part dedicated to other services.
3. Do you consider the reporting requirements proposed in templates S 03.00 to be suitable for carrying out a robust analysis and to strike an appropriate balance with the competing need to avoid excessive reporting burden for the industry?
In the EACB’s view, the reporting requirements proposed in templates S 03.00 are not suitable for carrying out a robust analysis and don’t strike an appropriate balance with the competing need to avoid excessive reporting burden for the industry
Specifically, the reporting of Statement of Fees (SoF) like data will be an excessive reporting burden.
The institutions offer a wide range of account models with different scopes of services and therefore also different price models. Customer behaviour and preferences play a major role, especially with individual price models. In our opinion, the items surveyed here are not meaningful in the least.
As stated in the EBA’s explanatory document, the purpose of the reporting is to assess the development between the changes in charges for instant credit transfers and the expenses associated with payment accounts. We believe that collecting data on accounts and related total expenses may not provide a comprehensive measure for assessing the impacts of instant payment pricing.
4. Do you consider that the reporting requirements on the charges for payment accounts and credit transfers will allow for a robust analysis of charges for such individual financial services where they are provided as part of a package of services? How could robustness be improved to strike the right balance between collecting relevant data and not overburdening the PSPs?
We believe that the reporting requirement should focus on transaction charges, leave out the account maintenance and the overall annual cost of the payment account. The overall annual cost of the payment account will cover much more than relevant within the scope.
5. Do you agree that, in light of the aims of the underlying regulation, there is a need for template S 04.00 to collect data on the number of rejected transactions on the side of the payer’s and payee’s PSP prior to the application of the IPR amendments to SEPA Regulation, and rejected transactions on the side of the payer’s PSP, and frozen funds on the side of the payee’s PSP, after the application of the IPR amendments to SEPA Regulation?
We disagree with the EBA proposal. Comparing the number of rejected transactions in the periods before and after the application of amendments to the SEPA regulation resulting from the IPR will not provide useful information. The number of rejected transactions may vary depending on the number of targeted individuals or the number of transactions initiated by or directed at these individuals. Only percentage of rejections could be meaningful.
Clarification is needed regarding the EBA request on instant payment transactions rejected or frozen by the payee's PSP due to the application of the targeted financial restrictive measures. Our understanding is that “targeted financial restrictive measures” in the IPR refer to European lists only. And PSPs are unable to separate rejections based on European lists from other foreign lists. We understand that data requested is from the sending bank point of view:
- From 0010 to 0030: as a sender PSP, it is the number of transactions sent but rejected with RR04 reason (regulatory reason).
- From 0040 to 0060: as a sender PSP, it is the number of transactions never sent because rejected before sending with RR04 reason (regulatory reason).
6. Are the instructions and templates in Annex I and II clear to you or do any of the terms therein require to be defined further?
NA
7. Do you perceive the reporting requirements to be proportionate? Is there information contained in the templates that is overly burdensome to report?
We consider that the reporting requirements are not proportionate. In general, the requirements seem to be too granular with regard to many items, exceeding the requirements of the regulation and lead to disproportionate costs for implementation and operation. Further to this, retrospective data for 2022, 2023 and 2024 may not be possible to collect in every instance. The ITS should reflect this constraint and acknowledge that PSPs may report these data on an adequate best effort or estimate basis if not possible otherwise (see Q.1 and 3).
The reporting requirements will be particularly challenging for banking groups, especially cooperative ones, where there may be hundreds of individual PSPs. For this reasons, we request that the holding company be allowed to implement centralized reporting, with the ability to enter values averaged across different pricing structures.
Regarding the terminology proposed by the EBA, the consultation document (p.4) states: “In developing its proposals, the EBA has sought to strike the appropriate balance between the need to obtain data for a robust analysis of the impact of the IPR on account and credit transfer pricing, and the shares of rejected transactions, while avoiding an excessive reporting burden for the industry. To achieve this, the EBA has leveraged existing terminology and approaches developed in other pieces of EU law, such as PSD2, the ECB Regulation on payment statistics, and the Payment Account Directive (PAD), rather than creating new terms and imposing additional requirements from scratch.”
From the EACB’s perspective, the terminology proposed by the EBA could be improved. The definitions for transaction and volume statistics should align with the ECB's payment statistics requirements to ensure cost-effective and consistent reporting obligations.
Also, we believe that the requirement for S 03.00 0030 (Total number of credit transfers initiated using mobile payment solutions) will place an undue burden on institutions.
Finally, we have a question regarding the scope of the data to be reported: Should SWIFT payments in EUR within the EU be included, or is the scope limited to SEPA Credit Transfers and SEPA Instant Payments?
8. Do you have any other comments on the reporting requirements proposed in this CP?
The EBA consultation document states: “... the first of the annual reports shall be submitted on 9 April 2025, and shall include information on the level of charges and rejections during the period starting on 26 October 2022.” Furthermore, it is stated that “While the new SEPA Regulation requires the first data points to be as of 26 October 2022, it does not specify the subsequent reference dates. The draft ITS proposes to use the date of 31 December for that purpose. It means that the first submission of information from the PSPs to the NCAs will take place on 9 April 2025 and will include aggregates for the periods 26 October 2022 – 31 December 2022, 1 January 2023 – 31 December 2023, and 1 January – 31 December 2024. Subsequent submissions to be submitted by 9 April of each year will include annual aggregates for the preceding year.”
We would like to highlight that the proposed timeline for the reporting requirements is highly unrealistic. According to the draft ITS, the final technical standards (e.g., XML specifications) will be available by the end of 2024. However, the first report is expected by 9 April 2025 (as stated in paragraphs 6 and 7 on page 6 of the consultation document). This allows banks only three months to analyze the technical specifications and implement a reporting system for historical transactions dating back more than two years.
Besides, IPR Art. 15.5 provides that “The EBA shall submit the draft implementing technical standards referred to in the first subparagraph of this paragraph to the Commission by 9 June 2024.” It seems that this deadline has not been respected by the EBA.
EACB members, based on internal analysis and assessments from their technical providers, have expressed concerns that the proposed timelines for reporting are impractical and will incur high bureaucratic costs. The draft reporting requirements are overly granular in many respects, extend beyond the Instant Payments Regulation, and at times lead to considerable, inappropriate implementation costs.
The draft reporting requirements are highly detailed, and in some cases, PSPs will need to implement additional systems to identify certain products separately in combination with their charges. For instance, some EACB members report that they only have one pricing per customer for electronic credit transfers. Therefore, to calculate the number of transactions initiated online (a subcategory of electronic payments), they would need one system for tracking transactions, and then combine those numbers at the customer level with pricing information from another system to determine the correct total charges for online-initiated credit transfers.
This example illustrates that the timeline for the first reporting, as proposed by the EBA, is too ambitious and unrealistic. Banks are currently focused on implementing the IPR requirements (the obligation to send and receive instant payments in euro, pricing, verification of payee, sanctions screening). Given the non-urgent nature of the reporting obligations compared to the other implementations required for the successful adoption of SCT Inst at the European level, we would welcome a derogation from the legislation, for example, a 6-month delay.
Additionally, we are interested in knowing which authority banks will be required to submit the reporting data to, as banks will need to implement an API interface for data delivery or at least adapt an existing API for this special report. The API connection and submission process will also need to be tested. Service providers may be interested in supporting banks with this reporting, but the proposed timeline does not allow sufficient time for them to develop the necessary solutions.
In view of the assessments made in the consultation, it should be reconsidered whether an evaluation of the data from 2022 onwards is useful and necessary. Reporting is not an example of efficient regulation.
Reporting mechanism (in case of obligation to submit one report per PSP): To avoid manual data copying, it is advisable to automate the process. However, working with Excel formats makes automation challenging. Therefore, a simplified format, such as XSD, should be proposed to streamline the process.