Фреймворк операционного риска и инцидентов для PSP под надзором Банка Канады

Закон о розничных платёжных операциях (Retail Payment Activities Act, S.C. 2021, c. 23, s. 177) работает в два этапа. Регистрация PSP в Банке Канады началась 1 ноября 2024 года, а требования к фреймворкам управления риском и защите средств клиентов вступили в силу 8 сентября 2025 года.

Что должно быть в фреймворке

Статья 5 регламента перечисляет обязательные элементы:

• цели по целостности, конфиденциальности и доступности платёжных операций и измеримые цели надёжности с показателями;
• люди, бюджет и навыки, которые нужны для работы фреймворка;
• роли и ответственный старший руководитель (senior officer), который отвечает за выполнение статей 6–10;
• источники операционного риска, включая кибербезопасность, мошенничество, третьих лиц, изменения и непрерывность бизнеса;
• меры защиты, непрерывный мониторинг и план реагирования на инциденты и аномалии.

Все элементы соразмерны тому, какой ущерб сбой может нанести пользователям и другим участникам платёжной системы (ст. 5(2)).

Регламент задаёт ритм, по которому фреймворк живёт после утверждения:

• Утверждение. Старший руководитель и совет директоров, если он есть, утверждают фреймворк не реже раза в год и после каждого существенного изменения (ст. 5(6)).
• Пересмотр. Не реже раза в год и до существенного изменения PSP пересматривает фреймворк, фиксирует выводы и передаёт их руководителю (ст. 8).
• Тестирование. PSP сам задаёт методику, частоту и объём тестов, тестирует перед существенными изменениями и хранит записи (ст. 9).

Цели надёжности

Руководство Банка ожидает, что PSP устанавливает цели доступности систем и операций на уровне детализации, который подходит его модели. Чем шире PSP присутствует на рынке и чем больше он связан с другими участниками, тем строже должны быть цели. Мы подбираем показатели, которые вы реально измеряете.

Инцидентом закон называет незапланированное событие или серию событий, которые приводят или могут привести к снижению, ухудшению или прекращению платёжной операции (ст. 2 RPAA).

Что входит в уведомления

• Банку (ст. 11 регламента): через электронную систему Банка, с названием PSP, контактным лицом, описанием инцидента и его существенного влияния, принятыми мерами. После выяснения причины и последствий подаётся итоговое уведомление.
• Пользователям и партнёрам (ст. 12): каждому существенно затронутому лицу по последним контактам, а при их отсутствии публикация на сайте PSP. В тексте описание инцидента, последствий и мер, которые человек может принять сам.

План реагирования по ст. 5(1)(i) заранее назначает, кто эскалирует, расследует причину, сдерживает ущерб, сообщает участникам и отслеживает статус транзакций. Если инцидент затронул и персональные данные, параллельно действуют правила PIPEDA; этот сценарий разбираем на странице реагирование на инциденты.

Поставщики и агенты

Облачный хостинг, процессинг, KYC-сервис, служба поддержки на аутсорсе: каждый такой поставщик попадает в оценку. Для агентов и представителей PSP устанавливает критерии управления операционным риском и тоже проверяет их ежегодно (ст. 5(4)).

Кто проводит независимую проверку

Руководство Банка уточняет: требование касается PSP, у которых есть внутренний или внешний аудитор, то есть регулярно пользуются услугами аудитора; разовое привлечение аудитора для отдельной проверки требование не включает. Проверяющий должен обладать нужной квалификацией и не участвовать в создании, внедрении и поддержке фреймворка. Им может быть сотрудник PSP или внешняя сторона. Результаты сертификационного или иного аудита засчитываются, если PSP письменно покажет, что их объём покрывает требования регламента.

Если фреймворк готовили мы, независимую проверку того же фреймворка проводит другая сторона. Мы готовим к ней документы и доказательства.

1. Карта операций. Какие из пяти платёжных функций, перечисленных в ст. 2 RPAA, вы выполняете, на каких системах, с какими поставщиками и агентами.
2. Разрывы. Сравниваем то, что есть, со статьями 5–10 регламента и руководством Банка, отмечаем, что закрыть до ближайшего отчёта.
3. Документы. Фреймворк, цели надёжности и показатели, план реагирования на инциденты, реестр поставщиков с оценками, методика тестирования, график пересмотров.
4. Исправления. Доступы, MFA, резервные копии с проверкой восстановления, журналы событий. Техническую часть в Канаде может выполнять itopsi.com, ИТ-бренд группы.
5. Учения. Проводим настольное учение по плану инцидентов и правим план по итогам.

Вопросы регистрации и лицензий группы ведёт наша практика лицензирования.