> ## 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. # B15 Collateral and securities > Track pledged assets and enforce release only when the secured obligation permits it. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Collateral management records an asset pledged as security, its ownership, valuation and the obligations it secures. It does not approve credit or assume that an uploaded property document creates an enforceable charge. | Attribute | Module definition | | - | - | | Entry condition | A secured facility needs valuation, pledge allocation, monitoring or release. | | Owned records | Secured asset, evidence, valuation, encumbrance and release authority. | | Functional output | A traceable security position linked to the correct facilities and controlled release status. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations security/collateral workspace; customer channels expose only permitted own evidence or requests. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B13 Credit underwriting and decisioning](/banking/modules/b13) | B15 provides verified security facts; B13 considers them in a credit decision. | | [B14 Loan servicing and repayment](/banking/modules/b14) | B14 confirms the serviced obligation; B15 checks it before releasing its security. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Collateral officer; valuer; legal reviewer; credit approver. 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: SEC-001 / loan LN-001. | Stage | Example | | - | - | | Starting situation | A property is proposed as security for a loan. | | Operator/customer actions | Verify title and valuation, record the approved charge, allocate security to LN-001 and monitor the permitted coverage rule. | | Expected normal outcome | Security ownership, valuation version, charge evidence and linked facility are visible to authorised roles. | | Failure or alternate outcome | A partial release that violates approved coverage or retains an outstanding charge is blocked. | 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: Register security to release after authorised discharge ```mermaid theme={null} flowchart TD START["B15-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Register security"] N0 --> N1 N1["verify title/value"] N1 --> CHECK{"Title, charge and coverage valid"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N2 N2["create permitted charge"] N2 --> N3 N3["link facility"] N3 --> N4 N4["monitor coverage"] N4 --> N5 N5["release after authorised discharge"] 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: Valuation falls to retain valuation history ```mermaid theme={null} flowchart TD START["B15-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Valuation falls"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["calculate shortfall"] N1 --> N2 N2["notify owner"] N2 --> N3 N3["approve top-up/substitution or action"] N3 --> N4 N4["retain valuation history"] 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 | | - | - | - | | B15-F1: Asset and ownership registry | Register the asset and legal owners with original evidence references. | Asset identity and ownership can be distinguished from borrower identity. | | B15-F2: Valuation, legal evidence and charge creation | Record valuation date/method, legal checks and confirmed charge evidence. | An unverified document stays pending rather than becoming confirmed security. | | B15-F3: Collateral-to-facility allocation and encumbrance | Allocate security to facilities and track existing encumbrances. | Exposure coverage uses current approved values without double-counting the asset. | | B15-F4: Revaluation, insurance expiry and shortfall monitoring | Monitor revaluation/insurance dates and raise shortfall or expiry cases. | Exceptions have an owner and link to the affected facilities. | | B15-F5: Substitution, partial release and final discharge | Check all secured obligations before approved substitution or release. | Released security retains its original allocation and discharge evidence. | ## Required configuration Asset types; title/charge checks; valuation frequency; LTV; insurance; pooled security; release authority. 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 Register security → verify title/value → create permitted charge → link facility → monitor coverage → release after authorised discharge. 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 Valuation falls → calculate shortfall → notify owner → approve top-up/substitution or action → retain valuation history. 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 Asset ownership/valuation; registry charge evidence; facility balances; release confirmation. 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 collateral/security management 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: Same asset double pledged; stale valuation; partial release breaches coverage; missing charge evidence. * 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.** Initial collateral asset classes and valuation/release authorities. 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.