Risk & scenarios

One exposure figure per counterparty where dashboards disagreed

Exposure

Counterparty and obligor records resolved at source, so credit exposure is reported once, correctly, in one application.

Existing
The challenge
Credit exposure reporting relied on dashboards fed by legacy systems and manual imports, producing an inconsistent aggregate view. Inconsistent naming across counterparties and parent-company and obligor combinations undermined the exposure calculations themselves.
As built
What we built
- The Foundry ontology used to resolve counterparty and obligor inconsistencies at source, in one auditable repository
- Policy and referral limit uploads built into the workflow, so users see their effect on the figures in near real time
- A Foundry application delivered as the definitive exposure report, where stakeholders generate reports, edit data and monitor outcomes
In production
The impact
- Aggregate exposure reported accurately for every counterparty above the institution’s threshold
- Policy and referral limits onboarded through the workflow
- One definitive report, replacing a set of dashboards that disagreed with each other
One report
per counterparty, in one application

The same problem elsewhere

The same resolution applies wherever one party appears under several names across systems: suppliers, customers, counterparties, sites.

Banking & capital markets: Counterparty exposure assembled from systems that each spell the same obligor differently.
Insurance & reinsurance: Cedent, broker and client exposure aggregated across entities with inconsistent naming.
Manufacturing & engineering: Supplier concentration and spend that cannot be summed because one supplier is many records.
Energy & utilities: Counterparty and trading exposure across desks, registers and settlement systems.

Bring us the version of this you are living

Tell us where your programme stands, and we will say whether the same approach would work for it.

info@ainurinsights.com