Multi-Bank Platform Proposal

Today the app is wired to one bank. Four problems block any release to customers: mock code can show a fake transfer success, release builds are signed with the debug key, the server switch that turns features off is not connected, and the PIN encryption key travels over plain HTTP.

The proposal keeps one codebase and adds:

• a tenant pack per bank, chosen when the app is built;
• one backend codebase, deployed separately for each bank, so each bank's data, keys and core-banking link stay isolated;
• a five-layer feature model, so the bank and the server decide what each customer sees;
• per-bank flows through settings and server-driven security steps, never code branches;
• five update lanes, from a live switch in minutes to a store release in weeks, with UAT and production for every bank;
• management through an admin portal with two-person approval, an audit log and per-bank monitoring.

Cost: about six weeks for one mobile developer, plus backend work in parallel. The first week fixes the release blockers.

Decided (12 October 2026): one backend codebase, deployed separately for each bank, the same way the app is built separately for each bank.

Still needed from you: nine decisions in section 13. The three that matter most: where each bank's backend runs, each bank's own store accounts, and the server-driven security protocol.

• One codebase. Bank differences live in data (tenant packs and server config), never in if (bank) branches.
• The server decides access and security. The app follows the server and never widens what it allows.
• Fail closed. An unknown feature key, step or config means off or stop.
• Every bank is isolated: its own app build, backend deployment, data, keys, OTA channels, store listing and sign-off.
• Every change has a lane. Use the fastest lane the change allows.
• No change reaches a bank's customers without that bank's UAT sign-off.

The backend follows the same rule as the app: one codebase and one versioned build, deployed separately for each bank and each environment. Banks differ only in configuration: their core-banking connection, database, keys, certificates and feature settings.

A tenant is one bank. It exists in four places, tied together by one id such as bank-b.

The pack is a typed file. The build fails if a field is missing.

Offboarding: switch the bank's features off live, unpublish its store listing with the bank, retire its two OTA channels, hand over or archive its data as the contract requires, shut down its backends, and remove the pack from the registry.

• The root key decides a module. Children default to on and are switched off only to remove one capability. Today's loans.* and cards.* children get a one-time cleanup.
• New keys ship off. A CI check fails any new key that defaults to on without a written reason.
• The backend knows every key. CI exports a feature catalog on each merge; the backend imports it, so the admin portal lists the same keys the app understands.
• The server checks again. Every endpoint maps to its feature key and refuses with FEATURE_NOT_AVAILABLE.
• Backend first, then switch on. Each bank upgrades its backend on its own schedule. A feature that needs a newer backend stays off for a bank until that bank's backend is upgraded; each backend reports what it supports, and its config service never switches on a feature it cannot serve.

Some banks want the same feature to work differently. Use the lowest rung that fits; each step up adds power and upkeep.

Working locally, one bank at a time:

Rules for developers

• Never branch on the bank. Use a setting, the server policy, a journey variant, a strategy or a slot.
• Every new screen, tab, button and money action has a feature key, and the key ships off.
• Values a bank might change are settings, not constants.
• Security steps go through the flow framework, never a hand-written step machine.
• Mock data lives behind the dev environment only.
• Bank-specific code lives in that bank's pack, with a note in the pack's README saying why.

A feature is done when: its key ships off; route, UI and handler are gated; the server endpoint maps to the key; tests cover the flow; it passes every CI check; the catalog is exported; and the bank-facing notes are written.

Versions

• Each bank's version lives in tenants/registry.json as MAJOR.MINOR.PATCH. A native release bumps MINOR; a native hotfix bumps PATCH.
• Version code is computed: MAJOR × 10000 + MINOR × 100 + PATCH, so 1.6.2 becomes 10602.
• OTA bundles target exact native versions (-t 1.6.2), never wide ranges.
• We support the last two minor versions. Below that, the server's minimum version sends the customer to the store.

Signing and secrets

• One upload key per bank, stored only in CI secrets and backed up offline.
• Google Play App Signing per bank app; iOS certificates in each bank's Apple account.
• Hot Updater credentials per environment; only CI may deploy to production channels.

Working with backend releases

• A bank's backend is upgraded before any app feature that needs it is switched on for that bank.
• API changes are additive. A field is removed only after every bank's backend and every supported app version have moved past it.
• The config response carries a schema version; the app ignores keys it does not know.

• One image everywhere. Banks differ only in configuration and secrets: core-banking endpoint, database, key pair, certificates and org id.
• Infrastructure as code. One script creates a new bank's UAT and production backends. The target is one day per bank.
• Expand, then contract. Database and API changes are added first and removed later, so the previous backend version and older apps keep working during a rollout.
• Each backend reports itself. GET /meta returns its version and capabilities, and the release registry records which version each bank runs.
• Each backend serves one bank. It accepts only its own org id and refuses anything else.
• Hosting is still open (section 13): our cloud with one isolated account per bank, or the bank's data centre, where its operators deploy our signed image. The image and the steps are the same.

Every bank has two channels: bank-x-uat, installed by its testers, and bank-x-prod, installed by its customers. The channel is baked into the binary, so a bundle for Bank B can never reach Bank A.

• Hotfix: the same path, compressed into one day: UAT smoke test within two hours, then 10% and 100% the same day.
• Rollback levels: automatic (crash before the first screen); disable one channel's bundle; disable a release on every channel with one script; then fix forward.
• A bank that has not signed off stays on its previous bundle. It may lag at most two trains before the release manager escalates.

Every crash report, API log and event carries five tags: tenant, appVersion, bundleId, configVersion and channel. Each bank's backend sends its metrics and logs, without customer data, to central monitoring, tagged with its bank and backend version. Thresholds below are starting points.

Support lookup: in the ops console, a support agent enters a customer's mobile number and sees the bank, app version, bundle, config version and every feature with the layer that decided it. The app already has this logic in featureService.explain(); the server mirrors it.

Every change takes one of five lanes. The lane depends on what changed, not on urgency.

What keeps Bank B's change away from other banks

• A change only under tenants/bank-b/: CI detects it and rebuilds only Bank B's bundles.
• A change to shared code: every bank gets it in UAT, but each bank's production moves only after its own sign-off.
• A backend change or a switch: it happens in Bank B's own backend deployment. Other banks run separate deployments, and Bank B's admins cannot reach them.
• On the phone: the channel and the tenant guard stop any other bank's bundle from running.

1. The server is the boundary. Every business API checks the bank, the role and the customer again. App-side gating is for the customer's convenience.
2. No mock code in release builds. Fixtures and fake OTPs exist only in the dev environment, and CI checks the release bundle.
3. Fail closed. An unknown feature key, challenge type or unreadable config means off or stop.
4. The bank's off is final. Session and device layers cannot re-enable it; release builds let the device layer switch features off only.
5. Kill switches survive offline, and the cached config only moves forward in version.
6. No leaks between customers or banks: session flags wiped at sign-out, per-bank bundles, tenant guard, and a separate backend, database and key pair for every bank. The central platform holds no customer data.
7. HTTPS with per-bank certificate pinning before production, for config, challenges and every API. The PIN encryption key is fetched from the bank's backend before every encryption, so pinning is what makes that key trustworthy.
8. Signed code: a store key per bank, signed OTA bundles, production deploys only from CI.
9. Crash reports without personal data, stored where the banks' data rules allow.
10. Every change recorded: two-person approval and an audit log for switches and policies.

Estimates are rough, for one mobile developer. The backend work runs in parallel from week one.

About 29 working days in total, roughly six weeks. Phase 0 comes first. Phases 1 and 2 can run side by side; phase 3 comes before phase 4; phase 5 can start any time after phase 2.