White-Label, Multi-Tenant Onboarding: One Platform Across Brands, Branches and Segments
White-label, multi-tenant account onboarding — how one platform serves multiple brands, branches, and segments with per-tenant branding, forms, and document rules.
Most banking groups in East Africa do not run a single institution. They run a holding company with subsidiaries in several markets, a flagship bank alongside a microfinance arm, or a digital brand carved out from a legacy balance sheet. Each entity has its own logo, its own account products, its own document rules and its own regulator — yet each is solving the same problem: turning a paper or PDF business account-opening form into a guided, compliant digital journey. A white-label, multi-tenant platform answers that problem once, then configures itself for every brand, branch and segment rather than being rebuilt for each.
The hidden cost of one platform per institution
When each subsidiary or client institution gets its own deployment, the apparent simplicity is deceptive. Every copy of the code needs its own patching, its own security review, its own uptime monitoring and its own release cycle. A fix made for one bank has to be hand-carried to the others, and over time the copies drift apart until they are no longer the same product. For a vendor serving several institutions, or a group operating subsidiaries across borders, that drift is where cost and risk accumulate.
Multi-tenancy inverts the model. One platform serves many tenants — a bank, a microfinance institution, a SACCO, a fintech — and the differences between them live in configuration, not in forked code. The engineering team maintains a single codebase. Each tenant sees only its own brand, its own form and its own data. The same logic that lets a group run several subsidiaries also lets a software vendor offer onboarding as a managed service to institutions that would never build it themselves.
This is the principle behind the Creodata Business Account Opening System, and it sits at the centre of the wider guide to digital business account opening. The platform is multi-tenant by design: per-tenant branding, configurable forms, configurable document checklists and configurable products, segments and branches — all delivered without touching the code.
What "white-label" actually means in practice
White-label is more than a logo swap. It means that an applicant arriving at one tenant's onboarding journey experiences that institution's brand throughout, while the platform underneath remains shared. In BAOS, each tenant configures its own logo and colours, so the nine-step application wizard carries the right identity from the first screen of business information to the final document review.
The configurability goes deeper than appearance:
- Form fields. The wizard maps the bank's own account-opening form. Fields can be configured per tenant, so an institution that collects a particular detail at the business-information step gets exactly that, without a field another tenant does not use.
- Document checklists. The checklist that drives uploads — Certificate of Incorporation, CR12, KRA PIN certificate, Memorandum and Articles of Association, board resolution, annual returns, passport photos and so on — is configured per tenant. One institution's document requirements need not match another's.
- Account products, segments and branches. Each tenant defines its own account types and currencies, its own customer segments and its own branch structure. The same platform can present a foreign-currency corporate account for one institution and a basic business account for another.
Because these are configuration objects rather than code, a new tenant — or a new product within an existing tenant — is brought live by the Tenant Config service, not by a release. That is the difference between onboarding a new brand in a configuration session and onboarding it in a development sprint.
Schema-per-tenant isolation: shared platform, separate data
Sharing a platform must never mean sharing data. In a multi-tenant system the question that matters to a compliance officer and a regulator alike is simple: can one tenant ever see another tenant's applicants? BAOS answers that with schema-per-tenant isolation in PostgreSQL. Each tenant's data lives in its own schema, kept separate at the database level rather than relying on a single shared table with a tenant column and the discipline to filter it every time.
That isolation pairs with access control inside each tenant. The Authorization service enforces role-based access control with branch scoping, so staff see only the applications belonging to their own branch and segment — a head-office reviewer and a branch officer do not share the same view. Every action is recorded by the Auditing service in an append-only log, which means the platform can show, per tenant, who did what and when. The discipline of an audit-ready onboarding trail is the same regardless of how many tenants share the platform, and it carries the same weight when compliance work shifts to four-eyes review and audit logging in AML after the account is open.
| Layer | What is shared | What is isolated per tenant |
|---|---|---|
| Application code | One codebase, one release cycle | — |
| Configuration | Configuration engine | Branding, form fields, document checklists, products, segments, branches |
| Data | PostgreSQL instance | A dedicated schema per tenant |
| Access | RBAC engine | Roles, branch scoping, who sees which applications |
Configurable workflow, not just configurable screens
The configuration story does not stop at the applicant's screen. Behind the journey runs a six-stage bank workflow — Submission, Compliance Check, Document Verification, Internal Review, Approval and Account Creation — each stage carrying an SLA timer with breach monitoring so operations teams can see where applications are queuing. That workflow is shared across tenants, but the segments, branches and products that route work through it are tenant-specific. A tenant with several branches sees its own breach lists; a tenant with a single segment sees only that.
The compliance work inside the journey is consistent for every tenant, which is exactly what you want. The Compliance service runs PEP, FATCA and KYC/AML checks and presents a staff review workflow, so the discipline of PEP and sanctions screening at account opening and of collecting beneficial-ownership detail does not vary by brand. Each institution applies its own products and document rules on top of a common compliance backbone — and when the relationship moves from onboarding into ongoing monitoring, the same beneficial-ownership and screening data feeds the Creodata AML Compliance Platform.
Two deployment models for one set of data-residency rules
East African institutions do not all answer the same data-residency question the same way. Some are comfortable with a managed cloud service; others must keep applicant data inside their own infrastructure. A platform meant to serve a group or a vendor base has to support both without becoming two different products.
BAOS deploys two ways with feature parity:
- Azure Managed Application. The platform runs as a managed application on Microsoft Azure — Static Web App, Function Apps, PostgreSQL Flexible Server, Service Bus and Blob Storage — for institutions that want a cloud-hosted service with documents in Azure Blob and events on Service Bus.
- On-premises Kubernetes. For institutions with data-residency obligations, the same platform runs on Kubernetes on-premises, with RabbitMQ for the event bus, MinIO for document storage and Keycloak for identity. The architecture and the feature set are the same; only the substrate changes.
A banking group can therefore standardise on one onboarding platform while letting one subsidiary run in the cloud and another run inside its own data centre. The eight microservices — Account Application, Tenant Config, Compliance, Document, SLA Monitoring, Authorization, Auditing and Email Notification — behave identically across both. Where a tenant needs the final stage of the journey to feed a core-banking system, that handoff is handled as a clean architectural boundary at the Account Creation stage; the core-banking integration and account-creation handoff is designed as a pattern rather than a hard dependency, so adding a tenant does not mean re-plumbing the whole platform.
Bringing a new tenant or brand online
Because branding, forms, checklists, products, segments and branches are all configuration, standing up a new tenant follows a predictable path rather than a development project. The institution's identity is applied, its form is mapped to the shared wizard, its document checklist is defined, its account products and segments are set up, and its branch structure and staff roles are configured against the RBAC matrix. Applicants then use the same self-service portal — registering, signing in, starting or resuming a draft, and tracking status through a non-enumerable reference token — under that tenant's brand. The shorter the configuration list, the faster a group can roll out a new market or a vendor can take on a new client.
Frequently asked questions
How does a multi-tenant platform keep one institution's data separate from another's?
BAOS isolates each tenant's data in its own PostgreSQL schema rather than mixing all tenants in shared tables, so data is separated at the database level. Within each tenant, role-based access control with branch scoping limits staff to the applications in their own branch and segment, and the append-only audit log records every action. The combination of schema-per-tenant isolation, branch-scoped RBAC and audit logging means a shared platform does not become shared data, which matters for both compliance officers and regulators.
Can different tenants run in different environments to meet data-residency rules?
Yes. The platform deploys either as an Azure Managed Application — Static Web App, Function Apps, PostgreSQL Flexible Server, Service Bus and Blob Storage — or on-premises on Kubernetes with RabbitMQ, MinIO and Keycloak, and the two deployments have feature parity. A banking group can keep one subsidiary in the cloud and another inside its own data centre while running the same onboarding platform, so each tenant can be placed where its data-residency obligations require without forking the product.
What can a tenant configure without changing code?
Each tenant configures its own branding (logo and colours), form fields, document checklists, account products, currencies, customer segments and branch structure, all through the Tenant Config service. Staff roles are configured against the RBAC permission matrix with branch scoping. Because these are configuration objects rather than code, a new tenant or a new product is brought live in a configuration session rather than a release cycle, which is what allows one codebase to serve many brands.
Multi-tenancy is what lets a group, or a vendor, treat onboarding as one platform rather than many. To see per-tenant branding, configurable forms and document rules, schema-per-tenant isolation and the dual Azure or on-premises deployment working together, read more on the Business Account Opening System product page, revisit the complete guide to business account opening, and book a demo to walk through a tenant configured to your own brand and rules.