Ланселот: Управление операционными
рисками по 744-П ЦБ РФ База событий, расчёт и отчётность
Запросить демонстрациюДемонстрация

База событий операционного риска

Карточка события: из чего она состоит

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

  • 90атрибутов в карточке события
  • 10разделов карточки, каждый — под отдельным разрешением
  • 9разрезов классификации одного события
  • 5связанных реестров: потери, возмещения, проводки, мероприятия, вложения
Реестр событий и карточка события Пример заполнения

Таблица листается вбок — колонок больше, чем помещается на экране.

Номер Дата выявления Краткое описание Подразделение выявления Статус события Сумма потерь, ₽ Статус для расчёта 744-П
00041218.02.2026 Двойное списание комиссии по переводу Подразделение 1 Готово для второй валидации 420 000,00Не исключен из расчёта 744-П
00041116.02.2026 Сбой платёжного шлюза, задержка расчётов Подразделение 2 На редактировании 1 250 000,00Не исключен из расчёта 744-П
00041011.02.2026 Ошибка в расчёте вознаграждения по договору Подразделение 1 Качество проверено 96 000,00Отправлено на исключение в Банк России
00040904.02.2026 Утрата документа при передаче в архив Подразделение 3 Закрыто 0,00Исключен из расчёта 744-П
00040829.01.2026 Некорректная выгрузка тарифов в канал самообслуживания Подразделение 2 На отмену 310 000,00Не исключен из расчёта 744-П

Набор колонок, их подписи, ширина, порядок и сортировка — это представление реестра: базовое общее или собственное пользовательское.

Состав колонок, разделов и статусов — как в продукте; значения в строках подставлены для показа.

Десять разделов карточки, каждый под своим разрешением

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

Описание и классификация 3 раздела
  • Описание события: даты выявления, реализации и окончания, подразделения возникновения и выявления, краткое и подробное описание
  • Классификация: продукты, процессы, типы события, виды и источники риска
  • Источники события
Деньги 2 раздела
  • Последствия: потери с типом, видом, резервом, датой, суммой и связанной проводкой
  • Возмещения: тип, вид, источник, третье лицо, сумма, дата и связанная проводка
Работа по событию 3 раздела
  • Решение и контрольные мероприятия
  • Связанные риски
  • Признаки недобросовестных действий
След 2 раздела
  • Чат по событию
  • История изменений

Разделы карточки события, карточки риска и карточки КИР объявлены типами объектов защиты: разрешение выдаётся на чтение и на запись отдельно.

Многомерная классификация события

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

  • Направление деятельности Разрез, по которому события ложатся в отчётность 716-П и в расчёт долей ELOR.
  • Бизнес-процесс До четырёх уровней процесса с весом: событие делится между процессами, а не приписывается одному.
  • Продукт До трёх продуктов на событие плюс тип клиента.
  • Тип события Классификатор типов с весом — основа разбора «какие ошибки повторяются».
  • Вид риска Вид риска с весом и связь с другим видом риска.
  • Источник (фактор) риска До трёх источников с весом и текстовым описанием источника.
  • Вид потерь Разрез, по которому потери раскладываются в отчётных формах.
  • Бизнес-колонка Разрез управленческой отчётности организации.
  • Классификация процесса Отдельная привязка события к классификатору процессов.

Три категории события: операционный риск, ИТ и информационная безопасность

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

Веса вместо спора о том, чей это процесс

В каждом разрезе, где событие относится сразу к нескольким значениям, проставляется вес в процентах. Одна и та же сумма потерь корректно раскладывается по процессам, типам событий, видам риска, ИТ-системам, технологическим процессам и поставщикам — и не задваивается при суммировании.

Потери, возмещения и чистые потери

Потери и возмещения — не два поля в карточке, а два связанных реестра с привязкой к проводкам учётной системы. Из них считаются чистые потери, и на защите расчёта перед проверкой вопрос «откуда эта цифра» закрывается ссылкой на конкретную проводку.

Потеря

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

Каждая потеря сопоставляется с проводкой: счёт, дата, референс, сумма в рублях и в валюте.

Возмещение

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

Расформирование резерва — отдельный тип возмещения: именно по нему система понимает, что резерв закрыт.

Проводка учётной системы — самостоятельная сущность на 25 атрибутов, и она загружается импортом. Поэтому связка «событие → потеря → проводка» проверяема в обе стороны: от суммы в отчёте до строки в учёте и обратно.

Что дальше происходит с этими суммами

  • Чистые потери по событию и по группе событий сравниваются с порогом включения в расчёт средних чистых потерь — как устроен порог.
  • Возмещения относятся к прямым потерям по методу FIFO и дисконтируются по эффективной процентной ставке — методика отнесения.
  • Остаток нерасформированного резерва блокирует закрытие события — контроль резервов.
  • Суммы попадают в форму 0409106 и в отчётность 716-П без ручного переноса — отчётность в Банк России.

Контрольные мероприятия по событию

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

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

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

Вложения и обсуждение события

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

Файлы при событии и при мероприятии

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

Чат по событию

Обсуждение ведётся внутри карточки, участники получают уведомление о новом комментарии. Аргумент «мы это обсуждали в почте» перестаёт быть аргументом: обсуждение — часть записи, и оно видно тому, у кого есть разрешение на этот раздел карточки.

Группы связанных событий

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

Группа в расчёте

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

Группа в контроле отмен

Отмена события с потерями от 350 000 ₽ или события из группы, где связанных событий больше десяти, уходит уведомлением первому и второму валидатору. Крупное или массовое событие нельзя тихо отменить в конце квартала.

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

История изменений на уровне поля

Система пишет не «карточка изменена», а «такого-то числа такой-то сотрудник изменил такое-то поле с такого значения на такое». Это тот уровень детализации, на котором разговор с проверяющим и со службой внутреннего аудита заканчивается, а не начинается.

Раздел «История изменений» карточки события Пример заполнения
Дата изменения Сотрудник Поле Старое значение Новое значение
19.02.2026 10:14:22Сотрудник 1Сумма потерь, ₽96 000,00420 000,00
19.02.2026 10:15:07Сотрудник 1Тип события—Тип события 2
19.02.2026 12:02:41Сотрудник 2Статус событияНа регистрацииГотово для первой валидации
20.02.2026 09:31:56Сотрудник 3Подразделение возникновенияПодразделение 2Подразделение 1

Состав колонок истории — как в продукте: дата, сотрудник, поле, старое и новое значение.

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

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

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

Модель данных описана данными

227 определений сущностей, 223 из них с локализованными названиями, 521 код атрибутов и 1522 связи «сущность — атрибут». Модель разложена по 13 схемам базы данных; декларативно создаётся 177 таблиц.

Источник — метаданные и миграции продукта.

Схема разворачивается миграциями

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

Реестры настраиваются без разработки

Представление реестра задаёт набор колонок, подпись, шаблон значения, ширину, порядок и сортировку. Базовые и пользовательские представления — разные объекты защиты: общий вид реестра меняет администратор, свой — сам сотрудник.

Файлы — вне базы

Вложения хранятся в S3-совместимом объектном хранилище с настраиваемым бакетом и глубиной каталогов. База данных остаётся компактной, а политику хранения файлов задаёт площадка.

Состав модулей, интеграции и требования к площадке — на странице архитектуры и внедрения.

Показать карточку события на ваших данных

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

Запросить демонстрацию Требования к развёртыванию