Если невозможно установить ни прямую, ни опосредованную взаимосвязь инцидента ни с одной бизнес-линией, то такому инциденту, согласно Базель 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.
Причина. Уполномоченные руководители, перелистывая слайды, ожидают увидеть оценку ситуации в одной области слайда, графики в другой, показатели в третьей, причины и меры в четвертой области слайда.
Требование 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. Примеры деловых плакатов для сотрудников подразделения по операционным рискам
Сноски
1
По сравнению с кредитными и рыночными рисками.
2
Работа над рекомендациями велась 6 лет и была завершена в январе 2014 г. Все их положения полностью или по частям выносились автором на практическое экспертное обсуждение, согласование и одобрение в банковской среде (в рамках формирования нормативных документов, презентаций, отчетов, предложений рабочих групп и т. д.). Несмотря на это, изложенная информация представляет из себя лишь попытку отразить ключевые моменты управления операционным риском в сжатом и систематизированном виде, не является истиной в последней инстанции и предполагает необходимость дальнейшего обсуждения и улучшения. Также вполне очевидно, что разумность банка (с позиции операционных рисков) и как её считать по каждому из упомянутых здесь разделов можно предложить материал в объеме, превышающем настоящий труд, однако это не соответствовало бы его целям. В рекомендациях используется нумерация каждого пункта (как в нормативных документах) для обеспечения возможности использования перекрестных ссылок на какие-то пункты и разделы, и как следствие настоящие рекомендации могут применяться утилитарно – в качестве главного нормативного документа любой компании в части управления операционными рисками (при условии, если убрать некоторые разделы и заменить слова «банк» на «предприятие», «рекомендации» на «политика»).
3
Под детальным учетом понимается фиксация по инциденту всех видов данных, указанных в Приложении 4. Граница в 10 тыс. рублей может быть изменена решением комитета по рискам (см. п. 4.2.1).
4
В соответствии с п. 13–16 письма ЦБ N69-Т 16.05.12, а также документа «Principles for the Sound Management of Operational Risk», Basel Committee on Banking Supervision, June 2011.
5
Или заместитель председателя правления по рискам.
6
Сотрудники подразделения по операционным рискам.
7
Под департаментом здесь и далее подразумевается подразделение Центрального офиса / Головного банка, поименованное департаментом банка, а также иное подразделение банка, наделенное аналогичным статусом.
8
В соответствии с требованиями настоящих Рекомендаций.
9
Оформление субъектов, управляющих операционными рисками своего департамента (включая всех функционально курируемых им территориальных сотрудников) и их первичное обучение должно занимать от двух до четырех недель и производится риск-менеджерами последовательно (сначала один департамент, потом второй и т. д.). Для этих целей риск менеджеры оформляют план-график формализации субъектов первой линии защиты операционных рисков и утверждают этот план на комитете по рискам.
10
Имеются в виду сотрудники вне департамента, в т. ч. в регионах, функционально подчиненными этому департаменту.
11
Назначение риск-координаторов (помимо руководителей департаментов и лиц, замещающих их), производится из числа методологов или сотрудников, наиболее разбирающихся в процессах и регламентах своего департамента (при этом руководитель департамента контролирует их деятельность и несет солидарную с ними ответственность). Назначение производится приказом Председателя правления банка (проект приказа готовится риск-менеджером). При этом в должностных инструкциях каждого руководителя департамента и назначенных риск-координаторов фиксируется следующая обязанность: «Является риск-координатором и отвечает за организацию управления операционными рисками сотрудниками департамента (подразделения), и региональными сотрудниками, функционально подчиненными департаменту (подразделению) в соответствии с правилами, установленными нормативными документами банка».
12
Шкалу рисков см. в п. 3.3.2.
13
Назначение экспертов по инцидентам (и в обязательном порядке лиц, замещающих их) производится из числа сотрудников, которые в текущем режиме уже занимаются работой с инцидентами или которые более всего подходят к такой работе в силу своих должностных или функциональных обязанностей (риск-координатор готовит списки всех функционально курируемых им экспертов по инцидентам, в т. ч. в регионах). Назначение статуса эксперта по инцидентам производится приказом Председателя правления банка (проект приказа готовится риск-менеджером). При этом в должностных инструкциях каждого эксперта по инцидентам фиксируется следующая обязанность: «Является экспертом по инцидентам и отвечает за организацию и осуществление эффективной идентификации и работы с инцидентами, находящимися в его компетенции, а также за оказание помощи в организации функционирования риск-процедур в соответствии с правилами, установленными нормативными документами банка».