Регуляторные технические стандарты оценки моделирования операционного риска

3 июня 2015 г. Европейский орган банковского надзора (European Banking Authority) выпустил стандарты по использованию ЛМЛ-подхода для операционных рисков («Final Draft RTS on AM A Assessment for Operational Risk»). В данном документе определены границы между операционным и другими рисками, изложены основные принципы управления операционными рисками, а также стандарты качества данных по операционным рискам, используемых ИТ-систем, требования к данным, используемым для моделирования.

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

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

не нарушать правила в БД, которые должны периодически проверяться.

• 3. Имеется соответствующая документация по организации и ведению баз данных:
  • — общая карта баз данных вовлеченных в систему управления ОР с их описанием;
  • — политика по данным и документация, закрепляющая ответственность подразделений;
  • — описание рабочих процессов по сбору и хранению данных;
  • — описание слабых мест, выявленных в базах данных в процессе валидации и пересмотра, и описание, как банк планирует их устранять.
• 4. Документы по планированию, созданию, тестированию и внедрению ИТ-инфраструктуры для АМА (далее — цикл) должны быть одобрены органом управления или высшим руководством банка.
• 5. Цикл должен удовлетворять лучшей практике для ИТ-систем в отношении:
  • — проектного менеджмента, риск-менеджмента и управления;
  • — выработки требований, контроля качества и планирования тестирований;
  • — моделирования и развития систем;
  • — контроля качества во всех направлениях, включая пересмотр кодов и, где применимо, верификацию кодов;
  • — тестирования, включая одобрение пользователем.
• 6. ИТ-инфрасгруктура, но АМА должна подвергаться управлению конфигурацией, изменениями и релизами.
• 7. Цикл и планы непрерывности по АМА должны быть одобрены органом управления или высшим руководством банка, и они должны быть периодически информированы о состоянии ИТ-инфраструктуры по АМА.

Под требованиями к данным, используемым для моделирования {"building the calculation data set"), имеются в виду следующие требования.

• 1. Банк должен использовать «валовые убытки» или «валовые убытки за вычетом возмещений» (кроме страховых возмещений). Банк не должен использовать «валовые убытки за вычетом страховых возмещений».
• 2. Банк должен использовать данные как минимум за пять лет (допускается использование данных за три года, если банк впервые использует АМА). Для тех категорий операционного риска, у которых низкая частота событий, необходимо использовать данные за больший период, чем за пять лет.
• 3. Для отбора данных банк должен использовать одну из двух отчетных дат: дату выявления события или дату бухгалтерского учета убытка от реализации события. Данная дата не может быть позже даты бухгалтерского учета убытков или резервов^[1], относящихся к правовому риску.
• 4. Банк может установить минимальные пороги моделирования для каждой категории операционного риска. Минимальный порог моделирования — это значение, начиная с которого распределения частоты и тяжести потерь «подгоняются» к данным, но убыткам. Желательно, чтобы он не сильно превышал минимальный порог для сбора событий, а если и сильно превышал, то это было бы обосновано.
• 5. Банк должен группировать связанные события операционного риска, вызванные одной причиной или событием {"root-event"), и регистрировать их как одно событие операционного риска. События, сгруппированные в одно событие, не вызванные одной причиной или событием, не могут быть включены в данные, используемые для моделирования.

• [1] Например, на счете 61 501.