Комплаенс в финтехе: мой опыт работы с нормативкой

Когда я начал работать в финтехе, первым делом нужно было разобраться: какие требования к нам применимы? Оказалось, нормативки немало, и каждая требует своего подхода.

Расскажу о регуляторных требованиях, с которыми я работал, и как выстраивал систему комплаенса. Это личный опыт, не официальное руководство.

С чего начал

В компании уже была база по ИБ, но фрагментарная: что-то внедрили здесь, что-то закрыли там. Системного подхода не было.

Первым делом составил список всех применимых требований. Тут и началось самое интересное.

Нормативка Банка России

Банк России — главный регулятор для финансовых организаций. Требования серьёзные, но если разобраться — логичные.

Положение № 683-П

Ключевое положение о защите информации при банковской деятельности. Цель — предотвратить несанкционированные переводы денег.

Основные требования:

• Система защиты информации
• Контроль доступа к банковским системам
• Мониторинг и реагирование на инциденты
• Регулярные проверки и аудиты

Требования детальные, но на практике каждая мера находит применение.

Положение № 787-П

Требования к защите информации в платёжной системе ЦБ. Фокус на защите платёжных данных и непрерывности процессов.

Положение № 821-П

Порядок защиты информации при переводах денег. Детально описана защита на каждом этапе обработки платежей.

При внедрении пришлось плотно работать с разработчиками — многие требования закладываются на уровне архитектуры.

СТО БР БФБО-1.8-2024

Стандарт о безопасности при дистанционной идентификации и аутентификации. Актуален для онлайн-банкинга и дистанционного обслуживания.

Упор на защиту от мошенничества при идентификации клиентов.

СТО БР ИББС

Комплексный стандарт по информационной безопасности банковских систем:

• Управление рисками ИБ
• Защита информации на всех уровнях
• Инцидент-менеджмент
• Безопасность разработки

Это целая система, а не просто набор требований. Нужно выстраивать процессы, настраивать мониторинг, обучать людей.

ГОСТ Р 57580.1-2017: базовые меры защиты

Стандарт «Безопасность финансовых операций. Защита информации финансовых организаций» определяет базовый состав организационных и технических мер.

Уровни защиты

Стандарт определяет несколько уровней защиты с разными требованиями. Нужно определить применимый уровень для компании.

Для этого анализируется: объём данных, критичность систем, риски. Это не быстро, но без этого анализа двигаться нельзя.

Организационные и технические меры

Стандарт описывает систему взаимосвязанных требований.

Организационные меры:

• Назначение ответственных
• Политики и процедуры
• Обучение персонала
• Контроль и мониторинг

Технические меры:

• Средства защиты информации
• Контроль доступа
• Мониторинг
• Резервное копирование

Важно: меры должны работать вместе. Нельзя внедрить только технические или только организационные.

Выбор мер защиты

Не всё нужно внедрять сразу. Сначала оценить риски, затем выбрать адекватные меры. Это позволяет не делать избыточных вложений при необходимом уровне защиты.

Полнота реализации

Меры должны быть реализованы полностью. Формально создать политику — не значит защититься. Лучше сделать меньше, но качественно.

Защита на всех этапах жизненного цикла

Стандарт требует защиту на всех этапах: от проектирования до вывода из эксплуатации.

Это означает тесную работу с разработкой: внедрение практик безопасной разработки, анализ кода, тестирование защиты.

Одно из самых сложных направлений — разработчики привыкли фокусироваться на функциональности. Но постепенно безопасность становится частью культуры.

PCI DSS: работа с картами

Международный стандарт для тех, кто обрабатывает платёжные карты. Требования жёсткие, но логичные:

• Защита периметра — файрволы, сегментация сетей
• Защита данных — шифрование, ограничение хранения
• Управление доступом — строгий контроль прав
• Мониторинг — отслеживание действий с данными карт
• Тестирование — регулярные проверки уязвимостей
• Политики — документирование процессов

Самое сложное — ограничение хранения данных. Нельзя хранить полные номера карт и CVV дольше необходимого. Пришлось переделывать часть системы.

Но когда всё работает — становится спокойнее. Данные защищены, мониторинг настроен, система устойчива.

152-ФЗ: персональные данные

Закон о персональных данных актуален для всех, кто их обрабатывает. В финтехе особенно важен — работаем с финансовыми данными клиентов.

Основные требования:

• Получение согласия на обработку
• Обеспечение безопасности
• Уведомление регулятора
• Права субъектов данных

Требования базовые, но нужно выполнять качественно. Важно реально защитить данные, а не формально.

Как строил систему комплаенса

Разобравшись с требованиями, начал практическую работу. Не пытался закрыть всё сразу — составил план.

Этап 1: Аудит

Провёл аудит текущего состояния: что есть, что работает, что только на бумаге. Это заняло месяц.

Оказалось, часть требований выполнена, но не системно. Меры для одного требования не использовались для другого. Нужна унификация.

Этап 2: Приоритизация

Определил приоритеты:

• Критичные — могут привести к остановке деятельности или штрафам
• Высокие — влияют на репутацию и доверие клиентов
• Средние и низкие — по остаточному принципу

Этап 3: Внедрение

Начал внедрять постепенно. Сначала базовые меры, которые закрывают несколько требований. Потом специфичные.

Важно: не делать «для галочки». Каждая мера должна реально работать.

Этап 4: Обучение

Самое важное — обучение сотрудников. Без понимания «зачем» система не работает.

Проводил обучение для разных групп: разработчики, операторы, менеджмент. Для каждой — свой подход.

Результат

Через полгода была система комплаенса, которая реально работала. Не идеальная, но рабочая:

• Критичные требования закрыты
• Процессы настроены
• Люди понимают, что и зачем делают

Главное — система не формальная. Каждая мера имеет практическое применение. Результат заметен: инциденты снизились, проверки проходят успешно.

Основные выводы

Не бойтесь нормативки
Требования кажутся сложными, но они логичны. Каждое решает конкретную задачу.

Системный подход критичен
Нельзя закрывать требования по отдельности. Одна мера может закрывать несколько требований.

Практика важнее теории
Можно написать кучу документов, но если они не работают — это бесполезно. Лучше меньше, но качественно.

Коммуникация важна
Объясняйте людям «зачем». Когда понимают цель — лучше выполняют.

Комплаенс — процесс
Не разовое мероприятие. Нужно постоянно мониторить, улучшать, адаптироваться.

Заключение

Нормативка постоянно обновляется — нужно следить за изменениями и адаптировать систему.

Если начинаете работать с комплаенсом в финтехе: изучите требования, проведите аудит, определите приоритеты. Двигайтесь постепенно.

В следующей статье расскажу о практических кейсах внедрения стандартов ИБ.