--- title: "EBA Q&A 2024_7003 — Q&A — Third party access to account attributes [Rejected question]" shortTitle: "EBA Q&A 2024_7003 — Q&A — Third party access to account attributes [Rejected question]" answer_id: EBA_QA_2024_7003 status: "Rejected question" type: qa instrument_type: qa authority: EBA binding: false binding_character: non_binding legal_status: withdrawn regulation: "PSD2" psd2_level3: true mica_level2: false legal_basis: "Article 66(4) PSD2" date: 30 July 2024 source_link: https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2024_7003 lifecycle: "Rejected question" text_version: "EBA Q&A register, 30 July 2024" source_url: "https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2024_7003" check_status: matched verified: true last_checked: 2026-10-26 checked_against: "the EBA publication" source: prepared_by: "not stated in the document" published_by: "EBA" published_in: "EBA Single Rulebook Q&A tool" evidence: prepared_by: "Competent authority" locator: "EBA Q&A register entry 2024_7003: no answer; the register names only the 'Type of submitter'" document_type: "qa_question" legal_nature: "not_legislation" addressees: "not stated in the document" dates: published_on: "2024-07-30" question_submitted_on: "2024-02-12" locators: published_on: "EBA Q&A register entry 2024_7003, field 'Rejected publishing date'" question_submitted_on: "EBA Q&A register entry 2024_7003, field 'Submission date'" lifecycle_label: "Rejected question" --- **Question published in the EBA Q&A tool · no answer · not legislation · published 30 Jul 2024 [Rejected question]** *Rejected question · EBA Q&A register, 30 July 2024 · Checked against the EBA publication on 26 Oct 2026 · [Official source](https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2024_7003)* | | | |---|---| | **Full title** | EBA Q&A 2024_7003 — Q&A — Third party access to account attributes \[Rejected question\] | | **Prepared by** | Not stated in the document | | **Published by** | EBA, in the EBA Single Rulebook Q&A tool | | **Reference** | EBA_QA_2024_7003 | | **Document type** | Q&A | | **Legal nature** | No answer · not legislation | | **Addressees** | Not stated in the document | | **Dates** | Published 30 July 2024; question submitted 12 February 2024 | | **Legal basis** | Article 66(4) PSD2 | | **Related instruments** | None recorded | | **Text on this page** | Word for word — the full text of the EBA publication | **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 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. *** ### Answer 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”. *** **Source:** [EBA original document](https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2024_7003) ## Related Level 1 articles - [Article 66 — Rules on access to payment account in the case of payment initiation services](../../../articles/66.md)