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

# B28 Communications documents and consent

> Deliver the correct disclosures and documents through verified channels and retain evidence.

**Review draft • 14 October 2026 • New Banking project • Implementation not started.**

## Definition and responsibility

Communications produces and delivers the approved document or notice for a banking event, with consent and evidence. Sent, delivered, read and accepted are separate facts. This module does not decide the underlying financial terms.

| Attribute | Module definition |
| - | - |
| Entry condition | An operation requires a disclosure, agreement, statement, notification or consent record. |
| Owned records | Template version, document, delivery attempt, preference and acceptance evidence. |
| Functional output | The correct recipient can access the exact approved content and its delivery/acceptance status. |
| Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. |
| Application entry points | Banking Operations template/delivery administration; Customer Web/mobile receive permitted own documents, notices and consent requests. Access is governed by the approved institution permission matrix. |

### How it differs from related modules

| Related module | Boundary and handoff |
| - | - |
| [B03 Product and programme configuration](/banking/modules/b03) | B03 owns product economics/disclosure policy; B28 renders and delivers the approved version. |
| [B29 Management and regulatory reporting](/banking/modules/b29) | B28 produces recipient documents; B29 produces governed operational/regulatory data reports. |

Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms.

Planned operating duties: Customer; communication owner; document reviewer; service operator. Access to these duties requires the approved institution permission matrix. The bank or authorised regulated entity owns product policy and financial outcomes. Platform operators receive no automatic customer-data, fund-movement or issuer authority.

## 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 requirements illustration, not seeded data or approved banking policy.** Reference: DOC-001 / loan agreement version 1.

| Stage | Example |
| - | - |
| Starting situation | A borrower has accepted a verified loan agreement. |
| Operator/customer actions | Generate the signed version, deliver to the verified permitted destination and retain secure access and delivery evidence. |
| Expected normal outcome | The downloaded document hash/version matches the accepted agreement; delivery failure is visible. |
| Failure or alternate outcome | Changing the email destination or template cannot silently resend another customer's document. |

No real customer, regulator approval, provider connection or bank operation is asserted. Illustrative amounts have currency INR and scale 2; actual economics/authority must be supplied by the institution.

## Module flow diagrams

Read each flow from top to bottom. Rectangles are actions or recorded outcomes; diamonds are decisions; labelled arrows show the next permitted route. The denial route stops the operation. The pending/unknown route keeps the original reference for investigation instead of claiming success. Each diagram corresponds to the numbered journey below.

Planned workflows are shown below. Execution depends on confirmed institution policy and interface contracts.

### Flow 1: Authoritative event to provide secure customer copy

```mermaid theme={null}
flowchart TD
  START["B28-J1 request"] --> ACCESS{"Actor, institution and offering permissions"}
  ACCESS -->|No| DENY["Deny without exposing other data"]
  ACCESS -->|Yes| N0
  N0["Authoritative event"]
  N0 --> N1
  N1["select approved template/recipient"]
  N1 --> CHECK{"Recipient, consent and document version valid"}
  CHECK -->|No| STOP["Stop: resolve evidence or eligibility"]
  CHECK -->|Yes| N2
  N2["generate document"]
  N2 --> N3
  N3["deliver via contracted channel"]
  N3 --> N4
  N4["capture status"]
  N4 --> N5
  N5["provide secure customer copy"]
  N5 --> RESULT
  RESULT{"Completion evidence verification"}
  RESULT -->|Yes| DONE["Record outcome, audit and return"]
  RESULT -->|Pending or unknown| HOLD["Keep original reference; reconcile status"]
  HOLD --> REVIEW["Authorised resolution; no blind retry"]
```

### Flow 2: Delivery fails to record final result

```mermaid theme={null}
flowchart TD
  START["B28-J2 request"] --> ACCESS{"Actor, institution and offering permissions"}
  ACCESS -->|No| DENY["Deny without exposing other data"]
  ACCESS -->|Yes| N0
  N0["Delivery fails"]
  N0 --> CHECK{"State and approval eligibility"}
  CHECK -->|No| STOP["Stop: resolve evidence or eligibility"]
  CHECK -->|Yes| N1
  N1["retain failure"]
  N1 --> N2
  N2["verify destination or use approved alternative"]
  N2 --> N3
  N3["retry same notice safely"]
  N3 --> N4
  N4["record final result"]
  N4 --> RESULT
  RESULT{"Outcome verification"}
  RESULT -->|Yes| DONE["Record outcome, audit and return"]
  RESULT -->|Pending or unknown| HOLD["Keep original reference; reconcile status"]
  HOLD --> REVIEW["Authorised resolution; no blind retry"]
```

## 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 |
| - | - | - |
| B28-F1: Disclosures, agreements, statements and certificates | Render the adopted disclosure/agreement/statement/certificate from verified source facts. | Recipient, source date and template version match the operation. |
| B28-F2: Secure document generation/download and integrity | Generate integrity-protected documents with scoped authenticated downloads. | Another institution/customer cannot obtain the file by guessing its reference. |
| B28-F3: Transactional notices and permitted campaigns | Send permitted transactional or campaign content through contracted channels. | Purpose, recipient and applicable preference/consent are recorded. |
| B28-F4: Delivery status, bounce/failure handling and manual follow-up | Track provider delivery, bounce/failure and approved follow-up without false success. | A retry retains the original notice identity and accurate delivery status. |
| B28-F5: Consent/preferences and template approval history | Record consent, preference changes and independent template approval. | Later content use can show the effective authorisation and exact version. |

## Required configuration

Templates/version; event/recipient; consent; verified destination; delivery retry; document access/retention. Store approved values in versioned, effective-dated product/programme policy. Capture the exact configuration version used by an instruction. Missing mandatory configuration blocks the dependent action; enabling a menu cannot grant legal authority.

## End-to-end journey 1

Authoritative event → select approved template/recipient → generate document → deliver via contracted channel → capture status → provide secure customer copy.

The journey ends only when its authoritative result, customer/staff-visible result and related book or case history agree. A saved request, queue entry or HTTP acknowledgement is an intermediate state.

## End-to-end journey 2

Delivery fails → retain failure → verify destination or use approved alternative → retry same notice safely → record final result.

Every transition needs an authorised actor, original version and recorded reason where required. Cancellation or client disconnection does not prove server rollback. Financial corrections retain their original reference and use linked reversal/adjustment entries rather than deleting history.

## Interfaces and data dependencies

Template owner; delivery connector; signature; secure storage; verified destination. Agree stable institution, product, party and operation references; source version; as-of time; completeness; status/finality; retry rules and correction handling. Where no financial posting occurs, record the administrative/case outcome instead of inventing a journal.

All channel requests use server-verified identity and institution scope. Partner, branch and customer access is narrower than institution membership. Lists, details, search, exports, callbacks and files must enforce the same boundary.

## Current implementation and reuse

**New Banking project: proposed, not built.** Existing private document/notification foundations exist; no complete outbound-delivery platform.

Reviewed legacy feature boundaries: `documents`, `consumer-notifications`, `staff-notifications`. See the source inventory on the [gap page](/banking/current-system-gap). Legacy feature presence is a reuse candidate, not acceptance or deployment evidence for this module.

## Acceptance criteria and exception scenarios

Explicit cases: Wrong recipient; expired download; duplicate notice; attachment mismatch; consent revoked.

* Allowed success: confirm saved/output values, authoritative status and the exact approved actor/channel.
* Denial: reject foreign institution, unauthorised branch/customer/programme and revoked or expired access without information leakage.
* Reliability: prove stale-version rejection and concurrency behaviour; retryable commands apply one economic effect; unknown financial outcomes are reconciled by original reference.
* Records and usability: preserve redacted audit, monetary precision and document integrity; verify keyboard/mobile, direct links, expired sessions, Back/Forward and return navigation. Internal web navigation preserves its workspace.

Apply the [scenario matrix](/banking/scenario-matrix) and the [shared journey rules](/banking/journeys). Timing, amounts and regulatory applicability are institution-owned inputs, not defaults supplied by this document.

## Required implementation inputs

**Status: Pending institution confirmation.** Mandatory notice events, delivery channels, approved templates and retention rules by offering.

Implementation dependencies and approvals are recorded in the [decision register](/banking/decisions).

[Module register](/banking/module-register) · [Offering compatibility](/banking/offering-matrix)


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