Федеральный закон от 27.07.2010 № 224-ФЗ, статья 11, часть 2

Правила внутреннего контроля по инсайдерской информации, которые исполняются системой

Часть 2 статьи 11 224-ФЗ требует не только разработать и утвердить правила внутреннего контроля, но и обеспечивать их выполнение. Разница между папкой с утверждённым документом и исполняемой процедурой — это то, что спрашивают при проверке: не текст правил, а подтверждение, что описанный в них порядок отработал на конкретном сообщении, в конкретный день, конкретным сотрудником.

Продукт превращает процедурную часть правил в маршрут, который нельзя обойти: 24 статуса, 38 переходов, отдельное разрешение на каждый переход, непустой комментарий на 25 переходах из 38 и протокол смены статусов с датой, временем, фамилией и комментарием. За неисполнение обязанностей по принятию мер, направленных на предотвращение, выявление и пресечение злоупотреблений на финансовых и товарных рынках, частью 4 статьи 15.35 КоАП РФ установлен штраф на должностных лиц от 20 000 до 30 000 рублей либо дисквалификация на срок до одного года, на юридических лиц — от 300 000 до 700 000 рублей.

Перейти к разделу

Маршрут события: что происходит с сообщением о возможном нарушении

Сообщение может прийти от работника, из почтового ящика или быть заведено вручную. Дальше оно движется по одному и тому же маршруту независимо от источника. Ниже — триажный участок, на котором решается судьба сообщения: относится оно к регуляторному риску или нет.

Текстовая запись того же маршрута: «Предсобытие» → «Первичная валидация» → при необходимости «Запрос информации у инициатора» → «Информация по запросу предоставлена» → снова «Первичная валидация» → «Учёт информации о Событии РР» → «Квалификация события» → либо «Закрыто. Не РР.», либо «Анализ: Оценка уровня риска» → «Анализ: Причины возникновения» → «Закрыто». На узком экране схема прокручивается по горизонтали; текстовая запись выше передаёт тот же маршрут полностью.

Сообщение принято Событие создаётся в статусе «Предсобытие» при ручном вводе либо сразу в «Первичной валидации» при поступлении из почтового ящика. В обоих случаях оно попало в реестр и уже не может исчезнуть незамеченным.
Первичная оценка На первичной валидации решается, хватает ли сведений. Не хватает — уходит запрос инициатору с установленной датой ответа; после ответа событие возвращается на ту же первичную валидацию, а не проскакивает вперёд.
Квалификация Событие либо признаётся не относящимся к регуляторному риску и закрывается со статусом «Закрыто. Не РР.», либо уходит в анализ. Оба исхода остаются в протоколе — «тихо не заметить» сообщение нельзя.
Анализ и согласование Оценивается уровень риска и устанавливаются причины. После верификации руководителем событие расходится на три независимые ветви — СПНП, информационная безопасность, информационные технологии.
Финальное согласование Только после согласования СПНП событие уходит эксперту. Эксперт закрывает его, отправляет в черновик или возвращает СПНП — и каждый из этих переходов требует непустого комментария.

Все 24 статуса и 38 переходов: посмотрите любой

Статусная модель — не картинка в презентации, а работающее ограничение: система разрешает ровно те переходы, которые в ней перечислены. Выберите статус, чтобы увидеть, куда из него можно уйти, откуда в него приходят и требуется ли на переходе непустой комментарий. Список работает с клавиатуры: перемещение табуляцией, выбор — пробелом или вводом.

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

Итог по модели: 24 статуса, 38 переходов, 25 переходов требуют непустого комментария, 13 — не требуют. У закрытого события остаётся выход в «Переоткрыто»: маршрут возобновляется, если появились новые сведения.

Запрет обхода первичной валидации: сообщение не попадёт в согласование напрямую

Риск, который это снимает. Классический способ похоронить неудобное сообщение — провести его мимо оценки: завести карточку и сразу отправить её «на согласование», где она растворится среди штатных задач. Проверка вскроет это по протоколу мгновенно, и объяснить, почему сообщение о возможном нарушении не проходило первичную оценку, будет нечем.

Как устроено. Из статуса «Предсобытие» в модели есть ровно один выход — «Первичная валидация». Прямой переход из предсобытия в согласование руководителю в маршруте отсутствует: он выключен в самой модели, а не спрятан за настройкой прав, которую можно тихо поправить. Тот же эффект работает и для внешнего канала: событие, созданное из письма, попадает сразу в «Первичную валидацию».

Что из этого следует для проверки

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

Право на каждый переход — отдельное разрешение, а не общая роль «согласующий»

Риск, который это снимает. Когда право на движение по процессу выдаётся «на систему целиком», один человек с широкой ролью проводит событие от приёма до закрытия. Разделение обязанностей, описанное в правилах внутреннего контроля, при этом существует только на бумаге.

Как устроено. Статусная модель — самостоятельный тип защищаемого объекта, а право на переход выдаётся действием «выполнение» на конкретный целевой статус. Кнопка перехода, на который у сотрудника нет права, просто не появляется: интерфейс собирается из того, что человеку разрешено, а не прячет запрещённое за сообщением об ошибке.

Как это проектируется при внедрении

Право выдаётся на целевой статус: сотрудник получает разрешение переводить событие в конкретное состояние — например, в «Верифицировано». На стыках ветвей маршрута ставятся разные целевые статусы, и матрица доступа строится вокруг них.

Обязательный комментарий: решение нельзя принять молча

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

Как устроено. 25 переходов из 38 открывают форму с полем «Комментарий» и ограничением «не пусто»: пустым его оставить нельзя, переход не выполнится. Комментарий попадает в протокол смены статусов вместе с датой, временем и фамилией.

Разделение полномочий заложено в конструкцию маршрута

Риск, который это снимает. Внутренний фрод и обыкновенная халатность выглядят одинаково: событие прошло согласование, но фактически его никто не смотрел. Защита здесь не в регламенте, а в том, что маршрут физически требует нескольких независимых участников.

Как устроено. После верификации событие расходится на три параллельные ветви — СПНП, информационная безопасность, информационные технологии; ветви ИБ и ИТ включаются признаками самого события. Только после согласования СПНП событие уходит на финальное согласование эксперту. Возврат по маршруту тоже формализован: есть явные статусы «Возврат руководителю» и «Возврат СПНП», а не «отправить назад» без следа.

Верифицировано → (СПНП | Менеджер риска ИБ | Менеджер риска ИТ) → Согласовать СПНП → Передано на согласование риск эксперту → Закрыто

Как назначаются роли ветвей

Права нескольких ролей объединяются по «или», поэтому состав ролей у каждого сотрудника закрепляется матрицей доступа: ветви СПНП, информационной безопасности и информационных технологий раздаются разным субъектам, и на демонстрации это проверяется за одну минуту.

Протокол смены статусов: доказательство исполнения, а не рассказ о нём

Риск, который это снимает. На запрос регулятора о том, как рассматривалось конкретное сообщение, обычно отвечают выборкой из переписки, собранной вручную за несколько дней. Протокол смены статусов отвечает на тот же вопрос выгрузкой из карточки.

Протокол ведётся по каждому событию и содержит дату и время, старый статус, новый статус, фамилию сотрудника и комментарий. Ниже — как это выглядит на экране.

События РР · Карточка события · Протокол смены статусов Пример заполнения

Событие РР-2026-0148 · Передача материалов по непубличной сделке во внешний адрес

Передано на согласование риск эксперту Событие является Регуляторным риском в области ПНИИИМР: ДА

Протокол смены статусов события — пример заполнения интерфейса
Дата и время	Из статуса	В статус	Сотрудник	Комментарий
12.08.2026 09:41	—	Первичная валидация	Создано из почтового ящика	—
12.08.2026 11:05	Первичная валидация	Запрос информации у инициатора	Сотрудник СПНП	—
13.08.2026 15:02	Запрос информации у инициатора	Информация по запросу предоставлена	Сотрудник	—
13.08.2026 16:22	Информация по запросу предоставлена	Первичная валидация	Сотрудник СПНП	—
14.08.2026 10:10	Квалификация события	Анализ: Оценка уровня риска	Руководитель	—
17.08.2026 12:48	Верифицировано	Передано на согласование СПНП	Руководитель	—
19.08.2026 09:30	Передано на согласование СПНП	Согласовать СПНП	Сотрудник СПНП	Круг лиц, имевших доступ, установлен; основание передачи выясняется
19.08.2026 17:14	Согласовать СПНП	Передано на согласование риск эксперту	Сотрудник СПНП	Направлено на финальное согласование

Интерфейс системы. Прочерк в колонке «Комментарий» стоит там, где переход комментария не требует, — это те самые 13 переходов из 38.

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

Предохранитель: система сама сообщает, что событие останется без рассмотрения

Риск, который это снимает. Самый незаметный сбой контроля — обрыв маршрута согласования: сотрудник уволился, роль сняли, права переназначили, и событие ушло в статус, к которому ни у кого нет доступа. Формально процедура соблюдена, фактически событие лежит.

Как устроено. Если следующий статус недоступен ни одному пользователю системы, рассылается предупреждение: событие в этом статусе никем не будет обработано. Это редкий механизм — обычно системы согласования молчат до тех пор, пока кто-нибудь не хватится.

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

Канал приёма сообщений, который нельзя обойти

Риск, который это снимает. Сообщение о возможном нарушении чаще всего приходит письмом — и там же заканчивается: адресат в отпуске, письмо утонуло в переписке, срок пошёл, но никто его не считает.

Как устроено. Система раз в минуту опрашивает выделенный почтовый ящик, читает непрочитанные письма и создаёт по ним события. Тема и тело письма складываются в описание, адрес отправителя сопоставляется с сотрудником по служебному адресу электронной почты, и, если сотрудник найден, он проставляется инициатором и автором. Письмо помечается прочитанным только после успешного создания события — то есть сбой не «съедает» обращение. Событие всегда создаётся в статусе «Первичная валидация»: внешний канал не даёт обойти триаж.

Периодичность опроса ящика

раз в минуту, безусловно

Статус созданного события

«Первичная валидация»

Сопоставление отправителя

по служебному адресу электронной почты сотрудника; если сотрудник не найден, инициатор и автор остаются пустыми

Ошибка обработки письма

не прерывает цикл: остальные письма обрабатываются

Роли маршрута и подразделения заказчика

Роли в продукте названы так, как они называются в интерфейсе. Ниже — подсказка, какому подразделению они обычно соответствуют. Это методический ориентир для сопоставления с вашей оргструктурой, а не свойство системы: соответствие ролей подразделениям определяет сама организация в матрице доступа.

Роли контрольного контура и их место в маршруте события
Роль в системе	Что делает в маршруте	Обычно это подразделение
Сотрудник	Заводит предсобытие и отвечает на запросы информации. При единственной этой роли реестр открывается в урезанном представлении.	Работник любого подразделения, обнаруживший событие
Руководитель	Верифицирует событие и раздаёт его по ветвям; принимает возвраты.	Руководитель подразделения, в котором произошло событие
Сотрудник СПНП	Ведёт триажный участок и содержательную часть разбора; согласует событие перед передачей эксперту.	Подразделение, ведущее регуляторный риск и комплаенс
Менеджер риска ИБ	Отдельная ветвь согласования по признакам события.	Служба информационной безопасности
Менеджер риска ИТ	Отдельная ветвь согласования по признакам события.	Подразделение информационных технологий
Эксперт ПНИИИМР	Финальное согласование: закрытие, возврат СПНП или отправка в черновик.	Ответственное должностное лицо по части 1 статьи 11 224-ФЗ либо подчинённое ему подразделение
Сотрудник СВК	Наблюдение за процессом в объёме выданных прав.	Служба внутреннего контроля
Аудитор	Чтение событий и протоколов в объёме выданных прав.	Служба внутреннего аудита

Роль администратора безопасности и ещё семь прикладных ролей помечены системными: их нельзя отредактировать или удалить из интерфейса — ролевая матрица защищена от случайной правки. Роль «Эксперт ПНИИИМР» остаётся редактируемой, чтобы её состав прав настраивался под правила организации.

Что это даёт ИТ-директору

Процесс описан данными, а не кодом на стороне заказчика. Статусная модель, состав переходов и требование комментария заданы в самой модели; настройка прав на переходы выполняется в консоли администрирования, а не доработкой.
Состав модуля понятен. Маршрут события регуляторного риска — один модуль; события операционного риска ведёт та же машина статусов в своей модели. Это одна кодовая база и одна модель доступа, а не два продукта.
Приём сообщений не требует интеграционной шины. Достаточно выделенного почтового ящика: опрос по протоколу IMAP выполняется самим приложением.
Диагностируемость. Предупреждение о недоступном следующем статусе и протокол смены статусов дают понятную картину, когда процесс встал, — без разбора логов приложения.

Варианты развёртывания — в закрытом контуре организации или в частном облаке — и требования к инфраструктуре подтверждает поставщик на этапе пилота.

Куда идти дальше

На чём основана разработка

Продукт предоставляет инструменты, которыми организация исполняет процедуры своих правил внутреннего контроля, и оставляет доказательство их исполнения для ответственного должностного лица. Разработано с учётом требований статьи 11 Федерального закона № 224-ФЗ, Указания Банка России № 5222-У и Методических рекомендаций № 23-МР.

Статусная модель универсальна: тот же механизм обслуживает и события операционного риска — это одна кодовая база и одна модель доступа. Специфика ПНИИИМР задаётся наименованиями реквизитов карточки, классификацией и настройкой прав.
Маршрут настраивается под утверждённые правила внутреннего контроля: ответственное должностное лицо задаёт, кто и какой переход вправе выполнить, и закрепляет это в матрице доступа.

Смежные разделы: карта «требование ↔ функция» по статье 11 224-ФЗ показывает, какое место эта процедура занимает среди остальных обязанностей; порядок доступа и охрана конфиденциальности — как устроены права, на которых держится маршрут; рабочее место ответственного должностного лица — как этим маршрутом управляют каждый день; контур комплаенса — как система встраивается в работу банка.

Посмотреть маршрут на стенде Цена вопроса: статья 15.35 КоАП РФ