> ## 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. # B05 Customer relationships and servicing view > Show a verified, scoped relationship between parties, accounts, cards, loans and servicing branches. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility The relationship view answers which verified customer owns, controls or services which account, loan or card. It combines references from their source modules; it is not a new financial book or a permission to edit every displayed item. | Attribute | Module definition | | - | - | | Entry condition | An authorised officer needs a customer’s servicing context or corrects a relationship. | | Owned records | Party-to-product relationship and its source/freshness information. | | Functional output | A scoped view of linked products, roles and permitted servicing entry points. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations for authorised servicing enquiry; customer channels expose only their own permitted relationships. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B04 Customer onboarding and KYC](/banking/modules/b04) | B04 establishes identity evidence; B05 uses the accepted party reference. | | [B06 Account lifecycle and mandates](/banking/modules/b06) | B06 owns the account’s legal holders and mandate; B05 presents that relationship without duplicating its authority. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Relationship manager; branch officer; customer service. 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: CUSTOMER-001 / ACC-001 and CARD-001. | Stage | Example | | - | - | | Starting situation | A Mumbai officer searches an exact bank-issued customer reference. | | Operator/customer actions | The server resolves the reference inside DEMOBANK, checks current branch/relationship authority and returns only permitted product links with as-of information. | | Expected normal outcome | The officer opens ACC-001 only if the relationship and scope are current. DEMONBFC's matching reference is not returned. | | Failure or alternate outcome | A removed or incomplete relationship cannot be treated as current authority. | 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: Find permitted customer to return ```mermaid theme={null} flowchart TD START["B05-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Find permitted customer"] N0 --> CHECK{"Current relationship and scope confirmed"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["verify identity context"] N1 --> N2 N2["inspect linked products"] N2 --> N3 N3["open a permitted detail"] N3 --> N4 N4["perform authorised servicing"] N4 --> N5 N5["return"] 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: Incorrect relationship reported to verify no stale authority ```mermaid theme={null} flowchart TD START["B05-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Incorrect relationship reported"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["preserve disputed evidence"] N1 --> N2 N2["approve correction"] N2 --> N3 N3["update affected access"] N3 --> N4 N4["verify no stale authority"] 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 | | - | - | - | | B05-F1: Exact customer search and authorised identity matching | Find an exact permitted customer reference and verify the institution/branch scope. | A foreign or ambiguous reference does not disclose customer details. | | B05-F2: Customer-to-account/card/loan relationships | Show account, card and loan links with relationship type and source reference. | Each link resolves to a permitted source record. | | B05-F3: Joint holders, nominees, guardians and business signatories | Distinguish owner, joint holder, nominee, guardian and signatory roles. | Displayed roles do not imply equal transaction authority. | | B05-F4: Consolidated holdings with source/as-of labels | Present holdings with source, as-of time and completeness labels. | A stale or partial feed is visibly different from a current complete view. | | B05-F5: Controlled corrections, merges and relationship history | Review relationship corrections or proposed merges with original-source evidence. | Approved corrections preserve previous links and revoke inappropriate access. | ## Required configuration Party/account relationships; signatory mandates; branch scope; masking; freshness; legal restrictions. 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 Find permitted customer → verify identity context → inspect linked products → open a permitted detail → perform authorised servicing → return. 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 Incorrect relationship reported → preserve disputed evidence → approve correction → update affected access → verify no stale 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 Stable party namespace; complete relationship graph; correction order; no-match/freshness semantics. 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.** Existing account snapshots/scoped enquiry are partial. The approved minimal customer lookup lacks its authoritative read contract. Reviewed legacy feature boundaries: `staff-enquiry`, `account-snapshots`, `source-mappings`. 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: Same reference in two banks; removed relationship; stale source; incomplete linked-account page. * 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.** Authoritative party identifiers and complete customer-product relationship source. 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.