Открыть меню

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

Создано 28 мая 2026 г. Обновлено 28 мая 2026 г. 3 мин чтения

Как определить критерии регистрации событий операционного риска по 716-П: пороги, подход за пределами бухгалтерского убытка, роль ИБ- и ИС-событий.

Актуальность проверена: 2026-05-28

Кратко

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

Нормативная база

  • Положение Банка России № 716-П от 08.04.2020.
  • Ответы Банка России по 716-П о порогах и классификации событий.

Суть требования

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

Практическое значение для банка

  • Владелец процесса должен иметь простое правило первичной передачи.
  • СУР должна иметь право запросить уточнения и переквалифицировать событие.
  • ИТ и ИБ должны передавать события по отдельным каналам и классификаторам.
  • Претензионные и юридические подразделения должны передавать события с правовым эффектом.
  • Бухгалтерия должна подтверждать финансовую сторону, но не быть единственным фильтром.

Типовые ситуации

  • Сбой без потерь, но с простоем критичного процесса.
  • Компенсация клиенту без признания вины банка.
  • Ошибка документа, исправленная до отправки клиенту.
  • Потенциальный штраф, по которому еще нет решения регулятора.
  • Однотипные ошибки в серии операций.

Что должен сделать банк

  • Утвердить критерии регистрации и исключения.
  • Определить материальные и нематериальные пороги.
  • Описать события с потерями, без потерь и с потенциальными потерями.
  • Настроить каналы передачи от ИТ, ИБ, бухгалтерии, претензий и юристов.
  • Установить порядок спорной квалификации.
  • Регулярно анализировать пропуски и ложные срабатывания.

Риски неправильного применения

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

Связанные заметки

Вопросы для самопроверки

  1. Есть ли в банке порог регистрации событий без потерь?
  2. Кто принимает решение по спорному событию?
  3. Регистрируются ли потенциальные штрафы?
  4. Как учитываются массовые однотипные ошибки?
  5. Какие источники событий сверяются с базой?

Источники

Живой сад

Этот текст можно улучшать вместе

Нашёл опечатку?

Выдели фрагмент в заметке и нажми «Сообщить» — откроется короткая форма с контекстом.

Хочешь обсудить?

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

Telegram-комментарии

Добавь `telegramPostId` в публичную заметку, чтобы здесь появился виджет обсуждения.

Источник: публичный слой Obsidian Vault.