Solution

Unified Limit Management

Centralised management of client, related-party group, product, industry and portfolio limits. One source of truth — instead of scattered spreadsheets and manual calculations at the moment of decision.

Discuss Your Setup

A limit only works at the moment of decision

The point of a limit is not to be recorded, but to influence a decision. If a limit exists but nobody thinks about it when the deal is reviewed, it is not doing its job. It becomes a decorative element of the risk policy — beautiful on paper, useless in practice.

That is why any limit management system should be tested by one simple question: does the person making the decision see the current limit at the moment of making the decision? If not, this is not a management system — it is an accounting system.

The group structure is the most underrated entity

One of the key problems in limit management is the handling of related-party groups. Formally, every bank knows this entity exists and that limits must be calculated per group, not just per client. In practice, groups are maintained with delays, incompletely, sometimes subjectively. This is the main source of divergence between the picture the bank sees at home and the picture the regulator sees.

So any mature limit management project starts not with numbers but with a question: how exactly do we maintain related-party groups, who is responsible, and how do we learn about structure changes.

CTA

If you want to understand how much your bank’s limit picture actually matches reality, a good starting point is a fast audit on one portfolio segment — it usually surfaces discrepancies worth fixing first.

Target Model

How It Should Work

A mature limit management contour is one source of truth from which any part of the bank gets the answer to «can this deal go through and why». Client limit, related-party group limit, industry concentration, product constraints, regional limits — all of it visible at the moment the deal is reviewed, not in the next report. At the same time a limit is not a hard block but a managed rule that can be exceeded with an explicit decision and recorded responsibility.

Unified limit registry: client, group, product, industry, region

Related-party group model with change history

Embedding limits in the deal decision-making contour

Managed breach contour with approval process

Management analytics: concentration, coverage, dynamics

Audit of limit decisions

Integration with covenant control and risk monitoring

Проблемы

Где обычно все ломается

No unified limit registry — each limit type lives in its own spreadsheet

The «client → related-party group» link is maintained manually, with a lag

Industry and regional concentration are calculated as reports, not at decision time

Limit breaches have no formal approval process

There is no history — it is impossible to trace how limits changed over time and on what grounds

Consequences

What This Leads To

⚠ The bank discovers industry concentration breaches too late

⚠ Large deal decisions are made without an exact limit picture at the session

⚠ The regulator finds discrepancies faster than the bank itself

⚠ Large clients can quietly approach the group limit and the deal fails at the last moment

⚠ Audit of limit breach decisions becomes archaeological work

My Approach

How I Approach the Challenge

I start by mapping every limit type that currently exists in the bank and finding out who maintains it, where it is stored, who recalculates it and how often it is updated. Almost always it turns out that the same entity — for example, a related-party group — is kept in two or three places with diverging data. That is the first thing to fix.

Recognize your situation?

Discuss Your Setup

Team

How We Work

My Role

I help the bank consolidate fragmented limit management into a single working contour. I design a model where a limit is a living rule with history and process, not a static number in a report.

Team Role

The team implements the unified registry, the related-party group model, integration with LOS, the breach contour, links to reporting and to risk contours.

Important

Key Considerations for Implementation

🔎 A limit is a living rule, not a static record

🔎 The related-party group is a separate management entity, not a client attribute

🔎 The limit must be visible at the moment of decision, not in the next cycle's report

🔎 A breach must have an explicit managed process, not silent tolerance

🔎 Limit change history is an audit tool that should be designed in from day one

Results

What Results to Expect

✓ Full limit picture at the moment of new deal review

✓ Early detection of industry and related-party group concentration

✓ Traceability of limit change history

✓ Managed breaches with explicit responsibility

✓ Readiness for regulatory concentration requests without emergency recalculations

FAQ

Frequently Asked Questions

We already calculate limits in risk reports. Isn't that enough?

A risk report shows the picture after the fact. It is good for management conclusions but useless at the moment of decision. A limit management contour is needed precisely so the limit is visible at the moment of decision, not in the next reporting cycle.

Can we build this on top of our existing data warehouse?

Partly yes — the warehouse can be a data source for the limit engine. But the engine itself must be a separate contour with a related-party group model, change history and integration into decision-making processes. A simple BI report is not enough.

→

What else is worth exploring

Topics from the same area we usually explore together

Solution

These are not just articles

I do not just write about this. I can come in, examine your situation and design a solution for your specific landscape.

Discuss applying this →

← All Solutions

Ready to discuss your setup?

Tell me what's not working. I'll review the situation and suggest a concrete path forward.

Discuss Your Project Write on Telegram

Usually respond within a few hours