> 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/api-policies.md).
# API Policies
Policies are the platform's governance mechanism. Each one is a small, configurable behavior attached to an API group version, an individual API, or a single operation. Together they decide what a call must satisfy before it reaches the Back Office, and what happens to the response on the way back.
## Trust and identity
| Policy | What it does |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Certificate validation** | Confirms the TLS certificate is present, belongs to the calling third party, and is trusted. Expiry and revocation are checked by the platform before the policy runs. Can be set to mandatory, or relaxed for sandbox compliance APIs. |
| **Certificate Parser** | Reads the client certificate, extracts the organization identifier from a nominated object identifier, verifies that the identifier belongs to both the calling application and its owner, and passes it to the back office in a header. |
| **TPP Register Check** | Verifies against the national register that the third party holds the role it is exercising and that its status is active. A role present in the certificate but not active in the register is refused with an explicit message. |
| **Basic Authentication** | Builds a basic authorization header from credentials supplied in the incoming request, for back-office systems that expect it. |
## Message integrity
Four complementary policies cover signing and signature checking in both directions. All support the Berlin Group signature scheme, the openFinance JSON Web Signature profile, and a simplified JWS variant reserved for custom back-office integrations. Digest and signature algorithms, mandatory and optional signed headers, and target header names are all configurable.
| Policy | What it does |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Request signature validation** | Verifies the signature on requests arriving from a third party, and on requests and responses exchanged with the back office. A missing signature can be treated as a failure or tolerated. |
| **Request signature calculation** | Signs requests the platform sends to the back office, using a signature certificate configured on the outgoing channel. |
| **Response signature calculation** | Signs responses returned to a third party, or to a back office. |
| **Response signature validation** | Verifies signatures on responses received from the back office. |
## Schema validation
| Policy | What it does |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Open API Validation** | Checks the incoming payload against the schema in the version's OpenAPI specification. No configuration — the specification is the contract. |
| **OBAP adapter** | Transforms XS2A requests into calls against the bank's SCA and Core interfaces. Required on every compliance API group; the mapping logic is built in rather than configured. |
| **Endpoint correction** | Rewrites the URLs the platform returns in hypermedia links so they address the platform rather than the bank. Applied to all account information and payment initiation groups. |
## Traffic management
| Policy | What it does |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Rate limiter** | Caps requests per second. Operations that share a named limiter share one counter, so a limit can be applied across a set of endpoints rather than each in isolation. |
| **Response caching** | Caches responses with a configurable lifetime and a storage ceiling, evicting the oldest entry when the ceiling is reached. The cache key covers method, URI, authorization headers, cookies and body. |
| **Cache invalidation** | Drops cached responses when the back office returns nominated status codes for nominated operations, so a write invalidates the reads it affects. Conditions are expressed against the response content. |
## Data Transformation
| Policy | What it does |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Headers action** | Adds a header with a fixed or dynamic value before routing to the back office. |
| **Format conversion** | Converts the message body between JSON and XML in either direction, so a back office that speaks XML can serve a JSON API and a JSON service can sit behind an XML one. This is what lets a core system stay as it is while the published interface follows the standard. |
| **Header removal** | Strips nominated headers from the request before it reaches the back office, and from the response before it reaches the third party. Used to keep certificates, signatures and authorization material from leaking beyond where they are needed. |
## Logging
| Policy | What it does |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Audit policy** | Logs the HTTP exchange between third party and platform, and between platform and back office. Recommended on every API group version, and required on back-office endpoints for the bank-side leg to be captured.
|
| **Data masking** | Nominated payload fields and headers can be masked before the record is written to the audit store, with control over how many leading and trailing characters remain visible, or a pattern matching only the part to be hidden. This is the mechanism by which sensitive authentication data is stripped from stored records — the requirement that makes card data handling defensible. |
## Back-office call policies
Policies apply to the platform's outbound calls as well as its inbound ones, configured per back-office operation. Default sets are supplied for the SCA and Core interfaces, with signature calculation applied to payment-initiating operations and audit logging applied throughout, so a newly connected bank starts from a sound baseline rather than an empty one.
---
# 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/api-policies.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.