Министерство  образования и науки РФ

Государственное образовательное учреждение

Высшего профессионального образования

«Рязанский  государственный университет имени  С.А. Есенина»

      Статья  на тему:

      Автоматизация выпуска обязательной банковской отчётности

      Проблемы, подходы и примеры  реализации.

 
 
 
 
 
 

Подготовила:

студентка факультета экономики 4 курса группы Б-41

Денисова  К. Г.

Преподаватель:

Гаджиева  И. Р. 
 
 

      Рязань, 2011 

      Ключевыми требованиями к обязательной отчётности со стороны контролирующих органов являются своевременность предоставления и достоверность. Именно на обеспечение достоверности отчётных данных и пресечение попыток манипулирования отчётностью с целью её формального улучшения направлено Указание ЦБ РФ от 17.09.09 № 2293-У «О порядке отзыва у кредитной организации лицензии на осуществление банковских операций при установлении существенной недостоверности отчётных данных».

      Риски срыва сроков и снижения достоверности в случае «типовой» для российских банков технологии подготовки отчётности обоснованы несколькими факторами.

      Процесс получения любой отчётной формы  включает в себя три последовательных этапа:

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

      Этап  сбора данных наиболее трудоёмок, по различным оценкам, на него расходуется до 80 % времени, затрачиваемого на подготовку отчётности. Причина кроется, прежде всего, в децентрализации данных первичного учёта. Источниками данных являются: АБС (в которой ведётся главная книга банка), разнообразные модули учёта сделок и договоров (специальные модули в составе АБС, обособленные бэк-офисные системы, базы данных и системы собственной разработки), а зачастую - настольные базы данных и отдельные Excel-файлы. Для многофилиальных банков проблема усугубляется наличием нескольких АБС от разных производителей. В незавидном положении оказываются банки, внедрившие иностранные АБС, требующие адаптации к российским правилам бухгалтерского учёта. Сходные трудности возникают и в случае слияний-поглощений банков. Качество исходных данных снижается и по причине отсутствия синхронизации нормативно-справочных данных, используемых в различных учётных системах. Даже ведение единых справочников не исключает дублирования и искажения данных (типичный пример – дублирование данных по клиентам).

      Расчёт показателей также децентрализован и выполняется:

• специализированными модулями, входящими в состав АБС (как правило, это все показатели для отчётных форм 409101, 409102, 0409134, 0409136, 0409901, 0409902);
• бэк-офисными приложениями и (или) системами собственной разработки (как правило, это отдельные показатели или группы показателей, рассчитываемые на основе информации о сделках). Показатели данной категории участвуют в дальнейших расчётах отчётных показателей или используются для частичного заполнения форм 409135, 409110, 409125, 409155, 409634 и др.;
• вручную (с использованием средств настольной автоматизации, например Excel) на основании данных, собранных из разных систем, а также полученных по запросу из соответствующих подразделений банка.

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

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

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

      Задача  автоматизации процесса подготовки обязательной отчётности – одна из наиболее любимых ИТ-компаниями, специализирующимися на обслуживании банковского сектора. Однако до определённого момента она не входила в число приоритетных, а решалась как сопутствующая задача (в основном на базе АБС). Положение изменилось с момента выхода Инструкции Банка России от 16.01.04 № 110-И «Об обязательных нормативах банков», существенно ужесточившей требования к составу расчётных показателей и срокам предоставления отчётных форм в органы надзора. На российском рынке банковского ПО обозначился устойчивый рост спроса на специализированные решения для подготовки регулятивной отчётности.

      По  данным АРБ, с 2008 года автоматизация обязательной отчётности возглавляет рейтинг задач, которые банки решают на основе хранилища данных (ХД). Показательно, что антикризисное урезание ИТ-бюджетов качественно не изменило этой закономерности. Практически единственным направлением, на которое банки открывают новое финансирование в текущем году, является автоматизация регуляторной отчётности. Такой непреходящий интерес не объясняется только желанием соответствовать требованиям, а во многом обусловлен внутренней потребностью банков в оперативном контроле за уровнем принимаемых рисков, и в первую очередь за риском потери ликвидности. Это направление чрезвычайно важно: если в 2008 году Банк России отозвал 34 банковские лицензии, и на протяжении прошедших лет эта мера воздействия на коммерческие банки стала широко применяемой. Изменились и причины отзыва лицензий, так в 2008 году преобладали нарушители закона об отмывании средств, а теперь поводом для применения санкций преимущественно является недостаток ликвидности в банке.

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

      Первый  хорошо известен – это использование  специализированных модулей в составе  транзакционных систем. Сегодня все отечественные поставщики АБС предлагают выполненные в такой архитектуре решения для получения отчётности по стандартам ЦБ РФ. Такие модули успешно справляются с задачей подготовки оперативных отчётов (выписки по счетам, оборотно-сальдовые ведомости) и тех форм регламентированной отчётности, для получения которых используются только данные бухгалтерского учёта. И хотя отдельные производители заявляют о готовности выпускать более сложные формы (в частности, 135), под автоматизацией здесь понимается предоставление интерфейса для заполнения формы рассчитанными вне системы показателями, а не полностью автоматизированная технология расчёта необходимых для представления в Банк России нормативов.

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

      Второй  подход базируется на принципе разделения информационных инструментов учёта  и отчётности и является широко распространённым в мировой практике. Идея использования  единого хранилища для сбора  и хранения всех необходимых для  получения отчётности данных не нова. Многие российские банки широко эксплуатируют созданные специально для решения этой задачи хранилища, в 2008-2009 годах более половины проектов построения хранилищ данных в банках выполнялись с целью автоматизации выпуска пруденциальной отчётности. Плюсы технологии очевидны: для построения отчётов используются единые, согласованные и прошедшие необходимые проверки данные, что автоматически обеспечивает требуемый уровень достоверности показателей и позволяет уложиться в определённые регулятором временные рамки. Немаловажно, что построение хранилища данных делает процесс подготовки отчётности независимым от учётной системы. А это значит, что снимаются ограничения на использование высокопроизводительных, но нелокализованных решений иностранных поставщиков.

      В качестве примера можно рассмотреть конкретный банк. АКБ «Газэнергопромбанк» - это крупный региональный банк, дистрибьюторская сеть которого насчитывает 20 филиалов и более 70 точек банковского обслуживания различного формата.

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

• создание единого хранилища данных бухгалтерского учёта и сделок банка;
• автоматизация процедур очистки и консолидации первичной учётной информации;
• создание эффективной системы подготовки и выпуска регламентной отчётности по требованиям ЦБ РФ.

      В банке проводилось внедрение  новой высокопроизводительной версии Хранилища данных «Контур» (разработчик  компания Intersoft Lab), функционирующей под управлением СУБД Oracle Database 10g.

      Принципиальная  схема решения вкдючает:

• собранные в ХД данные бухгалтерского учёта по головному офису и филиалам банка, а также информация по сделкам используются для наполнения специализированных витрин данных, которые могут содержать первичные учётные данные, расчётные показатели и группировки первичных данных в соответствии с методикой предоставления отчётной информации;
• для корректного визуального представления отчётных данных используются отчётные формы, представляющие собой дополнительный пакет процедур и настроек метаданных;
• готовые печатные формы по запросу пользователя выгружаются в файлы Excel, Word, txt, html или экспортируются в формате программных продуктов, распространяемых Банком России (Kliko, ПТК ПСД, Obved). Для всестороннего анализа исходных данных может быть также использована платформа Oracle BI.

      Архитектура решения для подготовки обязательной  отчётности на базе хранилища данных «Контур»

      Настройка структур ХД проводилась на базе методической модели Intersoft Lab и заключалась в адаптации типовой модели финансового управления банком к особенностям Газэнергопромбанка. Для организации сбора данных бухгалтерского учёта в систему специалисты компании ISL разработали модуль выгрузки, осуществляющий инкрементальную выгрузку данных из АБС «Кворум».

      Выполнена архивная загрузка данных бухгалтерского учёта в систему. После загрузки архивного года выполнялись проверки на сходимость баланса, сходимость входящих остатков, оборотов и исходящих остатков, сходимость оборотов с операциями.   Следует отметить исключительно высокую пропускную способность подсистемы ввода данных ХД «Контур». Загрузка архивного года банка с 20 филиалами прошла за две недели.

      Начиная с 1 января 2010 года в банке организована ежедневная загрузка данных бухгалтерского учёта в хранилище данных. Филиалы ежедневно предоставляют в головной офис данные бухгалтерского учёта, выгруженные из АБС по окончании операционного дня. Загрузка данных одного операционного дня, включающая в себя загрузку данных бухгалтерского учёта головного офиса и 20 филиалов, занимает не более часа. Ежедневно в хранилище обновляется информация о состоянии 500 тыс. лицевых счетов, загружается около 20 тыс. оборотов по лицевым счетам, 30 тыс. операций по головному офису банка и более 150 тыс. операций по филиалам банка. При этом выполняются обязательные проверки на сходимость баланса, сходимость входящих остатков, оборотов и исходящих остатков, сходимость оборотов с операциями. Ведётся контроль ошибок загрузки. Ошибки в бухучёте филиалов оперативно исправляются.

      В процессе внедрения приложения хранилища  данных «Отчётность для Банка  России» были учтены особенности, связанные  с качеством и полнотой исходных данных и технологией ведения  учёта. Специалисты компании Intersoft Lab разработали индивидуальные алгоритмы классификации лицевых счетов и бухгалтерских проводок, а также алгоритмы расчёта показателей, реализующие бизнес-логику обработки данных при построении отчётности.

      В процессе перехода на данную модель банк получил:

1. Создано единое высокопроизводительное хранилище данных банка на платформе СУБД Oracle 10g.
2. Налажен ежедневный сбор данных бухгалтерского учёта в централизованное ХД. Информация о клиентах, лицевых счетах, остатках и оборотах лицевых счетов, о бухгалтерских документах и операциях ежедневно поступает из всех филиалов банка в головной офис. Определён регламент процесса сбора данных для подготовки отчётности. Начат сбор данных о сделках – кредитах и депозитах физических и юридических лиц.
3. Автоматизированы процедуры очистки и консолидации первичной учётной информации в единую главную книгу банка, что позволило сократить сроки выверки данных для подготовки регламентированной отчётности и снизить вероятность появления несогласованных данных.
4. Создана эффективная система подготовки и выпуска регламентированной отчётности по требованиям ЦБ РФ. Полностью автоматизирована технология подготовки комплекта отчётных форм, формируемых по данным бухгалтерского учёта (формы 101, 102, 134, 136, 245, 202, 603 и т. д., всего 17 форм).
5. Существенно снижена трудоёмкость и сокращено время на подготовку отчётности.
6. Специалисты банка получили возможность оперативно анализировать отчётные показатели в различных разрезах, при необходимости выполняя детализацию до первичных данных. Визуализация отчётных данных выполняется с использованием платформы Oracle Business Intelligence и модуля Contour Report.
7. Система подготовки отчётности на базе ХД является основой для дальнейшего поэтапного  наращивания прикладной функциональности BPM-системы.