Дані про клієнта і захист персональних даних: де конфлікт
- KYC і GDPR не виключають один одного — вони вимагають різних підходів до тих самих даних, і баланс знаходиться в законній підставі та мінімізації.
- Зберігати «на всяк випадок» — це прямий шлях до штрафів від Охоронця даних і питань від фінмоніторингу одночасно.
- Робочий процес будується на мапінгу категорій даних до законних підстав, термінах зберігання та процедурах видалення, а не на шаблонах з інтернету.
Ще на минулому тижні клієнт банку надсилав скан паспорта у Telegram-боті, бо «менеджер просив». Комплаєнс-офіцер знайшов це під час перевірки — не в процесі, а через місяць. Система KYC відпрацювала, персональні дані витекли, відповідального не було. Це типова помилка: компанії пишуть політики для перевірки, а не для роботи.
Чому KYC і GDPR потрапляють у конфлікт?
Конфлікт не між цілями, а між інструментами. Фінмоніторинг каже: «Збирайте все, що може знадобитися для розслідування». Захист даних каже: «Збирайте лише те, що безпосередньо необхідно для мети, і видаляйте, коли мета досягнута». Банк, фінтех, юрфірма або некомерційна організація — усі вони одночасно суб'єкти фінмоніторингу та контролери персональних даних. Порушення однієї з мандрять нормативних систем тягне за собою санкції від другої.
На практиці це виглядає так: політика KYC вимагає скан паспорта, кода ЄДРПОУ/РНОКПП, довідки про реєстрацію, пакет документів про бенефіціарів, фінансові звіти контрагента. GDPR вимагає обґрунтувати, чому саме ці дані, на якій законній основі, як довго вони зберігатимуться і хто до них має доступ. Якщо в організації немає мапінгу «категорія даних — законна основа — термін зберігання — суб'єкт доступу», конфлікт вирішується на користь зручності: зберігають усе, довго, без порядку.
Які дані дійсно потрібні для KYC, а які — «на всяк випадок»?
Закон України «Про запобігання та протидію легалізації (відмиванню) доходів, одержаних злочинним шляхом...» (ст. 7, 8) визначає мінімальний перелік: ідентифікаційні дані (ПІБ, дата/місце народження, документ, адреса), дані про бенефіціарних власників, інформацію про структуру власності, джерело коштів, призначення операцій. Все вище — це вже рішення бізнесу, яке має бути задокументоване в оцінці ризиків.
Поширена практика: просити довідку з місця роботи, банківський виписку за рік, копії договорів контрагента, соціальні медіа профілі. GDPR не забороняє це, але вимагає: чому саме ці дані для саме цього клієнта? Якщо ризик низький — достатньо мінімального набору. Якщо високий — розширений zbір має бути обґрунтований в профілі ризику. Автоматичне запитування «всього по черзі» — це порушення принципу мінімізації (Art. 5(1)(c) GDPR).
Як задокументувати законну підставу для кожної категорії даних
Створіть таблицю відповідності. Приклад структури:
| Категорія даних | Мета обробки | Законна основа (ст. 8 ЗУ / Art. 6 GDPR) | Термін зберігання | Підстава терміну | Доступ мають |
|---|---|---|---|---|---|
| ПІБ, дата народження, паспорт | Ідентифікація клієнта | Виконання закону (фінмоніторинг) | 5 років після закінчення відносин | Ст. 11 ЗУ «Про ПД/ФТ» | Комплаєнс, МЛРО, аудитори |
| Дані бенефіціара | Визначення контролеру | Виконання закону (фінмоніторинг) | 5 років після закінчення відносин | Ст. 11 ЗУ «Про ПД/ФТ» | Комплаєнс, МЛРО |
| Банківська виписка (за запитом) | Оцінка джерела коштів | Виконання договору / легітимний інтерес | До прийняття рішення + 1 рік | Внутрішня політика | Аналітик ризиків |
| Соцмережі (публічні) | Репутаційна перевірка | Легітимний інтерес | До прийняття рішення | Внутрішня політика | Аналітик ризиків |
Ця таблиця — ваш головний артефакт при перевірці і від Охоронця даних, і від ДФС/Нацбанку. Відсутність мапінгу = відсутність управління процесом.
Як встановлювати та дотримувати терміни зберігання
Фінмоніторинг (ст. 11 ЗУ «Про ПД/ФТ») вимагає зберігати документи ідентифікації та операцій 5 років після закінчення відносин з клієнтом. GDPR (Art. 5(1)(e)) вимагає: «не довше, ніж необхідно для цілей». Конфлікт вирішується так: 5 років — це максимальний термін для даних, зібраних виключно для фінмоніторингу. Але якщо ви використовуєте ті ж дані для маркетингу, аналітики, скорингу — для цих цілей термін інший і має окрему підставу.
Практичний крок: впровадьте автоматизовані (або календарні) тригери видалення/анонімізації. Через 5 років + 1 місяць після закриття рахунку/розриву договору — дані ідентифікації архівуються в «тільки для читання» для регуляторних запитів, але вилучаються з операційних систем. Доступ до архіву — лише за запитом МЛРО або суду.
Хто і як керує доступом до даних KYC
Принцип «need to know» працює суворо. Менеджер по продажам не повинен бачити повний пакет KYC після онбордингу. Аналітик фінмоніторингу бачить історію операцій, але не маркетингові теги. Юрист при судовому спорі отримує витяг, а не дамп БД. Це реалізується через RBAC (role-based access control) і журнали доступу.
Часта помилка: один Google Drive / SharePoint / CRM з відкритим доступом для відділу. Це одночасно порушення ст. 19 ЗУ «Про захист персональних даних» (заходи безпеки) та вимог Нацбанку до захисту інформації. Мінімум — розділення середовищ: онбординг, операційний моніторинг, архів. Кожне з власним матрицею доступу.
Як відповідати на запити суб'єктів даних (DSAR) під час KYC
Клієнт має право (ст. 22 ЗУ / Art. 15 GDPR): дізнатися, чи обробляються його дані, які саме, з якої мети, хто одержувач, термін зберігання, право на виправлення, видалення, обмеження, заперечення, портативність. У контексті KYC: право на видалення не діє, якщо обробка відбувається за законом (фінмоніторинг). Але право на інформацію — діє повністю.
Процедура: 1) Верифікація ідентичності запитувача (не дайте дані іншій особі). 2) Пошук по всіх системах (CRM, архів, пошта, месенджери, бекапи). 3) Формування відповіді за 30 днів (можна продовжити до 60 з повідомленням). 4) Виключення внутріжніх коментарів, оцінок ризику, судових стратегій — це не «дані суб'єкта», а робочий продукт. 5) Логування запиту та відповіді.
Немає процедури — буде скарга до Охоронця даних, перевірка, штраф. Маєте 30 днів, починаючи зараз.
Як працювати з передачею даних третім сторонам (процесорам, банкам-кореспондентам, реєстраторами)
Кожна передача — це окрема операція обробки, яка потребує: законної основи, укладення договору з процесором (Art. 28 GDPR / ст. 13 ЗУ), оцінки адекватності країни отримувача (або SCC/BCR). Для банків-кореспондентів: передача даних для виконання платежу — це виконання договору з клієнтом. Але передача всього KYC-пакета «для перевірки» без конкретного платежу — вже потребує окремої підстави.
Перевірка контрагентів через відкриті реєстри, SanctioScan, World-Check — це легітимний інтерес. Але завантаження паспортних даних у зовнішній SaaS-скринінг без договору з процесором і DPIA (оцінки впливу) — це ризик. Детальніше про банківські відмови і скринінг.
ПRACTИЧНИЙ АРТЕФАКТ: Чекліст аудиту конфлікту KYC / GDPR
- Мапінг даних — є таблиця «категорія / основа / термін / доступ» для всіх даних, зібраних при KYC?
- Мінімізація — відсутні поля «на всяк випадок» в онбординг-формах? Запит додаткових даних ініціюється лише аналітиком ризиків з обґрунтуванням?
- Зберігання — налаштовані тригери архівування/видалення за 5 роками після закінчення відносин? Архів ізольований від операційних систем?
- Доступ — RBAC налаштований за принципом «need to know»? Журнали доступу ведуться та перевіряються раз на квартал?
- Процесори — укладені угоди з усіма процесорами (CRM, хмарні сховища, скринінг-сервіси)? Проведено DPIA для систем високого ризику?
- DSAR — є відпрацьована процедура обробки запитів суб'єктів даних за 30 днів? Відповідальна особа призначена?
- Навчання — менеджери знають, що не можуть просити паспорт у Telegram/email, а лише через безпечний портал?
- Інциденти — є план реагування на витік даних KYC (сповіщення Охоронця за 72 години, суб'єктів — без непотрібної затримки)?
Як це пов'язане з автоматизацією моніторингу
Машина не вирішує, які дані збирати — це рішення людини з відповідальністю. Автоматизація лише виконує правила. Якщо правила дозволяють «збирати все» — машина зібере все. Якщо правила жорстко прив'язані до мапінгу — машина блокує зайве. Автоматизація фінансового моніторингу: що справді можна віддати машині.
Як це впливає на репутаційну перевірку контрагентів
Перевірка через відкриті джерела (OSINT) — легальна за легітимним інтересом. Але збереження скріншотів профілів, копій документів з суду.гув.уа, нотаріальних реєстрів у власній базі без терміну видалення — це вже створення власного реєстру персональних даних, який підпадає під GDPR. Репутаційна перевірка засновників: що знаходять у відкритих джерелах.
FAQ
Чи згода клієнта потрібна для KYC?
Ні. Законна основа — «виконання закону» (фінмоніторинг) або «виконання договору». Згода потрібна лише для цілей, що виходять за межі KYC (маркетинг, профілювання, передача партнерам не за законом).
Чи можна зберігати дані KYC довше 5 років?
Тільки якщо є окрема законна основа для кожної додаткової категорії даних або мети. «На випадок перевірки» — не є законною основою.
Що робити, якщо клієнт вимагає видалити свої дані під час відносин?
Пояснити, що видалення неможливе через вимоги фінмоніторингу (ст. 11 ЗУ «Про ПД/ФТ»), але забезпечити право на доступ, виправлення, обмеження обробки за межами KYC.
Чи підпадає скринінг через World-Check / Dow Jones під GDPR?
Так. Це передача даних третій стороні (процесору). Потрібен договір з процесором, оцінка адекватності (SCC для США), DPIA, якщо обробка масштабна/системна.
Як документувати відмову клієнта надати дані для KYC?
Фіксувати в системі: дата запиту, перелік даних, причина відмови (якщо відома), рішення про відмову в онбордингу/розрив відносин. Це ваш захист при перевірці фінмоніторингу.
Чи потрібен DPIA (оцінка впливу на захист даних) для KYC-системи?
Так, якщо: системна обробка чутливих даних, масштабна автоматизована обробка, використання нових технологій. Для більшості банків і фінтех — так. Для малих НБФІ — оцінюйте за критеріями ст. 35 GDPR.
Конфлікт між фінмоніторингом і захистом даних не розв'язується вибором «хто важливіший». Він розв'язується архітектурою процесу: чіткий мапінг, мінімізація за замовчуванням, ізольоване архівування, суворий контроль доступу і відпрацьовані процедури DSAR та інцидентів. Це не про папери для перевірки — це про те, чи здатна організація відповідати за дані, які змушена збирати. Почніть з аудиту чеклістом вище — і ви побачите, де саме у вас «проліває» управління ризиками.
Матеріал підготовлено за допомогою штучного інтелекту та перевірено авторкою перед публікацією. Це загальне пояснення принципів, а не індивідуальна юридична чи фінансова консультація: конкретна ситуація потребує окремого розгляду.