> For the complete documentation index, see [llms.txt](https://doc.api.tieto.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.api.tieto.com/standards-and-compliance/psd2.md). # PSD2/PSD3 Full PSD2 compliance on the Berlin Group XS2A standard, with the regulatory services already being prepared for PSD3 and the PSR. The second Payment Services Directive obliges account servicing payment service providers to let licensed third parties reach payment accounts on a customer's instruction. The platform's regulatory API products discharge that obligation for every bank you serve — published, operated and measured by you, on their behalf. ## Compliant today | Obligation | Answered by | | -------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | A dedicated interface for third-party access | Published, versioned regulatory API products served through the API Gateway | | Strong customer authentication | SCA orchestrated against each bank's own authentication server, in every approach the standard defines | | Identification of the third party | eIDAS certificate validation on every call, checked against the national register of authorized providers | | Secure communication | TLS 1.2 or higher, with message-level signatures where the operation requires them | | Publication of availability and performance | Daily per-bank metrics to the European Banking Authority definitions, published on the Developer Portal | | A fallback interface, or exemption from one | Deployed to Tieto's recommendations, the platform supports exemption from the fallback mechanism | ## Built on the Berlin Group standard The platform implements the **NextGenPSD2 XS2A Framework** as published, and that is a commercial decision as much as a regulatory one: a third party already integrated with a Berlin Group interface anywhere in Europe can integrate with this one, using request shapes, field names and error structures it has seen before. ISO 20022 data types, consent semantics and the signature profile arrive with the standard rather than being invented alongside it. Where a regulator publishes its own national profile, that profile is what the platform serves. Several versions run at once, each announced ahead of release and kept available after deprecation, so no third party is forced to migrate the day a new version appears. ## Services | Service | Scope | | ----------------------------- | --------------------------------------------------------------------------------------------------- | | Account Information | Accounts and details, balances, transaction history, and card accounts where the bank supports them | | Payment Initiation | Single, bulk and multi-bulk payments, future-dated and recurring payments, status and cancellation | | Funds Confirmation | Confirmation that funds are available on an account | | List of Trusted Beneficiaries | The trusted beneficiaries service defined by the standard | Available payment types follow what the local scheme and the individual bank support, including domestic payment type codes and cross-border payments in foreign currency. Authentication covers every approach the standard defines — redirect, decoupled, embedded, multi-level and channel-based, plus the exemptions the regulation permits — because banks differ in how they authenticate, and a platform that handled only redirect would exclude most of them. ## Ready for PSD3 and the PSR PSD2 is being replaced by two instruments: **PSD3**, a directive covering licensing and prudential rules, and the **Payment Services Regulation (PSR)**, directly applicable and carrying the conduct rules — interfaces, authentication, fraud and liability. The move from a directive to a regulation matters to an operator. PSD2 was transposed twenty-seven times and read twenty-seven ways, which is why national profiles exist at all. Conduct rules in a regulation apply as written in every member state, so the surface your tenants are measured against converges rather than diverges. {% hint style="info" %} The package reached political agreement in November 2025 and is moving through formal adoption, with the conduct rules expected to apply around late 2027. Details in the final text and in the technical standards beneath it can still move; the platform tracks them as they land. {% endhint %} The platform's regulatory services are being prepared for it now. The headline changes — the dedicated interface as the access route rather than one of two, firmer performance and availability standards with quarterly publication, a customer-facing permission dashboard, advance notice of interface changes, a supported testing facility, and authentication only on a provider's first access to account data — land on foundations that already exist here: a published versioned API per tenant, per-bank measurement to the European Banking Authority definitions, a complete consent record, a sandbox, and a release process with announcement windows. That is the argument worth making to a prospective tenant while the text settles. The cost of PSD3 and the PSR is paid once, by the operator, and amortized across every bank on the platform: a bank here inherits readiness, a bank running its own interface inherits a project. ## Open finance is next Alongside the payments package sits the **Financial Data Access Regulation (FIDA)**, which extends the same access model past payment accounts into savings, loans, investments, pensions and insurance — on commercial terms rather than free of charge. That is already the shape of what this platform publishes: the Extended Account Information Service reads cards, savings, loan and securities accounts, and premium products carry tariffs, limits and agreement management. The regulated version of open finance arrives as more of what is already here. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://doc.api.tieto.com/standards-and-compliance/psd2.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.