Способы снижения операционного риска

Выдержка из книги «Анализ кредитных рисков»
автор: Наталья Костюченко

В качестве методов ограничения операционного риска можно предложить:

● Разделение функций по проведению сделок, которые должны производиться сотрудниками отдельных независимых подразделений, в целях персональной ответственности за каждую операцию и исключения возможности провести финансовую операцию от начала до конца, не уведомив иные подразделения;

● Создание контрольной среды, то есть наличие встроенной системы контроля в ежедневные операции в целях повторного контроля операций со стороны независимого контролера путем подтверждения или двойного ввода информации;

● Введение мер операционной, технической и физической безопасности (например, путем ограничения физического и логического доступа к информации с помощью шифрования, паролей и т.д.);

● Обеспечение хранения, обработки и передачи данных, наличие дублирующих мощностей в телекоммуникационных и вычислительных сетях, обеспечение целостности данных и программного обеспечения;

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

● Определение приемлемого уровня операционных рисков, присущих деятельности банка на финансовых рынках, и установление лимитов.

● Для большинства операций достаточным лимитом будет служить объемный лимит, ограничивающий оборот в рамках той или иной деятельности или объемы вложений в определенные активы / пассивы. Целесообразным может быть лимитирование величин отдельных операций, проводимых под операционным риском;

● Юридический контроль оформления операций (договоры и прочие документы);

● Подтверждение сделки контрагентом, т.е. проведение расчетов только по факту получения от контрагента подтверждения сделки по надежным каналам связи;

● Наблюдение за операционными рисками с целью принятия мер по поддержанию рисков на приемлемом уровне;

● Контроль правильности, адекватности и полноты применения утвержденных процедур контроля и управления определенным уровнем рисков, а также независимая оценка результатов деятельности;

● Передача операционного риска третьим лицам путем страхования и аутсорсинга (привлечение специализированной сторонней организации для выполнения отдельных видов работ/услуг) или отказ от осуществления определенных видов сделок.

Минимизация операционного риска в АБС. Технологический подход.

Известно, что самым слабым звеном в автоматизированных системах при выполнении стандартных (рутинных) процедур является человек (для АБС — операционист), поэтому технологический подход в самом общем виде направлен на снижение риска человеческого фактора при выполнении банковских операций. Основным направлением здесь с точки зрения минимизации операционного риска является максимальная автоматизация процессов управления и контроля информации на стадиях ввода/вывода данных в/из АБС.

Практика борьбы за снижение операционного риска выработала ряд типовых на сегодняшний день подходов, которые реализуются во всех промышленных АБС. Рассмотрим некоторые из них.

Управление правами доступа пользователей — позволяет разграничить доступ к информации в зависимости от компетенции и сферы ответственности конкретного исполнителя. Так, например, можно предоставить право формировать и корректировать реквизиты платежного поручения одному пользователю, в то время как другой пользователь будет иметь только право просмотра. Тем самым снижается риск внесения ошибочных данных неквалифицированным пользователем.

Автоматизированное заполнение документов условно постоянной информацией — минимизирует ручной ввод данных операционистом. При этом используются такие приемы, как:

• применение различных настроечных параметров (реквизиты банка, оргструктура, ФИО руководства и т.п.), информация из которых автоматически включается в различные платежные документы, отчеты и другие документы;
• справочники-классификаторы с нормативно-справочной информацией (НСИ), которая используется как при заполнении исходящих, так и при контроле входящих документов. Состав таких справочников в АБС достаточно широк, он включает в себя общероссийские классификаторы (ОКВЭД, ОКПО, СОАТО и др.), отраслевые классификаторы (ЦБ РФ, МНС, ФСФМ, ФСФР и др.), а также ряд международных стандартов (ISO, SWIFT, стандарты международных платежных систем);
• шаблоны операций и документов с предварительно заполненными параметрами, например маски счетов, коды документов, коды операций и т.п. Такие шаблоны позволяют избежать полного ручного заполнения документов — достаточно указать сумму и детали платежа. Если учесть, что количество платежных (и других) документов, формируемых в АБС, достаточно велико, а число реквизитов в таких документах тоже немалое, такие шаблоны являются эффективнейшим средством снижения операционного риска;
• формализованное описание условий типовых договоров, банковских продуктов (типы операций, процентные ставки, пеня, срочность и т.п.) — также позволяет избежать появления ошибок как при первоначальном вводе договора, так и при последующей его обработке (начисление процентов, пролонгация, закрытие);
• реализация протоколов обмена с внешними системами РКЦ, SWIFT, карточными процессингами и др. — исключает ручной набор платежных документов на терминалах соответствующих внешних систем. При этом очень важно обеспечить хранение в АБС формализованных описаний расчетных инструкций контрагентов.

Как видно из контекста, указанные приемы в основном направлены на минимизацию ввода реквизитов непосредственно операционистом за счет использования системной предварительно проверенной информации, хранящейся в базе данных.

Способствует снижению операционного риска и основной принцип СУБД — однократность ввода информации и многократное ее использование в различных приложениях. При этом важным элементом являются выделение и использование типовых (стандартных, ядерных) прикладных процедур, например расчета процентов, в различных функциональных модулях АБС. Здесь же следует отметить важность разработки и использования таких организационно-технических приемов, как:

• организация двойного ввода значимой информации;
• акцепт выполняемых операционистом операций вышестоящим лицом;
• применение дополнительных процедур контроля результатов расчета, которые особенно широко используются при формировании банковской отчетности (поверочные тесты, расшифровки сводных и агрегированных данных и т.п.).

Минимизация операционного риска в АБС. Функциональный подход.

Перечисленные выше методы снижения операционного риска не претендуют на полноту охвата, главная их особенность — это то, что они могут быть применены для любого реализуемого в АБС банковского продукта. В то же время порядок и правила выполнения банковских операций достаточно жестко регламентируются нормативными документами Банка России, начиная с правил бухгалтерского учета (формирование плана счетов и номеров счетов, выполнение проводок и т.п.) и заканчивая четкими требованиями к геометрии форм выходных документов. Кроме того, существует жесткая регламентация и со стороны внешних систем, с которыми взаимодействует АБС.

Поэтому важнейшим элементом снижения операционного риска является соответствие результатов функционирования программного обеспечения АБС этим внешним требованиям. Другими словами, алгоритмы и их реализация (код программы) не должны содержать ошибок, то есть отличий от заявленной функциональности банковского продукта и от законодательных требований к условиям его реализации.

Минимизация рисков здесь достигается за счет хорошо проработанных промышленных методов разработки ПО, анализ которых не входит в предмет настоящей статьи. Можно лишь отметить, что набирающий в последнее время популярность подход к независимой реализации сервисов в рамках информационных систем (SOA — сервис-ориентированная архитектура), безусловно, способствует минимизации операционного риска. Дело в том, что «монолитное» ПО, в котором одни и те же процедуры используются для реализации различных банковских продуктов, чрезвычайно чувствительно к модификациям — любое вносимое в интересах конкретной функциональности изменение может непредсказуемо отразиться на других функциях. А так как в настоящее время поток нормативных изменений правил выполнения банковских операций и формирования отчетности достаточно интенсивный, то и соответствующие изменения в ПО АБС вносятся практически постоянно.

Минимизация операционного риска в АБС. Методологический аспект.

В основе функционирования любой автоматизированной информационной системы лежит двоичная логика. Поэтому реализация в виде программного кода возможна лишь для четко формализованных алгоритмов. Ярчайшей иллюстрацией этого тезиса является создание в настоящее время шахматных компьютерных программ, превосходящих шахматистов-профессионалов. В этом нет ничего удивительного — ведь шахматная партия развивается по четким, строго определенным правилам, количество вариантов ходов для каждой фигуры в каждой ситуации также отнюдь не бесконечно. Поэтому формализованное описание правил в виде программного кода вполне осуществимо, а количество анализируемых вариантов зависит от быстродействия вычислительных средств. А так как компьютер не устает и не «зевает», то у него есть преимущество перед человеком.

Возвращаясь к операционным рискам в АБС, в этой связи следует отметить огромное значение для их минимизации методологического обеспечения, под которым здесь понимается законодательная база. В самом деле, чем четче прописаны правила выполнения операций в законах, инструкциях, распоряжениях и других нормативных документах, тем меньше риск возникновения ошибок при реализации банковского продукта в АБС.

К сожалению, текущая ситуация далека от идеала. Так, например, задуманная одно-значная идентификация физических и юридических лиц по ИНН не дала должного результата. Из-за этого разработчики АБС вынуждены изобретать свои собственные эвристические алгоритмы идентификации клиентов, которые не всегда срабатывают правильно.

Другим примером являются правила формирования документа «Платежное поручение». В свое время эти правила были дополнены порядком формирования полей для налоговых реквизитов. Однако такой важный реквизит, как НДС, был оставлен в неструктурированном поле «Назначение платежа», причем его печать в выходной форме необходимо осуществлять с новой строки. Эту ситуацию каждый разработчик ПО также решает по-своему.

Таких примеров можно привести достаточно много. Но эти проблемы в процессе эксплуатации постепенно решаются также эмпирическим путем. В настоящее время в связи с практикой применения Федерального закона «О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма» рассматриваемый здесь методологический аспект приобретает особое значение.

Практически во всех АБС появился дополнительный функционал для реализации положений упомянутого Закона и связанных с ним нормативных актов Банка России и других правительственных органов власти:

• идентификация клиентов, установление и идентификация выгодоприобретателей — сбор информации в целях противодействия легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма;
• выявление операций, подлежащих обязательному контролю, и иных операций с денежными средствами или иным имуществом, связанных с легализацией (отмыванием) доходов, полученных преступным путем, или финансированием терроризма;
• выявление среди клиентов или участников операций лиц и организаций, причастных к терроризму;
• формирование сообщений в уполномоченный орган (ФСФМ).

Появились даже автономные программные продукты с такой функциональностью, которые используют сведения, экспортируемые из АБС.

Имеется достаточно большое количество методических разработок, определяющих порядок идентификации клиентов, выявление операций, подлежащих обязательному контролю, протоколы передачи данных в ФСФМ.

Вместе с тем и в этих нормативных документах имеются положения, не поддающиеся формализации в рамках АБС. Примерами могут служить группы операций, приведенных в Положении ЦБ РФ от 20.12.2002 № 207-П и отмеченных кодами 5000 «Иные сделки с движимым имуществом» и 8000 «Сделки с недвижимым имуществом». Так как через банк проходят платежи по указанным сделкам, а в платежных документах пока никак не регламентированы ссылки на такие сделки, то выявить автоматизированным способом такие платежи невозможно, и риск невыявления таких операций достаточно велик. Что это означает для банка — можно легко себе представить.

На практике для выявления операций, подлежащих обязательному контролю, в АБС применяются различные способы фильтрации платежных документов:

• по корреспонденции счетов, соответствующих предварительно настроенным шаблонам;
• по нахождению суммы платежа в определенных пределах;
• по наличию в поле «Назначение платежа» определенных словосочетаний.

Окончательное решение по отбору операций остается за операционистом. Если учесть, что, как правило, количество документов, отобранных по такому сочетанию фильтрующих параметров, бывает достаточно большим, эффективность такого контроля оставляет желать лучшего.