> 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/multi-tenancy-and-white-labeling.md). # Multi-Tenancy and White-Labeling One installation of the platform can serve many banks. Each participating bank is a tenant, with its own data, administrators, tariffs and consents, and no visibility into any other tenant's affairs. ## What a tenant is A tenant record identifies a bank by legal name, financial identifier, country and address, and carries a system-generated tenant identifier used throughout the platform. Tenants are created in Central Administration Portal. ## What is isolated * **Administration.** A bank's administrators can only see their own bank's users. * **Commercial terms.** Tariffs are configured by the bank, not the operator, because pricing describes the relationship between a bank and its third parties and stays confidential to them. * **Consents.** Each bank sees and manages only the consents its own customers have granted. * **Reporting.** Reports are scoped to the tenant, with deliberate cross-tenant aggregates available on Central Portal for platform-level oversight. * **Data.** Tenant data is logically separated, with tenant-specific components deployed as dedicated workloads where separation demands it. ## Two tenancy models The same platform supports two quite different commercial shapes, and the choice determines what a third-party provider experiences. ### Separated multi-tenancy Each tenant gets its own developer-facing portal, at its own address, presented under its own brand. A third party integrating with two banks sees two portals and registers with each. This suits deployments where banks compete with one another, where each wants an unmediated relationship with its developer community, or where regulation or brand policy makes a shared channel unattractive. Compliance API groups can still be provisioned centrally and appear automatically in each tenant's portal, so the operator maintains one specification while each bank presents it as its own. ### Marketplace All tenants publish into one shared developer portal. A third party registers once, then subscribes to whichever banks it needs — selecting a provider when it requests a subscription, and holding one subscription per bank. This suits national and regional infrastructure, where the value to the market is a single point of entry. It shortens third-party onboarding considerably: one registration, one certificate upload, one set of applications, many banks. ### Choosing between them | | Separated | Marketplace | | ------------------------ | ------------------------------------------------------------------ | ------------------------------------------------------------ | | Developer portals | One per tenant | One, shared | | Third-party registration | Per bank | Once for the platform | | Branding | Each bank's own | The platform operator's | | Best for | Competing banks, brand-led strategies, one-bank-only installations | Clearing houses, processing centers, national infrastructure | Both models run on one installation, and the operator can combine them — a shared marketplace with a dedicated portal for a tenant that requires one. ## White-labeling The Developer Portal is delivered with custom UI/UX: * client's own branding for a marketplace, * bank-specific designs for separated multi-tenancy. Day-to-day content — landing page, product catalog, frequently asked questions, support details — is then maintained by the client through the built-in [content management](/features/content-management.md) system, without involving Tieto. White-labeling extends further than presentation. A bank can resell compliance and premium APIs to partners under its own name, and partner organizations that hold no payment license can be served by allow-listing non-regulatory certificates for them — which is what makes it practical to offer API access to a corporate client that is not a regulated third party. --- # 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/multi-tenancy-and-white-labeling.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.