Управление операционными рисками банка

Кастомизация системы – это этап, на котором типовой «коробочный» продукт настраивается под индивидуальные особенности конкретного банка.

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

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

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

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

Этап 2. Интеграция системы с данными банка (со справочниками и иными данными).

Систему целесообразно интегрировать как минимум с двумя справочниками: со справочником «Сотрудники и подразделения» и со справочником «Продукты банка». Такая интеграция означает, что в случае изменений, например, в составе сотрудников банка (в кадровой системе) такие изменения автоматически произойдут и в базе операционных рисков. Если такой интеграции не делать, то на поддержание списка сотрудников в актуальном состоянии в базе рисков будет уходить очень много ручного труда.

Иногда производят интеграцию с другими справочниками, например, курсов валют, списками счетов, каталогами Active Directory (для возможности авторизации пользователей по своим учётным записям) и т. п.

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

Базу рисков интегрируют и с данными для расчета ключевых индикаторов рисков и т. д.

Этап 5. Настройка отчетов, настройка средств доступа к ним.

Всю отчетность целесообразно строить не в базе рисков, а из хранилища данных (предварительно обеспечив ежедневную выгрузку туда этих данных из базы рисков – см. выше этап 4 настоящего пункта).

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

7.8. Аллокация инцидентов

7.8.1. Важность аллокации и инструменты.

Аллокация инцидентов[83] (по исполнителям, подразделениям, покрывающим убытки, и иным признакам) в рамках их учета является важным моментом, обеспечивающим работоспособность всей системы управления операционным риском. Ниже приводятся примеры наиболее важных аллокаций и раскрываются причины их важности.

1. Аллокация инцидента по типу (виду) инцидентов.

Если инциденты будут аллоцироваться не на те типы инцидентов, к которым они относятся то и направляться для обработки они будут не на те маршруты и не к тем экспертам (их обработки либо вовсе не будет, либо она будет некомпетентной). В этих условиях вся работа с инцидентами будет неэффективной.

2. Аллокация инцидента по виду бизнеса.

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

Список названий оптимальных признаков инцидента и информационных полей приведен в Приложении 4.

Присвоение признаков играет ключевую роль и для последующей аналитики и построения отчетности, и для автоматической аллокации инцидентов на классификаторы Базель II (для расчета операционного риска продвинутым способом).

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

• Что произошло?

• С чем произошло (ресурс)?

• Где произошло (территория)?

• Где произошло (процесс / продукт)?

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

7.8.2. Особенности аллокации инцидентов по категориям и бизнес-линиям.