Funding in backtests: reconcile payments on perpetual futures

A position closes at the price you expected, yet the test result is still wrong. When a strategy trades perpetual futures, check funding in backtests: when settlement occurred, how much of the position was eligible and which side paid.
You do not need hundreds of trades to begin. Take one position held across a funding settlement and reconstruct its events. An error is easier to find there than in an aggregate equity curve.
Funding is based on the position, not the margin deposit
The funding rate determines a periodic payment between holders of long and short positions. With a positive rate, longs generally pay; with a negative rate, shorts pay. This is a separate cash flow. An order execution fee does not replace it.
For a linear contract, the payment amount is generally calculated from the position value at settlement and the rate for that period. But the valuation price, payment currency and formula must come from the specific contract's rules. Do not transfer the formula for a linear USDT contract to an inverse contract without checking.
Do not multiply an already calculated position value by leverage again. Leverage affects the relationship between exposure and collateral. Applying the rate to margin and counting leverage twice produce different, but equally incorrect, payments.
Do not assign one funding interval to every instrument either. Schedules and rules can differ by exchange, contract and historical period. For example, OKX's funding rules describe several intervals and allow them to change.
How to reconcile funding in backtests with position events
You need settled funding-rate history and events that change the position. Convert timestamps to one zone, such as UTC, while retaining the originals. A forecast of the next rate is not a substitute for the rate actually settled. If the strategy itself uses funding as a signal, it may only see information available at decision time: using the future final rate introduces look-ahead bias.
| Check | Source | Error it can reveal |
|---|---|---|
| Exchange and exact contract | Contract specification and historical-data source | The rate belongs to a different market |
| Time and settled rate | Funding settlement history | A forecast or wrong timestamp was used |
| Position direction and size | Fills, including partial fills | Payment was calculated before a size reduction |
| Valuation price and currency | Contract rules | Position value, margin or units were confused |
| Payment sign and amount | Calculation record; for live reconciliation, the exchange ledger | A charge became income or was counted twice |
Consider an illustrative example with no trading results: a long opens before settlement, part closes before it and the remainder closes afterwards. If the venue bases funding on the position at settlement, the payment applies to the remaining exposure. The original full size is already wrong; the zero position after the final close is wrong too.
Examine entries or exits precisely on the settlement boundary separately. Matching seconds in a report do not establish event order. You need the venue's rules and sufficiently precise source data. If either is missing, record the uncertainty rather than choosing the ordering that favours the strategy.
A missing rate must not silently become zero
Candles may exist for the month you need while funding history does not. Zero means a known zero payment only when the source confirms it. A missing record means the payment is unknown.
There are several practical options: obtain the missing history, shorten the tested period or calculate a separate scenario with an explicit assumption. The last option is useful for sensitivity analysis, but it does not reconstruct the historical result. The report should distinguish observed rates from substituted ones.
This problem also occurs in established backtesting tools. Freqtrade's documentation warns that substituting an incorrect rate where history is unavailable makes that period's result inaccurate. This illustrates a methodological limitation, not how funding is implemented in another tester.
Check missing rates separately from missing candles in a backtest. Restoring one series does not repair the other.
What a completed reconciliation looks like
First freeze the trades and compare their cash result with and without funding. With unchanged trades, the difference should be explained by the sum of those payments, without counting them again in commissions. This isolates funding's effect, but it is not yet a substitute for a complete rerun.
If the strategy sizes positions from available capital or makes decisions using current profit and loss, funding can change subsequent trades. You then need a rerun with funding inside the model. Simply subtracting an aggregate amount from final profit does not reproduce that effect; margin and liquidation effects also need separate checks.
XTester's general backtesting guide already includes funding among the costs to consider. That does not confirm every rate source, automatic import or settlement model in your version. Before a practical test, verify support for the specific exchange and contract, historical coverage and how payments are recorded. Where something is unknown, retain the reconciliation as a separate calculation and do not call it an XTester engine result.
A completed check leaves a short, understandable record: rate source, coverage period, position events, settlement rules and an explained difference. If even one payment cannot be reconstructed, the result remains conditional, however convincing the final number looks.
This article is informational, not investment advice. Futures trading can result in loss of capital. Funding reconciliation checks only part of a model; it does not establish a strategy's profitability or safety, or guarantee live execution.
This material is for information only and is not investment advice. Backtest results do not guarantee future returns.


