Applications and channel boundaries

Banking has five requested application surfaces. The mobile item is an API product for mobile clients; a native mobile UI has not been commissioned. The ATM application needs separate terminal/device and network certification.

Application	Primary users	Owns	Access and scope boundary
Super Admin	Platform operators and commissioned security roles	Institutions, subscriptions/modules, environment and permitted access governance	Customer servicing and institution funds require separate institution-scoped authority.
Banking Operations	Branch, Head Office, finance, cards, lending, risk and other approved duties	Institution-scoped operating workspaces	Duties and independent maker/checker authority are assigned separately.
Customer Web	Verified retail/business customers and authorised signatories	Own products, proof/consent, instructions and servicing	Product access requires verified current ownership or signatory authority.
Mobile-facing APIs	Approved customer mobile applications	Versioned discovery/read/instruction/status and security journeys	Native mobile UI is outside the current implementation scope; equivalent action proof applies.
ATM application	ATM customers, with separately authenticated terminal operators	Secure terminal sessions, device workflow and switch coordination	Terminal operation requires device, switch and network commissioning evidence.

All applications share institution/product policy and financial services. They receive distinct credentials/scopes, trusted origins or device trust, data projections, rate controls and audit channels. Business calculations are implemented in the shared authorised service boundary.

Proposed code ownership

The planned workspace structure includes apps/super-admin, apps/banking-ops, apps/customer-web, apps/atm, a shared domain/API service and packages for UI/contracts. Mobile APIs are an independently versioned interface within the server boundary. Split deployment/service boundaries when reliability, certification or isolation requires it, after design review. This is a proposal, not repository scaffolding. Operations navigation retains the workspace during internal movement. Search → detail → action → saved status → return restores filters. Customers see only enabled, commissioned products. A disabled offering returns a safe denial even if a caller bypasses the menu.

Common channel acceptance

Sign in/enrol → discover authorised products → read fresh context → quote → consent/proof → submit once → inspect status → recover unknown outcome → see statement/history. Test logout, revoked access, session/device expiry, business-date boundaries and two-institution isolation in every channel.

​Proposed code ownership

​Common channel acceptance

Proposed code ownership

Common channel acceptance