Реалістичний бектест криптостратегій неможливий без урахування всіх витрат: комісій, прослизання, funding rate. Ігнорування цих факторів призводить до завищених очікувань — стратегія, що показує 30% річних на історії, в реальності легко йде в мінус. Наприклад, для стратегії, яка здійснює 100 угод на місяць, комісія taker у 0.1% з'їдає 10% капіталу на рік. Додайте маркет-імпакт та фандинг — і ви побачите справжню дохідність.
Ми розробляємо системи, які чесно враховують усі торгові витрати, включаючи комісії біржі, прослизання та funding rate. Такий підхід дозволяє побачити справжню дохідність і уникнути ілюзій. Одного разу клієнт поділився стратегією, що показувала 40% річних на історії без урахування витрат. Після додавання реальних комісій та прослизання дохідність впала до 12%, а з funding rate — до 5%. Це типовий сценарій, коли ілюзії змінюються розчаруванням. Ми знаємо, як цього уникнути. Замовте розробку моделі витрат — і отримайте правдивий аналіз.
Чому без комісій бектест марний?
Навіть tiny-витрати накопичуються: 0.1% taker fee на кожну угоду при 100 угодах на місяць з'їдають 10% капіталу на рік. Додайте прослизання — і стратегія, яка здавалася прибутковою, йде в мінус. Реалістичний бектест зобов'язаний враховувати:
- Комісії біржі: maker/taker, VIP-скидки, rebate
- Прослизання: market impact, bid-ask spread, gap slippage
- Funding rate для ф'ючерсів: платежі кожні 8 годин
- Непрямі витрати: latency, мережеві збори
Одного разу клієнт приніс стратегію з 25% річних на історичних даних без урахування комісій. Після включення реальної тарифної сітки та прослизання результат упав до 9%, а з урахуванням funding rate — до 4%. Тільки тоді він зрозумів, що торгівля на ф'ючерсах з низьким обсягом з'їдає весь прибуток. Наш гібридний підхід до моделювання slippage допомагає уникнути таких сюрпризів: він мінімум у 2 рази точніший за фіксоване значення на реальних даних.
Як правильно враховувати прослизання?
Єдиної моделі немає. Для стратегій з малим обсягом достатньо фіксованого відсотка. Для великих ордерів потрібна модель market impact — slippage зростає з розміром позиції відносно обсягу свічки. Ми використовуємо гібридний підхід: комбінацію фіксованого спреду та volume impact. Ось приклад реалізації моделі фіксованого прослизання:
class FixedSlippage(SlippageModel): def __init__(self, slippage_pct: float = 0.0005): self.slippage_pct = slippage_pct def get_fill_price(self, order_price: float, bar, side: str) -> float: if side == 'BUY': return order_price * (1 + self.slippage_pct) else: return order_price * (1 - self.slippage_pct) А для об'ємозалежного прослизання:
class VolumeImpactSlippage(SlippageModel): def __init__(self, impact_factor: float = 0.1): self.impact_factor = impact_factor def get_fill_price(self, order_price: float, bar, side: str, order_size_usd: float = 0) -> float: bar_volume_usd = bar.volume * bar.close market_impact = self.impact_factor * order_size_usd / bar_volume_usd if bar_volume_usd > 0 else 0 if side == 'BUY': return order_price * (1 + market_impact) else: return order_price * (1 - market_impact) Структура комісій: реалістичні тарифи
Багато стратегій пишуться під конкретну біржу, тому важливо закладати її тарифну сітку. Ось приклад для Binance Spot з VIP-рівнями:
@dataclass class FeeSchedule: maker_fee: float taker_fee: float vip_tiers: list[tuple[float, float, float]] = None def get_fee(self, order_type: OrderType, volume_30d: float = 0) -> float: if self.vip_tiers and volume_30d > 0: for min_vol, maker, taker in sorted(self.vip_tiers, reverse=True): if volume_30d >= min_vol: return maker if order_type != OrderType.MARKET else taker if order_type == OrderType.MARKET: return self.taker_fee else: return self.maker_fee BINANCE_SPOT = FeeSchedule(maker_fee=0.001, taker_fee=0.001, vip_tiers=[(1_000_000, 0.0009, 0.001), (5_000_000, 0.0008, 0.0009), (20_000_000, 0.0007, 0.0008)]) Funding rate для ф'ючерсів
Для стратегій на перпетуалах funding — значна стаття витрат. Ми враховуємо історичні ставки та розраховуємо сумарний платіж за період:
class FundingRateModel: def __init__(self, funding_interval_hours: int = 8): self.interval = funding_interval_hours self.funding_history: dict[str, pd.Series] = {} def calculate_funding_cost(self, symbol, position_value, from_ts, to_ts, position_side) -> float: if symbol not in self.funding_history: return 0.0 rates = self.funding_history[symbol] mask = (rates.index >= from_ts) & (rates.index < to_ts) period_rates = rates[mask] total_funding = 0.0 for rate in period_rates: if position_side == 'LONG': funding_payment = -position_value * rate else: funding_payment = position_value * rate total_funding += funding_payment return total_funding Що дає облік витрат? Порівняння
Ми тестуємо стратегії у двох режимах: ідеальному (без витрат) та реалістичному. Різниця наочна:
| Показник | Ідеальний | З комісіями |
|---|---|---|
| Аннуалізована дохідність | +32% | +18% |
| Коефіцієнт Шарпа | 1.4 | 0.9 |
| Частка комісій від gross P&L | 0% | 1.2% |
| Тип витрат | Вплив на річну дохідність |
|---|---|
| Тільки taker fee (0.1%) | -12% |
| Taker fee + 0.05% slippage | -18% |
| Taker + slippage + funding (1% річних) | -25% |
Згідно з даними Binance, середня комісія taker становить 0.1%. Докладніше про прослизання можна прочитати на Wikipedia.
Кейс: приховані витрати на реальному прикладі
Ми проаналізували стратегію клієнта, яка показувала 25% річних на ідеальному бектесті. Після включення реальних комісій та прослизання результат упав до 9%, а з funding rate — до 4%. Клієнт був здивований, але саме це допомогло йому переглянути підхід. Один клієнт заощадив понад $12 000 на рік завдяки нашому аналізу.Як ми це робимо: процес роботи
- Аналітика — вивчаємо стратегію, її торгову частоту, обсяги, цільову біржу.
- Проектування — обираємо моделі комісій та прослизання, налаштовуємо параметри.
- Реалізація — пишемо двигун бектестування з інтеграцією даних (історичні свічки, funding).
- Тестування — прогоняємо на синтетичних та реальних даних, верифікуємо через Tenderly.
- Деплой — передаємо документацію, код та дашборд для моніторингу.
Що входить в роботу (deliverables)
- Документація щодо моделі витрат
- Вихідний код двигуна (Python, прив'язаний до вашого стеку)
- Інтеграція з історичними даними бірж
- Аналіз розбіжності ідеального та реалістичного бектесту
- Підтримка 14 днів після здачі
Поширені прорахунки при обліку витрат
- Використання лише фіксованого slippage без прив'язки до обсягу
- Ігнорування funding rate для довгострокових ф'ючерсних стратегій
- Неврахування VIP-знижок при обсягах >$1M
- Використання bid-ask спреду як константи без залежності від волатильності
Терміни та вартість
Термін розробки: від 5 до 15 робочих днів залежно від складності стратегії та кількості бірж. Вартість розраховується індивідуально — пишіть, оцінимо ваш проект протягом дня. Досвід нашої команди в бектестуванні налічує 5+ років, ми реалізували понад 30 проектів з урахуванням витрат. Типова економія для клієнтів становить до $5000 на рік за рахунок виявлення неочевидних витрат.
Гарантуємо: реалістичність моделі в межах 5% від реальних торгових результатів. Зв'яжіться з нами, щоб отримати консультацію та замовити розробку. Отримайте систему, яка не приховує витрати, а показує реальну картину.