Отчетность является для банков крайне важной задачей по следующим причинам:
Надежная инфраструктура отчетности позволяет банку отслеживать все виды рисков (рыночные, кредитные, риски ликвидности и проч.), вносить свои коррективы, а также гарантировать, что все лица, принимающие решения, имеют в своем распоряжении достаточно аналитических средств для принятия грамотных решений.
Отчетность охватывает ряд этапов управления рисками, а именно:
и т.п.
На сегодняшний день можно выделить два типа инфраструктуры формирования отчетов:
Какую из них выбрать?
В первую очередь, необходима такая структура, которая будет способна (с точки зрения масштабируемости и функциональности, а также доступа к различным платформам и форматам хранения) генерировать данные и обрабатывать их в соответствии с бизнес-правилами, обеспечивая аналитические результаты. Поэтому очевидно, что данные и отчеты должны принадлежать общей архитектуре, что позволит добиться беспрепятственного потока информации и точных результатов, а также удобного представления отчетов (с минимальным участием IT-персонала).
Таким образом, отчетность должна иметь общую архитектуру с компонентами управления и анализа данными. Такая архитектура хорошо функционирует в случае реализации общей структуры метаданных, безопасности и сервисов.
Клиентские приложения для отчетности могут быть самыми разнообразными в сегодняшней многоканальной рабочей среде (кто-то предпочитает Excel, кто-то — вебпорталы, кто-то - .NET и Java-приложения и т.д.). Архитектура должна быть достаточно гибкой, чтобы в ней могли функционировать различные сервисы запросов и отчетов, а также использовались общие метаданные и функции безопасности как для данных, так и для компонентов управления отчетностью.
Вычисления и модели генерируют результирующие данные, отчетность по которым базируется на предопределенных бизнес- и регулятивных измерениях и иерархиях.
Репозиторий данных должен быть организован таким образом, чтобы:
Отчеты являются конечным результатом всех вычислений, включая вычисления финансовых показателей, оценки рисков и капитала. Эти вычисления должны храниться в денормализованном репозитории, что позволит эффективно выполнять нерегламентируемые запросы и отчеты. В интегрированной среде все хранимые процессы должны быть доступны любому клиенту, а также должны разделять метаданные с механизмами вычисления рисков и выполнения отчетов.
Структура репозитория рисков должна обеспечивать хранение отчетных данных и информации о самом отчете, в том числе дату выхода, автора, регулятивную среду.
Например, банк может работать в нескольких юрисдикциях, поэтому ему необходима гибкость в конфигурировании расчетов и отчетного механизма для выполнения требований конкретной юрисдикции и т.п.
Поддержка исторической информации в репозитории очень важна, так как гарантирует простой доступ к результирующим данным, из которых можно сформировать нерегламентируемые отчеты по тенденциям или выполнить запросы регулирующих органов по аналитическим результатам за определенный период. Модель данных должна обеспечивать добавление и внесение изменений в таблицы и строки в денормализованном виде, оптимизированном для выполнения запросов и отчетов по множеству иерархий или переменных.
Очевидно, что именно Хранилище данных идеально отвечает всем описанным выше требованиям к банковскому репозиторию для отчетности.
Механизмы расчетов, анализа и отчетности («механизм» — это логическое представление модулей, которые в целом составляют полностью интегрированный аналитический расчет и платформу отчетности, без необходимости использования промежуточного ПО третьих фирм для упрощения обработки данных в цепочке управления рисками) должны быть достаточно гибкими для выполнения требований различных юрисдикций. А значит, язык отчетности также должен быть гибким. Для глобальных финансовых групп, возможности отчетности на всех используемых языках особенно важны, особенно для выполнения регулятивных требований.
Как на практике решается задача генерирования и предоставления отчетности для разных юрисдикций? Часто готовые отчетные шаблоны (например, такие, как отчеты COREP[1]) обеспечивают базу, на которой строятся дополнительные региональные или функционально-специфичные отчеты. Если информационная инфраструктура достаточно гибкая, то дешевле и быстрее всего формировать такие отчеты по мере необходимости.
Поводя итоги можно сказать, что основные элементы, обеспечивающие эффективную отчетную инфраструктуру следующие:
Отчетные результаты могут быть точными (исключая риск-факторы и ценовые модели, где ошибочные результаты можно считать допущениями модели) только тогда, когда исходные данные точны.
В банковских операциях и отчетности, в том числе при расчетах рисков, очень важна точность данных. Если, например, рассмотреть информацию о залоге, то очевидно, что без уверенности в качестве информации расчеты подверженности рискам с использованием обычного подхода к сокращению рисков могут дать некорректный результат. Преувеличить важность качества данных трудно.
В целом, отчеты по качеству данных должны обеспечивать информацию для IT-подразделения и внешних аудиторов по следующим аспектам:
Банк и регулирующие органы должны иметь возможность аудита, проверки качества и эффективности расчетов, а также управления рисками.
Управление рисками и качеством данных должно вестись на базе единой платформы, что упрощает обмен данными и отчетными результатами.
Результаты анализа рисков и создания отчетов хранятся в репозитории (Хранилище) и доступны различным потребителям, в том числе акционерам и партнерам, которые заинтересованы во внутренних результатах банка, либо внешним потребителям (надзорным органам и аудиторам)
Функции отчетности должны обеспечивать представление данных в формате и содержимом, которое требуется любому пользователю.
Поэтому, с технологической точки зрения, возможность управления различными требованиями очень желательна и эффективна. Централизованное средство хранения с отчетными инструментами, позволит беспрепятственно передавать отчеты потребителям.
Отчетные средства обеспечивают представление данных в удобном для пользователя формате.
Возможно представление отчетов в различных форматах и по разным каналам, через web-порталы, в виде статического или динамического контента, либо в виде скрипта, который осуществляет доступ к последним данным и выдает «живые» результаты (приближенные к реальному времени).
Сегодня корпоративное Хранилище данных является одним из наиболее удобных средств, позволяющих реализовать регулятивную отчетность в банках.
Отчеты, предоставляемые финансовыми учреждениями надзорным органам, требуют доступа к большим объемам исторических данных. Например, требования Базель II, обязывают хранить детальные данные за 7 лет, и, вероятно, в ближайшее время этот срок будет увеличен до 11 лет. Кроме того, большие объемы информации также необходимы для отчетности по тенденциям и в целях аудита.
Однако эффективность выполнения нормативных требований и получения отчетности зависит от хорошо продуманной архитектуры Хранилища.
Наиболее грамотный подход для нормативной отчетности - корпоративное внедрение Хранилища, обеспечивающие использование единых информационных ресурсов, как для выполнения требований, так и для аналитики.
Публикации:
[1] COREP — Common Reporting Framework, XBRL-таксономия, обеспечивающая представление общей ин общей инфраструктуры отчетности по коэффициенту платежеспособности (solvency ratio) для кредитных организаций и инвестиционных компаний в соответствии с новым режимом требований к капиталу (т.е. основывается на первом компоненте соглашения Базель II).