Development системы RFQ (Request for Quote) для OTC
RFQ — Request for Quote — протокол двусторонней котировки, где покупатель запрашивает цену у нескольких маркет-мейкеров и выбирает лучшую. В отличие от order book торговли, цена не публична до момента запроса. Это стандарт институциональной торговли на традиционных рынках, перенесённый в крипто.
RFQ Flow детально
1. Клиент → система: RFQ запрос
{instrument: "BTC/USDC", side: "buy", quantity: 100,
expiry: 30s, client_id: "inst_001"}
2. Система → маркет-мейкеры: broadcast запроса
(одному или нескольким MM одновременно)
3. Маркет-мейкеры → система: котировки
{bid: 67450.00, ask: 67480.00, valid_until: T+30s}
4. Система → клиент: лучшие котировки (или агрегация)
5. Клиент → система: принятие котировки
{quote_id: "q_abc123", accept: true}
6. Система → MM: уведомление об исполнении
7. Settlement: обмен активами
Управление котировками
Quote aggregation: при нескольких MM система может агрегировать котировки:
- Best-of: показать клиенту лучший bid/ask от разных MM
- NBBO (National Best Bid and Offer) в крипто-OTC контексте
- Internalization: если деск может исполнить из собственного инвентаря по лучшей цене
Quote validity: каждая котировка имеет expiry (30-60 секунд). После истечения — auto-cancel. MM не хочет быть exposed на цену которую дал минуту назад при движении рынка.
Partial fills: если MM даёт котировку на 100 BTC, а клиент хочет 50 BTC — split quote. Или клиент запрашивает 200 BTC, а один MM может дать только 100 — multi-venue fill.
Маркет-мейкер management
Система управляет пулом MM:
Routing rules: каким MM отправлять какие RFQ. Критерии: специализация по инструменту, размер сделки, исторический hit rate (как часто MM дают принятые котировки), spread competitiveness.
Response time tracking: MM которые медленно отвечают ухудшают UX. Система трекает median response time каждого MM и de-prioritizes slow responders.
Quote quality metrics:
- Fill rate: процент котировок которые были приняты
- Miss rate: котировка была лучшей но клиент не принял (возможно слишком широкий спред)
- Stale quotes: котировки отправленные после истечения expiry
Connectivity: MM подключаются через WebSocket (низкая latency для котирования) или REST (для систем без WS capability). FIX 4.4 для интеграции с институциональными MM-системами.
Real-time state management
RFQ система высоконагруженная и state-ful. Активные RFQ запросы, pending котировки, accepted quotes ожидающие settlement — всё это меняется за секунды.
Redis для hot state: активные RFQ и котировки хранятся с TTL, автоматически экспирируются. Pub/sub для real-time нотификаций участников.
Event sourcing: все события (RFQ created, quote received, quote accepted, settlement confirmed) пишутся в immutable log. State восстанавливается из событий. Audit trail из коробки.
Anti-gaming mechanisms
Недобросовестные участники могут злоупотреблять системой:
Last look: MM оставляет право отклонить принятую котировку. Защита от HFT-клиентов которые принимают котировку только когда рынок уже двинулся в их пользу. Controversial — клиенты не любят last look, но MM его требуют.
Rate limiting для RFQ запросов: клиент не должен мочь делать сотни RFQ в секунду для "price discovery" без намерения торговать. Это information extraction против MM.
Minimum trade size: только реальные институциональные сделки.
IP restrictions: только whitelisted институциональные клиенты могут отправлять RFQ.
RFQ система — более сложная в реализации чем простое matching engine, но обеспечивает institutional-grade trading experience для крупных объёмов.