Скринер глибини ринку: де ламається оцінка ліквідності
Рішення про угоду найчастіше ухвалюють за останньою ціною: вона одна, її просто показати й порівняти. Але ліквідність визначається не ціною, а щільністю заявок на рівнях поруч із нею.
Скринер глибини ринку збирає стакан заявок і рахує, який обсяг реально виконається без зсуву котирування — тобто дає оцінку ліквідності замість ілюзії «ціни».
Ламається це на тонких парах. Верх стакана виглядає щільним, але за ним порожньо: перша ж велика заявка проходить через десяток рівнів і зсуває ціну.
Прослизання ціни виявляється в рази вищим за розрахункове, а розмір позиції, який за останньою ціною виглядав безпечним, перевищує денний обсяг пари. При цьому сам актив торгується на кількох майданчиках, і глибина на кожному з них своя.
Друга причина — застарілі дані. Скринер, який запитує стакан за розкладом, показує вже неіснуючу картину: між запитами лімітні заявки знімають, ринкові виконують, і рівень, на який ви розраховували, зникає.
Агрегатор біржових даних вирішує це потоковими оновленнями й зводить глибину майданчиків в одну картину, але потребує нормалізації кроку ціни, комісій і різного формату віддачі в кожного джерела.
Ціна такої помилки — вхід за ціною, якої вже немає, і сигнал, що спрацював після руху. Розбираємо далі, як оцінка ліквідності перетворюється на набір вимірюваних метрик: глибина в межах відхилення від середини, ширина спреду, стійкість рівня в часі. Кожна з них працює лише на потокових даних — інакше метрика бреше.
Що змінюється після впровадження: вимірювані ефекти
Скринер глибини ринку перетворює потік котирувань на керований сигнал: розрізнені спостереження за майданчиками змінюються одним контуром контролю, який повідомляє про стан ліквідності до того, як угода піде в прослизання. Нижче — чотири наслідки, які видно на метриках у перші тижні.
Швидкість реакції замість розбору постфактум
Оповіщення про прослизання надходять у момент перетину порогу глибини за парою, а не після виконання за гіршою ціною. Черговий бачить зміну книги заявок одразу, тому реакція вимірюється хвилинами, а не тривалістю розбору інциденту.
Керована частка хибних сигналів
Поріг будується на мінімальній глибині в межах заданого відхилення ціни, а не на одній спредовій величині. Шум коротких підтягувань котирувань відсікається, частка незмістовних оповіщень падає кратно, і чергування перестає вигорати на порожніх спрацюваннях.
Зменшення простоїв на виконанні
Часта відмова — спроба провести обсяг через порожню ділянку книги, після чого маршрутизація перебудовується вручну. Постійний моніторинг ліквідності знімає цей клас: маршрут перезбирається за даними, і простій скорочується з годин до хвилин.
Повнота картини за майданчиками
Єдина шкала ліквідності приводить глибину різних ринків до зіставної величини з поправкою на комісію та схему розрахунку. Зведення звіряється із зовнішніми агрегаторами на кшталт CoinGecko, тому картина не залежить від того, чий інтерфейс відкритий в оператора.
Режими роботи: потік, знімки за розкладом, архів
Режими збору даних визначають, що взагалі потрапить у зріз ліквідності й наскільки глибоко його потім можна переперевірити.
Потік даних у реальному часі дає повну картину змін, знімки стакана за розкладом — зіставні точки для порівняння майданчиків, архів зрізів ліквідності — основу для історії та розбору спірних ситуацій.
Обмеження в кожного режиму своє. Потік пише кожну зміну й зростає разом з активністю ринку; знімки економлять обсяг, але пропускають усе, що сталося між опитуваннями; архів зберігає агрегати, з яких окрему заявку вже не відновити.
Що вибрати під задачу
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Потік даних у реальному часі | Алерти за різкими провалами глибини, контроль великих заявок | Запис зростає лінійно з активністю; при обриві зв'язку вікно втрачається, потрібна буферизація |
| Знімки стакана за розкладом | Порівняння майданчиків, звіти, історичні графіки | Між опитуваннями зміни не видно; короткий сплеск може залишитися непоміченим |
| Архів зрізів ліквідності | Довгі періоди, перевірка моделей, ретроспектива | Зберігає агрегати, деталізацію окремої заявки не повернути |
| Змішаний: потік і знімки | Потрібні і алерти, і зіставна історія | Два контури збору треба синхронізувати за часом |
Етапи робіт: від аудиту майданчиків до передачі системи
Майданчики віддають різну глибину ринку: десь видно весь стакан, десь лише верхні рівні, десь дані надходять із затримкою та обривами зв'язку.
Зібрати з цього один зіставний потік можна лише після звірки джерел, тому робота йде етапами — від аудиту майданчиків до передачі системи.
- Аудит біржових майданчиків. Перевіряємо, які рівні стакана доступні, з якою частотою оновлюються, чи є історія для зворотної перевірки правил і які ліміти накладає майданчик.
- Схема потоків даних. Фіксуємо, що забираємо безперервним каналом, що — періодичними зрізами, де потрібне резервне джерело на випадок обриву.
- Нормалізація даних. Приводимо позначення пар, одиниці обсягу, точність ціни та мітки часу до одного вигляду — без цього порівняння майданчиків дає хибні сигнали.
- Розрахунок метрик глибини. Рахуємо щільність заявок у межах заданого відхилення від ціни, дисбаланс сторін і швидкість, з якою ліквідність зникає.
- Налаштування оповіщень. Задаємо пороги за кожною метрикою, час утримання умови й антибрязкіт, щоб канал не забивався шумом; правила зберігаємо в конфігурації, яку можна змінювати без повторного збирання.
- Перевірка на історичних даних. Запускаємо правила на записах минулих періодів і дивимося частку хибних спрацювань і пропусків.
- Приймання системи та передача документації. Звіряємо метрики з ручним розрахунком, оформлюємо звіти, інструкції з експлуатації та порядок дій при збої джерела.
Що залишається у вас: конфігурації, схеми, регламенти
Робочий скринер — це половина результату. Друга половина — комплект артефактів, за якими ваша команда зможе піднімати систему, змінювати джерела й розбирати інциденти без нашої участі.
Передаємо все у вигляді текстових файлів і схем у вашому репозиторії, а не у вигляді «налаштовано в нас на сервері».
- Конфігурації підключень — адреси джерел, список торгових пар, ліміти запитів, час очікування відповіді та правила повторних спроб; редагуються без повторного збирання коду.
- Схеми потоків даних — від знімків стакана й стрічки угод до розрахунку глибини, щільності рівнів і дисбалансу обсягів, із позначкою точок перезапуску без втрати стану.
- Права доступу й ролі — матриця «роль → дія»: хто змінює пороги алертів, хто бачить історію, хто керує ключами; ключі зберігаються поза репозиторієм, дії потрапляють у журнал аудиту.
- Регламент реагування — що означає кожен тип алерту, кому й куди він іде, за який час очікується реакція, як відрізнити ринковий рух від збою джерела і що робити при хибному спрацюванні.
- Журнали й метрики — затримка доставки даних, частка пропущених оновлень, кількість спрацювань за кожним правилом, час реакції; окремо описано вивантаження за період і терміни зберігання.
- Документація по системі — архітектура, формули метрик глибини, схема зберігання, порядок підключення нової біржі та її перевірки на історичних даних.
- Інструкції з розгортання та відкату — як підняти контур з нуля і як повернутися до попередньої версії правил і конфігурацій, якщо зростання спрацювань виявиться хибним.
Кейс: хибні сигнали на тонкому ринку і як їх прибрали
До: ручний збір і розсинхрон зрізів
Аналітик зводив книгу заявок із чотирьох майданчиків вручну в одну таблицю. Зрізи надходили з різницею в кілька секунд, глибина рахувалася за різними мітками часу, одиниці обсягу не збігалися.
На тонкому ринку, де ціна рухається від десятка великих заявок, такий розсинхрон давав до семи хибних сигналів із десяти, а команда встигала відреагувати вже після відкату.
Розбираємо, що змінили. Майданчики підключили потоком, зрізи привели до єдиної мітки часу й нормалізували обсяги.
Метрика глибини рахується в заданому коридорі відхилення від середини, а не за всією книгою заявок, тому спред і «пил» на дальніх рівнях більше не спотворюють картину.
Після: сигнал підтверджується серією зрізів
Алерт спрацьовує, лише якщо дисбаланс тримається кілька послідовних зрізів підряд і глибина на боці тиску перевищує поріг.
Поріг задається в конфігурації окремо за кожним інструментом — CoinGecko використовується як референс для звірки цін і відсікання викидів з одного майданчика.
Частка хибних сигналів впала з семи з десяти до однієї-двох, час реакції команди скоротився з хвилин до секунд. Повідомлення надходить разом із готовим зрізом: видно, на якому майданчику набрана глибина, як вона змінювалася і який поріг спрацював.
Чим глибина ринку відрізняється від обсягу торгів
Обсяг торгів — величина історична: скільки угод пройшло за інтервал. Глибина ринку описує стан прямо зараз: скільки ліквідності виставлено в стакані по обидві сторони від середини і на якому віддаленні від неї.
Зростання обсягу не гарантує виконання за очікуваною ціною. Інструмент може торгуватися жваво, але ліквідність тримається вузьким шаром біля середини — заявка середнього розміру з'їдає цей шар і зсуває котирування на кілька відсотків.
Вирішує зв'язка спреду й щільності заявок: вузький спред при щільному стакані ціна переживе, широкий при тому ж обсязі — виконання виявиться помітно дорожчим за очікуване.
| Метрика | Що вимірює | Що говорить про угоду |
|---|---|---|
| Обсяг торгів | минулі угоди за інтервал | активність та інтерес — але заднім числом |
| Глибина ринку | ліквідність у стакані на віддаленні від середини | скільки можна провести без зсуву ціни |
| Спред і щільність заявок | розрив найкращих цін і концентрація заявок за рівнями | ціну входу й стійкість до великої заявки |
Ліквідність і волатильність пов'язані зворотною залежністю: на тонкій глибині невеликий обсяг рухає ціну сильніше, ніж великий на щільному стакані.
Для скринера це означає, що ранжувати інструменти за одним обсягом безглуздо.
Рахуємо глибину на кількох віддаленнях від середини, спред і розподіл щільності за рівнями, а сигнал даємо, коли глибина тане відносно власного профілю інструмента — до того, як угода піде за несподіваною ціною.
Технічні сумніви: затримки, джерела, стійкість
Затримка даних — не одна цифра, а сума: публікація угоди на майданчику, доставка потоком котирувань, перерахунок стакана, агрегація за біржами.
Ми не ховаємо її усередненням: у кожного сигналу є мітка часу й обсяг глибини, за якою він порахований, тому видно, де затримка зросла і що стало причиною — рух ринку чи зависання джерела.
Джерела котирувань підключаємо кількома незалежними каналами: основний потік, резервний і звірка з агрегатором на кшталт CoinGecko.
Сигнал вважається підтвердженим лише при збігу за двома джерелами й відсутності викидів за спредом, тому верифікація відсікає хибні спрацювання на тонкому стакані.
Що станеться, якщо одне джерело відвалиться?
Потік позначається як неактивний, розрахунок продовжується на решті, а в інтерфейсі з'являється попередження про неповну картину. Сигнали в цей момент не придушуються, але отримують позначку про неповну звірку.
Як система поводиться при обриві зв'язку?
З'єднання перепідключається автоматично, пропущений інтервал довантажується з історії, а до відновлення дані позначаються застарілими. Порожній екран краще, ніж оповіщення, побудоване на застарілій глибині.
Чи можна довіряти сигналам на низьколіквідних парах?
Ні, якщо стакан тонший за заданий поріг — такі пари виключаються з розрахунку або переходять до списку спостереження. Поріг налаштовується під вашу стратегію, а не заданий жорстко.
Обговоримо задачу: що надіслати для оцінки та плану
Щоб повернутися не із загальними міркуваннями, а з оцінкою та планом робіт, нам потрібен мінімальний набір вхідних даних. Чим точніше ви опишете вимоги до системи, тим менше припущень закладемо в схему рішення і тим реалістичнішими вийдуть терміни впровадження.
- Біржі та ринки, які потрібно покрити: спотові, строкові, окремі пари.
- Метрики скринера глибини ринку: глибина стакана на заданих віддаленнях від ціни, спред, стійкість котирування при великому виконанні.
- Умови спрацювання алертів — абсолютні пороги, відхилення від середнього за вікном, різкий зсув за хвилини.
- Канали доставки сигналів: месенджер, пошта, виклик у вашу систему, панель у браузері.
- Режим роботи — безперервний потік котирувань або розрахунок за розкладом; за який період зберігаємо історію.
- Поведінка при розриві зв'язку з біржею і чи потрібно дублювати джерело даними з інших майданчиків.
- Обмеження: де розміщувати систему, уподобання щодо інфраструктури, хто з боку замовника приймає результат.
- Бажані терміни впровадження та дата, до якої потрібен робочий контур.
Опишіть задачу у вільній формі — цього достатньо для старту. Обговоримо її предметно й повернемося з оцінкою та планом робіт: схемою збору даних, складом метрик і алертів, етапами та термінами впровадження.
