744
Главная бухгалтерская книга банка на цифровой платформе. «Консерватор», готовый к разумным изменениям
ПЛАС: Сначала давайте поясним, зачем вообще банку Главная бухгалтерская книга и какие задачи она решает.
В. Рахманов: Модуль Главная бухгалтерская книга автоматизирует ведение бухгалтерского учета и формирование бухгалтерской отчетности. Согласно требованиям законодательства банки обязаны вести бухгалтерский учет своих операций, поэтому Главная бухгалтерская книга присутствовала во всех поколениях автоматизированных банковских систем. Ее относят к так называемой core banking функциональности.
ПЛАС: Что собой представляет Главная бухгалтерская книга банка как программный продукт?
Е. Булыгина: Можно представлять себе Главную бухгалтерскую книгу как базу данных, в которой хранится информация о счетах и проводках. На счетах отражается информация о денежных средствах и ценностях банка и его клиентов. Бухгалтерские проводки соответствуют финансовым операциям и изменяют остатки на счетах. К базе данных прилагаются многочисленные настроечные справочники. Особая роль отводится справочнику «План счетов», в котором фиксируются правила именования и систематизации счетов.
База данных сопровождается прикладной функциональностью для доступа и работы с учетными данными через пользовательский или программный интерфейс. Ведение детального аналитического учета и обобщенного синтетического учета реализуется в виде самостоятельных модулей. Отдельно представлены процедуры закрытия операционного дня, расчет баланса и формирование бухгалтерской отчетности. Особая роль отводится модулю Accounting Engine – гибкому и быстрому «движку», порождающему счета и проводки в Главной книге на основании событий продуктовых фабрик.
ПЛАС: Выглядит «классически»: высокопроизводительный «движок» и большое хранилище данных.
Е. Булыгина: Действительно, компонентная архитектура Главной бухгалтерской книги выглядит интуитивно понятной. Но за ее реализацией кроется большое количество «нюансов». Начиная с внимания к округлению и хранению денежных величин до правильного использования временных меток, реализации алгоритмов сверки, расчета остатков, вставок в прошлую дату, ведения статусов операционного дня и периодов «закрытия» отчетности, и многих других специфических для учета нюансов. Помножьте на значительные объемы хранения и высокие требования к производительности. Примите во внимание специфику работы распределенных приложений. И тогда вы поймете, что выполнение понятных с виду задач может преподнести непростые уроки.
ПЛАС: Мы уже отмечали тот факт, что банки не спешат с заменой Главной бухгалтерской книги.
В. Рахманов: Потому что это связано с высокими рисками. Главная бухгалтерская книга располагается в самом фундаменте многослойной бэк-офисной функциональности. Чем глубже изменения, тем они дороже, тем выше вероятность понести финансовые и репутационные потери. Представьте себе, что ИТ-архитектура банка – это стопка книг. Если резко вытащить книгу ближе к основанию, то с большой вероятностью обрушится вся конструкция.
Чем раньше на платформе появляется Главная книга, тем более радикальным является выбранный банком сценарий миграции. К слову, в проекте Сбербанка Главная бухгалтерская книга с самого начала устанавливается на целевую платформу. Далее она контролирует и поддерживает последовательную миграцию продуктовых модулей, которые еще называют продуктовыми фабриками.
ПЛАС: Чем объясняется столь значимая роль Главной бухгалтерской книги на распределенной платформе банка?
В. Рахманов: В первую очередь она обусловлена контрольной функцией бухгалтерского учета. Такую возможность в бухгалтерский учет заложил в 15 веке итальянский монах-математик Лука Пачоли, предложивший метод «двойной записи» (позже получивший название «двойная итальянская бухгалтерия»). Метод довольно прост: в базу данных Главной бухгалтерской книги одновременно вносятся как минимум две записи на одинаковую сумму: дебетовая и кредитовая. Эти записи, или «полупроводки», вместе составляют одну проводку и отражают атомарное движение денежных средств. «Двойная запись» помогает избегать ошибок и не допускать потерю денег, поскольку всегда понятно, откуда пришли и куда ушли деньги. Можно утверждать, что за 300 лет до Ньютона был открыт первый из законов сохранения – «закон сохранения денег».
Главная бухгалтерская книга «консервативна», как и сам бухгалтерский учет. На распределенной платформе она остается логически централизованной системой в окружении «децентрализованных» фабрик.
Е.Булыгина: Следуя методу «двойной записи», Главная книга обязывает продуктовые фабрики объединять свои распределенные операции в сбалансированные транзакции. Например, если клиент частично гасит задолженность по кредиту, используя денежные средства, размещенные на текущем счете, то транзакция будет распределена между фабрикой расчетно-кассового обслуживания и фабрикой кредитования. Она будет содержать одну операцию списания с текущего счета и две операции зачисления: на счет основного долга по кредиту и на счет процентов по кредиту. Владельцем транзакции будет одна из продуктовых фабрик, обычно та фабрика, которая инициировала транзакцию. «Сбалансированность» транзакции означает, что сумма списаний должна равняться сумме зачислений. В этом случае в Главной бухгалтерской книге можно будет собрать корректный баланс банка и сформировать достоверную финансовую отчетность.
Мы активно используем возможности Главной бухгалтерской книги для управления проектными работами. Например, содержимое Плана счетов банка практически не изменяется при переходе на новую платформу, поэтому с его помощью можно судить о статусе миграции на основании объема фактически мигрировавших бухгалтерских данных. Он также способен помочь в выявлении «потерянной» функциональности. Или вот Альбом бухгалтерских проводок: он укажет на зависимости между банковскими продуктами, что весьма важно при составлении дорожной карты миграции.
ПЛАС: Часто приходится слышать о необходимости освободить развитие продуктовой функциональности от «засилья» регуляторных требований. Как это стыкуется с тем, о чем вы рассказываете?
В. Рахманов: Нужно уточнить, что именно подразумевается под «засильем» бухгалтерского учета. У бухгалтерского учета две основные функции – контрольная и информативная. Банк остается финансовой организацией, а значит, проводимые им операции должны отвечать требованиям регуляторных органов, в частности, Российским правилам ведения бухгалтерского учета (РПБУ).
Информативная функция бухгалтерского учета не менее важна, и ее значение будет только возрастать. Бухгалтерский учет в банке является «правдой в последней инстанции». Он служит основой для анализа фактического состояния организации и принятия управленческих решений. Не имея этой информации, невозможно судить о подлинных источниках создания прибыли, о том, что работает хорошо, а где есть проблемы. Не думаю, что кто-то готов от нее отказаться.
Чаще всего недовольство вызвано тем обстоятельством, что развитие продуктовой логики приходится вести с оглядкой на регуляторные требования. Кроме того, большое количество требовании Банка России и их высокий приоритет при оценке необходимых доработок съедают значительную часть бюджета и времени. Потраченные средства могли бы использоваться для повышения конкурентоспособности банка.
ПЛАС: Какой вам видится выход из сложившейся ситуации?
Е. Булыгина: В последние годы Банк России активно продвигает новые технологии для предоставления отчетности. Фокус смещается в сторону непосредственного доступа регулятора к данным банка как альтернатива постоянным доработкам в представляемой отчетности. В качестве примера можно привести инициативу по внедрению стандарта XBRL.
С другой стороны, в ряде российских банков реализуется так называемая концепция разделения учетов, призванная обеспечить независимое развитие продуктовой логики. Согласно этой концепции, первичным является продуктовый учет, отражающий совершение операции по договору на банковский продукт. Как только продуктовый учет сформирован, клиента можно отпускать. И далее в режиме офлайн на основании данных продуктового учета формировать другие производные виды учета: РПБУ, МСФО, управленческий, налоговый. Если это делать одновременно, то такой процесс называется «параллельным учетом».
На первый взгляд, концепция разделения учетов хорошо уживается с переходом на компонентную архитектуру: продуктовый учет остается за децентрализованными продуктовыми фабриками, а производные виды учета формируются в Главной бухгалтерской книге.
ПЛАС: Но насколько реализуема указанная концепция на практике?
В. Рахманов: Разумеется, необходима адаптация к реалиям российского бухгалтерского учета. Например, при совершении кассовых операций данных продуктового учета оказывается недостаточно, поскольку клиенту необходимо вернуть кассовый ордер с данными о бухгалтерских счетах.
Основной риск данной концепции связан с отсутствием единой методологии. На платформе нового поколения продуктовый учет распределен между продуктовыми фабриками и может трактоваться ими по-разному. В отличие от бухгалтерского учета, в банке у продуктового учета нет единого и очевидного владельца. Притом что внедрение концепции разделения учетов требует модификации бизнес-процессов и изменения зон ответственности между подразделениями банка.
ПЛАС: Приходилось слышать, что разделение учетов реализовано в российских дочках зарубежных банков.
Е. Булыгина: Действительно, иногда в качестве примера приводят опыт банков, в которых применяются зарубежные банковские системы, будь то Midas+ или Flexcube. «Нативный» бухгалтерский учет в этих системах подается как аналог «первичного» продуктового учета, а вынужденная локализация к требованиям РПБУ – как реализация «вторичного» бухгалтерского учета. Безусловно, методология ведения учета, предлагаемая производителями зарубежных банковских систем, может использоваться для реализации продуктового учета. Но такая аналогия все же отчасти притянута за уши. К тому же речь идет о монолитных системах предыдущего поколения.
ПЛАС: В первой части нашего разговора вы упомянули оптимизм, связанный с появлением новых технологий. Что именно вы имели в виду?
Е. Булыгина: В первую очередь облачные технологии и блокчейн. В интернете немало статей, скептически комментирующих изначальные ожидания от блокчейна. На наш взгляд, это несправедливо. Независимо от того, насколько широкое применение в конечном итоге получит эта технология, ряд привнесенных ею инновационных решений уже используются и будут применяться в дальнейшем. В комбинации с облачными сервисами эти технологии позволяют банкам находить новые сценарии для перехода на цифровые платформы.
ПЛАС: И это при том, что для многих банков облачные технологии все еще остаются дорогостоящей инвестицией?
Е. Булыгина: Появляются решения, способные повысить рентабельность инвестиций в «облака», – это модели типа «услуга как сервис». Они ориентированы на различные категории пользователей и способны обеспечить гибкость между ценой и предложением. Например, модель «инфраструктура как сервис» (IaaS) позволяет пользователю гибко масштабировать потребляемые облачные ресурсы. Модель «платформа как сервис» (PaaS) предоставляет ему платформу и инструменты для ведения разработки, тестирования и развертывания приложений. Появляется возможность полностью сконцентрироваться на создании нового продукта, временно арендуя подготовленную инфраструктуру.
Наконец, модель «программное обеспечение как сервис» (SaaS) предлагает пользователю готовый продукт, работающий в облаке. Допускается замена словосочетания «программное обеспечение» на название конкретной области применения программного продукта. Например, модель «банкинг как услуга» (BaaS) предлагает пользователю функциональность core banking. Именно модель BaaS лежит в основе популярной ныне технологии «встроенного финансирования». Банк публикует интерфейсы для доступа к своим цифровым продуктам и предоставляет их небанковским компаниям. Небанковские компании получают возможность предлагать своим клиентам финансовые услуги, не имея банковской лицензии, а банк получает еще один канал распространения услуг.
ПЛАС: И как это связано с переходом банков на новую платформу?
В. Рахманов: Появляется еще один не очень радикальный сценарий миграции. В качестве примера можно привести стартап инвестиционного банка Goldman Sachs: в 2016 году банк на основе собственного решения типа BaaS за восемь месяцев создал и открыл свое цифровое дочернее подразделение Marcus. Marcus работал на облачном решении от Goldman Sachs, содержащем «функциональное ядро» и единственный продукт – мгновенные кредиты. Эксперимент оказался успешным: Marcus сумел привлечь более 5 миллионов клиентов, а Goldman Sachs апробировал свой облачный core banking и даже монетизировал его.
Таким образом, сценарий миграции может состоять из двух этапов. Сначала платформа реализуется как облачная модель типа BaaS с функциональным «ядром» и несколькими шаблонами для реализации классических банковских продуктов: депозитов, кредитов и расчетно-кассового обслуживания. Это решение лицензируется поставщиком и не допускает кастомизации. Предполагается, что на основании этого решения можно автоматизировать бизнес-процессы финтеха или небольшого банка. Если необходима реализация более «экзотических» продуктов, то модель BaaS следует расширить до модели SaaS, предоставляющей инструменты для программирования банковских продуктов. На рынке уже существуют инструменты для реализации подобного подхода, наиболее известные из них – Mambu и Thought Machine.
ПЛАС: А какие новые возможности привносит в функционал Главной бухгалтерской книги блокчейн?
Е. Булыгина: В первую очередь способность к интеграции процессов. Сегодня часто можно слышать о том, как блокчейн позволяет интегрировать бизнес-процессы банка и его клиентов. Но аналогичным образом можно интегрировать и внутрибанковские процессы, например, процессы двух или нескольких продуктовых фабрик. Для решения этой задачи блокчейн предлагает решение, основанное на четырехзвенной архитектуре продуктовых модулей, в которой уровень данных разделен на приватные и общедоступные данные. Интеграция через общедоступные данные может прийти на смену интеграции на основе API.
Еще одна уже сейчас востребованная технология – неизменяемые базы данных или базы данных типа ledger. Их безусловным преимуществом являются гарантированная целостность и встроенный аудит. Главная книга банка на основе неизменяемой базы данных выглядит как очень привлекательное решение.
Наконец, смарт-контракты. Они предлагают по-иному взглянуть на программирование бэк-офиса. Функциональность цифрового бэк-офиса должна программироваться не для автоматизированной поддержки деятельности специалистов банка, а в логике конечного автомата со своей статусной моделью и обязательным переходом в конечное состояние. В этом случае операционное сопровождение должно уйти в «ноль», а банк может стать на 100% цифровым банком.
