Введение

CDO SwiftRide получил от Big 4 список «топ-25 findings»; одиннадцать из них про данные. Третий пункт звучит так: «No formal identification of critical data elements feeding ICFR-relevant processes». На kick-off встрече один из senior engineers задаёт правильный вопрос: «У нас в OpenMetadata 1 847 датасетов. Какие из них critical? И что значит critical — у меня все пайплайны важные».

Этот урок — фиксация определения Critical Data Element (критический элемент данных), без размытости. После него вы можете сесть напротив senior manager из Big 4 и в одном предложении объяснить, что попадает в CDE-реестр и почему остальное — нет.

Определение

CDE (Critical Data Element / критический элемент данных) — это элемент данных, ошибка, отсутствие или искажение которого приводит к материальному финансовому, регуляторному или операционному ущербу. В этом определении два слова делают всю работу: «элемент» и «материальный».

«Элемент» — это не таблица и не схема. Это атрибут, поле, конкретная колонка — driver_earnings.gross_amount, customer.kyc_status, loan.expected_credit_loss_stage. Когда регулятор спрашивает «покажите ownership и lineage для CDE», ответ должен быть на уровне поля, не «у нас есть таблица kyc_profile, владелец — Compliance». Каталог с CDE-флагом на уровне таблиц — это первый шаг; CDE-флаг на уровне колонок — это работающая программа.

«Материальному» — это термин, заимствованный из бухгалтерского учёта (см. урок 2 про materiality threshold). Не всё «важное» — материально. Тысяча датасетов, которые помогают product team итерировать по feature flags, важны для бизнеса, но не материальны для финансовой отчётности. Выходы pricing engine — материальны, потому что фидят revenue recognition и попадают под EU AI Act EU AI Act Art. 10.

CDE требует, при минимальной зрелости программы, шести вещей: назначенный Data Owner, бизнес-определение в бизнес-глоссарии, техническое определение (где живёт, какой тип), DQ tolerances с метриками, lineage до authoritative source, и controls, покрывающие минимум accuracy + completeness. Если хотя бы одного из шести нет — это не CDE, это «номинированный кандидат».

Откуда пришёл термин

Термин не родился в банковской регуляции. Сначала его использовало сообщество DAMA.

Ключевой исторический факт: к моменту, когда регуляторы (ECB, MAS) приняли термин, у банков уже было около 10 лет практики. Implementation review BCBS 239 BCBS d559 Nov 2023 показывает: даже после десятилетия только 2 из 31 G-SIBs полностью compliant. Это полезное напоминание CDO SwiftRide: программа на 18 месяцев — амбициозно, но достижимо, если периметр честный.

CDE vs KDE — это одно и то же

В литературе встречается KDE — Key Data Element. Это тот же самый концепт, просто разные регуляторы и фреймворки предпочли разную терминологию.

• CDE — DAMA, EDM Council, диалект BCBS 239, ECB RDARR Guide, MAS.
• KDE — APRA (Австралия), OSFI (Канада), несколько банков в US.

В вашей организации выбирайте одну терминологию и не смешивайте. SwiftRide идёт на листинг NYSE — придерживайтесь CDE как mainstream-варианта. Если в M&A вы приобретаете компанию с KDE-программой, синхронизация двух реестров требует glossary mapping, но не пересборки концепции.

Чем CDE отличается от соседних понятий

Самая частая ошибка джуниорской data risk-команды: «у нас CDE-программа уже есть, мы же давно ведём Master Data и Reference Data». Это разные вещи, и путаница обходится дорого, когда аудитор задаёт точный вопрос.

Master Data — persistent business entities (Customer, Product, Driver, Location). Это тип содержимого: данные, описывающие сущности, а не их транзакции. Владение обычно у MDM-команды. Часть Master Data — CDE (water-tight identifier в KYC profile — CDE), часть — нет (product catalog для маркетингового экспериментирования — обычно не CDE).

Reference Data — controlled vocabularies, code lists, lookup tables. ISO country codes, internal status enums, currency codes. Часто путают с Master Data: ключевое отличие — масштаб и частота изменений. Reference Data — небольшой набор значений (десятки-сотни), меняются редко (через формальный change request). Может быть CDE: country code фидит логику tax jurisdiction — попадает в SOX scope, становится CDE.

Critical Data Element — это ось criticality, а не тип содержимого. Любая категория слева может быть CDE или не быть. CDE-утверждение про что произойдёт при ошибке, а не про какого типа эти данные.

Confidential / Restricted / Internal / Public — это security classification, ось, ортогональная criticality. Restricted KYC profile — и CDE, и Restricted. Внутренний employee handbook — Restricted, но не CDE. Опубликованный квартальный GMV — Public, но абсолютно CDE для SOX. Не путайте две оси.

SwiftRide: портфель из 15 кандидатов — где CDE очевидно, где нужен criticality scoring

В сквозном кейсе есть портфель из 15 кандидатов в CDE (см. урок M0.4, секцию «Кандидаты в CDE»). Часть из них — очевидные CDE; часть требует criticality scoring. Сравним два конкретных:

Driver earnings ledger (кандидат №2). Содержит gross amount, commission, taxes, payout per driver per period. Очевидно CDE:

• Финансово: фидит revenue recognition (take rate = (driver gross - driver payout) / driver gross — это revenue logic под IFRS 15 / ASC 606).
• Регуляторно: labour compliance (отчётность по странам), 1099 (US-водители), social security по странам; после IPO — SOX 302 (CEO/CFO certify), 404 (ICFR over revenue).
• Операционно: отказы или задержки payouts = массовый driver churn в течение 48 часов (инцидент SwiftRide 2024 — $2.3M underpayment в регионе DACH).
• Репутационно: протесты водителей в LATAM в 2023 (другая компания) были спровоцированы earnings dispute — попадание на front-page media в трёх странах.

Score 5/5 по всем 4 dimensions. CDE — без дискуссии.

SwiftAds attribution data (часть кандидатов из бизнес-юнита SwiftAds). Это данные о том, какому advertiser приписать какой install, click, view. Здесь сложнее:

• Финансово: SwiftAds — 1-2% net revenue на T0 (по сквозному кейсу около $25M); материально для бизнес-юнита, не материально для consolidated revenue.
• Регуляторно: GDPR Art. 6 (lawful basis для targeting), EDPB Opinion 22/2024 (обязательства processor), DSA recommender transparency. Это reputational + privacy, не SOX-grade.
• Операционно: SwiftAds — async revenue stream; ошибка не блокирует core ride-hailing operations.
• Репутационно: средний уровень; advertiser disputes — обычное дело, эскалируют редко.

Score варьируется: около 2/5 financial, 3/5 regulatory, 1/5 operational, 2/5 reputational. Weighted — около 2. Пограничный случай. Решение зависит от scoping pre-IPO программы: если SOX-scope включает segment reporting SwiftAds под IFRS 8 — CDE, иначе — вне периметра первой итерации реестра, перепроверка через 12 месяцев.

Этот контраст — суть criticality scoring (урок 4 этого модуля). Не «всё критично», не «всё некритично» — структурированное решение по каждому кандидату.

Анти-паттерн: «всё критично» → коллапс программы

Самая дорогая ошибка CDE-программ — scope inflation. Что чаще всего происходит:

Шаг 1. CDO формулирует амбициозный мандат: «у нас должна быть полная атрибуция владельца всех data assets, не только CDE». Это правильное долгосрочное видение, но смешение с CDE-программой опасно.

Шаг 2. Бизнес-юниты, услышав слово «critical», начинают защитно номинировать всё своё. «Все наши финансовые данные critical», «весь pricing engine critical», «все ML-фичи critical». Никто не хочет быть тем, чьи данные оказались non-critical и потом попали в инцидент.

Шаг 3. Реестр разрастается с 24 запланированных до 600 элементов. Каждый требует Data Owner, DQ tolerances, controls. Нагрузка на команду растёт в 25 раз, а capacity — нет.

Шаг 4. Через 6-9 месяцев программа коллапсирует. Data Owners назначены формально, но не вовлечены. DQ tolerances — копипаст. Controls существуют на бумаге, не выполняются. Когда приходит external audit, evidence package — пустой.

Industry rule of thumb (глоссарии DataKitchen, Alation, Collibra): зрелая организация приземляется на 100-400 CDE. Программы, которые пытаются равномерно governить тысячи атрибутов, проваливаются. Это не теория — это back-tested на десятках внедрений.

Для SwiftRide T0 — реалистичная цель первого года: 24 CDE (T+3M, см. драматургию в M0.4), 60 CDE к концу первого года, около 150 CDE к T+18M (момент IPO). Не больше. Если 300 — это или другая программа (полная data governance), или ошибка scoping.

Почему CDE-программы проваливаются — полная таксономия

Из BCBS d559 (Nov 2023), отраслевых эссе (DataKitchen, Alation 2026 field guide), и наблюдений Big 4 — следующие 5 failure modes, ранжированные по частоте:

1. Scope inflation (описано выше). Программа пытается governить всё → не успевает governить ничего.
2. Tooling-first трансформация. Купили Collibra / Atlan / Workiva до того, как определили периметр. Через год: «у нас есть каталог, но никто не знает, что туда положить» (см. M0.3 для подробностей).
3. Ownership без accountability. Поле Data Owner заполнено на 95% — это метаданные. Owner не подписывает quarterly attestation, не отвечает за DQ tolerances, не получает эскалацию при breach. Это catalog hygiene, не CDE-программа.
4. Разрыв с таймлайном аудита/регулятора. CDE-реестр существует, но не синхронизирован с циклом external audit. Senior из Big 4 просит evidence за Q3, в реестре — данные за последние 30 дней. Программа не пережила первый audit cycle.
5. DQ-as-checks без последствий. DQ-тесты запускаются в dbt, fail rate 5%, упавшие тесты игнорируются. Это шум, не control. Согласно AS 1105 IPE-testing — если control не enforced, это не control.

Программа SwiftRide должна явно вычленить эти 5 паттернов в design phase (M0-M2) и встроить митигации.

Итоги

• CDE — гранулярный элемент данных, материально влияющий на financial, regulatory, operational или reputational outcomes. Элемент — на уровне field/column, не table.
• Происхождение термина: DAMA-DMBOK 2 (2010); BCBS 239 (Jan 2013) — первый регуляторный текст; ECB RDARR Guide (May 2024) и MAS Information Paper (May 2024) — явные supervisory expectations.
• CDE ≡ KDE в большинстве регуляторных текстов; APRA/OSFI предпочитают KDE. SwiftRide использует CDE как mainstream-вариант.
• CDE — ось criticality, ортогональная осям content type (Master Data / Reference Data / Transactional) и security classification (Public / Internal / Restricted / Confidential). Один датасет может быть CDE + Reference Data + Restricted одновременно.
• Реализм периметра: зрелая организация приземляется на 100-400 CDE. SwiftRide T+3M цель — 24, T+18M — около 150. Программы со «всеми датасетами критичны» коллапсируют через 6-9 месяцев.
• 5 failure modes: scope inflation, tooling-first, ownership без accountability, разрыв с audit cycle, DQ-as-checks без последствий. Митигировать в design phase, не в production.
• Дальше: урок 2 — materiality threshold, как accounting concept переносится на данные.