> 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/open-banking-platform/faq.md).

# FAQ

<details>

<summary>Do I need eIDAS certificates to start testing?</summary>

No. Registration on the Developer Portal grants sandbox access immediately. Sandbox applications do not require certificates, and test regulatory certificates can be downloaded from the portal. Live certificates — QWAC and QSealC in the EU, OBL-issued in the UK — are required only for production access.

</details>

<details>

<summary>Which regulatory services are available?</summary>

Account Information Service, Payment Initiation Service and Funds Confirmation Service, together with a List of Trusted Beneficiaries service. Payment types, bulk payments and future-dated payments depend on what the individual institution supports.

</details>

<details>

<summary>Which standards does the platform implement?</summary>

In the EU, the Berlin Group NextGenPSD2 XS2A Framework — implementation guidelines V1.3.12 and version 2.0 — plus openFinance by Berlin Group. In the UK, the Open Banking Standard published by Open Banking Limited, currently v4.0.1.

Across both, element names and types follow ISO 20022 and responses use HAL hypermedia. Identification relies on eIDAS QWAC and QSealC certificates in the EU, and on OBL-issued certificates against the OBL Trust Anchor in the UK.

</details>

<details>

<summary>Do you support the UK Open Banking Standard as well as PSD2?</summary>

Yes. The Account and Transaction API, Payment Initiation API and Confirmation of Funds API are supported at v4.0.1, with the FAPI security profile, detached JWS signatures over an unencoded payload using PS256, the `x-fapi-*` headers and `x-idempotency-key` on payment submission.

Both regimes run on one installation, with the market profile applied per API product — so a group operating in the UK and the EU does not need two platforms or two operations teams. Variable Recurring Payments and the Event Notification API are part of the OBL standard but are not in the current scope.

</details>

<details>

<summary>Can you accommodate our regulator's own profile of the standard?</summary>

Yes, and this is the normal case rather than the exception. The regulator's own specification is what gets published: you upload it, and the platform adapts it to its URL, versioning and security conventions rather than asking you to fit ours.

Additional fields, local interpretations, national payment products and local identifiers arrive with the specification. Consent validity periods, frequency caps, transaction history windows and error message text are configured per market and per institution and take effect without a release. Where the mapping to an institution's back office is not one-to-one, Tieto delivers an adapter for that market.

</details>

<details>

<summary>How do you know a third party is still authorized to call?</summary>

Because the platform checks the register, not just the certificate. A certificate carries the roles held when it was issued and stays cryptographically valid for its full lifetime, so a provider whose authorization has been withdrawn still presents a valid one.

On every call the exercised role is checked against the national register of licensed providers, and the provider's status must be active. A lapsed or suspended authorization is refused with an explicit code, without anyone having to intervene. Certificate revocation is re-checked continuously against the published revocation lists on top of that.

</details>

<details>

<summary>Does the platform produce the reporting a regulator asks for?</summary>

Yes, and it is generated rather than assembled. Availability, downtime, error rates and response times are computed to the supervising authority's own definitions, from continuous health probing that follows the same path as production traffic.

In the UK that covers the full MI reporting set — performance and availability, response outliers, authentication efficacy, PSU and payments adoption and the rest — consumed by OBL, the CMA and the FCA. In the EU it covers the availability and performance statistics behind exemption from the fallback mechanism.

</details>

<details>

<summary>How do I move from sandbox to production?</summary>

Upload or generate the required certificates, request a subscription to the API service you need, then create live client applications. Regulatory services are added immediately once a valid certificate is present. Premium and aggregation services are reviewed by the provider first.

</details>

<details>

<summary>Are the APIs charged for?</summary>

Compliance APIs mandated by national regulation are free of charge. Premium APIs are monetized by the publishing institution, which sets a per-call fee — flat or progressive — and an optional recurring fee per product. Fees and limits are visible in the Developer Portal before a subscription is requested.

</details>

<details>

<summary>How many API versions run at the same time?</summary>

Up to two versions of an API can be live simultaneously. New major versions follow the standard's own releases and national regulatory mandates, are announced six months in advance, and deprecated versions remain available for up to six months. Calling `/v1/` without a minor version resolves to the highest active version within the application's scope.

</details>

<details>

<summary>Are there limits on how often I can call an API?</summary>

Yes. Every API carries rate limits that protect it against overload. For account information, requests made without the PSU present are capped by regulation — by default four per day per consent — and exceeding the cap returns HTTP 429. Institutions may additionally set commercial call limits per premium product, which can be unlimited.

</details>

<details>

<summary>Can I reach several banks through one integration?</summary>

Yes, where the operator offers aggregation. A single aggregated interface fronts the regulatory and premium services of multiple institutions, absorbing the differences between their individual implementations — including institutions that are not tenants of the platform at all.

</details>

<details>

<summary>Can the platform carry our own brand?</summary>

Yes. The developer-facing portal is delivered against the operator's or institution's design, and its content is maintained through the built-in content management system. In multi-tenant deployments each tenant can be given its own portal and address.

</details>

<details>

<summary>Where can the platform be deployed?</summary>

On the customer's own infrastructure, orchestrated on Kubernetes, or as a managed service operated by Tieto. Both models run the same platform.

</details>


---

# 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/open-banking-platform/faq.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.
