As-Reported против Restated: почему выбор версии данных убивает бэктестинг

У любой финансовой отчётности есть как минимум две версии: цифра, которую компания впервые показала рынку, и та, что сегодня лежит в базе после исправлений, реклассификаций и корректировок. Если вы строите фундаментальный бэктест, перепутать их — один из самых тихих способов завысить историческую доходность стратегии. Тише, чем ошибка выжившего, но столь же реальный.

В этой статье разберём, что такое «as-reported» и «restated», почему бэктест, использующий не ту версию, учится на информации, которой ещё не существовало, и как точечный набор данных вроде Tradevo Data позволяет выбирать осознанно, а не случайно.

As-reported: то, что рынок увидел на самом деле

As-reported (ещё называют original или first-filed) — это значение, раскрытое в отчёте, который стал публичным. Для нас это 10-K (или 10-K/A). У него есть дата: момент, когда эта цифра попала в публичный доступ через SEC EDGAR. До этой даты ни один участник рынка не мог её знать. В этом вся суть точечных данных: каждый факт имеет временную метку, когда он стал известен, а не только то, каким факт стал в итоге.

Restated: каким число стало сегодня

Restated (или latest) — это текущая, исправленная цифра после любых последующих изменений в 10-K/A или сравнительных корректировок в более поздних отчётах. Компании пересматривают данные по разным причинам: бухгалтерские ошибки, изменение стандартов, реклассификации, перераспределения из-за слияний. Пересмотренное число часто точнее как историческая запись того, что произошло на самом деле. Однако это не то, что трейдер или аналитик мог знать на дату выхода первоначального отчёта.

Почему это ведёт к предвзятости забегания вперёд в бэктесте

Бэктест, который соединяет сегодняшние пересмотренные фундаментальные показатели с историческими ценами, молчаливо предполагает, что рынок имел доступ к информации, которой у него ещё не было. Если компания позже скорректирует выручку вверх, а ваш бэктест использует пересмотренную цифру на дату первоначального отчёта, любая стратегия, основанная на этой цифре, будет выглядеть умнее в ретроспективе, чем могла быть в реальном времени. Эффект обычно невелик на одну компанию, но корректировки — не редкость: в нашем наборе отмечено 18 772 пересмотра на 314 436 строк, что говорит о системном характере явления, а не о пограничном случае, которым можно пренебречь.

Решение механическое, не статистическое: для любой даты, по которой вы тестируете, используйте только те значения, у которых дата first_filed не позднее этой даты, и используйте значение, как оно было впервые заявлено, а не то, каким оно стало позже.

Наглядный пример

Допустим, компания подаёт первоначальный 10-K с выручкой за финансовый год N. Несколько кварталов спустя она подаёт 10-K/A, который пересматривает выручку за тот же год — изменение превышает порог в 0,5% по тому же показателю, который мы используем для фиксации значимой корректировки (а не просто округления или изменения представления).

В схеме Tradevo Data один факт о выручке за год N порождает:

• first_filed: дата, когда первоначальный 10-K стал публичным;
• original_value: выручка, как была впервые отражена — это то, что вы используете для безопасного бэктеста на исторических датах;
• latest_value: выручка по текущему состоянию после 10-K/A;
• restated: true, так как пересмотр превысил порог в 0,5%;
• qa_status: внутренняя проверка, прошла ли строка чистый парсинг и сверку.

Если логика вашего бэктеста звучит как «на дату X — что мы знали о выручке компании», вы фильтруете строки с first_filed <= X и читаете original_value. Если логика — «что на самом деле произошло с выручкой компании, точка», вы читаете latest_value. Одна строка, два разных вопроса, два разных ответа — и выбор не того для не того вопроса как раз и есть та ошибка, которую точечные данные призваны предотвратить.

As-reported vs Restated: краткое сравнение

Когда пересмотренные данные действительно лучше

Это не призыв всегда предпочитать as-reported. Если вы делаете ретроспективный фундаментальный анализ — «как на самом деле менялась маржинальность компании за десять лет», — пересмотренная цифра обычно более честный ответ, так как она отражает исправленную бухгалтерию, а не ошибку, которую потом исправили. Пересмотренные данные также правильный выбор для обучения долгосрочных моделей оценки, где вы не имитируете точечные решения, или для аудита того, насколько сильно изменились цифры компании с момента первого раскрытия. Ошибка не в использовании restated, а в использовании их внутри бэктеста, который претендует на историчность.

Строить самому или использовать чужой набор

Собрать конвейер точечных данных из сырых отчётов EDGAR вполне реально, и для некоторых команд это правильное решение: полный контроль над логикой парсинга, сопоставлением тегов и порогами обнаружения пересмотров, а также независимость от чужого графика обновления. Однако есть и обратная сторона: сверка XBRL-тегов в исправлениях, отслеживание каждого 10-K/A и проверка дат первой подачи по реальным меткам EDGAR — это неблагодарная текущая работа, в которой легко завести молчаливые ошибки (например, случайно подхватить пересмотренное значение), которые проявятся только тогда, когда результаты бэктеста станут подозрительно хорошими.

Если вам нужны квартальные данные, неамериканские рынки или Parquet «из коробки», стоит посмотреть на других провайдеров — Sharadar, Tiingo, QuantConnect предлагают добротные продукты по фундаментальным показателям. Tradevo Data сейчас — это только годовые данные (10-K/10-K/A), только США и в первую очередь CSV (Parquet в планах). Так что если ваш случай требует большего, один из этих сервисов, возможно, подойдёт лучше.

Где здесь место Tradevo Data

Что мы предлагаем: 5 216 американских компаний, 314 436 точечных строк по 7 основным концепциям, до 12 лет истории, причём каждое значение несёт first_filed, original_value, latest_value и флаг restated, чтобы вам никогда не приходилось гадать, на что вы смотрите. В нашей бесплатной выборке из 40 компаний измеренное забегание между моментом, когда значение стало публичным, и моментом, когда его можно было использовать, составило в среднем 43,4 дня (максимум 61 день) по строкам с надёжными отчётами — эта цифра относится только к этой выборке, а не ко всему набору, потому что мы пока не измеряли его по всей вселенной.

Полная методология и 3 280 примеров строк доступны бесплатно, без регистрации. Если это подходит под ваш рабочий процесс, полный набор данных и API стоят $49/мес. — включая массовую загрузку и снимки всей вселенной, отмена в любой момент.

Это не инвестиционная рекомендация; проверяйте цены конкурентов самостоятельно на их сайтах.