> ## Documentation Index
> Fetch the complete documentation index at: https://banking.nextedge.consulting/llms.txt
> Use this file to discover all available pages before exploring further.

# Applications and channel boundaries

> Five application surfaces sharing authorised business services without sharing privileges.

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](/banking/apps/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](/banking/apps/banking-ops) | 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](/banking/apps/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](/banking/apps/mobile-api) | 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](/banking/apps/atm) | 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.