FinTech-платформа почти неизбежно обрабатывает персональные данные.
Даже если продукт работает преимущественно с юридическими лицами, в его процессах появляются сведения о представителях компаний, инвесторах, заемщиках, сотрудниках, партнерах и подрядчиках.
Платформа получает данные через разные каналы:
— сайт и приложение;— личный кабинет;— заявки и формы обратной связи;— партнерские виджеты;— телефонные звонки;— сервисы идентификации;— CRM и аналитические системы;— API-интеграции.
По мере развития продукта количество участников, документов и технических связей растет. При этом юридическая модель часто остается на уровне первоначальной политики конфиденциальности и нескольких чекбоксов.
Именно здесь возникает основная проблема:
Документы формально существуют, но уже не описывают реальное движение данных внутри продукта.
Разберем, что стоит проверить FinTech-платформе, чтобы снизить риски и не создавать лишние препятствия для пользователей.
Начинать аудит лучше не с политики конфиденциальности.
Сначала нужно понять, как данные фактически перемещаются внутри продукта.
Для каждой точки сбора зафиксируйте:
— какие сведения получает компания;— от кого они поступают;— куда передаются;— для какой цели используются;— кто определяет цель и состав обработки;— на каком правовом основании ведется обработка;— какой документ описывает этот процесс.
Например, пользователь заполняет форму на сайте партнера. После этого данные:
Одна форма может запускать несколько самостоятельных процессов обработки.
Если смотреть только на чекбокс под формой, эту цепочку невозможно увидеть.
Карта потоков позволяет обнаружить:
— лишние передачи;— процессы без понятного основания;— подрядчиков, не включенных в документы;— дублирующие согласия;— случаи, когда платформа ошибочно принимает на себя роль оператора.
На вебинаре мы отдельно показывали, почему обычного чек-листа «политика есть, согласие есть» для платформенного бизнеса недостаточно. Нужно проверять не наличие документа, а его соответствие реальному движению информации.
В многостороннем цифровом продукте одна компания не всегда играет одинаковую роль во всех процессах.
Оператором персональных данных является тот, кто определяет:
— цель обработки;— состав данных;— действия, совершаемые с ними.
Сам по себе факт, что сведения проходят через интерфейс или сервер платформы, еще не делает владельца платформы оператором во всех случаях.
Компания может быть:
— оператором в отношениях со своими пользователями;— обработчиком по поручению банка, лизингодателя или эмитента;— самостоятельным оператором в маркетинговых коммуникациях;— обработчиком при техническом хранении или передаче сведений.
Это важно не только для документов.
От роли зависит, кто должен:
— собирать согласия;— отвечать на запросы субъектов;— уведомлять Роскомнадзор;— обеспечивать безопасность данных;— нести ответственность при нарушении.
Нередко аудит показывает, что платформа собирает согласие там, где она фактически действует по поручению другого оператора.
В результате пользователь получает дополнительный чекбокс, а компания — лишнюю ответственность.
Одна из самых распространенных ошибок — пытаться оформить через согласие всю обработку данных.
Логика понятна:
Чем больше согласий соберем, тем лучше будем защищены.
Но согласие не является универсальным юридическим щитом.
Для разных процессов могут применяться разные основания:
— исполнение договора;— исполнение требований закона;— осуществление прав и законных интересов;— обработка по поручению оператора;— отдельное согласие пользователя.
Например, проверка клиента по требованиям законодательства не должна зависеть от добровольного согласия.
Иначе возникает противоречие: пользователь может отказаться или отозвать согласие, а компания все равно обязана провести проверку.
То же относится к действиям, необходимым для исполнения договора.
Если обработка действительно нужна для предоставления сервиса, соответствующие условия можно закрепить в пользовательском соглашении или договоре. Отдельный чекбокс в такой ситуации может быть не только избыточным, но и юридически некорректным.
Согласие стоит использовать там, где нет другого подходящего основания.
Например:
— заказ обратного звонка;— публикация отзыва;— рекламная рассылка;— дополнительная маркетинговая коммуникация;— передача данных третьему лицу, не связанная с исполнением договора или закона.
Если согласие действительно необходимо, оно должно быть:
— конкретным;— предметным;— информированным;— добровольным;— подтверждаемым.
Одна цель — одно согласие.
Не стоит объединять в одну формулировку:
— пользовательское соглашение;— политику конфиденциальности;— согласие на обработку данных;— рекламную рассылку;— передачу партнерам.
Политика конфиденциальности — декларативный документ. Пользователя нужно с ней ознакомить, но формулировка «принимаю политику» обычно не решает самостоятельной юридической задачи.
Отдельно стоит проверить, не используются ли на сайте рискованные способы сбора данных:
Если галочка уже поставлена за пользователя, сложно говорить о его самостоятельном волеизъявлении.
Данные не должны попадать в CRM до того, как пользователь совершил действие, запускающее законную обработку.
Сам факт передачи базы знакомым предпринимателем или партнером не подтверждает наличие законного основания для обзвона и рассылки.
Согласие на обработку данных и согласие на рекламу — разные юридические действия.
При споре недостаточно показать, что на сайте сейчас есть чекбокс.
Нужно доказать, что конкретный пользователь:
— видел определенную версию текста;— дал согласие в конкретный момент;— совершил подтверждающее действие;— согласился именно с теми условиями, которые действовали в этот момент.
Поэтому согласия желательно логировать.
В системе можно фиксировать:
— дату и время;— идентификатор пользователя;— версию согласия;— страницу или форму;— совершенное действие;— IP-адрес и user agent;— результат SMS- или email-подтверждения.
Чем сложнее и рискованнее процесс, тем надежнее должен быть способ подтверждения.
Для разных продуктов могут использоваться:
— техническое логирование;— код из SMS;— подтверждение по электронной почте;— электронная подпись;— авторизация через допустимую российскую систему.
Главный принцип:
Оператор должен хранить не только текст согласия, но и доказательства его получения.
Минимальный набор документов и элементов зависит от продукта, но обычно стоит проверить:
— опубликована ли политика обработки персональных данных;— соответствует ли она реальным процессам;— есть ли пользовательское соглашение или оферта;— привязаны ли формы к подходящим основаниям;— опубликованы ли отдельные тексты согласий;— работает ли cookie-уведомление;— может ли пользователь отказаться от необязательных cookie;— указаны ли способы отзыва согласия;— доступны ли документы до отправки формы;— совпадает ли текст документа с интерфейсом.
Особое внимание нужно уделить формам, которые часто остаются вне основного аудита:
— заказ звонка;— регистрация на мероприятие;— заявка через виджет партнера;— отзыв;— форма поддержки;— реферальная ссылка;— заявка, которую вводит менеджер за клиента.
Каждая такая форма — самостоятельная точка сбора данных.
Современная платформа почти никогда не обрабатывает данные полностью самостоятельно.
В процессах участвуют:
— CRM;— хостинг;— облачная инфраструктура;— сервисы идентификации;— колл-центр;— email- и SMS-рассылки;— аналитические сервисы;— коллтрекинг;— сервисы электронной подписи;— подрядчики по технической поддержке;— банки и платежные сервисы.
Для каждого подрядчика нужно определить:
Отсутствие корректного поручения может привести к тому, что ответственность за действия подрядчика останется на компании, передавшей данные.
Кроме того, пользователь должен понимать, кому и для чего могут передаваться его сведения.
FinTech-продукты часто используют иностранную инфраструктуру, которая подключалась еще на раннем этапе развития бизнеса.
В архитектуре могут остаться:
— зарубежный хостинг;— иностранная аналитика;— зарубежные сервисы авторизации;— облачные базы данных;— инструменты маркетинга и рассылок.
Нужно проверить:
— где происходит первичная запись данных;— хранится ли основная база в России;— осуществляется ли трансграничная передача;— направлялось ли необходимое уведомление;— есть ли законное основание для использования конкретного сервиса.
Проблема в том, что подобные решения часто не видны юридической службе.
Их подключают разработчики или маркетологи, а информация о передаче данных появляется только во время технического аудита.
Комплаенс по персональным данным похож на пожарную безопасность.
Компания рассчитывает, что инцидента не будет. Но сотрудники должны знать, что делать, если он произошел.
Минимальный план должен включать:
— канал для сообщения об инциденте;— ответственных сотрудников;— порядок подключения юристов и IT-команды;— внутреннее расследование;— фиксацию времени обнаружения;— определение состава и количества данных;— проверку подрядчиков;— подготовку уведомления Роскомнадзора;— коммуникацию с пользователями;— сохранение доказательств предпринятых мер.
Первичное уведомление об инциденте направляется в течение 24 часов после того, как компании стало о нем известно.
После расследования в течение 72 часов направляется дополнительная информация о причинах, масштабе и принятых мерах.
Поэтому разрабатывать документы уже после обнаружения утечки поздно.
До инцидента должны быть готовы:
— регламент;— шаблоны сообщений;— список ответственных;— контакты подрядчиков;— сценарий расследования;— инструкция для сотрудников.
Результатом аудита не должна становиться только папка с политиками и согласиями.
Хороший проект включает:
— карту потоков данных;— распределение ролей;— перечень оснований обработки;— реестр подрядчиков и систем;— документы внешнего контура;— внутренние регламенты;— инструкции для разработчиков;— рекомендации по изменению интерфейсов;— план действий при инциденте;— обучение сотрудников.
Юридические документы должны быть связаны с конкретными элементами продукта.
Например:
— на этом экране разместить уведомление;— здесь убрать лишний чекбокс;— в этой форме добавить ссылку;— этот процесс перевести на договорное основание;— с этим сервисом подписать поручение;— в этой точке включить логирование.
Иначе документы быстро перестают соответствовать продукту.
Проверьте, можете ли вы уверенно ответить «да» на следующие вопросы:
Если несколько ответов вызывают сомнение, начинать стоит не с обновления политики, а с аудита всей системы.
Персональные данные на FinTech-платформе — это не отдельный юридический документ.
Это часть архитектуры продукта.
Правильно выстроенная модель помогает одновременно:
— снизить регуляторные риски;
— сократить количество лишних согласий;
— сделать путь пользователя понятнее;
— сохранить конверсию;
— безопасно подключать подрядчиков;
— быстрее запускать новые продукты и интеграции.
Юридическая чистота и удобство продукта здесь не противоречат друг другу.
Наоборот, часто именно юридический аудит показывает, какие процессы можно упростить — без нарушения закона и без потери клиентов.
Если хотите разобраться с ПДн в вашем проекте - напишите нам