Ланселот ПНИИИМР: Инциденты и риски Сквозной учёт от события ПНИИИМР до отчёта в надзорный орган
Запросить демонстрациюДемонстрация

События РР: маршрут от предсобытия до закрытия

Что такое событие РР

Событие регуляторного риска — первая запись в цепочке: сообщение о том, что что-то пошло не по регламенту в области ПНИИИМР (противодействие неправомерному использованию инсайдерской информации и манипулированию рынком, 224-ФЗ). Событие не теряется между «завели тикет» и «до кого-то дошло»: оно попадает в реестр riskReestr одним из двух путей — вручную кнопкой «Создать» в шапке или автоматически из письма в почтовый ящик риска — и с этой секунды у него есть статус, инициатор, автор и полная карточка с историей.

  • 24статуса маршрута события
  • 38переходов между статусами
  • 11вкладок в карточке
  • 35подписанных полей описания

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

Маршрут: статусы и переходы

Статусная модель RiskStatus проводит событие от первого сообщения до закрытия по 24 статусам и 38 переходам. Кнопки перехода в карточке строятся из статусов, доступных именно из текущего — сотрудник не может «перепрыгнуть» этап, которого не проходил.

Основной маршрут события РР Предсобытие, первичная валидация, учёт информации, квалификация события, оценка уровня риска, причины возникновения, закрытие; первичная валидация обменивается с запросом информации у инициатора; из квалификации доступен также выход «Закрыто. Не РР.»; закрытое событие переоткрывается. Предсобытие Первичная валидация Запрос информации у инициатора Учёт информации Квалификация события Закрыто. Не РР. Оценка уровня риска Причины возникновения Закрыто Переоткрыто

Упрощённая схема основного пути; полная модель — 38 переходов, включая ветку возврата к согласованию риск-менеджера/ИБ/ИТ/эксперта, достижимую из статуса «Переоткрыто». Состав статусов и переходов — как в продукте (RiskStatus.java).

Одна роль — один переход

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

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

Карточка события РР

11 вкладок карточки — не фиксированный набор полей, а зонирование доступа: видимость каждой вкладки определяется правом на соответствующий раздел (riskSection), причём базовое и полное описание — разные права. Порядок вкладок сотрудник настраивает перетаскиванием, и система запоминает его.

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

Файл с грифом «Ограниченный доступ» — не для всех, кто открыл карточку

Такие вложения видит и которыми управляет только тот, у кого есть отдельное право manageSecretFiles — доступ к карточке события не открывает доступ к секретным файлам автоматически.

Автоматическая регистрация из почты

Почтовый ящик риска проверяется каждую минуту (плюс однократно при старте приложения). Из темы и текста непрочитанного письма формируется описание, отправитель сопоставляется с сотрудником по внутреннему e-mail и становится инициатором и автором записи — карточку не нужно создавать вручную и переносить данные из письма руками.

Почтовый ящик риска → реестр событийПример заполнения
ИсточникПериодичностьРезультат
Письмо в почтовом ящике рискараз в минуту, плюс при стартеновая запись в статусе «Первичная валидация», письмо помечено прочитанным

Расписание и результат — как в продукте (RiskEmailSettings, RiskMailImporter).

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

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

  • Хранение — таблица dm.fact_risk в PostgreSQL, доступ через MyBatis-мапперы, без отдельной копии данных для витрины.
  • Видимость вкладки и раздела карточки регулируется правом на объект riskSection — базовое и полное описание разграничены отдельно.
  • Автоматическая регистрация из почты работает по протоколу IMAP; параметры ящика — часть конфигурации при внедрении, не константа в коде.
  • Файлы с грифом «Ограниченный доступ» управляются отдельным правом manageSecretFiles, не привязанным к правам на карточку.

Записаться на демонстрацию

Показать маршрут события РР на вашем стенде

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

Записаться на демонстрацию