> 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/premium-financial-api-products.md).

# Premium Financial API Products

Turn existing premium financial services into governed API products that generate revenue. Offer your own APIs to corporate customers, fintechs, and partners. You can also build a multi-tenant solution that lets tenants manage and commercialize their own services through a shared platform.

The Platform gives product, engineering, and commercial teams the controls needed to launch and operate premium APIs:

* publish APIs as clearly defined, reusable products;
* connect each product to your services or your tenants’ upstream systems;
* apply API Gateway policies for security, routing, transformation, and traffic control;
* version, deprecate, suspend, and retire API products throughout their lifecycle;
* onboard customers through the [Developer Portal](/portals-and-interfaces/developer-portal.md), where they can discover, test, and integrate with your services;
* set product-specific pricing, usage limits, and access rules;
* use built-in reporting and billing to measure usage and monetize each product.

## Berlin Group OpenFinance standard

Premium does not have to mean proprietary. The Berlin Group’s **openFinance API Framework** carries the NextGenPSD2 architecture past the regulatory minimum into commercial territory, and the Platform ships that extension as a suite of ready-to-integrate API products — modeled, documented, and wired to the gateway before your project starts. You pick the products you want to sell, connect them to your own or your tenants’ upstream systems, and publish.

Two suites are available today, both at framework version 2.2:

| Suite                                                                                                       | What it adds beyond the regulatory interface                                                                                                                                         |
| ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [Extended Account Information Service](/api-references/openfinance/extended-account-information-service.md) | Single cards, savings accounts, loan accounts, and securities accounts — details, balances, and transaction lists for each, securities positions and orders, and account statements. |
| [Extended Payment Initiation Service](/api-references/openfinance/extended-payment-initiation-service.md)   | Secured, deferred, multiple-deferred, and recurring payments, with authorization separated from initiation so limit and balance checks apply up front and secure the later payment.  |

Why a standard is worth even more here than it is in compliance work:

* **Nothing to design.** The slow part of a premium API program is usually agreeing what the resources are, how errors are reported, and how consent is expressed. The framework has settled all of that, and the products arrive with it built in.
* **One integration for the TPP.** Extended services reuse the request structure, consent model, SCA flows, signing, and error semantics that every TPP on your platform already implements for the regulatory APIs. Taking a premium product becomes a subscription rather than a project — and consumption is what you bill for.
* **Recognizable across borders.** A Berlin Group-shaped API reads the same in every market that implemented NextGenPSD2, so a product launched for one tenant is sellable to the next, and to TPPs that have never worked in your market.
* **Not a straitjacket.** National profiles, additional fields, and entirely non-standard products of your own sit alongside the standard ones, published through the same lifecycle and the same Developer Portal.
* **Aggregatable by design.** The openFinance framework is also what the Platform speaks when it consumes another institution’s premium interfaces, so a product published in this shape can be offered onward as part of an aggregated proposition.

The framework keeps growing — securities data, lending data, and account statements all reached the market this way. Each new release follows the same publication path: a specification becomes an API product, a version, and a set of operations, without platform development work.

## Examples of Premium APIs

The products below are live on client platforms today. They fall into two families: open finance data and payment products that extend the regulatory interfaces, and card processing services sold on to banks, merchants, and fintechs.

* **Extended account information** — Cards, savings, loans, and securities accounts, their balances and transaction lists, securities positions and orders, and account statements: the account types the regulatory AIS deliberately leaves out. Sold to budgeting, wealth, and accounting apps, and just as readily to a tenant’s own corporate customers reading their accounts directly.
* **Extended payment initiation** — Secured, deferred, multiple-deferred, and recurring payments, with the authorization step pulled away from the initiation step and limit and balance checks applied at authorization time. This is what makes pay-later, marketplace payout, subscription, and deposit-on-booking flows work on top of an ordinary credit transfer.
* **Card issuing and lifecycle** — Create a client with an agreement and a card; order, renew, replace, and close cards; read card data and balances; change and verify PIN; suspend and reactivate; run and reverse card payments; provision Apple Pay and Google Pay tokens. The product that lets a fintech launch a card program without integrating with a processor directly.
* **Card controls, limits, and stop lists** — Limits by transaction type, merchant category, and acquirer category at card, cardholder, and BIN level with live counters; account attributes such as credit and upper balance limits; and the issuing and acquiring stop lists with batch lookup and history. The raw material for in-app card controls, and the shortest path between a fraud alert and a blocked card.
* **Merchant and acquiring services** — Merchant, terminal, and agreement onboarding for POS and e-commerce channels, batch status changes, and a processed-transaction history that acquirers and their merchants use to reconcile what was processed against what was settled.
* **3-D Secure and cardholder authentication** — Card and device registration with the authentication service, plus a queryable history of authentication events across the Visa and Mastercard programs.
* **Operational services** — Batch file processing status, reference dictionaries, and exchange rates by operational day. Small endpoints, but they are what turns a one-off integration into something a partner can run unattended.

## Relevant features

<table data-view="cards"><thead><tr><th></th><th data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td>Publish OpenAPI-based products through the gateway and Developer Portal.</td><td><a href="/features/api-publication.md">API Publication and Governance</a></td></tr><tr><td>Version, publish, deprecate, suspend, and retire products predictably.</td><td><a href="broken://pages/ZQyBAhLEpkWQSgGOTo1N">Broken link</a></td></tr><tr><td>Connect premium APIs to bank, card, payment, and tenant upstream services.</td><td><a href="/features/back-office-integrations.md">Back Office Integrations</a></td></tr><tr><td>Apply security, transformation, routing, and traffic controls per API operation.</td><td><a href="/features/api-policies.md">API Policies</a></td></tr><tr><td>Define limits and recurring or usage-based pricing per product.</td><td><a href="/features/limits-fees-and-monetization.md">Fees and Monetization</a></td></tr></tbody></table>


---

# 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/premium-financial-api-products.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.