Skip to main content
Review draft • 14 October 2026 • New Banking project • Proposed, not built.

​
Definition and responsibility

Customer digital identity proves which person/signatory is using web or mobile and which products they may access. Linking an email is insufficient ownership evidence. Sensitive-action proof must refer to the specific action the customer accepted. Read the module comparison map for the whole platform and the glossary for shared terms. Planned operating duties: Customer; verified business signatory; customer security reviewer; recovery officer. The institution owns rules and authority; this specification grants none.

​
Worked Indian example

Use the four stages below to distinguish the initial facts, the action to test, confirmed completion and the alternate result. This example exercises this module’s responsibility; related modules still own the handoffs listed above. Fictional illustration, not seeded data or approved policy. CUSTOMER-001 / old mobile device.

​
Module flow diagrams

Read top to bottom: rectangles describe actions/outcomes; diamonds describe decisions. Follow denial and unknown-result routes as well as success. Each diagram matches its numbered journey below; a request acknowledgement does not prove final completion.

​
Flow 1: Verify customer/mandate to sign out

​
Flow 2: Device lost or relationship removed to confirm only current product access

​
Required features

Planned functionality is listed below. Implementation requires confirmed field definitions, permissions, state transitions and product economics for the selected offering.

​
Required configuration

Eligibility/ownership proof; factors; device/session policy; recovery; consent; step-up and notice policy. Use approved, effective-dated versions; bind each sensitive intent to its original terms and approval. Missing required evidence or policy blocks the dependent action.

​
End-to-end journey 1

Verify customer/mandate → register accepted factors → sign in → discover authorised products → prove sensitive action → inspect status/security history → sign out.

​
End-to-end journey 2

Device lost or relationship removed → revoke affected authority → verify recovery or changed mandate → fresh enrollment/login → confirm only current product access. A request acknowledgement is not a final financial/security result. Reconcile the original reference rather than blindly retrying after an uncertain response. Corrections preserve original history.

​
Interfaces and data dependencies

Verified customer relationship; accepted factor/proof policy; mobile device/session contract; recovery evidence/notices. Confirm stable institution/resource IDs, freshness, completeness, status/finality, correction ordering and exact money representation. Web/mobile/ATM must not duplicate policy calculations or widen authority.

​
Current implementation and reuse

New Banking project: not built. Synthetic customer password/link/session foundations exist; real eligibility, proof/factor and recovery contracts remain incomplete. Reviewed legacy feature boundary: consumer-access, consumer-auth, consumer-sessions, consumer-account-links.

​
Acceptance criteria and exception scenarios

Stolen device; recycled phone number; joint mandate removed; duplicate proof; weak recovery bypass; app reinstall. Verify permitted success, foreign institution/branch/customer denial, current revoked authority, stale state, concurrent/repeated actions, outages/unknown outcomes and redacted audit. Test exact book/counter effects where applicable and safe list → detail → action → result → return navigation. Apply shared journeys and the scenario matrix.

​
Required implementation inputs

Status: Pending institution confirmation. Customer factors, ownership evidence, device controls and recovery authority. Module register · Decision register