Р. Бедрединов - Управление операционными рисками банка: практические рекомендации Страница 18

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

• оказывает необходимую консультационную помощь инициаторам ввода / упразднения подразделений и штатных единиц;

• координирует внедрение ИТ-системы учета изменений организационно-штатной структуры, координирует использование этой системы;

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

• организует исполнение иных требований п. 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 коды).