B 2019 году ожидается несколько глобальных изменений в российском банковском бизнесе, связанных с цифровой трансформацией, такие как маркетплейс ЦБ, система быстрых переводов и т.д.

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

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

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

Один из современных трендов в банковской IT-сфере — разделение учетных систем на слои: каналы взаимодействия с клиентами (маркетплейс, обеспечивающий продажу продуктов, мобильный банкинг, интернет-банкинг, ДБО); фронт-офис, обеспечивающий процессы продажи и обслуживания продуктов; продуктовые системы, обеспечивающие жизненный цикл банковского продукта, и учетный слой, который агрегирует в себе все события в продуктовых системах и отражает их на лицевых счетах бухгалтерского учета.

В данном подходе выделенная Главная книга становится ядром архитектуры приложений банка, предназначенной для автоматизации учета, обеспечения хранения и обработки учетных данных по операциям в соответствии с требованиями бухгалтерского учета Банка России (№ 385-П «О правилах ведения бухгалтерского учета в кредитных организациях, расположенных на территории Российской Федерации»), МСФО, а также внутренней управленческой отчетности.

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

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

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

Первой частью решения является универсальная банковская Главная книга, в функции которой входят: централизованное ведение бухгалтерского учета банка; возможность одновременного ведения нескольких планов счетов (РСБУ, в соответствии с учетной политикой банка, МСФО, внутренний управленческий учет); гибкая настройка аналитических учетных срезов, обеспечение процессов открытия, закрытия лицевых счетов; учет плановых и фактических остатков, учет остатков и оборотов в валюте счета и национальной валюте; проведение массовых учетных операций, таких как переоценка или свертка остатков на парных счетах; управление операционными днями с возможностью раздельного закрытия дней по филиалам и областям учета; составление и контроль бухгалтерского баланса банка.

Вторая часть, Accounting Engine, — это система до обогащения и трансформации продуктовых бизнес-событий, которая представляет собой неотъемлемую часть системы Accounting Solution, обеспечивающей настройку правил преобразования бизнес-события в учетное в соответствии с настроенной учетной моделью.

Функции этой части решения включают в себя: загрузку бизнес-событий из продуктовых систем; валидацию и контроль качества входных данных (как технический, так и проверку бизнес-целостности данных); управление процессом их обработки (в том числе контроль необработанных данных и процессы их исправления); гармонизацию бизнес-событий; формирование учетного события универсального формата, так как источников и входящих форматов может быть очень много; создание недостающих учетных событий, которые не формируются продуктовой системой (например, переносы по срокам до погашения для ПФИ); генерацию учетных событий, достаточных для создания бухгалтерских проводок в Главной книге.

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

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

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

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

Реклама