White-Label, Multi-Tenant Onboarding: One Platform Across Brands, Branches and Segments

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 Bank 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 colours, 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, several brands share one deployment and each tenant has its own colours and browser title, so the nine-step application wizard carries that institution's colours from the first screen of business information to the final document review. BAOS does not render a tenant's logo, brand its emails, send from a per-tenant email address or generate branded PDFs.

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 product within an existing tenant is brought live through the Tenant Config service, not by a release, and a new brand is a new tenant schema and configuration set rather than a fork of the code. That is the difference between onboarding a new brand as a set-up task 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. BAOS ships eight roles with branch scoping, so staff in branch-scoped roles see only the applications belonging to their own branch — a head-office reviewer and a branch officer do not share the same view. Every workflow action is recorded by the Auditing service with who did it, in which role, when and from which address and device, and reviewer decisions keep their comments. 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.

Configurable workflow, not just configurable screens

The configuration story does not stop at the applicant's screen. Behind the journey runs the bank workflow: a reviewer claims the application, verifies documents and approves or rejects it (or emails the applicant for more information); once the core banking system opens the account, staff record the account number in BAOS. SLA timers run on the workflow steps and a dashboard shows average time per step, so operations teams can see where applications are slowing down. That workflow is shared across tenants, but the branches and products that work flows through are tenant-specific, and staff in a branch-scoped role see only their own branch's applications.

The compliance work inside the journey is consistent for every tenant, which is exactly what you want. The application captures PEP and FATCA declarations, and BAOS works out every person who needs screening — directors, beneficial owners, group members, joint holders, signatories — once each, and lists them on the application for your compliance team; the screening itself runs in your screening tool. That way 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, that work belongs to an AML system such as 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 supports both:

• Azure Managed Application. The platform runs as a managed application in the institution's own Azure subscription, in the Azure region it chooses — web portal, 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. For institutions with data-residency obligations, BAOS deploys in the institution's own data centre, installed and supported by Creodata with its infrastructure team (PostgreSQL, RabbitMQ, MinIO and Keycloak take the place of the Azure services).

A banking group that wants one subsidiary in the cloud and another inside its own data centre can run one deployment of each, planned with Creodata. The platform itself is eight microservices — Account Application, Tenant Config, Compliance, Document, SLA Monitoring, Authorization, Auditing and Email Notification. BAOS does not book the account in your core banking system: staff open it there and record the account number in BAOS. A direct integration would be a separate project (see core-banking integration and the account-creation handoff), and adding a tenant does not depend on one.

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 colours and browser title are 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 — in that tenant's colours. 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 in branch-scoped roles to the applications in their own branch, and the audit log records every workflow action with who did it, in which role, when and from which address. 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, as separate deployments. BAOS deploys as an Azure Managed Application in the institution's own Azure subscription — web portal, Function Apps, PostgreSQL Flexible Server, Service Bus and Blob Storage — in the Azure region it chooses, or on-premises in the institution's own data centre, installed and supported by Creodata (PostgreSQL, RabbitMQ, MinIO and Keycloak take the place of the Azure services). A banking group that needs one subsidiary inside its own data centre runs an on-premises deployment for it beside the Azure one.

What can a tenant configure without changing code?

Each tenant configures its own branding (colours and browser title), form fields, document checklists, account products, currencies, customer segments and branch structure, all through the Tenant Config service. Staff are assigned to the eight built-in roles, with branch scoping. Because these are configuration objects rather than code, a new product is brought live in a configuration session rather than a release cycle, and a new brand is a new tenant schema rather than a fork of the code, 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 colours, configurable forms and document rules, and schema-per-tenant isolation working together, read more on the Bank Account Opening System product page, revisit the complete guide to business account opening, and book a demo to walk through a tenant configured in your own colours and rules.