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

# B34 Approvals limits and operational controls

> Apply cross-channel approval and aggregate controls before a financial or sensitive administrative action can execute.

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

## Definition and responsibility

Operational approval controls evaluate one specific proposed action: who initiated it, who may approve it and whether limits and current conditions permit execution. A role grants eligibility; it does not let its holder approve their own work automatically.

| Attribute | Module definition |
| - | - |
| Entry condition | A financial or sensitive administrative command reaches its approval/limit gate. |
| Owned records | Bound action intent, approval decision, consumed limit and exception authority. |
| Functional output | An executable or rejected/expired intent with attributable independent decisions. |
| Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. |
| Application entry points | Banking Operations independent approval queues and shared service gates across channels. Customers initiate eligible intents, not staff approval duties. 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 grants the staff duty; B34 verifies its independent use for this exact action. |
| [B03 Product and programme configuration](/banking/modules/b03) | B03 supplies the approved product policy version; B34 evaluates action-specific approval and aggregate limits. |

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

Planned operating duties: Operation maker; independent checker; policy owner; risk; 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.** PAY-APP-001 / two channels / illustrative INR 10,000.00 daily limit.

| Stage | Example |
| - | - |
| Start | Web and mobile concurrently request INR 6,000.00 each under a fictional shared limit. |
| Actions | Use a single authoritative counter/reservation boundary and independent approval where the adopted matrix requires it. |
| Expected outcome | Both cannot be admitted against the same INR 10,000.00 capacity. The limit value is illustrative, not adopted bank policy. |
| Failure | A screen-local counter or a maker approving their own prohibited payment fails acceptance. |

## 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: Create exact operation intent to reconcile

```mermaid theme={null}
flowchart TD
  A["B34-J1 request"] --> B{"Actor and offering permissions"}
  B -->|No| X["Deny safely"]
  B -->|Yes| N0
  N0["Create exact operation intent"] --> N1
  N1["evaluate policy/limits"] --> N2
  N2["obtain independent approval/proof"] --> N3
  N3["recheck current state"] --> N4
  N4["reserve permitted capacity"] --> N5
  N5["execute once"] --> N6
  N6["reconcile"] --> 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: Intent changes or approver revoked to reject or resubmit explicitly under new intent

```mermaid theme={null}
flowchart TD
  A["B34-J2 request"] --> B{"Actor and offering permissions"}
  B -->|No| X["Deny safely"]
  B -->|Yes| N0
  N0["Intent changes or approver revoked"] --> N1
  N1["invalidate affected approval"] --> N2
  N2["obtain fresh context/authority"] --> N3
  N3["reject or resubmit explicitly under new intent"] --> 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 |
| - | - | - |
| B34-F1: Versioned maker-checker and delegation matrices | Version maker/checker/delegation rules by institution, duty and action class. | The initiator cannot satisfy a required independent approval. |
| B34-F2: Exact per-operation and aggregate/daily limits across channels | Check exact operation and shared aggregate limits atomically across channels. | Concurrent web/mobile/ATM requests cannot each spend the same remaining allowance. |
| B34-F3: Approval queues, evidence, reasons and expiry | Present queued intent/evidence and record reasons, expiry and decisions. | Approval references the exact amount/destination/configuration version being reviewed. |
| B34-F4: Bound intent, current eligibility and concurrency checks | Recheck bound intent, current permissions and state immediately before execution. | Changed or stale instructions need the adopted reapproval path. |
| B34-F5: Controlled exception authority and complete decision history | Route exception requests only to adopted higher authority and retain full history. | A limit override never becomes a silent permanent bypass. |

## Required configuration

Duty/action/amount matrix; branch/product scope; aggregate limits; proof; approval expiry; exceptions. 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

Create exact operation intent → evaluate policy/limits → obtain independent approval/proof → recheck current state → reserve permitted capacity → execute once → reconcile.

## End-to-end journey 2

Intent changes or approver revoked → invalidate affected approval → obtain fresh context/authority → reject or resubmit explicitly under new intent.

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

Approved matrix; exact amount/limit counters; current duty/evidence; quote and operation hash; release of reservations. 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.** Saved currency-control configuration exists, but no general financial approval/enforcement engine exists. Reviewed legacy feature boundary: transaction-controls (saved settings only).

## Acceptance criteria and exception scenarios

Maker checks own operation; two channels exceed shared daily limit; stale approval; changed beneficiary; expired proof. 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.** Action/amount-specific maker, checker and override authority; aggregate-counter reset/release 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.