> 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/standards-and-compliance/national-profiles.md). # National Profiles How the platform accommodates each market's own reading of the standard — additional fields, local deviations, national payment products and regulator-specific rules. The Berlin Group publishes a framework, not a finished interface. Every market then makes it its own: the regulator issues a national profile, institutions interpret the same field differently, and local payment products exist that the standard never anticipated. This is the point at which most implementations run into trouble. A platform built to serve the specification as written meets its first national profile and needs development. The platform is built the other way round — the market's own reading of the standard is what gets published, and adapting to it is configuration. ## What actually varies between markets | Variation | Typical shape | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | National profile of the specification | The regulator publishes its own subset or extension of the Berlin Group specification, and that document — not the generic one — is what institutions must expose | | Additional fields | Elements the local scheme requires that the standard does not define, in requests, responses or headers | | Local interpretations | The same field used differently from one market to the next, or a status mapped to a different meaning | | Local payment products | Domestic payment type codes, national instant-payment schemes, bulk formats and locally defined payment categories | | Local identifiers | Organization registration numbers, national provider identifiers and tenant identifier formats specific to the jurisdiction | | Consent rules | Validity periods, frequency caps for unattended access, and how far back transaction history may reach | | Signing and certificates | Which signature scheme applies, which trust anchor issues certificates, which headers are signed | | Authentication approaches | Which of the framework's SCA approaches the market actually uses, and how corporate authorization is collected | | Reporting duties | Which metrics the regulator wants, to which definitions, published at what cadence | ## How the platform absorbs it Five mechanisms do the work, and none of them requires a release. ### The specification is an input, not a constraint You upload the regulator's own OpenAPI document. The platform validates it, then rewrites it to the platform's URL, versioning and security conventions — so a national profile is adopted by publishing it, not by asking us to support it. Additional fields defined by the local scheme arrive with the specification and are served as specified. ### Policies carry the local requirements Schema validation, signature calculation and verification, certificate validation, header injection and removal, and channel-specific attributes are all assigned per operation. A market that requires an extra header, a different signing profile or an additional validation gets it as policy configuration. ### Adapters handle transformation the standard does not describe Where the mapping between the published interface and an institution's back office is not one-to-one — because the local scheme works differently, or because a legacy system predates the standard — Tieto delivers an adapter for that market. Everything around it stays standard. ### The rule engine holds the regulator's thresholds Consent validity periods, frequency caps on unattended access, the reach of transaction history and the error text a third party sees are configured per market and per institution, and take effect immediately. When a regulator revises a threshold, that is a configuration change. ### Versions are mapped, not coupled The consumer-facing API version is mapped onto the institution's own interface version. A bank can stay where it is while a newer national profile is published, and institutions in different markets on one installation can sit on different interface versions at the same time. ## Reporting to the local definitions Availability, response time and error-rate metrics are computed to the definitions the supervising authority uses — including how downtime is counted and which failures are attributed to the institution. Where a regulator requires periodic publication of interface statistics, the figures are generated and published through the developer channel rather than assembled by hand. ## Entering a new market In practice the sequence is short, and deliberately so: 1. Read the national profile against the generic standard and identify the deltas — fields, statuses, payment products, signing, thresholds. 2. Publish the regulator's specification as an API product and let preprocessing adapt it. 3. Configure the policy chain for the market's validation, signing and header requirements. 4. Set the rule engine to the regulator's consent and frequency thresholds. 5. Map the published version onto each institution's interface version. 6. Switch on reporting to the local metric definitions. What this means commercially is that a new market is a configuration project rather than a new product — and that one installation can serve several markets at once, each with its own profile, while the operations team stays a single team. {% hint style="info" %} If your market's profile diverges from the standard in ways not covered above, tell us what it requires. The honest answer is sometimes an adapter rather than configuration — but it is an adapter inside a platform that already does everything else, not a bespoke build. {% endhint %} --- # 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/standards-and-compliance/national-profiles.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.