Методология и лимиты

Риск не является свойством сделки сам по себе. Это результат расчета по конкретной методологии.

Метрика — число, которое получилось. Методология — правила, предположения и данные, с помощью которых система получила это число.

Например, утверждение PFE = 500 млн само по себе говорит мало. Нужно знать:

• на каком horizon рассчитана метрика;
• какой percentile или confidence level использован;
• как применяются netting и collateral;
• какой выбран MPOR;
• на каком уровне агрегирован портфель.

Два одинаковых значения PFE могут описывать совершенно разный риск, если за ними стоят разные методологии.

Упрощенно risk calculation можно представить так:

Portfolio State + Market Data + Scenarios + Methodology → Risk Metric

Одна и та же IRS может дать разные PFE или stress loss, если изменить:

• временной горизонт;
• confidence level;
• volatility assumptions и correlation;
• правила netting;
• учет collateral;
• MPOR;
• уровень агрегации.

Поэтому недостаточно сохранить только итоговое число. Для воспроизводимости результата системе нужны версия методологии, входные данные и контекст расчета.

Pre-trade расчет нужен до заключения сделки. Он отвечает на вопрос: если добавить эту сделку в портфель, не нарушим ли мы ограничения?

Current Portfolio + Proposed Trade → Approximate New Risk

Допустим, current PFE равен 420 млн, а limit — 500 млн. Standalone PFE новой сделки равен 100 млн, но сделка частично компенсирует существующую позицию.

После ее добавления portfolio PFE может вырасти лишь до 455 млн. Значит, incremental PFE равен 35 млн, а не 100 млн.

Pre-trade может быть приближенным, потому что решение нужно быстро. Расчет может использовать simplified scenarios, proxy-модели и неполные lifecycle details.

Post-trade отвечает на другой вопрос: какой риск реально возник после заключения и подтверждения сделки?

Для него доступны confirmed trade terms, актуальный lifecycle state, полный netting set, actual collateral, весь портфель и production methodology.

Иными словами:

• Pre-trade — decision support.
• Post-trade — authoritative risk measurement.

Важный edge case: pre-trade разрешил сделку, но post-trade после booking показал breach. Тогда система должна запустить не пересчет прошлого решения, а заранее определенный процесс реакции.

Standalone risk новой сделки не показывает, как она изменит риск всего портфеля.

Допустим:

• current portfolio risk = 400;
• standalone risk новой сделки = 150;
• risk портфеля после сделки = 430.

Наивное сложение дает 550. Но offset, diversification и netting снизили реальный результат до 430.

Incremental Risk = Risk(Portfolio + New Trade) − Risk(Portfolio)

В этом примере incremental risk равен 30. Именно это число показывает, сколько дополнительной risk capacity потребила сделка.

Incremental risk важен для pre-trade решения, limit usage, pricing и capital allocation.

Стратегические ограничения превращаются в операционные границы сверху вниз:

Capacity → Appetite → Tolerance → Concrete Limits

• Risk capacity — сколько риска банк в целом способен выдержать с учетом капитала, ликвидности и regulatory constraints.
• Risk appetite — какую часть capacity банк сознательно готов использовать ради стратегии.
• Risk tolerance — какое отклонение от целевого уровня еще допустимо.
• Risk limit — жесткая операционная граница для конкретной метрики.

Например, capacity может быть 100, appetite — 60, а tolerance временно допускать рост до 70. На операционном уровне это превращается в набор конкретных limits.

Например:

• PFE limit = 500 млн;
• DV01 limit = 5 млн RUB/bp;
• Vega limit = 20 млн;
• Settlement limit = 1 млрд.

Limit всегда относится к конкретной метрике. Фраза «у клиента лимит 500 млн» неполна: PFE limit, settlement limit и current exposure limit ограничивают разные виды риска.

После расчета метрику сравнивают с соответствующим limit.

Utilization = Risk Metric / Limit

Если PFE равен 450 млн, а PFE limit — 500 млн, utilization составляет 90%.

Это не означает, что «риск равен 90%». Это означает, что использовано 90% разрешенной capacity по конкретной метрике.

Уровни utilization должны приводить к понятным состояниям:

• ниже limit — продолжаем monitoring;
• около limit — warning или escalation;
• выше limit — breach и обязательное действие.

Риск можно агрегировать на разных уровнях:

• trade;
• counterparty;
• netting set;
• desk или portfolio;
• country, currency или sector.

Одна сделка может быть небольшой standalone, но создавать значительную концентрацию. И наоборот, крупная сделка может уменьшить portfolio risk через offset.

Обычная метрика отвечает на один класс сценариев. Stress проверяет устойчивость при более сильном или необычном движении рынка.

Например:

• FX +30%;
• rates +500 bp;
• volatility spike;
• одновременное ухудшение credit quality нескольких counterparties.

Stress — не просто еще один limit. Это отдельный взгляд на то, переживет ли портфель сценарий, который плохо отражается обычной метрикой.

Risk metric также влияет на pricing и capital allocation. Если сделка потребляет много limit, капитала или ликвидности, это должно отражаться в цене и approval process.

Risk metric нужна не ради отчета. Она нужна, чтобы принять решение.

Metric → Limit → Utilization → Breach → Action

После breach возможны разные действия:

• остановить новые сделки;
• запустить escalation;
• поставить hedge;
• запросить дополнительный margin;
• уменьшить или переструктурировать позицию;
• выдать temporary approval;
• пересмотреть limit после отдельного review.

Выбор действия зависит от типа метрики, причины breach, срочности и того, является ли превышение временным или структурным.