> ## 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. # B13 Credit underwriting and decisioning > Record reproducible, authorised credit decisions and policy exceptions. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Underwriting decides whether the institution is willing to lend, how much and under which approved conditions. It records evidence and accountable decision authority; it does not move funds or replace the customer’s agreement. | Attribute | Module definition | | - | - | | Entry condition | A lending or credit-card application needs assessment, sanction or exception review. | | Owned records | Assessment inputs, policy version, decision, conditions and exception reasons. | | Functional output | A reproducible approved/declined/conditional credit decision. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations credit-review workspace; customer channels receive only the permitted offer/decision communication. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B12 Loan origination](/banking/modules/b12) | B12 collects/co-ordinates the application; B13 assesses it and records sanction authority. | | [B20 Credit card accounts billing and servicing](/banking/modules/b20) | B13 supplies a credit decision; B20 operates a revolving card receivable under the accepted limit. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Credit analyst; credit approver; policy owner; risk 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: APP-001 / policy CREDIT-DEMO-v1. | Stage | Example | | - | - | | Starting situation | An analyst assesses the INR 120,000.00 application using a versioned policy. | | Operator/customer actions | Record consented income/bureau inputs, compute explainable outcomes and route any deviation to the authorised credit approver. | | Expected normal outcome | The decision can be reproduced from its input and policy version; sanctioned amount and reason are recorded. | | Failure or alternate outcome | The analyst cannot approve their own prohibited deviation or reuse an expired bureau result. | 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: Collect consented inputs to present reasoned offer ```mermaid theme={null} flowchart TD START["B13-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Collect consented inputs"] N0 --> N1 N1["compute policy outcomes"] N1 --> CHECK{"Inputs current and approver permitted"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N2 N2["review exceptions"] N2 --> N3 N3["approve/decline"] N3 --> N4 N4["save input/policy version"] N4 --> N5 N5["present reasoned offer"] 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: Revised evidence or expired bureau result to obtain new authority ```mermaid theme={null} flowchart TD START["B13-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Revised evidence or expired bureau result"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["invalidate affected offer"] N1 --> N2 N2["rerun approved assessment"] N2 --> N3 N3["obtain new authority"] N3 --> 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 | | - | - | - | | B13-F1: Versioned policy rules and decision inputs | Record the evidence snapshot and approved decision-policy version. | Reassessment does not overwrite the inputs used for an earlier decision. | | B13-F2: Bureau/exposure and affordability assessment | Review permitted bureau/exposure and affordability evidence with completeness labels. | Missing/stale evidence cannot be silently treated as a favourable result. | | B13-F3: Manual review and documented policy deviations | Assign an exception to the proper reviewer and record its justification. | Deviations remain attributable and cannot bypass the approved authority matrix. | | B13-F4: Independent sanction authority and exception controls | Obtain the required independent sanction for amount, conditions and validity. | A current authorised decision is linked to the original assessment. | | B13-F5: Decision explanation, appeals and historical reproducibility | Explain decision reasons and retain appeal/review history. | The institution can reproduce why the original outcome was reached. | ## Required configuration Score/policy versions; exposures; affordability; delegation; deviation limits; manual review; reason codes. 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 Collect consented inputs → compute policy outcomes → review exceptions → approve/decline → save input/policy version → present reasoned offer. 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 Revised evidence or expired bureau result → invalidate affected offer → rerun approved assessment → obtain new authority. 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 Permitted bureau data; policy engine; exposure; sanctions; adverse-decision notices. 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 operational underwriting or credit policy engine exists. Reviewed legacy feature boundaries: No operational source module was found. Legacy feature presence is a reuse candidate, not acceptance or deployment evidence for this module. ## Acceptance criteria and exception scenarios Explicit cases: Stale bureau; missing income; self-sanction; aggregate exposure across programmes. * 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.** Credit-policy/model ownership, override authority and sanction delegation. 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.