text:
© Бедрединов Р.Т.
© Onebook.ru, 2014
Введение
Идея формализованного управления операционными рисками возникла сравнительно недавно - 10-15 лет назад[1]. Возможно, ввиду столь малого срока руководство и сотрудники большинства банков воспринимают деятельность по управлению своими операционными рисками недостаточно объективно - как непонятную формальность, которую им хотят навязать.
В результате большинство руководителей банков до сих пор не считают операционные риски критически важной функцией (в большинстве банков - это один-два сотрудника "для галочки", чтобы "показывать" их регулятору и рейтинговым агентствам). Такое отношение руководители банков объясняют примерно так: "Если компанию сравнить с организмом, то какой это орган - операционные риски? Насколько критичны его функции? Дыхание или питание (производство и продажи) критичны - без них компания прекратит свое существование. А если убрать риски, то явных изменений можно и не заметить...". И они правы. Заметных изменений в краткосрочной перспективе можно не заметить.
Наверное, наиболее подходящей метафорой является отведение "рискам" функции разума (в этом случае орган - префронтальная кора головного мозга, которая отвечает за критическое мышление, самоконтроль и способность прогнозировать ситуацию). Иначе говоря, риски прежде всего отвечают за то, насколько разумным будет поведение сотрудников, подразделений и банка в целом, и насколько такое разумное поведение будет стабильным.
Чем разумнее организация, тем больше её доход. Это подходит и для людей: большинство именно по этой причине пытаются получить образование и повышают свою квалификацию "разумности", чтобы быть более эффективными и получать больший доход.
Однако руководители банков выдвигают очередной контраргумент: "Производство и продажи легко поддаются подсчету, а как посчитать доход от этой самой разумности?? И если вы не сможете подсчитать это, то и ваш бюджет останется без изменений (не увеличится)...".
Действительно подсчитать это практически невозможно, как невозможно подсчитать окупаемость затрат на образование и повышение квалификации простого человека. Что уж говорить об организации...
Представляется, что в числе прочего и по этой причине Базельский комитет (а следом и Банк России) сделали банкам своеобразное "коммерческое предложение", позволяющее формально подсчитать доход от такой разумности. Они сказали примерно следующее: "Разумным банкам (тем, которые управляют своими рисками по наилучшим практикам) мы дадим существенную скидку. То есть тем, кто сделает волевые и финансовые вложения в повышение своей разумности, а также пройдет обучение и "сдаст экзамены по рискам", мы дадим преференции". Для российских банков такие преференции предполагается делать через показатель Н1 (достаточность капитала). И некоторое движение началось. Но для того чтобы все заработало полноценно, регулятор должен действительно проводить такие "экзамены на разумность", давать реальные "скидки", осуществлять регулярные "переэкзаменовки".
Настоящие рекомендации[2] как раз и делают попытку ответить вопрос: "Что такое разумность банка (с позиции операционных рисков) и как её считать..."
1. Общие положения
1.1. Рекомендации по управлению операционными рисками (далее - Рекомендации) разработаны с учетом требований законодательства Российской Федерации, требований Банка России, положений Международной конвергенции измерения капитала и стандартов капитала Базельского комитета по банковскому надзору в сфере управления операционными рисками и определяют:
• цели и задачи банка в области управления операционными рисками;
• основные подходы и принципы управления операционными рисками;
• описание системы управления операционными рисками, механизмы и методы;
• участников процесса управления операционными рисками, их полномочия и ответственность.
1.2. Положения Рекомендаций распространяются на следующие сферы деятельности банка (учитываются при разработке и модернизации следующих нормативных документов):
• управление организационной структурой банка, разделение и делегирование полномочий, функциональных обязанностей;
• порядок взаимодействия подразделений, сотрудников и обмена информацией;
• порядок, правила, процедуры совершения банковских операций и других сделок;
• учетную политику, организацию внутренних процессов;
• правила, порядок и процедуры функционирования и эксплуатации систем (технических, информационных и других);
• порядок разработки и представления отчетности и иной информации;
• порядок стимулирования служащих.
Данный перечень не является исчерпывающим и может быть расширен в рабочем порядке по усмотрению руководства банка.
1.3. Рекомендации разработаны с учетом следующих нормативных документов:
2. Цели и задачи управления операционным риском
2.1. Основные цели управления операционными рисками:
• своевременное выявление и минимизация рисков и возможностей их негативного влияния на результаты деятельности банка (минимизация убытков от событий операционных рисков);
• обеспечение стабильности банка и готовности к продолжению своей деятельности при возникновении чрезвычайных обстоятельств, обеспечение готовности банка к минимизации убытков при возникновении чрезвычайных обстоятельств (обеспечение непрерывности деятельности);
• обеспечение достаточности капитала банка для покрытия убытков от возможной реализации операционных рисков - прогнозирование сумм резервов, необходимых банку на покрытие убытков от инцидентов операционного риска, контроль резервирования указанных сумм, в том числе управление экономическим капиталом в соответствии с рекомендациями Базель II.
2.1.1. В практической интерпретации указанные цели означают обеспечение работы банка в условиях операционных рисков в соответствии с риск-аппетитом - сокращение вероятности и размера потенциального ущерба от реализации событий операционного риска, которые могут негативно повлиять на бизнес и обеспечение непрерывности бизнеса, если указанные события всё же произошли.
2.1.2. Достижение указанных целей осуществляется с учетом следующих главных приоритетов:
• приоритета сохранения жизни и здоровья человека: как сотрудников банка, его клиентов, так и других людей, находящихся во взаимодействии с банком в момент реализации угрозы;
• приоритета закона, означающего, что действия по управлению операционными рисками должны осуществляться в соответствии (не вступать в противоречие) с законодательством РФ и других стран, нормативными актами ЦБ РФ, международными стандартами и рекомендациями Базельского комитета, сложившейся банковской практикой;
• приоритета бизнеса, означающего, что эффективное управление операционными рисками должно способствовать защите и развитию бизнеса, не создавать ему излишних препятствий и трудностей;
• приоритета имиджа банка, означающего, что действия по управлению операционными рисками не должны нести текущего или потенциального, прямого или косвенного негативного влияния на публичный имидж банка;
• приоритета объективной количественной оценки всех видов рисков.
2.2. Основные задачи управления операционными рисками
Такими задачами являются внедрение процедур (компонентов) управления операционными рисками (см. схему 1) и обеспечение их эффективности:
1. Эффективная работа с инцидентами.
2. Выявление рисков и их устранение.
3. Система раннего предупреждения рисков.
4. Обеспечение непрерывности деятельности.
5. Координация работы всех департаментов в управлении своими рисками.
6. Система отчетов и прогнозов, поддержание базы рисков.
7. Контроль соблюдения стандартов минимизации рисков.
Ключевые цели и задачи
Схема 1. Процедуры (компоненты), с помощью которых банк управляет своими операционными рисками
3. Характеристики операционного риска
3.1. Понятие операционных рисков
Под операционными рисками понимаются риски банка, влекущие прямые и (или) косвенные потери (в т. ч. простои ресурсов) по следующим причинам, или под воздействием следующих факторов:
• случайные или преднамеренные действия физических и (или) юридических лиц, в том числе с участием сотрудников банка;
• несовершенство бизнес-процессов, в т. ч. организационной структуры банка в части распределения полномочий подразделений и служащих, порядка и процедур совершения банковских и других операций и сделок, их документирования и отражения в учете, несоблюдение служащими установленных порядка и процедур, неэффективность внутреннего контроля;
• сбои в функционировании систем и оборудования;
• неблагоприятные внешние обстоятельства, находящиеся вне контроля банка (в т. ч. изменения законодательства, рыночной конъюнктуры, стихийных бедствий, других форс-мажорных обстоятельств).
3.2. Понятие инцидента
Под инцидентом понимается любое событие, связанное с операционными рисками, которое может повлечь ущерб для банка (материальный, имиджевый, и т. д.). Общая классификация инцидентов приведена в Приложении 1. Для целей учета различают значимые и незначимые инциденты.
Значимыми инцидентамибанк, например, признает все инциденты, связанные со злоумышленными действиями, и иные инциденты с потенциально возможной или фактически наступившей суммой убытка более 10 тысяч рублей[3]. Значимые инциденты подлежат детальному учету (подробнее см. в разделе 6.1 "Эффективная работа с инцидентами"). К незначимым инцидентам, в таком случае, относятся иные инциденты (с меньшей суммой убытка).
3.3. Классификация операционных рисков
Для целей анализа рисков и инцидентов (в т. ч. для расчета размера операционного риска) каждый идентифицированный риск, инцидент, убыток или проблема, обусловливающая риск, должны быть классифицированы по следующему списку критериев (список может быть расширен в рабочем порядке комитетом по рискам (см. п. 4.2.1):
3.3.1. По типу риска:
1. Риски техногенного, природного, социального характера.
2. Риски сбоев техники, программ, простоев.
3. Риски нарушений прав сотрудников, условий труда, конфликтов.
4. Риски ошибок в процессе обслуживания клиента или контрагента.
5. Риски ошибок внутреннего процесса, не связанного с обслуживанием клиента или контрагента.
6. Риски мошенничества и злоупотреблений с участием сотрудников банка.
7. Риски мошенничества и злоупотреблений с участием третьих лиц.
Эти типы рисков детализированы в Приложении 1.
3.3.2. По значимости:
1. Экстремальный (символьное обозначение AAA, красная зона).
2. Критичный (AA, красная зона).
3. Высокий (A, красная зона).
4. Средний (BB, желтая зона).
5. Низкий (B, желтая зона).
6. Допустимый (C, зеленая зона).
Эта шкала риска детализирована в Приложениях 2.1 и 2.2.
3.3.3. По бизнес-линии:
1. Банкинг физических лиц.
2. Банкинг юридических лиц.
3. Платежи и расчеты лиц, не являющихся клиентами банка.
4. Агентские услуги.
5. Биржевая и внебиржевая торговля.
6. Финансирование корпораций.
7. Управление активами.
8. Брокерские услуги.
Эти бизнес-линии детализированы в Приложении 3.
Могут использоваться и иные классификации риска.
4. Субъекты управления операционными рисками
Для управления операционными рисками в банке существуют три линии защиты[4]:
1-я линия защиты - все подразделения банка, которые работают с операционными рисками на месте его возникновения.
Выделяют три вида ответственных:
• риск-координаторы (начальники департаментов и назначенные лица);
• эксперты по инцидентам;
• регистраторы (все сотрудники подразделения).
2-я линия защиты - субъекты, которые координируют в целом всю систему управления операционными рисками:
• комитет по рискам или иной комитет, наделенный соответствующими полномочиями (далее - комитет по рискам);
• директор по рискам[5];
• риск-менеджеры[6].
3-я линия защиты - подразделение внутреннего аудита (далее - подразделение по аудиту), которое осуществляет независимый аудит системы управления операционными рисками. Ответственные - аудиторы.
Визуальная схема субъектов, управляющих операционными рисками, и их задач представлена на схеме 2.
Субъекты, управляющие операционными рисками
Схема 2. Схема субъектов, управляющих операционными рисками банка, и их задач
4.1. Субъекты первой линии защиты
Первая "линия защиты" включает в себя процесс управления операционными рисками на уровне каждого подразделения банка, его процессов, средств и ресурсов (децентрализованный подход).
В рамках первой линии защиты в подразделениях банка операционными рисками управляют:
• риск-координаторы;
• эксперты по инцидентам;
• регистраторы.
Перечисленные субъекты, безусловно, имеются во всех департаментах банка[7], так как каждый департамент в текущем состоянии уже производит разбирательства с инцидентами, проводит методологические и технологические улучшения своих процессов, обеспечивает взаимозаменяемость сотрудников (в рамках непрерывности деятельности) и т. д.
Если эти субъекты департаментов не оформлены должным образом[8], то риск-менеджеры оказывают помощь этому подразделению для соответствующего их оформления[9] и обучения.
4.1.1. Риск-координаторы.
4.1.1.1. Риск-координаторы - это сотрудники, которые отвечают за организацию управления операционными рисками конкретного департамента и региональных сотрудников[10]. Риск-координаторами являются руководитель департамента и сотрудники, назначаемые им для выполнения обязанностей риск-координатора[11].
4.1.1.2. Обязанность риск-координатора - организовать и контролировать выполнение сотрудниками своего департамента и региональными сотрудниками следующих риск-процедур:
1. Эффективная работа с инцидентами.
2. Выявление рисков и их устранение.
3. Система раннего предупреждения рисков.
4. Обеспечение непрерывности деятельности.
5. Координация работы всех департаментов в управлении рисками.
6. Система отчетов и прогнозов, поддержание базы рисков.
7. Контроль соблюдения стандартов минимизации рисков.
Выполнение этих обязанностей должно соответствовать стандартам и требованиям настоящих Рекомендаций (прежде всего раздела 6).
4.1.1.3. Риск-координатор для эффективного выполнения обязанностей, перечисленных в предыдущем пункте, имеет право:
1. Принимать решения по обнаруженным операционным рискам зеленой зоны (уровня "допустимый")[12] - о мерах по устранению риска (или) об оставлении риска без его устранения.
2. Проводить проверку на предмет анализа операционных рисков всех процессов департамента, его региональных сотрудников, ресурсов, документов без каких-либо специальных разрешений (проверки, связанные со входом в помещения, в которых осуществляется хранение ценностей, осуществляются на основании приказа Председателя правления банка).
3. Подготавливать и изменять нормативные документы об управлении операционными рисками своего департамента.
4. Давать обязательные для исполнения указания курируемым экспертам по инцидентам, регистраторам о выполнении ими положений настоящих Рекомендаций, контролировать исполнение этих указаний.
5. Получать от любых подразделений банка и их сотрудников информацию о состоянии операционных рисков и эффективности управления ими (относительно рисков, прямо связанных с департаментом).
6. Направлять в подразделения по управлению персоналом документы о мотивировании сотрудников, принесших банку финансовую экономию от эффективного управления операционными рисками, или о привлечении к ответственности сотрудников, нарушающих правила нормативных документов об управлении операционными рисками.
7. Обращаться к риск-менеджерам для получения разъяснений об управлении операционными рисками, а также для эскалации проблем управления операционными рисками, которые ему не удалось разрешить на своем уровне (для их решения на уровне комитета по рискам или Правления банка).
8. Назначать экспертов по инцидентам в департаменте и среди региональных сотрудников (в случае если департамент и региональные сотрудники работают с инцидентами), а также контролировать их работу.
4.1.1.4. О выполнении этих задач риск-координатор отчитывается перед риск-менеджером с периодичностью, установленной нормативными документами банка.
4.1.2. Эксперты по инцидентам.
4.1.2.1. Эксперты по инцидентам[13] - это сотрудники подразделений банка (находящиеся в Центральном офисе / Головном банке, региональных и иных подразделениях), которые в рамках своих полномочий занимаются устранением последствий произошедших инцидентов[14].
4.1.2.2. Обязанность эксперта по инцидентам - организовать и осуществлять эффективную работу с инцидентами (их идентификацию, минимизацию ущерба, расследование, отчет об исполнении мер и прочие действия, указанные в разделе 6.1 настоящих Рекомендаций) и оказание помощи риск-координатору и риск-менеджеру в организации риск-процедур перечисленных в главе 6.
4.1.2.3. Эксперт по инцидентам для эффективного выполнения обязанностей, перечисленных в предыдущем пункте, имеет право:
1. Принимать необходимые меры для локализации инцидентов в пределах своих полномочий.
2. Получать от любых подразделений банка и их сотрудников информацию об инцидентах, находящихся в его компетенции.
3. Направлять курирующему риск-координатору документы о мотивировании сотрудников, принесших банку финансовую экономию от эффективного управления операционными рисками, или о привлечении к ответственности сотрудников нарушающих правила нормативных документов об управлении операционными рисками.
4. Обращаться к курирующему риск-координатору и риск-менеджерам для получения разъяснений об управлении операционными рисками, а также для эскалации проблем управления операционными рисками, которые не удалось разрешить на своем уровне.
5. Инициировать подготовку и изменение нормативных документов о процедурах работы с инцидентами.
4.1.2.4. О выполнении этих задач эксперт по инцидентам отчитывается перед курирующим риск-координатором и риск-менеджером с периодичностью, установленной нормативными документами банка.
4.1.3. Регистраторы.
4.1.3.1. Регистраторы[15] - это все сотрудники подразделений, так как в рамках выполнения своих функций они могут обнаруживать инциденты и проблемы, вызывающие операционный риск.
4.1.3.2. Обязанность регистратора при обнаружении инцидентов и проблем, вызывающих операционный риск:
1. Осуществлять действия по сохранению жизни и здоровья сотрудников и клиентов и предпринимать первичные действия по минимизации ущерба от инцидента (при наличии такой обязанности).
2. Незамедлительно сообщать эксперту по инцидентам и риск-координатору об инциденте или проблеме.
3. Осуществлять иные обязательные действия согласно правилам, установленным нормативными документами банка.
При необходимости регистратор обязан также оказывать помощь эксперту по инцидентам, риск-координатору и риск-менеджеру в организации риск-процедур, перечисленных в разделе 6.
4.1.3.3. Регистратор имеет право:
1. Обращаться к экспертам по инцидентам, риск-координаторам, риск-менеджерам для получения разъяснений об особенностях регистрации инцидентов и проблем, а также для эскалации проблем управления операционными рисками, которые ему не удалось разрешить на своем уровне.
2. Ставить вопрос перед риск-координатором и риск-менеджером о необходимости изменения нормативных документов и процедур, имеющих проблемы[16].
4.1.3.4. Контроль за исполнением всеми сотрудниками подразделений обязанностей регистраторов осуществляет тот риск-координатор, чей департамент курирует этих сотрудников.
4.2. Субъекты второй линии защиты
Вторая "линия защиты" включает в себя процесс координации системы управления операционными рисками в целом, проверку данных и отчетов об операционных рисках, организацию деятельности комитетов по риску, представление отчетности руководству банка[17] (централизованный подход).
В рамках второй линии защиты операционными рисками управляют:
• комитет по рискам;
• директор по рискам[18];
• риск-менеджеры[19].
4.2.1. Комитет по рискам (или иной комитет, наделенный соответствующими полномочиями - далее - комитет по рискам).
4.2.1.1. Комитет по рискам (в рамках управления операционными рисками) - это высший коллегиальный орган, который принимает решения о действиях банка в отношении тех или иных рисков (в т. ч. операционных). Председателем комитета по рискам является директор по рискам с правом вето на любые решения комитета.
4.2.1.2. Права комитета по рискам (в рамках управления операционными рисками)[20]:
1. Принимает решения по обнаруженным операционным рискам красной зоны (уровня "высокий" и выше), а также по рискам желтой и зеленой зон в случаях, когда они были эскалированы до уровня комитета.
2. Инициирует разработку стратегий, политики и основополагающих подходов к управлению операционными рисками банка и представляет их на согласование в Правление банка.
3. Утверждает методологию управления операционными рисками для обеспечения общего понимания рисков.
4. Утверждает уровень операционного риска на год - риск-аппетит банка (пороговый риск в части разработки и утверждения мер по его минимизации).
5. Осуществляет постоянный мониторинг соответствия подходов к управлению операционными рисками принятой стратегии.
6. Получает и анализирует данные об уровне операционных рисков для принятия решений по управлению рисками.
7. Инициирует разработку эффективных мер и осуществляет последующий контроль над операционными рисками в рамках заседаний комитета.
8. Утверждает общую терминологию, формы отчетности и системы представления информации субъектами системы управления операционными рисками.
9. Утверждает меры по управлению операционными рисками и осуществлению контроля за их эффективностью.
10. Утверждает сферу компетенции подразделений по управлению операционными рисками, а также обеспечивает наличие у них достаточных ресурсов и соответствующего доступа к информации для эффективного осуществления своих функций.
11. Утверждает отчеты по управлению операционными рисками, подлежащими включению в отчет для Правления банка.
12. Разрешает разногласия, возникающие в ходе процесса управления операционными рисками.
4.2.2. Директор по рискам.
4.2.2.1. Директор по рискам (в рамках управления операционными рисками) - это лицо, которое принимает решения о действиях банка в отношении операционных рисков, относимых к рискам желтой зоны (уровню "средний и низкий")[21], а также по рискам зеленой зоны в случаях, когда они были эскалированы до уровня директора по рискам.
4.2.2.2. Директор по рискам отвечает также за организацию управления операционными рисками во всем банке и за эффективность управления операционными рисками.
4.2.3. Риск-менеджеры.
4.2.3.1. Риск-менеджеры - это сотрудники, которые отвечают за организацию управления операционными рисками во всем банке (в каждом подразделении и каждым сотрудником). Риск-менеджерами являются все сотрудники подразделения по операционным рискам.
4.2.3.2. Обязанность риск-менеджера - организовать и контролировать выполнение в каждом департаменте и подразделении следующих риск-процедур:
1. Эффективная работа с инцидентами.
2. Выявление рисков и их устранение.
3. Функционирование системы раннего предупреждения рисков.
4. Обеспечение непрерывности деятельности.
5. Координация работы в управлении рисками.
6. Система отчетов и прогнозов, поддержание базы рисков.
7. Контроль соблюдения стандартов минимизации рисков.
Выполнение этих обязанностей должно соответствовать стандартам и требованиям настоящих Рекомендаций (прежде всего раздела 6).
4.2.3.3. Для эффективного выполнения обязанностей, перечисленных в предыдущем пункте, риск-менеджер имеет право:
1. Проводить на предмет анализа операционных рисков проверку любого процесса банка, подразделения (за исключением подразделения по аудиту), ресурсов банка, документов без каких-либо специальных разрешений (проверки, связанные со входом в помещения, в которых осуществляется хранение ценностей, осуществляются на основании приказа Председателя правления банка).
2. Инициировать подготовку и изменение нормативных документов об управлении операционными рисками. Поручать разработку таких документов риск-координаторам, если эти документы касаются управления операционными рисками только одного или нескольких конкретных подразделений или региональных сотрудников.
3. Давать риск-координаторам, экспертам по инцидентам, регистраторам обязательные для исполнения указания о выполнения ими положений настоящих Рекомендаций и нормативных документов, составленных по их исполнению. Контролировать исполнение ими этих указаний.
4. Получать от любых подразделений банка и их сотрудников информацию о состоянии операционных рисков и об эффективности управления ими.
5. Направлять в подразделения по управлению персоналом документы о мотивировании сотрудников, принесших банку финансовую экономию от эффективного управления операционными рисками, или о привлечении к ответственности сотрудников, нарушающих правила нормативных документов об управлении операционными рисками.
6. Обращаться к аудиторам для получения разъяснений о спорных вопросах об управлении операционными рисками, а также для эскалации проблем управления операционными рисками, которые не удалось разрешить на своем уровне.
7. Эскалировать спорные вопросы по операционным риска на уровень комитета по рискам или Правления банка.
4.2.3.4. О выполнении этих задач риск-менеджеры отчитываются перед директором по рискам, перед Правлением банка и перед Советом директоров.
4.3. Субъекты третьей линии защиты
Третья "линия защиты" включает в себя процесс независимого контроля и регулярного аудита эффективности всей системы управления операционными рисками и контроля её соответствия требованиям ЦБ РФ и Базельского комитета[22].
В третьей линии защиты, операционными рисками управляет подразделение по аудиту, а именно аудиторы.
4.3.1. Аудиторы.
4.3.1.1. Обязанность аудитора (в рамках управления операционными рисками) - осуществлять текущий независимый контроль и регулярный аудит эффективности всей системы управления операционными рисками и её соответствия требованиям ЦБ РФ и Базельского комитета, а также давать заключения о соответствии или несоответствии с замечаниями, которые должны быть устранены.
4.3.1.2. Аудит должен производится не чаще двух раз в год и не реже одного раза в год.
4.3.1.3. Права аудитора фиксируются в нормативных документах, регламентирующих деятельность подразделения по аудиту.
5. Этапы управления операционным риском
5.1. Четыре этапа управления риском
Управление операционными рисками состоит из четырех этапов:
Этап 1. Идентификация рисков (выявление, классификация, документирование).
Этап 2.Анализ и оценка (определение владельца, классификация, оценка, выбор метода управления, определение мероприятий).
Этап 3. Управляющее воздействие - выполнение мероприятий по минимизации риска.
Этап 4. Мониторинг (контроль исполнения мероприятий, измерение уровня риска, отчетность).
Схема 3. Взаимосвязь четырех этапов управления операционным риском
5.2. Два подхода управления риском
Для управления рисками используются два взаимодополняющих подхода:
• "сверху вниз" - подход, при котором оцениваются последствия реализации риска (прямые и косвенные потери/затраты, их влияние на конечные результаты деятельности банка);
• "снизу вверх" - подход, при котором выявляются и оцениваются источники, причины и последствия (потенциальные и реализованные) возникновения риска в подразделениях банка и бизнес-процессах. Идентификация рисков при таком подходе происходит путем оценки реакции сотрудников, процессов, технологий на внутренние или внешние воздействия, и при этом определяются точки контроля.
6. Компоненты управления операционными рисками
Для достижения целей управления операционными рисками, обозначенных в п. 2.1, субъекты управления операционными рисками выстраивают и поддерживают в эффективном состоянии следующие риск-процедуры, которые обозначаются как компоненты управления операционными рисками:
Компонент No 1. Эффективная работа с инцидентами.
Компонент No 2. Выявление рисков и их устранение.
Компонент No 3. Система раннего предупреждения рисков.
Компонент No 4. Обеспечение непрерывности деятельности.
Компонент No 5. Координация работы всех департаментов в управлении рисками.
Компонент No 6. Система отчетов и прогнозов, поддержание базы рисков.
Компонент No 7. Контроль соблюдения стандартов минимизации рисков.
6.1. Компонент No 1. Эффективная работа с инцидентами
6.1.1. Гарантии качественной обработки всех банковских инцидентов.
6.1.1.1. Банк организует работу со всеми видами банковских инцидентов[23]. По каждому виду инцидентов банк назначает департамент, который в рамках выполнения своих функций[24] отвечает за организацию и осуществление эффективной работы с этими инцидентами (за их идентификацию, минимизацию ущерба, расследование, отчеты об исполнении мер и за организацию прочих необходимых действий во всем банке, включая его территориальные подразделения). Непосредственно такую работу с инцидентами организуют риск-координаторы департаментов.
6.1.1.2. Риск-координатор назначает экспертов по инцидентам[25] в своем департаменте и среди сотрудников, функционально курируемых департаментом (в т. ч. в территориальных подразделениях), организует и контролирует их работу. Численность и местонахождение экспертов по инцидентам определяется так, чтобы они охватывали работой все инциденты своего вида во всем банке, включая все территориальные подразделения (при этом может использоваться удаленная работа с инцидентами).
6.1.1.3. По однотипным инцидентам[26] или инцидентам с уровнем значимости высокий и выше[27], риск-координаторы, которые отвечают за обработку этих инцидентов, разрабатывают и внедряют планы (методики) реагирования и локализации, включающие в себя как минимум следующие пункты:
• виды инцидентов, подлежащих обработке, их признаки;
• порядок регистрации сообщений об инцидентах этого вида (в том числе виды категории сотрудников банка, которые с наибольшей вероятностью могут обнаружить признаки инцидента; места, где могут быть обнаружены признаки инцидентов (виды информационных систем, ситуаций, иных источников));
• классификацию критичности инцидентов этого вида;
• мотивацию сотрудников банка к регистрации сообщений об инцидентах;
• порядок эскалации и определения шкалы срочности, которая должна быть применена к инцидентам данной категории;
• последовательность действий при реагировании на инцидент, данные об основных участниках процесса реагирования на инциденты и их обязанности;
• процесс анализа последствий инцидента;
• действия по ограничению распространения инцидента, устранению последствий;
• порядок актуализации инцидентов, по которым не все меры выполнены или возможно изменение существенных обстоятельств.
6.1.1.4. Все инциденты подлежат учету. При этом значимые инциденты[28] подлежат детальному учету, т. е. должны фиксироваться обстоятельства инцидента, принятые меры, их результаты, возможные изменения, прежде всего возможные поступления или отчисления, а также планируемые действия и сроки, предложения по вводу процедур недопущения повторений инцидента, по наказанию виновных и т. д. (писок полей приведен в Приложении 4).
6.1.2. Три основных этапа работы с инцидентами.
Работа с инцидентами делится на три этапа:
Этап 1. Обнаружение инцидента и реагирование на него (осуществляет эксперт по инцидентам);
Этап 2. Отчет об обработке инцидента (осуществляет эксперт по инцидентам);
Этап 3. Проверка качества обработки инцидента (осуществляют риск-координатор и риск-менеджер).
Схема 4. Три основных этапа работы с инцидентами
6.1.3. Этап 1. Обнаружение инцидента и реагирование на него.
Вне зависимости от количества субъектов, участвующих в обнаружении инцидента и реагировании на него, в целом за эти действия отвечает одно лицо - соответствующий эксперт по инцидентам.
6.1.3.1. Обнаружение признаков инцидента и регистрация сообщения.
6.1.3.1.1. При обнаружении признаков инцидента[29] незамедлительно осуществляются следующиепервичные действия:
• действия по сохранению жизни и здоровья сотрудников и клиентов и первичные действий по минимизации ущерба от инцидента (при наличии такой обязанности);
• регистрация сообщения об инциденте (по процедуре, установленной для этого вида инцидентов).
6.1.3.1.2. Обнаружить признаки и зарегистрировать сообщение может любой сотрудник банка (регистратор) или непосредственно эксперт по инцидентам. Сотрудник имеет право не регистрировать сообщение об инциденте, когда точно знает, что такая регистрация уже осуществлена другим сотрудником и впоследствии это может быть документально подтверждено.
В тех случаях, когда инцидент произошел, но не был зарегистрирован, привлечению к дисциплинарной ответственности за неисполнение функции регистрации подлежат руководитель подразделения, в котором произошел инцидент. Также в обязательном порядке производится разбирательство, должным ли образом риск-координатор и эксперт по инцидентам организовали процедуры идентификации и регистрации инцидентов (так, чтобы сотрудники банка, которые вероятнее всего могут обнаружить инцидент, знали о признаках таких инцидентов, знали, как регистрировать сообщения об инцидентах (с ними проводилось обучение), и были заинтересованы это делать). Если этого не было сделано, риск-координатор и эксперт по инцидентам также привлекаются к дисциплинарной ответственности.
6.1.3.1.3. Сообщения об инциденте должно поступать на рассмотрение соответствующего эксперта по инцидентам не более 5 минут после факта регистрации.
6.1.3.2. Реагирование на инцидент.
6.1.3.2.1. После осуществления первичных действий и получения сообщения об инциденте эксперт по инцидентам осуществляет следующие действия:
• направляет регистратору инцидента уведомление: "Сообщение об инциденте (название инцидента) принято в работу (Ф.И.О. эксперта по инцидентам)";
• организует дальнейшую локализацию инцидента, устранение его последствий, при необходимости координируя деятельность других лиц, участвующих в работе с инцидентом;
• формирует отчет о работе с инцидентом (не позже 4 часов после регистрации сообщения об инциденте).
6.1.4. Этап 2. Отчет об обработке инцидента.
Эксперт по инцидентам составляет отчет о работе с инцидентом.
В случае если инцидент полностью исчерпан (все меры исполнены, изменений не прогнозируется), то регистратору инцидента направляется уведомление: "Закончена работа с инцидентом (название инцидента) Ф.И.О. эксперта по инцидентам. Подтвердите факт того, что инцидент полностью исчерпан".
В случае если инцидент имеет статус "Не закончен" (по инциденту предполагаются дополнительные меры или прогнозируются изменения), то регистратору инцидента направляется сообщение: "Закончена первичная работа с инцидентом (название инцидента) Ф.И.О. эксперта по инцидентам, об окончании работ будет сообщено дополнительно".
Если инцидент является значимым[30], то эксперт по инцидентам в своем отчете фиксирует детали инцидента согласно полям Приложения 4 и отправляет его на согласование риск-координаторуне позже чем через 4 часапосле регистрации сообщения об инциденте.
6.1.5. Этап 3. Проверка качества обработки инцидента.
Риск-координатор проверяет отчет об обработке инцидента, поступивший от эксперта по инцидентам (не позже чем через 4 часа после отправки отчета экспертом по инцидентам) и совершает следующие действия:
• в случае обнаружения неточностей, фактов о том, что не все обстоятельства установлены, не все прогнозы и планы зафиксированы, он возвращает отчет об инциденте с замечаниями, которые должны быть устранены;
• при отсутствии замечаний он подтверждает правильность и достоверность отчета, факты исполнения перечисленных в нем мер и направляет отчет на проверку риск-менеджерам, которые осуществляют аналогичную проверку отчета об инциденте.
6.1.6. Дополнительная работа с инцидентом.
Эксперт по инцидентам осуществляет дополнительные работы по инциденту и обновляет отчет об инциденте при наступлении следующих событий:
• если отчет об инциденте возвращен риск-координатором или риск-менеджером с замечаниями, которые должны быть устранены;
• если эксперт по инцидентам не успел осуществить все меры в течении четырех часов с момента регистрации сообщения об инциденте (обязанность отправки первичного отчета в течение четырех часов сохранятся);
• если наступил срок для совершения ранее запланированных дополнительных мер по инциденту (например, для установления содержания судебного решения, совершения звонка клиенту, дополнительного выезда и пр.);
• если требование об актуализации инцидента поступило от риск-координатора или риск-менеджера;
• если произошли изменения в обстоятельствах инцидента (например, поступили возмещения по инциденту или выявлены дополнительные убытки).
Все инциденты со статусом "Не закончено" (по инциденту предполагаются дополнительные меры или прогнозируются изменения) должны обновляться экспертом по инцидентам (с обновлением отчета о работе с инцидентом) не реже одного раза в две недели.
6.1.7. Отчетность об инцидентах.
Еженедельно всем руководителям департаментов[31] представляется отчетность об инцидентах, которые относятся к их департаменту (количество инцидентов, убытки, динамика с начала года, наиболее крупные инциденты, крупные инциденты со статусом "Не закончено", инциденты, которые продолжают нести потенциальную угрозу убытка и пр.). Эти отчеты предоставляются риск-менеджерами.
Ежемесячно аналогичные отчеты представляются комитету по рискам.
Ежеквартально аналогичные отчеты представляются Правлению.
Ежегодно отчет об операционных рисках представляется Совету директоров.
Информация об инцидентах с фактическим убытком более 50 тыс. руб.[32] доводится до соответствующих руководителей департаментов, до риск-менеджеров и до директора по рискам не позднее четырех часов с момента обнаружения инцидента. Такие инциденты и осуществляемые по ним меры ставятся на особый контроль (в т. ч. в рамках процедур раздела 6.2).
6.1.8. Технологическая среда учета и обработки инцидентов.
6.1.8.1. Организация учета и обработки инцидентов должна удовлетворять следующим требованиям:
• все сообщения об инцидентах, отчеты об обработке инцидентов, замечания риск-координаторов и риск-менеджеров по отчетам должны фиксироваться на электронных носителях, поддерживающих последующую выгрузку этих данных в excel-таблицы;
• сообщение об инциденте должно маршрутизироваться (передаваться) соответствующему эксперту по инцидентам (для принятия его в работу) и соответствующему риск-координатору (для уведомления о факте инцидента) не позднее 5 минут после регистрации такого сообщения;
• должна поддерживаться маршрутизация (передача) отчетов о работе с инцидентом (по значимым инцидентам) от эксперта по инцидентам к риск-координатору и риск-менеджеру;
• по значимым инцидентам[33] отчет эксперта по инцидентам об обработке инцидента должен содержать обязательный перечень полей, которые должны быть заполнены (см. Приложение 4);
• обновленные выгрузки всех сообщений об инцидентах и отчетов об обработке инцидентов должны производится в формате excel-таблиц, доступном для загрузки в единую базу операционных рисков, на ежедневной основе.
6.1.8.2. Учет и обработка инцидентов[34] может производится в одной из следующих систем:
• в узкоспециализированной системе обработки инцидентов конкретного департамента;
• в единой базе операционных рисков[35].
Выбор использования системы определяется риск-координатором.
6.1.8.3. Если обработка инцидентов в узкоспециализированной системе имеет регулярные сбои и ошибки, не удовлетворяет требованиям нормативных документов банка, риск-менеджеры ставят вопрос о переносе работы с инцидентами из этой системы в единую базу операционных рисков (в комитет по рискам).
6.1.8.4. Для возможности легкой и быстрой регистрации сотрудниками инцидентов банк создает интернет страницу на своем внутреннем сайте с названием: "Сообщить об инциденте или проблеме"[36].
6.1.8.5. При отсутствии автоматизированных систем учета и обработки инцидентов риск-координаторы могут организовывать направление уведомлений по телефону или электронной почте, но с обязательной фиксацией в excel сообщений об инцидентах и отчетов о работе с инцидентами.
6.1.9.Критерии оценки эффективности работы с инцидентами.
6.1.9.1. Эффективность деятельности риск-координаторов в организации работы с инцидентами своего департамента и курируемых им подразделений и сотрудников оценивается по следующим показателям.
1. Количественные показатели: - рост сумм предотвращенных и возмещенных убытков; - рост количества учтенных инцидентов; - снижение времени обработки инцидентов.
2. Качественные показатели: - улучшение качества отчетов об инцидентах; - улучшение регламентов по идентификации инцидентов и их обработке; - улучшение отчетности по инцидентам.
6.1.9.2. Эффективность деятельности риск-менеджеров оценивается по тем же показателям, что отмечены в п. 6.1.9.1, но в разрезе всего банка.
6.2. Компонент No 2. Выявление рисков и их устранение
Выявление рисков и их устранение (минимизация) - это анализ банка на предмет операционных рисков, идентификация рисков, определение мероприятий (рекомендаций) по их минимизации, контроль организации исполнения этих мероприятий владельцами процессов, в которых обнаружены риски.
Банк выделяет четыре этапа выявления рисков и их устранения
6.2.1. Этап 1. Анализ объектов потенциального риска и обнаружение рисков.
6.2.1.1. Субъектами выявления рисков и их устранения являются проверяющие: аудиторы, риск-менеджеры, риск-координаторы (последние в рамках процессов своих департаментов и курируемых подразделений) и специально уполномоченные сотрудники банка (например, сотрудники служб предупреждения мошенничества, юридической службы и др.).
Эти субъекты выявляют риски и формируют рекомендации по их устранению.
6.2.1.2. Объектами анализа могут выступать показатели работы банка, подразделений и сотрудников, отчеты, продукты, процессы, операции, подразделения, системы, нормативные, финансовые и иные документы, внешние факторы, влияющие на банк и иные объекты, которые могут послужить идентификации риска.
6.2.1.3. События, которые вызывают необходимость анализа и идентификации рисков:
• при формировании предложений по запуску / изменению банковского продукта;
• при формировании предложений по изменению бизнес-процессов (включая создание / изменение внутренних нормативных документов, подачу на исполнение бизнес-требований, бизнес-проектов, описывающих такие изменения);
• при изменении организационно-штатной структуры подразделений, их компетенции и выполняемых функций;
• при перераспределении функций и функциональных обязанностей сотрудников внутри подразделения, в том числе в связи с кадровыми назначениями и перестановками;
• при появлении внешних по отношению к банку факторов, влияющих на деятельность подразделений, действие которых будет носить долго- и среднесрочный характер (изменения в законодательстве, природные катаклизмы, техногенные факторы, социальные изменения и др.);
• при реализации катастрофических рисковых событий;
• при поступлении сообщений от системы раннего предупреждения рисков (см. п. 6.3), в т. ч. полученных в рамках самостоятельной оценки подразделениями уровня операционного риска их деятельности (RCSA).
По каждому виду перечисленных событий список проверяющих, которые обязаны провести анализ рисков и дать свое заключение, в числе прочего определяется матрицами полномочий согласно п. 6.7.2.1.5.
6.2.1.4. В некоторых случаях информация о риске или проблеме поступает в виде конкретного сообщения или является очевидной и не требует идентификации (например, обнаружено, что у подразделения нет обязательного отчета верхнего уровня по единому формату или нет показателей эффективности).
6.2.1.5. Риск-менеджеры обучают риск-координаторов так, чтобы они могли самостоятельно идентифицировать риски своего департамента и курируемых департаментом подразделений и сотрудников, классифицировать их и эскалировать на уровень риск-менеджера.
6.2.2. Этап 2. Фиксация риска как рекомендации (в т. ч. её согласование с владельцем процесса, в котором обнаружен риск).
6.2.2.1. Проверяющий, который идентифицировал риск, формирует рекомендацию по форме Приложения 5 (делает описание риска, определяет меры по его устранению или минимизации, владельца процесса, в котором обнаружен риск, сроки, тяжесть риска) и направляет её по e-mail владельцу процесса (см. п. 6.2.2.3), в котором обнаружен риск (самостоятельно или через риск-менеджеров). По взаимному согласию все параметры рекомендации могут корректироваться, однако если в течении 5 рабочих дней проверяющий и владелец процесса не пришли к согласию относительно всех параметров рекомендации по форме Приложения 5, то они выносят этот вопрос на ближайшее заседание комитета по рискам, который принимает окончательное решение.
6.2.2.2. В тех случаях, когда работы по минимизации риска уже ведутся или риск обозначается устранённым (без представления соответствующих подтверждений), рекомендации все равно фиксируются, назначаются к исполнению и будут считаться закрытыми только после проведения процедур по п. 6.2.3.4.
6.2.2.3. Ответственным за организацию исполнения рекомендации всегда обозначается одно лицо (во избежание перекладывания ответственности) - соответствующий руководитель департамента в чьем процессе обнаружен риск. В тех случаях, когда для исполнения рекомендации необходимы доработки информационно технологической структуры (далее ИТ), регламентов, оборудования или его закупки, проведение различных работ (в т. ч. рекламных кампаний, коррекции процессов, продуктов, систем мотивации и т. д.), указанный руководитель организует формирование необходимых требований на такие доработки, закупки, работы (при необходимости согласовывает их с риск-менеджерами) и контролирует их реализацию. При обнаружении некачественного исполнения таких требований ответственный эскалирует эту проблему до уровня риск-менеджера и комитета по рискам.
Ответственность за организацию исполнения рекомендации возлагается на нескольких ответственных только в тех случаях, когда не может возникнуть вероятность ситуации, в которой один ответственный может переложить часть ответственности за неисполнение рекомендации на другого ответственного. Например, рекомендация о представлении отчетов по единому формату может быть возложена на неограниченное число руководителей департаментов, так как каждый из них не сможет обосновать неисполнение рекомендации тем, что другой начальник не представил своего отчета.
6.2.2.4. Снижение уровня отдельных видов операционного риска может быть осуществлено путем внедрения контрольных процедур (согласно п. 6.3.4), передачи риска или его части третьим лицам (аутсорсинг). Аутсорсинг осуществляется на основе договоров, предусматривающих распределение прав, обязанностей и ответственности между банком и поставщиком услуг. Для уменьшения финансовых последствий операционного риска (вплоть до полного покрытия потенциальных операционных убытков) возможно применение различных видов страхования.
6.2.2.5. Для случаев, когда минимизация риска является недостаточной (по мнению риск-координаторов или риск-менеджеров), комитет по рискам (или директор по рискам в зависимости от тяжести риска (см. пп. 4.1.1.3(1), 4.2.1.2(1), 4.2.2.1.) принимает решение о принятии риска или отказе от операций, его обуславливающих.
6.2.2.6. По риску может быть предложен индикатор, отражающий снижение или рост риска (по процедурам п. 6.3.2).
6.2.3. Этап 3. Организация исполнения рекомендаций.
6.2.3.1. Ответственный, назначенный согласно п. 6.2.2.3, организует исполнение рекомендаций.
6.2.3.2. Списки всех обнаруженных проверяющими рисков и сформированных ими рекомендаций передаются для единого учета и контроля риск-менеджерам в формате Приложения 5. Риск-менеджеры учитывают эти рекомендации как меры по устранению рисков, следят за тем, чтобы не было дублирующихся рекомендаций, учитывают их в реестре рисков в рамках функционирования системы раннего предупреждения рисков (см. п. 6.3.7).
6.2.3.3. Не реже одного раза в месяц риск-менеджер по e-mail затребует от исполнителей рекомендаций промежуточные отчеты о состоянии исполнения рекомендаций, возникающих проблемах и необходимости их эскалации. В случае если отчеты не представляются, рекомендация в отчете перед Правлением банка приобретает статус проблемной.
6.2.3.4. Рекомендация считается закрытой, когда владелец процесса представил документ, подтверждающий устранение риска (служебную записку, приказ, регламент, заключение), а проверяющий и риск-менеджер лично проверили исполнение рекомендации и подтвердили это своим экспертным мнением. В случае если в течение 5 рабочих дней проверяющий и владелец процесса не пришли к согласию относительно факта исполнения / не исполнения рекомендации риск-менеджер выносит этот вопрос на ближайшее заседание комитета по рискам, который принимает окончательное решение.
6.2.4. Этап 4. Ежеквартальный отчет об исполнении рекомендаций владельцами процессов.
6.2.4.1. Не реже одного раза в квартал риск-менеджер формирует единый отчет для Правления банка о количестве рисков и прогресса их устранения по форме Приложения 6 с проектом решения о предупреждении владельцев процессов, допускающих нарушения в устранении своих рисков (непринятие рекомендации к исполнению, нарушение сроков). При неоднократном вынесении предупреждений владельцам процессов риск-менеджер ставит вопрос о привлечении их к дисциплинарной ответственности.
6.2.4.2. Каждый выявленный риск и меры по нему должны быть также учтены в реестре рисков (по процедурам п. 6.3.7).
6.2.5. Критерии оценки эффективности выявления рисков и их устранения.
6.2.5.1. Эффективность деятельности риск-координаторов по организации выявления рисков своего департамента и курируемых им подразделений и сотрудников (и устранения этих рисков) оценивается по следующим показателям.
1. Количественные показатели: - рост сумм обнаруженных рисков; - рост сумм предотвращенных рисков; - увеличение количества устраненных рисков (рекомендаций); - увеличение количества проверенных процессов.
2. Качественные показатели: - улучшение регламентов; - улучшение отчетности по рискам.
6.2.5.2. Эффективность деятельности риск-менеджеров оценивается по тем же показателям что отмечены в п. 6.2.5.1, но в разрезе всего банка.
6.3. Компонент No 3. Система раннего предупреждения рисков
Обеспечение раннего предупреждения рисков (их аналитический мониторинг) производится для измерения уровня операционного риска (текущего и прогнозного) с целью последующего осуществления управляющих воздействий по минимизации рисков.
Субъекты управления операционными рисками обеспечивают аналитический мониторинг рисков в рамках следующих форматов:
6.3.1. Самооценка рисков.
6.3.1.1. Самооценка рисков - это оценка операционных рисков подразделениями, в ходе которой они сами оценивают и представляют информацию о том, какие риски возникают в ходе деятельности их подразделения, как их можно предотвратить, каковы величина и частота потерь и др.
6.3.1.2. Основными параметрами самооценки являются:
• предмет самооценки (вид оцениваемого риска, процесса или операции);
• источники самооценки (категории или списки сотрудников, которые будут проходить самооценку рисков);
• регулярность самооценки;
• способ самооценки (заполнение сотрудниками подразделений анкет или прохождение ими интервью и опросов);
• присутствие независимых лиц (ответы в присутствии риск-менеджеров, риск-координаторов) или без такового;
• инструмент фиксации ответов (заполнение в базе рисков (что наиболее целесообразно для обеспечения анонимности) или в иных системах, или в excel-таблицах, или в бумажной форме).
6.3.1.3. Данные о том, какие ответы дали конкретные сотрудники являются закрытыми (не разглашаются). Проверку этих данных при необходимости может осуществить только подразделение по аудиту, внешние аудиторы или представители ЦБ РФ.
6.3.1.4. В исключительной компетенции риск-менеджеров находится:
• право инициирования проведения самооценки в подразделениях;
• определение параметров самооценки;
• содержание вопросов анкет, программ опросов и интервью самооценки;
• анализ данных, собранных в ходе самооценки;
• подготовка заключений и отчетов о самооценке;
• разработка регламентов и методик о порядке проведения самооценки.
6.3.1.5. При необходимости риск-менеджер может пользоваться помощью риск-координаторов для формулирования вопросов анкет, контроля за своевременностью заполнения анкет и пр.
6.3.1.6. Использование самооценки имеет ограничение: один и тот же сотрудник может отвлекаться от работы для дачи ответов на вопросы самооценки не чаще одного раза в квартал не более чем на один час.
6.3.2. Мониторинг ключевых индикаторов рисков.
6.3.2.1. Система ключевых индикаторов рисков (КИР) - это показатели или параметры, отражающие текущий уровень различных видов операционного риска банка, которые служат для обнаружения тенденций превышения уровня операционного риска над его предельным уровнем и осуществления упреждающих управляющих воздействий по минимизации этих рисков.
6.3.2.2. Основными параметрами индикаторов рисков являются:
• предмет индикатора (вид оцениваемого риска) и название индикатора;
• формула расчета индикатора;
• лимиты (пороговые значения) индикатора - пределы зеленой зоны значений индикатора (ситуация в пределах нормы), желтой (обострение ситуации, увеличение масштабов), красной (критическая ситуация);
• источники индикатора (категории или списки сотрудников, которые будут представлять или рассчитывать значение индикатора, или виды систем, из которых это значение будет браться, а также риск-координаторов, курирующих конкретные индикаторы);
• регулярность сбора значений индикатора;
• инструмент фиксации значений (заполнение в базе рисков, или в иных системах, или в excel-таблицах, или в бумажной форме);
• периодичность пересмотра эффективности индикатора.
6.3.2.3. В исключительной компетенции риск-менеджеров находится:
• право на установление индикаторов в подразделениях;
• определение параметров индикаторов;
• анализ данных индикаторов;
• подготовка заключений и отчетов об индикаторах;
• разработка общих регламентов и методик о порядке функционирования индикаторов и эскалации информации для принятия управленческих воздействий по минимизации рисков.
6.3.2.4. Система пороговых уровней (лимитов) КИР должна являться составной частью риск-аппетита и служить метрикой допустимого уровня операционного риска банка. Пороговые значения должны быть обоснованы и задокументированы, а также должны пересматриваться на регулярной основе.
6.3.2.5. При необходимости риск-менеджер может пользоваться помощью риск-координаторов для определения параметров индикаторов риска и контроля за своевременностью представления сотрудниками значений КИР.
6.3.2.6. Риск-координаторы несут ответственность за контроль своевременности представления значения индикаторов, которые они курируют, достоверность расчетов этих значений, организацию разработки порядка действий для ситуаций, когда значение индикатора переходит в желтую зону, и для ситуаций, когда оно переходит в красную зону.
6.3.3. Мониторинг ключевых показателей эффективности управления риском.
6.3.3.1. Субъекты управления операционными рисками устанавливают систему и критерии оценки эффективности управления операционными рисками во внутренних документах.
6.3.3.2. Соответствующий внутренний документ должен быть разработан прежде всего подразделением по аудиту для контроля за эффективностью принятых подразделениями и органами управления мер, обеспечивающих снижение уровня выявленных рисков, или документирование принятия руководством подразделения и (или) органами управления решения о приемлемости выявленных рисков (в соответствии с Положением ЦБ РФ от 16 декабря 2003 г. N 242-П). Подразделение по аудиту каждый год проводит анализ и формирует отчет перед Правлением банка о результатах соответствия системы управления риском критериям оценки её эффективности.
6.3.4. Мониторинг ключевых контролей риска.
6.3.4.1. Система ключевых контролей риска - это перечень контрольных процедур (например, обязательная проверка и акцепт платежной операции вторым сотрудником), исполнение которых минимизирует вероятность наступления инцидентов или иных негативных последствий риска. Контроли риска могут использоваться не только для предотвращения инцидентов, но и для их обнаружения (например, контрольные выгрузки / выборки фактов выдач кредитов клиентам с наличием просроченной задолженности).
6.3.4.2. Контрольные процедуры подлежат регулярному тестированию и пересмотру на предмет их влияния на остаточный риск. Перечень контрольных процедур и периодичность их тестирования должна учитываться в матрице контрольных процедур и матрице рисков (см. п. 6.3.7).
6.3.4.3. С целью наиболее полного охвата бизнес-процессов подразделений риск-координаторы заполняют / обновляют контроли в следующей последовательности:
• определяются бизнес-процессы подразделения;
• определяются основные риски, связанные с этими процессами, типичные инциденты для этих процессов;
• для каждого риска указывается его уровень, определяются существующие контрольные процедуры, способствующие его снижению;
• если контрольная процедура отсутствует либо она очевидно неэффективна, проектируются тесты, которые позволят проверить эффективность работы контрольной процедуры в целях снижения соответствующего ей риска;
• устанавливается периодичность тестирования.
6.3.4.4. По результатам тестирования контрольные процедуры совершенствуются с целью снижения связанных с ними рисков.
6.3.4.5. В случае, если невозможно или нецелесообразно введение/изменение контрольных процедур с целью снижения вероятности/тяжести последствий реализации риска, данный риск может быть принят.
6.3.4.6. Принятие риска допустимо в случаях, если возможные потери от реализации риска приемлемы для банка, и при этом введение/изменение контрольной процедуры по управлению этим риском:
• требует значительных материальных затрат либо затрат труда (в частности, значительных изменений в бизнес-процессах банка, закупки оборудования, доработки программного обеспечения);
• нецелесообразно в силу запланированных значительных изменений бизнес-процесса, устраняющих либо значительно снижающих данный риск.
6.3.4.7. Субъекты, которые имеют право принять риски, и лимиты их полномочий определены пп. 4.1.1.3(1), 4.2.1.2(1), 4.2.2.1.
6.3.5. Сценарный анализ рисков и стресс-тестирование.
6.3.5.1. Сценарный анализ и последующее стресс-тестирование - это моделирование возможного возникновения стрессовых ситуаций и сценариев их развития в оцениваемых процессах и операциях, которые могут привести к существенным убыткам и рискам (сценарный анализ) и последующее моделирование распределения частоты возникновения и размеров убытков (стресс-тестирование). Сценарный анализ направлен на получение оценки маловероятных, но возможных и крайне значительных по тяжести потерь. Экспертные заключения о таких сценариях могут даваться любыми специалистами банка, имеющими соответствующие познания о процессе или операции, которые подвергаются оценке, а также риск-менеджерами.
6.3.5.2. Основными параметрами сценарного анализа и стресс-тестирования являются:
• предмет анализа (вид оцениваемого риска, процесса или операции);
• источник получения экспертных заключений (категории или списки сотрудников, которые будут производить экспертное моделирование ситуаций и сценариев и представлять эти данные);
• регулярность анализа;
• способ получения экспертных заключений (заполнение сотрудниками подразделений анкет или прохождение ими интервью и опросов);
• присутствие независимых лиц (дача заключений в присутствии риск-менеджеров, риск-координаторов или без такового);
• инструмент фиксации экспертных заключений (заполнение в базе рисков (что наиболее целесообразно для обеспечения анонимности) или в иных системах, или в excel-таблицах, или в бумажной форме).
6.3.5.3. В исключительной компетенции риск-менеджеров находится:
• право инициирования проведения сценарного анализа и стресс-тестирования в подразделениях (далее анализа);
• определение параметров анализа;
• содержание вопросов анкет, опросов и интервью о предмете анализа;
• оценка данных, собранных в ходе анализа;
• подготовка заключений и отчетов об анализе;
• разработка регламентов и методик о порядке проведения анализа.
6.3.5.4. При необходимости риск-менеджер может пользоваться помощью риск-координаторов для формулирования вопросов анкет, контроля за своевременностью заполнения анкет и пр.
6.3.5.5. Использование сценарного анализа и стресс-тестирования имеет ограничение: не чаще одного раза в квартал один и тот же сотрудник может отвлекаться от работы для дачи ответов на вопросы не более чем на один час.
6.3.6. Анализ внешних потерь от операционных рисков.
6.3.6.1. Банк обеспечивает учет и анализ инцидентов, произошедших в других банках (бенчмаркинг). Такая работа осуществляется в целях предотвращения возможности возникновения таких инцидентов в банке и для минимизации вероятности наступления таких событий (впоследствии минимизация рисков таких инцидентов осуществляется по процедуре п. 6.2). Данные о таких инцидентах в обязательном порядке используются также в расчете размера операционного риска продвинутым способом (в рамках процедур п. 6.3.8.).
6.3.6.2. Учет производится после изучения обстоятельств инцидента и только в случае если банк признает, что аналогичные инциденты в банке не происходили и имеется вероятность того, что они могут произойти (банк осуществляет операции в рамках, которых произошел инцидент и отсутствуют технические и иные процедуры предотвращения таких инцидентов). Исходя из величины банка, в котором произошли инциденты, банк должен масштабировать (увеличить / уменьшить) такие потери применительно к своему масштабу[37].
6.3.6.3. Риск-менеджеры организуют функционирование базы рисков для возможности регистрации в ней инцидентов, произошедших в других банках. Риск-координаторы и эксперты по инцидентам обязаны регистрировать инциденты, произошедшие в других банках, о которых им стало известно (здесь их эффективность оценивается по показателю роста количества учтенных внешних инцидентов и улучшению качества их учета).
6.3.6.4. Риск-менеджеры могут также наладить регулярное получение такой информации из других источников (от организаций или источников, специализирующихся на учете такой информации, например из базы SAS OpRisk Global Data).
6.3.7. Ведение и оценка реестра рисков и карт рисков.
6.3.7.1. Реестр / матрица операционных рисков представляет собой базу данных с возможностью ввода, структурирования, хранения, обработки информации о выявленных операционных рисках банка и статусе работ по их оптимизации.
6.3.7.2. Целью ведения реестра операционных рисков является систематизация информации о выявленных банком рисках, их параметрах, результатах оценки и самооценки, контрольных процедур, поддержание информации об операционных рисках в актуальном состоянии. С помощью реестра операционных рисков осуществляется также контроль и мониторинг выполнения мероприятий по управлению операционными рисками.
6.3.7.3. Реестр операционных рисков включает в себя следующую информацию:
• описание операционного риска;
• информацию о владельце риска (подразделении и риск-координаторах, в чьей компетенции находится обязанность по минимизации операционного риска и работы с инцидентами, от его реализации);
• риск-факторы;
• описание контрольных процедур, направленных на минимизацию риска;
• оценку уровня операционного риска;
• описание запланированных мер по управлению операционным риском и статус их исполнения;
• выбранный банком метод управления операционным риском (обоснованное принятие, перенос, минимизация, отказ от вида деятельности);
• списки инцидентов, произошедших от реализации операционного риска;
• списки внешних инцидентов (в других банках), произошедших от реализации такого риска.
6.3.7.4. Реестр операционных рисков по усмотрению банка может включать в себя и другую информацию.
6.3.7.5. Реестр операционных рисков включает информацию о них, полученную в результате исполнения любого из 7 компонентов управления операционными рисками, предусмотренных разделом 6.
6.3.7.6. Риск-менеджеры организуют функционирование реестра рисков. Риск-координаторы обязаны регистрировать и обновлять в реестре рисков всю информацию о рисках своего департамента, курируемых им подразделений и сотрудников. Риск-менеджеры оказывают методическую поддержку в процессе ввода и актуализации информации, а также осуществляют контроль соответствия зарегистрированной в реестре рисков информации установленным требованиям.
6.3.8. Расчет размера операционного риска (VaR OpRisk).
6.3.8.1. Размер операционного риска банка может рассчитываться различными способами:
1. Базовым индикативным подходом (согласно требованиям Базель II и/или нормативных документов Банка России, в том числе, положению Банка России 346-П от 03.11.2009);
2. Стандартизованным подходом (согласно требованиям Базель II и/или нормативных документов Банка России);
3. Усовершенствованным ("продвинутым") подходом (АМА) (согласно требованиям внутренних методик банка, разработанных во исполнение Базель II и/или нормативных документов Банка России);
4. Управленческим прогнозным подходом с учетом планов развития бизнеса (согласно внутренним методикам банка).
6.3.8.2. Во всех случаях когда операционный риск, рассчитанный согласно перечисленным выше подходам, предполагается к использованию в расчете показателей / нормативов банка для их представления в Банк России (например, в расчете показателя Н1 - достаточность капитала), применение такого подхода должно осуществляться согласно нормативному документу Банка России или подлежит предварительному согласованию с ним.
6.3.8.3. Размер операционного риска, полученный согласно каждому из способов, может быть различным исходя из особенностей учета (РСБУ, МСФО, внутренней управленческой отчетности).
6.3.8.4. Расчет размера операционного риска в рамках п. 6.3.8.1(а) осуществляется подразделениями банка, ответственными за учет банка по РСБУ, МСФО. Расчет размера операционного риска в рамках пп. 6.3.8.1(b-d) осуществляется подразделением по операционным рискам.
6.3.8.5. Расчет размера операционного риска регламентируется нормативными документами банка.
6.3.8.6. Расчет риска продвинутым способом в обязательном порядке должен основываться на анализе следующих данных (помимо анализа исторических данных об инцидентах):
1. Данных самооценки рисков (согласно п. 6.3.1).
2. Данных мониторинга ключевых индикаторов рисков (согласно п. 6.3.2).
3. Данных сценарного анализа рисков и стресс-тестирования (согласно п. 6.3.5).
4. Данных о внешних потерях от операционных рисков (согласно п. 6.3.6).
6.3.9. Эскалация рисков, идентифицированных аналитическим мониторингом.
6.3.9.1. При обнаружении рисков в рамках аналитического мониторинга риск-менеджер или риск-координатор инициирует работу с ними в рамках процедур п. 6.2.
6.4. Компонент No 4. Обеспечение непрерывности деятельности
Обеспечение непрерывности и возобновления деятельности (далее - ОНиВД) осуществляется в соответствии с Приложением 5 к Положению No 242-П для определения целей, задач, порядка, способов и сроков осуществления комплекса мероприятий по предотвращению или своевременной ликвидации последствий возможного нарушения режима повседневного функционирования банка и его подразделений, вызванного непредвиденными обстоятельствами (возникновением чрезвычайной ситуации или иным событием, наступление которого возможно, но трудно предсказуемо и связано с угрозой существенных материальных потерь или иных последствий, препятствующих выполнению кредитной организацией принятых на себя обязательств).
6.4.1. Обеспечение непрерывности деятельности регламентируется двумя группами нормативных документов:
• планами непрерывности деятельности критичных процессов (BCP[38]);
• памятками действий сотрудников при чрезвычайных ситуациях;
• дополнительными документами, при недостаточности упомянутых выше, например, DRP[39].
6.4.2. Планы непрерывности деятельности банка.
План ОНиВД представляет собой совокупность модулей, каждый из которых описывает действия подразделений банка по одному критичному процессу, функции или обстоятельству. Бланк плана состоит из следующих основных частей:
Часть I. О непрерывности деятельности исполнителей процесса
• описание критически важной функции исполнителей;
• действия при выбытии исполнителей;
• действия при сбое программных и технических ресурсов;
• действия при выбытии помещений, используемых исполнителями;
• действия при наступлении иных чрезвычайных обстоятельств.
Часть II. О непрерывности деятельности серверного программного обеспечения (ПО), используемого в процессе
• описание ПО, расположенного на серверах, описание серверов и каналов связи, используемых в критически важной функции, SLA (соглашение об уровне обслуживания серверов и информационных систем на серверах);
• действия при сбое ПО, расположенного на серверах, серверов и каналов связи;
• действия при выбытии помещений, в которых расположены серверные программы;
• действия при выбытии исполнителей, обеспечивающих функционирование серверных программ, серверов и каналов связи;
• действия при наступлении иных чрезвычайных обстоятельств, связанных с серверами и приведших к нарушению критически важной функции.
6.4.3. Бланк плана представлен в Приложении 7. Он заполняется риск-координаторами тех департаментов, чьи процессы признаются для банка значимыми (в части I п. 6.4.2) и риск-координатором ИТ-подразделения (в части II п. 6.4.2). Список значимых процессов обозначен в Приложении 8. Принципиальный подход разработки, согласования, утверждения, пересмотра и проверки (тестирования) плана ОНиВД представлен на схеме 5.
6.4.4. Памятки действий сотрудников при чрезвычайных ситуациях готовятся риск-координаторами, ответственными за работу с тем или иным видом чрезвычайной ситуации (ЧС). При необходимости памятки о различных ЧС могут объединяться.
6.4.5. Банк стремится обеспечивать непрерывность своей деятельности с минимальными издержками - резервные рабочие места по возможности должны размещаться на рабочих местах и компьютерах, используемых другими сотрудниками некритичных функций.
6.4.6. Правила и особенности деятельности по обеспечению непрерывности деятельности банка регламентируются нормативными документами банка.
6.5. Компонент No 5. Координация работы департаментов в управлении рисками
6.5.1. Согласно разделу 4 настоящих Рекомендаций для управления операционными рисками в банке существуют три линии защиты[40]:
1-я линия защиты - все подразделения банка, которые работают с операционными рисками на месте его возникновения.
Выделяют три вида ответственных:
• риск-координаторы (начальники департаментов и назначенные лица);
• эксперты по инцидентам;
• регистраторы (все сотрудники подразделения).
2-я линия защиты - субъекты, которые координируют в целом всю систему управления операционными рисками:
• комитет по рискам или иной комитет, наделенный соответствующими полномочиями (далее - комитет по рискам);
• директор по рискам[41];
• риск-менеджеры[42].
3-я линия защиты - подразделение внутреннего аудита (далее - подразделение по аудиту), которое осуществляет независимый аудит системы управления операционными рисками. Ответственные - аудиторы.
Визуальная схема субъектов, управляющих операционными рисками, и их задач представлена на схеме 2.
6.5.2. Порядок назначения, права и обязанности этих субъектов обозначены в разделе 4 настоящих Рекомендаций. Формат их работы, особенности взаимодействия, обучения и координации обозначены в остальных разделах прежде всего в разделе 6.
6.5.3. Риск-менеджеры контролируют, чтобы структура субъектов управления операционными рисками соответствовала требованиям раздела 4 настоящих Рекомендаций, а формат их работы соответствовал требованиям всех разделов Рекомендаций и детализирующих её нормативных документов банка. Каждое несоответствие обозначается риском с уровнем "высокий", и решается в рамках процедур раздела 6.2.
6.5.4. Риск-менеджеры особое внимание уделяют организации следующих координирующих действий:
6.5.4.1. Актуализация списков ответственных за работу с операционными рисками своих подразделений (риск-координаторов - по правилам п. 4.1.1 и экспертов по инцидентам - по правилам п. 4.1.2), определение их прав в автоматизированной системе управления операционными рисками (если таковая внедрена в банке).
6.5.4.2. Обучение вышеназванных сотрудников, оказание им помощи в написании методик управления операционными рисками департамента, оперативная координация такой работы.
6.5.4.3. Мониторинг эффективности работы с операционными рисками (по правилам п. 6.2.5) и инцидентами (по правилам п. 6.1.9), контроль дисциплины, поддержание мотивации сотрудников к повышению эффективности управления своими операционными рисками.
6.5.4.4. Обеспечение всех подразделений актуальными отчетами об их операционных рисках (по правилам п. 6.6), эскалация вопросов о проблемах операционных рисков (по правилам п. 6.2).
6.5.4.5. Выполнение функций арбитра при разграничении компетенции по работе с рисками или инцидентами между подразделениями. Установление общих правил работы всех департаментов со своими операционными рисками и инцидентами, лимитами прав на решения об операционных рисках.
6.6. Компонент No 6. Построение системы отчетности о рисках и поддержка базы рисков
6.6.1. Отчетность о рисках.
6.6.1.1. Система отчетности банка об операционных рисках - это совокупность технического, программного и организационного обеспечения, а также персонала, предназначенная для того, чтобы своевременно обеспечивать внутренние структуры банка и внешних контрагентов надлежащей информацией об уровне операционного риска в банке с целью эффективного управления.
6.6.1.2. Банк, в числе прочего составляет следующие виды отчетности об операционных рисках (пример деления приведен на схеме 6):
• сигнальные (для немедленной эскалации мер) - см. Приложение 9.1[43];
• о KPI[44] субъектов, управляющих операционными рисками (для оценки эффективности их деятельности) - см. пп. 6.1.9, 6.2.5, 6.6.3;
• общеаналитические (для оценки ситуации и тенденций по операционным рискам, последующей выработки мер) - см. Приложение 9.2.
6.6.1.3. Риск-менеджеры готовят отчет об уровне операционного риска и представляют его на рассмотрение департаментов и территориальных дирекций, управлений, филиалов[45] (еженедельно), комитета по рискам (ежемесячно), Правления банка (ежеквартально), Совета директоров (ежегодно) и иных уполномоченных субъектов (по требованию). Отчеты должны быть подготовлены: на основании данных/отчетов, получаемых от ответственных подразделений по управлению операционными рисками по направлению деятельности и/или из систем банка, в четкой, сжатой и логичной форме. Отчеты должны содержать описание и оценку рисков, их концентрацию и динамику, прогнозы, предлагаемые меры по их минимизации, сведения об исполнении мер по устранению риска, аллокацию капитала под операционный риск и прочую информацию по операционным рискам. Требования к отчетности по инцидентам изложены также в п. 6.1.7.
6.6.1.4. Процедуры принятия мер минимизации и предотвращения рисков в соответствии с информацией, содержащейся в отчетности, порядок действий, ответственность должностных лиц за принятие мер, контроль исполнения мер определяются в подразделе 6.2.
6.6.1.5. С риск-менеджерами должны предварительно согласовываться все отчеты подразделений, содержащие информацию об операционных рисках (об инцидентах, о рисках, проблемах, обусловливающих операционный риск и о мерах минимизации рисков).
6.6.1.6. Информация об операционном риске должна быть широко представлена во внутренней отчетности об общем уровне риска, принимаемого на себя банком; в управленческой отчетности, в том числе в целях анализа риска и распределения (внутреннего размещения) капитала в соответствии с концепцией экономического капитала).
6.6.1.7. Риск-менеджеры отвечают за разработку и реализацию внутренней системы отчетности по вопросам операционного риска.
Схема 6. Пример группировки отчетов по операционным рискам
6.6.2. Поддержка базы рисков.
6.6.2.1. Для обеспечения удобства исполнения риск-процедур (обработки инцидентов, проверки процессов, контроля исполнения мер минимизации рисков и т. д.), для осуществления онлайн контроля за эффективностью этих процедур, для возможности формирования отчетов и прогнозов о рисках вся работа с рисками должна производиться подразделениями банка в единой базе операционных рисков[46]. Риск-менеджеры обеспечивают функционирование единой базы операционных рисков[47].
6.6.3. Критерии оценки эффективности системы отчетности об операционных рисках.
6.6.3.1. Эффективность деятельности риск-менеджеров по построению системы отчетности о рисках оценивается по следующим показателям:
1. Количественные показатели: - количество департаментов, получающих отчеты об ОР; - количество отчетов об ОР, представляемых в департаменты; - количество исполненных, запросов на доработку отчетов об ОР;
2. Качественные показатели: - степень удовлетворенности департаментов отчетами об ОР; - бесперебойная работа базы инцидентов и рисков; - выполнение запросов на отчеты; - использование методики расчета операционного риска продвинутым способом.
6.7. Компонент No 7. Контроль соблюдения стандартов минимизации рисков
Для целей недопущения основной массы операционных рисков на первичном (зачаточном) уровне их возможного возникновения банк определяет 5 видов базовых стандартов, обязательность соблюдения которых способствует предотвращению операционных рисков:
1. Стандарты целевой структуры показателей банка.
2. Стандарты целевой продуктово-процессной структуры.
3. Стандарты целевой организационной структуры.
4. Стандарты целевой ИТ-архитектуры и технологий.
5. Стандарты целевой структуры нормативных документов (норм. документов).
6.7.1. Стандарты целевой структуры показателей банка
Банк отмечает особую важность назначения целей, которые он должен достигнуть (целевых показателей руководства банка и сотрудников банка).
Отсутствие зафиксированных целей, их формальность или неактуальность (бесцельность), отсутствие системы коррекции целей и контроля их достижения, отсутствие системы мотивации и культуры к достижению целей банк определяет как системообразующий высокий операционный риск, который влечет неэффективность управления всеми процессами банка и неэффективность их исполнения (в соответствии с требованиями п. 3.1).
Банк выделяет следующие виды целевых показателей[48]:
• показатели для банка в целом (по которым Правление должно отчитываться перед Советом директоров);
• показатели для департаментов (по которым департаменты должны отчитываться перед Правлением);
• показатели для сотрудников (по которым сотрудники отчитываются перед руководством департаментов).
6.7.1.1. Показатели для банка в целом (по которым Правление должно отчитываться перед Советом директоров).
В качестве таких показателей могут выступать критерии о риск-аппетите (границах, которые не должен пересекать банк), а также целевые показатели, например, следующие:
• целевой кредитный рейтинг рейтинговых агентств (например, банк будет стремится к поддержанию рейтинга не ниже X);
• достаточность общего капитала (например, целевой уровень достаточности общего капитала: >=X);
• норматив Н1 ЦБ РФ (например, целевой уровень достаточности по нормативу Н1: X %);
• соотношение доступных финансовых ресурсов к эк. капиталу (например, целевой уровень > X %);
• концентрации по отраслям / продуктам / сегментам.
Примерный перечень таких показателей приведен в Приложении 10.
6.7.1.2. Показатели для Департаментов (по которым Департаменты должны отчитываться перед Правлением).
Для Бизнес-департаментов в качестве таких показателей могут выступать, например, следующие:
• чистая прибыль;
• рост клиентского привлечения;
• рост кредитного портфеля;
• доля комиссионных доходов в общем доходе;
• прибыльность / эффективность;
• проблемная задолженность / кредитный портфель;
• количество активных клиентов.
Для каждого департамента, в т. ч. для департаментов поддержки, показатели назначаются индивидуально.
6.7.1.3. Показатели для отделов и сотрудников (по которым сотрудники должны отчитываться перед руководством департаментов).
Для сотрудников показатели устанавливаются руководством департаментов.
6.7.1.4. Особые условия построения структуры показателей банка.
6.7.1.4.1. Банк обозначает размер убытков и количество значимых инцидентов в качестве понижающего коэффициента оценки всех руководителей банка.
Целевые показатели членов правления и руководителей подразделений должны иметь понижающие коэффициенты уровня операционных рисков в курируемых ими процессах[49].
6.7.1.4.2. Банк обозначает размер предотвращенных убытков и рисков от несовершенства банковских процессов повышающим коэффициентом оценки всех руководителей банка.
Целевые показатели членов правления и руководителей подразделений должны иметь повышающие коэффициенты уровня предотвращенных убытков и устраненных ими банковских операционных рисков (в т. ч. в процессах не находящихся в сфере курирования конкретного руководителя)[50]. Высокий уровень предотвращенных подразделениями убытков и рисков должен вознаграждаться соответствующим образом, и такие факты должны широко рекламироваться в банке.
6.7.1.4.3. Банк обеспечивает прозрачность и контролируемость показателей.
Для контроля за ситуацией с показателями каждый отдел банка[51] формирует ежемесячный отчет на одном-двух слайдах со следующим содержанием:
• производительность отдела (количество осуществленных операций) - помесячный график за прошедшие полгода от текущей даты (план / факт);
• качество результатов (доля операций с хорошим результатом, без результата, с плохим результатом) - помесячный график за прошедшие полгода от текущей даты (план / факт);
• общая оценка работы (хорошо / плохо в виде интуитивно понятной пиктограммы);
• список всех показателей отдела (значения плана, факта, процента достижения плана оценки (плохо / хорошо в виде интуитивно понятных пиктограмм));
• причины, повлиявшие на текущее значение показателей;
• предпринимаемые меры по улучшению показателей;
• эффективность предшествующих мер;
• Ф.И.О. руководителя подразделения и количество сотрудников, выполнявших операции.
Все отчеты должны соответствовать единому формату, приведенному в Приложении 11 (в том числе форме графиков, формату легенд графиков (начинающихся со слов "Хороший результат:...", "Без результата", "Плохой результат:..."), цветовой гамме и т. д.). Плановые значения определяются с учетом бенчмаркинга[52] (о чем должны быть соответствующие пояснения).
Указанные отчеты не реже одного раза в месяц должны заслушиваться руководителями департаментов и широко использоваться в отчетности банка. Для обеспечения объективного контроля за актуальностью показателей, учета рисков, повлиявших на текущие значения показателей, и контроля за мерами по их минимизации такие отчеты должны ежемесячно проверяться риск-координаторами (по курируемым ими подразделениям) и направляться риск-менеджерам.
Если указываемые начальниками отделов названия показателей, их нормативные значения (план), отчетные данные об их достижении (факт), формы графиков или таблиц, причины, повлиявшие на изменение значения показателей, меры по улучшению показателей носят формальный, нерепрезентативный характер или не отвечают условиям наилучших практик, риск-координатор или риск-менеджер выносит вопрос на комитет по рискам об обнаружении несоответствий с предложением оптимального альтернативного варианта. Комитет по рискам утверждает или отклоняет изменения.
6.7.1.4.4. Банк поддерживает различные схемы мотивации сотрудников.
Для усиления мотивации сотрудников банк стремится внедрять и использовать различные дополнительные системы мотивации.
В частности, в банке должна использоваться система карьерного роста с прозрачными правилами, и очевидными массовыми примерами роста конкретных сотрудников. Так, внутри групп сотрудников, выполняющих схожие операции (например, андеррайтеры, коллекторы или верификаторы), операции должны группироваться по уровням сложности (1-й класс, 2-й класс и т. д.), а сотрудники - по квалификации, соответствующей группе операций той или иной сложности. Чем выше сложность операций, тем выше должен быть повышающий коэффициент мотивации и тем выше должна быть должность (например, верификатор 7-го класса). Сотрудники стремятся повышать свою квалификацию и получать должность более высокого класса (с повышенной сложностью работы и повышенным коэффициентом мотивации)[53].
Дополнительно может использоваться премирование сотрудников не только деньгами, но и балами или бонусами, на которые они могут выбирать конкретные подарки из заранее утвержденного списка.
Возможно использование системы наставничества руководителями банка наиболее продвинутых сотрудников (ежемесячные личные встречи наставника с наставляемыми сотрудниками, участие наставляемых в каких-либо совещаниях, деловых обедах или мероприятиях "рабочий день с руководителем" и т. д.).
Не исключается использование системы имиджевого стимулирования, например, премирование отличившихся сотрудников какими-либо дефицитными возможностями (возможностью посещения закрытых деловых мероприятий или мероприятий, на которые очень длинная очередь).
6.7.1.4.5. Банк поддерживает культуру постоянного улучшения эффективности сотрудников.
Для ознакомления с количественными достижениями сотрудников банк создает интернет-страницу на своем внутреннем сайте с названием: "Достижения сотрудников по производительности"[54]. На этой странице должны приводиться списки сотрудников, сегментированные по сопоставимости работ и отсортированные по производительности (1-е, 2-е и последующие места) с указанием примененных к ним мер поощрения. Страница должна обновляться не реже одного раза в две недели и хранить историю за квартал. Как минимум все действующие сотрудники сети должны иметь возможность сопоставлять свою результативность с результативностью других сотрудников с помощью этой страницы (с учетом уровней конфиденциальности).
При отсутствии возможности создания такой страницы, указанные списки должны рассылаться по группам сотрудников не реже раза в две недели.
6.7.1.4.6. Миссия, цели банка, цели подразделений и сотрудников не должны противоречить общечеловеческим ценностям.
Устанавливаемые руководством миссия банка, его цели, а также цели подразделений и сотрудников не должны противоречить общечеловеческим ценностям, принципам морали и этики, охраны труда, охраны окружающей среды.
6.7.1.5. Сервисная среда построения структуры показателей банка.
Банк поддерживает сервисную среду, которая обеспечивает назначение актуальных стратегических целевых показателей и обеспечивает контроль за их достижением.
Для этого банк назначает ответственное подразделение, которое:
• разрабатывает порядок установления целевых показателей; организует определение показателей и их нормативных значений на горизонт 5 лет (с учетом стратегических целей банка и инициатив подразделений); разрабатывает соответствующий план-график ввода или упразднения показателей на 5 лет и контролирует его исполнение;
• разрабатывает порядок представления подразделениями значений показателей и их проверки; определяет формат показателей и их параметров; собирает значения показателей и проверяет их достоверность; формирует единый реестр показателей;
• оказывает необходимую консультационную помощь подразделениям, представляющим значения показателей, и инициаторам изменений показателей;
• координирует внедрение ИТ-системы хранения списков показателей банка, их описаний и значений; координирует использование этой системы;
• ежемесячно готовит отчет для рассмотрения на заседании комитета по рискам о реализации проектов по построению структуры показателей банка, а также об изменениях видов показателей банка и их значений; причинах этих изменений и прогнозах;
• организует исполнение иных требований п. 6.7.1.
6.7.2. Стандарты целевой продуктово-процессной структуры банка
Банк отмечает особую важность назначения целевой структуры банковских продуктов (целевых групп клиентов и их особенностей, целевых характеристик бизнес-продуктов), целевой процессной структуры банка и особенностей банковских процессов.
Отсутствие зафиксированной целевой продуктово-процессной структуры, отсутствие системы её коррекции и контроля достижения, отсутствие системы мотивации и культуры достижения этих целей банк определяет как системообразующий высокий операционный риск, который влечет неэффективность управления всеми банковскими процессами и неэффективность их исполнения (в соответствии с требованиями п. 3.1).
Банк выделяет следующие группы банковских продуктов и процессов:
• бизнес-продукты и процессы;
• сервисные продукты и процессы;
• аутсорсинговые, "облачные", территориально удаленные продукты и процессы.
6.7.2.1. Особые условия построения продуктово-процессной структуры банка.
6.7.2.1.1. Банк обеспечивает централизованный учет всех продуктов и процессов и закрепляет каждый продукт и процесс за соответствующим владельцем процесса.
По каждому виду процессов и продуктов банк назначает департамент (владельца процесса), который отвечает за организацию и осуществление эффективной работы с этим процессом и продуктом. Все доработки процесса, формирование паспорта продукта, регламента, схемы процесса организуются соответствующим владельцем процесса (при необходимости он привлекает иных экспертов внутри банка, формирует бизнес-требования, контролирует их исполнение).
Банк ведет соответствующую матрицу полномочий (таблицу), в которой каждый процесс и продукт распределен на каждое ответственное подразделение.
6.7.2.1.2. Банк поддерживает культуру постоянного улучшения процессов.
Банк создает культуру, мотивирующую сотрудников к улучшению процессов и оптимизации ИТ-процедур. Не реже одного раза в квартал со всеми сотрудниками банка проводятся тренинги (в т. ч. дистанционные) о целесообразности улучшения процессов, способах их улучшения, мотивации.
Для ознакомления всех сотрудников банка с достижениями по улучшению процессов банк создает страницу на своем внутреннем сайте с названием: "Достижения сотрудников по улучшению процессов"[55].
Банк внедряет и поддерживает программы бережливого производства и постоянного повышения эффективности деятельности: в рамках либо программы 5S, либо LSS (lean six sigma), либо Кайдзен (Kaizen), либо VSM (Value Stream Map). Банк внедряет и поддерживает также программу процессного подхода управления (Business Process Management System - BPMS).
6.7.2.1.3. Банк обеспечивает удобность поиска нормативных документов.
Для того чтобы сотрудники могли легко и быстро находить регламенты, схемы процессов, нормативные документы, бланки и методички банк создает поисковую страницу на своем внутреннем сайте с названием "ВНД банка"[56].
Эта страница должна позволять находить любые действующие, недействующие и разрабатываемые ВНД и бланки (с учетом уровней конфиденциальности). Каждому ВНД может быть присвоено неограниченное число признаков, по которым их можно отфильтровать (найти), в т. ч. по признакам регламентируемого продукта и процесса, виду ВНД, подразделению, разработавшему ВНД, по действительности, дате, No, ключевым словам и пр. Должна быть обеспечена возможность отбирать только схемы процессов или паспорта продуктов.
6.7.2.1.4. Банк обеспечивает легкость внесения предложений об изменении процессов.
Для обеспечения возможности легкого и быстрого улучшения регламентов, процессов и ИТ-процедур банк создает страницу на своем внутреннем сайте с названием: "Направить предложение об изменении регламента, процесса или ИТ-процедуры"[57]. В ней также должна быть создана возможность указания практической важности изменений, примерной трудоемкости изменений, срока для внедрения изменений, предмет изменений (регламент, процедура, настройка ИТ-системы).
Резолюция о принятии (отклонении) предложений с указанием причин должна направляться их инициаторам в сроки не позднее пяти рабочих дней.
В случае принятия предложения и завершения работ инициатору направляется уведомление о внедрении его предложений.
Если изменения повлекли существенное повышение эффективности процедур, то к их инициаторам применяются поощрительные меры.
6.7.2.1.5. Банк обеспечивает быстроту изменения регламентов и процедур.
Банк закрепляет порядок согласования новых или изменения действующих регламентов, процедур, проектов, паспортов продуктов, иных изменений, сроки согласования, порядок эскалации замечаний, которые не могут быть устранены, список подразделений, которые должны их согласовывать (матрицу согласований).
Если согласование касается внедрения или изменения процесса или регламента[58], то такое согласование производится в два этапа. На первом этапе согласуется только схема процесса (схема должна соответствовать формату, утвержденному в банке - см. п. 6.7.2.1.9). И только после полного и окончательного её согласования на второй этап выносится весь документ.
В процессе согласований учитываются только те замечания, которые содержат формулировку решения, реализация которого устранит озвученные замечания.
Срок согласования изменений регламентов и процедур согласующими лицами, включая делегирование согласований, ограничивается пятью рабочими днями. Каждый день просрочки согласования должен снижать коэффициент премирования руководителя, на имя которого было выставлено первичное согласование.
Замечания, которые не были приняты хотя бы одним из согласующих руководителей, с приложением заключения об операционных рисках рассматриваются комитетом по рискам.
6.7.2.1.6. Банк ограничивает виды внутренних нормативных документов.
Банк закрепляет исчерпывающий список названий всех внутренних нормативных документов, допускаемых в банке, а также пояснения о предназначении каждого документа.
6.7.2.1.7. Банк закрепляет строгий формат нормативных документов.
Банк закрепляет форму бланков каждого вида нормативного документа, их содержания, примеры каждого вида нормативного документа (примеры заполненных бланков).
6.7.2.1.8. Банк закрепляет обязательность наличия паспортов продуктов.
По каждому банковскому продукту банк закрепляет обязательность наличия паспорта, который описывает характеристики этого продукта. Банк устанавливает формат паспорта, перечень его элементов, типовые примеры паспортов. Практический запуск продукта (изменений продукта) должен осуществляться только после утверждения нового паспорта продукта на заседании комитета по рискам (тарифы могут утверждаться другими органами банка). Пример паспорта продукта приведен в Приложении 12.
6.7.2.1.9. Банк закрепляет обязательность наличия визуальных схем процессов.
По каждому банковскому продукту банк закрепляет обязательность наличия визуальной схемы (карты) процесса создания этого продукта и его последующего обслуживания (схемы должны предусматривать все возможные варианты событий, которые вызывают старт или окончание процесса и охватывать весь жизненный цикл продукта). Банк закрепляет форматы указанных схем, перечень их элементов, типовые примеры схем. Практический запуск процесса должен осуществляться только после утверждения новой схемы процесса и регламента процесса комитетом по рискам.
Банк закрепляет обязательность наличия в каждом регламенте[59] визуальной схемы (карты) процесса. Пример составления схем процессов приведен в Приложении 13.
6.7.2.1.10. Банк закрепляет обязательность наличия визуальных схем-инструкций сотрудников для всех выполняемых ими повторяющихся обязанностей.
Банк закрепляет обязательность наличия схем действий сотрудников (схемы должны предусматривать все возможные варианты событий, которые вызывают старт или окончание работы сотрудника и охватывать весь жизненный цикл от старта до окончания). Например, в визуальной схеме работы сотрудника контакт-центра отражаются варианты поступающих звонков, вопросов/ответов и действий сотрудника в зависимости от целей разговора и получаемых от клиента ответов. Банк закрепляет форматы указанных схем, перечень их элементов, типовые примеры схем. Практический запуск выполнения новых обязанностей сотрудника должен осуществляться только после утверждения соответствующей схемы подразделением, ответственным за сервис продуктово-процессной структуры.
6.7.2.1.11. Банк обеспечивает независимость и эффективность подразделения, ответственного за сервис продуктово-процессной структуры.
Банк закрепляет обязательность наличия подразделения, которое занимается обеспечением сервиса продуктово-процессной структуры банка (исполнением всех требований п. 6.7.2). Это подразделение не должно подчиняться руководителю по информационным технологиям и ИТ-поддержке или руководителю по кадровому обеспечению (для обеспечения разделения полномочий с разными интересами)[60].
6.7.2.1.12. Банк обеспечивает технологичность хранения и обработки описаний процессов.
Для обеспечения доступности продуктово-процессной информации банк формирует единый электронный репозиторий бизнес-процессов (BPMS - Business Process Management System)[61], который одновременно учитывает данные о следующих элементах:
• информация о продуктах банка: - о бизнес-продуктах (для клиентов и контрагентов); - о сервисных продуктах (продуктах, необходимых для функционирования банка); - об аутсорсинговых и "облачных" продуктах и процессах;
• информация о банковских процессах и логике процессов, с помощью которых создаются и сопровождаются продукты банка;
• информация об исполнителях процессов банка - внутренних исполнителях (организационная и штатная структура банка) и внешних (исполнителях - третьих лицах);
• информация об инструментах, используемых для осуществления внутренних и внешних процессов (информационных и технических системах), и иных ресурсах, необходимых для осуществления процесса;
• другие виды процессной информации.
6.7.2.2. Сервисная среда продуктово-процессной структуры банка.
Банк обеспечивает сервисную среду, которая поддерживает эффективность продуктово-процессной структуры банка, а также её соответствие стратегическим целям банка. Для этого назначается ответственное подразделение (с учётом требований п. 6.7.2.1.11), которое:
• разрабатывает порядок назначения целевой линейки продуктов и процессов, организует их определение на горизонт 5 лет (с учетом стратегических целей банка и инициатив подразделений), разрабатывает соответствующий план-график ввода или упразднения продуктов / процессов на 5 лет и контролирует его исполнение;
• разрабатывает порядок внедрения подразделениями новых банковских продуктов / процессов, порядок их изменения, определяет форматы паспорта продукта, регламента процесса, графических схем процессов, проверяет все описания продуктов / процессов, составленные подразделениями банка, формирует единый реестр продуктов / процессов, матрицу полномочий;
• оказывает необходимую консультационную помощь инициаторам изменений продуктов / процессов;
• координирует внедрение ИТ-системы хранения списков продуктов и процессов и их описаний, координирует использование этой системы;
• ежемесячно готовит отчет для рассмотрения на заседании комитета по рискам о деятельности по поддержанию продуктово-процессной структуры банка, а также о значимых изменениях в продуктах / процессах, причинах этих изменений, ближайших планах и прогнозах;
• организует исполнение иных требований п. 6.7.2.
6.7.2.3. Продуктово-процессная структура формируется для обеспечения миссии и целей банка (см. п. 6.7.1). Все изменения продуктово-процессной структуры производятся с учетом миссии банка и его целей, с учетом планов их изменения и плановых значений целевых показателей (с обязательным уведомлением о таких изменениях подразделения, указанного в п. 6.7.1.5).
6.7.3. Стандарты целевой организационной структуры банка
Банк отмечает особую важность назначения его целевой организационной структуры. Отсутствие зафиксированной целевой организационной структуры, системы её коррекции и контроля её достижения, системы мотивации и культуры достижения этих целей банк определяет как системообразующий высокий операционный риск, который влечет неэффективность управления всеми банковскими процессами и неэффективность их исполнения (в соответствии с требованиями п. 3.1).
Банк применяет следующую классификацию его подразделений:
• бизнес-подразделения;
• сервисные подразделения;
• аутсорсинговые подразделения;
• территориальное деление с учетом функционального подчинения.
6.7.3.1. Особые условия построения организационной структуры банка.
Банк формирует адекватную управленческую и организационную структуру, исключающую возникновение конфликта интересов по следующим параметрам:
6.7.3.1.1. Полномочия подразделения должны быть функционально отделены от полномочий других подразделений банка.
Ввод нового подразделения, его упразднение, изменение его компетенции не должны вызывать неконтролируемое оставление каких-либо процедур без их исполнителей или вызывать неконтролируемое дублирование функций других подразделений. В этой связи все изменения организационно-штатной структуры должны проходить предварительный анализ и согласование с подразделением, ответственным за сервис продуктово-процессной структуры и ведение матрицы полномочий (с подразделением указанным в п. 6.7.2.2).
6.7.3.1.2. Полномочия банковского надзора и контроля должны быть отделены от функций исполнения процессов (поднадзорных полномочий):
• внутренний контроль и аудит;
• управление операционным риском;
• безопасность;
• комплаенс;
• управление рыночными рисками и рисками ликвидности;
• управление кредитными рисками;
• принятие решений об установлении лимитов на операцию, сделку, группу операций, контрагентов;
• принятие решений о заключении нетиповых договоров.
"Надзорные" подразделения (исполняющие перечисленные функции), не должны исполнять поднадзорных операций и не должны подчиняться руководителям, курирующим организацию поднадзорных функций.
6.7.3.1.3. Полномочия координации функции по банку должны быть отделены от полномочий исполнения этой функций на местах.
Для каждого регионального подразделения и сотрудника (соответственно в положении о подразделении и должностной инструкции) должен быть обозначен департамент, координирующий его деятельность (в том числе для исполнительских подразделений и сотрудников, находящихся в регионе присутствия департаментов).
6.7.3.1.4. Полномочия Фронт, Мидл, Бэк[62] должны быть отделены от других функций и друг от друга.
Банк стремится к тому, чтобы Фронт, Мидл, Бэк были обособлены друг от друга, в том числе так чтобы Фронт или Бэк взаимодействовали только через Мидл. Для исключения проведения операций без должного оформления указанные функции в банке должны быть представлены обособленными руководителями, занимающими равноценные должности на уровне региональных подразделений / филиалов и равноценные должности на уровне Правления (банка в целом).
В каждом положении о подразделении и должностной инструкции (если они касаются подразделений и сотрудников Фронт, Мидл, Бэк) должен быть обозначен соответствующий статус этого подразделения / должности - "эта должность или подразделение выполняет функции Фронт" или Мидл, или Бэк.
У одного сотрудника не может быть совмещение одновременно двух и более функций (Фронт, Мидл, Бэк).
6.7.3.1.5. Полномочия контроля значимых операций должны быть отделены от полномочий исполнения этих операций.
Следующие операции осуществляются с контролем и акцептом[63] как минимум еще одного сотрудника, специально уполномоченного на контроль и акцепт такой операции (перечень операций может быть изменен комитетом):
1. Списания средств со счета, осуществляемые по документарным платежным документам.
2. Выдача, прием, передача денежных средств, ценных бумаг и иных активов.
3. Изменение персональных данных клиентов (прежде всего образца подписи; фотографии; контактного номера телефона, в т. ч. мобильного телефона, который может использоваться банком для проверки правомочий лица; отпечатка пальца (если банк фиксирует такие персональные данные)).
4. Обращение клиента за получением нового кредита, кредитной карты, иной ссуды (с целью исключения мошенничества со стороны сотрудников банка).
5. Согласование договоров.
6.7.3.1.6. Рабочие места сотрудников, осуществляющих аналитическую работу (программисты, аналитики, методологи и т. д.) должны быть отделены от рабочих мест иных сотрудников и от потенциальных отвлекающих факторов.
Банк ведет учет должностей сотрудников, чья работа требует глубокой умственной сосредоточенности, не допускающей отвлекающих факторов (программисты, аналитики, методологи и т. д.). Для таких сотрудников нежелательно размещение в пространствах открытого типа, размещение с сотрудниками с "шумной" деятельностью (т. е. часто ведущих совещания, переговоры, в т. ч. телефонные), в местах передвижения людей[64].
Для мест размещения таких сотрудников должны применяться специальные правила поведения (в т. ч. использования технических и переговорных устройств), которые обеспечивают тишину и минимизацию отвлекающих факторов (как в читальных залах библиотек). Контроль за соблюдением этих правил возлагается на ответственных лиц.
6.7.3.2. Сервисная среда обслуживания организационной структуры банка.
Банк обеспечивает сервисную среду, которая поддерживает эффективность организационной структуры банка, а также её соответствие стратегическим целям банка. Для этого назначается ответственное подразделение, которое:
• разрабатывает порядок назначения целевой организационной структуры с учетом территориальных и аутсорсинговых особенностей, организует её определение на горизонт 5 лет (с учетом стратегических целей банка и инициатив подразделений), разрабатывает соответствующий план-график ввода или упразднения подразделений с учетом планируемых территориальных и аутсорсинговых изменений на горизонт 5 лет и контролирует его исполнение;
• разрабатывает порядок ввода / упразднения подразделений, определяет формат положений о подразделениях и должностных инструкций;
• оказывает необходимую консультационную помощь инициаторам ввода / упразднения подразделений и штатных единиц;
• координирует внедрение ИТ-системы учета изменений организационно-штатной структуры, координирует использование этой системы;
• ежемесячно готовит отчет для рассмотрения на заседании комитета по рискам о деятельности по поддержанию организационно-штатной структуры банка, а также о значимых изменениях в структуре, причинах этих изменений, ближайших планах и прогнозах;
• организует исполнение иных требований п. 6.7.3.
6.7.3.3. Организационно-штатная структура формируется для обеспечения продуктов и процессов банка (см. п. 6.7.2). Все изменения организационно-штатной структуры определяется продуктово-процессной структурой, планами её изменения, плановыми значениями объемов продуктов, объемов операций и должны согласовываться с подразделением, указанным в п. 6.7.2.2 на соответствие этим планам.
6.7.4. Стандарты целевой ИТ-архитектуры и технологий банка
Банк отмечает особую важность назначения целевой ИТ-архитектуры и технологий банка (целевой функциональной структуры, целевой структуры приложений).
Отсутствие зафиксированной целевой ИТ-архитектуры и технологий банка, системы её коррекции и контроля её достижения, системы мотивации и культуры достижения этих целей банк определяет как системообразующий высокий операционный риск, который влечет неэффективность управления всеми банковскими процессами и неэффективность их исполнения (в соответствии с требованиями п. 3.1).
6.7.4.1. В банке должны быть формализованы и утверждены следующие документы:
1. Целевая ИТ-архитектура.
2. Ключевые элементы целевой ИТ-архитектуры.
3. Текущая ИТ-архитектура.
4. Соответствие имеющихся систем целевой ИТ-архитектуре.
5. План реализации программы перехода к целевой ИТ-архитектуре (с учетом промежуточных состояний).
6. Бюджет программы перехода к целевой ИТ-архитектуре.
7. Список проектов развития целевой ИТ архитектуры (с указанием приоритетности, состояния, заказчика, заинтересованных подразделений и времени окончания).
8. Ориентировочная стоимость проектов программы развития ИТ-архитектуры (с указанием полной стоимости внедрения и последующей стоимости обслуживания).
9. Список проектов высокого приоритета.
Работа по управлению ИТ-архитектурой должна осуществляться в рамках этих документов.
6.7.4.2. Банк выстраивает целевую ИТ архитектуру с учетом следующих принципов.
Функциональные принципы.
1. Отделение каналов взаимодействия с клиентами банка от систем Мидл- и Бэк-офиса.
2. Мультиканальный подход к управлению взаимодействием с клиентом (принцип единого окна).
3. Максимальная унификация клиентских сервисов в каналах взаимодействия.
4. Выделение функциональности построения аналитической отчетности из систем операционного уровня.
Архитектурные принципы.
1. Преимущество существующих систем над новыми при прочих равных условиях.
2. Преимущество индустриальных решений над собственной разработкой.
3. Подход к управлению сквозными бизнес-процессами на платформе BPMS[65] (с учетом высокоуровневой бизнес-логики).
4. Унификация приложений в целевой архитектуре (для решения аналогичных бизнес-задач, приоритет целостных решений).
5. Централизация программных приложений (с возможностью их удаленного использования), где это возможно.
Интеграционные принципы.
1. Интеграция приложений в соответствии с принципами сервисно-ориентированной архитектуры (SOA) - слабо связанных, заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.
2. Вынесение интеграционной логики из приложений в рамках бизнес-процессов, подверженных частым изменениям, и ее реализация на базе интеграционной платформы; организация интеграционных взаимодействий между системами операционного уровня через сервисную шину.
3. Единый стандарт интеграционных решений - использование единого стандарта для всех сообщений, циркулирующих по интеграционной шине.
6.7.4.3. Особые условия построения ИТ-архитектуры банка и технологий.
6.7.4.3.1. Для целей минимизации операционных рисков банк стремится максимально автоматизировать все, операции осуществляемые в ручном режиме.
6.7.4.3.2. Для целей минимизации рисков несанкционированного доступа к системам банка и минимизации рисков несанкционированных операций банк стремится использовать технологию единого входа сотрудников (Single Sign On), при которой уволившийся сотрудник автоматически не сможет пройти аутентификацию ни в одной системе банка.
6.7.4.3.3. Обязательность наличия единого хранилища данных (DWH - Data Warehouse).
Для обеспечения доступности аналитической, статистической и финансовой информации, используемой для расчета показателей и формирования управленческой отчетности, банк формирует единое хранилище данных (DWH - Data Warehouse), специально предназначенное для подготовки отчётов и бизнес-анализа:
• информация о клиентах, контрагентах банка и их операциях;
• информация о финансовой и хозяйственной деятельности банка (в т. ч. его убытках);
• информация о конкурентах банка и внешней среде, которая может оказать влияние на банк;
• другие виды статистической и финансовой информации.
6.7.4.3.4. Технологические требования к операциям акцепта[66]:
• обособление в АБС[67] процедуры акцепта значимых операций, без прохождения которых операции в АБС технически не смогут быть исполнены;
• обособление в АБС групп доступа на акцепт значимых операций;
• обеспечение возможности проведения акцепта операций самим клиентом в АБС (защищенного акцепта):
• С помощью кодов подтверждений по SMS, которые автоматически генерируются АБС, направляются клиенту по SMS, после чего получаются от клиента и автоматически проверяются АБС. Операция технологически может быть исполнена в АБС только при совпадении отправленных и введенных в АБС кодов. Такая проверка может применяться как для подтверждения интернет-операций, так и для подтверждения операций при личном обращении клиента (операционист получает код от клиента и вводит его в АБС, при этом должны быть предусмотрены особые процедуры верификации клиента для случаев, когда клиент не имеет с собой телефона, на который отправляются SMS коды).
• С помощью банковской карты, ранее выданной клиенту. При этом происходит идентификация карты и ПИН-кода в терминале без такой идентификации операция технически не может быть выполнена в АБС.
• С помощью биометрических характеристик клиента, автоматически обрабатываемых АБС (отпечатка пальца, ключевых точек лица, сетчатки глаза и пр.) - в случае если такое решение принято банком.
6.7.4.3.5. Уведомление клиентов по SMS о проведении значимых операций:
• бронирование в кассе денег к выдаче на следующий день в сумме, превышающей 1 млн руб.;
• попытка осуществления клиентом дистанционной операции, а также очной операции на сумму свыше 1 млн руб.;
• любое изменение персональных данных клиента, используемых для его верификации (прежде всего образца фотографии, скана паспорта, контактного номера телефона, в т. ч. мобильного телефона, который может использоваться банком для проверки правомочий лица и т. д.);
• выпуск новой банковской карты;
• регистрация заявки на выдачу ссуды[68].
В банке должны быть предусмотрены процедуры немедленного приостановления несанкционированных операций по счету для случаев, когда в банк поступила информация о том, что операция клиентом не производилась.
6.7.4.3.6. Максимальное технологическое ограничение доступа сотрудников банка для ручных операций во внешних АБС[69].
1. Доступ сотрудников банка к внешним АБС должен быть максимально ограничен.
2. Внешняя АБС должна исполнять платежи только на основании защищенных транзакций, автоматически выгружаемых из внутренней АБС.
3. Все операции, заводимые сотрудниками банка вручную, в том числе изменение параметров плановых операций (например, плановые безакцептные списания), должны производиться сотрудниками банка во внутренней АБС. Каждая операция должна сопровождаться обязательным акцептом контролера во внутренней АБС.
4. В случаях когда доступ ко внешним АБС не может быть ограничен, должны быть предусмотрены процедуры особого контроля всех операций, производимых сотрудниками во внешних АБС, и процедуры их последующей сверки.
6.7.4.3.7. Запрет красного сальдо - расходных операции (техническая невозможность их совершения), если в результате операции расчетный счет примет отрицательную величину.
6.7.4.3.8. Использование электронных досье клиента[70].
6.7.4.3.9. Развитие системных средств минимизации рисков дистанционных операций клиентов физических и юридических лиц (операций с банковскими картами, интернет-операций, операций клиент-банк):
1. Обеспечение круглосуточного мониторинга (fraud-monitoring) транзакций. Исключительные полномочия по выполнению этой функции должны быть возложены на конкретные подразделения.
2. Использование для банковских карт процедуры дополнительного подтверждения интернет-транзакций по протоколу 3-D Secure, MasterCard Security Code (MCC), Verified by Visa, J/Secure. Настройка авторизации банковских карт с чипом в POS-терминалах и банкоматах - только посредством авторизации через чип (т. е. запрет авторизации через магнитную полосу).
3. Использование банковских карт с чипом.
6.7.4.3.10. Дополнительная фиксация фактов проведения крупных операций (например, на сумму свыше 1 млн руб.) с помощью дополнительных технических средств.
1. Сканирование документов. Например, при получении клиентом суммы свыше 1 млн руб. может производиться дополнительное сканирование страницы паспорта клиента с фотографией (с возможным отображением на экране АБС одновременно двух сканов - сделанного при открытии счета и предъявленного сейчас). Скан должен сохраняться с датой и местом создания и данными сотрудника, его создавшего.
2. Видеозапись. Например, при получении клиентом суммы свыше 1 млн руб. может автоматически производиться видеозапись в фоновом режиме с веб-камеры операциониста, изначально направленной в клиентскую сторону.
3. Фотографирование. Например, при оформлении клиенту кредита осуществляется его фотографирование.
6.7.4.3.11. Банк обеспечивает централизованный учет всех ИТ-систем и закрепляет каждую ИТ-систему за соответствующим владельцем.
По каждой ИТ-системе банк назначает департамент (владельца ИТ-системы), который отвечает за организацию и осуществление эффективной работы в этой системе. Все доработки ИТ-системы, формирование методологических документов осуществляются по инициативе владельца ИТ-системы, который при необходимости привлекает иных экспертов внутри банка, формирует бизнес-требования, контролирует их исполнение. Владельцем ИТ-системы не может быть назначено ИТ-подразделение (если только ИТ-подразделение не является исключительным пользователем такой системы).
Банк ведет соответствующую матрицу полномочий (таблицу), в которой каждая ИТ-система распределена на каждое ответственное подразделение.
6.7.4.4. Сервисная среда обслуживания ИТ-архитектуры и технологий банка.
Банк обеспечивает сервисную среду, которая поддерживает эффективность ИТ-архитектуры и технологий банка, а также её соответствие стратегическим целям банка. Для этого назначается ответственное подразделение, которое:
• разрабатывает порядок назначения целевой ИТ-архитектуры и технологий банка, организует её определение на горизонт 5 лет (с учетом стратегических целей банка и инициатив подразделений), разрабатывает соответствующий план-график внедрения или модернизации систем и технологий с учетом планируемых изменений на горизонт 5 лет и контролирует его исполнение;
• разрабатывает порядок ввода / упразднения / сопровождения систем;
• организует сопровождение систем и их необходимые доработки;
• координирует внедрение ИТ-системы учета систем и их связей; координирует использование этой системы;
• ежемесячно готовит отчет для рассмотрения на заседании комитета по рискам о деятельности по поддержанию ИТ-архитектуры и технологий банка, а также о значимых изменениях в структуре, причинах этих изменений, ближайших планах и прогнозах;
• организует исполнение иных требований п. 6.7.4.
6.7.4.5. ИТ-архитектура банка формируется для обеспечения его продуктов и процессов банка (см. п. 6.7.2). Все изменения ИТ-архитектуры определяются продуктово-процессной структурой, планами её изменения, плановыми значениями объемов продуктов, объемов операций и должны согласовываться с подразделением, указанным в п. 6.7.2.2 на соответствие этим планам.
6.7.5. Стандарты целевой структуры нормативных документов банка
Банк выделяет следующие виды внутренних нормативных документов (ВНД):
• ВНД однократного пользования (приказы, распоряжения и другие документы текущего характера);
• ВНД многократного пользования (политики, регламенты, методики и пр.);
• бланки документов и отчетов (внутренних и внешних).
6.7.5.1. Особые условия построения структуры нормативных документов банка определяются в п. 6.7.2.1.
6.7.5.2. Сервисная среда построения структуры нормативных документов банка определяются в п. 6.7.2.2.
7. Особенности процедур управления рисками
7.1. Типовой план-график мероприятий
Менеджмент операционных рисков должен быть зрелым, системным и скоординированным. Это возможно при наличии план-графика (дорожной карты) как минимум на один год вперед. Руководитель подразделения по операционным рискам должен сформировать этот план-график и представить руководству (в рамках презентации) для его согласования и утверждения.
Желательно, чтобы такой график состоял из разделов, пунктов и подпунктов с указанием сроков (с диаграммой Ганта), ответственных, ресурсов и прочих характеристик. Есть множество программных инструментов такого планирования (например, MS Project), в т. ч. с удобной опцией "схлопывания" детализированной информации.
Такой план целесообразно представлять руководству банка в виде верхнеуровневого план-графика с диаграммой Ганта (с сохранением готовности "расхлопывать" те этапы, по которым могут возникнуть вопросы).
В качестве разделов такого графика можно предложить нижеследующие пункты.
1. Первоочередные неотложные действия:- экспресс-аудит эффективности управления операционными рисками; - экспресс-аудит рисков наиболее значимых процессов и их устранение.
2. Запуск базовых механизмов управления операционными рисками (ОР):- общая отчетность для регулярной оценки ОР; - утверждение политики правления ОР.
3. Координация команды централизованного управления ОР:- Отдел координации инцидент менеджмента в подразделениях; - Отдел по выявлению и устранению рисков; - Отдел раннего предупреждения рисков.
4. Поэтапная легализация кураторов ОР в департаментах и регионах:- учет кураторов ОР;- обучение кураторов ОР; - организация рабочего взаимодействия с кураторами ОР.
5. Запуск всех компонентов управления ОР:- No 1. Эффективная работа с инцидентами. - No 2. Выявление рисков и их устранение. - No 3. Система раннего предупреждения рисков. - No 4. Обеспечение непрерывности деятельности. - No 5. Координация работы всех департаментов в управлении рисками. - No 6. Система отчетов и прогнозов, поддержание базы рисков. - No 7. Контроль соблюдения стандартов минимизации рисков.
6. Внедрение автоматизированной системы управления ОР:- проведение тендера; - формирование договора и приложений (бизнес-требований); - интеграция системы и наполнение ее справочниками; - тестирование и подписание актов; - подготовка инструкций и обучение персонала; - ступенчатый ввод в эксплуатацию (по регионам, по департаментам).
Если какие-то действия уже осуществлены или какие-то компоненты управления операционным риском уже присутствуют, такой план будет выглядеть по-другому.
7.2. Утверждение политики
7.2.1. Ключевые препятствия.
Внедрение процедур управления операционными рисками начинается обычно с утверждения политики по операционным рискам и ключевых документов. Перед утверждением их проекты рассылаются во все подразделения для их согласования и получения замечаний. При этом возникают первые проблемы, которые при неправильном отношении могут "поставить крест" на всей деятельности по операционным рискам, не дав ей даже проявится.
Все согласующие делятся на три группы:
• первая группа согласовывает, читая поверхностно;
• вторая группа читает и согласовывает (если это заинтересованное подразделение, как, например, служба качества или служба внутреннего аудита);
• третья группа читает, видит, что на неё будет возложена реальная ответственность за риски и убытки, что появляется контроль, и не согласовывает документы.
Чаще всего руководители, которые не согласовывают политику, выдвигают следующие, вполне обоснованные, аргументы:
1. Эти рисковые функции являются для банка новыми, они вызывают много дополнительных операции и требуют набора новых сотрудников ("давайте деньги").
2. Изменения очень масштабны, требуют запуска новых процессов, закупки новых систем, осуществления большого объема работ, и их реализация в ближайшие год-два физически невозможна.
3. Это нереалистичные правила, они носят формальный характер и поэтому не нужны.
4. В проекте политики очень много деталей, их целесообразно перенести в подчиненные документы.
7.2.2. Способы преодоления препятствий.
Если согласиться с этими аргументами, то утверждение политики станет невозможным, что вызовет отказ от полноценного управления операционными рисками.
По замечаниям 1-й группы ("Эти рисковые функции являются для банка новыми, они вызывают много дополнительных операций и требуют набора новых сотрудников") можно выдвинуть следующие контраргументы.
Такие сотрудники (по работе с рисками) имеются во всех департаментах банка[71], так как каждый департамент в текущем состоянии производит разбирательства с наступившими инцидентами, проводит методологические и технологические улучшения своих процессов, обеспечивает взаимозаменяемость сотрудников (в рамках непрерывности деятельности) и т. д.
Если эти субъекты департаментов не оформлены должным образом[72], то риск-менеджеры оказывают помощь этому подразделению для соответствующего их оформления[73] и обучения.
Обо всем этом говорит п. 4.1 проекта политики (если настоящие Рекомендации переименовать в политику).
По замечания 2-й группы ("Изменения очень масштабны, требуют, запуска новых процессов, закупки новых систем, осуществления большого объема работ, и их реализация в ближайшие год-два физически невозможна") можно выдвинуть следующие контраргументы.
Смысл политики как раз и заключается в том, чтобы обозначить цели и задачи, а также принципы целевого состояния процесса управления операционными рисками (а не наоборот, когда текущее неудовлетворительное состояние операционных рисков определяет политику). И именно она побудит подразделения банка начать осуществлять действия по приведению своих процессов к состоянию, намеченному политикой с учетом текущих возможностей и приоритетов банка (внедрение политики будет производиться в предельно щадящем режиме путем наименьших издержек).
По замечания 3-й группы ("Это не реалистичные правила, они носят формальный характер и поэтому не нужны") можно выдвинуть следующие контраргументы.
Во-первых, принципы, изложенные в политике, сформированы с учетом требований Базельского комитета и Банка России. Во-вторых, все принципы носят прикладной характер и могут использоваться как прямое руководство к действиям.
По замечания 4-й группы ("В проекте политики очень много деталей, их целесообразно перенести в подчиненные документы") можно выдвинуть следующие контраргументы.
Во-первых, подчиненные документы типа положения, регламента, методики и т. п. охватывают только отдельные группы процессов, продуктов и подразделений. А документы в виде Кодекс (например, Кодекс корпоративной этики) или политики затрагивают все процессы и продукты, или все подразделения, или вопросы особой важности. Все положения проекта политики как раз относятся к таковым - они касаются всех процессов и всех подразделений банка (все тезисы имеют уровень политики).
Во-вторых, все положения проекта политики обозначают только требования, оставляя за непосредственными исполнителями определённую свободу выбора способов их реализации. Например, принципы работы с инцидентами (раздел 6.1) обозначают лишь основные этапы работы с инцидентами (сохраняя за исполнителями возможность индивидуального выстраивания процессов с учетом специфики их деятельности), предоставляют свободу выбора системы работы с инцидентами и т. д.
Остальные замечания снимаются ссылкой на то, что эти нормативные документы составлены во исполнение требований регулятора и обещаниями, что внедрение будет производиться в предельно щадящем режиме путем наименьших издержек.
В тех случаях, когда отдельные замечания не снимаются, формируется таблица разногласий, которая подается Председателю правления банка или на коллегиальный орган для принятия окончательного решения. При этом многое зависит от оформления этой таблицы.
Пример оптимального оформления такой таблицы представлен ниже:
Столбец No 3: "Замечания". Оставшиеся неурегулированными замечания обычно - это либо очень краткие необоснованные оценки (например: "Это все формальность"), либо очень большие и пространные. И это делается намеренно: высшее руководство обычно не вчитывается в большие объемы текстов, поэтому такие замечания целесообразно разделять на строки, а также представлять их краткий смысл.
Столбец No 4: "Краткий смысл замечаний (в интерпретации рисков)" - самый важный в таблице столбец. Обычно за многословными и витиеватыми замечаниями кроется конкретный смысл "Это не наша функция, мы не хотим брать ответственность за риски своего подразделения" и т. п.
После составления такой таблицы проект нормативного документа с приложением указанной таблицы выносится на рассмотрение высшего руководства или коллегиального органа банка, где принимается окончательное решение.
Целесообразно отметить, что при взаимодействии с подразделениями, в т. ч. при согласовании документов, надо проявлять максимальную дружелюбность, встречаться, разъяснять, показывать презентации. Важно всегда озвучивать миссию: "Наша задача говорить подразделениям об их рисках, убытках и помогать закрывать их. Мы помогаем обеспечивать безопасность бизнеса, для того чтобы он мог уверенно зарабатывать деньги"[74].
7.3. Организация мер по минимизации рисков
7.3.1. Назначение ответственных за исполнение мер по минимизации рисков.
Практически во всех случаях назначения ответственных за минимизацию рисков они говорят: "Конечно эти меры нужны, вот вы их и делайте - вы же риски", или: "Пусть это делают методологи или ИТ-специалисты, там же нужно изменение регламента или доработка ИТ-системы" и т. п. Т. е. персонал не хочет выполнять излишнюю, по их мнению, работу и брать на себя обязанности, за неисполнение которых могут наказать.
Специально для таких ситуаций предусмотрены следующие правила назначения ответственных за исполнение мер по минимизации рисков (см п. 6.2.2.3 настоящих Рекомендаций).
Повторно приведем его:
"Ответственным за организацию исполнения рекомендации всегда обозначается одно лицо (во избежание перекладывания ответственности) - соответствующий руководитель департамента в чьем процессе обнаружен риск. В тех случаях, когда для исполнения рекомендации необходимы доработки информационно технологической структуры (далее ИТ), регламентов, оборудования или его закупки, проведение различных работ (в т. ч. рекламных кампаний, коррекции процессов, продуктов, систем мотивации и т. д.), указанный руководитель организует формирование необходимых требований на такие доработки, закупки, работы (при необходимости согласовывает их с риск-менеджерами) и контролирует их реализацию. При обнаружении некачественного исполнения таких требований ответственный эскалирует эту проблему до уровня риск-менеджера и комитета по рискам.
Ответственность за организацию исполнения рекомендации возлагается на нескольких ответственных только в тех случаях, когда не может возникнуть вероятность ситуации, в которой один ответственный может переложить часть ответственности за неисполнение рекомендации на другого ответственного. Например, рекомендация о представлении отчетов по единому формату может быть возложена на неограниченное число руководителей департаментов, так как каждый из них не сможет обосновать неисполнение рекомендации тем, что другой начальник не представил своего отчета".
7.3.2. Техника учета и контроля мер по минимизации рисков.
Количество рисков, мер по их минимизации со временем многократно увеличивается. И их контроль становится возможным только с использованием соответствующих ИТ-инструментов. Простейший пример такого инструмента приведен в Приложении 5 в виде excel-файла с раскрывающимися столбцами и возможностью фильтрации рисков и мер по суммам, датам, исполнителям, значимости и т. д.
7.4. Организация непрерывности деятельности (планов ОНиВД)
7.4.1. Техника учета и контроля планов ОНиВД.
Планы непрерывности деятельности изначально достаточно объемны, а при росте их количества обновление таких планов, и их использование при возникновении чрезвычайных происшествий становится затруднительным. Пример упрощения такой работы приведен ниже в виде пояснений к excel-файлу, в котором на одном листе ведутся все планы непрерывности деятельности (см. схему 7).
Обычно для организации работы участников обеспечения непрерывности деятельности создают сетевую папку, в которой размещают планы непрерывности деятельности, акты проверок и иную документацию.
Схема 7
7.5. Принципы подсчета размера операционного риска[75]
Этот процесс условно можно разделить на три основных этапа.
Этап 1. Подготовка данных. Он охватывает:
• фильтрацию инцидентов для включения их в расчет (по сумме, дате, потенциальным, внешним потерям и т. д.);
• распределение по бизнес-линии и по категории убытка;
• распределение по сумме убытка и частоте (см. схему 8).
Этап 2. Подборка модели распределения тяжести последствий, которая наиболее точно описывает распределение фактических потерь Банка (см. схему 9)
Обычно для подборки используют следующие распределения:
1. Распределение Бурра.
2. Экспоненциальное распределение.
3. Гамма-распределение.
4. Обратное гауссовское распределение.
5. Логарифмически нормальное распределение.
6. Комбинированное логарифмически нормальное гамма-распределение.
7. Комбинированное надежное логарифмически нормальное гамма-распределение.
8. Комбинированное логарифмически нормальное обобщенное распределение Парето с хвостом.
9. Логарифмически нормальное обобщенное Парето-Хилла.
10. Комбинированное х-логарифмически нормальное обобщенное распределение Парето с хвостом.
11. Распределение Парето.
12. Обобщенное распределение Парето.
13. Распределение Вейбулла.
14. Комбинированное распределение тяжести последствий с хвостом.
Этап 3. Масштабирование модели на убытки банка, вычисление границ доверительного интервала и установление суммы потерь соответствующей 99,9 % границе (см. схему 10).
В инструменте SAS OpRisk VaR результаты такого расчета графически будут выглядеть примерно так[76] (см. схему 11).
Схема 11
7.6. Организация подразделения по операционным рискам
7.6.1. Структура подразделения.
7.6.1.1. Оптимальная структура подразделения по операционным рискам представлена на схеме 12.
7.6.1.2. Представленное деление сотрудников на юниты[77] обусловлено несовместимостью знаний, навыков, интересов, необходимых для выполнения задач юнитов.
Так, юнит по выявлению и устранению рисков (отдел 2 на схеме) - это сотрудники, имеющие интересы и глубокие познания в области методологии, операционной деятельности. По типо-характеру эти сотрудники - гуманитарии. Они имеют большой опыт работы в различных подразделениях банка, знают все банковские процессы и их слабые места, знают риски - это самые дорогостоящие сотрудники.
Юнит по раннему предупреждению рисков - это сотрудники имеющие, интересы и глубокие познания в области статистической аналитики, отчетности. По типо-характеру эти сотрудники - "технари" - математики. Они имеют опыт сбора и анализа больших объемов данных, математического обнаружения тенденций, идентификации их причин, программирования, например, в SAS Enterprise Guide или SPSS Clementine / Modeler, или иных инструментах. Это также высокооплачиваемые сотрудники.
Юнит по координации инцидент-менеджмента в подразделениях состоит, во-первых, из группы "методологов-тренеров" (тех, которые координируют деятельность всех подразделений, обучают работе с рисками и инцидентами (это менее "дорогие" сотрудники)). Во-вторых, этот юнит состоит из группы сотрудников "потоковой проверки инцидентов" без глубоких навыков и познаний (это самые "недорогие" сотрудники). По типо-характеру это ярко выраженные "неугомонные экстраверты-миротворцы", имеющие опыт успешного взаимодействия с другими сотрудниками.
7.6.1.3. Таким образом можно выделить четыре группы сотрудников подразделения по операционным рискам:
• гуманитарии (юнит по выявлению и устранению рисков);
• "технари" (юнит по раннему предупреждения рисков);
• тренеры-наставники (юнит по координации инцидент-менеджмента);
• инцидент-контролеры (юнит по координации инцидент-менеджмента).
7.6.1.4. В подразделение по операционным рискам запрещается включать другие подразделения, связанные с операционной деятельностью, такие например, как подразделения противодействия мошенничеству и мониторинга сомнительных транзакций, мониторинга кредитных мошенничеств, контроля лимитов[78] и т. д. Это нарушает принцип разделения полномочий управления рисками и полномочий исполнения процессов (п. 6.7.3.1.2) и влечет неадекватность и предвзятость оценки рисков в этих подразделениях.
7.6.1.5. Запрещается также отдавать из подразделения по операционным рискам различные функции.
Пример структуры подразделения по управлению операционными рисками
Схема 12
Так, аналитиков по раннему предупреждению рисков, часто хотят "забрать" в иные подразделения, например, в макроаналитическое подразделение. Этого делать нельзя, так как значительную часть работы таких аналитиков составляет непосредственная организация процедур раннего предупреждения (что не вправе делать сотрудники иных подразделений).
Так же часто хотят "забрать" функцию по обеспечению непрерывности (в кадры, в ИТ-подразделение или в подразделение информационной безопасности). Однако все эти подразделения при организации непрерывности деятельности будут выполнять несвойственные им функции (например, не в компетенции кадров находится организация ИТ-непрерывности, так же как не в компетенции подразделения информационной безопасности находится организация непрерывности работы персонала и т. д.). Такое выполнение несвойственных функций является нарушением (выходом за рамки своих полномочий) и по сути дела некомпетентной деятельностью.
7.6.2. Подчиненность подразделения.
Стандартно подразделение по операционным рискам входит в блок рисков (либо в составе подразделения по банковским рискам, либо обособленно с прямым подчинением директору по рискам).
Вхождение подразделения в блок рисков несет существенные риски и ведет к "вырождению" функции управления операционными рисками.
Так, значительное число операционных рисков идентифицируется подразделением именно в блоке рисков (в скоринге, верификации, андеррайтинге, раннем взыскании, позднем взыскании, работе с коллекторами, предотвращении мошенничеств и т. д.). Т. е. подразделение идентифицирует риски у своего начальника - директора по рискам. Более того, когда устранение этих рисков задерживается, подразделение должно "жаловаться" на своего начальника Правлению. Налицо нарушение принципов разделения полномочий управления рисками и полномочий исполнения процессов (п. 6.7.3.1.2). Риск-функция в этих условиях теряет свою эффективность и объективность.
Для недопущения такой ситуации подразделение по операционным рисками должно подчиняться напрямую Председателю правления банка, а не его заместителю по рискам (не директору по рискам[79]). Однако на практике это не наблюдается.
7.6.3. Организация рабочих мест сотрудников подразделения.
7.6.3.1. Подразделение по операционным рискам должно размещаться обособленно от других сотрудников, так как обсуждаемые вопросы по большей части носят конфиденциальный характер.
7.6.3.2. Рабочие места трех юнитов должны обособляться с учетом принципов, указанных в п. 6.7.3.1.6. Так, работа юнита по координации инцидент-менеджмента по большей части представляет собой достаточно шумную деятельность, а работа юнита по раннему предупреждению рисков требует глубокой сосредоточенности. Поэтому одни не должны мешать работать другим. Идеальной ситуацией является расположение этих трех юнитов в трех обособленных пространствах.
7.6.4. Численность подразделения.
Оптимальное количество сотрудников каждого юнита подразделения по операционным рискам определяется возможностями банка.
Предельно минимальное количество сотрудников должно составлять 5 человек (с учетом руководителя подразделения)[80].
7.6.5. Миссия и культура сотрудников подразделения.
Для подразделения операционных рисков целесообразно обозначить общий посыл (лозунг) работы, ключевые цели, миссию, а также иные положения, влияющие на деловую культуру сотрудников подразделения.
В качестве целей, например, можно обозначить:
• предотвращение убытков;
• возмещение убытков.
Миссию можно представить следующими тезисами: "Защищать банк от внешних и внутренних угроз. Обеспечить своевременные и ясные: 1. Оценку ситуации (и перспектив); 2. Идентификацию рисков; 3. Меры по устранению рисков. Каждое подразделение и сотрудник должны ощущать такую нашу защиту и поддержку.".
На практике это означает, что сотрудники подразделения во внутренней работе и при взаимодействии с другими сотрудниками должны постоянно осознавать и транслировать эту миссию.
Эти цели и миссия, а также иные положения, влияющие на деловую культуру сотрудников подразделения должны быть в постоянном использовании. Целесообразно также разместить в рабочих пространствах подразделения соответствующие деловые плакаты (примеры таких плакатов см. в Приложении 14).
Также каждому юниту свойственны свои целевые показатели (они отмечены в схеме 12 к п. 7.6.1.1).
7.7. Внедрение автоматизированной системы по операционным рискам
7.7.1.Мотивация руководства к закупке автоматизированной банковской системы по операционным рискам (АБС по операционным рискам).
Есть несколько различных видов мотивации руководства банка дать бюджет на внедрение АБС по операционным рискам. Например, сообщить, что это требования регулятора и если мы не сделаем этого, то на нас наложат взыскание. Или сообщить, что это экономическая выгода: если мы сделаем это, то получим соответствующий финансовый результат.
Наиболее доходчивой является аргументация через экономическую выгоду. И здесь приходит на помощь "экономическое" предложение Базельского комитета и национального регулятора, которое говорит, что банки, эффективно управляющие своими рисками, получают финансовые преференции через показатель Н1 (достаточность капитала).
В этом показателе соотношение капитала банка (в числителе) к кредитному, операционному, рыночному риску (в знаменателе) должно быть выше 10-11 %.
Банк заинтересован в снижении капитала (числителя), так как его поддержание стоит денег (например, в виде субординированных кредитов, плата за которые составляет, например, 5 % годовых). Т. е. банк хочет снизить расходы на поддержание капитала (иногда это существенные суммы, даже для больших банков)[81]. При константе значения формулы в 11 % числитель можно снизить только при помощи снижения знаменателя, а в этом как раз и заложен операционный риск (помимо кредитного и рыночного).
С учетом этого национальный регулятор разрешит банкам, эффективно управляющим своими рисками, считать размер операционного риска самостоятельно (по умолчанию он равен 15 % дохода банка). А это значит, что при получении такого разрешения банк, снижая риски, будет снижать знаменатель Н1, что вызовет снижение числителя (при константе значения Н1) и экономию[82].
К таким аргументам необходимо подготовить детальное экономическое обоснование, согласовать правильность расчетов и прогнозов в экономической службе банка.
Экономическое обоснование должно содержать следующие разделы:
1. Наглядную схему экономической выгоды от получения разрешения на самостоятельный расчет операционного риска (см. схему 13).
2. Плановые показатели операционного риска, рассчитанного по стандартной формуле (ОР = 15 % от дохода): - размер ОР; - размер капитала аллоцируемого этим ОР; - размер расходов на этот аллоцируемый капитал; - размер расходов на поддержание функции управления операционным риском.
3. Плановые показатели операционного риска, рассчитанного по продвинутой методике (ОР = ожидаемые и непредвиденные убытки по операционным рискам): - размер ОР; - размер капитала, аллоцируемого этим ОР; - размер расходов на этот аллоцируемый капитал; - размер расходов на внедрение системы ОР и поддержание функции управления операционным риском.
4. Разница (выгода) между показателями разделов А и В.
Располагая всеми значениями формулы Н1 конкретного банка, несложно подсчитать конкретную долю капитала, аллоцируемую операционным риском. Прогнозные суммы роста дохода можно взять у экономической службы. Размер ожидаемых и непредвиденных убытков можно рассчитать исходя из истории фактических убытков, применив повышающие коэффициенты с учетом примерной доли латентных убытков и планируемого роста бизнеса банка.
Эти документы для получения бюджета обычно выносятся на заседание Правления банка для утверждения готовности банка к закупке АБС по операционным рискам.
В тех случаях, когда внедрение базы рисков для руководства банка очевидно (они готовы выделить средства без дополнительной аргументации), рекомендациями настоящего пункта можно пренебречь.
Схема 13
[*] Представленные суммы и цифры не имеют ничего общего с реальной ситуацией в каком-либо банке, а приводятся исключительно для иллюстрации.
7.7.2. Особенности проведения тендера по закупке АБС по операционным рискам (критерии выбора системы).
При проведении тендера самое важное провести качественное сравнение коммерческих предложений и обеспечить качественную визуализацию результатов тендера.
Обычно сравнение производится по своеобразному проверочному листу (checklist), в котором в левой части указаны критерии оценки (группированные по блокам и важности), а в правой части проставляются да/нет. Из этих листов формируются сравнительные таблицы (пример таблиц представлен ниже в схемах 14.1-14.3). Обязательными критериями должны быть также условия структурирования сделки по закупке системы (эти критерии изложены в следующем разделе).
Указанные таблицы с приложением выводов и конкретных рекомендаций выносятся на рассмотрение уполномоченных органов, например комитета по технологическим изменениям и Правления или тендерной комиссии, которые делают окончательный выбор поставщика.
Выводами и рекомендациями могут быть, например, следующие тезисы:
"Принимая во внимание, что:
• Системы от поставщика 1 и поставщика 4 обладают наибольшими функциональными возможностями.
• Стоимость решения поставщика 4 дешевле решения поставщика 1 на 30 % (...млн руб. против... млн руб.), стоимость ежегодного обеспечения и сроки внедрения поставщика 1 и поставщика 4 являются приемлемыми.
• Банки, установившие системы от поставщика 1 с наибольшей вероятностью получат разрешения от ЦБ считать капитал под операционный риск самостоятельно.
• У решения от поставщика 1 отсутствуют риски прекращения обслуживания.
Рабочая группа рекомендует покупку системы поставщика 1".
Немаловажным фактором является цена, поэтому для ее снижения поставщиков необходимо постоянно держать в курсе всех снижений цены конкурентов или изменений критериев с вопросом: "Конкурент снизил цену, Вы готовы дать такую же скидку?".
7.7.3. Структурирование сделки по закупке системы.
После выбора поставщика важным становится структурирование сделки, хотя на самом деле параметры сделки оговариваются еще на этапе тендера и являются одним из критериев оценки. Зачем нужны такие условия? Они гарантируют качественное внедрение системы в установленные сроки.
Ниже приводятся некоторые из таких условий:
1. Включение в договор внедрения подробнейших бизнес-требований с указанием штрафных санкций при отсутствии соответствующей функциональности к определённой дате, включение в договор лицензии условий обслуживания, технической поддержки и доработок системы.
2. Истребование наилучших условий оплаты: - оплата лицензии после внедрения (trial версия на период внедрения); - оплата внедрения частями (какая то часть после внедрения); - штрафные санкции за просрочку внедрения; - фиксация размера ежегодных платежей на конкретный период; - включение работ по обслуживанию и технической поддержке в сумму лицензионных платежей.
3. Квалифицированное составление документов: - условия расторжения договора; - приоритетный язык договора; - место разрешения споров.
4. Квалифицированное оформление и подписание документов - очередность подписание договоров (сначала контрагентами, потом на своей стороне одновременно договоров внедрения и лицензии); - сшив договоров.
7.7.4. Интеграция системы.
Интеграция системы может состоять из следующих этапов:
1. Кастомизация системы (корректировка пользовательских форм, справочников).
2. Интеграция системы с данными банка (со справочниками и иными данными).
3. Настройка резервирования и механизмов восстановления системы (SLA).
4. Настройка механизмов ежедневных выгрузок в хранилище данных.
5. Настройка отчетов и средств доступа к ним.
6. Загрузка исторических данных.
7. Формирование регламента работы с системой, формирование пользовательских инструкций.
Все этапы одинаково важны, но ключевую роль в функционировании всей системы операционных рисков играют три этапа: кастомизация системы, интеграция системы, настройка отчетов и прогнозов.
Этап 1. Кастомизация системы (корректировка пользовательских форм, справочников).
Кастомизация системы - это этап, на котором типовой "коробочный" продукт настраивается под индивидуальные особенности конкретного банка.
Качество кастомизации, во-первых, влияет на уровень использования системы ее пользователями. От того, насколько удобными и понятными для пользователей (а регистрировать инциденты могут все сотрудники банка) будут пользовательские формы и выпадающие списки, настолько эта система и будет использоваться.
Эту ситуацию можно сравнить с удобностью интерфейсов мобильных телефонов: некоторые удобны и пользоваться ими можно без прочтения каких-либо инструкций, а некоторые непонятны и даже неприятны.
Во-вторых, качество кастомизации влияет на эффективность процессов управления рисками. Например, если какие-либо важные действия не находят отражения в учете системы, то они и выполняться не будут.
В-третьих, качество кастомизации влияет на качество аналитики, отчетности и прогнозов. Например, если какие-либо важные признаки рисков не находят отражения в системе, то по ним нельзя будет сделать выборку и анализ.
Этап 2. Интеграция системы с данными банка (со справочниками и иными данными).
Систему целесообразно интегрировать как минимум с двумя справочниками: со справочником "Сотрудники и подразделения" и со справочником "Продукты банка". Такая интеграция означает, что в случае изменений, например, в составе сотрудников банка (в кадровой системе) такие изменения автоматически произойдут и в базе операционных рисков. Если такой интеграции не делать, то на поддержание списка сотрудников в актуальном состоянии в базе рисков будет уходить очень много ручного труда.
Иногда производят интеграцию с другими справочниками, например, курсов валют, списками счетов, каталогами Active Directory (для возможности авторизации пользователей по своим учётным записям) и т. п.
Базу рисков интегрируют также с источниками данных об однотиповых множественных инцидентах (например, фактами осуществления исправительных проводок или излишками / недостачами в банкоматах).
Базу рисков интегрируют и с данными для расчета ключевых индикаторов рисков и т. д.
Этап 5. Настройка отчетов, настройка средств доступа к ним.
Всю отчетность целесообразно строить не в базе рисков, а из хранилища данных (предварительно обеспечив ежедневную выгрузку туда этих данных из базы рисков - см. выше этап 4 настоящего пункта).
От того, насколько удобными, понятными и актуальными для пользователей будут отчеты и прогнозы (а использовать отчеты и прогнозы по своим операционным рискам будут все подразделения банка), настолько и будет оцениваться эффективность управления операционным риском.
7.8. Аллокация инцидентов
7.8.1. Важность аллокации и инструменты.
Аллокация инцидентов[83] (по исполнителям, подразделениям, покрывающим убытки, и иным признакам) в рамках их учета является важным моментом, обеспечивающим работоспособность всей системы управления операционным риском. Ниже приводятся примеры наиболее важных аллокаций и раскрываются причины их важности.
1. Аллокация инцидента по типу (виду) инцидентов.
Если инциденты будут аллоцироваться не на те типы инцидентов, к которым они относятся то и направляться для обработки они будут не на те маршруты и не к тем экспертам (их обработки либо вовсе не будет, либо она будет некомпетентной). В этих условиях вся работа с инцидентами будет неэффективной.
2. Аллокация инцидента по виду бизнеса.
Если расходы на возмещение инцидентов и на их обработку не будут аллоцироваться на конкретные подразделения (и не вычитаться из их бюджетов), то у этих подразделений никогда не возникнет настоящего желания минимизировать свои риски и предотвращать инциденты.
Список названий оптимальных признаков инцидента и информационных полей приведен в Приложении 4.
Присвоение признаков играет ключевую роль и для последующей аналитики и построения отчетности, и для автоматической аллокации инцидентов на классификаторы Базель II (для расчета операционного риска продвинутым способом).
Основные проблемы при аллокации инцидентов возникают из-за неудобства механизмов присвоения их признаков. В ходе практического решения этой проблемы оказалось, что главным является одновременные интуитивная понятность и высокая детализация этих признаков. Они определяются при первоначальной регистрации инцидента и сопровождают его на всем протяжении жизненного цикла. Инициатор указывает эти признаки, отвечая на четыре вопроса:
• Что произошло?
• С чем произошло (ресурс)?
• Где произошло (территория)?
• Где произошло (процесс / продукт)?
Эффективность аллокации по многочисленным признакам будет зависеть от удобства выпадающих многоуровневых списков, их интуитивной понятности и детализации.
7.8.2. Особенности аллокации инцидентов по категориям и бизнес-линиям.
Нередко определение принадлежности инцидента к той или иной категории и бизнес-линии вызывает трудности и спорные моменты. Принадлежность определяется экспертным путем, а правила и особенности такого определения приводятся в конце Приложения 1 и Приложения 3.
7.8.3. Несоответствия между управленческим и финансовым учетом.
В случаях, если какие-либо инциденты и убытки учтены в базе операционных рисков, но не учтены в бухгалтерском, финансовом или управленческом учете, приоритет должен отдаваться сведениям из базы операционных рисков.
7.9. Правила расчета убытка по крупным инцидентам[84]
Банк производит оценку суммы убытка каждого инцидента по внутренним методикам, при этом расчет суммы убытка по инцидентам может производиться по следующим правилам:
Примерная формула расчета:
К убытку от инцидентов не относятся расходы, затраченные банком на выработку мер по недопущению инцидентов, аналогичных произошедшему (мер предотвращения инцидентов), а также расходы на реализацию таких мер.
В сводных отчетах по банку все инциденты, в которых сумма убытка имеет отрицательную величину (когда суммы поступлений, вызванных инцидентом, превышают суммы потерь), учитываются так чтобы они не искажали размера убытков от других инцидентов (не снижали сумм убытков от других инцидентов). Такими инцидентами могут быть, например, факты возникновения излишков в банкоматах или инциденты, по которым сумма возмещений превысила сумму убытков. При этом банк должен иметь возможность представить отчетность отдельно по инцидентам, где суммы поступлений, вызванных такими инцидентами, превышают суммы потерь.
Для обеспечения точности расчета убытков от однотипных инцидентов с примерно одинаковым убытком, например, исправительных проводок, не повлекших прямых убытков, размер убытка может назначаться нормативно (при этом убытком может быть себестоимость каждой исправительной проводки).
Следует различать убыток банка и убыток клиентов банка. Например, если хищение произошло со счетов клиентов (вклада, банковской карты или текущего счета), то такой убыток целесообразно регистрировать как потенциальный, который изменит статус на фактический, если эти средства будут возмещены клиенту из бюджета банка.
7.10. Оценка состоятельности системы управления операционным риском
Уровень управления операционным риском можно определять по следующим критериям.
Критерий 1 - по уровню технологичности.
Этот критерий больше характеризует силу, грамотность и техническое оснащение второй линии защиты операционных рисков (подразделения по операционным рискам).
Показателями высокой технологичности можно обозначить следующие критерии:
• эффективность механизмов раннего предупреждения рисков (в т. ч. индикаторов рисков и контролей рисков), перечисленных в разделе 6.3.;
• наличие в банке технической системы управления операционными рисками известного производителя;
• полнота, актуальность и качественность первичных данных об инцидентах и рисках;
• интересные и актуальные отчетность и прогнозы;
• действующие инструменты расчета рисков продвинуты способом.
Критерий 2 - по уровню культуры.
Здесь имеется в виду уровень проникновения культуры управления операционными рисками во все подразделения банка и уровень их заинтересованности и вовлеченности в эти процессы. Эти критерии больше характеризуют силу, грамотность и техническое оснащение первой линии защиты операционных рисков (всех подразделений банка).
Показателями высокой культуры можно обозначить следующие критерии:
• высокий уровень предотвращения убытков на первой линии защиты, где более 9/10 убытка предотвращено всеми подразделениями банка и соответственно менее 1/10 предотвращено подразделением по операционным рискам;
• высокий уровень выявления и устранения рисков на первой линии защиты, где более 9/10 рисков идентифицируются всеми подразделениями банка и соответственно менее 1/10 выявляется подразделением по операционным рискам;
• наличие в каждом подразделении банка заинтересованных и активно действующих методологов, которые помимо прочего организуют работу с рисками и инцидентами своего подразделения и активно взаимодействуют с подразделением по операционным рискам (согласно разделу 4.1);
• аллокация убытков и рисков на подразделения и взыскание с этих подразделений возмещений расходов по убыткам и работам с рисками и инцидентами, аллокация управленческих резервов по операционным рискам на эти подразделения;
• использование каждым подразделением банка отчетов о своих убытках, рисках, возмещениях;
• регулярное заслушивание комитетом по рискам вопросов соблюдения стандартов минимизации рисков;
• эффективность механизмов минимизации рисков (в т. ч. высокого уровня методологии, визуальных схем процессов, схем действий сотрудников; паспортов продуктов и т. д.), перечисленных в разделе 6.7.
Заключение
Импульсивное поведение компаний может допускаться в непредвиденных условиях выживания (и то с большой натяжкой). Но оно недопустимо как перманентное состояние повседневной деятельности.
Компании должны вести свою деятельность системно и проактивно[85] с пониманием шагов долгосрочного планомерного стабильного развития. Ведение дел должно быть разумным.
Такое разумное состояние невозможно без соблюдения практик управления операционными рисками, указанных в настоящих Рекомендациях (и прежде всего стандартов раздела 6.7).
Желательно чтобы они были внедрены и эффективно использовались во всех крупных банках, а затем, по мере адаптации, и во всех крупных отечественных компаниях.
Именно доступность понимания материала и его актуальность определяет, будет ли он внедрён или нет. И по этой причине Рекомендации изложены в формате и объеме, который позволяет понять их как специалистам, так и людям, не сведущим в этой области.
Представленный труд преследует именно эти цели.
Благодарности
Работы над этими рекомендациям велись 6 лет и были завершены в январе 2014 г. Их написание стало возможным исключительно Провидению, которое сталкивало меня с яркими и незаурядными коллегами и руководителями, вдохновлявшими к написанию этих материалов (прямо или косвенно, дружелюбно или императивно, наставлениями, информацией или личным примером). Это были то подготовка презентаций, то оперативное разрешение проблемных ситуаций, то аргументация перед оппонентами. Благодаря возникавшей необходимости небольшие разрозненные кусочки информации на глазах складывались в более крупные блоки и "обрастали" сопутствующими материалами как бы сами собой.
Отдельно хочу выразить признательность своим друзьям и родственникам, чья поддержка была крайне важна и незаменима.
Об авторе
Бедрединов Рустам в банковской сфере с 2004 г.: свою карьеру начал в РегионИнвестБанке в должности специалиста. Специализируется на риск ориентированных функциях - руководил подразделениями верификации[86] и андеррайтинг[87] (МДМ Банк), коллекшн[88] (МДМ Банк), банковских рисков (БТА Банк), операционных рисков (МДМ Банк, БТА Банк, БИНБАНК, Восточный экспресс банк). В своей деятельности придерживается стандартов комплексного и высокотехнологичного подхода в управлении рисками, охватывающих каждое подразделение банка и каждого его сотрудника.
Принимает участие в развитии бизнес-культуры с регулярными докладами на различных конференциях и публикациями в специализированных изданиях. Принимал участие в рабочей группе Ассоциации российских банков по внедрению стандартов управления операционным риском Базельского комитета в банках России.
Закончил Московский юридический институт и Московский университет экономики, статистики и информатики. Защитил диссертацию на тему: "Риски операций с ценными бумагами".
Приложения
Приложение 1. Классификация рисков и инцидентов по видам (типам)
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
Настоящий список соотносится с Приложением 7 Базель II (для соотнесения выделенный ниже 8-й тип должен быть включен в 6-й, а 9-й тип должен быть включен в 7-й).
Для разграничения рисков, инцидентов и убытков операционного риска от событий, относимых к иным видам рисков, используются следующие критерии.
Не являются инцидентами операционного риска ошибки персонала (неумышленные) в оценке кредитного, рыночного рисков (в т. ч. процентного, валютного, фондового) - они относятся к кредитному и рыночному риску, с соответствующим источником покрытия. Не являются инцидентами операционного риска ошибки персонала в оценке стратегического и репутационного риска. Не является инцидентом операционного риска ущерб, возникший от реализации кредитного, рыночного, стратегического и репутационного рисков.
Если какое-либо событие классифицируется согласно Приложению 1 как инцидент операционного риска (вне зависимости от направления деятельности банка, в котором оно произошло), работа с ним производится по правилам, предусмотренным работой с инцидентами (прежде всего раздела 6.1 Рекомендаций). Это правило распространяется также на события, произошедшие в процессах, подверженных кредитному или рыночному рискам, если такие события классифицируются согласно Приложению 1 как инциденты операционного риска. Например, такие события, как факт просрочки по ссуде, при проверке которой установлено, что клиент заведомо не собирался ее погашать, или попытки получения ссуд с предоставлением поддельных документов (согласно Приложению 1 - злоумышленные действия) признаются инцидентами 102 операционного, а не кредитного риска (несмотря на то, что они произошли в процессе, подверженном кредитному риску с соответствующим покрытием). Например, такие события, как факт ошибки в стороне сделки с ценной бумагой - вместо покупки осуществление продажи (согласно Приложению 1 - ошибка персонала при осуществлении операции) признаются инцидентами операционного, а не рыночного риска (несмотря на то, что они произошли в процессе, подверженном рыночному риску).
Формирование управленческих резервов для покрытия убытков операционного риска осуществляется в рамках управленческой отчетности (за исключением инцидентов кредитного мошенничества, резервирование которых осуществляется в рамках стандартных процедур кредитного риска).
Операционный риск включает в себя юридический (правовой) риск (согласно Базель II), включая ошибки персонала в оценке правовых рисков, инциденты, связанные с уплатой банком штрафов, пеней или исполнением взысканий, в т. ч. являющихся результатом действия органов надзора, а также частных судебных исков (включая любой ущерб, возникший от реализации правового риска). Порядок сбора информации об инцидентах правового риска производится в том же порядке, что и при других инцидентах операционного риска.
Принадлежность инцидента к категории определяется экспертным путем. При этом экспертное мнение является приоритетным в сравнении с формально наличествующими признаками. Например, если инцидент (злоумышленные действия) имеет признаки того, что мог быть совершен только при участии сотрудника банка, но прямых доказательств этому нет, то такой инцидент должен быть всё равно отнесён к категории злоупотреблений или противоправных действий.
Приложение 2.1. Классификация рисков и инцидентов по значимости (нефинансовая шкала)
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
При использовании шкалы обозначается максимальный уровень рисков (в случае если риск идентифицируется по финансовому и по нефинансовому критерию (см. также Приложение 2.2).
Приложение 2.2. Классификация рисков и инцидентов по значимости (финансовая шкала)
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
При использовании шкалы обозначается максимальный уровень рисков (в случае если риск идентифицируется по финансовому и по нефинансовому критерию (см. также Приложение 2.1).
Приложение 3. Классификация рисков и инцидентов по бизнес-линии
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
Настоящий список соотносится с Приложением 6 Базель II.
Правила распределения рисков, инцидентов и убытков по бизнес-линиям.
Для распределения инцидентов используются объективные критерии, представленные здесь и позволяющие произвести такое деление между восемью бизнес-линиями взаимоисключающим и исчерпывающим образом.
В случаях, когда инцидент произошел во вспомогательном процессе (например, в процессе кадрового делопроизводства), устанавливается предназначение этой вспомогательной операции (бизнес-линия, для которой производилась эта операция, в которой произошел инцидент или обнаружен риск). Например, если инцидент произошел в процессе кадрового делопроизводства (не связанного с бизнес-линиями) при назначении сотрудника на должность в подразделение кредитования физических лиц, то этому инциденту назначается бизнес-линия "Банкинг физических лиц". Если же трудоустройство сотрудника, в ходе которого произошел инцидент, осуществлялось в подразделение корпоративного кредитования, то этому инциденту назначается бизнес-линия "Банкинг юридических лиц". При применении правил настоящего пункта в отчете об инциденте в обязательном порядке приводятся пояснения подтверждающие взаимосвязь инцидента с бизнес-линией.
Если невозможно установить ни прямую, ни опосредованную взаимосвязь инцидента ни с одной бизнес-линией, то такому инциденту, согласно Базель II, назначается бизнес-линия, приносящая банку наибольшую доходность. Подразделение рисков ежегодно определяет эту бизнес-линию.
Приложение 4. Минимальный список полей отчета об обработке значимого инцидента
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
Приложение 5.1. Бланк учета рекомендаций по минимизации обнаруженных рисков (без служебных полей)[89]
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
Приложение 5.2. Бланк учета рекомендаций по минимизации обнаруженных рисков (со служебными полями)
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
Приложение 5.3. Бланк учета рекомендаций по минимизации обнаруженных рисков (подробное, с пояснениями, часть 1)
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
Приложение 5.4. Бланк учета рекомендаций по минимизации обнаруженных рисков (подробное, с пояснениями, часть 2)
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
Приложение 5.5. Бланк учета рекомендаций по минимизации обнаруженных рисков (подробное, с пояснениями, часть 3)
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
Приложение 6. Бланк отчета об исполнении владельцами процессов рекомендаций по минимизации операционных рисков
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
Приложение 7. Бланк плана непрерывности деятельности банка (типовой модуль плана непрерывности)
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
Часть I. О непрерывности деятельности исполнителей процесса
1. Описание критически важной функции
2. План ОНиВД при выбытии исполнителей критически важной функции
2.1. Действия при наступлении ЧП
2.2. Обеспечительные действия
2.3. Тестирование плана ОНиВД
2.4. Обучение плану ОНиВД
3. План ОНиВД при сбое программных и технических ресурсов, используемых для критически важной функции
3.1. Действия при наступлении ЧП
3.2. Обеспечительные действия
3.3. Тестирование плана ОНиВД
3.4. Обучение плану ОНиВД
4. План ОНиВД при выбытии помещений, используемых для критически важной функции
4.1. Действия при наступлении ЧП
4.2. Обеспечительные действия
4.3. Тестирование плана ОНиВД
4.4. Обучение плану ОНиВД
5. План ОНиВД при наступлении иных чрезвычайных обстоятельств, приведших к нарушению критически важной функции
5.1. Действия при наступлении ЧП
5.2. Обеспечительные действия
5.3. Тестирование плана ОНиВД
5.4. Обучение плану ОНиВД
Аналогично оформляются разделы в отношении серверной части
Часть II. О непрерывности деятельности серверного ПО, используемого в процессе
• описание программного обеспечения, расположенного на серверах, описание серверов и каналов связи, используемых в критически важной функции, SLA;
• действия при сбое программного обеспечения, расположенного на серверах, серверов и каналов связи;
• действия при выбытии помещений, в которых расположены серверные программы, серверы;
• действия при выбытии исполнителей, обеспечивающих функционирование программного обеспечения, серверов и каналов связи;
• действия при наступлении иных чрезвычайных обстоятельств, связанных с серверами и приведших к нарушению критически важной функции.
Модули плана непрерывности для облегчения создания и использования могут также вестись в виде таблиц excel-файлов.
Приложение 8. Список критичных процессов банка
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
Приложение 9.1. Примеры "сигнальных" отчетов
1. Незакрытые инциденты (топ 5)
2. Незакрытые потенциальные убытки (топ 5) - инциденты с текущим потенциальным убытком
3. Неустранённые риски (топ 5) - неисполненные рекомендации
4. Неустранённые системные риски (топ 5) - неисполненные рекомендации
5. Наихудшие подразделения (по отработке инцидентов) - топ 5 по количеству замечаний
6. Наихудшие регионы(по отработке инцидентов) - топ 5 по количеству замечаний
7. Убыточные процессы (топ 5)
8. Убыточные регионы (топ 5)
9. Убыточные виды инцидентов (топ 5)
Приложение 9.2. Примеры общеаналитических отчетов
Отчет 1. Инциденты по кураторам (кол-во инцидентов обработанных экспертами по инцидентам)
Отчет 2. Убытки по кураторам (суммы убытков, обработанных экспертами по инцидентам, тыс. руб.)
Отчет 3. Инциденты по продуктам (кол-во)
Отчет 4. Убытки по продуктам (суммы убытков, тыс. руб.)
Отчет 5. Инциденты по регионам (кол-во)
Отчет 6. Убытки по регионам (суммы убытков, тыс. руб.)
Отчет 7. Виды инцидентов (кол-во)
Отчет 8. Убытки по видам инцидентов (суммы убытков, тыс. руб.)
Приложение 10. Примеры показателей банка
Приложение 11. Образец стандартного отчета об эффективности подразделения
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
Настоящий отчет не заменяет других отчетов
Единый образец отчета
Пример заполнения образца отчета
Такие требования к отчетам об эффективности подразделений определяются в числе прочего следующими обстоятельствами.
Требование 1. Не более одного слайда для каждого отдела.
Причина. Объединенный отчет для руководства может составлять значительное число страниц. Если каждый отдел предоставит, например, по 7 слайдов, то общий отчет будет составлять, например, 500 страниц.
Руководители банка будут затруднятся в уяснении такого большого объема данных, а значит будут испытывать трудности и в принятии 146 эффективных управленческих решений. В особых случаях, когда есть прямое указание членов правления, отчет конкретного отдела может быть увеличен до 2-х, 3-х слайдов.
Требование 2. Слайды всех отделов должны быть единого формата в PowerPoint.
Причина. Уполномоченные руководители, перелистывая слайды, ожидают увидеть оценку ситуации в одной области слайда, графики в другой, показатели в третьей, причины и меры в четвертой области слайда.
Руководители ожидают, что все графики и элементы будут одного, привычного для них формата, который не будет изменяться во всем объединенном отчете. Так зеленый - это хороший результат, красный и черный - плохой, план - это, к примеру графический элемент "ромб" и т. д.
Листая слайды руководитель ожидает сразу видеть, что слайд показывает плохую или хорошую оценку (там, где пиктограмма общей оценки) и останавливается прежде всего на отчетах с негативной оценкой. Он сразу хочет видеть ответственного, узнать причины негативной ситуации и предпринимаемые меры.
В связи с использованием руководством android и ios-устройств отчеты должны рассылаться руководству в двух форматах (pdf и PowerPoint).
Приложение 12. Пример паспорта продукта
Настоящее приложение может пересматриваться. Новая редакция приложения утверждается решением комитета по рискам.
Паспорт продукта должен быть составлен подразделением, ответственным за разработку и внедрение продукта, и согласован с юридическим подразделением, подразделением рисков, подразделением информационной безопасности, подразделениями Бэк и Мидл, ИТ-подразделением, а также всеми подразделениями, которые обозначены в схеме как участники процесса. Замечания, которые не могут быть устранены, рассматриваются комитетом по рискам. Паспорт конкретного продукта утверждается комитетом по рискам.
Раздел I. Условия продукта
Раздел II. Бизнес-план банковского продукта
Раздел III. План-график мероприятий по внедрению / модификации банковского продукта
1 Схема должна быть предварительно составлена подразделением, ответственным за разработку и внедрение продукта, и включена в паспорт продукта разделом IV.
Раздел IV. Графическая схема процесса реализации и обслуживания продукта (всего жизненного цикла продукта)[90]
[здесь должна быть представлена графическая схема процесса, составленная согласно правил п. 6.7.2.1.9]
Результаты оценки паспорта продукта
Результаты оценки рисков продукта
Приложение 13. Пример правил составления визуальных (графических) схем процессов Банка
1. Каждый разрабатываемый или изменяемый регламент, порядок или иной нормативный документ, в котором приводится описание процедуры последовательных действий трех и более сотрудников или подразделений, должен в обязательном порядке сопровождаться схемами, составленными согласно стандарту схем бизнес-процессов.
2. Схемы составляются в программном обеспечении Microsoft Office Visio (далее MS Visio) в соответствии с международным стандартом документирования бизнес-процессов "EPC" (см. меню MS Visio (шаблон > Бизнес > Схема EPC)). После составления схемы копируются в Microsoft Office Word и оформляются приложением к регламенту, порядку или иному нормативному документу.
3. В схемах используются следующие элементы:
4. Образец составления схем[91]:
Этап 1. Прием заявки и принятие решения о выдаче кредита
5. Если количество листов со схемами составляет два и более, то схема должна сопровождаться дополнительной схемой верхнего уровня согласно следующему образцу[92]:
Приложение 14. Примеры деловых плакатов для сотрудников подразделения по операционным рискам