Split adjustment data issue

Issues
#1

Hi Brian,

I think there may be an issue with the split-table adjustments in the daily price data. My backtest suddenly showed a large drawdown in the 2015 date range, which appears to be related to split adjustments downloaded within the last couple of days.

The split records I checked from 2015 onward are stored with ratio = 1.000 (no adjustment), including the examples below:

Stock Split date Raw close before → after Ratio in split table Expected ratio
GILD 2013-01-28 79.36 → 39.44 0.500 ✓ 0.5
AAPL 2014-06-09 645.57 → 93.70 0.143 ✓ 1/7
CNC 2015-02-20 120.67 → 59.85 1.000 ✗ 0.5
MPC 2015-06-11 101.79 → 52.03 1.000 ✗ 0.5
NFLX 2015-07-15 702.60 → 98.13 1.000 ✗ 1/7
SKX 2015-10-16 132.67 → 45.15 1.000 ✗ 1/3
GPN 2015-11-03 136.23 → 67.56 1.000 ✗ 0.5
HRL 2016-02-10 82.86 → 41.67 1.000 ✗ 0.5
AAPL / TSLA 2020-08-31 499 → 129 / 2213 → 498 1.000 ✗ 1/4, 1/5
NVDA 2021-07-20 751 → 186 1.000 ✗ 1/4
WMT 2024-02-26 175.56 → 59.60 1.000 ✗ 1/3
NVDA 2024-06-10 1208.88 → 121.79 1.000 ✗ 1/10
ORLY 2025-06-10 1348.10 → 91.71 1.000 ✗ 1/15

Across the full table, the percentage of records stored with a ratio of 1.0 increases sharply starting in 2015. This affects both splits and dividends:

Years Splits stored with ratio 1.0 (no adjustment) Dividends stored with ratio 1.0
2007–2014 4–9% 1–3%
2015–2026 83–95% 85–99%

Could you please check whether a recent data update may have caused this, and advise on how to correct the affected adjustment records?

Thanks,
Kamran

#2

Investigating...

#3

Can you collect an update and check again? If you still see the issue, can you then please drop and re-collect the usstock history database?

By the time of your report, the data on our end looked correct, but I did see some incorrect results in already downloaded databases in various places. This makes me think that there was a temporary issue that self-resolved but that still showed up in certain places depending on how and when you downloaded the data. We will keep looking to see if we can figure out the root cause, although that is made more challenging by the issue having already apparently resolved itself.

Do you know when you most recently updated the history database prior to seeing the issue? Any specifics about how often you update the database and when the problem emerged could be helpful.

The usstock bundle uses a different collection strategy than the history database, and I did not see any evidence that this issue affected the bundle.

#4

Thanks. One clarification: the issue affected the Zipline bundle usstock-1d-bundle, which was last updated on October 15, 2026, at 06:06 UTC.

In its adjustments.sqlite database, the splits table had ratio = 1.0 for 83–95% of splits per year from 2015 onward, compared with 4–9% for 2007–2014. Examples included CNC (2015-02-20), SKX (2015-10-16), AAPL and TSLA (2020-08-31), NVDA (2021-07-20), WMT (2024-02-26), NVDA (2024-06-10), and ORLY (2025-06-10).

The raw daily bars showed the corresponding split-related price drops, but the adjustment ratios did not account for them. As a result, backtests holding positions through those splits recorded artificial losses. The dividends table showed a similar pattern, with ratio = 1.0 for 85–99% of rows from 2015 onward.

We update the bundle nightly at 10:30 PM Pacific time. A backtest run on October 13 handled the NVDA 2021-07-20 split correctly. However, a run on October 14, after the nightly update, failed to adjust for splits in 2015–2016. When we inspected the table, the NVDA 2021 split also had a ratio of 1.0.

Artificial split losses also appeared in an earlier backtest for WMT (2024-02-26), NVDA (2024-06-10), and ORLY (2025-06-10), indicating that some affected records predated this week.

We had already dropped and re-ingested the bundle several times. We repeated the process this morning, and the latest full drop and re-ingest appears to have resolved the issue. The bundle now contains the expected split and dividend adjustment ratios:

Measure Before re-ingestion After re-ingestion
Splits stored with ratio 1.0, 2015–2026 83–95% per year 5–11% per year, except 2020 at 19%
Splits stored with ratio 1.0, 2007–2014 4–9% per year 4–9% per year (unchanged)
Dividends stored with ratio 1.0, 2015–2026 85–99% 0–2%

The percentage of split records with a ratio of 1.0 for 2015–2026 is now much closer to the unaffected 2007–2014 range, although 2020 remains higher at 19%. The remaining records may represent legitimate cases requiring no adjustment, but the aggregate percentages alone do not establish that.

I checked the following individual split records and confirmed that all now contain the expected adjustment ratios. Ratios below are rounded where applicable:

Stock Split date Adjustment ratio now Expected split
CNC 2015-02-20 0.5 2-for-1
MPC 2015-06-11 0.5 2-for-1
NFLX 2015-07-15 0.1429 7-for-1
SKX 2015-10-16 0.3333 3-for-1
GPN 2015-11-03 0.5 2-for-1
HRL 2016-02-10 0.5 2-for-1
AAPL 2020-08-31 0.25 4-for-1
TSLA 2020-08-31 0.2 5-for-1
NVDA 2021-07-20 0.25 4-for-1
WMT 2024-02-26 0.3333 3-for-1
NVDA 2024-06-10 0.1 10-for-1
ORLY 2025-06-10 0.0667 15-for-1

The bundle was affected, and the latest full drop and re-ingest corrected the adjustment records I checked, but it remains a mystery what exactly happened with this data.

#5

The bundle is broken again after the latest nightly update, this time affecting a different range of years. I haven't changed anything.

The bundle files were rewritten on October 16 at 06:01 UTC. Here is the current state of the adjustment tables:

Years Splits stored with ratio 1.0 (no adjustment) Dividends stored with ratio 1.0 Status
2007–2011 5–8% 2–3% OK
2012–2023 87–98% 90–100% Broken
2024–2026 5–6% 0–2% OK

Several split records that were correct after the October 15 re-ingestion now have a ratio of 1.0 again.

We use usstock-1d-bundle with daily data for the full US stock universe, starting on January 3, 2007. There is no usstock history database on this deployment; all backtests read directly from the bundle.

I directly inspected the splits and dividends tables in the bundle's adjustments.sqlite file. The raw daily bars appear correct, but the adjustment ratios are wrong.

Timeline (all timestamps UTC):

Bundle written Operation Splits with ratio 1.0 Dividends with ratio 1.0
2026-10-15 06:06 Incremental update 83–95% per year for 2015–2026, compared with 4–9% for 2007–2014 85–99% per year for 2015–2026
2026-10-15 15:42 Full drop and re-ingestion 5–11% per year, except 2020 at 19%; all split records checked were correct 0–2%
2026-10-16 06:01 Incremental update 87–98% per year for 2012–2023; 2024–2026 returned to normal levels 90–100% per year for 2012–2023

Both problematic updates affected a block of exactly 12 calendar years, with the affected range shifting from 2015–2026 in the first update to 2012–2023 in the latest update.

The affected ranges appear to align with calendar-year boundaries. In the latest bundle, the records I checked were correct through December 28, 2011, but had a ratio of 1.0 from January 3, 2012, through December 2023. The records I checked from 2024 onward were correct.

Examples:

Security Split date Expected adjustment ratio After full re-ingestion (October 15) After incremental update (October 16)
GILD 2013-01-28 0.5 0.5 1.0
AAPL 2014-06-09 0.142857 0.142857 1.0
NFLX 2015-07-15 0.142857 0.142857 1.0
SKX 2015-10-16 0.3333 0.3333 1.0
AAPL 2020-08-31 0.25 0.25 1.0
TSLA 2020-08-31 0.2 0.2 1.0
NVDA 2021-07-20 0.25 0.25 1.0
WMT 2024-02-26 0.3333 0.3333 (was 1.0 after the October 14 update) 0.3333
NVDA 2024-06-10 0.1 0.1 (was 1.0 after the October 14 update) 0.1

Ratios are rounded where applicable.

Impact: When an adjustment ratio is incorrectly stored as 1.0, a backtest holding a stock through a split records the split-related price drop as a loss. For example, a 3-for-1 split produces an artificial loss of approximately 67% on the position, before accounting for the actual market move. Missing dividend adjustments also cause dividends to be omitted from total returns.

One of our backtests recorded artificial split losses totaling approximately 58% of capital across 25 events. Another showed a 41% drawdown that was entirely attributable to these split-adjustment errors.

#6

Investigating...

#7

I apologize for the impact to your strategies.

The bundle is generated several times throughout the night. The current version of the bundle’s adjustment.sqlite was generated and available at 7:21 UTC, about an hour after you downloaded the bundle with problematic adjustments. In the latest 7:21 UTC adjustments.sqlite, I don’t see any of the issues you report. We will investigate the possibility that an earlier run is setting the factors to 1 while the final run is not, since that would seem to match the timing you’re seeing. In the meantime, if you can, it might be prudent to delay your nightly update until around 1 AM Pacific, by which time the final run should have completed.

#8

We have identified the root cause affecting the earlier run and are working on a fix.

#9

We have implemented a fix for this issue. It was caused by a race condition that was introduced by a recent enhancement to a backend server. The nature of race conditions is that they show up sometimes but not always, which is why this happened some days but not others. The race condition did not exist in the later processing run, which is why the problem was already resolved by the morning.

You can leave your nightly update schedule unchanged now that the underlying issue is resolved.

Thank you for detailed report. It helped with diagnosing the issue.

#10

Brian, thank you for investigating this issue.

#11

This topic was automatically closed after 15 days. New replies are no longer allowed.