> 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/how-the-platform-works.md).

# How the Platform Works

<figure><img src="https://4249390778-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FyF38p3LreGjb3YiIkEJi%2Fuploads%2FkCgnodZ8iBsACgTsMk10%2Fplatform-domain-model.svg?alt=media" alt="The platform between its administrators, tenant banks, non-tenant banks reached by aggregation, and the TPPs and payment service users on the other side"><figcaption></figcaption></figure>

## Client Perspective

{% stepper %}
{% step %}

#### Have the Platform installed

Choose the operating model that fits your security and governance requirements: a [**managed service**](/deployment/managed-service.md) operated by Tieto, or an [**on-premises**](/deployment/on-premises.md) deployment on your own infrastructure. Tieto delivers and configures either one, and the software is identical — so nothing in the steps below depends on the choice.

On-premises, you supply the supporting infrastructure the Platform runs on — a Kubernetes cluster, a SQL database, a search cluster, a secret store and a mail service — in whichever technologies your organization already runs. As a managed service, Tieto provides all of it.

{% hint style="info" %}
See [Deployment](/deployment.md) for what you provide, what each model covers, and who operates what.
{% endhint %}
{% endstep %}

{% step %}

#### Onboard a tenant

Register new tenant in [Central Administration Portal](/portals-and-interfaces/central-portal.md). Tenant is an external financial organization willing to leverage the Open Banking Platform for PSD2 compliance or for exposing their commercial API services.

{% hint style="warning" %}
Not required in a single-tenancy deployment — one where you connect published API Products to your own back office only, rather than hosting other institutions on the Platform.
{% endhint %}
{% endstep %}

{% step %}

#### Configure an API Product

Register an API product (regulatory, commercial or aggregation) by uploading an Open API Specification via Central Portal's [API Management UI](/features/api-publication.md). Assign [API Policies](/features/api-policies.md) to customize the new APIs based on your business needs.
{% endstep %}

{% step %}

#### Connect the API Product with tenant's servers

Specify URL of the upstream server and configure authentication and authorization mechanisms. Optionally, assign API Policies to execute fuller control over the integration layer between the Platform and your tenant (see [Back Office Integrations](/features/back-office-integrations.md)).

{% hint style="info" icon="chart-diagram" %}

#### API Aggregation

A single API Product can front the interfaces of many financial organizations at once, with each connection mapped to the specifics of its target API — differing optional parameters, versions and field interpretations absorbed by the Platform rather than by your consumers.

The result is a whole market reduced to one integration. And because aggregation goes beyond what the regulation mandates, it is a value-added service you own and price yourself — while the institutions behind it never need to become tenants.
{% endhint %}

{% hint style="success" %}

#### Connecting to your own backend

The upstream interface does not have to belong to a tenant. Point an API Product at your own back office and the same Platform discharges your PSD2 obligation exactly as it discharges anyone else's.

The wider opportunity is commercial. Any internal service placed behind an API Product inherits the whole governance layer — policies, versioning, rate limits, metering and billing — together with a [Developer Portal](/portals-and-interfaces/developer-portal.md) where third parties register, test against a sandbox and subscribe without a conversation. An interface you built for internal use becomes a product you can sell.
{% endhint %}
{% endstep %}

{% step %}

#### Expose your API

Make the new API Product available for consumption by client applications. This entails a simple status change on the Central Portal.
{% endstep %}

{% step %}

#### Document your API Product

The API References are automatically generated and rendered on the Documentation Portal for TPPs. Guides, FAQs and support content are yours to edit through the CMS.
{% endstep %}

{% step %}

#### Monitor API Usage

Track volumes, failures and response times by product, application and tenant. Availability and error-rate figures are calculated from that same traffic, to the definitions the regulator expects.
{% endstep %}

{% step %}

#### Monetize

Set call limits and pricing per product — a recurring fee plus a per-call fee, flat or progressive. Our Reporting features will facilitate your billing process, and will keep your tenants and consumers up to date with their obligations.
{% endstep %}

{% step %}

#### Version and retire your APIs

Publish a new version of an API Product alongside the current one, then deprecate the old one while consumers migrate.
{% endstep %}
{% endstepper %}

## Tenant perspective

**What it takes.** For PSD2/PSD3 compliance — two RESTful interfaces implemented based on Tieto guidelines, one for customer authentication, one for serving account information and processing payment initiations. For commercial APIs — just exposing them to the Platform. The Platform will handle all the rest.

**What it's worth.** PSD2/PSD3 becomes a configuration exercise rather than a build. There is no developer portal to run, no certificate lifecycle to handle, no consent store to design and no availability reporting to invent. Because the interface meets the standard third parties already know, onboarding them costs support time instead of integration projects, and availability measured the regulator's own way removes the need for a fallback interface. The same channel that discharges the obligation then sells premium APIs at prices the bank sets and keeps confidential — turning a compliance cost line into a revenue one. And the bank sees every consent its customers have granted, with the ability to revoke one on the spot: the control that matters the day fraud is suspected.

## TPP/PSP perspective

**What it takes.** Register on the [Developer Portal](/portals-and-interfaces/developer-portal.md), test, add certificates, subscribe. Self-service from start to finish, with no commercial conversation required to begin.

**What it's worth.** Evaluation costs nothing: sandbox access arrives with registration — no certificates, no subscription, no agreement — so a team can prove the integration works before anyone signs anything. The interface is the Berlin Group standard, so an integration built for one market largely fits, and the reference reflects live behavior rather than a document that has drifted from it. Prices and call limits are visible before subscribing, which makes the commercial decision a self-service one. In marketplace deployments a single registration reaches every bank on the platform, and [aggregation](/solutions-and-use-cases/aggregation.md) reaches banks that are not on it at all — national coverage from one integration instead of one per bank.


---

# 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/how-the-platform-works.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.
