- Question ID
-
2024_7003
- Legal act
- Directive 2015/2366/EU (PSD2)
- Topic
- Strong customer authentication and common and secure communication (incl. access)
- Article
-
66
- Paragraph
-
4
- Subparagraph
-
(c)
- COM Delegated or Implementing Acts/RTS/ITS/GLs/Recommendations
- Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication
- Article/Paragraph
-
Article 32, number 3.
- Name of institution / submitter
-
Financial Supervisory Authority of Norway
- Country of incorporation / residence
-
Norway
- Type of submitter
-
Competent authority
- Subject matter
-
Third party access to account attributes
- Question
-
In Norway there is a widely used scheme by which payees send out invoices containing structured payment information which is being used by the payee to match incoming payments with invoices. The information is in the form of a number defined by the payee. The number consists of up to 25 digits, including a control digit. The information flows all the way through the payment chain and back to the payee. The credit account number must be set up with attributes associated with it, according to scheme rules, which are defined jointly by the banks. The payee has to enter into an agreement with its bank in order to make use of the scheme. There is a nationwide registry covering all banks, containing information about agreements, accounts and attributes associated with each account.
The banks have direct access to the registry. As and when the PSU (Payment Service User) keys in the invoice information, the bank checks in real time that what is being keyed in is correct according to information held in the registry. There is check that indeed the credit account is set up for the scheme. A control digit is checked, increasing the likelihood of a correct number being entered. If no number is keyed in, the PSU is told so, if the account is such that a number is required. While keypunching, the PSU is being informed there and then if the information is wrong such that the PSU may correct it. The bank will not accept the payment order unless it is pre-verified to pass the controls.
Not so for TPPs (Third Party Provider). They are not granted access to the registry. The TPP does not know if the payment order will pass the controls. Not until payment initiation there is a check. This check is being performed by the bank, not by the third party. The TPP receives information from the bank about the outcome of the check. TPPs must revert back to the PSU and / or the payee, or the banks, and try to resolve any issues. There are costs associated with follow up and correction.
PSD2 Article 66 number 4 letter (c) obliges ASPSPs to treat payment orders transmitted through the services of a payment initiation service provider without any discrimination other than for objective reasons, in particular in terms of timing, priority or charges vis-à-vis payment orders transmitted directly by the payer. Not having access to the registry puts the TPPs at a disadvantage, with a bearing on timing, as payments may be delayed and may become overdue. The banks' own payment services have direct access to the key payment information held in the registry, whereas third party payment services do not. The FSA of Norway seeks advice on whether this constitutes a discrimination according to PSD2 Article 66.
Not having access to the registry puts the TPPs at a disadvantage. It leads to extra work for TPPs and others involved in the payment. Additional costs are being incurred. The FSA of Norway seeks advice on whether not giving TPPs access to the registry creates obstacles for TPPs as per Commission delegated regulation (EU) 2018/389 Article 32 number 3.
Lastly, the FSA of Norway seeks advice on whether there are other relevant provisions in the regulation, and whether the principle of "level playing field" may apply in this case.
- Background on the question
-
TPPs have for quite some time been addressing us as a competent authority stating that they do not to have access to account attribute information the same way the banks do, giving rise to transactions not going through. Due to comparatively low volumes, TPPs have found the time and effort, on a case-by-case basis, to revert back to one or more of PSU, payee and bank, sort the problem, and correct the payment, so eventually it is being executed. Volumes are picking up, and the this process is no longer a viable one. It is of some urgency for them to get access to account attributes in order to reduce the number of refuted payments.
- Submission date
- Rejected publishing date
-
- Rationale for rejection
-
This question has been rejected because to ensure the effectiveness of the Q&A process it focuses on answering questions that are likely to be relevant to a broad set of stakeholders – for example, a large number, broad range or wide geographical distribution – rather than questions which address circumstances which appear likely to be relevant only to the particular circumstances of certain stakeholders or transactions.
For further information on the purpose of this tool and on how to submit questions, please see “Additional background and guidance for asking questions”.
- Status
-
Rejected question