Введение
В M4.1 мы выбрали hybrid с приоритетом top-down для SwiftRide. Этот урок — детальный workflow потока top-down. Выход — список кандидатов CDE с явной трассой от строки отчёта до физической колонки. Шаблон документации сохраняется как аудит-артефакт: когда Big 4 спрашивает «как мы знаем, что выручка захвачена полностью», ответ — это этот документ, не разговор.
Top-down работает не только для финансовых отчётов. Тот же паттерн применяется к регуляторным сдачам (Pillar 3, IFRS disclosures), GDPR Art. 30 ROPA, регистрациям EU AI Act, DORA Register of Information. Универсальная формула: публикуемый артефакт → трассировка зависимостей → отметка листов как CDE.
Workflow из 5 шагов
Шаг 1 — Определить вселенную отчётности
Перечисляем все отчёты / сдачи / disclosures, в которые SwiftRide публикует данные. На T0 SwiftRide:
| Отчёт | Аудитория | Частота | Владелец |
|---|---|---|---|
| S-1 / 10-K Income Statement | SEC + инвесторы | Квартально / ежегодно | CFO |
| S-1 / 10-K Balance Sheet | SEC + инвесторы | Квартально / ежегодно | CFO |
| IFRS 18 P&L (цель T+12M) | SEC + инвесторы (после IPO) | Квартально | CFO |
| GDPR Art. 30 ROPA | Внутренний + надзор | Постоянно | DPO |
| EU AI Act registration (Annex VIII) | Notifying body + EU AI Office | Один раз, затем обновления | Legal + ML Lead |
| DORA Register of Information | Компетентный орган через банка-партнёра | Ежегодно | CISO + связной банка-партнёра |
| AMLR SAR / STR filings | FIU | По событию | Compliance |
| Отчёты Internal Audit | audit committee | Квартально | Internal Audit |
| Материалы по рискам для совета директоров | Board Risk Committee | Квартально | CRO |
| Pillar 3 disclosures (через банка-партнёра) | Рынок | Квартально | Банк-партнёр + связной SwiftRide |
| IFRS 15 / ASC 606 revenue disclosures | SEC + инвесторы | Квартально | CFO |
Критично: этот список — выход вовлечения стейкхолдеров (M4.4), не предположения. Включает внутренние отчёты (материалы для совета директоров) — потому что материалы совета вызвали аудиторский вопрос про $40M ECL (драматургия M0.4).
Шаг 2 — Определить значимые элементы в каждом отчёте
Для каждого отчёта — какие строки / метрики / поля значимы? Значимый = искажение / пропуск / неточность, которые изменили бы решение пользователя.
Лексика PCAOB: AS 2201 ¶.29 — аудитор идентифицирует значимые счета по характеристикам, включая размер, подверженность искажению, природу, сложность. Тот же подход применяем для выявления — но мы делаем самооценку, не аудит.
Практически: значимые элементы обычно составляют 70-90% отчёта по весу. Обратное Парето — длинный хвост маленьких элементов пропускаем в первичном sweep.
Пример Income Statement SwiftRide T+0M draft:
| Строка | Материальна? | Обоснование |
|---|---|---|
| Net Revenue | да | $2.1B; основная верхняя строка |
| Driver Earnings & Incentives | да | Крупнейшая операционная расходная статья; прецедент SwiftPay 2024 |
| Cost of Revenue (cloud + payments) | да | Концентрация поставщиков; риск DORA |
| Sales & Marketing | да | Видимость распределения капитала |
| Research & Development | да | Капитализация команды AI / ML |
| General & Admin | да | Включая юридические / комплаенс-резервы |
| Income / loss from operations | да | Заголовочная метрика |
| Interest income / expense | да | Выручка от кредитования SwiftCapital + управление денежными средствами |
| Provision for ECL | да | Кредитный портфель SwiftCapital |
| Foreign exchange (gain) / loss | возможно | Материальна в некоторых кварталах |
| Other operating items | нет | Ниже порога материальности |
11 элементов материальны; 1 условно; ниже отсечки не отслеживается в первичном sweep.
Шаг 3 — Декомпозиция элемента → SOX-счёт → системы → пайплайны
Для каждого материального элемента:
3a. Маппить к SOX significant account (если применимо). Significant account — бухгалтерская концепция; данные могут питать несколько счетов.
3b. Идентифицировать все системы, вносящие вклад в этот счёт. Не только основную систему; включая источники сверки, корректировок, ручных override.
3c. На систему — пайплайны, питающие выход (Kafka topics, dbt models, Airflow DAGs).
3d. На пайплайн — исходные таблицы.
3e. На таблицу — колонки, напрямую участвующие в расчёте.
Пример SwiftRide: Net Revenue
- Элемент:
Net Revenue - SOX significant account:
Trip Revenue+Delivery Revenue+SwiftAds Revenue+SwiftCapital Interest Revenue - На счёт, основные системы:
- Trip Revenue: сервис Dispatch (Go) → сервис Billing (Python) → Snowflake
- Delivery Revenue: аналогично через сервис Delivery
- SwiftAds Revenue: сервис SwiftAds Attribution → Snowflake
- SwiftCapital Interest Revenue: сервис SwiftCapital loan → Snowflake
- На систему: пайплайны, таблицы, колонки (см. интерактивную трассу ниже)
Шаг 4 — Обратная трасса lineage через каталог
Тулинг — OpenMetadata + Marquez с lineage на уровне колонок. Процесс:
- Запрос lineage upstream от
fct_revenue_daily(финальный агрегат). Возвращает DAG: агрегат → несколько fact-таблиц → несколько источников. - Обход DAG вниз. Каждая нода — система / пайплайн / таблица. Каждое ребро на уровне колонок — маппинг колонок.
- Отметить листья (исходные колонки) — первичные кандидаты CDE.
- Если есть пробел в lineage (например, у ECL-системы нет инструментации OpenLineage) — это находка: пробел в lineage есть пробел в выявлении — открыть список задач на инструментацию lineage к T+3M.
Принцип: PCAOB AS 2201 ¶.21 говорит, что top-down-подход начинается на уровне финансовой отчётности и работает вниз. Выявление идёт в том же направлении, но добавляем измерение: внутри каждого SOX-счёта декомпозируем до колонки. Это идёт глубже, чем тестирование контролей в аудите — аудит выбирает контроли (entity-level → process-level), выявление выбирает примитивы данных.
Шаг 5 — Шаблон документации
На кандидата CDE (листовую колонку) минимально фиксируем:
candidate_id: cand-001
report_line: "Income Statement — Net Revenue"
sox_account: "Trip Revenue"
system: "Dispatch service (Go)"
pipeline: "kafka:trips.completed → dbt:fct_trip_records"
table: "snowflake.dl_marts.fct_trip_records"
column: "fare_total_usd"
trace_evidence:
- "S-1 draft section 4.3 — revenue recognition policy"
- "OpenLineage event ID 4a92..."
- "dbt model fct_trip_records.sql lineage"
discovered_via: "top-down"
nominator: "CDO Office"
nomination_date: "2026-06-15"
notes: "Совпадает с топ-5 из M1.7 (revenue_gmv_aggregates upstream)."Эта структура — вход для модели данных реестра CDE (M4.5). Каждое поле покрыто там в деталях.
Top-down trace explorer
Choose a starting point (S-1 / 10-K line item, board deck figure, or regulatory report). Expand the tree to traverse layers down to physical columns. CDE flag marks candidates for the registry.
Самая verifiable строка для top-down — single P&L line which traces back to ASC 606 / IFRS 15 performance obligations satisfied per completed trip.
Кликните стартовую точку → раскрытие дерева. Каждый узел показывает обоснование; маркер CDE на листовых колонках обозначает кандидата для реестра.
Вариант: top-down от регуляторных нефинансовых отчётов
Методология top-down та же, но стартовые точки другие.
GDPR Art. 30 ROPA
GDPR Art. 30 — контроллёр поддерживает запись обработок. На цель обработки — категории субъектов данных, категории персональных данных, получатели, передачи, retention, меры безопасности.
Top-down-трасса:
- Запись ROPA: «Цель обработки: KYC / верификация личности».
- Декомпозиция: категории персональных данных = документы личности + биометрическое совпадение + государственные ID.
- Системы, вносящие вклад: сервис KYC (вендор Persona) + внутренняя очередь ревью.
- Таблицы:
postgres.kyc.profile,s3://kyc-evidence/{user_id}/.... - Колонки:
document_number_hash,biometric_match_score,dob,country_of_issue. - Листья → кандидаты CDE с флагом GDPR Art. 9 special-category.
DPO заполняет ROPA на цель обработки; команда данных валидирует корректность трассы. Зона пересечения: кандидаты CDE, всплывающие в обоих top-down (ROPA + SOX) приоритетах — kyc_profile находят оба: SOX (шлюз пригодности для выручки) + GDPR Art. 9.
Регистрация EU AI Act Annex VIII
EU AI Act требует регистрации высокорискованных AI-систем. Поля Annex VIII: детали поставщика, описание системы, целевое назначение, использованные обучающие наборы данных, характеристики производительности, процедура оценки соответствия.
Top-down-трасса:
- Запись регистрации: «Модель кредитного скоринга ECL SwiftCapital».
- Annex VIII «использованные обучающие наборы данных» — поле требует документированного провенанса данных по Annex IV.
- Трасса пайплайна: train pipeline → feature store → исходные таблицы.
- Исходные таблицы:
loan_portfolio_history,borrower_demographic_features,repayment_event_stream. - Колонки:
pd_historical,lgd_historical,borrower_age,borrower_employment_status, … - Кандидаты CDE с флагом data-governance по Article 10.
Pillar 3 disclosures (через каскад банка-партнёра)
SwiftRide напрямую не подпадает под Pillar 3, но через банка-партнёра SwiftPay — каскадно. Банк-партнёр публикует Pillar 3 квартально; SwiftPay-related фиды (баланс водителя, объёмы платежей, fraud-сигналы) — потенциально downstream от риск-отчётов банка.
Top-down-трасса:
- Pillar 3 disclosure: «Credit risk RWAs по exposure class».
- Декомпозиция: по exposure class, исходные фиды.
- SwiftPay-related: counterparty exposure к SwiftRide; агрегированные объёмы транзакций.
- Трассировать upstream: банк → взаимный обмен данными SwiftRide → API SwiftPay.
- Кандидаты CDE SwiftRide:
swiftpay_settlement_volume_daily,swiftpay_chargeback_rate,swiftpay_counterparty_balance.
DORA Register of Information
Ежегодная подача по Pillar 4. Поля включают ICT third-party providers, services, классификацию критичности.
Top-down-трасса:
- Запись реестра: «Snowflake — основной поставщик хранилища данных».
- Классификация сервиса: критичный / важный / поддерживающий.
- Декомпозиция: какие ICT-сервисы полагаются на Snowflake — финансовая отчётность + AML-мониторинг + расчёт driver-earnings + ECL-скоринг + ad-attribution.
- Кандидаты CDE: все датасеты, хранящиеся в Snowflake, поддерживающие критические функции.
Заметки по lineage-тулингу
Спецификация OpenLineage определяет фасет lineage на уровне колонок с типами трансформации DIRECT / INDIRECT и флагом маскирования. DIRECT — значение колонки вычислено из upstream-колонки. INDIRECT — колонка получена через агрегацию / фильтр / условие join. Masking — значение трансформировано перед потоком (хеширование, частичная редакция).
Для выявления работают все три типа: DIRECT обычно основной; INDIRECT обычно указывает на зависимости, связанные с governance (фильтр по PII определяет, чьи данные включены); флаг маскирования — индикатор того, что данные были санитизированы вниз по потоку, выявляет следствия для приватности.
OpenMetadata 1.12.x импортирует события OpenLineage; UI показывает lineage на уровне колонок с бейджем DIRECT / INDIRECT. Marquez — референсный бэкенд; пригоден к production.
Антипаттерны
Трасса останавливается на уровне таблицы
Симптом: реестр с кандидатом “trip_records” (уровень таблицы), не уровень колонок.
Почему плохо: разговор с аудитором: «А какая колонка в trip_records материальна — все? fare? completion_timestamp? city_id? metadata?» Без уровня колонок — контроли будут широкие (на всю таблицу), evidence — неоднозначные.
Исправление: обязательно уровень колонок. Если есть пробел в lineage на уровне колонок — сначала исправить инструментацию.
Заблуждение единого источника правды
Симптом: «Выручка идёт только из сервиса dispatch» — игнорируется корректировка сервиса billing + override-сверки + ручные журнальные записи.
Почему плохо: все три фида могут независимо вызывать материальное искажение. Ручные журнальные записи — частая причина дефицитов SOX (находки PCAOB inspection 2024-2025).
Исправление: Шаг 3b — все системы, вносящие вклад, включая сверку + ручные override-источники. Документируйте каждый отдельно.
Пропуск нефинансовых отчётов
Симптом: sweep покрывает 10-K, S-1; пропускает GDPR ROPA + регистрацию AI Act + DORA register.
Почему плохо: SOX-периметр у Big 4 — OK; запрос DPO + ICO supervisory проваливается. Мульти-регуляторная экспозиция невидима.
Исправление: Шаг 1 вселенная отчётности — все отчёты. M3 regulatory landscape — референс по регуляции.
”Всё это в OpenLineage” — игнорирование пробелов инструментации
Симптом: трасса останавливается, «потому что OpenLineage не покрывает train pipeline SwiftCapital» — молча пропускаем, идём дальше.
Почему плохо: молчаливый пробел = невидимый пропуск. Кандидаты CDE в зоне пробела — обнаруживаются только при инциденте.
Исправление: пробелы lineage — first-class находки. Открытая задача: «инструментировать train pipeline SwiftCapital OpenLineage к T+3M». До этого — ручная трасса + флаг кандидатов с lineage_evidence: manual.
Evidence трассы не зафиксированы
Симптом: yaml кандидата перечисляет trace_evidence как «выведено из lineage»; нет ID события OpenLineage, нет ссылки на dbt model.
Почему плохо: пост-хок аудит «как мы знаем, что выручка захвачена?» — ответ должен быть конкретными артефактами. Расплывчатые evidence = уязвимость.
Исправление: Шаблон документации Шага 5 — конкретные evidence на кандидата. ID события OpenLineage + SHA dbt model + ссылка на исходный код.
Top-down sweep SwiftRide — поставка фазы 1
T0 → T+1M:
- 11 отчётов обследовано (Income Statement + Balance Sheet + IFRS 18 mock + ROPA + AI Act draft + DORA register + Pillar 3 cascade + AMLR + Internal Audit + материалы для совета директоров + IFRS 15 disclosures).
- ~30 кандидатов CDE задокументировано в YAML-файлах с тегом
candidate_id. - 8 пробелов lineage идентифицировано (задачи инструментации T+2M).
- 3 источника ручных журнальных записей отмечены для walkthrough-тестирования в M5 (контроли).
- Перекрёстная сверка: кандидаты с топ-5 из M1.7 — все 5 всплыли (revenue_gmv_aggregates, kyc_profile, driver_earnings_ledger, swiftcapital_loan_portfolio, aml_alerts_dispositions).
- Новые кандидаты, не пересекающиеся с M1.7: 25 (включая SwiftAds attribution, обучающие фичи SwiftCapital, ledger налоговых удержаний, FX-хедж-позиции, vendor accounts payable).
Итоги
- Top-down workflow — 5 шагов: определить вселенную отчётности → значимые элементы → декомпозиция в SOX-счёт / системы / пайплайны → обратная трасса lineage → документировать на кандидата.
- PCAOB AS 2201 ¶.21 влияет, но не идентичен — выявление выбирает примитивы данных, аудит выбирает контроли.
- Вселенная отчётности — все отчёты: финансовые (10-K, S-1, IFRS 18) + регуляторные нефинансовые (GDPR ROPA, AI Act Annex VIII, DORA register, Pillar 3 cascade) + внутренние (материалы для совета директоров, internal audit).
- Шаблон документации: yaml на кандидата с report_line, sox_account, system, pipeline, table, column, trace_evidence, discovered_via, nominator, date, notes.
- Lineage на уровне колонок OpenLineage с фасетами DIRECT / INDIRECT / masking — основной инструмент. UI Marquez / OpenMetadata.
- Антипаттерны: трасса до уровня таблицы; заблуждение единого источника правды; пропуск нефинансовых отчётов; игнорирование пробелов инструментации lineage; расплывчатые evidence трассы.
- Поставка SwiftRide T+1M: 30 кандидатов CDE; идентифицировано 8 пробелов lineage; сверено с топ-5 из M1.7; 25 новых кандидатов сверх M1.7.
- Следующий урок (M4.3): bottom-up workflow — lineage на уровне колонок + аналитика использования + распространение критичности; обнаруживает операционные + теневые CDE.