Якість даних як головне обмеження комплаєнс-аналітики
- Якість вхідних даних визначає межу ефективності будь-якої комплаєнс-моделі, навіть найсучаснішої.
- Найчастіші првали: дублі сутностей, відсутність історичної глибини, розрив між операційними та референтними даними.
- Вирішує системна робота з даними на рівні архітектури, а не точковий клайнінг перед перевіркою.
Пишу політику фінмоніторингу для команди тридцяти людей, а в базі клієнтів — п'ять варіантів назви однієї й тієї ж української державної компанії. Це типова помилка, яку я бачу регулярно: інвестують у моделі, а не в дані, які ці моделі годять.
Чому якість даних стає вузьким місцем саме зараз?
Регулятори перейшли від перевірки наявності політик до оцінки якості їхнього виконання. FATF у версні 2026 року підвищив ризики для гамінгу і гемблінгу, акцентуючи увагу на тому, що оператори не можуть якісно ідентифікувати бенефіціарів через фрагментовані дані. У України НБУ у перевірках 2024–2025 років почав вимагати докази того, як саме банк або фінпослуга підтримує актуальність довідників санкцій і ПЕП — не раз на рік, а в режимі тьоб-бази.
Паралельно бізнес масово впроваджує автоматизований скринінг і правила-тригери. Але правила працюють детерміновано: якщо в полі "країна реєстрації" стоїть "КИТАЙ" замість "CN" або "China", правило на ризик юрисдикції не спрацює. Модель не знає, що це одна країна — вона бачить різні рядки.
Де найчастіше рветься ланкужок даних?
Перше — дублі клієнтів і контрагентів у CRM, банківському ядрі, системі скринінгу, у обліковій. У практиці це 15–30% карток у середньому підприємстві без виділеного MDM. Другий — розрив між операційними даними (переказ, договір, акт) та референтними (хто власник, чи є у санкціях, яка країна ризику). Третє — відсутність часових зрізів: система знає стан "зараз", але не знає, що бенефіціар змінився півроку тому, а скринінг запускався по старому сніпшоту.
Як діагностувати проблему до того, як її знайде регулятор?
- Інвентаризація джерел — складіть реєстр усіх систем, де живуть дані про клієнтів, власників, операції, країни, санкційні листи. Позначте власника даних, частоту оновлення, формат вивантаження.
- Профайлінг ключових полів — перевірте заповненість, унікальність, відповідність довідникам для: ПІБ/найменування, ЄДРПОУ/LEI/REID, країна реєстрації, бенефіціарні ланки, статус ПЕП/санкцій.
- Тест на лінкування — виберіть 100 випадкових клієнтів і вручну перевірте, чи система бачить їх як одну сутність у всіх підсистемах. Якщо помилок > 5% — проблема системна.
- Аналіз історії змін — чи є аудит-шлях зміни бенефіціара, країни ризику, статусу ПЕП? Якщо історія починається вчора — ви сліпі до ретроспективного аналізу.
Які архітектурні рішення працюють на практиці?
| Рівень | Рішення | Чим відрізняється від "просто очістити" |
|---|---|---|
| Джерело | Єдиний довідник контрагентів (Master Data) з власними ID | Не залежить від ID банку, CRM, ERP — має свій простір ключів |
| Інтеграція | CDC (Change Data Capture) + event-driven оновлення скринінгових двигунів | Зміна бенефіціара в MDM миттєво пушає новий профіль у скринінг |
| Референтні дані | Централізоване керування довідниками (ISO, FATF, OFAC, UK, EU, UA) з версіонуванням | Кожне правило скринінгу тягне актуальну версію на момент транзакції |
| Якість | SLA на completness / accuracy / timeliness з відповідальними бізнес-власниками | Не IT-метрика, а KPI комерційного відділу / онбордингу |
| Історія | Bi-temporal таблиці: valid_time (коли сталося в реальності) + transaction_time (коли дізналися) | Дозволяє відтворити стан бази на будь-яку дату минулого для ретро-аудиту |
Як впровадити MDM без рокахого проекту?
Починайте з однієї доменної області — контрагенти платежів або клієнти онбордингу. Виділіть "золоті атрибути": ідентифікатори (ЄДРПОУ, LEI, SWIFT BIC), нормалізована назва, країна, бенефіціарне дерево до 25% контролю. Збудуйте ETL, який раз на добу зтягує дані з усіх джерел, робить лінкування (фuzzy matching по назві + точне по ідентифікаторам), виділяє кластери дублів, генерує звіт на погодження бізнес-власника. Після погодження — пуш у всі споживачі. Цикл: 2 тижні на пілот, 6 тижнів на розкат по доменах.
Як це зв'язано з пояснюваністю моделей?
Регулятор питає: "Чому ця транзакція пройшла, а ця — спричинила алерт?" Якщо ваш feature store підшиває в модель різні ідентифікатори для одного бенефіціара, модель бачить двох різних людей. SHAP-значення покажуть чистий шум. Пояснюваність починається не з інтерпретатора моделі, а з єдиного feature vector для однієї реальної сутності. Це те, про що я писала у статті про пояснюваність моделей.
Як оцінювати якість даних безперервно?
Введіть дашборд Data Quality для комплаєнсу з чотирма панелями:
- Покриття ідентифікаторами — % карток з ЄДРПОУ / LEI / SWIFT BIC.
- Консистентність довідників — % записів, де країна/валюта/НАЦЕ не відповідають еталонному довіднику.
- Свіжість референтних даних — години з останнього оновлення санкційних листів, ПЕП, реєстру бенефіціарів.
- Розриви лінкування — кількість кластерів дублів, що чекають розв'язання > 48 годин.
Кожна панель — з відповідальною особою і ескалацією до CRO при перевищенні порогу.
Як це працює на перевірці банку-кореспондента?
Кореспондент запитує: "Покажіть, як ви ідентифікували бенефіціара у цій ланці платежів". Ви видаєте: (а) गोलдений запис бенефіціара з MDM, (б) версія санкційного листа на момент транзакції, (в) аудит-шлях зміни статусу ПЕП за останні 12 місяців, (г) результат скринінгу з feature vector, що збігається з золотним записом. Банк бачить інфраструктуру, а не Excel перед перевіркою. Це знімає 80% фолов-ап запитів.
FAQ
Чи потрібен окремчий MDM, якщо ми малі — до 500 клієнтів?
До 500 контрагентів можна обійтися централізованим довідником у Google Sheets / Airtable з версіонуванням і єдиним імпортом у скринінг. Головне — дисципліна: жодного ручного редагування в скринінговій системі, всі зміни — тільки через мастер-довідник.
Як нормалізувати назви контрагентів з різних країн?
Використовуйте легальні ідентифікатори (LEI, ЄДРПОУ, UEN, SIREN, CVR) як первинний ключ. Назва — тільки для людського читання і fuzzy-лінкування. Тримайте довідник відомих варіацій назв для топ-100 контрагентів за обсягом.
Що робити з історичними даними, де немає ідентифікаторів?
Проведіть разовий ретро-лінкування: зматчуйте історичні операції по набору (назва + країна + IBAN/BIC + сума + дата) до поточного MDM. Результат — таблиця відповідностей transaction_id → master_id. Далі працюєте тільки з master_id.
Як часто оновлювати санкційні листи в продакшні?
Мінімум — T+1 після публікації ОФАС, ЄС, UK, UA. Для високоризикових юрисдикцій — вебхук/поллінг кожні 15 хвилин. Критично: версіонування. Кожен алерт має зберігати версію листа, за яким спрацював.
Чи можна передати відповідальність за якість даних IT-відділу?
Ні. IT будує труби і інструменти. Власником даних (Data Owner) має бути бізнес-процес: комерційний директор для клієнтів, закупівля для постачальників, фінанси для кореспондентів. IT — Data Steward, не Owner.
Який перший крок, якщо регулятор приходить через місяць?
Зробіть експрес-аудит: витягніть 50 останніх алертів скринінгу, перевірте вручну, чи бенефіціар у алерті збігається з бенефіціаром у договорі/платіжці. Якщо розбіжностей > 10% — ваш головний ризик не в моделі, а в лінкуванні. Починайте виправляти саме це.
Якість даних у комплаєнсі — це не про порядок за столом. Це про те, чи зможете ви на перевірці показати, що ваша система "бачить" одного й того ж бенефіціара у всьому ланцюзі: від онбордингу до вивантаження у FIU. Якщо система бачить п'ять різних осіб — ви граєте в лотерею, де виграш — відсутність штрафу, а програш — репутація і ліцензія. Почніть з інвентаризації джерел і одного домену для пілоту. Решта — ітерації.
Матеріал підготовлено за допомогою штучного інтелекту та перевірено авторкою перед публікацією. Це загальне пояснення принципів, а не індивідуальна юридична чи фінансова консультація: конкретна ситуація потребує окремого розгляду.