Жизненный цикл сделки

Contract определяет, что должно произойти.

Lifecycle показывает, где обязательство находится сейчас.

Risk описывает возможный downside именно в этом состоянии.

Связь можно записать так:

Lifecycle Event → Contract State → Remaining Cash Flows → Valuation → Exposure → Risk

Если система неправильно обработала одно событие, ошибка может одновременно попасть в payments, liquidity forecast, P&L, risk reports и limits.

Вернёмся к учебному RUB/NOK NDF.

RUB Notional:        100 000 000 RUB
Contract Rate:       0.10 NOK/RUB
Fixing Date:         15 декабря
Payment Date:        17 декабря
Settlement Currency: NOK

Формула с точки зрения Norway Christmas:

Settlement Amount = (Contract Rate − Fixing Rate) × RUB Notional

Контракт уже содержит все правила. Lifecycle отвечает на другой вопрос: какие из этих правил уже сработали и что существует сейчас?

Упрощённо состояние можно представить функцией:

New State = transition(Current State, Lifecycle Event)

Из нового состояния система выводит remaining cash flows и передаёт их в Valuation, Risk, Operations и Treasury.

Для NDF Norway Christmas основной путь выглядит так:

Quoted → Traded → Confirmed → Pre-Fixing → Fixed → Due → Settled → Closed

Это не универсальный список статусов для любой системы. Важно не название state, а его бизнес-инварианты.

Например, state Fixed должен означать: contractual fixing принят, settlement amount определён, но payment ещё не исполнен.

Состояние	Что известно	Remaining obligation	Главный risk focus
Quoted	Предварительные terms	Юридической сделки ещё нет	Pre-trade impact и pricing
Traded	Terms согласованы	Условный будущий NOK payment	Market и counterparty risk
Confirmed	Terms сверены сторонами	Тот же условный payment	Confirmation и operational risk
Pre-Fixing	Fixing ещё неизвестен	Amount определяется формулой	Market uncertainty и PFE
Fixed	Fixing принят	Известный receivable или payable	Counterparty, liquidity и settlement risk
Due	Payment должен быть исполнен	Известная сумма к оплате	Settlement и operational risk
Settled	Деньги переданы	Remaining cash flow = 0	Reconciliation и residual breaks
Closed	Все обязательства завершены	Нет	Data retention и audit

Risk profile меняется не потому, что поменялось название статуса. Он меняется потому, что изменились facts и remaining obligations.

На Trade Date стороны согласуют экономические terms. В системе появляется trade record и первый набор future cash flows.

Для Norway Christmas фиксируются notional, contract rate, fixing source, dates, settlement currency и conventions.

Confirmation сверяет представление банка с представлением клиента. Она помогает обнаружить wrong rate, currency, notional или date.

Confirmation обычно не должна незаметно переписывать экономику сделки. Расхождение требует amendment, correction или dispute process.

На этом этапе cash flow ещё зависит от будущего fixing. Valuation использует market data, а counterparty exposure учитывает возможную будущую стоимость.

До 15 декабря контрактная формула известна, но fixing rate ещё отсутствует.

Система хранит условный future cash flow:

Amount = (0.10 − future RUB/NOK fixing) × 100 000 000

В зависимости от рынка Bank может стать payer или receiver. Поэтому будущий settlement amount моделируется через scenarios.

Именно здесь market factors влияют на valuation и PFE.

С приближением fixing date time horizon сокращается, но direction и amount всё ещё не определены договорно.

15 декабря приходит contractual fixing 0.08 NOK/RUB.

Система применяет формулу:

(0.10 − 0.08) × 100 000 000 = 2 000 000 NOK

После события FixingObserved состояние меняется:

до fixing:    conditional cash flow, amount unknown
после fixing: Bank → Norway Christmas, 2 000 000 NOK, amount known

Market uncertainty по этому cash flow исчезла. Движение RUB/NOK после fixing уже не меняет contractual settlement amount.

Но risk не исчез целиком. До payment остаются counterparty, liquidity, settlement и operational risk.

Для банка 2 млн NOK становятся известным payable. Для Norway Christmas — известным receivable.

После fixing сумма известна, но деньги ещё не переданы.

Между Fixing Date и Payment Date Operations должны подготовить instruction, проверить SSI, cut-off, calendar и доступность NOK liquidity.

Treasury видит известный отток 2 млн NOK. Risk видит оставшееся обязательство. Finance отражает изменение valuation и соответствующие accounting events.

Если банк обязан заплатить Norway Christmas, недостаток NOK в payment date становится liquidity problem, даже если формула рассчитана идеально.

17 декабря банк отправляет 2 млн NOK по согласованным settlement instructions.

Событие отправки payment ещё не обязательно означает окончательное исполнение. Возможны статусы initiated, accepted, rejected и settled.

После подтверждённого settlement:

Known payable:        0
Remaining cash flow:  0
Trade state:          Settled

Затем reconciliation проверяет, что сумма, валюта, получатель и value date совпали с ожиданием.

Trade можно закрыть только после того, как обязательства исполнены или корректно прекращены. Maturity date сама по себе не доказывает settlement.

Lifecycle engine не должен выдумывать значение, если contractual fixing не пришёл.

Состояние остаётся Awaiting Fixing, а контракт определяет следующий допустимый шаг: ожидать публикацию, использовать fallback или передать решение calculation agent.

Важно разделять два факта:

• fixing должен был произойти по расписанию;
• fixing фактически получен и принят системой.

Использование scheduled value вместо observed event может преждевременно создать неправильный payment.

Один fixing event может быть доставлен дважды из-за retry или повторной публикации.

Если обработчик не idempotent, система создаст два одинаковых settlement cash flow или два payment instruction.

Повторная обработка одного business event должна приводить к тому же состоянию, что и однократная.

Для этого нужны стабильный event identity, проверка текущего state и защита от повторного side effect.

Идемпотентность особенно важна на границе с платежными системами: повторный message не должен означать повторный перевод.

Поставщик данных может исправить ранее опубликованный fixing. Это не duplicate, а новый business fact.

Система должна знать:

• разрешает ли контракт использовать correction;
• какая версия fixing является действующей;
• был ли payment уже рассчитан или отправлен;
• какие downstream results нужно пересчитать;
• нужен ли adjustment cash flow.

Простое обновление поля fixingRate недостаточно. Старое значение уже могло попасть в valuation, payment instruction, P&L и reports.

Correction требует контролируемого пересчёта проекций и audit trail: что изменилось, почему и какой результат был заменён.

Если payment instruction отклонён из-за неверного SSI, obligation не исчезает. Меняется operational state, но amount остаётся due.

Если банк отправил только 1.5 млн NOK из 2 млн, remaining obligation составляет 0.5 млн NOK, если контракт допускает partial settlement.

Дальше могут появиться default interest, cure period, notice или dispute.

Нужно различать:

• operational failure — ошибка системы, instruction или cut-off;
• credit failure — counterparty не исполняет obligation;
• settlement failure — обмен не завершён как предусмотрено.

Одинаковый статус FAILED без причины слишком беден для Risk и Operations.

Представим, что стороны до fixing уменьшают RUB notional со 100 до 60 млн.

Система не должна переписывать историю так, будто сделка всегда была на 60 млн. Нужны исходные terms, amendment event и effective date.

После amendment формула применяется к новому remaining notional:

(0.10 − 0.08) × 60 000 000 = 1 200 000 NOK

Будущие cash flows, valuation и exposure меняются с effective moment amendment.

Исторические расчёты до amendment должны оставаться воспроизводимыми.

При early termination плановый settlement может быть отменён и заменён termination amount.

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

При novation payoff NDF может остаться тем же, но одна сторона заменяется новой.

Тогда market cash flow почти не меняется, а counterparty exposure, PD, CSA, netting set, collateral и limits могут измениться существенно.

Это показывает, почему lifecycle нельзя свести только к payment schedule.

Событие FixingObserved(0.08) используется сразу несколькими функциями.

Функция	Реакция на fixing
Trading	Позиция больше не зависит от будущего fixing по этому cash flow
Valuation	Условный payoff заменяется известной суммой
Risk	Market uncertainty снижается, остаётся settlement exposure
Operations	Создаётся payment instruction на 2 млн NOK
Treasury	В liquidity forecast появляется известный NOK outflow
Finance	Обновляются P&L и accounting events
Reporting	Меняются state, amount и risk classification

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

Поэтому lifecycle — это не одна колонка status, а согласованное распространение business facts.

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

Event time — когда событие экономически или юридически произошло.

Processing time — когда конкретная система его получила и обработала.

Fixing мог быть опубликован в 12:00, market-data service получил его в 12:01, а risk batch применил в 12:10.

Без этого различия трудно объяснить расхождения между системами, восстановить состояние на исторический момент и корректно обработать late event.

Логика состояний одна, но события зависят от продукта.

IRS

До fixing floating coupon неизвестен. После fixing ставка и coupon известны. После payment этот cash flow исчезает из remaining obligations.

Deliverable FX Forward

До settlement существуют две principal obligations. После успешного обмена обе валютные ноги закрываются.

FX Option

До expiry существует optional right. После exercise появляется settlement obligation. После expiry без exercise право исчезает без будущего payoff.

CCIRS

Initial exchange сменяется последовательностью fixing и coupon payments, а затем final principal exchange.

Сравнивать продукты полезно через один вопрос: какие remaining cash flows существуют после конкретного event?

При чтении обработчика события или MR полезно пройти шесть шагов.

1. Какой business event пришёл?
2. Из какого state переход разрешён?
3. Какие invariants должны выполняться?
4. Какие remaining cash flows создаются, изменяются или исчезают?
5. Какие downstream-проекции нужно обновить?
6. Что произойдёт при duplicate, late или corrected event?

Хороший handler не просто меняет статус. Он атомарно фиксирует business fact и обеспечивает согласованные последствия.

Особенно опасны скрытые переходы, когда поле обновляется напрямую, а valuation, payments или risk продолжают жить в старом состоянии.

Для каждого lifecycle event можно заполнять одну таблицу.

Поле	Вопрос
Event	Что произошло в бизнесе?
Preconditions	Из каких states событие допустимо?
New facts	Что стало известно?
Removed uncertainty	Что больше не зависит от будущего?
Remaining obligations	Какие cash flows ещё существуют?
Side effects	Какие payments, calculations и reports обновить?
Risk impact	Какие risk factors исчезли или появились?
Failure handling	Что делать при duplicate, late, missing или corrected event?
Audit	Как воспроизвести решение позже?

Такая таблица превращает расплывчатое «обработать fixing» в проверяемую спецификацию.