> 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.md).

# Standards and Compliance

PSD2 and the Berlin Group standard, the UK Open Banking Standard, adaptation to national profiles, PCI DSS card data handling, and GDPR.

PSD2 and the UK Open Banking Standard each define what the interface must do in their own market. National profiles then vary both. PCI DSS governs card data wherever it appears, and GDPR governs the personal data the platform holds on the institution's behalf.

|                                                                                    |                                                                                                                                                                                              |
| ---------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [PSD2](/standards-and-compliance/psd2.md)                                          | The directive's obligations, the Berlin Group NextGenPSD2 framework the platform implements, services, strong customer authentication, eIDAS certificates, versioning and fallback exemption |
| [UK Open Banking Standard (OBL)](/standards-and-compliance/uk-open-banking-obl.md) | The three APIs supported, how the UK security profile differs from the EU one, and the full MI reporting the UK regulator requires                                                           |
| [National Profiles](/standards-and-compliance/national-profiles.md)                | How each market's own reading of the standard is accommodated — additional fields, local deviations, national payment products and regulator-specific thresholds                             |
| [PCI DSS](/standards-and-compliance/pci-dss.md)                                    | Protection of card data in transit and at rest, the masking mechanism, what is never stored, and the PCI Software Security Framework                                                         |
| [GDPR](/standards-and-compliance/gdpr.md)                                          | What personal data exists and what deliberately does not, consent as a stored object, retention, erasure, access control and residency                                                       |

## The short version

* **PSD2** compliance is delivered through the **Berlin Group NextGenPSD2 XS2A Framework** — implementation guidelines V1.3.12 and version 2.0 — plus **openFinance by Berlin Group**.
* **The UK** is served by the **Open Banking Limited** standard, currently v4.0.1: the Account and Transaction, Payment Initiation and Confirmation of Funds APIs, the FAPI security profile with detached JWS signatures, and the complete MI reporting set the CMA and FCA require.
* **National profiles** are treated as the norm rather than the exception. The regulator's own specification is what gets published, and local fields, thresholds, payment products and signing requirements are configuration rather than development.
* **Third-party identity** rests on eIDAS QWAC and QSealC certificates in the EU and OBL-issued certificates in the UK, validated for trust, ownership and expiry on every call, with revocation re-checked continuously and roles cross-checked against the national register.
* **Card data** is protected by TLS in transit and masked at rest, and sensitive authentication data — full track data, verification values and PIN blocks — is never stored in any form.
* **Personal data** is minimized by design: the platform never holds customers' banking credentials, masks sensitive fields before writing them, retains records per type rather than globally, and anonymizes the audit trail on erasure so a deletion request can be honored without destroying required history.
* Development and operation follow **ISO 27001 and 27002**, **OWASP** practices and the **PCI Software Security Framework**, with role-based least-privilege access, mandatory two-factor authentication and four-eyes approval on consequential change.

Because the market profile is applied per API product rather than baked into the platform, one installation can serve several regulatory regimes at once — which is what makes a single deployment viable for a group operating across the UK, the EU and beyond.


---

# 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.md?ask=<question>&goal=<user_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.