Бектестування з комісіями та прослизанням: точний облік витрат

Реалістичний бектест криптостратегій неможливий без урахування всіх витрат: комісій, прослизання, 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

Що дає облік витрат? Порівняння

Ми тестуємо стратегії у двох режимах: ідеальному (без витрат) та реалістичному. Різниця наочна:

Згідно з даними Binance, середня комісія taker становить 0.1%. Докладніше про прослизання можна прочитати на Wikipedia.

Як ми це робимо: процес роботи

1. Аналітика — вивчаємо стратегію, її торгову частоту, обсяги, цільову біржу.
2. Проектування — обираємо моделі комісій та прослизання, налаштовуємо параметри.
3. Реалізація — пишемо двигун бектестування з інтеграцією даних (історичні свічки, funding).
4. Тестування — прогоняємо на синтетичних та реальних даних, верифікуємо через Tenderly.
5. Деплой — передаємо документацію, код та дашборд для моніторингу.

Що входить в роботу (deliverables)

• Документація щодо моделі витрат
• Вихідний код двигуна (Python, прив'язаний до вашого стеку)
• Інтеграція з історичними даними бірж
• Аналіз розбіжності ідеального та реалістичного бектесту
• Підтримка 14 днів після здачі

Поширені прорахунки при обліку витрат

• Використання лише фіксованого slippage без прив'язки до обсягу
• Ігнорування funding rate для довгострокових ф'ючерсних стратегій
• Неврахування VIP-знижок при обсягах >$1M
• Використання bid-ask спреду як константи без залежності від волатильності

Терміни та вартість

Термін розробки: від 5 до 15 робочих днів залежно від складності стратегії та кількості бірж. Вартість розраховується індивідуально — пишіть, оцінимо ваш проект протягом дня. Досвід нашої команди в бектестуванні налічує 5+ років, ми реалізували понад 30 проектів з урахуванням витрат. Типова економія для клієнтів становить до $5000 на рік за рахунок виявлення неочевидних витрат.

Гарантуємо: реалістичність моделі в межах 5% від реальних торгових результатів. Зв'яжіться з нами, щоб отримати консультацію та замовити розробку. Отримайте систему, яка не приховує витрати, а показує реальну картину.