GDPR для FinTech: ключові вимоги та практичні кроки для комплаєнсу
Про ключові аспекти застосування General Data Protection Regulation (GDPR) для фінансово-технологічних проєктів розповіли у відео на YouTube-каналі «Legal IT Group», а ми підготували короткий виклад найважливішого.
Сфера дії та фундаментальні принципи GDPR
Для FinTech-компаній критично важливо розуміти, що GDPR набуває обов'язкової сили, якщо обробка персональних даних відбувається в контексті діяльності установи у Європейському Союзі. Це правило діє навіть тоді, коли сама обробка здійснюється за межами ЄС. Фактично, Регламент поширюється на компанію, якщо її продуктами користуються резиденти Європейського Союзу, незалежно від того, де вона фізично розташована.
Фундаментом комплаєнсу є суворе дотримання шести базових принципів, які для регулятора слугують ключовим індикатором законності обробки. Ці принципи є не просто «духом закону», а практичними, обов'язковими нормами, невиконання яких часто є підставою для штрафів. Для FinTech-проєктів особливого значення набувають:
-
1
Мінімізація даних: Вимагає збирати дані лише в обсязі, необхідному для конкретної мети обробки. Заборонено збирати більше, ніж є необхідним.
-
2
Обмеження зберігання та цілей: Дані не можуть зберігатися довше, ніж це потрібно, і можуть збиратися лише для конкретних, законних та чітко визначених цілей.
-
3
Цілісність та конфіденційність: Обробка має забезпечувати необхідний рівень безпеки даних.
-
4
Точність: Персональні дані мають бути точними і виправлятися за необхідності.
-
5
Відповідальність: Контролер завжди несе відповідальність за дотримання всіх вищевказаних принципів.
Саме на принципи мінімізації даних, точності, цілісності та конфіденційності фінансово-технологічним проєктам необхідно приділити максимум уваги.
Правові стовпи: на чому ґрунтується обробка даних
Кожна дія з обробки персональних даних повинна мати чітку, достатню правову підставу. Найчастіше FinTech використовує:
- Виконання договору (Performance of a contract): Обробка законна, якщо вона необхідна у контексті договору або наміру укласти такий договір.
- Виконання юридичних зобов'язань (Legal Obligation): Це єдина незамінна правова підстава для проведення процедур KYC (Know Your Customer) та AML (Anti-Money Laundering). Це важливо, оскільки компанія не може використовувати згоду користувача. Згода має бути вільно наданою, а це означає, що користувач мав би право відмовитися, що зробило б неможливим ефективне проведення обов'язкових за законом процедур.
- Явна згода (Explicit Consent): Необхідна у ситуаціях з високим ризиком, наприклад, при обробці спеціальних (чутливих) категорій даних, коли вимог звичайної згоди недостатньо. Суб'єкт даних повинен явно заявити про свою згоду, наприклад, письмовим шляхом.
- Легітимний інтерес (Legitimate Interest): Виникає, наприклад, у випадку обробки персональних даних для забезпечення безпеки систем.
Втілення принципів на практиці реалізується через підходи Privacy by Design та Privacy by Default. Перший, Privacy by Design, вимагає, щоб компанія враховувала питання приватності та захисту даних уже на етапі проєктування будь-якої системи, послуги чи продукту, підтримуючи це протягом усього життєвого циклу. Другий, Privacy by Default, гарантує, що компанія обробляє лише ті дані, які необхідні для досягнення конкретної мети. Це означає, що FinTech-проєкт повинен забезпечити обробку з найвищим рівнем захисту від самого початку, щоб за замовчуванням оброблялись лише мінімально необхідні дані.
Обробка даних у KYC/AML та уроки судової практики
Підписуйтеся на наші соцмережі
Обробка даних для KYC/AML, ґрунтуючись на правовій підставі Legal Obligation, має чіткі межі:
-
1
Обмеження цілей: Дані, зібрані для верифікації, не можуть використовуватися для інших цілей, наприклад, для маркетингу. Якщо це разова перевірка, збір даних не може бути необмеженим у часі, якщо це не передбачено законом.
-
2
Обмеження зберігання: Якщо законом не передбачено інший строк, дані не можуть зберігатися необмежено, і компанії потрібно зберігати лише факт верифікації.
-
3
Перевірка чутливих даних: Необхідно перевіряти, чи дозволяє застосоване національне законодавство обробку чутливих даних (наприклад, біометрії обличчя) у рамках цих процедур.
Якщо FinTech-проєкт користується послугами сторонніх KYC-провайдерів, вони зазвичай є процесорами за GDPR. Це вимагає обов'язкового підписання угоди про обробку даних (Data Processing Agreement, DPA). Більшість SaaS-рішень мають публічні DPA, але їх потрібно перевіряти на актуальність та відповідність дійсності. У разі відсутності DPA або його нерелевантності, компанія може підписати власну DPA, використовуючи офіційні шаблони Єврокомісії.
Показовий кейс іспанського регулятора (2021 рік) демонструє підхід до безпеки. Компанія отримала штраф у 2.5 млн євро за те, що вимагала від клієнта надіслати чутливу фінансову інформацію щодо походження грошей через звичайний незашифрований email, що було визнано небезпечною практикою. Додаткові фактори штрафу: у контролера був незаповнений DPA, який не стосувався саме процедури AML, не були надані альтернативні, безпечні способи передачі інформації (наприклад, поштою чи особисто), а заходи щодо виправлення ситуації були вжиті лише через рік, що також вплинуло на суму стягнення. Регулятор розцінив використання незашифрованих листів для передачі фінансових даних як порушення статті 32 щодо безпеки даних.
Чутливість фінансових даних: категорії та особливі вимоги
Фінансові персональні дані — це будь-які відомості, які вказують на економічну особистість фізичної особи. Навіть найпростіший датасет (набір даних) про транзакцію, що містить номер рахунку, ім'я покупця та інформацію про термінал, якщо він дозволяє ідентифікувати особу, вважається фінансовим датасетом.
Важливо розрізняти поняття чутливих даних:
- Чутливі платіжні дані (за PSD2): Це ті дані, які можуть бути використані для здійснення шахрайства (наприклад, паролі доступу).
- Спеціальні категорії даних (за GDPR): Це дані, що розкривають расове або етнічне походження, політичні чи релігійні погляди, членство у профспілках, або дані про здоров'я.
Для FinTech-проєктів ключовим є принцип «чутливості всього датасету», підтверджений рішенням суду ЄС (справа Meta проти Бундескартиля). Якщо в датасеті платіжних транзакцій міститься хоча б один елемент, який опосередковано розкриває спеціальні категорії даних (наприклад, платіж за послуги в стоматологічній клініці, або пожертвування політичній чи релігійній організації), то весь датасет має захищатися та оброблятися як чутливий. Це вимагає від контролера застосування найвищих стандартів безпеки до всіх таких даних.
Data Protection Officer (DPO): роль та обов'язки
Призначення Data Protection Officer (DPO) є обов'язковим, якщо основна діяльність FinTech-компанії пов'язана з регулярною та систематичною обробкою персональних або спеціальних категорій даних у великих масштабах. Відсутність DPO у таких випадках розцінюється як пряме порушення регламенту.
DPO може бути як внутрішнім працівником (In-house), так і зовнішнім консультантом (Outsourced). Обидва варіанти є рівнозначними.
- Внутрішній DPO добре знає структуру бізнес-процесів та культуру компанії, але повинен зберігати незалежність у корпоративній структурі та не мати конфлікту інтересів; наприклад, він не може одночасно очолювати відділ інформаційної безпеки.
- Зовнішній DPO забезпечує відсутність корпоративного конфлікту інтересів, має ширший досвід роботи з різними бізнес-моделями і може застосовувати перевірені рішення. Часто є економічно вигіднішим для малого та середнього бізнесу.
Незалежно від формату, DPO має залишатися доступним для працівників, брати участь у плануванні нових процесів та надавати незалежні поради.
Необхідна документація: зовнішній та внутрішній захист
Програма приватності FinTech-компанії має складатися з комплексу публічної та внутрішньої документації, що є базисом для її побудови.
Публічна документація:
- Privacy Policy: Це основний документ для користувача. Він повинен відповідати вимогам статей 13-14 GDPR, пояснювати, які персональні дані збираються, кому можуть передаватися, з якою метою, які права має суб'єкт даних і як він може їх реалізувати. Документ має бути написаний максимально доступно і зрозумілою мовою.
- Cookies Policy: Необхідна, якщо використовуються Cookies, та має відповідати вимогам ePrivacy Directive. Це більш актуально для вебсайтів.
- Публічний Data Processing Agreement (DPA): Рекомендований для B2B компаній та KYC-рішень, які виступають у ролі процесора. Такий договір може бути частиною загальних умов обслуговування (Terms of Service).
Внутрішня документація:
Records of Processing Activities (RoPA): Згідно зі статтею 30 GDPR, цей документ містить відомості про всі операції обробки даних, країни, куди дані можуть передаватися, а також застосовані технічні та організаційні заходи безпеки.
Data Protection Impact Assessment (DPIA): Рекомендована, якщо існує високоризикованість обробки. Враховуючи, що FinTech часто збирає фінансові та чутливі дані, проведення DPIA є доцільним.
Information Security Документація: Набір політик та процедур, що стосуються безпеки, зокрема:
- Політики щодо доступу до даних.
- Bring Your Own Device Policy (BRYOD).
- Business Continuity Policy.
- Процедури реагування на інциденти безпеки та порядок повідомлення регулятора (Supervisory Authority).
Інша внутрішня документація полегшує життя компаніям та включає:
- Процедури відповідей на запити суб'єктів даних.
- Розподіл ролей та відповідальності (Roles and Responsibilities).
- Розклад тренінгів для підвищення компетенцій.
- Політику оцінки постачальників (Vendor Assessment Policy) та відповідні процедури.
Цей комплекс документації є невід'ємною частиною програми приватності та необхідною базою для законної роботи FinTech-проєкту на європейському ринку.
Цей матеріал підготовлений на основі інформації з відкритих джерел. Редакція самостійно відбирає ключові факти, аналізує їх та структурує за допомогою AI-інструментів.