Таким образом, переходя непосредственно к теме управления ликвидностью банка, можно дать следующее определение. Управление ликвидностью - это ежедневное балансирование между риском недополучения дохода (в случае недоразмещения ликвидных, но недоходных активов в менее ликвидные, но зато доходные) и риском избыточных расходов (в случае предъявления к исполнению платежных обязательств, превышающих существующие возможности банка, и, соответственно, необходимости привлекать средства с рынка).

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

3.2.1. Автоматизированное управление ликвидностью ЗАО «НГБ»

Как нет в природе двух одинаковых людей, так нет и не будет одинаковых банков. Соответственно, и методики управления ликвидностью, которыми пользуются конкретные финансовые институты, будут, хотя бы частично, разниться. Различаются также и программные системы, хранящие данные, необходимые для управления ликвидностью, и конкретные процедуры работы банка. Таким образом, в идеале каждый банк должен разрабатывать индивидуальное автоматизированное решение для управления собственной ликвидностью. К счастью, сотрудникам банка нет необходимости делать это «с нуля». Многие отечественные компании предлагают программные продукты, предназначенные для аналитической работы, а также готовы помочь в адаптации своего продукта к той или иной задаче. Например, в начале 2004 года на базе АПК «Нострадамус» специалисты компании «ПрограмБанк» раз­работали индивидуальное прикладное решение для управления ликвидностью для одного из ведущих финансовых институтов Ямалаа – ЗАО «Ноябрьский городской банк».

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

Осенью 2004 года руководство ЗАО «НГБ» дало свое согласие на реализацию пилотного проекта по разработке и внедрению в банке системы автоматизации управления ликвидностью. На тот момент специалисты управления экономического анализа, прогнозирования и казначейства НГБ, использующие набор стандартных программных продуктов, испытывали серьезные трудности при решении этой задачи. Именно по этой причине в банке было принято решение приобрести аналитическую систему. Проведя анализ предложений рынка банковских информационных технологий, специалисты банка остановили свой выбор на комплексе «Нострадамус», предназначенном для разработки и реализации прикладных решений, в первую очередь, в области банковской аналитики. Необходимо пояснить, что комплекс является мощной аналитической системой класса OLAP (оперативной аналитической обработки), в основу которой положена технология хранилища данных (Data Warehouse). По словам специалистов банка, их выбор был обусловлен, прежде всего, универсальностью технологии комплекса, которая позволяет собирать в единую базу данных самую разнообразную информацию любых форматов (в том числе, из разных бизнес-систем), систематизировать ее, и приводить ее к единому формату. Работа специалистов проекта «Нострадамус» в НГБ, начиная с формулировки задачи до сдачи готового решения в промышленную эксплуатацию, ограничилась всего четырьмя месяцами. На первом этапе внедрения совместно с сотрудниками банка была определена задача - разработка и реализация методики планирования среднесрочной (от 1 недели до 3 месяцев) и мгновенной ликвидности. После определения списка типов платежей, влияющих на уровень ликвидности, началась непосредственно разработка.

3.2.2. Проблема загрузки данных

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

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

3.2.3. Генерация справочников, отчетов и настройка пользовательского интерфейса

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