Multi-Bank Platform Blueprint

Code lives in one repository. A release script builds it once per bank and ships it in two ways: store builds for native changes, OTA bundles for JavaScript. On the phone, the app asks the backend what this bank and this customer may use, and the backend checks every action again.

• Bank differences are data, not code branches. They live in tenant packs and in server config.
• The server decides security. Which checks a transfer needs, and whether a customer may use a feature at all.
• Every change has a lane. A switch flips in minutes, a JS fix ships in hours, a native change takes days. Pick the fastest lane that is allowed (section 07).

"Bank A" is not one thing. It exists in four places, and onboarding a bank means filling in all four. The bank's id (for example bank-a) ties them together.

The app keeps its current layering. Two things are added: a tenant layer that supplies the bank's identity at build time, and a flows layer that runs security steps and journeys. Bank-specific input enters in only two places: the tenant pack when building, and server config when running.

Every screen, tab, button and action has a feature key such as loans.apply. The app resolves each key through five layers. A later layer overrides an earlier one, with one exception that protects the bank: a false from the bank or from the session is final.

Bank A has loans and cards, but has switched cards off live during an outage. Bank B has no loans. Customer X at Bank A has KYC pending.

• The root key decides a module. Turning loans on for a bank turns on the whole module; children are switched off only to remove one capability.
• New keys ship off. An OTA update never shows a new feature to a bank that did not ask for it.
• The server checks again. Hiding a button is for the customer's convenience. The API refuses the call with FEATURE_NOT_AVAILABLE either way.

Some banks want the same feature to work differently: other security checks, other steps, other limits. There are five ways to allow that. Use the lowest rung that fits; each step up adds power and upkeep.

If the app decided "Bank B skips the TPIN", a modified app could skip it anywhere. So the server holds each bank's policy and replies one step at a time: "now the TPIN", "now the OTP", "done". The app only knows how to show each kind of check.

Each bank moves through the same lifecycle. After go-live, every change, large or small, goes back through that bank's UAT before production.

Every crash report, API log and analytics event carries five tags: tenant, appVersion, bundleId, configVersion and channel. With those, one dashboard filters to any bank and support can see exactly what a customer was running.

• Crash-free sessions per bank and per OTA bundle, to decide when to widen a rollout
• OTA adoption per channel, and how many phones are still on old native versions
• FEATURE_NOT_AVAILABLE rate: if it rises, the app is showing something the server refuses
• Challenge failure rates by type, for example OTP not delivered at one bank

There are four lanes. Choose by what changed, not by urgency: a native change can never take the OTA lane, and a switch never needs a release.

• The app ignores config keys it does not know, so the server can publish ahead of the apps.
• The backend keeps every API that the oldest supported app version uses. Remove a field only after the minimum version has moved past it.
• The minimum supported version lives in server config. Below it, the app sends the customer to the store.

1. The server is the boundary. Every business API checks the bank, the role and the customer again. The app's gating is for the customer's convenience.
2. Fail closed. An unknown feature key, an unknown challenge type or an unreadable config means "off" or "stop", never "allow".
3. The bank's off is final. Session and device layers cannot re-enable it, and release builds let the device layer switch features off only.
4. Kill switches survive offline. The last bank config is cached and applied on a cold start without network.
5. No leaks between customers or banks. The session layer is wiped on sign-out, each bank's bundle contains only its own pack, and a tenant guard refuses to run a bundle in the wrong bank's app.
6. HTTPS before production. Config and challenge replies must not be changeable in transit.
7. Signed code. Separate store signing keys per bank, and signed OTA bundles.
8. Every change is recorded. Two-person approval and an audit log for switches and policies.

The early phases change nothing customers can see. They make the current app ready for a second bank. Sizes are rough, for one developer.