Фінансові персональні дані: розбираємо датасети. Погляд DPO

Коли датасет стає “фінансовим”?

GDPR у визначенні персональних даних зазначає, що можна визначити фізичну особу за деякими факторами, в тому числі за “економічною” ідентичністю особи. Відповідно, будь-які дані, які вказують на фінансові справи конкретної людини, є персональними. Очевидно, що навіть при найпростішій операції – наприклад, розрахунку за каву банківською карткою, обробляється цілий масив даних покупця. Він може містити номер банківського рахунку, ім’я покупця, інформація про термінал, через який здійснювалась оплата тощо. Якщо ми через такий датасет можемо визначити особистість людини та те, що вона здійснила фінансову операцію, – цей датасет є фінансовим.

Які дані містяться в фінансовому датасеті?

Фінансові персональні дані зазвичай проходять декілька етапів обробки, оскільки вони потребують високого захисту, а їх витік може мати значні наслідки для суб’єкта даних. Розберемо категорії даних, які визначає один із основних європейських документів про платіжні послуги – Payment Services Directive 2 (PSD2):

  • інформація про платіжний акаунт (наприклад, банківський рахунок);
  • персоналізовані захисні відомості (personalised security credentials);
  • ідентифікатори, які використовуються для визначення платіжного акаунту особи при проведенні транзакції;
  • чутливі платіжні дані;
  • ім’я власника платіжного акаунту;
  • номер платіжного акаунту.

З цих даних ми можемо виділити дві основні категорії – ідентифікатори, за якими платіжний сервіс “впізнає” особу, та платіжні дані, які необхідні для виконання транзакції.

Які дані містяться в фінансовому датасеті?

Ідентифікатори

Ідентифікатор у розумінні PSD2 – це комбінація літер, цифр або символів, яка присвоюється користувачеві постачальником платіжних послуг, а потім використовується сервісом для ідентифікації такого користувача для здійснення платіжної операції.

Платіжні сервіси з міркувань безпеки та зручності при обробці даних не передають повне ім’я та прізвище разом із номером та іншою інформацію про платіжний акаунт. Користувачеві натомість присвоюється “номер”, який за ним закріплюється. Наприклад:

  • John Doe – “id151025”;
  • Jane Doe – “id987123”.

На цьому прикладі бачимо, що платіжні сервіси дуже часто використовують псевдонімізацію – вид обробки, внаслідок якого за одним лише ідентифікатором неможливо визначити особу без додаткових інструментів (наприклад, ключів шифрування). Така операція додатково убезпечує користувачів платіжних сервісів, дозволяючи сервісу “впізнавати” їх на своїй стороні.

Платіжні дані

До платіжних даних ми можемо віднести:

  • персоналізовані захисні відомості;
  • аутентифікаційні дані;
  • чутливі платіжні дані (в розумінні PSD2).

Ці дані необхідні для подолання етапів проведення транзакції, таких як авторизація, аутентифікація та виконання транзакції. В результаті послідовної обробки персоналізованих захисних відомостей, аутентифікаційних та чутливих платіжних даних сервіс розуміє, що:

  1. ідентифікований користувач безпечно хоче ініціювати транзакцію;
  2. після ініціації він аутентифікується – сервіс знає, що це точно є даний користувач, а не зловмисник;
  3. користувач передає свої чутливі платіжні дані сервісу, який їх обробляє та проводить транзакцію.

Якщо ми послідовно проаналізуємо обробку ідентифікаторів та платіжних даних, отримаємо таку формулу:

Ідентифікація + ініціація + аутентифікація + платіжні дані = транзакція.

Видобуток чутливих даних з датасету за GDPR

Варто зазначити, що чутливі дані за GDPR та чутливі платіжні дані за PSD2 – це різні дані. Ми вже розбирали цю різницю у матеріалі про PSD2, тому зосередимось на дуже важливій властивості датасетів, якщо вони містять чутливі дані.

Суд Справедливості Європейського Союзу у своєму рішенні Meta v. Bundeskartellamt встановив – якщо в датасеті є хоча б один елемент чутливих даних, весь датасет вважається чутливим. Це означає, що якщо ми з будь-яких даних при транзакції можемо дізнатись про расове або етнічне походження, політичні погляди, релігійні або філософські переконання, або членство в профспілці, здоров’я або про сексуальне життя чи сексуальну орієнтацію фізичної особи – контролер матиме вищі вимоги щодо захисту та обробки датасету в цілому.

До прикладу, суб’єкт даних сплатив внесок до профспілки, або оплатив послуги в стоматологічній клініці, або переказав пожертву для релігійної організації. Це означає, що за допомогою сукупності платіжних транзакцій можна виявити різні типи поведінкових моделей, які можуть включати спеціальні категорії персональних даних. Вже виходячи з самого факту визначення таких адресатів переказів коштів, платіжний сервіс обробляє не просто платіжні дані, а чутливі дані свого користувача.

Як безпечно обробляти фінансові персональні дані?

Отож, фінансові персональні дані це не просто набір даних про користувача – завдяки ним ми можемо дізнатись дуже багато інформації про особистість людини. Тому на платіжні сервіси поширюється вся “суворість” вимог GDPR:

  • Принципи обробки (ст. 5 GDPR): необхідно дотримуватись усіх визначених Регламентом принципів обробки персональних даних, а особливо мінімізації, точності, цілісності та конфіденційності.
  • Правові підстави (ст. 6 і ст. 9 GDPR): у випадку, якщо оброблятимуться “звичайні” та чутливі персональні дані. Тоді платіжному сервісу треба буде зібрати як звичайну згоду за ст. 6, так і явну згоду (explicit consent) за ст. 9.
  • Прозорість та інформування (ст. 13 GDPR): сервіс повинен попередити користувача про те, які категорії даних будуть оброблятись, з якою метою та як довго.
  • Права суб’єктів даних (ст. 15–22 GDPR): сервіси повинні забезпечити механізми реалізації прав суб’єктів даних за GDPR.
  • Безпека обробки (ст. 24–25 GDPR): через особливий, а часто чутливий характер фінансових персональних даних, необхідно забезпечити організаційні та технічні заходи безпеки (зокрема, псевдонімізацію даних).
  • Реєстр активностей з обробки (ст. 30 GDPR): обробка фінансових даних може нести високий ризик для прав та свобод суб’єктів даних, а тому в будь-якому випадку фінансові компанії мають вести реєстр активностей з обробки даних.
  • Оцінка впливу на захист даних (ст. 35 GDPR): з наведених вище причин щодо ризиковості обробки фінансових персональних даних контролер зобов’язаний провести оцінку впливу на захист даних, а за необхідності – звернутись до DPO за допомогою.
  • Призначення DPO (ст. 37 GDPR): оскільки фінансові компанії систематично та масштабно обробляють дані своїх користувачів, зокрема чутливі дані, вони зобов’язані призначити Data Protection Officer.
Як безпечно обробляти фінансові персональні дані?

Які санкції за недотримання вимог GDPR?

Регулятори особливо пильні до фінансових компаній, а тому санкції корелюються з тією відповідальністю, яка лежить на сервісах. Загалом, GDPR визначає два види санкцій в залежності від порушених вимог:

  • до 10 000 000 € або 2 % від річного світового обороту компанії — за менш тяжкі порушення;
  • до 20 000 000 € або 4 % від річного світового обороту компанії — за більш тяжкі порушення (наприклад, за незаконну обробку спеціальних категорій даних або порушення принципів обробки).

Регулятори накладають на компанії, які не змогли дотриматись вимог GDPR в контексті фінансових даних значні штрафи – у мільйонних розмірах:

  • British Airways (ICO, Велика Британія): 20 000 000 фунтів стерлінгів стягнуто за нездатність захистити фінансові дані понад 400 000 суб’єктів даних.
  • Caixabank S.A. (AEPD, Іспанія): 6 000 000 € стягнуто через недостатню правову підставу для обробки даних.
  • Banco Bilbao Vizcaya Argentaria, S.A. (AEPD, Іспанія): 5 000 000 € стягнуто за відсутність достатньої правової підстави для обробки даних та ненадання адекватної інформації про обробку своїм клієнтам.

Ми Вам допоможемо із комплаєнсом

Для такої складної задачі, як комплаєнс із GDPR у контексті фінансових персональних даних, необхідні справжні професіонали з приватності. Такими є ми – Legal IT Group, із досвідом консультування, підготовки усієї необхідної документації та аудитом обробки даних для наших фінтех клієнтів.

Є запитання до юристів?
до 500 символів
Сталася помилка
Запит надіслано Дякуємо за ваше повідомлення! Ми обробимо його якнайшвидше.

Статті по темі

Перейти до блогу