Smart order routing: де заявки втрачають на фрагментації ліквідності
Велика заявка майже ніколи не знаходить весь обсяг в одному стакані. Ліквідність розмазана: частина стоїть на централізованих біржах, частина — у пулах децентралізованих майданчиків, частину виставляють маркет-мейкери. У кожного джерела своя глибина, свій спред і свої правила виконання.
Фрагментація ліквідності сама по собі не проблема — проблема в тому, що маршрут вибирається один: за звичкою, за найкращою верхньою котировкою або за найзнайомішим майданчиком. Система бачить лише той обсяг, який лежить на вибраному джерелі, і надсилає туди заявку цілком.
Звідси два класи втрат. Прослизання ціни: кожен наступний рівень стакана дорожчий за попередній, і середня ціна угоди від'їжджає від тієї, що була видна в момент ухвалення рішення.
Часткове виконання: глибина майданчика закінчується раніше за обсяг, і недобраний залишок або повертається, або йде в повторний запит уже за зсунутим ринком.
Далі ефект накопичується. Повторні заявки конкурують одна з одною і з чужими алгоритмами, а втрата обсягу заявки зростає нелінійно: чим більший розмір, тим гірший результат вибору одного майданчика.
Smart order routing закриває саме цей розрив — маршрут збирається динамічно, з кількох джерел, під конкретний обсяг і поточний стан стаканів. Нижче розбираємо, як це влаштовано і від чого залежить якість виконання.
Що змінюється після впровадження маршрутизації заявок
Перше, що видно вже в першу добу після вмикання маршрутизації, — частка виконання.
Заявка перестає йти на один заздалегідь вибраний майданчик: алгоритм оцінює доступний обсяг на кожному й розподіляє її частинами, тому обсяг, який раніше залишався невиконаним або знімався вручну, закривається в тому ж циклі.
Другий ефект — середня ціна виконання. Маршрутизатор зіставляє не лише найкращу котировку, а й глибину ринку на кожному рівні, комісії та очікуване прослизання, а велику заявку дробить так, щоб не виїдати один стакан.
На дистанції це зсуває середню ціну ближче до середини ринку й прибирає разові переплати на тонких рівнях.
Третій — стійкість до відмови окремого майданчика. Якщо з'єднання рветься, зростає затримка відповіді або падає доступна глибина, маршрут перебудовується на резервні джерела, а невиконаний залишок переноситься туди зі збереженням початкових умов заявки. Відмова одного майданчика перестає бути подією, що потребує ручного втручання.
Четвертий — передбачувані витрати. Чим точніше розподілено обсяг, тим менше зустрічних переказів між майданчиками й проміжних конвертацій, а витрати на переміщення коштів перестають залежати від того, хто і в якому порядку виставляв заявки вручну.
Далі метрики стабілізуються: частка виконання й середня ціна перестають залежати від того, якому майданчику «пощастило» в моменті.
З'являється спостережуваність — за кожною заявкою видно вибраний маршрут і причину вибору, тому зміни в правилах перевіряються на історії, а не на відчуттях.
Режими routing: книга заявок, пули ліквідності, гібрид
Схеми виконання відрізняються не наявністю книги заявок або пулів ліквідності, а тим, хто утримує ордер у момент угоди і як ділиться обсяг. Від цього залежить прослизання, кількість часткових заповнень і те, як контур поводиться, коли один із майданчиків перестає відповідати.
Нижче — робочі варіанти, між якими вибирають під час проєктування роутера. Ми не фіксуємо схему заздалегідь: спочатку дивимося, де стоїть ліквідність і наскільки передбачуваний потік зустрічних заявок, і лише потім пропонуємо контур.
| Схема | Коли підходить | Обмеження |
|---|---|---|
| Один майданчик | Ліквідність зібрана в одному місці, обсяги невеликі | Точка відмови одна, зі зростанням заявки зростає прослизання |
| Розбиття заявки | Великий ордер проти тонкої книги заявок | Фрагменти йдуть за різними цінами, потрібен контроль часткових заповнень і повторів |
| Роутер-контракт | Кілька пулів ліквідності в одному контурі | Атомарність лише всередині контуру, маршрути оновлюються за підтвердженням оператора |
| Внутрішній метчинг із хеджем | Потік зустрічних заявок клієнтів стійкий | Зміщення власної позиції: потрібні ліміти ризику й хедж на кожну пару |
| Гібрид | Частина обсягу закривається всередині, залишок іде назовні | Більше станів ордера, складніше розбирати виконання за журналами |
| Міжмережеве виконання | Ліквідність розподілена по кількох мережах | Затримка переходу, ризик незавершеного переказу, розходження балансів |
Варіанти комбінуються: роутер-контракт зазвичай доповнює розбиття заявки, а внутрішній метчинг працює поверх гібрида.
Впровадження алгоритму маршрутизації: етапи робіт
Маршрутизацію не пишуть «у вакуумі»: спочатку потрібно зрозуміти, де саме втрачається ціна виконання. На вході — мета знизити прослизання й вартість проходу по стакану за заданого ліміту часу на угоду. Нижче сім етапів, кожен закінчується артефактом, який можна перевірити й передати вашій команді.
- Аудит майданчиків і моделей виконання. Збираємо режими виставляння заявок, правила скасування, ліміти, поведінку при обриві з'єднання — фіксуємо, які джерела ліквідності реально доступні.
- Схема правил вибору маршруту. Описуємо пріоритети: ціна, доступний обсяг, імовірність виконання, затримка відповіді майданчика. Правила узгоджуються письмово до першого рядка коду.
- Прототип ядра. Модуль розбиття великої заявки на частини й перерахунку маршруту за кожної зміни стакана.
- Інтеграції. Єдина модель заявки й угоди, обробка часткових виконань, повторних спроб і відмов майданчика.
- Перевірка на історичних даних. Прогін на записаних потоках котировок і порівняння з базовою стратегією: прослизання, частка виконаних заявок, поведінка на тонкому ринку.
- Запобіжники й моніторинг. Ліміти на розмір позиції та темп виставляння, автоматичне вимкнення маршруту при відхиленні метрик, журнал ухвалених рішень.
- Передача в експлуатацію. Конфігурація, документація щодо правил, регламент змін і навчання вашої команди.
Артефакти постачання: ядро маршрутизації, схеми, регламенти
Віддаємо не звіт, а робочий контур розумної маршрутизації ордерів, який ваша команда веде далі без нас. Приймання прикладне: інженери замовника самі збирають ядро з репозиторію й змінюють правила маршруту на тестовому контурі — якщо це виходить без підказки, постачання відбулося.
- Вихідний код ядра маршрутизації й відтворюване складання: репозиторій, залежності, тести на сценарії з низькою ліквідністю та відмовою майданчика.
- Схема маршрутів: граф майданчиків і зв'язок, порядок розбиття обсягу, пріоритети й умови перемикання між маршрутами.
- Конфігурації підключень: параметри сесій, ліміти на обсяг і частоту звернень, поведінка при недоступності джерела.
- Політики доступу й ключів: ролі, права на правку маршрутів, ротація ключів, розділення середовищ виконання.
- Документація алгоритму: критерії вибору маршруту, обмеження моделі, карта метрик і трактування відхилень.
- Регламент моніторингу: перелік метрик якості виконання, пороги оповіщень, чергові дії.
- Регламент відкату: версіонування правил, повернення до попереднього набору маршрутів, порядок виведення майданчика з роботи.
Усе передаємо разом із розбором на ваших даних: де вузькі місця, які пороги виставлені й чому. Далі додавання майданчиків і правка маршрутів ідуть у вас, без звернення до нас за кожною ітерацією.
Кейс: маршрутизація потоку заявок між шістьма майданчиками
Клієнт — маркет-мейкер, який тримав потік заявок на шести майданчиках. До впровадження маршрут вибирав оператор вручну: звіряв таблиці ліквідності, вирішував, куди надіслати обсяг, і на рухливому ринку це рішення відставало від ціни. Частина обсягу залишалася невиконаною, а угоди йшли за ціною помітно гірше від орієнтира.
Ми зібрали єдиний стакан з усіх шести майданчиків і навчили алгоритм розподіляти обсяг за доступною ліквідністю з урахуванням комісій, затримки відповіді та ризику часткового виконання.
Підключення йдуть через FIX-шлюзи — це дає єдиний потік подій і журнал маршрутів: майданчик, вага, причина вибору. Відмова майданчика обробляється штатно — її вага перерозподіляється між рештою всередині одного циклу, без ручного втручання.
Заміри до і після
| Показник | До | Після |
|---|---|---|
| Частка виконаного обсягу | 61% | 94% |
| Відхилення середньої ціни від орієнтира | 11 б.п. | 3 б.п. |
| Відмова одного майданчика | ручне перемикання, простій до 15 хвилин | перерозподіл ваги, простій не фіксується |
| Розбір спірної угоди | звірка вручну, години | запис у журналі маршрутів, хвилини |
Обидва заміри замовник проводив сам, на різних періодах і різних наборах інструментів, порівнюючи журнал маршрутів із вивантаженням із торгових систем.
Обидва дали однаковий напрям: частка виконання зросла, відхилення від орієнтира стиснулося, а падіння одного майданчика перестало бути інцидентом — заявки йшли на решту, якість виконання не просідала.
За цими ж замірами видно, куди змістилося вузьке місце: уже не ручний вибір майданчика, а повнота й свіжість вхідних даних про ліквідність.
Чим відрізняється маршрутизатор від простого розбиття заявки
Розбиття заявки — арифметика, задана заздалегідь: обсяг ділиться на частки й розкидається по майданчиках за фіксованим правилом.
Маршрутизатор рахує маршрут на кожному кроці заново: перш ніж надіслати чергову частину, він перечитує стан книги заявок і пулів ліквідності, а також витрати на переказ коштів між майданчиками.
Ключова різниця — у реакції на зміну глибини ринку. Статична сітка не знає, що на другому майданчику ліквідність просіла: вона продовжить віддавати туди частки й збере виконання за найгіршими рівнями ціни.
Динамічний маршрут перевіряє глибину на кожному рівні, порівнює її з порогом ліквідності й переносить залишок туди, де він закриється цілком, без прослизання.
Другий фактор — витрати й ризик невиконання. Переказ коштів між майданчиками займає час і коштує мережевих витрат, а частина обсягу може залишитися невиконаною.
Маршрутизатор відкидає варіанти, де виграш за ціною не перекриває витрати на переказ, і ділить залишок так, щоб кожна частина вкладалася в доступну глибину.
Перерахунок маршруту відбувається після підтвердження кожної частини, а не один раз на вході. Тому зустрічний обсяг, що надійшов у процесі, або вихід ліквідності з майданчика змінюють залишок, а не ламають усю заявку.
Галузевий розбір Виконання великих заявок на децентралізованих майданчиках підтверджує: саме покроковий перерахунок дає виграш на обсягах, зіставних із глибиною ринку.
На малих обсягах, які вкладаються в перший рівень ціни, різниця між підходами майже непомітна. На великих — розходяться частка виконаного обсягу, відхилення середньої ціни від розрахункової та частка заявок, закритих частково.
Технічні питання: затримки, часткові виконання, відмова майданчика
Маршрутизатор працює там, де частина відповідей приходить пізніше, ніж потрібно, а частина не приходить узагалі. Нижче — розбір сумнівів, які найчастіше випливають під час проєктування smart order routing.
Що робити, якщо затримка відгуку майданчика зросла?
Маршрут будується з урахуванням свіжості котировки: застарілі знімки виключаються, інакше виграш за ціною виявиться уявним. На очікування відповіді ставиться ліміт — якщо майданчик не вклався, заявка йде на наступний маршрут.
Як обробляється залишок заявки при частковому виконанні?
Залишок не надсилається наосліп: маршрут перераховується за доступною глибиною, обсяг дробиться між майданчиками. Якщо ліквідність вичерпана, залишок або знімається, або виставляється лімітною частиною за заданою ціною.
Що відбувається при недоступності майданчика?
Майданчик перевіряється до надсилання заявки, а не після. При серії помилок він автоматично виводиться з маршруту на час, завислі заявки знімаються, потік іде через решту напрямів.
Чи враховуються витрати на переказ коштів між майданчиками?
Рахуємо не лише комісію, а й час переказу та ризик не дійти. Якщо витрати з'їдають різницю в ціні, маршрут через цей майданчик не розглядається взагалі.
Наскільки складно вбудувати це в уже працюючу систему?
Маршрутизатор підключається до вашого шлюзу через адаптер, торговий контур і облік залишаються незмінними. Вмикаємо поетапно: спочатку частину потоку, з можливістю повернути обробку на попередній контур.
Що потрібно для старту і як ми повернемося з оцінкою
Для оцінки алгоритму smart order routing потрібен ваш контекст, а не загальні побажання: без вхідних даних будь-який план етапів перетворюється на ворожіння. Нижче — що достатньо передати на першому кроці. Якщо частина відомостей є лише в голові трейдера або в старих логах — розберемо разом.
- Перелік майданчиків та інструментів, між якими потрібно розподіляти заявки, включно з тими, що плануються до підключення.
- Поточні правила виконання: як маршрут вибирається зараз — вручну, скриптом або зовнішнім сервісом — і що саме в них не влаштовує.
- Показники якості виконання, які вважаєте нормою: частка виконаних заявок, відхилення ціни від очікуваної, час від рішення до угоди.
- Обмеження за ризиком: ліміти на майданчик та інструмент, поведінка при частковому виконанні, що робити при недоступності одного з напрямів.
- Характер потоку заявок: частоти, типові розміри, розподіл за часом — це визначає, наскільки швидким має бути розрахунок маршруту.
- Вимоги до спостережуваності: які події та метрики потрібно бачити в реальному часі, що зберігати для розбору інцидентів.
- Інфраструктурні рамки: де алгоритм працюватиме, які доступи й середовища вже є, хто відповідає за експлуатацію після запуску.
Далі порядок такий: обговорюємо задачу, вивчаємо передані матеріали, перевіряємо ключові припущення на історичних даних. Потім повертаємося з оцінкою, планом етапів і складом робіт — з явним розділенням, що закриваємо ми, а що залишається на вашій стороні.
