> 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/uk-open-banking-obl.md). # UK Open Banking Standard (OBL) Support for the UK Open Banking Standard published by Open Banking Limited — the Account and Transaction, Payment Initiation and Confirmation of Funds APIs, plus the full MI reporting the UK regulator The UK did not adopt the Berlin Group. Its interface is defined by the **UK Open Banking Standard**, published by **Open Banking Limited (OBL)** under the CMA Order and supervised alongside the FCA — a different security profile, a different certificate regime, a different onboarding model and, most consequentially for a bank, a far heavier reporting obligation. The platform implements it as a first-class standard. A UK deployment is a configuration of the same platform that serves Berlin Group markets, not a separate product — which matters to any group operating on both sides of the Channel. ## APIs supported | API | Coverage | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Account and Transaction API** | Account access consents, accounts, balances, transactions, beneficiaries, direct debits, standing orders, products, offers, parties, scheduled payments and statements | | **Payment Initiation API** | Domestic payments, domestic scheduled payments, domestic standing orders, international payments and international scheduled payments — through the two-step consent-then-resource model, including multi-authorization where a payment needs more than one approver | | **Confirmation of Funds API** | `funds-confirmation-consents` and `funds-confirmations`, for Card Based Payment Instrument Issuers | {% hint style="info" %} Variable Recurring Payments and the Event Notification API are part of the OBL standard but are not in the current scope of this platform. Talk to us if either is on your roadmap. {% endhint %} ## Version currency The current standard is **v4.0.1**, with v3.1.x still running in production across the market. The platform's versioning model fits this directly: up to two versions of an API serve traffic simultaneously, deprecated versions remain available through a defined migration window, and the standard's own `payload-version` header lets a third party keep submitting an older schema while it migrates. ## What differs from the EU profile This is where a platform built only for the Berlin Group runs out of road. | Area | UK requirement | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | Security profile | The Financial-grade API (FAPI) profile, Part 2, with mutual TLS on every connection | | Message signing | **Detached JWS** over an unencoded payload (RFC 7797), algorithm **PS256**, carried in the `x-jws-signature` header | | Signature claims | The OBL-specific critical claims — `http://openbanking.org.uk/iat`, `.../iss` and `.../tan` — declared in `crit`, with the Trust Anchor named explicitly | | Certificates | OBL-issued network and signing certificates against the OBL Trust Anchor, rather than eIDAS QWAC and QSealC | | Onboarding | The Open Banking Directory and Dynamic Client Registration, instead of manual certificate upload | | Required headers | `x-fapi-interaction-id`, `x-fapi-auth-date`, `x-fapi-customer-ip-address`, `x-customer-user-agent` | | Idempotency | `x-idempotency-key`, maximum 40 characters, honored across a 24-hour window on payment submission | | Authentication flows | Redirect and decoupled, the latter via CIBA | | Errors | ISO 20022 reason codes alongside OBL proprietary codes, with consent status and `StatusReasonCode` updated on failure | Every one of these is a policy concern rather than a code change. Signature calculation and validation, certificate validation, header injection and removal, schema validation and idempotency are all configurable per operation, so the UK profile is assembled from the same policy set that serves every other market. ## Regulatory reporting This is the part UK banks underestimate, and the platform covers it in full. An ASPSP must submit **MI data to OBL** on a continuing cycle, consumed by OBL, the **CMA** for monitoring compliance with the Order, and the **FCA**. The obligation spans nine reporting areas: | Reporting area | Cadence | | -------------------------------------------- | ------------------- | | Performance and Availability | Daily, per endpoint | | PSU Authentication and Interaction | Daily | | Response Outliers — the slowest 50 endpoints | Monthly | | Auth Efficacy | Monthly | | PSU Adoption | Monthly | | Enhanced PSU Adoption | Monthly | | PSU Consent Adoption | Monthly | | Payments Adoption | Monthly | | Additional Metrics | Monthly | The metrics behind them are unusually specific: * **Availability** as a percentage of total hours in the month, split between **core hours (06:00–24:00)** and non-core hours, with downtime reported per brand. * **Response times** — both median and mean **time to last byte** and **time to first byte**, per endpoint per day, together with total response payload size. * **Call volumes** per endpoint per day, split core and non-core. * **Maximum Payment Initiations Per Second**. * **Payment status distribution** across the standard's status values. * **SCA exemption** request volumes by exemption type. * **Notification** delivery success and failure rates. * **PSU adoption** — new and cumulative users, split between consumers and SMEs. * **TPP onboarding and churn**. ### Why this is close to free here The platform already measures every one of these things, because it measures itself for its own operational reporting. Each API exchange is audited in full under a shared trace identifier; health endpoints are probed continuously through the gateway, so availability reflects what a third party actually experiences rather than whether a process is running; response times, payload sizes, status distributions and consent counts are all recorded per endpoint, per application and per brand. The consequence is that MI submission is a **generated output, not a monthly data-gathering exercise**. Banks that assembled these figures by hand — or reconstructed them from raw logs at month end — usually find this the single largest operational saving in a UK deployment. ## Running the UK profile For an institution already on the platform, adding the UK standard means publishing the OBL API products, connecting them to the same SCA and Core interfaces, and configuring the policy chain for detached JWS, FAPI headers and OBL certificates. Reporting is switched on rather than built. For a group operating in the UK and the EU, both standards run on one installation, with tenants isolated from one another and each market's profile applied per API product — one platform, one operations team, two regulatory regimes. --- # 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/uk-open-banking-obl.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.