By Damilare Peter Eniayewu
When a regulated financial brand asks for a white-label mobile application, what it usually receives is a colour swap. The logo changes. The accent palette shifts. The launch screen carries a different name. The codebase underneath is the same one that serves three or four other brands, and the engineering team treats this as the entire technical scope of going white-label.
This is the lie. And it is a particularly dangerous lie in financial services, because the brands sharing that codebase are each subject to their own regulatory obligations, their own customer base, and their own compliance audits. The user opening App A and the user opening App B see two independent products from two independent providers. The engineers know otherwise. The architecture, very often, does not.
I have spent several years building white-label mobile platforms in Flutter for fintech businesses operating in the United Kingdom and across other regulated markets. The pattern I have observed repeatedly is this: white-label is approached as a presentation-layer problem when, in fact, it is an isolation problem. The visible part — themes, fonts, brand tokens, and configurable copy — is the part that is well understood. The invisible part—what happens to a tenant’s cached personal data when the application is reused across brands, where authentication tokens live, how crash reports are routed, and whose audit trail is complete—is where the failures hide.
Most published guidance on white-label mobile architecture treats the topic as a configurability exercise. The mature pattern reads roughly as follows. Extract brand-specific assets into a configuration file. Drive the application’s appearance from that file at runtime. Produce a separate build flavor per tenant. Flutter’s flavour system, combined with a brand configuration loaded at startup, allows a developer to ship the same compiled application against any number of brands. Conference talks, vendor blog posts, and the documentation of platforms selling white-label tooling — all of them stop here.
What that guidance does not address is the deeper question. Once two regulated financial brands share a single binary in production, what prevents the artifacts of Tenant A from contaminating Tenant B? On the server, this question has well-rehearsed answers. Row-level security, schema-per-tenant, and dedicated databases for higher-tier customers — the patterns are documented and mature. On the device, no such patterns are in common circulation. The mobile application is treated as if it were a thin client whose only job is to render whatever the server returns, and therefore as if isolation were the server’s problem to solve.
It is not the server’s problem to solve. The mobile application caches data. It writes to secure storage. It maintains an in-memory state across background and foreground transitions. It registers crash handlers. It uses analytics SDKs. It writes log files. It holds biometric vault references. Each of these is a place where one tenant’s data can sit alongside another tenant’s data in the same process, and each is invisible to the server.
The fundamental difference between server-side multi-tenancy and mobile multi-tenancy is the meaning of the boundary. On a server, the boundary between tenants is logical. A request arrives, it carries a tenant identifier, and the server’s job is to ensure that no resource scoped to a different tenant is accessible during the processing of that request. The boundary is enforced per request, per connection, and per query, and the runtime is rebuilt for every request that crosses it.
On a mobile device, the boundary is the device itself—but the white-label pattern compromises that boundary by placing multiple tenants into the same compiled artefact. The runtime is shared. The Dart isolate is shared. The dependency injection container, if there is one, is shared. The HTTP client’s interceptor chain is shared. The shared preferences file is shared. Unless the engineering team has explicitly decided otherwise, every singleton in the application is a single instance serving every tenant that supports.
I have seen what this looks like in practice when it goes wrong. During the development of a white-label platform I worked on, a quality engineer testing Tenant A switched the build flavour to Tenant B, launched the application, and was presented with a partially populated profile screen containing the previous tenant’s session data. The root cause was a single shared preferences key that had been written under a non-namespaced identifier during a refactor. The fix was a five-line change. The implication was significantly larger. Had the same defect reached production, two unrelated regulated financial brands would have effectively shared a customer’s personal information, with no audit trail, no detection mechanism, and no lawful basis.
This is not a story about a careless engineer. It is a story about an architecture that permits the mistake. A platform that depends on every engineer to remember to namespace every cache write, every secure storage key, every flag, every log destination, is a platform that will eventually leak. The question is not whether it will leak. The question is when the leak is significant enough to be visible. The failure modes I have catalogued across white-label mobile fintech codebases fall into categories that the conventional theming-based approach does not address.
The first failure mode is the shared interceptor state. HTTP clients are typically configured once at application startup, with interceptors that attach authentication tokens, refresh credentials, and log network activity. When the same client instance services multiple tenants—either because of a build-flavour misconfiguration or because of a development-time tenant switch—it becomes possible for a token issued under one tenant’s authentication scheme to be attached to a request destined for another tenant’s backend. The server may reject the call. The server may not. Either way, a credential has crossed a trust boundary it was not issued for.
The second is shared local key-value storage. Flutter applications commonly use shared_preferences for non-sensitive client-side state and flutter_secure_storage for sensitive values. Both packages are key-value abstractions over underlying platform storage. If the application writes a key called user_profile or last_logged_in_user without tenant scoping, the second tenant installed over the first will read the first tenant’s data, in plain text, on launch. Encryption at rest does not solve the problem, because both tenants share the same process and therefore the same decryption key material the moment the application is unlocked.
The third is shared crash reporting. Tools such as Crashlytics and Sentry are initialised once at application startup with a destination project identifier. If the application initialises this destination from a static configuration rather than from a per-tenant runtime value loaded before the first crash handler is registered, then a crash occurring during Tenant B’s session is reported to Tenant A’s monitoring dashboard. The user identifier attached to that crash is Tenant B’s customer. Two operators of regulated platforms have, at that point, exchanged a stream of personal data about each other’s customers without either party’s knowledge.
The fourth is a shared feature flag and remote configuration. Feature flag platforms commonly cache evaluated flag values in memory for performance. If the cache is keyed only by flag name and not by tenant, a feature enabled for Tenant A’s customers can surface in Tenant B’s session for the duration of a single application run. The user-visible result is that a tenant sees a feature it has not paid for, or has actively disabled in its compliance posture, appearing in its application.
The fifth, and the most often overlooked, is audit trail loss. Compliance audits in financial services depend on the ability to demonstrate which tenant any event belongs to. When a logging pipeline is configured to write structured log entries with no tenant context at the point of emission, the resulting audit trail cannot be partitioned reliably after the fact. The engineering team’s typical response is to introduce middleware that tags log entries with the current tenant identifier. The problem is that the current tenant is a runtime concept the logger does not natively understand. The moment a log line is emitted before the middleware initialises, the audit trail is incomplete in a way that no downstream cleanup can fully repair.
I propose a pattern, implemented in production white-label deployments, that can be described as tenant-isolated data layers. The principle is simple to state and demanding to implement. Every component in the application that touches storage, network, telemetry, or configuration is scoped to a tenant container. That container is created before any other component initialises and destroyed when the tenant context ends. There are no global singletons. There are no shared interceptors. There are no application-wide caches.
In Flutter, you achieve this goal by replacing the conventional global service locator with a tenant-scoped dependency injection container. Both get_it and Riverpod support scoped overrides, where a base set of services is registered at the application level, and a tenant scope overrides specific bindings with tenant-aware implementations. The HTTP client becomes a function of the tenant. The secure storage adapter becomes a function of the tenant, namespacing every key with the tenant identifier at the storage layer rather than asking each caller to remember to do so. The crash reporter becomes a function of the tenant, registered after the tenant’s destination is known.
The build configuration follows the same discipline. Rather than a single binary capable of running as any tenant at runtime, the production application is compiled into per-tenant flavours, where the tenant identifier is a compile-time constant. Runtime tenant switching is permitted only in internal testing builds. Even there, the act of switching tears down the dependency container and rebuilds it with the new tenant’s bindings. This is slower than a flag flip. It is also the only way to guarantee that no in-memory state from the previous tenant survives the switch.
The local storage layer is wrapped in an abstraction that takes the tenant identifier in its constructor and prepends it to every key it writes. This is not a security boundary in the cryptographic sense — any process with access to the file can read any key — but it is a correctness boundary. It becomes impossible for a caller to write a key without a tenant context, because the storage adapter does not expose a method that permits it. The compiler enforces what no engineer can reliably remember.
Telemetry and crash reporting are deferred until the tenant context is known. Most teams initialise Crashlytics or Sentry inside main, before any tenant logic runs, because the vendor documentation suggests it. In a multi-tenant white-label application, this is incorrect. The handler must be initialised inside the tenant scope, with the tenant’s project key, and unregistered cleanly when the scope ends.
Feature flag caches are partitioned by tenant. The cache key is the composite of flag name and the tenant identifier. This is, in practice, a small change to the wrapper layer around any feature flag library, and it is one of the most consistently neglected isolation requirements I have observed in the field.
This work is not theoretical. The Payment Card Industry Data Security Standard requires that cardholder data be isolated, that access to it be auditable, and that mechanisms be in place to prevent its unauthorised disclosure. A white-label application that allows tokenised card data from one tenant to be read by another tenant — even by the same engineer’s accidental development build — is a finding in any honest assessment. The mobile application is in scope for PCI DSS the moment it touches cardholder data, including tokenised data, and the assertion that the data lives on the server is not a defence when the application itself is the entry point for the card data and the same binary serves multiple regulated brands.
The treatment of white-label as a theming concern is a legacy of the era when white-label products served primarily as marketing surfaces. A merchant’s gateway, an affiliate’s landing page, a re-branded informational application. None of these handled regulated financial data. The patterns that grew up around them were appropriate for what they did.
Mobile fintech is a different category. The white-label application that ships under a regulated firm’s name is the regulated firm’s product, regardless of which engineers wrote it. The user opening it has rights, and the regulator overseeing the firm has expectations that do not relax because the technology provider has chosen to share code across customers. The compliance posture of the underlying platform is the same as that of every brand that runs on it. The implication for engineers building these platforms is straightforward. The work is not to make the theme configurable. The work is to make the boundary defensible. Theming is the easy part. Isolation is engineering.
About the author
Damilare Peter Eniayewu is a senior software engineer specialising in mobile fintech architecture and multi-jurisdictional regulated platforms. His engineering work spans white-label and B2B financial services in the United Kingdom, large-scale consumer fintech in Africa, and cross-border payments infrastructure operating across multiple regulatory regimes. He has shipped production systems under PCI DSS, ISO 27001, SOC 2, and United Kingdom FCA-aligned obligations and is currently engaged in the architecture of cross-border remittance infrastructure serving live institutional and retail markets.