Неочевидные шаги цифровой трансформации

Под цифровой трансформацией часто имеется ввиду биометрическая идентификация, финансовые маркетплейсы, Open API, искусственный интеллект и очень редко говорится о том, что трансформация коснется центральных учетных и продуктовых систем банка.

В 2019 году ожидаются несколько глобальных изменений в российском банковском бизнесе, связанных с цифровой трансформацией, такие как маркетплейс ЦБ, система быстрых переводов и т.д. Банковский бизнес усложняется последние 7-9 лет, находясь в постоянном поиске новых продуктов, каналов продаж и обслуживания. Особенно динамично идут изменения последние несколько лет, связанные со снижением маржинальности банковских продуктов, увеличения регуляторного давления со стороны Центрального Банка, а теперь и реализацией цифровой инфраструктуры. Это является следствием постоянного усложнения информационной архитектуры банка. Сегодня нет на рынке решения, которое способно было бы обеспечить учет всего разнообразия банковских продуктов. В средних и крупных банках задачи учета и отражения операций «размазаны» по разным системам, информационная структура банков перешла от модели единой банковской системы к модели мультисистемной архитектуры, где продажа, учет различных банковских продуктов осуществляется в специализированных, узко «заточенных» решениях. Ландшафт инфраструктуры банков становится сложнее, и «сделочная» информация ведется более, чем в одной системе. В данной архитектуре возникает сложность в централизации учетных и бухгалтерских функций, особенно это характерно для банков, в архитектуре которых стоят системы западных вендоров.

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

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

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

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

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

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

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

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

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

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

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

Если у вас возникнет желание поделиться своими мыслями и опытом или подискутировать на темы, затронутые в этой статье – мы будем благодарны за любые комментарии, наши контакты: info@rbtechnologies.ru