Карта всей системы

Банковская система начинается не с FX Swap, IRS или Option. Она начинается с задачи, которую клиент не может или не хочет решать самостоятельно.

Клиенту может понадобиться финансирование, временная ликвидность в другой валюте, фиксированный курс, предсказуемая ставка или защита от неблагоприятного движения рынка.

Иногда клиент хочет заработать. Но часто его главная цель — не заработать, а убрать неопределённость.

Экспортёр может зафиксировать будущий курс и отказаться от выгоды при благоприятном движении FX. В обмен он получает предсказуемую рублёвую выручку.

Компания с плавающей ставкой может обменять её на фиксированную. Она не знает, окажется ли это дешевле, зато заранее понимает размер будущих платежей.

Главная мысль проста:

Клиент хочет изменить своё финансовое состояние так, чтобы решить конкретную задачу.

Короткий ответ — банк хочет заработать. Но он не может просто максимизировать доход при любом уровне риска.

Банк зарабатывает, оказывая финансовую услугу и принимая только тот риск, которым способен управлять.

На самом верхнем уровне банк — распределитель и преобразователь ликвидности. Он соединяет клиентов с разными потребностями, сроками и валютами.

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

Доход возникает как процентная маржа, комиссия, bid-offer spread, плата за структуру сделки или trading margin.

Но вместе с доходом возникают обязательства. Именно поэтому встреча клиента и банка быстро приводит нас к продукту, cash flows и риску.

Под потребность выбирается продукт.

• Зафиксировать курс будущей покупки валюты — FX Forward.
• Получить валюту сейчас и вернуть её позже — FX Swap.
• Заменить плавающую ставку на фиксированную — IRS.
• Ограничить неблагоприятный исход, сохранив upside, — FX Option.

Связь выглядит так:

Client Need → Product

Продукт — не просто название из каталога. Это договорная конструкция, которая меняет будущие денежные потоки клиента и банка.

Чтобы понять экономику сделки, продукт нужно разложить на простые вопросы:

• кто платит;
• кому платит;
• когда платит;
• сколько платит;
• от какого условия зависит сумма.

В FX Forward стороны в будущем обменивают две валюты по согласованному курсу. В IRS одна сторона платит fixed rate, другая — floating rate.

У Option одна сторона платит premium, а второй платёж появляется только при выполнении условий исполнения.

Product — это набор правил, по которым возникают будущие cash flows.

Клиент знает об этих потоках: он подписывает договор с валютами, notional, датами, ставкой, strike, fixing source и правилами settlement.

Клиент подписывает контракт, а не внутреннюю risk-модель банка. Сначала существуют contract и cash flows, а уже потом система интерпретирует их последствия.

Большинство договорных cash flows находятся в будущем. А будущее неизвестно.

Курс может измениться. Ставка может вырасти. Контрагент может не заплатить. У банка может не оказаться нужной ликвидности. Settlement может не пройти.

Так из будущих обязательств естественно появляется риск.

Важно, что риск связан и с нежелательным исходом, и с неопределённостью. Если потеря заранее известна, это уже известный cash flow, а не классический risk.

Способ возможной потери определяет тип риска:

Risk — верхнеуровневое понятие. Конкретный тип отвечает на вопрос: каким способом банк может столкнуться с нежелательным результатом?

Разные продукты создают разные cash flows. Поэтому их стоимость зависит от разных переменных рынка.

• FX Forward зависит от FX и ставок двух валют.
• IRS — от процентных кривых.
• FX Option — от FX, volatility, rates и времени.
• CCIRS — от FX, ставок обеих валют и cross-currency basis.

Эти переменные называют Market Factors или Risk Factors.

Представим FX Forward: через три месяца клиент покупает USD по 100 RUB/USD. Позже рынок меняется, и аналогичный forward уже заключается по 110.

Сам контракт не изменился. Но изменилось его экономическое значение относительно текущего рынка.

Так появляется Valuation, или MTM: текущая стоимость оставшихся cash flows с учётом состояния рынка.

Теперь предположим, что MTM сделки для банка равен +100 млн рублей. Контракт представляет для банка экономическую ценность.

Если клиент завтра объявит дефолт, банк может эту ценность потерять. Так появляется Exposure.

Но Risk и Exposure — не одно и то же.

Exposure показывает, что и в каком размере находится под угрозой. Risk также учитывает неопределённость: реализуется ли нежелательное событие и насколько тяжёлыми будут его последствия.

Главная связь этого блока:

Cash Flows → Market Factors → Valuation → Exposure → Risk

У банка уже есть продукт, cash flows, market factors, counterparty и текущее состояние сделки. Но для управления риском этого недостаточно.

Банку нужно число. Иначе невозможно сравнивать сделки, агрегировать портфель или понять, находится ли риск в допустимых границах.

Эту работу выполняет Risk Methodology:

Risk Metric = f(Product, Market Factors, Counterparty, Lifecycle, Collateral, Netting, …)

На входе — данные и предположения. На выходе — PFE, EAD, DV01, VaR, Expected Shortfall, Stress Loss или другая metric.

Важно различать metric и methodology.

PFE = 500 млн — это metric. Horizon, percentile, scenarios, модель FX, collateral, netting set и MPOR — это methodology, по которой число получено.

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

Risk metric зависит не только от продукта и рынка. Она зависит и от текущего состояния сделки.

В IRS до fixing следующий floating cash flow неизвестен. После fixing ставка уже определена. После payment этот поток исчезает.

В FX Swap до near settlement существуют две будущие ноги. После расчёта по near leg остаётся только far leg.

В NDF до fixing payoff неизвестен. После fixing settlement amount уже определён.

В Option до expiry существует optionality. После exercise остаётся обычное обязательство по settlement.

Lifecycle определяет текущее состояние контракта и набор remaining cash flows.

Поэтому lifecycle влияет на всю цепочку:

Lifecycle → Cash Flows → Valuation → Exposure → Risk

До заключения сделки pre-trade risk отвечает на вопрос: что произойдёт с risk profile банка, если эту сделку заключить?

После заключения post-trade monitoring измеряет уже существующий portfolio с реальными terms, netting, collateral, market data и lifecycle state.

Pre-trade — не просто «неточный risk», а post-trade — не автоматически «точный». Это разные вопросы: прогноз изменения портфеля и измерение его текущего состояния.

Допустим, система рассчитала PFE = 400 млн рублей. Само по себе число ещё ничего не решает.

Если counterparty limit равен 500 млн, utilization составляет 80%. Теперь metric получила управленческий контекст.

На верхнем уровне Risk Appetite определяет, сколько риска банк готов принимать. Limits превращают это намерение в конкретные ограничения.

Методология говорит, сколько риска есть. Limit говорит, сколько риска разрешено иметь.

Но один лимит не показывает всю картину. Stress Testing проверяет портфель в тяжёлых сценариях: например, FX +30%, rates +500 bp или закрытый funding market.

Concentration Analysis показывает, не сосредоточен ли риск в одном клиенте, секторе, стране или валюте.

В итоге Risk Officer Сергей получает не просто число, а инструмент для решения:

• заключить сделку или отказать;
• потребовать collateral;
• снизить notional;
• захеджировать позицию;
• передать сделку на дополнительный approval;
• остановить дальнейшее увеличение риска.

Сергей видит, какой риск существует, почему он возник, где сосредоточен, укладывается ли в лимиты и что случится в stress-сценарии.

Риск под контролем — по крайней мере настолько, насколько вообще может быть под контролем будущее.

Теперь всю систему можно собрать в одну цепочку:

Client Need → Bank → Product → Contract → Cash Flows → Future → Uncertainty → Risk Factors → Valuation → Exposure → Lifecycle → Methodology → Risk Metric → Limits and Stress → Decision

Эта карта не заменяет книги по Trade Lifecycle, документацию по fixing или формулы PFE. Она показывает место каждого знания в общей системе.

Увидев новый класс, сервис или MR, можно спросить:

1. Какую потребность или банковское решение он поддерживает?
2. Какой product, contract или cash flow он представляет?
3. Какое lifecycle-событие меняет его состояние?
4. На valuation, exposure или risk metric он влияет?
5. Кто использует результат и какое решение принимает?

В этот момент код перестаёт быть набором локальных правил. Каждая строка получает место в большой системе — и становится понятно не только что она делает, но и почему она вообще появилась в мире.

• Почему клиенту может быть полезна сделка, даже если он не ожидает на ней заработать?
• Чем Product отличается от Contract и Cash Flows?
• Почему Risk нельзя свести только к величине Exposure?
• Как lifecycle-событие меняет valuation и risk profile сделки?
• Почему одна и та же metric бесполезна без methodology и limit?