Как мы помогли топовому банку России стать первым
Привет, Хабр! Сегодня мы, команда Risk and Compliance компании GlowByte, хотим рассказать о большом проекте с топовым банком России, который завершили буквально месяц назад. В общей сложности история длилась более 2 лет. Речь пойдёт о внедрении новой автоматизированной системы управления операционными рисками (СУОР). Благодаря этому проекту наш заказчик стал первым банком, полностью выполнившим требования ЦБ РФ по положению 716-П "О требованиях к системе управления операционным риском в кредитной организации и банковской группе", вступившему в силу 1 октября 2021 года. Также банк первым перешёл на продвинутый подход к резервированию капитала по операционным рискам.
“
Не было бы риска – не было бы и прогресса.
Что такое операционный риск и как им управлять?
Для общего понимания пройдём по азам. Операционный риск – это риск возникновения прямых и косвенных потерь в результате внешних событий или ошибочных действий сотрудников, систем или внутренних процессов. Например, сотрудник банка ошибся и выдал клиенту деньги со счёта дважды – это операционный риск.
Важной целью любого банка является контроль потерь от таких рисков и максимальное сохранение активов и капитала, уменьшение или исключение убытков. Для этого проводят мероприятия по минимизации риска, и все банки заинтересованы в том, чтобы они были наиболее эффективными.
Повышению эффективности способствуют контрольные процедуры. Если риск всё-таки реализуется (например, сотрудник отделения банка пришёл на работу и обнаружил, что банкомат взломан и все деньги из него украдены), это называют событием операционного риска, или рисковым событием.
В банках есть эксперты – риск-менеджеры, которые занимаются оценкой риска (так называемой самооценкой) минимум раз в год. Именно эти важные сотрудники управляют рисками – выявляют вероятность рисковых событий по каждому виду операционного риска и суммарные потери, а также оценивают эффективность контрольных процедур.
В случае если реальный уровень риска отличается от планового, то переопределяются контрольные процедуры и проводятся дополнительные мероприятия по минимизации риска.
Для общего понимания пройдём по азам. Операционный риск – это риск возникновения прямых и косвенных потерь в результате внешних событий или ошибочных действий сотрудников, систем или внутренних процессов. Например, сотрудник банка ошибся и выдал клиенту деньги со счёта дважды – это операционный риск.
Важной целью любого банка является контроль потерь от таких рисков и максимальное сохранение активов и капитала, уменьшение или исключение убытков. Для этого проводят мероприятия по минимизации риска, и все банки заинтересованы в том, чтобы они были наиболее эффективными.
Повышению эффективности способствуют контрольные процедуры. Если риск всё-таки реализуется (например, сотрудник отделения банка пришёл на работу и обнаружил, что банкомат взломан и все деньги из него украдены), это называют событием операционного риска, или рисковым событием.
В банках есть эксперты – риск-менеджеры, которые занимаются оценкой риска (так называемой самооценкой) минимум раз в год. Именно эти важные сотрудники управляют рисками – выявляют вероятность рисковых событий по каждому виду операционного риска и суммарные потери, а также оценивают эффективность контрольных процедур.
В случае если реальный уровень риска отличается от планового, то переопределяются контрольные процедуры и проводятся дополнительные мероприятия по минимизации риска.
Ещё одним важным инструментом для риск-менеджеров является мониторинг ключевых индикаторов риска (КИР).
Например, сумма прямых потерь за месяц по рисковому событию, связанному с информационной безопасностью, не должна превышать 200 000. Каждый месяц отслеживается сумма по такому КИР, и в случае превышения проводятся дополнительные мероприятия, направленные на уменьшение потерь.
Грамотное управление уровнем операционного риска помогает банку как минимум сократить потери от ошибок в операционной деятельности, а в случае перехода на продвинутый подход к резервированию капитала ещё и высвободить часть средств из резервов и направить их на операционную деятельность.
Как клиент жил до проекта
Наш заказчик использовал устаревшую к тому моменту версию ПО, которая в полной мере не удовлетворяла новым требованиям ЦБ, закреплённым в упомянутом выше положении 716-П. В связи с необходимостью существенно менять методологию управления операционным риском банком было принято решение и о замене существующей системы на новую.
В чём были несовершенства старой системы? Во-первых, она работала медленно и нестабильно, это мешало выполнять риск-менеджерам и экспертам возложенные на них задачи.
Во-вторых, заведение новых событий возможно было только вручную, причём эти “ручные” процессы были чересчур длительными и сложными. Наш клиент – один из крупнейших банков России, и на регистрацию событий требовались большие трудозатраты сотрудников. Нашей задачей стало упростить и автоматизировать работу пользователей.
В-третьих, несмотря на то, что процессы по обеспечению непрерывности и восстановлению деятельности (ОНиВД) находились в ведении управления операционных рисков, их работа велась в другой, сторонней системе. Организация единого рабочего места сотрудника рисков упростила бы работу конечных пользователей.
Решение проблем
Итак, все наши действия были направлены на соблюдение требований ЦБ. Согласно положению, СУОР в кредитной организации должна быть приведена в соответствие с новыми требованиями до 1 января 2022 года. Мы вместе с заказчиком выполнили задачу значительно раньше.
Уже в начале 2021 года были введены в промышленную эксплуатацию основные модули СУОР:
Например, сумма прямых потерь за месяц по рисковому событию, связанному с информационной безопасностью, не должна превышать 200 000. Каждый месяц отслеживается сумма по такому КИР, и в случае превышения проводятся дополнительные мероприятия, направленные на уменьшение потерь.
Грамотное управление уровнем операционного риска помогает банку как минимум сократить потери от ошибок в операционной деятельности, а в случае перехода на продвинутый подход к резервированию капитала ещё и высвободить часть средств из резервов и направить их на операционную деятельность.
Как клиент жил до проекта
Наш заказчик использовал устаревшую к тому моменту версию ПО, которая в полной мере не удовлетворяла новым требованиям ЦБ, закреплённым в упомянутом выше положении 716-П. В связи с необходимостью существенно менять методологию управления операционным риском банком было принято решение и о замене существующей системы на новую.
В чём были несовершенства старой системы? Во-первых, она работала медленно и нестабильно, это мешало выполнять риск-менеджерам и экспертам возложенные на них задачи.
Во-вторых, заведение новых событий возможно было только вручную, причём эти “ручные” процессы были чересчур длительными и сложными. Наш клиент – один из крупнейших банков России, и на регистрацию событий требовались большие трудозатраты сотрудников. Нашей задачей стало упростить и автоматизировать работу пользователей.
В-третьих, несмотря на то, что процессы по обеспечению непрерывности и восстановлению деятельности (ОНиВД) находились в ведении управления операционных рисков, их работа велась в другой, сторонней системе. Организация единого рабочего места сотрудника рисков упростила бы работу конечных пользователей.
Решение проблем
Итак, все наши действия были направлены на соблюдение требований ЦБ. Согласно положению, СУОР в кредитной организации должна быть приведена в соответствие с новыми требованиями до 1 января 2022 года. Мы вместе с заказчиком выполнили задачу значительно раньше.
Уже в начале 2021 года были введены в промышленную эксплуатацию основные модули СУОР:
- сбор данных по рисковым событиям,
- управление рисками,
- аналитические обобщения и планы мероприятий,
- модуль управленческой отчётности с ключевыми отчётами по рисковым событиям.
Мы пришли к следующим результатам:
Конечно, не всё шло по первоначальному плану. Ещё весной 2021 года многие банки начали задумываться на тему импортозамещения, и наш клиент не был исключением. Первым шагом в этом направлении стала замена используемой СУБД с Oracle на PostgreSQL. Процесс миграции в целом прошёл штатно, даже несмотря на то, что он совпал с разработкой нового функционала. Иными словами, развитие бизнес-составляющей системы не было принесено в жертву техническим задачам.
Отметим некоторые детали, на которые стоит обратить внимание, если вы столкнётесь с подобным на проекте:
Ещё одной трудностью были географические “границы” заказчика. Наш клиент – банк с большим количеством подразделений по всей территории страны и дочерними компаниями, которые разбросаны по всему миру. Это стало причиной весьма предсказуемых проблем с подключениями и адаптацией пользователей в системе: сказалась и разница часовых поясов, и государственные выходные, и праздники в разных частях мира.
Например, у пользователя с Дальнего Востока возникли сложности с передачей на согласование рискового события. Обычно такие вопросы решаются очень быстро, но для этого зачастую требуется быть на связи с пользователем, чтобы понять детали проблемы. Из-за разницы в часовых поясах между вопросом и ответом проходило более 10 часов. Ситуация требовала оперативности, чтобы не допустить задержки в бизнес-процессе банка. В данном случае нам удалось решить проблему без участия пользователя: служба поддержки и команда разработки перебрали все возможные варианты возникновения проблемы, и один из них подошёл к данному случаю.
Результаты
В результате проекта мы осуществили:
- СУОР предоставила возможность управлять и контролировать не только операционные риски, но и регуляторные, а также пограничные (то есть и операционные, и регуляторные).
- Был автоматизирован процесс регистрации рисковых событий: наша команда разработала ряд интеграций с другими системами банка для автоматической регистрации типовых рисковых событий на основе бухгалтерских проводок, претензий клиентов и нарушений.
- Мы внедрили модуль самооценки, благодаря чему добились удобного проведения банковской самооценки риска:
- банк перешёл к прогрессивной методологии самооценки, которая в полной мере соответствует требованиям регулятора;
- полный цикл процесса теперь реализуется только в СУОР;
- оптимизирована работа риск-менеджеров при проведении самооценки, в том числе за счёт возможности выполнения групповых операций;
- помимо оценки рисков, в системе можно проводить оценку контролей.
- Внедрение модуля ОНиВД в новую систему позволило сделать его единым решением для управления операционными рисками, а также дало возможность фиксировать в СУОР результаты проведения тестирования планов ОНиВД и проводить контроль мероприятий по их итогам. Ведение планов ОНиВД в СУОР позволяет гибко контролировать резервные ресурсы, оперативно получать информацию о влиянии чрезвычайных ситуаций на ИТ-системы и ключевые сервисы банка и связываться с сотрудниками-участниками плана ОНиВД.
Конечно, не всё шло по первоначальному плану. Ещё весной 2021 года многие банки начали задумываться на тему импортозамещения, и наш клиент не был исключением. Первым шагом в этом направлении стала замена используемой СУБД с Oracle на PostgreSQL. Процесс миграции в целом прошёл штатно, даже несмотря на то, что он совпал с разработкой нового функционала. Иными словами, развитие бизнес-составляющей системы не было принесено в жертву техническим задачам.
Отметим некоторые детали, на которые стоит обратить внимание, если вы столкнётесь с подобным на проекте:
- Настройки конфигурации по умолчанию PostgreSQL, которая используется у вашего заказчика. В нашем случае был изменён уровень изоляции транзакций с Read Committed на Repeatable Read, что заблокировало работу приложения через Web-интерфейс, так как изменить или увидеть изменения других пользователей текущий сотрудник уже не мог.
- Разница типов данных в разных СУБД. Например, тип данных Date в PostgreSQL хранит в себе только дату и не хранит время, а в Oracle, напротив, хранит и дату, и время.
- Создание надёжного кластера на промышленном контуре. Для решения этой задачи мы использовали Patroni и Haproxy. Рекомендуем устанавливать конфигурацию с данными компонентами как минимум ещё на одном, непромышленном контуре, чтобы избежать ошибок в работе системы, связанных с наличием данных компонент.
Ещё одной трудностью были географические “границы” заказчика. Наш клиент – банк с большим количеством подразделений по всей территории страны и дочерними компаниями, которые разбросаны по всему миру. Это стало причиной весьма предсказуемых проблем с подключениями и адаптацией пользователей в системе: сказалась и разница часовых поясов, и государственные выходные, и праздники в разных частях мира.
Например, у пользователя с Дальнего Востока возникли сложности с передачей на согласование рискового события. Обычно такие вопросы решаются очень быстро, но для этого зачастую требуется быть на связи с пользователем, чтобы понять детали проблемы. Из-за разницы в часовых поясах между вопросом и ответом проходило более 10 часов. Ситуация требовала оперативности, чтобы не допустить задержки в бизнес-процессе банка. В данном случае нам удалось решить проблему без участия пользователя: служба поддержки и команда разработки перебрали все возможные варианты возникновения проблемы, и один из них подошёл к данному случаю.
Результаты
В результате проекта мы осуществили:
- внедрение 6 модулей СУОР, 5 из которых представлены на двух языках и в состав которых входит более 30 объектов,
- 7 интеграций СУОР с различными системами банка,
- реализацию более 50 отчётов,
- 7 пакетных загрузчиков для массового ввода или обновления данных.
По итогам проекта банк получил единое автоматизированное решение для управления операционными рисками со следующими возможностями:
Нами совместно с командой банка заложен мощный ИТ-фундамент, на основе которого клиент сможет самостоятельно увеличивать качество управления операционными рисками и подстраиваться под современные и меняющиеся условия.
- система позволяет оперативно регистрировать данные о рисковых событиях, в том числе данные о финансовых/нефинансовых последствиях, страховых/нестраховых возмещениях, причинах возникновения и аллоцировать потери на ответственные подразделения;
- ведётся единый реестр рисков, причин и контрольных процедур;
- проводится мониторинг ключевых индикаторов риска;
- реализуется и контролируется исполнение мер минимизации риска;
- ведутся централизовано в системе планы обеспечения непрерывности и/или восстановления деятельности банка (планы ОНиВД), проводится их тестирование и по итогу отслеживается выполнение дополнительных мероприятий;
- ускорены процессы согласования;
- в онлайн-режиме осуществляется управление операционными рисками на основе данных, заведённых в системе: построение отчётности, расчёт требований к капиталу под операционный риск, контроль бизнес-процессов банка по минимизации операционного риска.
Нами совместно с командой банка заложен мощный ИТ-фундамент, на основе которого клиент сможет самостоятельно увеличивать качество управления операционными рисками и подстраиваться под современные и меняющиеся условия.