> ## 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.

# B35 Customer digital identity and security

> Verify customer access to products and secure web/mobile sessions without treating staff access as customer authority.

**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.

| Attribute | Module definition |
| - | - |
| Entry condition | A customer registers, signs in, links a product, proves an action or recovers access. |
| Owned records | Customer digital identity, verified product link, factor/device and session/proof. |
| Functional output | A scoped customer session or action proof, with attributable revocation and recovery history. |
| Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. |
| Application entry points | Customer Web and authorised mobile clients for registration, proof, sessions and recovery; separately authorised Banking Operations staff may assist verified recovery. Access is governed by the approved institution permission matrix. |

### How it differs from related modules

| Related module | Boundary and handoff |
| - | - |
| [B02 Staff identity and access](/banking/modules/b02) | B02 manages employee logins; B35 manages customer logins with different recovery/ownership evidence. |
| [B05 Customer relationships and servicing view](/banking/modules/b05) | B05 records/presents product relationships; B35 derives permitted digital access from verified current relationships. |

Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/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.

| Stage | Example |
| - | - |
| Start | A customer loses a phone that still has an active mobile session. |
| Actions | Revoke the device/session through the approved verified recovery path and require fresh proof/enrollment before restoring sensitive access. |
| Expected outcome | The old device is denied; the new session sees only current linked products and mandates. |
| Failure | Knowledge of the customer's email/phone alone cannot restore financial authority. |

## 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

```mermaid theme={null}
flowchart TD
  A["B35-J1 request"] --> B{"Actor and offering permissions"}
  B -->|No| X["Deny safely"]
  B -->|Yes| N0
  N0["Verify customer/mandate"] --> N1
  N1["register accepted factors"] --> N2
  N2["sign in"] --> N3
  N3["discover authorised products"] --> N4
  N4["prove sensitive action"] --> N5
  N5["inspect status/security history"] --> N6
  N6["sign out"] --> C
  C{"Authoritative completion verification"}
  C -->|Yes| D["Record confirmed outcome and audit"]
  C -->|No or unknown| E["Keep original reference and reconcile"]
```

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

```mermaid theme={null}
flowchart TD
  A["B35-J2 request"] --> B{"Actor and offering permissions"}
  B -->|No| X["Deny safely"]
  B -->|Yes| N0
  N0["Device lost or relationship removed"] --> N1
  N1["revoke affected authority"] --> N2
  N2["verify recovery or changed mandate"] --> N3
  N3["fresh enrollment/login"] --> N4
  N4["confirm only current product access"] --> C
  C{"Authoritative completion verification"}
  C -->|Yes| D["Record confirmed outcome and audit"]
  C -->|No or unknown| E["Keep original reference and reconcile"]
```

## Required features

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

| Feature | What the user or service does | Completion evidence |
| - | - | - |
| B35-F1: Customer registration and verified product linking | Verify the customer/signatory and product ownership before digital linking. | A matching email or guessed account reference grants no access. |
| B35-F2: Web/mobile login, factors and device/session lifecycle | Enrol adopted factors/devices and create expiring web/mobile sessions. | Every protected request checks current identity and product scope. |
| B35-F3: Sensitive-action proof bound to intent | Bind sensitive-action proof to the accepted intent, amount, destination and validity. | Reusing proof for a changed or later instruction is rejected. |
| B35-F4: Own-session/device revocation and security history | Show own device/session/security history and support explicit revocation. | Revoked sessions/proofs no longer authorise protected work. |
| B35-F5: Verified recovery, fraud containment and relationship-change revocation | Verify recovery evidence and invalidate affected access after fraud or relationship change. | Recovery cannot transfer another customer’s products to the requester. |

## 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](/banking/journeys) and the [scenario matrix](/banking/scenario-matrix).

## Required implementation inputs

**Status: Pending institution confirmation.** Customer factors, ownership evidence, device controls and recovery authority.

[Module register](/banking/module-register) · [Decision register](/banking/decisions)


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