Привет, Хабр! Сегодня мы, команда Risk and Compliance компании GlowByte, хотим рассказать о большом проекте с топовым банком России, который завершили буквально месяц назад. В общей сложности история длилась более 2 лет. Речь пойдёт о внедрении новой автоматизированной системы управления операционными рисками (СУОР). Благодаря этому проекту наш заказчик стал первым банком, полностью выполнившим требования ЦБ РФ по положению 716-П "О требованиях к системе управления операционным риском в кредитной организации и банковской группе", вступившему в силу 1 октября 2021 года. Также банк первым перешёл на продвинутый подход к резервированию капитала по операционным рискам.

Не было бы риска – не было бы и прогресса. 

В. Вересаев

Что такое операционный риск и как им управлять?

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

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

Повышению эффективности способствуют контрольные процедуры. Если риск всё-таки реализуется (например, сотрудник отделения банка пришёл на работу и обнаружил, что банкомат взломан и все деньги из него украдены), это называют событием операционного риска, или рисковым событием. 

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

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

Ещё одним важным инструментом для риск-менеджеров является мониторинг ключевых индикаторов риска (КИР). 

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

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

Как клиент жил до проекта

Наш заказчик использовал устаревшую к тому моменту версию ПО, которая в полной мере не удовлетворяла новым требованиям ЦБ, закреплённым в упомянутом выше положении 716-П. В связи с необходимостью существенно менять методологию управления операционным риском банком было принято решение и о замене существующей системы на новую.

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

Во-вторых, заведение новых событий возможно было только вручную, причём эти “ручные” процессы были чересчур длительными и сложными. Наш клиент – один из крупнейших банков России, и на регистрацию событий требовались большие трудозатраты сотрудников. Нашей задачей стало упростить и автоматизировать работу пользователей. 

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

Решение проблем

Итак, все наши действия были направлены на соблюдение требований ЦБ. Согласно положению, СУОР в кредитной организации должна быть приведена в соответствие с новыми требованиями до 1 января 2022 года. Мы вместе с заказчиком выполнили задачу значительно раньше. 

Уже в начале 2021 года были введены в промышленную эксплуатацию основные модули СУОР:

• сбор данных по рисковым событиям, 

• управление рисками, 

• аналитические обобщения и планы мероприятий,

• модуль управленческой отчётности с ключевыми отчётами по рисковым событиям. 

Мы пришли к следующим результатам: 

1. СУОР предоставила возможность управлять и контролировать не только операционные риски, но и регуляторные, а также пограничные (то есть и операционные, и регуляторные).

2. Был автоматизирован процесс регистрации рисковых событий: наша команда разработала ряд интеграций с другими системами банка для автоматической регистрации типовых рисковых событий на основе бухгалтерских проводок, претензий клиентов и нарушений. 

3. Мы внедрили модуль самооценки, благодаря чему добились удобного проведения банковской самооценки риска:

• банк перешёл к прогрессивной методологии самооценки, которая в полной мере соответствует требованиям регулятора;

• полный цикл процесса теперь реализуется только в СУОР;

• оптимизирована работа риск-менеджеров при проведении самооценки, в том числе за счёт возможности выполнения групповых операций;

• помимо оценки рисков, в системе можно проводить оценку контролей.

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

Сложности на проекте 

Конечно, не всё шло по первоначальному плану. Ещё весной 2021 года многие банки начали задумываться на тему импортозамещения, и наш клиент не был исключением. Первым шагом в этом направлении стала замена используемой СУБД с Oracle на PostgreSQL. Процесс миграции в целом прошёл штатно, даже несмотря на то, что он совпал с разработкой нового функционала. Иными словами, развитие бизнес-составляющей системы не было принесено в жертву техническим задачам. 

Отметим некоторые детали, на которые стоит обратить внимание, если вы столкнётесь с подобным на проекте:  

1. Настройки конфигурации по умолчанию PostgreSQL, которая используется у вашего заказчика. В нашем случае был изменён уровень изоляции транзакций с Read Committed на Repeatable Read, что заблокировало работу приложения через Web-интерфейс, так как изменить или увидеть изменения других пользователей текущий сотрудник уже не мог. 

2. Разница типов данных в разных СУБД. Например, тип данных Date в PostgreSQL хранит в себе только дату и не хранит время, а в Oracle, напротив, хранит и дату, и время.

3. Создание надёжного кластера на промышленном контуре. Для решения этой задачи мы использовали Patroni и Haproxy. Рекомендуем устанавливать конфигурацию с данными компонентами как минимум ещё на одном, непромышленном контуре, чтобы избежать ошибок в работе системы, связанных с наличием данных компонент.

Теперь о сложностях, связанных с масштабом нашего банка. На одном из этапов проекта разрабатывалась интеграция по автоматической регистрации рисковых событий в СУОР, основываясь на бухгалтерских проводках. Для начала нужно было понять, какие проводки из всех имеющихся в банке относились к событиям операционного риска. (В любом банке ежедневно проводятся десятки миллионов самых разных проводок, и только десятки из них относятся к событиям операционного риска.) В масштабах топового банка страны эта задача усложнилась в разы. На поиск нужных проводок, формирование правил отбора в витрину для последующей загрузки в СУОР и корректировки правил загрузки ушло неимоверное количество времени всех сторон, вовлечённых в проект. 

Ещё одной трудностью были географические “границы” заказчика. Наш клиент – банк с большим количеством подразделений по всей территории страны и дочерними компаниями, которые разбросаны по всему миру. Это стало причиной весьма предсказуемых проблем с подключениями и адаптацией пользователей в системе: сказалась и разница часовых поясов, и государственные выходные, и праздники в разных частях мира. 

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

Результаты

В результате проекта мы осуществили:

• внедрение 6 модулей СУОР, 5 из которых представлены на двух языках и в состав которых входит более 30 объектов, 

• 7 интеграций СУОР с различными системами банка,

• реализацию более 50 отчётов,

• 7 пакетных загрузчиков для массового ввода или обновления данных.

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

• система позволяет оперативно регистрировать данные о рисковых событиях, в том числе данные о финансовых/нефинансовых последствиях, страховых/нестраховых возмещениях, причинах возникновения и аллоцировать потери на ответственные подразделения;

• ведётся единый реестр рисков, причин и контрольных процедур;

• проводится мониторинг ключевых индикаторов риска;

• реализуется и контролируется исполнение мер минимизации риска;

• ведутся централизовано в системе планы обеспечения непрерывности и/или восстановления деятельности банка (планы ОНиВД), проводится их тестирование и по итогу отслеживается выполнение дополнительных мероприятий;

• ускорены процессы согласования;

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

Всё это помогло нашему клиенту улучшить методологию управления операционным риском, первым выполнить требования ЦБ РФ по переходу на 716-П и продвинутый подход к резервированию капитала, оптимизировать ручную работу по заведению рисковых событий, динамически в онлайн-режиме оценивать реальный уровень операционного риска в банке.

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