A borrower walks into a bank’s SME branch for a working capital loan. Six months later, the same borrower’s group entity draws down a supply chain finance facility through a different vertical. Neither team knows about the other’s exposure until the group starts missing payments and credit ops is left reconstructing the full picture from three separate systems, under pressure, after the damage is already done.
This risk is more likely where lending platforms were implemented at different times for separate product lines and do not share a reliable customer identity and connected-counterparty model.
Quick Answer
A single customer exposure view aggregates funded and non-funded facilities for one borrower and, where applicable, a group of connected counterparties across products, branches and business units. It helps credit teams assess concentration before approving new exposure and supports reporting under the RBI’s Large Exposures Framework. The view should be timely enough for the decision being made, although not every source system will update in real time.
What a Single Customer Exposure View Actually Means
A single customer exposure view is more than a periodic board report. It consolidates funded and non-funded facilities, including term loans, working-capital limits, guarantees, letters of credit and relevant supply chain finance exposures, against a legal entity and its connected-counterparty group. Update frequency should match the institution’s approval, monitoring and reporting requirements.
The connected-counterparty dimension matters as much as the individual customer record. Under the RBI framework, counterparties may form a connected group through control or economic interdependence. Different legal names and identifiers therefore do not remove the need to assess whether entities should be considered together for concentration risk.
Under the Reserve Bank of India’s Large Exposures Framework, a bank’s exposure to a single counterparty is generally limited to 20% of its eligible capital base, with a board-approved additional 5% permitted in exceptional cases. Exposure to a group of connected counterparties is limited to 25%. Institutions should apply the current framework, exemptions and counterparty-specific provisions to their own facts rather than relying on these headline limits alone.
Why Exposure Silos Happen in Lending Organizations
Most exposure blind spots are not caused by bad underwriting. They are caused by architecture.
- Product-line systems that don’t talk to each other. LOS handles origination, LMS handles servicing, SCF platforms handle receivables and payables finance. Each was often procured separately, at different times, sometimes from different vendors.
- Inconsistent customer identifiers. A borrower onboarded through retail lending may be keyed differently than the same borrower onboarded through commercial or SCF channels, especially before Permanent Account Number (PAN) or Corporate Identification Number (CIN) based matching was standardized.
- Branch and regional autonomy. Larger banks and NBFCs with wide branch networks often have exposure data that lives at the branch or regional level before it consolidates centrally, sometimes with a lag of days or weeks.
- Group structures that aren’t mapped. Even when a single borrower’s own exposure is visible, the borrower’s parent, subsidiaries, and affiliated entities frequently are not linked in the system. Regulators are now trying to close this gap.
The Regulatory Push Behind This
CRIF High Mark’s June 2026 MSMEx Spotlight reports a large and growing MSME credit market, with micro exposures accounting for most active loans in the dataset. That scale makes consistent identity matching and consolidated exposure monitoring operationally important. The report describes market composition; it does not measure the frequency of exposure-limit breaches or prove that borrowers hold facilities across multiple lenders.
The regulatory requirement is established through the RBI’s Large Exposures Framework for banks and the applicable concentration-risk rules for NBFCs. The precise denominator, exemptions, thresholds and reporting obligations depend on the institution’s category and the current directions. Legal and compliance teams should validate those requirements against official RBI instruments before the exposure view is configured.
These requirements make data lineage, entity resolution and reproducible exposure calculations essential. Product-specific systems may provide inputs, but a lender still needs governed rules for combining them into an auditable exposure figure.
Siloed Exposure Tracking vs. a Consolidated View
| Dimension | Siloed (product-by-product) | Single customer exposure view |
| Data refresh | Batch, often overnight or weekly | Frequency matched to approval and monitoring needs |
| Entity matching | Manual reconciliation across systems | Rules-assisted matching using identifiers and verified hierarchies |
| Group/connected-party visibility | Usually absent or manually maintained | Maintained through a governed connected-party hierarchy |
| Regulatory reporting effort | High, manual aggregation before submission | Potentially lower when calculations and lineage are governed |
| Early warning on limit breaches | Reactive, discovered after the fact | Can flag thresholds before approval when data is current |
| Cross-sell and collections impact | Teams work with partial customer context | Broader relationship context available to authorised teams |
What to Look for When Evaluating This Capability
If you are assessing whether your LOS, LMS, and SCF platforms can support a genuine single customer exposure view, a few questions separate a real capability from a dashboard that only looks consolidated:
- Does the system perform entity resolution using PAN, CIN, or GST (Goods and Services Tax) identifiers, or does it rely on name matching alone?
- Can it map group and connected-party hierarchies, including common directorship and cross-guarantees, not just parent-subsidiary relationships?
- Is exposure data updated as facilities are disbursed, restructured, or closed, rather than refreshed on a batch cycle?
- Does the aggregation span origination, servicing, and SCF data, or only one product line?
- Can credit ops set and monitor internal exposure thresholds ahead of the regulatory caps, not just at the caps?
- Does the system generate an auditable trail showing how an exposure figure was calculated, for regulatory reporting purposes?
Implementation Isn’t Just a Data Problem
Building this view is harder than merely adding a dashboard, mainly because the underlying data was never designed to be joined. Legacy core banking and legacy LOS platforms frequently store customer records with inconsistent formatting, duplicate entries for the same borrower, and no standard field for group affiliation.
That may look like a straightforward data-cleaning exercise. But it usually is not. It requires an ongoing entity resolution process, not a one-time cleanup, because new borrowers, new group structures, and new connected-party relationships are created every time a facility is originated.
Bottom Line
A single customer exposure view supports concentration-risk controls, regulatory reporting and better-informed credit decisions. Its value depends on accurate identity resolution, connected-party mapping, clear calculation rules, reliable source data and updates that arrive before a relevant approval or monitoring action. A dashboard without those foundations can consolidate errors as easily as it consolidates exposure.
Frequently Asked Questions (FAQs)
Entities are treated as connected when they share control, common management, or economic interdependence, meaning financial distress in one is likely to cause distress in the other, even without direct ownership links.
No. It applies across the portfolio, including MSME and retail borrowers who may hold multiple facilities across a lender’s product lines, which is where blind spots are most common given how much of India’s active loan volume sits in the micro segment.
In some cases, yes, through an integration or data layer that performs entity resolution across existing platforms. Whether that is sufficient depends on how consistently customer identifiers are captured across those systems today.
