Development системы потоковых котировок для OTC
Streaming quotes — это непрерывный поток двусторонних котировок (bid/ask) от маркет-мейкера к клиенту в реальном времени, без необходимости каждый раз делать RFQ запрос. Клиент видит актуальные цены постоянно, как биржевой стакан, но с гарантией исполнения по котируемой цене.
Streaming vs RFQ: когда что использовать
RFQ лучше для: разовых крупных сделок, нестандартных инструментов, ситуаций когда клиент не торгует регулярно.
Streaming quotes лучше для: активных трейдеров с частыми транзакциями, стандартизированных инструментов (BTC, ETH, топ-20), клиентов которым нужна цена «сейчас» без ожидания response.
Техническая реализация
WebSocket streaming: маркет-мейкер устанавливает WebSocket соединение и непрерывно отправляет обновления котировок:
{
"type": "quote_update",
"instrument": "BTC/USDC",
"bid": 67450.00,
"bid_size": 50,
"ask": 67460.00,
"ask_size": 50,
"timestamp": "2024-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.
Throttling и адаптивная частота
Поток котировок на BTC в активном рынке может обновляться сотни раз в секунду. Клиентским системам не нужна такая частота — они не могут реагировать с такой скоростью.
Адаптивный throttling:
- Базовая частота: 1 обновление в 500ms
- При высокой волатильности (BTC двигается > 0.5% за 1 минуту): 1 обновление в 100ms
- При спокойном рынке: 1 обновление в 2s
Клиент может запросить нужную ему частоту при subscription: "update_frequency": "500ms".
Управление несколькими 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 исключается из агрегации до восстановления соединения.
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).
Система потоковых котировок — технически сложная инфраструктура, но даёт лучший trading experience для активных OTC клиентов.