> 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/solutions-and-use-cases/tieto-aggregation-service.md).
# Tieto Aggregation Service
**One integration. More than 200 banks. Coverage from day one.**
The same Financial API Aggregation capability, delivered as a service. Instead of standing the platform up yourself, you connect once to Tietoโs cloud and reach more than 200 banks across Europe through consistent APIs for account information and payment initiation. We aggregate each institutionโs XS2A interfaces and keep them aggregated โ the version upgrades, the national quirks, the Tuesday-morning breakages are on our side of the line.
## Where it reaches
Twenty-nine markets, with the Nordic and Baltic regions as our primary focus.
{% columns %}
{% column %}
๐ฆ๐น Austria\
๐ง๐ช Belgium\
๐ง๐ฌ Bulgaria\
๐ญ๐ท Croatia\
๐จ๐พ Cyprus\
๐จ๐ฟ Czech Republic\
๐ฉ๐ฐ Denmark\
๐ช๐ช Estonia\
๐ซ๐ฎ Finland\
๐ซ๐ท France
{% endcolumn %}
{% column %}
๐ฉ๐ช Germany\
๐ฌ๐ท Greece\
๐ญ๐บ Hungary\
๐ฎ๐ช Ireland\
๐ฎ๐น Italy\
๐ฑ๐ป Latvia\
๐ฑ๐น Lithuania\
๐ฑ๐บ Luxembourg\
๐ฒ๐น Malta\
๐ณ๐ฑ Netherlands
{% endcolumn %}
{% column %}
๐ณ๐ด Norway\
๐ต๐ฑ Poland\
๐ต๐น Portugal\
๐ท๐ด Romania\
๐ธ๐ฐ Slovakia\
๐ช๐ธ Spain\
๐ธ๐ช Sweden\
๐บ๐ฆ Ukraine\
๐ฌ๐ง United Kingdom
{% endcolumn %}
{% endcolumns %}
## Who it is for
* **Payment service providers** opening account-to-account payments alongside cards, without a bank-by-bank integration program behind it.
* **Fintechs and lenders** that need account verification, real balances and transaction history for affordability and onboarding decisions โ in every market they operate, not just the first one.
* **Enterprises and software vendors** โ accounting, ERP, treasury and payroll products โ that want bank connectivity as a feature rather than a roadmap.
## What stays on our side of the line
* **Two hundred bank interfaces**, each with its own reading of the Berlin Group specification, its own optional fields and its own payment products.
* **Every version upgrade.** When a bank publishes a new release, the aggregated interface you integrated against does not change.
* **The national profiles.** Market-specific fields, local deviations and regulator-specific rules are absorbed before they reach you.
* **The operational tail** โ monitoring, retries and the quiet work of noticing that one institution started answering differently this morning.
What reaches your developers is one set of REST APIs for accounts, balances, transactions and payment initiation, with the bank as a parameter of the call.
## Managed now, yours later
The service runs on the same aggregation technology that ships inside the platform, so the choice is operational rather than architectural. Start as a tenant of ours while coverage matters more than control; move to [Financial API Aggregation](/solutions-and-use-cases/aggregation.md) on your own infrastructure when you want to set the tariffs, pick the institutions and own the roadmap. The interface your customers integrated against is the same either way.
## Explore the APIs
:code:
Tieto SaaS Aggregation API reference
See how bank discovery, authentication and aggregated account and payment APIs fit into your product. Explore the endpoint reference.
---
# 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/solutions-and-use-cases/tieto-aggregation-service.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.
