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

# B33 Cheque operations and clearing

> Manage cheque books, instruments, clearing and returns with linked financial evidence.

**Review draft • 14 October 2026 • New Banking project • Proposed, not built.**

## Definition and responsibility

Cheque operations manage physical cheque instruments and their clearing/return lifecycle. Issuing a cheque book does not debit an account. A stop-payment request and a cheque already presented for clearing need separate confirmed states.

| Attribute | Module definition |
| - | - |
| Entry condition | A customer requests a cheque book, stops an instrument or a clearing item arrives. |
| Owned records | Cheque range, instrument, stop instruction, clearing item and return. |
| Functional output | A confirmed instrument disposition linked to its clearing/posting/settlement evidence. |
| Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. |
| Application entry points | Banking Operations cheque/clearing servicing; permitted Customer Web/mobile cheque requests and own status. Access is governed by the approved institution permission matrix. |

### How it differs from related modules

| Related module | Boundary and handoff |
| - | - |
| [B11 Payments beneficiaries and mandates](/banking/modules/b11) | B11 owns electronic payment instructions; B33 owns cheque-specific instrument and clearing facts. |
| [B24 Reconciliation and exception management](/banking/modules/b24) | B33 records clearing/return outcomes; B24 matches them against financial and settlement sources. |

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

Planned operating duties: Customer; cheque operations; branch officer; clearing finance. 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.** CHQ-001 / ACC-001 / INR 5,000.00.

| Stage | Example |
| - | - |
| Start | A customer reports a cheque lost while its clearing status is not final. |
| Actions | Verify the customer mandate/instrument and submit one stop request; read the clearing authority's effective outcome. |
| Expected outcome | Only a confirmed effective stop is shown as stopped. If already paid, route the customer to the appropriate dispute/servicing path. |
| Failure | A saved stop request cannot be presented as a guaranteed prevented debit. |

## 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: Request book to reconcile statement

```mermaid theme={null}
flowchart TD
  A["B33-J1 request"] --> B{"Actor and offering permissions"}
  B -->|No| X["Deny safely"]
  B -->|Yes| N0
  N0["Request book"] --> N1
  N1["verify account/mandate"] --> N2
  N2["issue and deliver"] --> N3
  N3["capture permitted instrument details"] --> N4
  N4["present to clearing"] --> N5
  N5["confirm paid or returned"] --> N6
  N6["reconcile statement"] --> 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: Report lost cheque to notify

```mermaid theme={null}
flowchart TD
  A["B33-J2 request"] --> B{"Actor and offering permissions"}
  B -->|No| X["Deny safely"]
  B -->|Yes| N0
  N0["Report lost cheque"] --> N1
  N1["verify instrument/account authority"] --> N2
  N2["submit stop"] --> N3
  N3["confirm effective status"] --> N4
  N4["handle any already-paid/clearing conflict"] --> N5
  N5["notify"] --> 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 |
| - | - | - |
| B33-F1: Cheque-book request, inventory and delivery | Verify entitlement and issue/deliver a controlled cheque-number range. | Inventory and customer delivery references agree without treating issue as payment. |
| B33-F2: Issued cheque and stop-payment servicing | Track an instrument and confirm stop-payment under adopted eligibility rules. | Current instrument/clearing state is checked before displaying an effective stop. |
| B33-F3: Outward/inward clearing with verified images/data | Validate permitted clearing images/data and record inward/outward processing references. | Each accepted item has one identifiable clearing/posting outcome. |
| B33-F4: Return reasons, linked charges and controlled correction | Record return reasons and approved charges/corrections linked to the original item. | Rejected instruments retain their history and financial corrections are traceable. |
| B33-F5: Clearing settlement and reconciliation | Match cheque-cycle totals with posted items and settlement funds. | Unmatched items remain explicit exceptions before cycle sign-off. |

## Required configuration

Instrument numbering; permitted accounts; positive-pay/proof rules; cutoff; returns; stop authority; fees. 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

Request book → verify account/mandate → issue and deliver → capture permitted instrument details → present to clearing → confirm paid or returned → reconcile statement.

## End-to-end journey 2

Report lost cheque → verify instrument/account authority → submit stop → confirm effective status → handle any already-paid/clearing conflict → notify.

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

Account/mandate; clearing/image/status contracts; instrument identity; stop finality; return and settlement files. 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.** No operational cheque book, stop-payment or clearing implementation exists. Reviewed legacy feature boundary: No operational module found.

## Acceptance criteria and exception scenarios

Stop races with clearing; duplicated presentment; signature mismatch; already paid instrument; wrong cheque range. 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.** Cheque services, clearing contracts, action proof and effective stop-payment rules.

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


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