Problem
Bank partners each needed their own branded operations console, but nobody wanted to maintain a separate app per bank. That meant building one platform that could white-label per tenant, enforce a real permission model, and support admin work across loans, merchants, devices, and business-rule configuration.
My role
I started this from an empty Next.js project and built out the core architecture: auth, a reusable table and form library, dynamic per-bank theming and routing, and the overall admin module structure. I still actively maintain it and ship major features, including a security patch for a critical framework-level vulnerability and the permission system, while teammates handle bank-specific rollout and integration.
Architecture
A Next.js App Router SPA in TypeScript talks to the lending backend over a standard data-fetching layer with NextAuth handling sessions. Multi-tenant white-labeling maps each bank to its own theme tokens and routing, so the same codebase can present as several distinct branded products. A role and permission system (RBAM/PBAM) gates navigation and actions. On top of that sit the actual admin modules: users and devices, loan-approval workflows for MSME, merchant management, reporting, and configurable business rules like multipliers, interest, and commission, described here only as configuration surfaces rather than specific partner formulas.
Technical highlights
- Per-bank white-labeling and theming from one shared codebase.
- A permission system that drives what shows up in the sidebar and what actions are actually allowed.
- A reusable table and form library that became the foundation for the rest of the admin UI.
- Shipped a patch for a critical framework-level vulnerability, plus ongoing fixes from pentest findings.
Simplified flow
Shared codebase
Next.js platform
Theme / routing layer
Per-bank white-labeling
RBAM / PBAM
Permission layer
Bank A
Bank B
Bank C