Primary tabs

Accenture

DISCLAIMER: Because Accenture is not authorized to act as a legal adviser or interpret laws and regulations, Accenture may not confirm any of the legal interpretation made by EBA in the Consultation Paper. The responses below assume that the EBA’s interpretations are correct and provide comments solely related to accommodating such interpretations through technical and business means.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Accenture is responding to this consultation because we believe, through our work across the European Member States with financial institutions and retailers, that the EBA electronic central register is an essential component of an efficient digital payment ecosystem operating under the framework of the PSD2. The register is needed to meet the PSD2 objectives to enhance the transparency of payment institution operations and to ensure high levels of consumer protection, including from cyber-crime. It is a public record of the authorised and regulated third parties for account information and payment initiation services, against which account servicing PSPs can check the validity of the third parties which consumers use to provide these services.
However, we recognise that the EBA has a legal mandate that limits its Regulatory Technical Standards (RTS) to define technical requirements to develop, maintain and operate the register, and to define the details and structure of data it holds. The EBA’s mandate excludes definition of how the register is used by market participants, the overall architecture of the market and the role of the register within it, and how the market operates.
There is therefore a gap between the market requirements for the register and the requirements the EBA is able to mandate. Further, definition of market requirements is outside the scope of the EBA’s remit, even if it were able to anticipate them. While we act here only in the capacity of a business professional (and not a legal adviser or interpreter), Accenture believe that these RTS should be defined such that the market itself, either through competition or collaboration, can build and operate additional components that are reliant on the EBA register to operate. For example, Accenture has responded to a RFP in a Member State to build a local register and identity access management for the local banks. This solution will interact with the EBA Registry and will be dependent on information in it, but the requirements for it are defined by the need of the local banks. Accenture expects similar solutions to be built in different Member States, all dependent on the EBA Registry.
For this to be achievable, it would be critical that the EBA register is kept up to date in real-time, 24/7 with the NCA registers that feed it, and is “machine-readable” through real-time, 24/7 standardised APIs by any market participant that needs to use it. With this capability, the EBA register is the “source of truth” for the market that is always up-to-date, ensuring integrity and trust in the market. Without 24/7, real-time updates, there will always be a delay in updating the market with the “source of truth”, in effect, a built-in weakness which can be exploited by fraudsters and cybercriminals, with potentially dire consequences. The cost of these consequences, in terms of financial loss, market uncertainty and consumer mistrust can potentially far outweigh the additional cost of making the register “machine readable”. Security breaches where fraudsters exploit weaknesses in cyber defences are unfortunately common – for example, the recent Equifax breach which has potentially affected 143 million consumers in the USA and 44 million in the UK.
Our answers to this consultation (limited to our experience as a business professional only) are made in this context, and in particular we recommend (in question 2) the EBA reconsiders its decision explained in paras 21 and 22 to reject the suggestion to make the register “machine-readable”.


Q1. Do you agree with the option the EBA has chosen regarding the transmission of information by NCAs to the EBA? If not, please provide your reasoning.

The selected option, one, includes a complete transmission of the entire dataset from the NCAs to the EBA Register. Given that a modification of the NCA registers are not likely to take place very frequently, option could be taken into consideration. The technical data transmission mechanism should be built in a way that a syntax and high-level business logic validation can be performed by the EBA Register – and the NCA is informed in a timely way by the EBA Register about errors (through an error log). In addition, the EBA Register should create a history log for all changes to each PSP listed.
DISCLAIMER: Because Accenture is not authorized to act as a legal adviser or interpret laws and regulations, Accenture may not confirm any of the legal interpretation made by EBA in the Consultation Paper. The responses below assume that the EBA’s interpretations are correct and provide comments solely related to accommodating such interpretations through technical and business means.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The proposed list of search criteria depicts the minimum requirements for the search functionality. But the list may not provide all parameters required – such as PSP license validity duration or an expiration date. In our experience, ASPSPs would want to use the EBA register list data for their own TPP access rights management needs (as an additional validation check). Qualified Trust Service Providers (TSPs) should also be able to use the EBA Register as a golden source with relevant information of all authorised TPPs to whom they will be requested to issue Qualified Certificates for Electronic Seals.

Hence ASPSP and Trust Service Providers should be able to download the full list via a system-to-system interface in real-time and in an automated way, for example using an API, rather than a manual process which could become inefficient due to possible manual procedure errors, for example loading an old version of a data file or incomplete copy. ASPSPs might require a search function via the interface in order to retrieve a subset of the EBA register list. In addition, it is even more important to make sure that the ITS include fields that are required by TSPs and ASPSPs for their plausibility and security checks, for example a parent company, or group field to help identify third parties who may be subsidiaries or affiliates of others

The “machine readable” functionality that is considered undesirable, is in fact essential in today’s digital environment, where connectivity and automation pervade business processes and communication. For example, if a NCA revokes the authorised status of a TPP, this can be transmitted immediately to the register and picked up immediately by users of the register, allowing them
DISCLAIMER: Because Accenture is not authorized to act as a legal adviser or interpret laws and regulations, Accenture may not confirm any of the legal interpretation made by EBA in the Consultation Paper. The responses below assume that the EBA’s interpretations are correct and provide comments solely related to accommodating such interpretations through technical and business means.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The proposed non-functional requirements provide a high-level overview and, from the business perspective, could be considered as a good initial baseline for a more detailed specification. The specification should be split in, at least, three categories: operation, security and performance requirements.

In order to size the EBA Register non-functional requirements and build a resilient system, a valid and realistic quantity structure of the usage need to be defined (expected download numbers and modification requests). The EBA Register and its data should be available 24/7 and in real-time to ASPSP, TPPs and private end consumers. Any interruption on the service should be reportable through a known and efficient channel to the EBA Register.

From Accenture’s point of view, it is not sufficient to just make sure that the EBA Register data is safely stored and backed-up. In line with normal security practice, the data should also be protected from unauthorised manipulations performed by external and internal actors. In addition, the EBA Register should be designed from a cyber security perspective, both to prevent malicious corruption of the data held on the register, and to inform all market participants if a PSP is flagged, for example, as fraudulent.
DISCLAIMER: Because Accenture is not authorized to act as a legal adviser or interpret laws and regulations, Accenture may not confirm any of the legal interpretation made by EBA in the Consultation Paper. The responses below assume that the EBA’s interpretations are correct and provide comments solely related to accommodating such interpretations through technical and business means.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

While legal interpretation of PSD is not within our mandate, we understand that one of the major aims of PSD2 and the RTS on SCC and CSC is to facilitate all market stakeholders with a cost-saving and efficient infrastructure.

As in the answer for Question 2, ASPSPs would likely want to use the EBA register perform additional TPP permission checks. Qualified Trust Service Providers (TSP) should also be able to use the EBA Register to know whom they will be requested to issue Qualified Certificates for Electronic Seals.

We see the EBA Register as the centre of all relevant information required to make an efficient digital payments ecosystem possible. Therefore, credit institutions acting as an AISP or PISP should be ideally included in the EBA Register as well – otherwise there is too much complexity in the overall system. For example, an ASPSP using the register to check the validity of an AISP, which happens to be a credit institution, may not know it is a credit institution, and therefore conclude the requesting AISP is invalid (it could check a NCA register, but it would not know which one to check without checking all of them).

The EBA should ideally build and maintain one comprehensive single listing of all participants to support operation of ASPSPs within the PSD2 scope.
DISCLAIMER: Because Accenture is not authorized to act as a legal adviser or interpret laws and regulations, Accenture may not confirm any of the legal interpretation made by EBA in the Consultation Paper. The responses below assume that the EBA’s interpretations are correct and provide comments solely related to accommodating such interpretations through technical and business means.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

While legal interpretation of PSD or other relevant EU regulations is not within our mandate, in order to enable a cheaper and more efficient implementation, we recommend strongly a standardized data format. But the EBA proposed minimum mandatory set of fields might not be sufficient to distinguish between especially large PSPs with subsidiaries – assuming this is legally acceptable, we suggest a Group ID is introduced which links separate entries for separate subsidiaries of the same PSP (the Group Id is the same as the PSP Id where there is only one entity). All relevant stakeholders such as PSPs, ASPSPs and NCAs need to be involved to define a standard that includes sufficient information for all to operate effectively.

Accenture also recommend that the data fields in Annex 1 are compatible with the ISO20022 data dictionary to facilitate interoperability and compatibility with modern financial systems. ISO20022 is a recognized format standard which is more and more in use internationally for financial messaging.
DISCLAIMER: Because Accenture is not authorized to act as a legal adviser or interpret laws and regulations, Accenture may not confirm any of the legal interpretation made by EBA in the Consultation Paper. The responses below assume that the EBA’s interpretations are correct and provide comments solely related to accommodating such interpretations through technical and business means.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The business/market expectation is for the EBA Register to be a utility that creates transparency and confidence in the new PSD2 era. It will be open for PSP customers as well and should, if permitted by law, include additional contact details in the case of dispute and fraud to create customer confidence. In this regard, the EBA should include immediate enquiry contact details of a monitored phone and email address – for ASPSP contacts and dispute resolutions. These two fields should be standardised (phone format, and email format).
DISCLAIMER: Because Accenture is not authorized to act as a legal adviser or interpret laws and regulations, Accenture may not confirm any of the legal interpretation made by EBA in the Consultation Paper. The responses below assume that the EBA’s interpretations are correct and provide comments solely related to accommodating such interpretations through technical and business means.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Assuming that EBA’s interpretation of PSD is accurate, it would certainly be a wise market choice for the EBA Register to be the central repository for all PSP across the EU. However, it would be also useful for ASPSPs and PSP customers to explicitly identify PSP that are not under PSD2 scope (similar to a blacklist). An additional “blacklist” could help to be aware of PSP that do not meet PSD2-requirements on strong customer authentication and liability. For example, this may be possible where third parties use screen-scraping to access ASPSP accounts without registering as an AISP or PISP (irrespective of the eventual text of the EBA RTS on Strong Customer Authentication and Secure Communication, which may, or may not, outlaw screen-scraping).
DISCLAIMER: Because Accenture is not authorized to act as a legal adviser or interpret laws and regulations, Accenture may not confirm any of the legal interpretation made by EBA in the Consultation Paper. The responses below assume that the EBA’s interpretations are correct and provide comments solely related to accommodating such interpretations through technical and business means.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Similarly to the previous questions, because Accenture is not authorized to make legal interpretation, we may not be able to confirm EBA’s interpretation that agents of payment institutions, exempted payment institutions, account information service providers, electronic money institutions and exempted electronic money institutions should be included in the EBA Register. However, assuming this is the correct interpretation, there might be an issue of gaps in accuracy due to NCAs collecting agency services types differently and in many cases not accurately. This may create a gap in accuracy. However, Accenture has helped define use cases with our clients where third parties act on behalf of other third parties as agents, so the inclusion of agents in the register is logical.
[IT services provider "]"
Management Consulting
Hakan Eroglu
+41 79 278 90 49