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

— Виталий, что меняется для организации, когда она переходит к сдаче отчетности в формате XBRL?

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

При переходе на XBRL появилась единая таксономия, содержащая все правила для представления отчетности. Таксономия описывает правила составления отчетных сведений в машиночитаемом виде, и подотчетная компания предоставляет регулятору XBRL-отчетность в виде единого массива информации в формате XBRL.

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

XBRL минимизирует необходимый для предоставления отчетной информации регулятору объем документов.

Ранее наличие определенных несоответствий между разными пакетами отчетности не приводило сразу к непосредственным замечаниям от ЦБ. Но после введения XBRL вся отчетность, которую организация предоставляет в ЦБ, должна быть согласована между собой, и это предъявляет дополнительные требования к процессу ее подготовки и выверки.

— В чем сложность перехода для банков? XBRL предполагает новый вид отчетности?

— Хотя переход на XBRL и означает смену старой отчетности на новую, методика формирования отчетных показателей сильно меняться на первом этапе не будет. Но придется навести порядок в подготовке всей информации и ее сверке.

Это уже сложно, ведь у банков отчетности в разы больше, чем у НФО, и они поддерживают много бизнес-направлений. Банкам перед отправкой регулятору нужно будет наладить процесс сбора данных, формирования показателей и их выверки для консолидации всей информации в единую структуру XBRL-документа.

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

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

Если при этом в IT-системе нельзя поддерживать сквозной бизнес-процесс, управлять соответствующим документооборотом, то при выпуске XBRL-отчетности сотрудники создают много отдельных Excel-таблиц, в которых проверяют данные и корректность расчета разных показателей, в том числе и на стороне учетных систем. Это трудозатратно и на этапе проверки показателей, и при работе с учетными системами.

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

— И как в этой ситуации ведет себя ЦБ?

— Думаю, Банк России ратует за то, чтобы все направления работы банков отражались в архитектуре XBRL, но это будет еще нескоро.

Банк России активно занимается развитием нового направления — датацентричного подхода к банковскому надзору. Сейчас под эгидой ЦБ создается рабочая группа «Датацентричный сбор информации в кредитных организациях: разработка единой модели данных».

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

— Сами банки готовятся к переходу на XBRL, раз он неотвратим?

— Пока не будет проекта нормативного акта или предварительной версии таксономии, предпринимать какие-то действия бессмысленно. Крупные банки уже знают, что такое XBRL-отчетность, благодаря дочерним организациям.

— Есть ли у вас опыт построения бизнес-процесса выпуска XBRL-отчетности с помощью автоматизации?

— Да. Это было сделано в рамках внедрения решения «ПрограмБанк.XBRL» в различных компаниях, в том числе в одной из крупнейших финансовых компаний России.

Все проверки происходят внутри решения «ПрограмБанк.XBRL». Все показатели, входящие в определенный набор отчетности (точку входа, в терминологии XBRL), находятся под контролем в рамках бизнес-процесса. Каждый показатель должен пройти определенные стадии — от приема информации до проверки и отметки о готовности.

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

— Но если у НФО порядка 10 тыс. показателей, то у банка их будет значительно больше. И даже если подготовкой отчетности будет заниматься 10 человек в режиме фулл-тайм, то все равно проверить вручную показатели невозможно. Что делать?

— Именно бизнес-процесс позволяет формировать отчетность из 10 тыс. показателей, в выпуске которой участвуют 10–20 человек (как раз не фулл-тайм). Но помимо этого необходимо по максимуму реализовать автоматизированные проверки показателей.

Таксономия уже содержит автоматизированные проверки — контрольные соотношения, внесенные Банком России. Они проверяют соответствие разных показателей между собой. К сожалению, контрольных соотношений ЦБ недостаточно.

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

— И компания «ПрограмБанк» реализовала эти дополнительные проверки показателей?

— В «ПрограмБанк.XBRL» мы реализовали много внутренних, дополнительных контрольных соотношений, не содержащихся в таксономии. Эти проверки сделаны на основе постановок задач от компаний и мнений экспертов рынка.

Банк сможет заранее убедиться, что контрольные соотношения, заданные регулятором, выполняются, и вовремя исправить ошибки. Это важно, ведь в случае ошибки в отчетности Банк России присылает предписание на изменение. У банка есть возможность получить только три предписания, потом идет отзыв лицензии. Поэтому необходимо реализовывать все возможные контрольные операции, чтобы минимизировать риск исправлений ошибок в рамках предписания. Кроме того, полезно использовать контроль, вытекающий из индивидуальных особенностей бизнеса организации.

В мае мы планируем провести вебинар, на котором продемонстрируем, как на практике выглядит выпуск XBRL-отчетности. Мы покажем, как работают контрольные соотношения — как Банка России, так и дополнительные. Эти проверки уже выдержали испытания практикой в крупных компаниях и, как нам кажется, будут интересны и опытным пользователям, и тем, кому только предстоит переход на XBRL.

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

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

— Как контрольные соотношения реализованы на техническом уровне?

— Для проведения описанных выше сверок в «ПрограмБанк.XBRL» в хранилище данных размещаются все показатели, формирующие XBRL-отчетность, первичные данные и пакеты прошлых периодов, уже сданные в ЦБ.

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

В результате пользователь увидит оба значения показателя для последующих точек входа: исходя из первой версии отчетности (которая была изначально предоставлена в Банк России) и из второй (уже после внесения правок). Результат должен содержать только скорректированные значения показателей, исправленных на основе замечаний ЦБ.

При этом таксономия включает в себя несколько видов описаний правил. Один из них описывает уровень элементов и связей, второй — это табличное представление показателей. В нашем решении мы даем возможность пользователям отобразить данные в табличном виде в соответствующей версии таксономии, а значения показателей хранятся согласно уровню элементов и связей. То есть в любую дату можно обратиться к действующей в ней таксономии и визуализировать табличный слой, действовавший в тот отрезок времени.

— Насколько сложен переход на новую версию таксономии в «ПрограмБанк.XBRL»?

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

— Как выглядит в результате бизнес-процесс, сочетающий в себе автоматизированные проверки и работу пользователей?

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

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

А после того, как все стадии проверок данный отчет прошел, сотрудник-верификатор передает его в состояние «готово к консолидации». Это значит, что отчет зафиксирован и никакие изменения в него вноситься уже не могут. Он ожидает готовности всех остальных отчетов, которые вносятся в тот же отчетный пакет, и уже после этого отчет выгружается вместе с проверенными данными.

— Один из источников ошибок — изменения в данных, произошедшие после расчета показателей. С этим можно что-нибудь сделать?

— Изменения в данных после того, как рассчитаны показатели, неизбежны. Это происходит и в НФО, и в банках. Вопрос — как отработать эту ситуацию?

Для этого у нас в «ПрограмБанк.XBRL» реализованы автоматические процедуры реконсиляции данных, то есть мониторинга их целостности. В рамках этих процедур мы можем сверить значения, которые подавались на загрузку в первичном варианте, с теми данными, которые в итоге планируется сдать в отчетность.

Это помогает избежать ошибок, связанных с изменениями данных, произошедшими после расчета показателей. Ведь в ходе работы с данными кто-то мог скорректировать значения показателей.

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

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

— На рынке сегодня присутствует немало инструментов для подготовки XBRL-отчетности. Как клиенту выбрать из них лучший?

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

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

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

ЦБ запустил механизм добровольной сертификация продуктов и решений данного класса. В рамках этой сертификационной процедуры регулятор изучает, как решение выполнено в целом, насколько корректно оно выполняет операции, необходимые при выгрузке и загрузке пакетов XBRL. И мы знаем, что некоторые решения не смогли пройти данную сертификацию по архитектурным причинам, поскольку за основу взят другой подход к технической реализации.

Например, в нашем решении все данные хранятся значениями показателей, согласно уровню связей таксономии, в структуре XBRL. Это то, чего хочет достичь регулятор в данной сфере.

— Смогут ли банки извлечь полезные аналитические сведения из той XBRL-отчетности, которую они будут готовить?

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

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

— Насколько далеко от нас то состояние XBRL-отчетности, когда можно будет говорить о полностью автоматической доставке изменений в таксономию регулятора из ЦБ в финансовое учреждение, об автоматическом формировании отчетного XBRL-пакета и автоматической отправке его в Банк России?

— Для этого должно быть хранилище всех показателей, которые считаются в банке с помощью ряда различных систем. Они должны сливаться в единое хранилище, из которого потом формируется XBRL-отчетность. Но сейчас достичь этого невозможно. Даже у НФО большой пул различных систем, работающих раздельно, скажем бэк-офис и системы, работающие с клиентами. И для разных систем создаются разные хранилища данных, причем зачастую на базе продуктов различных IT-вендоров. Информация для формирования того или иного отчетного показателя вначале извлекается из разных хранилищ, потом объединяется и затем обрабатывается для получения требуемого отчетного показателя.

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

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

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

— А не поможет переход от уникальных IT-проектов, которые каждый банк реализует собственными силами, к некоторым решениям на базе развитых эталонных методик?

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

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

Это будет первой задачей при переходе на XBRL-отчетность. Так что банкам в ожидании конкретных описаний от регулятора стоит заняться формированием единой структуры справочников. В этой части, конечно, тоже есть вопросы. Например, создавать ли справочники сразу по всему банковскому бизнесу или по отдельным направлениям?

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

— На что надо будет обратить внимание при переходе на XBRL помимо автоматизации процессов?

— До автоматизации необходимо создать регламенты, то есть формализовать то, с какими данными и как работать.

Также банкам необходимо выделить ресурсы на изучение формата XBRL и проектов новых нормативных актов. Существует так называемая Юрисдикция — «Центр ИксБиАрЭл», организующий взаимодействие участников рынка и регулятора посредством рабочих групп по определенным рынкам, обучение и массу другой полезной деятельности. Мы участвуем в этих рабочих группах, это полезно для всех сторон взаимодействия.

Призываем обратить внимание на рабочую группу «Датацентричный сбор информации в кредитных организациях: разработка единой модели данных». Чем больше представителей банков будет в этой группе, тем лучше все стороны будут готовы к грядущим изменениям. И еще раз приглашаем всех заинтересованных записываться на вебинар по XBRL-отчетности, который мы планируем провести в мае.

ProgramBank_XBRL-otchetnost-dlya-bankov.pdf

Источник публикации: Банковское обозрение, апрель 2021 автор Елена Покатаева

Поделиться:

Все статьи