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

- kbrbank

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

Неприятности, примеры и подходы реализации.

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

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

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

Таковой непреходящий интерес не разъясняется лишь жаждой «угодить» регуляторам, а во многом обусловлен внутренней потребностью банков в своевременном контроле за уровнем принимаемых рисков, и прежде всего за риском утраты ликвидности. Цена вопроса весьма громадна: в случае если в 2008 году Банк России отозвал 34 банковские лицензии, то в 2009 году, согласно расчетам генерального директора Агентства по страхованию вкладов А. Турбанова, лицензий лишатся от 50 до 60 банков. Изменились и обстоятельства отзыва лицензий, так в 2008 году преобладали нарушители закона об отмывании средств, а сейчас предлогом для применения санкций в основном есть недочёт ликвидности в банке.

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

Неприятности и подводные камни

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

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

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

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

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

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

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

Кроме того ведение единых справочников не исключает искажения и дублирования данных (обычный пример – дублирование данных по клиентам).

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

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

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

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

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

технологии и Подходы

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

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

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

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

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

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

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

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

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

Незначительные трансформации в составе объектов либо трансформации атрибутов потребуют полной ХД.

Хранилище разрешённых должно быть выстроено на базе качественной бизнес-модели данных, отражающей особенности национального бухгалтерского учёта и легко кастомизируемой. Механизмы хранилища разрешённых должны обеспечивать:

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

Проект построения совокупности подготовки необходимой отчётности

(на примере АКБ «Газэнергопромбанк»)

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

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

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

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

Принципиальная схема ответа представлена на рисунке:

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

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

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

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

Загрузка архивного года банка с 20 филиалами прошла за 14 дней.

Начиная с 1 января 2009 года в банке организована ежедневная загрузка данных бухучёта в хранилище данных. Филиалы каждый день предоставляют в главный офис эти бухучёта, выгруженные из АБС по окончании операционного дня. Загрузка данных одного операционного дня, включающая в себя загрузку данных бухучёта филиалов и головного 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-совокупности.

В состав приложения «Отчётность для Банка России» включён специальный модуль формирования отчётов Contour Report. Модуль делает пара функций: генерирует печатные формы отчётов по запросу пользователя, употребляется для корректировки либо ручного ввода отдельных показателей, снабжает выгрузку отчётов в формате программ ЦБ РФ и управление процедурами экспорта файлов в нужный формат (txt, html, xls, doc). Потому, что заполнение отчётных форм производится заблаговременно подготовленными в витринах данных показателями, генерация любого отчёта выполняется весьма скоро (в течение нескольких мин.).

Ольга МОРОЗОВА, начальник отдела документации компании Intersoft Lab,

Андрей БУРЫМ, глава департамента IT Газэнергопромбанка

Автозаполнение реквизитов платежек по налогам и взносам. Видео уроки «1С:Бухгалтерия 8».

Интересные записи

Похожие статьи, которые вам, наверника будут интересны: