Введение

Девять предыдущих уроков прокачали глубину по каждому регуляторному режиму. Этот lab — first integrated practical application регуляторных знаний к CDE-портфелю SwiftRide. Output — заполненная матрица 5 CDE × 8 регуляций, gap analysis, remediation roadmap. Lab — doc-centric (обязательно); связь с output risk register M2.7 + output CDE scoring M1.7.

Inputs

Top-5 CDE из lab M1.7

8 ключевых регуляций (покрытие M3.1–M3.9)

1. SOX 404 / ICFR — US-listed entities post-IPO.
2. BCBS 239 — banking risk data aggregation; SwiftRide косвенно через partner-bank.
3. GDPR + EDPB — EU privacy.
4. PCI-DSS v4.0.1 — card data environment.
5. EU AI Act — high-risk AI systems.
6. DORA — operational resilience.
7. EU AMLR + FATF — AML.
8. NIS2 — cyber-resilience.

Шаблон lab

Создайте labs/m3-regulatory-matrix/results.md:

# Regulatory exposure matrix SwiftRide — T+3M draft

## Матрица применимости

| CDE / Регуляция | SOX | BCBS 239 | GDPR | PCI-DSS | EU AI Act | DORA | AMLR | NIS2 |
|---|---|---|---|---|---|---|---|---|
| driver_earnings_ledger | ? | ? | ? | ? | ? | ? | ? | ? |
| trip_records | ? | ? | ? | ? | ? | ? | ? | ? |
| kyc_profile | ? | ? | ? | ? | ? | ? | ? | ? |
| aml_transaction_monitoring | ? | ? | ? | ? | ? | ? | ? | ? |
| swiftcapital_loan_portfolio | ? | ? | ? | ? | ? | ? | ? | ? |

Легенда: X = полный scope · ~ = частичный · · = N/A

## Cell-level анализ (ячейки полной применимости)

Per X-ячейка — control objectives + data requirements + remediation gap.

## Инвентарь gaps

Top 10 gaps в приоритетном порядке.

## Remediation roadmap

T0 (сейчас) → T+3M / T+6M / T+12M / T+18M milestones.

## Критерии self-check + lessons learned

Интерактивная матрица — reference

Click ячейка — control objectives + data requirements per CDE × регуляция. Используйте это как reference baseline для собственного lab.

Шаги выполнения

Шаг 1 — Per-CDE применимость (M3 review)

Для каждого CDE проходите 8 регуляций:

driver_earnings_ledger:

• SOX: полный (revenue + payroll-equivalent expense; misstatement >$10M триггерит material weakness post-IPO).
• BCBS 239: N/A напрямую; частично через driver-balance feeds bank-partner SwiftPay.
• GDPR: полный (driver = data subject; earnings раскрывают доход, часы — personal data + потенциально Art. 9 — выводимая union activity).
• PCI-DSS: N/A (нет CHD).
• EU AI Act: частично (питает обучение pricing engine).
• DORA: частично (через bank-partner SwiftPay).
• AMLR: частично (поддерживающее evidence для AML scoring patterns).
• NIS2: частично (availability-critical для income payouts).

trip_records:

• SOX: полный (основной источник revenue).
• BCBS 239: N/A напрямую.
• GDPR: полный (geolocation — sensitive по CJEU + EDPB).
• PCI-DSS: N/A.
• EU AI Act: частично (matching algorithm + pricing).
• DORA: частично (через SwiftPay).
• AMLR: частично (сигнал для AML patterns).
• NIS2: частично.

kyc_profile:

• SOX: частично (управляет onboarding gate, который управляет revenue eligibility — completeness).
• BCBS 239: N/A напрямую.
• GDPR: полный (Art. 9 biometric matching; DPIA обязательно).
• PCI-DSS: частично (если включает card-based identity verification).
• EU AI Act: частично (biometric matching Annex III, если 1:N идентификация).
• DORA: частично.
• AMLR: полный (основной процесс CDD).
• NIS2: частично (конфиденциальность sensitive PI).

aml_transaction_monitoring:

• SOX: частично (регуляторные + contingent-liability disclosures).
• BCBS 239: N/A напрямую.
• GDPR: частично (Art. 6(1)(c) legal obligation).
• PCI-DSS: N/A.
• EU AI Act: частично (если ML scoring).
• DORA: полный (ICT-critical для SwiftPay).
• AMLR: полный (прямой scope).
• NIS2: частично.

swiftcapital_loan_portfolio:

• SOX: полный (balance-sheet + provision ECL).
• BCBS 239: частично (через partner-bank при каскаде).
• GDPR: полный (Art. 22 автоматическое decisioning).
• PCI-DSS: N/A.
• EU AI Act: полный (Annex III credit scoring).
• DORA: полный.
• AMLR: частично (CDD при origination).
• NIS2: частично.

Шаг 2 — Cell-level data requirements

Per X-ячейка — extract из уроков M3 + RegulatoryTimeline:

driver_earnings_ledger × SOX:

• Field-level lineage trip → earnings → payout.
• 7-летний retention immutable evidence.
• Independent reconciliation control.
• Ежеквартальный attestation Business Owner.
• Reconciliation evidence trace в IPE testing (AS 1105 ¶.10).
• Tracking deficiency по AS 1305.

driver_earnings_ledger × GDPR:

• ROPA entry + sign-off DPO.
• Retention schedule + автоматическое удаление.
• DSAR-ready data extract path.
• Lawful-basis-per-purpose flag (Art. 6).
• TIA, если non-EEA обработка.

(пр.) Per X-ячейка — 4–6 specific data requirements.

Шаг 3 — Инвентарь gaps

Сравните current state vs target. Sample-формат:

## Top 10 gaps

| Priority | Gap | CDE × регуляция | Impact | Owner | Target date |
|---|---|---|---|---|---|
| P1 | driver_earnings field-level lineage неполный | driver_earnings × SOX | Блокер SOX 404 readiness | Data Platform | T+6M |
| P2 | Нет ROPA entry для swiftcapital_loan | swiftcapital × GDPR | Блокер DPIA + Art. 22 | DPO | T+3M |
| P3 | KYC pipeline нет задокументированной bias examination | kyc_profile × AI Act | AI Act Annex III 2 Aug 2026 | ML team + Legal | T+6M |
| ... | ... | ... | ... | ... | ... |

Шаг 4 — Remediation roadmap

Sample-структура:

## T0 → T+18M remediation roadmap

### T+3M (немедленный приоритет)
- driver_earnings field-level lineage в OpenLineage.
- ROPA entries для 5 CDE.
- План bias examination для kyc_profile.

### T+6M
- Инфраструктура 7-летнего retention (S3 lifecycle + immutable).
- DPIA для top-3 high-risk CDE.
- DORA exit strategies для критических вендоров (AWS, Snowflake, Databricks, Confluent, Okta).

### T+12M
- SR 26-2-grade model risk management для ECL SwiftCapital.
- Article 10 документация полная для систем AI Act Annex III.
- AMLR-ready CDD pipeline.

### T+18M (завершение pre-IPO readiness)
- SOX 404(b)-grade evidence pipelines.
- IFRS 18 automated GL tagging.
- Полный DORA incident response playbook, протестированный tabletop.
- NIS2 зарегистрирован в national authorities.

Критерии self-check

Проверки completeness

• Все 40 ячеек (5 CDE × 8 reg) классифицированы.
• У каждой X-ячейки есть 4–6 specific data requirements.
• У каждой ~ ячейки есть обоснование (объяснение partial scope).
• У каждой · ячейки есть обоснование (объяснение N/A).

Проверки качества

• Cross-references к урокам M3.1–M3.9 задокументированы.
• Cross-references к ID CDE registry M1.7 + обоснование scoring.
• Cross-references к записям risk register M2.7.
• Реалистичные remediation owners + даты.
• Нет vague «мы должны улучшить» — конкретные actions.

Проверки defensibility

• Можете провести Big 4 auditor по матрице без gap?
• Можете провести EU partner-bank по их каскадным зависимостям?
• Можете провести Board Risk Committee по приоритизации регуляций?
• Каждый gap связан с конкретной регуляторной ссылкой (стиль RegulationRef).

Типичные ошибки

Overscoping

Симптом: каждая CDE отмечена X для каждой регуляции. Почему плохо: размывает приоритет; auditor не может понять, где SwiftRide на самом деле нужна работа. Исправление: применять scope rules per регуляция (например, PCI-DSS scope = только CHD; не все данные).

Underscoping

Симптом: маркировка N/A для регуляций, каскадированных через bank-partner SwiftPay (DORA, BCBS 239). Почему плохо: упускает критический контрактный каскад; bank-partner найдёт gap при аудите. Исправление: относиться к partner-каскаду как к partial scope; задокументировать контрактные обязательства.

Силосированная обработка

Симптом: каждая строка регуляции независима; нет cross-regulatory анализа. Почему плохо: упускает synergies (например, CDE registry per BCBS 239 удовлетворяет аспекты ROPA GDPR). Исправление: задокументировать, где один артефакт служит нескольким регуляциям.

«Compliance theater»

Симптом: длинные документы policy без operational controls. Почему плохо: auditor находит policy + нет evidence = significant deficiency. Исправление: каждая X-ячейка маппится на конкретный evidence pipeline (M7) + operational control (M5).

Игнорирование time-bound дедлайнов

Симптом: нет ссылок на effective dates (AI Act 2 Aug 2026, AMLR 10 Jul 2027, IFRS 18 1 Jan 2027 и т.д.). Почему плохо: приоритизация невидима. Исправление: roadmap выровнен с регуляторными effective dates из RegulatoryTimeline (M3.4).

Связь с M4 + M5

Output этой матрицы → M4 (CDE inventory) — каждая запись CDE в registry включает массив applicable_regulations + per-regulation data requirements. Lab M4 строит registry entries для top-5 CDE.

Output этой матрицы → M5 (controls design) — data requirements каждой ячейки управляют design контролей в M5 (preventive / detective / corrective controls; evidence pipelines; SoD).

Матрица — канонический артефакт, поддерживаемый непрерывно. Ежеквартальный refresh — новые регуляции добавляются в колонки (например, PSD3 при принятии); новые CDE добавляются в строки; содержимое ячеек обновляется, когда меняются controls + evidence.

Резюме

Output lab (target):

1. Заполненная матрица применимости — 5 CDE × 8 регуляций, 40 ячеек классифицированы.
2. Cell-level анализ — per X-ячейка, 4–6 specific data requirements + control objectives.
3. Инвентарь gaps — top 10 gaps в приоритете P1–P3.
4. Remediation roadmap — milestones T+3M / T+6M / T+12M / T+18M с owners.
5. Cross-references — к M1.7 (scoring), M2.7 (risk register), M3.1–M3.9 (регуляторные ссылки), M4 (registry), M5 (controls).
6. Defensibility — walk Big 4 auditor + EU partner-bank + Board Risk Committee.

Типичные ошибки — overscoping, underscoping, силосированная обработка, compliance theater, игнорирование effective dates. Избегайте через явные правила per регуляция + интерактивная матрица выше как baseline.