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

• аутсорсинговые, «облачные», территориально удаленные продукты и процессы.

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].

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

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.