<!-- headlesslaw {"release":{"id":"a4f2a0495fe55b47323883f82977a9b34ab66171ec9623e39925d3a7045b6c81","published":"2026-11-01T16:41:30Z","pinned":false},"limits":{"coverage":{"history":"current_only","held_since":"2022-04-13","gaps":[],"covered":["EBA Q&A 2021_6245 — Q&A — ASPSP restricting access for TPPs who embeds the redirect [Final Q&A] L3"],"not_covered":["national guidance","court decisions"]},"freshness":{"release_id":"a4f2a0495fe55b47323883f82977a9b34ab66171ec9623e39925d3a7045b6c81","release_published":"2026-11-01T16:41:30Z","checked_at":"2026-10-26","checked_against":"the EBA publication"},"truncation":null,"failures":[],"incomplete":[]},"page":{"path":"/psd2/level-3/q-and-a/eba/eba-qa-2021-6245-aspsp-restricting-access-for-tpps-who-embeds-the-redirect","url":"https://www.headlesslaw.com/psd2/level-3/q-and-a/eba/eba-qa-2021-6245-aspsp-restricting-access-for-tpps-who-embeds-the-redirect","title":"EBA Q&A 2021_6245 — Q&A — ASPSP restricting access for TPPs who embeds the redirect [Final Q&A]","family":"l3","work_id":"spaces/psd2/level-3/q-and-a/eba/eba-qa-2021-6245-aspsp-restricting-access-for-tpps-who-embeds-the-redirect","status":"final q&a","force_status":null,"date_state":"current","requested_date":null,"as_of":"2026-11-01","applies_from":null,"application":null,"version_label":"EBA Q&A register, 13 April 2022","check":{"against":"the EBA publication","on":"2026-10-26"},"check_result":"matched","official_url":"https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2021_6245","valid_from":"0001-01-01","valid_until":null,"revision":1,"content_id":"8a6309cb82afdd81","change_date":null,"nearest_versions":["2022-04-13"],"first_text_date":null,"correction_applies":false,"versions":["2022-04-13"],"version_url":"https://www.headlesslaw.com/psd2/level-3/q-and-a/eba/eba-qa-2021-6245-aspsp-restricting-access-for-tpps-who-embeds-the-redirect/versions/2022-04-13","revision_url":"https://www.headlesslaw.com/psd2/level-3/q-and-a/eba/eba-qa-2021-6245-aspsp-restricting-access-for-tpps-who-embeds-the-redirect/versions/2022-04-13/rev/8a6309cb82afdd81","versions_url":"https://www.headlesslaw.com/psd2/level-3/q-and-a/eba/eba-qa-2021-6245-aspsp-restricting-access-for-tpps-who-embeds-the-redirect/versions","relations_url":"https://www.headlesslaw.com/psd2/level-3/q-and-a/eba/eba-qa-2021-6245-aspsp-restricting-access-for-tpps-who-embeds-the-redirect/relations","source_line":"Answer by the EBA, published in its Q&A tool · not legislation · published 13 Apr 2022 [Final Q&A]","attribution":{"prepared_by":"EBA","published_by":"EBA","published_in":"EBA Single Rulebook Q&A tool","document_type":"qa_answer","legal_nature":"not_legislation","addressees":"not stated in the document","dates":{"published_on":"2022-04-13","question_submitted_on":"2021-10-19","locators":{"published_on":"EBA Q&A register entry 2021_6245, field 'Final publishing date'","question_submitted_on":"EBA Q&A register entry 2021_6245, field 'Submission date'"}},"adoption":null}}} -->
---
title: "EBA Q&A 2021_6245 — Q&A — ASPSP restricting access for TPPs who embeds the redirect [Final Q&A]"
shortTitle: "EBA Q&A 2021_6245 — Q&A — ASPSP restricting access for TPPs who embeds the redirect [Final Q&A]"
answer_id: EBA_QA_2021_6245
status: "Final Q&A"
type: qa
instrument_type: qa
authority: EBA
binding: false
binding_character: non_binding
legal_status: in_force
regulation: "PSD2"
psd2_level3: true
mica_level2: false
legal_basis: "Article 68(5) PSD2"
date: 13 April 2022
source_link: https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2021_6245
lifecycle: "Final Q&A"
text_version: "EBA Q&A register, 13 April 2022"
source_url: "https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2021_6245"
check_status: matched
verified: true
last_checked: 2026-10-26
checked_against: "the EBA publication"
source:
  prepared_by: "EBA"
  published_by: "EBA"
  published_in: "EBA Single Rulebook Q&A tool"
  evidence:
    prepared_by: "Answer prepared by the EBA."
    locator: "EBA Q&A register entry 2021_6245, field 'Answer prepared by'"
document_type: "qa_answer"
legal_nature: "not_legislation"
addressees: "not stated in the document"
dates:
  published_on: "2022-04-13"
  question_submitted_on: "2021-10-19"
  locators:
    published_on: "EBA Q&A register entry 2021_6245, field 'Final publishing date'"
    question_submitted_on: "EBA Q&A register entry 2021_6245, field 'Submission date'"
lifecycle_label: "Final Q&A"
---

**Answer by the EBA, published in its Q&A tool · not legislation · published 13 Apr 2022 [Final Q&A]**

*Final Q&A · EBA Q&A register, 13 April 2022 · Checked against the EBA publication on 26 Oct 2026 · [Official source](https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2021_6245)*

| | |
|---|---|
| **Full title** | EBA Q&A 2021_6245 — Q&A — ASPSP restricting access for TPPs who embeds the redirect \[Final Q&A\] |
| **Prepared by** | EBA |
| **Published by** | EBA, in the EBA Single Rulebook Q&A tool |
| **Reference** | EBA_QA_2021_6245 |
| **Document type** | Q&A |
| **Legal nature** | Not legislation |
| **Addressees** | Not stated in the document |
| **Dates** | Published 13 April 2022; question submitted 19 October 2021 |
| **Legal basis** | Article 68(5) PSD2 |
| **Related instruments** | None recorded |
| **Text on this page** | Word for word — the full text of the EBA publication |

**ASPSP restricting access for TPPs who embeds the redirect**

### Question

Do Account Servicing Payment Service Providers (ASPSPs) have the right to block access to payment accounts for a Third Party Provider (TPP) who embeds the ASPSP-provided redirection website in order to provide the Payment Service User (PSU) with a TPP-provided user interface?

### Background

According to Article 68(5) PSD2, an ASPSP may only deny TPPs access for objectively and duly evidenced reasons related to unauthorised or fraudulent access, including fraudulent initiation of payment transactions. It has however happened that ASPSPs have contacted TPPs to say that they will restrict access to the PSD2 Application Programming Interface (API) because the TPP embeds the redirection domain provided by the ASPSP for PSUs to enter their credentials when using the services of a TPP. The stated reason is that the PSU in this instance does not enter its credentials into the ASPSP-hosted redirection domain but into an interface provided by the TPP.

If the ASPSP offers a redirection-only API, the TPP can improve the user journey by embedding the redirection domain and provide the user with a TPP-provided user interface (instead of requiring the user to enter the credentials into the redirection domain). This allows the TPP to e.g. provide a user interface in different languages, different font sizes and/or adapted to different devices/technology environments. As an example, a web-based redirection domain would not work in environments that are not web-browser based, such as e.g. gas stations, smart watches, Point of Sale terminals, internet of things, AI and voice assistants, etc. whereas the TPP would be able to provide user interfaces adapted for such environments by means of embedding the redirection domain.

Articles 45 and 46 PSD2 specify which information the TPP needs to provide to the PSU when providing such user interfaces and the transmission of security credentials needs to be done in a secure manner with encryption applied using RTS compliant techniques. To be clear, embedding the redirection domain is not “screen scraping” as the TPP identifies itself vis-a-vis the ASPSP (and leverages the PSD2 API); it only means the TPP can adapt and improve the user interface and as such convenience for the PSU.

The ASPSP does not need to do anything to enable embedded redirection; the work is solely at the side of the TPP. Alternatively, the ASPSP can of course as a part of its PSD2 API actively enable an embedded flow, which would mean the TPP would not have to embed the redirection domain itself. But the ASPSP must not block or otherwise make it difficult for the TPP if the TPP elects to build its own PSU-facing interface and transmit the credentials to the redirection domain of the ASPSP as TPPs may transmit credentials pursuant to Article 66(3)(b) PSD2.

***

### Answer

Article 68(5) PSD2 provides that an account servicing payment service provider (ASPSP) may deny an account information service provider (AISP) or a payment initiation service provider (PISP) access to a payment account for objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access to the payment account.

Q&A 6044 clarified that:

In accordance with Article 30(3) of the Commission Delegated Regulation (EU) 2018/389, PISPs and AISPs should follow the technical specifications set out by the ASPSP when accessing the ASPSP’s interface.

Where the ASPSP has opted for a redirection or a decoupled approach and does not allow in its documentation the possibility for the PISP/AISP to transmit the payment service user (PSU)’s credentials to the ASPSP, the PISP/AISP should redirect the PSU to the ASPSP’s domain to authenticate and should not introduce an approach for sending the PSU’s personalised security credentials to the ASPSP that is different to the approach envisaged by the ASPSP in the technical specifications of the interface. Such latter approach would not be in line with the requirements of Article 30(3) of the Delegated Regulation.

It follows from the above that the approach described by the submitter, where the PISP/AISP “embeds” the ASPSP’s redirection domain, would not be in line with Article 30(3) of the Delegated Regulation.

In addition, such an approach may lead to a situation where the ASPSP identifies, based on its transaction monitoring mechanisms under Article 2 of the Delegated Regulation, that it is not the PSU who is trying to access the account and subsequently denies access to the payment account. In such case, the denial of access to the account would be in line with Article 68(5) PSD2.

***

**Source:** [EBA original document](https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2021_6245)

## Related Level 1 articles

- [Article 68 — Limits of the use of the payment instrument and of the access to payment accounts by payment service providers](../../../articles/68.md)