> ## 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. # B11 Payments beneficiaries and mandates > Execute permitted payments with verified payees, proof, status recovery and reconciliation. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Payments move funds under a verified instruction. A beneficiary identifies the destination; a payment mandate authorises recurring collection or payment. A submitted instruction is not a settled transfer. | Attribute | Module definition | | - | - | | Entry condition | A customer/officer creates a payee, transfers funds or schedules an authorised payment. | | Owned records | Beneficiary, payment mandate, instruction and provider status. | | Functional output | A confirmed payment/return with original references, posting and reconciliation evidence. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations and eligible Customer Web/mobile payment instructions; the API carries the same server controls. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B21 Card authorisation clearing and settlement](/banking/modules/b21) | B11 owns non-card payment instructions; B21 processes card-network authorisation and clearing messages. | | [B24 Reconciliation and exception management](/banking/modules/b24) | B11 tracks instruction status; B24 compares it to books and complete external 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; payment maker/checker; operations exception officer. 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: PAY-001 / INR 2,500.00 domestic transfer. | Stage | Example | | - | - | | Starting situation | A customer transfers to a verified permitted payee; this illustration excludes fees. | | Operator/customer actions | Quote, enforce limits/funds, bind proof to amount/payee and submit using PAY-001 exactly once. Read authoritative outcome. | | Expected normal outcome | The payer/payee/rail references and reconciled debit agree. Pending is displayed until the bank confirms final status. | | Failure or alternate outcome | On timeout, query PAY-001; do not submit PAY-002 merely because the screen lost its response. | 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: Verify payee to reconcile ```mermaid theme={null} flowchart TD START["B11-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Verify payee"] N0 --> N1 N1["quote amount/fees"] N1 --> N2 N2["check limits and funds"] N2 --> N3 N3["prove/approve"] N3 --> CHECK{"Payee, limits, proof and funds valid"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N4 N4["submit once"] N4 --> N5 N5["track authoritative status"] N5 --> N6 N6["reconcile"] N6 --> 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: Provider times out to correct with linked entry if needed ```mermaid theme={null} flowchart TD START["B11-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Provider times out"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["retain original instruction/reference"] N1 --> N2 N2["query status"] N2 --> N3 N3["resolve confirmed/rejected/returned outcome"] N3 --> N4 N4["correct with linked entry if needed"] 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 | | - | - | - | | B11-F1: Beneficiary create/verify/activate/revoke | Capture and verify the payee before applying the adopted activation/revocation rules. | Payments use an eligible current beneficiary version. | | B11-F2: Internal transfer and enabled domestic payment rails | Offer only commissioned internal or domestic transfer routes for this institution/product. | The authoritative transfer result and financial references are retained. | | B11-F3: Scheduled/standing instructions and mandate lifecycle | Record recurrence, consent and validity of standing instructions or payment mandates. | Due instructions execute once and expired/revoked mandates cannot authorise new debits. | | B11-F4: Quote, proof, approval and idempotent submission | Bind quote, proof and approvals to the exact amount/destination/version before one submission. | Retries refer to the same original intent without another funds movement. | | B11-F5: Returns, failed/unknown status and reconciliation | Query unknown results and process linked returns with evidence. | Final payment state, corrective entries and customer history agree. | ## Required configuration Enabled rails; cutoffs; beneficiary verification; cooling periods; transaction/daily limits; fees; approval matrix. 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 Verify payee → quote amount/fees → check limits and funds → prove/approve → submit once → track authoritative status → reconcile. 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 Provider times out → retain original instruction/reference → query status → resolve confirmed/rejected/returned outcome → correct with linked entry if needed. 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 Rail eligibility; account verification; instruction/status; settlement; return/reversal contracts. 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.** No payment execution engine exists; saved limits do not enforce rail operations. Reviewed legacy feature boundaries: `transaction-controls`, `transaction-history (configuration/read only)`. 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: Duplicate click; cutoff transition; beneficiary changed after approval; unknown bank response. * 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.** First-release non-UPI payment rails, beneficiary verification and action-proof policies. UPI scope remains separately pending. 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.