Three Units, One Sponsor: The Aggregation Failure Behind a Clean Limit Report
Three lending units of a bank with $1.2bn of Tier 1 capital report monthly to the group risk function. Each applies a 10%-of-capital single-obligor limit at unit level. Internal Audit has found three exposures - $55m from Commercial, $48m from Retail (broker-originated investor loans) and $42m from Leasing - that belong to the same sponsor group, booked as 'Meridian Property Holdings', 'Meridian (BVI) Ltd' and 'MPH Sponsor S.a r.l.' There is no group hierarchy field; matching is done manually by name. A $60m industrial property is pledged as collateral to two of the units. The sponsor also guarantees a further $35m of undrawn facilities that are excluded from limit utilisation. The group credit committee reviews a report showing every unit at or below 9% of capital.
1. Quantify and characterise the true aggregate position. What limit framework failures does this reveal?
Read the worked answer
True exposure. Drawn: $55m + $48m + $42m = $145m. Add the $35m of undrawn facilities guaranteed by the sponsor - a guarantee is a credit substitute and must be included - giving $180m of committed exposure. Against $1.2bn of Tier 1 and a 10% single-obligor limit ($120m), utilisation is 15%: a $60m, or 50%, breach. Collateral is overstated: the $60m property is pledged to two units, so at most $60m (less haircuts) can be recognised once, and only if enforceability across both is confirmed.
What failed - four distinct issues, not one:
- Definition - no connected-counterparty standard, no treatment of guarantors, no treatment of undrawn commitments.
- Data - name-based matching with no legal-entity hierarchy; three name variants defeated aggregation.
- Limit design - limits set only at unit level, with no group-level limit that binds across units.
- Measurement base - utilisation measured on drawn balances rather than committed exposure.
The committee's report was arithmetically correct and substantively wrong. This is an aggregation failure, and therefore a governance failure, not a data-entry problem.
2. What remediation would you require, and how would you treat the position in the interim?
Read the worked answer
Interim (this month): recognise the group as a single obligor at $180m; stop new facilities and renewals to the sponsor and its SPVs until utilisation is remediated; verify collateral enforceability and recognise the second pledge at nil; report both drawn and committed utilisation to the credit committee.
Structural (next two quarters):
- Build a single counterparty master with a unique group ID, sourced from KYC and fed automatically by all three lending systems - not manually matched.
- Amend policy so utilisation is measured on committed exposure, including guarantees, letters of credit and undrawn lines, against a documented connected-counterparty standard.
- Introduce a group-level single-name limit that binds across units, plus a group-level sector limit; unit limits sit below it so the group limit is always the binding constraint.
- Maintain a collateral register with a uniqueness check so one asset cannot be pledged twice.
Accountability: the breach was found by audit, not by the second line. Assign ownership of the aggregation control and test it quarterly, with the test result reported to the board risk committee.
3. How should this be reported to the board, and what question should the board be asked?
Read the worked answer
Report it as a material control weakness, not as a credit loss.
- The true position: $180m committed, 15% of Tier 1, $60m over the $120m limit; the collateral double count; and which reports were wrong, and for how long.
- Root cause in one sentence: no group-level counterparty aggregation standard, so unit-level limits did not add up.
- Tail loss: if the sponsor fails, $180m of exposure with at most $60m of enforceable collateral implies a plausible loss of around $120m against $1.2bn of capital. The board should see that number.
- Remediation with dates, owners and independent validation; quarterly reporting until the hierarchy is live and tested.
The question to the board: should the risk appetite statement carry a group-level single-name limit expressed in capital terms, with its own trigger, so that a breach is visible at board level rather than only inside a unit report? Also ask whether the same weakness exists for other multi-unit clients - the probability that Meridian is the only one is low.