How to join historical funding rates and open interest for backtesting

How do I merge funding rates and open interest without look-ahead bias?

Choose the decision clock first. For every exchange and contract, select the latest completed OI observation whose required availability time is no later than the decision. Apply an explicit age limit, retain failures with reasons, and then attach the correct funding record. A backward as-of join solves chronological matching; it does not, by itself, prove that a value had been published or received.

The hypothesis tested here is narrower than profitability: does exact timestamp equality unnecessarily discard usable retrospective pairs, and does that conclusion survive a publication-delay assumption? We freeze a full calendar month and report every retained contract rather than selecting attractive trades. Predictive performance, funding arbitrage and executable P&L are outside this experiment.

Verify: Download settlement join diagnostics · Backward as-of merge semantics

Which contracts, dates and historical data did we actually test?

The primary window is August 1–31, 2026 UTC: start inclusive, September 1 exclusive. It includes all 24 Binance USD-M perpetual contracts in the frozen funding/OI archive cohort, not every contract Binance listed at that time. A preceding-day OI buffer supports backward joins near the first settlement. File paths and SHA-256 checksums were frozen before aggregation.

The contracts are AAVE, ADA, ARB, ATOM, AVAX, BCH, BNB, BTC, DOGE, DOT, ETC, ETH, FIL, INJ, LINK, LTC, NEAR, OP, SOL, SUI, TRX, UNI, XLM and XRP, all USDT perpetuals. Each has 93 settled funding records and 8,928 five-minute OI slots. That is 2,232 settlements and 214,272 OI slots overall, with zero missing grid slots, off-grid times or duplicate OI rows in this cohort.

Identical per-contract results are summarized once below; the complete 24-row contract file remains downloadable. This avoids presenting repeated values as additional findings. A current archive cohort can exclude older delisted contracts, so this month cannot establish survivorship-free coverage of the entire exchange.

Verify: Full contract-by-contract audit · Source files, cohort and aggregate evidence

Which funding-rate and OI units should a backtest preserve?

Keep native and normalized fields together. A funding fraction of 0.0001 is 0.01%, not 0.0001%; a settled rate applies to a particular settlement, not continuously to any arbitrary holding period. Do not assume that every symbol always settles every eight hours. Contract schedules can change, and an interval-aware join must use the source's actual settlement records.

OI quantity and OI notional answer different questions. For a linear BTC contract, a BTC quantity increase describes additional outstanding exposure; USDT notional can also increase simply because BTC's price rose. Positive funding does not identify a buyer, and increasing OI does not reveal whether longs or shorts will win. Both sides exist for every open contract.

Verify: Binance public historical formats · Funding settlement history fields

Why did exact funding/OI joins lose 46.2% of settlements?

Of 2,232 settlements, 1,032 did not equal the five-minute OI timestamp exactly. Their latest eligible OI point was only 1–26 milliseconds earlier. All 24 contracts share the same 50/93 exact-match pattern, suggesting a common timestamp alignment issue in this selected source window, not evidence that 24 separate markets were missing data.

A retrospective backward join recovers those pairs without selecting a future OI row. The gain from 53.8% to 100% is a join-coverage result, not an improvement in strategy returns. Rounding all timestamps down could hide the same problem and accidentally merge other records; preserving native precision and publishing the selected row age is more auditable.

The original three-row BTC example remains useful for arithmetic: OI at 15:55 and 16:00 on August 31 rose from 107,211.911 to 107,256.046 BTC, or 0.04117%. It is not a representative trading outcome. The expanded cohort tests alignment separately from that selected numerical illustration.

Verify: Original three-row arithmetic example · Expanded settlement evidence

What changes if OI becomes available 60 or 300 seconds later?

An assumed 60- or 300-second OI publication delay changes which observation is eligible before a funding settlement. In this frozen August 2026 Binance audit, either stress case retains 1,200 of 2,232 settlements at a literal 300-second maximum age; these are hypothetical availability assumptions, not measured historical exchange latency. The join selects the latest OI no later than settlement time minus the assumed delay.

In both delay scenarios, the selected row ages are 300.000–300.026 seconds. A literal ≤300-second tolerance therefore admits 1,200 pairs, while a ≤900-second tolerance admits all 2,232. The identical 60/300 results follow from five-minute sampling; they do not show that publication latency is irrelevant.

Do not choose 900 seconds merely because it maximizes retention. Decide before seeing strategy returns how old an input your task can tolerate, record precision effects, and test sensitivity. A longer permitted age does not establish source-public or local availability, and a delayed final funding result still cannot be an earlier predictor.

Verify: All three delay scenarios by settlement

How do I implement a reproducible funding and OI join?

Partition by venue and exact contract. Preserve numeric timestamp precision, sort ascending on the merge clock, and resolve duplicates according to an explicit version policy. In pandas, use merge_asof with direction='backward', a declared tolerance and contract grouping; verify sorting on the actual time key, not merely a symbol-first sort. Avoid nearest or forward matching for historical input features.

Availability filtering must happen before choosing the latest eligible version. Filtering only after a match can wrongly discard an observation when an older eligible version exists. If you have no authentic publication or receipt clock, label the result retrospective and run explicit delay assumptions rather than manufacturing a timestamp.

Acceptance check: the frozen zero-delay contract cohort should produce 2,232 retained joins, 1,200 exact matches and no negative selected age. A different count means the cohort, precision, ordering or maximum-age policy differs. Stop the feature pipeline, inspect a failing settlement and its eligible OI candidates, and reconcile the rule before adding returns; do not tune the tolerance to obtain a preferred strategy result.

Verify: Public Python diagnostic reproducer · Audit field dictionary

Can I use hourly OI, forward-fill gaps or download more than 30 days?

Hourly OI is the last eligible exposure observation before the hourly decision, not the sum of twelve five-minute OI values; any fill must retain its age and missingness flag. Longer history is a separate coverage question: Binance's recent OI statistics endpoint and downloadable historical archives have different scopes. Check the exact contract-by-date file inventory instead of promising years from the recent endpoint alone.

For five-minute-to-hourly features, require a completed observation under the declared availability clock, select backward, and reject it once its age exceeds the pre-set limit. OI is a stock of open exposure. Funding cash flows, by contrast, aggregate actual held settlements. Preserve bar-open/bar-close conventions so an hourly price bar does not silently select a later OI row.

Forward-filling a missing OI point can be acceptable for a declared slow context feature within a pre-set age limit. It is not evidence of unchanged true exposure. Do not interpolate missing settled funding costs as zero; carry a missing-cost flag or exclude affected P&L observations under a documented rule.

Verify: Binance recent OI statistics scope · Historical archive coverage

How should funding costs and OI signals enter the same experiment?

Use two separate clocks: information available at entry and realized costs after entry. A final settlement can legitimately become a later expense label even when it could not have been an entry feature. For each held settlement, signed cost depends on direction, applicable notional and the actual rate; add fees, slippage and any separate borrow cost without confusing them with funding.

For illustration only, $10,000 notional at a positive 0.01% settlement costs a long $1 and pays a short $1 before other costs. With $500 margin and 20× leverage, that is still a $10,000 notional calculation, not a $500 one. The example is arithmetic, not a recommended position or measured strategy return.

A credible extreme-funding/rising-OI study then needs prior-data thresholds, same-contract comparison periods, volatility and market-state controls, out-of-sample evaluation, overlapping-window treatment and cost sensitivity. The present alignment audit establishes none of those performance results.

Verify: Historical funding cost calculations · Extreme funding and rising OI research

What can I independently reproduce before buying the full data?

Download funding.json, funding-diagnostics.csv and the other two study JSON/diagnostic pairs together with reproduce.py; run python reproduce.py in their directory, or python3 reproduce.py if Python 3 is installed under that command. The standard-library script independently recomputes joins, ages and eligibility counts from the exported diagnostics. The manifest pins bytes and checksums. Contract summaries and the protocol explain the population and stress assumptions.

These files let you verify published diagnostic arithmetic without purchasing raw derivatives values. They do not independently certify the underlying market prices, funding fractions or OI quantities. For that, obtain the official source files identified in funding.json or an authorized evaluation extract and reconcile native fields, checksums and normalization. No confidence interval is attached to this cohort census; generalization to other months requires additional cohorts.

Verify: Study protocol · Reproduce all three diagnostic studies · Evidence manifest

What historical derivatives delivery should a research team request?

Send the supplier your exchanges, exact contracts including delisted instruments, dates, granularity, required availability clocks and intended use. Request a contract-by-month coverage matrix, native field dictionary, gap reasons, revisions and a small extract containing both successful and failed joins. Agree on file formats, update frequency, permissions and acceptance criteria before payment.

Use this report to define an acceptance test, not to infer that all internal data is for sale. CoinNudge now sells one-time fixed-edition research packs with their own reviewed scope. The study evidence here is unchanged; check the single coverage catalogue and pack sample page before purchasing.

Verify: View exact data coverage and delivery status · Inspect a product sample · Read API authentication and request examples · Compare fixed data plans

Frequently asked questions

Sources and verification

• Frozen 24-contract funding/OI auditCohort, file checksums and complete-month diagnostic results.
• Predefined protocol and exclusionsDecision clocks, stress assumptions and public-data limits.
• Binance public historical dataOfficial archive formats and source files.
• pandas merge_asofBackward join, sorting and tolerance definitions.

Specify the clock, contract and gaps your backtest can tolerate.

Use the public diagnostics to prepare an acceptance test, then confirm the exact historical delivery and permitted use.