Розробка алгоритму scalping
Scalping — торговельна стратегія з дуже високою частотою угод та мінімальними цільовими прибутками на кожній позиції (0.1–0.5%). Алгоритмічний скальпер робить десятки або сотні угод на день, заробляючи на малих рухах ціни при високому обсягу.
Вимоги до scalping-системи
Latency: затримка між отриманням сигналу та виконанням ордера повинна бути мінімальною. VPS у тому ж data center, що й біржа. Для Binance — AWS Tokyo (ap-northeast-1), для Bybit — аналогічно.
Fees: при цілі 0.1–0.2% taker fee 0.04–0.07% з'їдає значну частину. Потрібно або використовувати limit orders (maker fee 0–0.02%), або мати достатньо високий win rate та R:R.
Slippage: мінімальний на інструментах з глибоким стаканом. BTC/USDT та ETH/USDT на крупних біржах — мінімальний slippage.
Scalping стратегії
Order book imbalance scalping: при дисбалансі bid/ask > 3:1 або 1:3 очікується короткостроковий рух у відповідному напрямку. Швидкий вхід limit order, ціль 0.1–0.15%, стоп 0.1–0.15%.
Tape reading (tick data): аналіз потоку угод (aggTrades). Серія великих угод в одному напрямку = aggressors тиснуть на ціну.
Spread scalping з rebate: виставляємо limit orders на bid та ask, заробляємо спред + maker rebate. По суті маркет-мейкинг на мікро-рівні.
Microstructure momentum: перші 5–10 свічок після сильного руху часто продовжують напрямок. Вхід у напрямку імпульсу, швидкий вихід.
Управління позицією
Hard stop-loss: фіксований стоп 0.15–0.2% (залежить від інструмента). Не утримуємо збиткову позицію надіючись на розворот — це вбиває scalping.
Time-based exit: якщо через N секунд/хвилин позиція не показала прибуток — закриваємо. Час = гроші у scalping.
Maximum daily loss: при досягненні максимальної дневної втрати (наприклад, 2% капіталу) — алгоритм зупиняється автоматично.
Maximum daily trades: обмеження кількості угод запобігає overtrading у поганих умовах ринку.
Backtesting scalping
Звичайний OHLCV backtesting недостатній для scalping — потрібні tick-дані або 1-секундні бари. Облік slippage, spread та комісій критично важливий.
Реалістичний backtesting: використовуємо aggTrades дані (Binance надає історичні) з симуляцією order book execution. Припускаємо partial fill при великих limit-ордерах.
Метрики: profit factor (gross profit / gross loss) > 1.5, середній прибуток / середня втрата > 1.2, max drawdown < 5%, достатня кількість угод для статистичної значимості.
Стек: Python (asyncio + websockets) або C++ для мінімальної latency, ClickHouse для зберігання tick-даних, Grafana для realtime P&L моніторингу. Алгоритм працює як daemon з автоматичним reconnect при розриві WebSocket з'єднання.