> 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/features/back-office-integrations.md).

# Back Office Integrations

The platform does not replace core banking. It fronts it. A bank exposes its RESTful interfaces, and the platform handles everything between those interfaces and the third-party provider.

## How to connect a Back Office

A back office is connected per API Product, from the Central Portal, once the product's specification has been uploaded and its APIs generated. Nothing is deployed and no code is written on either side — the connection is configuration, and it can be changed without republishing the product.

{% stepper %}
{% step %}

#### Point the API Product at the upstream service

Supply the address of the back-office service that will serve the product's operations. 

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

#### One API Product, many back offices

A single API Product can be connected to the interfaces of several institutions at once, each connection mapped to the specifics of its target — differing optional parameters, interface versions and field interpretations absorbed here rather than by your consumers. That is how a whole market becomes one integration for a third party, and the institutions behind it never need to become tenants. See [API Aggregation](/solutions-and-use-cases/aggregation.md).
{% endhint %}
{% endstep %}

{% step %}

#### Configure how the two sides authenticate

Choose the mechanism for the connection and load the material it needs — certificates for mutual TLS, or client credentials where the service expects a token. Each direction is configured separately, because the platform both calls the back office and can be called by it. 
{% endstep %}

{% step %}

#### Add policies where the integration needs shaping

Optionally assign [API Policies](/features/api-policies.md) to the connection to adjust requests and responses in flight — headers and identifiers, field mapping, error translation, retries and routing, electronic signatures etc. This is where the gap between what the standard specifies and what a particular back office actually implements gets absorbed, instead of being pushed onto the consumer.
{% endstep %}

{% step %}

#### Test the connection, then expose the product

Exercise the connection against the sandbox before the product's status changes to published. Once exposed, traffic flows through to the back office and appears in monitoring broken down by product, operation and tenant.
{% endstep %}
{% endstepper %}

## PSD2 Connectors

For PSD2 compliance, banks expose two lightweight interfaces: SCA Server and Core Server. Both use JSON over HTTPS, and are implemented by the bank based on Tieto's detailed guidelines. The Platform comes with in-built PSD2 connectors that automatically register SCA and Core back offices for a tenant and connect them with regualtory API Products. 

You can further tweak and shape the integration with each bank in API Management UI. 

## Beyond the regulatory interface

The same integration pattern extends to a bank's own services. A custom back-office service can be connected and its operations published as premium API products, using the platform's authentication, policy enforcement, limits and billing. Guidance covers the API style the platform expects — REST with hypermedia, ISO 20022 naming, structured error responses — and the platform rewrites hypermedia links in responses so consumers only ever see platform addresses.


---

# 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/features/back-office-integrations.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.