The Same Customer, Four Times: Managing Total Exposure

A customer has a card, a personal loan, an overdraft, and now applies for something else. Each was assessed separately, each approval was sound, and nobody ever asked whether the total was. The assessments answered whether the household could service that product; none answered whether it could service all of them. Which means a lender can accumulate an aggregate exposure to one household that nobody would have approved as a single decision — and the failure isn't in any individual approval, it's that no decision was ever made about the sum.

Why product limits don't add up

Each assessment is locally correct and the aggregate isn't.

Assessment	Asks	Doesn't ask
Card application	Can they service this line?	What else do they have with us?
Loan application	Can they service this payment?	Same
Overdraft	Is this appropriate?	Same
Line increase	Have they handled the current line?	Same

Every row is a sensible question and the column on the right is empty. Per our affordability analysis, capacity is a household-level property — so assessing it product by product is assessing the wrong unit four times.

And there's a compounding mechanism per our line analysis: each approval changes the customer's position for the next one, and if the assessments run on stale data or don't see each other, the third approval is made on a picture that predates the first two.

Which is why this is an architecture question rather than a policy one. A limit that isn't checked at decision time is a report, not a control.

Identifying the same customer

The prerequisite, and harder than it sounds.

Aggregation is impossible without reliable matching, and matching fails in predictable ways:

• Name variations — married names, shortened forms, transliterations.
• Address changes between originations.
• Different products holding different identifiers.
• Systems acquired or migrated, each with its own customer key.
• Business and personal for the same individual, which per our small business analysis are frequently one financial unit.

The failure modes cut both ways and they aren't symmetric. Failing to match understates exposure, which is the risk. Over-matching attributes someone else's obligations to a customer, which per our error analysis is a mixed-file problem — and it produces a decline on grounds that are wrong and that the applicant can't contest because they never see it.

So the matching rule needs to be deliberate, documented, and reviewed — and it's a model input in the sense our attribute analysis describes, requiring the same governance as any other. Measure both error rates rather than only the one that costs you money.

What counts as exposure

The definitional question, and the commonly omitted item is the important one.

Item	Count it?	Why
Drawn balances	Yes	Obviously
Undrawn revolving availability	Yes	They can draw it without asking you
Approved but undisbursed	Yes	Committed
Guarantees they've given	Yes	Per our guarantee analysis
Business obligations they've guaranteed	Yes, where you can see them	Same household
Overdraft availability	Yes	Same as any undrawn line

Row two is the one operations omit and it's the most consequential. A customer with substantial unused availability can increase your exposure to the full amount without any further decision on your part — so a limit counting only drawn balances binds after the risk has been taken rather than before.

And row four is the one nobody has data for. Per our guarantee analysis, contingent obligations aren't reported — so even a thorough internal aggregation will miss guarantees the customer has given elsewhere, which is a known and unfixable gap worth stating in the policy rather than pretending away.

Why your own data beats the file

An observation that sounds obvious and is routinely ignored.

For your own products, the credit file is the worst source available. Per our attribute analysis:

• It reflects a statement date, not the current position.
• Recent originations may not appear yet.
• Undrawn availability may be represented imperfectly.
• You hold the actual data — balances, limits, and behaviour, as of now.

An operation aggregating its own exposure from the bureau is using a delayed summary of information it already has, which happens because the decisioning system was built to consume a file and internal positions weren't plumbed in.

The right structure: internal exposure from internal systems in real time, external exposure from the file with its lag acknowledged. And per our renewal analysis, the internal behavioural data is more predictive than the file anyway — so a lender ignoring its own position is discarding its best information twice over.

Setting the limit

The substantive question, and the answer should come from capacity rather than from a round number.

1. Establish the household's income, at a reliable level per our affordability analysis.
2. Establish committed outgoings, including obligations the file doesn't hold.
3. Compute residual income against a benchmark.
4. Derive the total obligation service the household can sustain, stressed.
5. Subtract obligations to others.
6. What remains is what you can prudently hold.

A limit derived this way declines applications the customer couldn't have sustained, which is a service to both parties. An arbitrary cap set at a round number just loses business at the boundary without corresponding to anything.

Two refinements worth making:

• Stress it. Per our affordability analysis, a total that fits only in a good month doesn't fit — and per our correlation analysis, multiple obligations to one lender all become difficult in the same month rather than in separate ones.
• Differentiate by product where appropriate. A secured obligation and an unsecured line are not equivalent claims on the same capacity, and treating them identically is as crude as not aggregating at all.

And document the basis, per our validation analysis. A limit whose derivation nobody can state is one nobody can defend or update.

When it binds

The operational moment, and it needs deciding in advance.

A customer you know and like applies for something and the aggregate limit declines them. What happens next:

• The reason has to be stated properly. Per our notices guide, this is an adverse action with specific reason requirements — and "total exposure with us" needs expressing in terms the applicant can act on.
• Offer an alternative where one exists. A smaller amount, a secured version, or consolidating existing obligations into the new one so the total doesn't rise.
• The consolidation option is the useful one and it's frequently better for the customer too — replacing three obligations with one at a lower total payment serves both sides without increasing exposure.
• Handle the override question deliberately. Per our override analysis, if relationship managers can exceed the limit, record who and why in structured form — otherwise the limit is advisory and you won't know how often it's ignored.
• Watch for a pattern of overrides on the same customers, which indicates either a wrong limit or a control that isn't one.

The second and third points are what make an aggregate limit commercially tolerable. A limit that only ever produces declines will be overridden until it's meaningless; one that produces a restructured offer keeps the customer and the discipline.

Drift without a decision

The failure that happens after everything was set up correctly.

A relationship within limit at origination can drift past it with no new approval. How:

• Balances grow on revolving products.
• Automatic line increases, per our line analysis.
• Interest and charges accumulate on delinquent accounts.
• The customer's capacity falls — income drops, other obligations rise.
• A limit set years ago is still being applied to a changed position.

Which means aggregate exposure needs monitoring rather than only checking at decision time. What to run:

1. Recompute exposure and limit periodically for every relationship.
2. Report on relationships over limit, with the reason.
3. Report on relationships approaching it, so the next application isn't a surprise to anyone.
4. Distinguish drift from capacity deterioration, since they need different responses.
5. Feed it into account management, per our line analysis — noting that reducing a line is itself consequential and raises utilization immediately.

Item four matters most. A relationship over limit because balances grew is different from one over limit because the customer's income fell — the first is a lending decision and the second is an early warning per our early warning analysis.

The household question

The harder version, and worth being honest about the limits.

Per our structural analysis, the unit that manages obligations is the household and the unit lenders assess is the individual. Which means:

• Two individuals in one household may each be within limit while the household isn't.
• Their obligations are serviced from one pool of income and one set of expenses.
• They fail together, per our correlation analysis.

Why lenders mostly don't aggregate at household level:

• Identifying a household reliably is difficult, and more error-prone than identifying an individual.
• It raises questions about assessing someone on another person's obligations — which per our fair lending analysis needs careful consideration, since household-based treatment can have effects that require justification.
• People's household arrangements change.

The honest position: joint obligations should obviously aggregate, and going further than that is a question for counsel rather than a modelling decision. An operation that aggregates joint exposure properly has captured most of the available benefit without entering the territory that needs legal analysis.

Frequently asked questions

---

This guide is educational and does not constitute legal or compliance advice. Requirements governing adverse action reasons, the use of information about persons other than the applicant, household-based assessment, and exposure aggregation vary by product, institution, and jurisdiction. Consult qualified counsel and your compliance and model risk functions before implementing aggregate limits or any household-level treatment.