Definition of "Communication Standards" under Article 30.3

a) Is ISO 20022 considered the communication standard referenced in Article 30(3) of the Regulatory Technical Standards (RTS), Commission Delegated Regulation (EU) 2018/389? b) How should NCAs ensure that ASPSPs comply with these standards, in accordance with Article 30.6 of the RTS?

According to the Recital 21 of Commission Delegated Regulation (EU) 2018/389, “ …To ensure the interoperability of different technological communication solutions, the interface should use standards of communication which are developed by international or European standardisation organisations.” ; Article 30.3 of the same Regulation states:  "Account servicing payment service providers (ASPSPs) shall ensure that their interfaces use communication standards issued by international or European standardization organizations.";  And,  Article 30.6 further mandates:  "Competent authorities shall ensure that account servicing payment service providers comply at all times with the obligations included in these standards in relation to the interface(s) that they put in place. In the event that an account servicing payment services provider fails to comply with the requirements for interfaces laid down in these standards, competent authorities shall ensure that the provision of payment initiation services and account information services is not prevented or disrupted to the extent that the respective providers of such services comply with the conditions defined under Article 33(5).” The Berlin Group is a standard widely adopted by the majority of ASPSPs in the industry, utilizing the ISO 20022 communication standard (in order to comply with the previously mentioned Articles), which defines transaction statuses in precise terms. ISO 20022 is a globally recognized standard that provides a common platform for the development of messages using a standardized language, facilitating interoperability and efficiency in financial communications. According to the ISO 20022 standard, the status of a transaction can vary based on the stage of the payment order process. For  bank transfers executed by ASPSPs through online channels, the process typically involves the authorization of the transfer by the client, followed by the automatic reservation and debiting of funds in the current account .  This action corresponds to a specific transaction statuses as defined by ISO 20022, which is and reflects the completion of the settlement on the debtor's account according to these standards. However, concerns arise from observed discrepancies in the application of transaction statuses, particularly the use of certain acronyms that are not aligned with ISO 20022 standards for payment initiation services (PIS). These discrepancies, without valid grounds, contradict the principles of PSD2 (Recital 29 of Directive PSD2) and may hinder the efficient execution of payment transactions. In such cases, when an ASPSP does not adhere to the adopted technical documentation, such as the ISO 20022 standard, NCAs should undertake actions as outlined in Article 30.6. Rather than adhering to a uniform standard, each ASPSP interprets the transaction statuses outlined in ISO 20022 in a manner that aligns with their individual practices, leading to significant inconsistencies in the execution of payment orders initiated by the TPPs. The following examples illustrate the varied interpretations communicated by ASPSPs: Some ASPSPs consider their interpretations of ISO 20022 valid simply because they are documented in their technical specifications. Other ASPSPs assert that their interpretations are correct because "this is how their internal systems communicate." Some ASPSPs claim that their interpretations of ISO 20022 are justified by the technical standards to which they have subjected the payment initiation service integration (e.g., Berlin Group, Open Banking, etc.). Other ASPSPs view ISO 20022 as a "guideline" rather than a mandatory requirement for providing payment initiation services. This interpretation allows them to conduct subsequent validations on the customer profile (such as anti-fraud systems, limitations, etc.), which may result in payment order rejections after the PSU's current account has been debited.