Which tenancy model is best for a fintech platform?

There is no single answer. A shared database with a tenant id is cheapest and suits many small tenants. A schema or database per tenant gives stronger isolation and easier per-tenant restores, which regulated partners often value. Many platforms share the application tier and isolate data, and some offer dedicated deployments to the partners that need them.

Is row-level security enough to isolate tenants in a shared database?

It is a strong safeguard because the database enforces it rather than application code. It does not cover caches, files, search indexes, logs or background jobs, so those need their own tenant controls, and isolation should be tested on every release.

Can one mobile app be white-labelled for many brands?

Technically yes, but Apple’s App Store Review Guidelines reject apps built from a commercialised template unless the content provider submits them. In practice each branded app is usually published from the partner’s own developer account, or a single app serves several brands where that suits the business.

Who is responsible for compliance on a white-label platform?

It depends on the arrangement, which is why it must be agreed in writing. The licence holder, the data controller and processor, identity checks, complaints and regulatory reporting each need a named owner, and the platform must produce the records each party needs.

Does Wideline build white-label platforms?

We build custom platforms and apps, and our team has shipped regulated lending, investing and trading software. We can help you choose a tenancy model and design the configuration, isolation and onboarding around it, and if an existing product already does what you need, we will say so.

White-labelling a fintech platform: tenancy, theming and compliance

Updated 18 October 2026 · 10 min read

The short answer

White-labelling a fintech platform means running one codebase for many brands, each with its own look, domain, configuration and often its own compliance obligations. The central decision is the tenancy model: a shared database with a tenant id on every row, a schema per tenant, or a database per tenant. Shared is cheapest to run and hardest to isolate; a database per tenant is the reverse.

For a regulated platform serving tens of partner brands rather than thousands, stronger data isolation is usually worth its cost, either a schema or database per tenant, or a shared database with isolation enforced by the database itself. Decide early, because changing tenancy model later is expensive, and treat theming, configuration, audit and tenant onboarding as features in their own right.

Start by defining a tenant

A tenant is whoever you separate data and configuration for. On a white-label fintech platform that is usually a business: a lender, a broker, a wealth manager or a retailer offering finance under its own brand. Each tenant has many users, and some tenants will want more than one environment or more than one brand.

Get this definition written down before you design anything else. It decides what goes in the tenant id, how users are mapped to tenants, whether one person can belong to two tenants, and who is responsible for the data each tenant holds. Microsoft’s architecture guidance makes the point that choosing a tenancy model is a commercial decision as well as a technical one, and that is especially true in regulated work.

Three tenancy models compared

There are three common ways to separate tenant data, and real platforms often mix them, for example sharing the application tier while giving each tenant its own database. Isolation is a spectrum rather than a switch, and different layers can sit at different points on it.

Question	Shared database, tenant id	Schema per tenant	Database per tenant
Data isolation	Logical only; relies on every query filtering correctly	Stronger; separate tables per tenant in one database	Strongest; separate databases, often separate credentials
Cost per tenant	Lowest	Low to moderate	Highest, unless databases are pooled
Noisy neighbour risk	High; one heavy tenant affects all	Moderate; shared database resources	Low
Schema migrations	Run once	Run once per tenant schema	Run once per database; needs automation
Restoring one tenant	Hard; data is mixed with others	Moderate	Straightforward
Per-tenant customisation	Difficult	Possible	Possible, but every variation adds maintenance
Suits	Many small tenants, low regulatory exposure	Tens to hundreds of tenants	Few large or highly regulated tenants
Main risk	A single missing filter leaks data across tenants	Migration drift between schemas	Operational load grows with every tenant

Making shared data safe

If you share a database, do not rely on developers remembering to add a tenant filter to every query. Put the tenant id on every tenant-owned table, set the tenant context once per request from the authenticated user, and have the database enforce it. PostgreSQL’s row-level security, for example, lets you define policies so that a session can only see and change rows for its own tenant, and denies access by default when no policy applies.

Background jobs, queues, caches, file storage and search indexes need the same discipline. A cache key or file path without the tenant id in it is a leak waiting to happen. Write automated tests that deliberately try to read another tenant’s data through every API, and run them on every release.

Theming, branding and domains

Theming works best as data, not code. Define design tokens (colours, type, spacing, corner radius), logos, email templates, legal text and support contacts per tenant, and have the front end read them at runtime. Test every screen against the most extreme themes you allow, because a partner’s pale brand colour on white text is an accessibility failure.

Custom domains mean issuing and renewing a TLS certificate for each partner’s domain and proving the partner controls it. Services such as Cloudflare for SaaS automate custom hostnames and certificates, and building this yourself is rarely worth it. Email needs similar care: sending as a partner’s domain requires their DNS records for sender authentication, so build that into onboarding.

Mobile apps are harder to white-label than web. Apple’s App Store Review Guidelines say apps built from a commercialised template will be rejected unless submitted by the provider of the app’s content, which in practice means each branded app is usually published from the partner’s own developer account. Plan for that in contracts and release processes, or consider a single app that serves several brands where that suits the business.

Per-tenant configuration and feature flags

Partners will ask for differences: a product they offer and others do not, a different onboarding step, different limits or fees. The safe way to give them that is configuration and feature flags, not code branches. Give tenant configuration a typed schema, validate it on save, version it and record who changed it. Treat a configuration change in production with the same seriousness as a code release, because on a fintech platform it can change what customers are charged.

Be wary of code that checks which tenant it is running for. Each such check is a fork in your product, and a platform with dozens of them becomes a set of separate products sharing a repository. When a partner needs something new, ask whether it can be a configurable capability that any tenant could switch on.

Isolation, audit and per-tenant compliance

Every action on the platform should produce an audit event that records the tenant, the user, the action, the record affected and the time. Your own staff’s access to tenant data needs particular care: support and engineering access should be granted for a reason, time-limited and logged, because partners and their regulators will ask who at the platform provider can see their customers’ data.

Compliance on a white-label platform is shared, and the split must be explicit. Agree with each partner who holds the licence, who is responsible for customer identity checks, who is the data controller and who is the processor, who handles complaints, and who submits which regulatory reports. The platform then needs to support those answers: reports filtered by tenant, retention policies that can differ by tenant, and data exports for a tenant’s auditors.

Data residency can override everything else. If a partner must keep data in a particular country, a shared database in another region is not an option, and a separate deployment for that tenant may be the only answer. That is one reason to automate infrastructure from the start, so that a dedicated deployment is a repeatable task rather than a project.

Onboarding a new tenant

The cost of a white-label platform shows up in onboarding. If adding a partner takes engineers several weeks of manual work, growth will be slow and error-prone. Aim for onboarding that operations staff can run from a checklist, with engineering involved only for genuinely new capabilities.

Commercial and compliance checks complete, and responsibilities agreed in writing.
Tenant record, configuration and feature flags created from a reviewed template.
Infrastructure provisioned by automation, including any dedicated database or deployment.
Branding, email templates, legal text and support details loaded and reviewed.
Custom domain verified, certificate issued, email sender authentication in place.
Mobile app accounts and store listings set up, if the partner has branded apps.
Integrations configured with the partner’s own credentials and accounts, where required.
Isolation tests, end-to-end tests and a supervised first transaction in production.
An offboarding plan: how data is exported, retained and deleted if the partnership ends.

Pricing and operations

Measure the cost of serving each tenant, at least roughly: infrastructure, third-party fees, support time. Without that you cannot price sensibly, and a large partner on shared infrastructure can quietly consume most of your margin. Tenancy can be part of the product: some platforms offer dedicated infrastructure as a higher-priced tier for partners that need stronger isolation.

Releases need a strategy too. On shared infrastructure every release reaches every partner at once, so a bad change affects all of them. Rolling changes out to groups of tenants, with feature flags to turn new behaviour on per tenant, limits the damage and lets partners schedule changes that affect their customers.

Questions

Which tenancy model is best for a fintech platform?: There is no single answer. A shared database with a tenant id is cheapest and suits many small tenants. A schema or database per tenant gives stronger isolation and easier per-tenant restores, which regulated partners often value. Many platforms share the application tier and isolate data, and some offer dedicated deployments to the partners that need them.
Is row-level security enough to isolate tenants in a shared database?: It is a strong safeguard because the database enforces it rather than application code. It does not cover caches, files, search indexes, logs or background jobs, so those need their own tenant controls, and isolation should be tested on every release.
Can one mobile app be white-labelled for many brands?: Technically yes, but Apple’s App Store Review Guidelines reject apps built from a commercialised template unless the content provider submits them. In practice each branded app is usually published from the partner’s own developer account, or a single app serves several brands where that suits the business.
Who is responsible for compliance on a white-label platform?: It depends on the arrangement, which is why it must be agreed in writing. The licence holder, the data controller and processor, identity checks, complaints and regulatory reporting each need a named owner, and the platform must produce the records each party needs.
Does Wideline build white-label platforms?: We build custom platforms and apps, and our team has shipped regulated lending, investing and trading software. We can help you choose a tenancy model and design the configuration, isolation and onboarding around it, and if an existing product already does what you need, we will say so.