Почему система фиксации курса ломается на волатильном рынке
Система фиксации курса обещает одно: клиент подтверждает фиксацию курса обмена и получает ровно ту цену, которую видел на экране. Пока рынок спокоен, обещание держится. Как только цена начинает двигаться внутри минуты, цепочка «источник цены, расчёт, подтверждение, исполнение» рвётся сразу в нескольких местах.
Первое — расхождение котировок между источниками. Биржа, пул ликвидности и агрегатор дают разные значения, а окно усреднения добавляет лаг: к моменту расчёта цифра уже не соответствует рынку. Чем шире разброс между площадками, тем сильнее расхождение котировок и тем чаще система закладывает цену, которой на рынке уже нет.
Второе — задержка подтверждения. Между подтверждением сделки и её попаданием в блок проходит время, и на волатильном рынке это стоит процентов движения. Отсюда проскальзывание цены: клиент получает исполнение хуже зафиксированного, а если разрыв превышает порог защиты, срабатывает отмена сделки.
Больнее всего бьёт именно отмена сделки на пике движения. Клиент видит отказ ровно тогда, когда цена ушла в его пользу, и уходит к тому, кто исполнил. Хуже, если отказ приходит с задержкой: ликвидность зарезервирована, курс зафиксирован, а сделка не закрыта — расчётный остаток не сходится, и разбираться с этим приходится вручную.
Разбираем, как эта цепочка закрывается.
Что даёт управляемая цена сделки: эффект в сроках и долях
Подписанная котировка — это обязательство, а не картинка на экране. Источник курса (Chainlink) отдаёт значение вместе с меткой времени и сроком жизни, а контракт обмена принимает только те заявки, чья подпись сходится и чьё окно не истекло. Не прошла проверка — обмен не создаётся вовсе: пользователь видит внятную ошибку вместо частично исполненной сделки по уехавшей цене.
Время подтверждения сделки сокращается, потому что у заявки появляется один детерминированный путь: проверка подписи, резерв средств, расчёт. Нет ожидания внешней сверки курса и повторных пересчётов — предсказуемая цена сделки известна до отправки. Окно от нажатия до подтверждения уходит с десятков секунд к единицам, и это гарантия, заданная сроком жизни котировки, а не среднее по нагрузке.
Доля отменённых заявок падает по другой причине: клиент больше не рвёт сделку из-за движения рынка между показом цены и подтверждением. Отмена остаётся осознанным действием, а истёкшая котировка не убивает заявку, а возвращает её к пересчёту по свежему курсу. Незавершённых обменов становится меньше в разы, и каждая подтверждённая заявка доходит до расчёта.
Ручные разборы обращений уходят в автоматику. У котировки есть идентификатор, все подписи и переходы статусов пишутся в журнал, поэтому спорная сделка воспроизводится по логу за минуты, а не восстанавливается по переписке. Обращения в духе «куда ушла цена» в штатном режиме исчезают, а поддержка занимается реальными сбоями.
Три метрики — время, доля отмен, ручные разборы — выводятся на панель мониторинга, так что эффект от управляемой цены виден в цифрах, а не на словах.
Режимы удержания цены: жёсткий, скользящий и условный
Режим удержания определяет, кто принимает на себя риск движения курса между расчётом цены и исполнением обмена. В системе он задаётся двумя параметрами: окном удержания цены — сколько живёт зафиксированное значение, и лимитом на сделку — какой объём можно закрыть по этой цене без пересчёта. Ниже — три режима и границы, за которыми каждый из них перестаёт работать в плюс.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Жёсткое удержание цены | Сумма к получению известна заранее: выплаты, расчёты с фиксированной квотой, операции с низкой терпимостью к отклонению | Риск движения рынка целиком на стороне площадки, поэтому окно короткое, а лимит на сделку ниже остальных режимов |
| Скользящее удержание цены | Крупные объёмы и периоды волатильности, когда важнее исполнить сделку, чем удержать конкретное значение | Итоговая сумма не гарантирована: цена следует за рынком внутри защитного коридора, за его границей сделка останавливается и требует подтверждения |
| Условное удержание цены | Фиксация по событию: достижение порога, заданное время, статус контрагента или этап расчётов | Нужен внешний источник данных и явная логика отмены — при недоступности условия заявка истекает, а не исполняется по последней цене |
Режимы не взаимоисключающие: ядро поднимает жёсткое удержание цены на типовых заявках, скользящее — на крупных, а условное работает как страховка на сценариях с отложенным расчётом. Переключение задаётся правилом на уровне сделки, поэтому одна и та же интеграция закрывает разные схемы обмена без переписывания логики. Перед вводом в работу прогоняем на стенде истечение окна, дробление заявки по лимиту и недоступность источника цены — именно эти три случая дают расхождения в учёте.
Порядок внедрения: от аудита потока заявок до передачи
Начинаем с аудита потока заявок: смотрим, как котировка проходит от источника до клиента, где курс фиксируется фактически и в какой момент он может измениться незаметно для обеих сторон. Результат этапа — карта узких мест и перечень сценариев, в которых клиент получает курс хуже заявленного.
- Аудит потока заявок — разбираем журналы и очереди, считаем долю заявок с расхождением курса, фиксируем задержку между подтверждением и фактическим удержанием.
- Схема расчёта курса — описываем источники котировок, их вес, спред и окно актуальности; правило отбраковки устаревших значений формализуем в спецификации с примерами.
- Настройка правил удержания — задаём окно фиксации, лимиты по объёму, условия частичного исполнения и аннулирования, поведение системы при разрыве потока котировок.
- Проверка на нагрузке — воспроизводим профиль реального трафика с всплесками, замеряем время от подачи заявки до фиксации и убеждаемся, что правила удержания не деградируют на пике.
- Регламенты — описываем для поддержки и дежурной смены, как читать журналы расхождений, что делать при остановке источника и как оформлять спорные случаи.
- Передача — отдаём конфигурации, схему развёртывания, тестовые сценарии и документацию, обучаем команду и остаёмся на связи на период сопровождения.
Каждый шаг закрывается артефактом, который вы принимаете: карта потока, спецификация расчёта, набор правил, отчёт по нагрузке, регламенты, комплект документации. Так результат проверяется до вывода в промышленную эксплуатацию, а не после.
Комплект поставки: настройки, схемы и регламенты расчёта
Систему фиксации курса нельзя считать сданной, если её можно только эксплуатировать, но нельзя перенастроить. Поэтому в комплект входят артефакты, по которым команда заказчика сама меняет параметры, а сторонний подрядчик разбирается без обратного проектирования.
- Файлы настроек — источники котировок, окно удержания курса, допустимое отклонение, лимиты на объём сделки. Правятся конфигурацией, без изменения логики и повторного развёртывания.
- Схемы потоков заявок — путь от подачи до исполнения: где проверяются условия, где резервируется обеспечение, где фиксируется курс и что происходит при отказе.
- Документация по расчёту — формулы курса исполнения и комиссий, порядок округления, правила сверки источников и признаки неисполнимой сделки.
- Правила доступа — роли операторов, администраторов и внешних систем, матрица прав, порядок выдачи и отзыва ключей, лимиты на подпись операций.
- Регламент разбора спорных сделок — сроки обращения, состав доказательной базы, сверка с журналом событий, сценарий закрытия зависшей заявки.
- Регламент обновления и отката — как выпускается новая версия, кто её подтверждает и за какое время система возвращается к предыдущим настройкам.
Отдельно передаём инструкцию по развёртыванию на вашем контуре: изменения проверяются на копии до вывода в рабочую среду, поэтому настройки и регламенты остаются рабочими документами, а не приложением к отчёту.
Кейс: как сократили долю оспоренных сделок втрое
Что было на входе
Сервис обмена среднего размера: клиент нажимал «зафиксировать курс», приложение запоминало цифру, а исполнение шло отдельным запросом к внешнему источнику котировок. При резком движении рынка окно между фиксацией и подтверждением растягивалось, и курс в сделке расходился с курсом в момент списания. Спорных сделок набегало 4,8% от объёма, каждое обращение разбирали 2-3 дня — поддержка вручную сверяла биржевые выгрузки, внутренний кэш и данные CoinGecko. До 11% заявок клиенты отменяли сами, не дождавшись подтверждения.
Что изменили
Фиксацию курса перевели в серверный расчёт: в момент запроса формируется подписанный срез курса с меткой времени, и подтверждение сделки считается по этому же срезу, а не по новому запросу к источнику. Заявка стала идемпотентной — уникальный идентификатор защищает от двойного списания при повторе на плохой связи. Добавили порог допустимого отклонения: если курс ушёл дальше, сделка не подтверждается автоматически, а уходит в очередь разбора вместе с готовым контекстом.
Что стало
Доля оспоренных сделок — 4,8% → 1,6%. Разбор обращения — с двух дней до 40 минут: инженеру достаточно открыть журнал, где хранятся срез, метка времени и источник расчёта. Число отменённых заявок упало с 11% до 3%. Расхождение между фиксацией и подтверждением встречается в 0,1% сделок и всегда объяснимо по журналу — стабильность расчёта перестала зависеть от того, кто и в какую секунду нажал кнопку.
Как пересчитывается курс при частичном исполнении заявки
Удержанная цена привязана не к заявке целиком, а к объёму, под который зарезервировано обеспечение. Когда приходит частичное исполнение заявки, контракт фиксирует цену и объём этого исполнения отдельной записью, а резерв освобождает пропорционально: на 40% закрытого объёма уходит 40% блокировки. Остаток заявки продолжает жить как самостоятельная сущность со своим объёмом и своим сроком удержания.
Дальше вступает правило пересчёта курса. Модель «одна котировка на заявку» держит исходную цену до конца срока удержания — остаток исполняется по той же цене, что и первая часть. Модель «котировка на исполнение» переоценивает остаток после каждого частичного исполнения, беря цену из актуального состояния источника: им служит проверенный оракул вроде Chainlink, а не собственный расчётный модуль.
Выбор модели — это компромисс. Жёстко зафиксированная цена предсказуема для клиента, но при резком движении рынка остаток становится удобной целью для арбитража: заявку намеренно добивают частями, пока старая котировка ещё жива. Переоценка снимает этот риск, но добавляет заявке неопределённость — заранее неизвестно, по какому курсу закроется хвост.
Поэтому остаток получает повторное удержание цены с явными границами. Если отклонение от исходного курса выходит за заданный порог, остаток не исполняется: система отменяет его и возвращает зарезервированное обеспечение, а не закрывает по устаревшей цене. Каждый вызов привязан к идентификатору заявки и номеру исполнения, поэтому повторная обработка одного и того же события не задваивает резерв.
Наружу это выходит последовательным журналом: сколько исполнено и по какой цене, сколько осталось, по какой цене удерживается остаток и до какого момента. Такой журнал даёт однозначную сверку — расхождение между отчётом площадки и состоянием заявки видно на конкретном шаге, а не растворяется в агрегате.
Частые технические вопросы по расчёту и защите от расхождений
Пять вопросов задают до старта работ: от того, как устроен ответ, зависит архитектура расчёта и набор проверок. Ниже — короткие ответы в том виде, в каком мы их даём: без формулировки «сделаем надёжно», а с конкретной механикой.
Откуда берётся курс — один источник или несколько?
Берём выборку независимых поставщиков и считаем медиану, а не среднее: одиночный выброс не двигает результат. Если расхождение котировок между источниками превышает заданный допуск, значение отбрасывается, а не усредняется.
Что именно попадает в журнал расчётов?
Каждая фиксация пишет неизменяемую запись: входные котировки с метками времени, применённый допуск, итоговый курс, идентификатор запроса. Журнал только дополняется, а правка оформляется отдельной записью-корректировкой со ссылкой на исходную.
Как устроена защита от манипуляций на тонком рынке?
Курс считается по временному окну, а не по одной точке: кратковременный выкуп объёма не сдвинет результат. Для пар с низкой ликвидностью порог отклонения расширяется, а крупная заявка уходит на подтверждение.
Насколько свежими должны быть данные на момент фиксации?
В расчёт идёт значение не старше заданного интервала — устаревшая котировка помечается и отбрасывается. При обрыве потока система переключается на резервный источник и фиксирует факт переключения в журнале.
Можно ли проверить расчёт постфактум?
Да. По записи журнала расчёт воспроизводится: те же входные данные дают тот же курс. Это позволяет разобрать спорный случай без доступа к внутренней логике сервиса.
Обсудим задачу: что нужно для старта работ
Чтобы вернуться с оценкой и планом работ, а не с общими формулировками, нам нужны исходные данные по вашему сценарию фиксации. Ниже — то, что снимает основную часть неопределённости; часть пунктов закрываем прямо на созвоне.
- Источники курса: свои или внешние, сколько независимых потоков, как решается расхождение между ними.
- Логика фиксации: кто инициирует, на какой срок, что происходит по истечении и можно ли продлить.
- Поведение при отклонении рынка: допустимый коридор, автоотмена, ручное подтверждение оператором.
- Роли и доступы: кто ставит, подтверждает и отменяет фиксацию, какие лимиты действуют на оператора.
- Где считается результат: изолированный контур, кастодиальный учёт или гибридная схема.
- Учёт и отчётность: выгрузки для сверки, журнал всех действий, требования к хранению истории.
- Нагрузка: сколько фиксаций в сутки и сколько одновременно в пике.
- Что уже есть: контракты, интеграции, тестовые стенды, ограничения вашей инфраструктуры.
По этим данным собираем оценку и план работ: разбиваем на этапы, фиксируем точки контроля и сроки внедрения. Отдельно считаем контур фиксации, интеграции и отказоустойчивость — так запуск можно делать частями, без ожидания всего объёма. Опишите задачу в свободной форме, остальное уточним вопросами.
