--- title: "EBA Q&A 2023_6753 — Q&A — Eligibility of communication by AISPs with ASPSP [Rejected question]" shortTitle: "EBA Q&A 2023_6753 — Q&A — Eligibility of communication by AISPs with ASPSP [Rejected question]" answer_id: EBA_QA_2023_6753 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 98(1) PSD2" date: 10 July 2023 source_link: https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2023_6753 lifecycle: "Rejected question" text_version: "EBA Q&A register, 10 July 2023" source_url: "https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2023_6753" 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: "Law firm" locator: "EBA Q&A register entry 2023_6753: 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: "2023-07-10" question_submitted_on: "2023-03-16" locators: published_on: "EBA Q&A register entry 2023_6753, field 'Rejected publishing date'" question_submitted_on: "EBA Q&A register entry 2023_6753, field 'Submission date'" lifecycle_label: "Rejected question" --- **Question published in the EBA Q&A tool · no answer · not legislation · published 10 Jul 2023 [Rejected question]** *Rejected question · EBA Q&A register, 10 July 2023 · Checked against the EBA publication on 26 Oct 2026 · [Official source](https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2023_6753)* | | | |---|---| | **Full title** | EBA Q&A 2023_6753 — Q&A — Eligibility of communication by AISPs with ASPSP \[Rejected question\] | | **Prepared by** | Not stated in the document | | **Published by** | EBA, in the EBA Single Rulebook Q&A tool | | **Reference** | EBA_QA_2023_6753 | | **Document type** | Q&A | | **Legal nature** | No answer · not legislation | | **Addressees** | Not stated in the document | | **Dates** | Published 10 July 2023; question submitted 16 March 2023 | | **Legal basis** | Article 98(1) PSD2 | | **Related instruments** | None recorded | | **Text on this page** | Word for word — the full text of the EBA publication | **Eligibility of communication by AISPs with ASPSP throughout interface used for authentication and communication with the ASPSP's payment services users in case of ASPSP’s exemption from the fall back mechanism** ### Question Question no 1: Does a fact, that based on art. 33(6) RTS, given ASPSP was granted by competent authority with exclusion from the obligation to set up the contingency mechanism described under art. 33(4) RTS, means, that such exemption merely gives this ASPSP a right not to set up the contingency mechanism, and hence, this is up to ASPSP to enjoy and to follow this exclusion, or whether, in opposition, this exemption creates on ASPSP side obligation to bring this exclusion to life. Question no 2: Does a fact, that given ASPSP was granted by competent authority with exclusion from the obligation to set up the contingency mechanism described under art. 33(4) RTS, creates on AISP’s end any kind of obligation, for instance lack of right to communicate with ASPSP in question throughout interface made available to the payment service users for the authentication and communication with their ASPSPs. ### Background Art. 33(6) RTS provides grounds for competent authorities to exempt given ASPSP, that has opted for a dedicated access interface, from the obligation to set up the contingency mechanism under art. 33(1) RTS. However, under RTS, it is not clear, whether granting of exemption under art. 33(6) RTS merely gives ASPSP a right not to set up the contingency mechanism, and hence, this is up to ASPSP to enjoy and to follow this exclusion, or whether, in opposition, this exemption creates on ASPSP side obligation to bring this exclusion to life. It happens, that in above depicted scenario, given ASPSP, being granted with exemption from the obligation to set up the contingency mechanism under art. 33(1) RTS (information of which being derived from generally accessible sources of information, i.e. Internet), nevertheless makes available to AISPs two access interfaces within a meaning of art. 31 RTS, i.e. (i) dedicated interface and (ii) interface used for authentication and communication with the ASPSP's payment services users. Therefore, in lack of relevant RTS provision, question arises, whether in above scenario, any kind of obligation arise on AISPs’ side, for instance lack of possibility to communicate with ASPSP in question throughout interface made available to the payment service users for the authentication and communication with their ASPSPs, especially in situation, where nevertheless, ASPSP allows AISPs for communication throughout this access interface. Above depicted unclarity brings further uncertainty to AISPs acting in given EU member states. In some jurisdictions exemption from the obligation to set up the contingency mechanism under art. 33(1) RTS is being granted in form of an individual, administrative decision addressed directly to ASPSP and there is no public register, based on which third parties, including AISPs, might verified, whether given ASPSP was in fact given with exemption to set up the contingency mechanism. Source of this information (knowledge) predominanlty comes from generally accessible sources of information, i.e. Internet. As a consequence, in lack of public register, AISPs does not possess certain, firm knowledge of exemption being granted to ASPSP. *** ### Answer This question has been rejected because the matter it refers to is in the process of being answered in Q&A 6752. *** **Source:** [EBA original document](https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2023_6753) ## Related Level 1 articles - [Article 98 — Regulatory technical standards on authentication and communication](../../../articles/98.md)