Термины и сокращения

ORMF — Operational Risk Management Framework — система управления операционным риском.

CRO — Chief Risk Officer — руководитель функции управления рисками.

IOR — Institute of Operational Risk — Институт операционного риска.

IRM — Institute of Risk Management — Институт управления рисками.

GRC — Корпоративное управление Risk and Compliance — корпоративное управление, риски и соответствие требованиям.

ORM — Operational Risk Management — управление операционным риском.

Категоризация операционных рисков

[picture]

Ключевая схема по теме руководства (русская адаптация по материалам IOR/IRM).

Практическое руководство IOR

Institute of Operational Risk (IOR), компания группы IRM

Русское электронное издание подготовлено по предоставленному пользователем оригиналу.

Предисловие

Категоризация — один из базовых элементов ORMF. Она создаёт общий язык, позволяющий одинаково понимать, регистрировать, агрегировать и сравнивать риски и события по всей организации.

Руководство IOR дополняет ISO 31000 и другие общие стандарты. Оно не предлагает универсальную таксономию для всех отраслей, а объясняет, как спроектировать и поддерживать классификацию, которая подходит конкретной организации.

Содержание

Введение

Зачем категоризировать операционные риски

Основные принципы

Проектирование системы категорий

причина, событие или эффект

пробелы и перекрытия

гранулярность

дополнительные вопросы дизайна

Внедрение

Выводы

Примеры классификаций

1. Введение

Организация подвержена разным видам риска.

Тип риска | Краткое определение
Кредитный | Контрагент не исполняет обязательство полностью либо ухудшается его кредитоспособность
Ликвидности | Организация не способна своевременно погасить финансовые обязательства
Рыночный | Потери из-за изменения стоимости активов или доходов от них
Операционный | Потери вследствие неадекватных или отказавших внутренних процессов, людей, систем либо внешних событий
Репутационный | Угрозы общественному восприятию организации и goodwill заинтересованных сторон
Стратегический | Риски, создаваемые или изменяемые выбранной стратегией

Операционный риск нельзя рассматривать полностью изолированно.

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

Поэтому классификация операционных рисков должна быть частью более широкой enterprise risk taxonomy и не создавать искусственных «стен» между связанными экспозициями.

2. Зачем нужна категоризация

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

Диапазон событий очень широк:

нарушения информационной безопасности;

трудовые споры;

мошенничество;

жалобы клиентов;

пожар;

наводнение;

другие внешние события.

Категоризация помогает упорядочить эту сложность.

Идентификация

Таксономия работает как menu рисков и напоминает пользователю, какие типы экспозиций проверить. Это снижает вероятность пропустить важный риск.

Измерение

Единые термины и определения позволяют:

сравнивать риски;

агрегировать данные;

анализировать статистику по подкатегориям.

Мониторинг и отчётность

Общая система координат позволяет:

сравнивать подразделения;

видеть концентрации риска;

приоритизировать ресурсы;

устанавливать более точные лимиты и пороги.

Контроль

Разным категориям нужны разные control strategies.

Например, часть рисков страхуется — property damage, liability claims. Другие, например многие регуляторные штрафы, могут быть нестрахуемыми.

Категоризация помогает выбирать подходящий способ управления.

Она также отделяет операционный риск от market, credit и других типов, уменьшая gaps и overlaps между функциями, хотя полностью устранить пограничные случаи невозможно.

3. Ключевые принципы категоризации

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

3.1. Начинать с признанной внешней модели

Полезно брать проверенную внешнюю основу.

Наиболее известный пример — таксономия Базельского комитета по операционным события потерь. Хотя она разработана для финансовых организаций, IOR рассматривает её как хорошую отправную точку и для других отраслей.

Ещё один пример — британский Treasury Orange Book.

3.2. Адаптировать под организацию

Внешняя модель — основа, а не догма.

Таксономию следует адаптировать к:

характеру деятельности;

масштабу;

сложности;

отраслевой специфике.

Если организация отклоняется от внешней классификации, желательно сделать mapping, чтобы убедиться, что ни одна важная внешняя категория не потеряна.

Если конкретная классификация обязательна для regulatory reporting, все обязательные категории должны сохраняться.

3.3. Консультация с пользователями

Категоризация должна быть понятной тем, кто будет ею реально пользоваться:

directors;

managers;

владелец рискаs;

внутренний аудит;

соблюдение требований;

сотрудники подразделений.

Рекомендуемый процесс:

risk/operational функция управления рисками создаёт черновик на основе внешнего framework;

пользователи обсуждают термины и определения;

предлагают недостающие категории;

функция управления рисками проверяет, действительно ли новая категория новая, а не просто другое название существующей;

каждая добавленная категория по возможности маппится назад к базовой модели.

3.4. Периодический пересмотр

Деятельность и риск-профиль меняются, появляются новые риски — как когда-то cyber risk.

Поэтому таксономию обычно следует пересматривать ежегодно.

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

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

Добавлять новые категории проще, чем менять старые, но нужно проверять, не дублируют ли они уже существующие. Избыточное количество категорий делает систему сложной и увеличивает misclassification.

4. Проектирование системы категорий

4.1. Основа: причина, событие или эффект?

Операционный риск многокомпонентен:

причина → событие → эффект.

Классическое определение операционного риска описывает четыре широких источника причин:

люди;

процессы;

системы;

внешние события.

Эти причины порождают события — пожар, затопление, кражу, ошибку, omission и т. д.

События в свою очередь создают эффекты:

финансовую потерю;

физическую травму;

простой;

репутационный ущерб и др.

Классификацию можно строить по любой из трёх граней.

Event-based approach

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

Преимущества:

удобно согласовать таксономию с базой события потерь;

событие — наиболее видимое проявление риска;

каждое событие затем можно разложить на причины и эффекты;

легче выявлять корреляции и концентрации.

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

Cause-based approach

Классификация по причинам привлекательна, потому что направляет риск-менеджмент к профилактике.

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

4.2. Минимизация пробелов и перекрытий

Идеальной классификации не существует.

Слишком детальная модель уменьшает риск пропустить событие, но создаёт:

overlaps;

трудности выбора категории;

misclassification;

высокую стоимость сопровождения.

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

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

Это позволяет:

классифицировать любое событие на верхнем уровне;

при необходимости уточнять его на нижнем;

агрегировать данные вверх;

снижать вероятность gaps и overlaps.

IOR в целом предпочитает event-based классификацию, дополняя её высокоуровневыми классификаторами причин и последствий.

Так организация видит полную связь:

причины → событие → последствия

и может выявлять опасные повторяющиеся закономерности.

4.3. Гранулярность

Уровень детализации — одно из важнейших дизайнерских решений.

Меньше детализации:

проще использовать;

проще агрегировать;

легче строить отчётность.

Больше детализации:

лучше помогает управлять конкретным риском;

облегчает выбор targeted mitigation;

уменьшает вероятность, что пользователь не заметит специфический вариант события.

Хороший компромисс — более глубокая детализация для критичных категорий и более грубая для малозначимых.

Типовые уровни

Уровень | Содержание | Пример
1 | Небольшое число верхнеуровневых категорий | природные/внешние события, business continuity, IT systems, legal & regulatory, financial crime
2 | Разбиение Level 1 на логические виды событий | пожар/наводнение/шторм; internal/external fraud; hacking/equipment failure
3 | Дополнительное деление применительно к видам деятельности подразделений | конкретные виды событий в финансах, производстве, клиентском сервисе и др.
4 | Детальное описание конкретного риска в локальном контексте | риск в payroll, manufacturing, sales и т. п.

Не всем нужны уровни 2–3. Часто верхние уровни используются для корпоративной агрегации, а Level 4 существует локально, чтобы подразделение могло описать свою специфику и при этом маппить её назад к общей категории.

4.4. Дополнительные принципы дизайна

Пропорциональность. Более подробная система не автоматически лучше. Для многих организаций достаточно Level 1 или максимум Level 2.

Однозначность. Определения должны быть простыми и понятными. Рекомендуется plain language, а не технический жаргон.

Релевантность всем подразделениям. Таксономия должна соответствовать реальной деятельности пользователей.

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

5. Внедрение

5.1. Роли и ответственность

Governing body и высшее руководство

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

Владелец рискаs и другие пользователи

Владелец рискаs должны:

понимать таксономию;

обеспечивать понимание среди сотрудников;

корректно использовать её при идентификации, регистрации и отчётности.

То же относится ко всем сотрудникам с обязанностями по операционному риску.

Risk / operational функция управления рисками

Отвечает за:

дизайн классификации;

единообразное применение;

документацию;

ясные определения категорий;

правила решения boundary issues;

обучение и awareness.

Internal audit

Даёт независимое подтверждение, что классификация fit for purpose и используется правильно.

Аудит также может применять ту же таксономию при планировании проверок и маркировке management actions. Это усиливает единство языка ORMF.

5.2. Последовательность использования

Если два подразделения одинаковые события классифицируют по-разному, корпоративная картина риска становится недостоверной.

Поэтому consistency — критическое требование.

Для него нужны:

определения;

примеры;

обучение;

встроенные подсказки в ИТ-системе;

возможность быстро обратиться в функция управления рисками при сомнениях.

5.3. Отчётность

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

Детализация зависит от уровня управления:

орган управления — значимые Level 1 exposures/события потерь;

высшее руководство — Level 2;

руководители подразделений — локальные Level 2/3 и более детальные риски.

Связанные события

Одно событие может вызвать другое.

Пример:

внешняя кибератака → отказ системы → кража данных.

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

IOR рекомендует в качестве основной категории использовать исходное/underlying event — в примере external cyber attack. При этом последствия для system continuity и data security должны отдельно фиксироваться и управляться.

Правила сложных случаев нужно документировать. Если менеджер сомневается — решение должна принимать operational функция управления рисками.

В обучении полезно использовать локальные примеры самой организации.

Если используется GRC/ORM IT system, классификатор должен быть встроен в интерфейс, например через dropdown с описанием категорий.

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

5.4. Boundary events

Boundary event — событие, которое проявляется как один тип риска, но имеет первопричину в другом.

Пример:

результат выглядит как credit risk — дефолт заёмщика;

причина — операционная ошибка due diligence, из-за которой кредит выдали контрагенту с плохим рейтингом.

Такие события неизбежны.

В организациях с изолированными функция управления рискамиs они вызывают проблемы:

спор, кто «владеет» событием;

двойное управление;

либо наоборот, никто не берёт ответственность.

Помогают:

Enterprise Risk Management framework;

единая функция управления рисками под CRO;

cross-discipline training;

межфункциональный risk committee, который распределяет ответственность за boundary events.

6. Выводы

Широкий спектр операционных рисков невозможно эффективно управлять без единой структуры.

Категоризация помогает:

не пропускать риски;

правильно распределять ограниченные ресурсы;

агрегировать данные;

сравнивать подразделения;

выбирать соответствующие controls.

IOR сравнивает хорошую категоризацию со скелетом ORMF. Если скелет слабый, вся система останется слабой, каким бы качественным ни был каждый отдельный инструмент.

Приложение. Пример Basel событие потерь classification

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

1. Внутреннее мошенничество (Internal Fraud)

Определение: потери вследствие умышленных действий внутреннего участника, направленных на мошенничество, присвоение имущества, обход закона, регулирования или политика, за исключением diversity/discrimination events.

Level 2:

несанкционированная деятельность;

кража и мошенничество.

Примеры Level 3:

намеренно незарегистрированные операции;

несанкционированный тип сделки с денежным ущербом;

умышленное неверное маркирование позиции;

fraud/credit fraud;

кража, вымогательство, присвоение, robbery;

незаконное присвоение активов;

умышленное уничтожение активов;

forgery;

smuggling;

захват учётной записи/impersonation;

умышленное налоговое нарушение;

взятки и kickbacks;

insider trading не от имени фирмы.

2. Внешнее мошенничество (External Fraud)

Определение: потери из-за мошенничества, присвоения имущества или обхода закона третьими лицами.

Level 2:

кража и мошенничество;

systems security.

Примеры:

theft/robbery;

forgery;

hacking damage;

кража информации с финансовым ущербом.

3. Трудовые практики и безопасность рабочего места

Определение: потери из-за нарушения трудовых норм, требований охраны труда и безопасности, требований по травмам работников либо discrimination/diversity events.

Level 2:

employee relations;

safe environment;

diversity and discrimination.

Примеры:

компенсации, льготы, увольнения;

организованная трудовая активность;

общая ответственность за травмы;

нарушения правил H&S;

workers compensation;

дискриминация.

4. Клиенты, продукты и бизнес-практики

Определение: потери вследствие неумышленного или небрежного невыполнения профессиональных обязанностей перед клиентами.

Level 2:

suitability/disclosure/fiduciary;

improper business or market practices;

product flaws;

selection/sponsorship/exposure;

advisory activities.

Примеры:

нарушение fiduciary duties;

проблемы KYC и disclosure;

нарушение конфиденциальности;

агрессивные продажи;

misuse of confidential information;

antitrust;

market manipulation;

unlicensed activity;

money laundering;

дефекты продукта;

model error;

недостаточная проверка клиента;

превышение client exposure limits;

споры по качеству advisory services.

5. Повреждение физических активов

Определение: потери из-за утраты или повреждения физических активов вследствие природных или иных событий.

Примеры:

природные катастрофы;

terrorism;

vandalism.

6. Нарушение бизнеса и отказы систем

Определение: потери вследствие business disruption или system failure.

Примеры:

hardware;

software;

telecommunications;

utility outage/disruption.

7. Исполнение, доставка и управление процессами

Определение: потери из-за ошибок transaction processing/process management, взаимодействия с контрагентами и поставщиками.

Примеры:

miscommunication;

ошибки ввода и загрузки данных;

пропущенные сроки и обязанности;

неправильная работа модели/системы;

accounting/entity attribution error;

ошибки выполнения задач;

delivery failure;

collateral management failure;

ошибки reference data;

нарушение обязательной отчётности;

неточная внешняя отчётность с убытком;

отсутствующие client permissions/disclaimers;

неполные юридические документы;

несанкционированный доступ к счетам;

неверные клиентские записи;

небрежная утрата/повреждение клиентских активов;

ошибки non-client counterparties;

outsourcing/vendor disputes.

Источник: Institute of Operational Risk / Institute of Risk Management — www.theirm.org.