# SMARTBETA-1 DEVIATION-001: distributions missing from Yahoo's adjusted close (QUAL, VLUE, SIZE), and how the issuer check was done **Written:** 2026-09-26 (UTC), about 17:25Z. Sealed with RFC 3161 timestamps (`deviation-001-seal/`) **before the sensitivity analysis below was run**. No corrected statistic has been computed. **Order of events (disclosed in full).** The confirmatory run (`run.py`) finished at about 17:21Z and its results had been read. PREREG §5 puts the issuer cross-check (iii) **after** the run, so this problem could only be found after the affected results were seen. That is why this note cannot precede the confirmatory results; it does precede the corrected (sensitivity) numbers. ## A. What the issuer cross-check found The issuer's own distribution tables (iShares product pages, fetched 2026-09-26 about 17:22Z) list these distributions, which **Yahoo's data omit**: no dividend event, and no change in the adjusted-close-to-close ratio across the ex-date. | ETF | Ex-date | Distribution per share (issuer) | |---|---|---| | QUAL | 2014-12-24 | $0.230861 | | QUAL | 2016-03-23 | $0.317741 | | VLUE | 2016-03-23 | $0.433562 | | SIZE | 2016-03-23 | $0.309404 | Every other iShares distribution for MTUM, QUAL, VLUE, SIZE and USMV matches Yahoo's dividend events (dates within 3 days; amounts within $0.005). Effect: on each listed ex-date the ETF's daily total return in the audited series is understated by roughly the distribution divided by the previous close (about 0.4% to 0.7%). Spread over 13 years, that is a few hundredths of a point a year, against the ETF. The calendar-year comparison (published figure: the largest absolute difference only) is in `results.json` under `issuer_cross_check`. The two largest year-level differences, VLUE and SIZE in 2016 (more than 1 point), come from the March 2016 omission. SIZE also shows an offsetting 2015/2016 pair (+1.2/−1.7 points) around a stale year-end market close (no trade on 2015-12-30 or 12-31), which is a market-price vs NAV timing effect, not a data error. ## B. Deviation in how check (iii) was done PREREG §5 says the check compares against "the issuer's published calendar-year total return (NAV or market)". The issuers' calendar-year tables are rendered in the browser and were not machine-readable to our fetcher. We instead used each issuer's **published monthly growth-of-$10,000 series for the fund itself** (iShares: embedded in the product page, since inception; Invesco: its public performance API, a 10-year window, so SPLV is compared over 2017–2025 only) and derived December-to-December returns from it. No benchmark or index series was read. The issuer files are kept in `raw/issuer/` (git-ignored, never published) with these SHA-256: | File | SHA-256 | |---|---| | `mtum_ishares.html` | `4cf2d10b9fc074828f9ce1c6415d4f38aba810dc1c2cb0eb1c40b226afaf2b2b` | | `qual_ishares.html` | `86d8338ab9c1489be431b548eb84df5187b7f2efdf4c7dcd2352f58c2cc5d41d` | | `vlue_ishares.html` | `5fa104606ecef4a7a3137e8b1e1388bc6ab2edb0078911fd231b785a87d7b46d` | | `size_ishares.html` | `267f3a99017d4cf377b76f684c571e491e33a1946aa4f4e7d1d28a82abfbb501` | | `usmv_ishares.html` | `362221afe2f0907648fbcd836f13b6eb6e95a2c471e436d89ce78b5b04fa67da` | | `splv_invesco_rolling.json` | `dd00ff36c5f6eb171c6bedf7c73776162b6a3fff29146be2842919b65b11e772` | Script: `issuer_check.py` (SHA-256 `cb6f0ee89d8509e3072482c8edd6bdb7ca31c2e1a8be1114f9dc51dbe2d26a30`). ## C. What we do about it (fixed now, before any corrected number exists) PREREG §5 says: "If a flagged problem cannot be resolved from the issuer's own data, the affected ETF is still reported, with the problem stated; nothing is dropped silently." Here the problem **can** be resolved from the issuer's own data, but the preregistration does not say what to do then, and it forbids re-running tests with other settings (§0 and "Publish all"). We therefore fix this rule: 1. **The confirmatory results stay exactly as run** on the sealed data source (Yahoo adjusted close, PREREG §5). `results.json`, the six reports and the verdicts are not replaced, and nothing is re-run in their place. 2. **A sensitivity analysis is run once** (`sensitivity_dev001.py`, SHA-256 `69c0989af718542823e1a01943083483b5a5cb0d6ff6580612c4cbb81f4e7d79`). For QUAL, VLUE and SIZE it raises the ETF's daily return on each missing ex-date by (issuer distribution ÷ previous unadjusted close). Everything else is identical: engine, rubric v1.2, settings, seed, cost, dates, declarations. Holm is recomputed across the six, with the three corrected p-values and the three unaffected ones as run. It reports each fund's p, Holm p, verdict, grade, average excess return and compound excess, next to the confirmatory values. Output: `sensitivity_dev001.json`. 3. **Reporting.** SUMMARY.md states this deviation, the four missing distributions and the sensitivity outcome, whatever it is. If any verdict or grade differs between the two, both are shown side by side in the primary table and the difference is stated in the headline. The confirmatory (as-run) result is listed first because it is the one the sealed protocol defines, and it is labelled as understating the three funds' returns by the amounts above. 4. **MTUM, USMV and SPLV** are unaffected by this issue (no missing distribution found; SPLV's issuer check covers 2017–2025 and shows a largest difference of 0.26 points). SPY, the benchmark, is not in scope of check (iii) and was not cross-checked.