Особенности внедрения лимитной системы в универсальном банке Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 336.71

Особенности внедрения

лимитной системы в универсальном

банке

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

Ключевые слова: автоматизированная система; банк; информационная система; контроль лимитов; лимитная система; система контроля рисков.

Abstract. This article discusses the problems that arise during the implementation of a typical investment activity limits control system in a multipurpose bank. The main components of such systems, their internal and external communications, and the main stages of implementation were analyzed in the article. The common errors of the implementation were identified and described in connection with possible after-affects. Based on this analysis the author offers practical recommendations on the design and implementation of an automated limit control system.

Keywords: automated system; bank; limits control; limit system; risk management system.

^ftgk Черкунов Л.А.,

'JM аспирант кафедры «Информационные

tri I

-- I технологии» Финансового университета

Iх И [email protected]

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

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

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

На равных с ней конкурирует продукт Kondor+/ KGR компании Misys, который характеризуется модульностью и наличием механизмов обратной совместимости при отсутствии отлаженных взаимосвязей модулей.

АБС.СПО отечественной компании Csbigroup обладает открытым кодом, однако платной и непопулярной платформой. Существуют также другие, менее известные и распространенные программные комплексы: Axiom, CorrTec, Polaris, iDEAL [1, 2]. Несмотря на достаточно большой выбор, все перечисленные системы обладают схожим базовым функционалом.

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

Научный руководитель: Заложнев А.Ю., доктор экономических наук, профессор.

Рис. 1. Архитектура лимитной системы класса standalone

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

Все перечисленные выше системы относятся к наиболее быстро развивающемуся классу автономных (standalone). Их характерными особенностями являются:

• возможность адаптации к уже существующим банковским системам; не требуют существенной переделки функционирующих банковских систем и используемых алгоритмов в процессе внедрения и эксплуатации [3];

• все необходимые для функционирования элементы уже включены в набор программного обеспечения (ПО);

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

• при внедрении автономных систем контроля лимитов стараются минимизировать изменения в связанных бизнес-процессах.

Архитектура рассматриваемых систем представлена на рис. 1.

1. Архитектура standalone-систем

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

1.1. Лимитный модуль

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

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

• на эмитентов или контрагентов по сделкам;

• на различные типы инструментов;

• на портфели ценных бумаг;

• на принадлежность различных элементов к определенным странам;

• на отрасли деятельности;

• на валюту сделки/бумаги;

• по рейтингу;

• по пользователям системы (позволяют контролировать отдельных трейдеров).

Следующим шагом в определении лимита является выбор его вида и внесение контрольного значения. Основные виды лимитов следующие:

• абсолютные;

• относительные;

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

• динамические (когда контрольное значение изменяется во времени).

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

Для того чтобы конечные потребители могли легко воспользоваться рассчитанной информаци-

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

1.2. Ядро - базовый модуль системы

Хранением и первичной обработкой данных со стороны лимитной системы занимается ядро или базовый модуль. К основным его функциям относятся обеспечение базового функционала: работа с базой данных и поддержание целостности информации в ней; функции коррекции возникающих в БД ошибок; предоставление унифицированного пользовательского интерфейса; разграничение прав доступа пользователей; функции администрирования системы; функции сохранения истории действий пользователей. Кроме того, ядро должно обеспечивать базовый финансовый функционал, а именно: хранение и обеспечение работы со справочниками финансовых инструментов; хранение списка сделок и дополнительной информации по ним; расчет финансовых показателей по хранимым инструментам.

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

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

с помощью написания дополнительных надстроек при внедрении и последующей эксплуатации.

1.3. Шлюзы - подготовка и передача данных извне

Для подготовки и передачи данных из внешних источников используется специальное программное обеспечение — шлюзы. Процесс подготовки и передачи данных состоит из следующих этапов:

• получение данных из всех внешних систем;

• фильтрация полученной информации;

• конвертация структуры данных;

• расчет производных параметров на основе полученных данных;

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

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

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

1.4. Внутренние шлюзы

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

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

В случае применения архитектуры с внутренними шлюзами возникает проблема дублирования одних и тех же данных в разных модулях. Это, во-первых,приводит к росту требований к базам данных, а, во-вторых, создает проблему синхронизации данных и поддержания их целостности.

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

2. Внешние данные standalone-систем

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

При использовании внешних данных возникают следующие проблемы.

• Несовпадение структур данных и баз данных. Для того чтобы передать данные из системы в систему, их необходимо предварительно подготовить.

• Различные поставщики баз данных. У разных вендоров приемы работы с данными могут различаться, что также создает дополнительные сложности при обработке информации.

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

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

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

3. Этапы внедрения

Несмотря на возможность адаптации к уже существующим АБС,принятие решения о приобретении standalone-системы вовсе не означает, что все действия по внедрению предполагают только установку необходимого оборудования и программного обеспечения (ПО). Процесс внедрения -процесс продолжительный и включает следующие этапы [4]:

• предпроектное исследование - подготовительные работы и предпроектное обследование;

• постановку задач и формирование технического задания (ТЗ);

• рабочее проектирование и адаптацию ПО;

• создание пилотного проекта;

• внедрение системы;

• ввод в эксплуатацию;

• поддержку;

• автономное функционирование.

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

1. Предпроектное обследование с постановкой задач и формирование ТЗ.

2. Рабочее проектирование и адаптация ПО, создание пилотного проекта.

3. Внедрение системы, ввод ее в эксплуатацию, начало процесса поддержки и автономного функционирования.

В силу автономности систем рассматриваемого класса, их разработкой и внедрением обычно занимаются сторонние организации. 3.1. Предпроектное обследование Перед тем как начать внедрение, необходимо провести детальное обследование затрагиваемых бизнес-процессов и существующих АБС. Главной целью данного этапа является определение места будущей лимитной системы среди иных банковских систем. Наиболее тесно лимитные системы взаимодействуют с торговыми системами, получая оттуда необходимые данные: текущие котировки бумаг, объемы торгов, волатильности, информацию о совершенных сделках. Окончательный набор данных определяется требованиями к функционалу системы, типами сделок и видами лимитов. В обратную сторону к торговым системам идут команды на совершение сделок: на сокращение позиции при превышении лимита, при достижении контрольного уровня. Лимитные системы также тесно взаимодействуют с системами управления отчетностью, получая данные о результатах деятельности в прошлом и представляя текущие фи-

нансовые отчеты. Из CRM-систем берутся данные о контрагентах для совершения сделок.

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

3.2. Первый этап внедрения системы

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

Необходимо очертить круг задач, решением которых должна в итоге заниматься система. По мнению автора, система контроля лимитов призвана решать следующие основные задачи.

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

• Подготовка данных от внешних поставщиков. Нужно отфильтровать, устранить ошибки, привести к заданной структуре и провести первичные расчеты необходимых показателей.

• Обеспечение надежного хранения данных. Возможность утери или порчи данных должна быть исключена.

• Группировка и сортировка сделок или иных элементов, на которые устанавливаются лимиты.

• Расчет использования лимита. В состав инструментальных средств системы должны включаться наиболее популярные алгоритмы расчета,

также должна быть предусмотрена возможность создания собственных механизмов.

• Сохранение исторических данных об использовании лимитов, а также их составе.

• Наличие механизма создания и отображения отчетов об использовании различных показателей.

• Зная задачи лимитной системы, можно сформулировать и основные требования к данному классу информационных систем.

• Наличие дружественного интерфейса, легкость в освоении, наличие качественной документации, технической поддержки и другие стандартные требования, предъявляемые к современным информационным системам.

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

• Корректность применяемых алгоритмов расчета. В случае наличия ошибок в алгоритмах расчета ПО может работать стабильно, выдавать ошибочные результаты, что, в конечном итоге, может привести к серьезным потерям.

• Расширяемость и гибкость. Чтобы соответствовать постоянно меняющимся требованиям, все элементы должны легко модифицироваться и обновляться, сохраняя при этом сделанные ранее наработки.

• Сервисная пригодность. Обязательно должны быть предусмотрены механизмы регламентного и экстренного обслуживания.

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

3.3. рабочее проектирование и реализация

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

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

3.4. Поддержка и автономное функционирование

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

Параллельно с самостоятельной разработкой необходимо проводить оптимизацию и ревизию кода как проводимых доработок, так и модулей, код которых открыт. Основные цели ревизии таковы:

• уменьшение количества ошибок;

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

• удешевление сопровождения приложения как следствие обеспечения совместного владения кодом;

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

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

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

Заключение

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

• формулирование требований;

• выбор архитектуры;

• тщательное изучение особенностей построения и функционирования;

• планирование на основе знаний об особенностях системы;

• контроль качества на каждом этапе работ;

• контроль качества программного кода и документации;

• контроль поставляемых компонентов;

• недопустимость переноса работ на последующие этапы;

• контроль за работоспособностью алгоритмов и адекватностью доработок.

И, наконец, что особенно важно: не следует подписывать никакие документы, относящиеся к внедрению системы и имеющие юридическую силу, на основании «доброй воли сторон».

литература

1. Financial Risk Management Software: financial risk management, crédit risk software // http://www.capterra.com/financial-risk-management-software (дата обращения: 21.03.2014).

2. Inntron Intelligence: Banking Back Office, Treasury, Trade, Asset, Risk Management Software //http://www.inntron.com/treasury.html ^дата обращения: 21.03.2014).

3. Standalone software // http://en.wikipedia.org/wiki/Standalone_ software (дата обращения: 25.03.2014).

4. Когаловский М.Р. Перспективные технологии информационных систем. М.: ДМК Пресс; Компания АйТи, 2003. 283 с.

5. Юркевич В.В. Надежность и диагностика технологических систем. М.: Academia, 2011. 216 с.

6. Каштанов В.А. Теория надежности сложных систем. М.: Физматгиз, 2010. 606 с.

7. Hassan Gomaa. Software Modeling and Design. Fairfax, Virginia: George Mason University, 2011.