B34 Approvals limits and operational controls

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.

Related module	Boundary and handoff
B02 Staff identity and access	B02 grants the staff duty; B34 verifies its independent use for this exact action.
B03 Product and programme configuration	B03 supplies the approved product policy version; B34 evaluates action-specific approval and aggregate limits.

Read the module comparison map for the whole platform and the 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

Flow 2: Intent changes or approver revoked to reject or resubmit explicitly under new intent

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 and the scenario matrix.

Required implementation inputs

Status: Pending institution confirmation. Action/amount-specific maker, checker and override authority; aggregate-counter reset/release rules. Module register · Decision register

Understand the modules

Core and operations modules

Lending modules

Cards and ATM modules

Control and delivery modules

B34 Approvals limits and operational controls

Definition and responsibility

Worked Indian example

Module flow diagrams

Flow 1: Create exact operation intent to reconcile

Flow 2: Intent changes or approver revoked to reject or resubmit explicitly under new intent

Required features

Required configuration

End-to-end journey 1

End-to-end journey 2

Interfaces and data dependencies

Current implementation and reuse

Acceptance criteria and exception scenarios

Required implementation inputs

​Definition and responsibility

​How it differs from related modules

​Worked Indian example

​Module flow diagrams

​Flow 1: Create exact operation intent to reconcile

​Flow 2: Intent changes or approver revoked to reject or resubmit explicitly under new intent

​Required features

​Required configuration

​End-to-end journey 1

​End-to-end journey 2

​Interfaces and data dependencies

​Current implementation and reuse

​Acceptance criteria and exception scenarios

​Required implementation inputs

Definition and responsibility

How it differs from related modules

Worked Indian example

Module flow diagrams

Flow 1: Create exact operation intent to reconcile

Flow 2: Intent changes or approver revoked to reject or resubmit explicitly under new intent

Required features

Required configuration

End-to-end journey 1

End-to-end journey 2

Interfaces and data dependencies

Current implementation and reuse

Acceptance criteria and exception scenarios

Required implementation inputs