Управление рисками предприятия на практике

Автор: Jonas Osman Abdelghafour — актуарий и специалист по финансовым рискам (FRM, GARP USA).

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

Этот материал собирает эти решения так, как я их вижу, с оглядкой на практиков, которым в один и тот же квартал нужно сделать ERM обоснованным перед советом директоров, регулятором и внутренним аудитором.

Отталкивайтесь от решений, а не от рисков

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

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

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

Аппетит к риску, который действует

Заявление об аппетите к риску стоит ровно столько, сколько решений оно останавливает. Если ничто и никогда не было отклонено из-за нарушения аппетита, заявление не откалибровано — это декорация. Три свойства отличают реальную систему аппетита от символической.

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

Заранее согласованная реакция при нарушении лимита. Наиболее распространённая слабость систем аппетита в том, что нарушение запускает обсуждение, а не действие. Согласуйте заранее: ниже X — мониторинг; между X и Y — план устранения в течение тридцати дней; выше Y — закрытие экспозиции. Советам директоров это неудобно, а менеджмент часто сопротивляется — именно поэтому это работает.

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

ORSA и её аналоги: принуждение к значимым сценариям

Собственная оценка рисков и платёжеспособности (ORSA) — один из наиболее ценных регуляторных инструментов, введённых Solvency II. Её ценность никак не связана с самим документом — она проистекает из выбранных сценариев и честности, с которой менеджмент в них вовлекается.

Полезная ORSA содержит три-четыре нарративных сценария, стресс-тестирующих конкретные уязвимости бизнеса, а не общие. Для монолайнового автостраховщика это сочетание инфляции тяжести убытков с законодательной реформой; для пенсионной схемы — долголетие плюс коллапс реальных ставок; для банка — шок качества активов в сочетании с оттоком депозитов. Копирование иллюстративных сценариев регулятора обесценивает упражнение.

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

Подробнее о построении сценариев и их использовании советом директоров я пишу в заметке о дизайне сценариев ORSA. Для финансовых организаций это связано с руководством по моделированию капитала, которое я использую с клиентами.

Проблема таксономии

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

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

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

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

Возникающие риски: выработайте привычку, а не реестр

В каждой виденной мной системе есть реестр возникающих рисков. Почти ни один из них не полезен. Реестр фиксирует то, что уже было очевидно на момент внесения записи — риск пандемии в 2019 году, геополитический риск в 2022-м, ИИ в 2024-м, — и не даёт вообще никакого раннего предупреждения.

Работает не документ, а квартальная привычка. Ротируемая группа экспертов первой линии, риск-менеджмента второй линии и одного внешнего голоса тратит девяносто минут на обсуждение того, что изменилось в операционной среде. Результат — одна страница. Дисциплина в том, что группа обязана определить хотя бы один сценарий, не охваченный текущей ORSA, и либо объяснить, почему его не следует включать, либо направить его в следующий цикл ORSA.

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

Модельный риск находится внутри ERM, а не рядом с ней

Фирмы, отделяющие управление модельным риском от ERM, в итоге дублируют управление и, что хуже, начинают относиться к моделям как к технической, а не стратегической проблеме. Каждая модель, влияющая на решение, расходует риск-ёмкость, и её сбой сам по себе является риском. Это вопрос первого порядка для ERM, а не сноска.

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

Отношения с советом директоров

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

Два практических совета. Во-первых, CRO должен отвечать не более чем за пять показателей в скоринговой карте совета директоров, и каждый из них должен быть таким, который CEO предпочёл бы не видеть. Если всё на дашборде рисков зелёное, дашборд ошибочен. Во-вторых, CRO должен выступать перед советом директоров в одиночку по крайней мере дважды в год — без CEO в зале. Это трудное культурное изменение, но за него стоит побороться.

Заключение

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

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