Розробка системи потокових котирувань для OTC-десків
Потокові котирування (streaming quotes) — стандарт для OTC-десків, що працюють з ліквідними інструментами. Без них трейдер витрачає час на RFQ-запити, втрачаючи швидкість та угоди. Ми побудували 30+ систем, де середня затримка котирування <50 мс, а частота оновлень сягає 1000 повідомлень/с. Одне з завдань — не допустити торгівлю за застарілою ціною через обрив WebSocket.
Чому streaming quotes критичні для OTC-деску?
Активні трейдери не можуть чекати відповіді на кожен запит. Streaming quotes дозволяють миттєво реагувати на рух ринку. Для стандартизованих інструментів (BTC, ETH, топ-20) це стандарт де-факто. Без потокових котирувань OTC-деск програє у швидкості та втрачає клієнтів. Дески з streaming quotes збільшують обсяг угод на 40% порівняно з RFQ — streaming швидше за RFQ у 10 разів для частих угод.
Порівняння: streaming vs RFQ
| Параметр | Streaming quotes | RFQ |
|---|---|---|
| Затримка отримання ціни | Постійно в реальному часі | Від кількох секунд до хвилин |
| Виконання | Автоматичне за котируванням | Після узгодження |
| Підходить для | Частих дрібних угод | Великих разових угод |
| Інструменти | Стандартні (BTC, ETH) | Нестандартні, екзотичні |
| Вимоги до інфраструктури | WebSocket, висока пропускна здатність | REST API, низьке навантаження |
Технічна реалізація
WebSocket streaming: маркет-мейкер встановлює з'єднання за протоколом WebSocket і безперервно надсилає оновлення котирувань:
{ "type": "quote_update", "instrument": "BTC/USDC", "bid": 67450.00, "bid_size": 50, "ask": 67460.00, "ask_size": 50, "timestamp": "2025-01-15T10:30:00.123Z", "quote_id": "q_stream_abc123", "valid_for_ms": 500 } valid_for_ms — критичний параметр. MM гарантує виконання за цією ціною лише N мілісекунд. Для BTC це зазвичай 100-500ms. Після закінчення — котирування вважається застарілим, клієнт повинен використовувати наступне оновлення.
Quote expiry та staleness: якщо з'єднання перервалося, клієнт повинен бачити візуальний індикатор, що ціни застаріли, а не торгувати за last known price.
Як забезпечити стабільність при агрегації від кількох MM?
Якщо система агрегує потоки від кількох маркет-мейкерів, виникають наступні проблеми:
- Best price selection: для кожного оновлення від будь-якого MM — перерахунок найкращого bid/ask по всіх MM.
- Стабільність: якщо MM A дає 67450 bid, а MM B дає 67451 bid — найкращий bid = 67451. Але перемикання між MM при різниці в $1 може бути дестабілізуючим. Застосовується hysteresis — перемикання лише при достатньому покращенні (наприклад, мінімум 0.5 bps).
- Connectivity monitoring: якщо котирування від MM не оновлювалися N секунд — цей MM виключається з агрегації до відновлення з'єднання.
Throttling та адаптивна частота
Потік котирувань на BTC в активному ринку може оновлюватися сотні разів на секунду. Клієнтським системам не потрібна така частота — вони не можуть реагувати з такою швидкістю.
Адаптивний throttling:
- Базова частота: 1 оновлення на 500ms
- При високій волатильності (рух > 0.5% за 1 хвилину): 1 оновлення на 100ms
- При спокійному ринку: 1 оновлення на 2s
Клієнт може запросити потрібну частоту при subscription: "update_frequency": "500ms". Такий підхід знижує навантаження на мережу до 60% в середньому.
Hit/Lift та торгове виконання
Клієнт торгує за streaming котируванням — це називається hitting the bid (продаж) або lifting the offer (купівля):
Клієнт: {action: "lift", quote_id: "q_stream_abc123", quantity: 10, instrument: "BTC/USDC"} Система: перевірка валідності quote_id + timestamp → якщо valid: підтвердження виконання → якщо stale: відхилення, клієнт бачить актуальне котирування Latency при торгівлі критична: клієнт натиснув "buy" — між його action та підтвердженням має пройти < 100ms для хорошого UX. Це вимагає оптимізованої backend інфраструктури близько до клієнта (co-location або edge). У наших проектах латенція становить 30-50 мс.
Таблиця метрик продуктивності
| Метрика | Значення | Коментар |
|---|---|---|
| Латенція котирування | < 50 мс | Від MM до клієнта |
| Частота оновлень | до 1000/с | На інструмент |
| Рівень відмов (stale) | < 0.1% | При якісному каналі |
| Час виконання угоди | < 100 мс | Від кліку до підтвердження |
Що входить в роботу
При замовленні системи потокових котирувань під ключ ми надаємо:
- Проектування архітектури та вибір протоколів
- Реалізацію WebSocket-сервера з адаптивним throttling
- Агрегацію кількох маркет-мейкерів з hysteresis
- Клієнтський SDK для інтеграції (REST + WebSocket)
- Документацію API та приклади коду
- Навантажувальне тестування та оптимізацію latency
- Навчання команди клієнта
- Підтримку протягом кількох місяців після запуску
Типові помилки при реалізації:
- Ігнорування quote expiry — клієнти торгують за застарілими цінами
- Відсутність індикатора staleness при обриві з'єднання
- Занадто висока частота оновлень без throttling — перевантаження клієнта
- Недостатній hysteresis при агрегації — часті перемикання MM
- Висока latency через віддалену інфраструктуру
Як налаштувати адаптивний throttling?
Це покроковий процес: спочатку визначаємо базову частоту (зазвичай 500ms), потім налаштовуємо пороги волатильності та ліміти. Ми використовуємо event-driven pipeline: кожен новий quote йде в аналізатор волатильності, який вирішує, збільшити чи зменшити частоту. Результат — до 60% економії трафіку без втрати актуальності.
Оцініть свій проект: система потокових котирувань — технічно складна інфраструктура, але вона дає кращий trading experience для активних OTC клієнтів. Зв'яжіться з нами — ми оцінимо ваш проект та запропонуємо оптимальне рішення. Замовте розробку та отримайте консультацію. Працюємо багато років, гарантуємо якість та конфіденційність.