"Никогда такого не было, чтобы все было"

Н.Глазков

Оглавление.

• 1. Вступление
• 2. Основные информационные структуры
• 3. Согласование, преобразование и очистка данных
• 4. Метаданные
• 5. Анализ клиентской базы, CRM
• 6. МСФО
• 7. Управленческий учет.
• 8. Заключение.

1. Вступление

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

OFSA FDM поддерживает традиционную технологию хранилищ данных ETL (extraction, transformation, loading). Данные, поступающие в хранилище данных FDM из OLTP систем, должны быть не только "извлечены, трансформированы и загружены", но и согласованы, выверены, приведены к общему формату:

• в многофилиальном банке может работать несколько АБС, да и в филиале среднего или крупного банка это не исключение, а, скорее, правило.
• филиалы международного банка хранят данные Главной Книги не только в национальных валютах, но и по разным планам счетов. Для проведения общего анализа по всей филиальной сети необходимо привести данные к общей валюте, согласовать планы счетов, кросс-курсы, картотеку клиентов и др.

Oracle Discoverer является системой поддержки принятия решений (DSS), позволяющей выполнять непредусмотренные запросы к базе данных, строить отчеты по результатам этих запросов, анализировать и форматировать отобранные данные. Используя данный продукт аналитики, менеджеры и другие работники информационной сферы могут легко работать с БД, не имея углубленных знаний по архитектуре Oracle и языку SQL

OWB (Oracle Warehouse Builder) является основным инструментом, используемым при формировании хранилища данных FDM, обеспечивающим технологию ETL. Oracle Warehouse Builder существенно облегчает создание, развертывание и поддержку хранилища данных, позволяя визуально моделировать схему хранилища, либо импортировать метаданные из репозитория Oracle Designer. Разработчик визуально определяет отображения между источниками данных и хранилищем, и затем OWB автоматически генерирует на их основе модули загрузки в виде процедур PL/SQL или скриптов SQL*Loader. OWB имеет встроенную библиотеку функций преобразования данных, которую при необходимости можно расширять собственными процедурами на PL/SQL. Встроенные в OWB дополнительные компоненты предоставляют мощные средства автоматической очистки данных, включающие алгоритмы нечеткой логики, синтаксический разбор имен и адресов, вероятностные модели и т.д.

В качестве источников могут выступать:

• РСУБД Oracle
• Файлы разных форматов (txt, html, dbf, xls, xml и др.)
• ERP-система SAP R/3
• DB2, Informix, MS SQL, Sybase
• ODBC-источники
• Мэйнфреймы.

Здесь нельзя не упомянуть некоторые материалы по теме "МСФО и хранилища данных", "банковские хранилища данных", в которых утверждается, что хранилища данных российского "производства" предпочтительнее из-за "… возможности изменять архивные данные "задним" числом"! Несмотря на недопустимость в принципе таких действий, следует заметить, что возможности Warehouse Builder позволяют выполнить и такое, выходящее за рамки общепризнанных правил деловой этики, требование.

Кроме того, в состав OFSA входит отдельный модуль "Balance & Control", обеспечивающий проверку и согласование данных, поступающих из разных источников, подробнее об этом модуле будет сказано ниже.

2. Основные информационные структуры

OFSA FDM манипулирует данными банковских информационных структур в самом широком спектре:

• Главная книга
• Клиенты (данные о клиентах, домашних хозяйствах, взаимотношение со счетами клиентов и др.)
• Счета клиентов, финансовые инструменты (сделки, контракты и др.)
• Транзакции/проводки
• Иерархические структуры (планы счетов, филиальная сеть, группировки клиентов и др.)
• Справочники
• Информация о моделях (бизнес - правила или ID).

Финансовые инструменты.

Финансовые инструменты (или просто "инструменты") занимают центральное место в системе, для них вполне подходит определении, данное в МСФО 39:

Финансовый инструмент - это любой договор, посредством которого одновременно возникает финансовый актив у одной компании и финансовое обязательство или долевой инструмент у другой.

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

Каждому финансовому инструменту в FDM соответствует отдельная таблица, используемая для хранения информации на уровне договора/лицевого счета (account-level information), например, в списке ниже приводятся некоторые предопределенные в системе инструментальные таблицы:

Последние три финансовых инструмента (отмечены *) относятся к страхованию.

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

Каждая строка инструментальной таблицы содержит детальные данные об отдельном счете/договоре на данный момент времени. Несколько "снимков" для одного счета/договора (т.е. записи инструментальной таблицы) идентифицируются разными значениями даты в колонке As-of-Date.

Структура конкретной инструментальной таблицы позволяет загружать в нее сделки самого разного вида. Вид сделки в рамках инструментальной таблицы определяется "типом продукта", например, для инструмента Investments предусмотрено свыше 70 "типов продукта". Имеется возможность расширять список предопределенных "типов продуктов".

В каждой инструментальной таблице можно выделить следующие группы колонок:

• общие для всех инструментов
• специфические для данного инструмента
• используемые для вычисления кэш-флоу

Примеры:

Общая информация для всех инструментов:

• Код источника данных
• Уникальный идентификатор записи
• Код клиента
• Код филиала

Специфическая информация для данного инструмента, например, для Кредитов:

• Код просроченной задолженности
• Статус кредита
• Код обеспечения

Информация, используемая для вычисления кэш-флоу:

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

Иерархические структуры

Иерархические структуры формируются на основе специальных колонок, определяемых в системе, таких как Leaf Columns (как конкретно это делается, см. ниже в разделе "Метаданные"), фактически, они обеспечивают измерения (и, соответственно, классификацию) данных в FDM.

Столбцы Leaf обеспечивают информацию о том, как счета/сделки могут быть классифицированы при помощи различных планов счетов или организационными структурами. Значения Leaf - самый низкий уровень при формировании иерархических структур, собственно, иерархические структуры формируются в OFSA Tree Rollup ID, пример фрагмента иерархической структуры можно найти в первой статье цикла.

Следующие Leaf Columns являются стандартными, они обеспечиваются начальной структурой базы данных FDM:

• Common COA (Common Chart of Account)
• GL Account (General Ledger Chart of Accounts)
• Org Unit (Organizational Unit)
• Financial Element.

Содержательно значения для первых трех Leaf Columns определяются в процессе внедрения, в то время как финансовые элементы являются предопределенными, достаточно подробно данная тема освящена в статье "OFSA. Основные принципы. Часть 1. Информационные структуры и алгоритмы".

В демонстрационной базе данных OFSA можно найти примеры дополнительных Leaf Columns, определенных пользователем (и, соответственно, иерархических структур) как для банков, так и для страхования, в том числе:

• Leaf Channel (ATM, PC Banking, Point-of-Sale, at a branch и др.)
• Leaf Transaction Type (Open Account, Payment, Inquiry и др.)
• Leaf Customer Segment (можно предложить такие категории для сегментации: возраст, местоположение, годовой доход, занятие и т.д.).

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

Моделирование жизненного цикла клиента предполагает использование различных продуктов и услуг в определенные периоды его жизни. Например, клиенту в 17-20 лет может потребоваться студенческая ссуда, затем - автомобильная ссуда, ипотека на жилищное строительство и др.

Справочники

OFSA FDM содержит значительное число преднастроенных справочников, в документации на них часто ссылаются как на MLS (multi-language support) таблицы. Примеры использования кодов подобных таблиц можно найти в статье "OFSA. Основные принципы. Часть 1. Информационные структуры и алгоритмы":

Для страхования имеется свой набор специфических преднастроенных справочников, например, Ofsa_Tobacco_Type_Mls:

Как определить дополнительный справочник, см. в разделе "Метаданные".

Транзакции/проводки

Хранят информацию о величине транзакции по каналу, типу и продукту для каждого счета клиента (записи инструментальной таблицы). Обычно хранят величину транзакции по типу операции, например, выдача наличных денег банкоматом. Transaction ID и Channel ID обычно определяются как пользовательские листья.

Клиенты

См. ниже раздел "Анализ клиентской базы, CRM"

Главная Книга

Уровень агрегации Ledger_Stat определяется набором определенных Leaf Columns плюс валюта, дата и еще тип данных: фактические, бюджетные и прогнозные.

Таблица базы данных Ledger_Stat содержит итоговые данные из таблиц уровня договора/лицевого счета.

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

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

3. Согласование, преобразование и очистка данных.

Кроме возможностей OWB по преобразованию и очистке данных, система OFSA использует собственные программные средства, обеспечивающие очистку и согласование данных, поступающих из разных источников.

Согласование ¹ представляет собой процесс сравнения информации из инструментальных таблиц и Главной Книги. Наиболее общий тип согласования предусматривает сравнение данных остатков инструмента с исходящими остатками Главной Книги на заданную дату.

Как только различия между информацией инструментальной таблицы и информацией Ledger Stat известны, они должны быть исправлены для того, чтобы утвердить данные (удостоверить правильность данных). Выше уже упоминалось, что таблица Ledger_Stat, кроме прогнозных и бюджетных данных, может хранить и фактические (т.е. загруженные) данные. Таким образом, данные по исходящим остаткам Главной Книги выступают своего рода контрольной суммой по отношению к данным инструментальных таблиц, что исключает несоответствие информации по сделкам фактическим показателям бухгалтерского учета.

Приложение OFSA "Balance & Control" обеспечивает механизмы проверки, согласования и балансирования данных Главной Книги инструментальным данным, имеются также средства для агрегации детальных данных. Данная функциональность обеспечивается созданием и выполнением специальных правил корректировки в базе данных FDM.

Эти правила (проверки и корректировки) формируются в специальном ID - "Correction Rule ID". Кроме того, в системе имеется одно предопределенное правило корректировки с именем "CASHFLOW_EDITS". Это правило фактически содержит ряд контрольных редактирований, которые могут применяться к кэш-флоу столбцам любой Инструментальной Таблицы. Цель кэш-флоу редактирования состоит в том, чтобы исключить противоречивые и/или неполные данные при обработке прерываний кэш-флоу в любом модуле OFSA, который использует кэш-флоу моделирование, включая Risk Manager и Transfer Pricing.

Фактически, речь идет о проверке условий и ограничений, наложенных на кэш-флоу колонки в документе "Technical Reference Manual". Кэш-флоу редактирование должно быть выполнено после завершения всех собственных (кастомизированных) редактирований данных. Используя опцию "Update Log Only", можно получить протокол проверок без реального редактирования.

4. Метаданные.

Чтобы использовать объекты базы данных в приложениях OFSA, их следует должным образом идентифицировать в рамках метаданных FDM. Приложение OFSA "FDM Administration" обеспечивает механизмы сопровождения структур хранилища FDM и управления разграничением доступа. Конечно в рамках статьи сколько-нибудь полно дать представление о метаданных в OFSA невозможно, поэтому будут приведены только элементы метаданных для примеров объектов базы данных приведенных в статье.

Идентификация объектов

Объекты (таблицы и представления) с префиксом "OFSA_" классифицируются как FDM Reserved, такие объекты поддерживают внутренние операции приложений OFSA. С немногими исключениями, эти объекты не могут быть произвольно настроены или изменены.

Объекты, не имеющие такого префикса, классифицируются как Client Data Objects, они полностью настраиваемы, можно также создавать собственные объекты клиентских данных (например, финансовые инструменты) для использования в FDM.

FDM Data Type - идентифицируют первичную цель колонки в рамках базы данных FDM. Например, тип данных LEAF используется для определения Leaf Columns, которые позволяют формировать иерархии и используются как измерения, например, колонка COMMON_COA_ID определяет значения плана счетов.

Колонки СOMPOUND_BASIS_CD, CUR_BOOK_BAL и CUR_NET_RATE в инструментальной таблице DEPOSITS2 определяются как Oracle RDBMS тип данных Number, но использование этих колонок в рамках FDM полностью различно. Это использование идентифицируется Типом Данных FDM. Колонка COMPOUND_BASIS_CD определяется как FDM Тип Данных CODE. Это означает, что приложения OFSA обеспечиваются списком значений, в данном случае списком значений "базиса начисления сложных процентов", для ситуаций, требующих пользовательского ввода. В то же время, колонка CUR_BOOK_BAL определяется как FDM Тип Данных BALANCE и хранит значения в денежном выражении, а колонка CUR_NET_RATE определяется как FDM Тип Данных RATE и хранит процентную ставку. Такие колонки используются в вычислениях приложений OFSA.

Table Classifications (табличные классификации) - определяют, как таблицы и представления используются в приложениях OFSA. Каждая табличная классификация идентифицирует определенную цель, для которой таблица или представление используются. Одной таблице можно присвоить несколько Табличных Классификаций. Например, для таблицы DEPOSITS могут быть назначены:

Например, любая таблица или представление с табличной классификацией "TP Cash Flow" или "TP Non-Cash Flow" появляется в списке таблиц Transfer Pricing Process ID. Табличная Классификация "Portfolio" определяет набор столбцов, общий для всех инструментальных таблиц.

Метаданные позволяют выделить следующие группы справочников:

Данные примеры справочников можно найти в первой статье.

Необходимо создавать платежный образец для 4-х летнего кредита с нерегулярными плановыми платежами.

Платежи для первых 12 месяцев являются только процентными платежами, следующие 35 платежей составляют половину от текущего планового платежа, и последний платеж является balloon платежом для остатка кредита. Запись в справочнике появляется автоматически при создании нового платежного образца. При помощи возможностей "Correction Rule ID" создается бизнес - правило (проверка и корректировка) для продуктов данного вида. См. раздел "Согласование, преобразование и очистка данных".

Функциональность по разграничению доступа позволяет администрировать привилегии и на уровне приложений, и на уровне базы данных, включая витрину обработки и витрину отчетности. Приложение "FDM Administration" использует такие понятия, как группы пользователей и профили безопасности, которые минимизируют трудозатраты на администрирование. Для тех требований, которые не могут быть реализованы через стандартные (предопределенные) роли, группы и профили, "FDM Administration" позволяет создавать и регистрировать свои собственные роли, группы и профили.

5. Анализ клиентской базы, CRM.

Возможности модуля "Performance Analyzer" до сих пор не рассматривались. Основная (оригинальная) функциональность модуля сосредоточена в следующих ID:

• Allocation ID
• Party Profitability Process ID.

Allocation ID позволяет выполнять разнесения (аллокации) самого разного типа (используя информацию как Главной Книги, так и финансовых инструментов), в том числе:

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

Например, можно выполнить разнесение непроцентных расходов в разрезе Org Unit/Common COA для ипотечных счетов, разнесение, пропорционально числу ипотечных счетов, для комбинации Org Unit/Common COA.

В данной статье речь идет исключительно о Party Profitability Process ID, т.е. о бизнес- правиле, которое предлагает законченное решение для определения степени коммерческой привлекательности клиента или, как прямо приводится в документации, "...дает организациям всех размеров необходимую информацию для выбора что делать, с кем, когда, и как, отвечая на следующие вопросы:

• Насколько выгодны ваши клиенты?
• Сколько иждивенцев приходится на наиболее выгодных клиентов?
• Какие клиенты являются нерентабельными?
• Почему они нерентабельны?
• Какую часть ваших ресурсов эти клиенты потребляют?"

Фактически речь идет о формировании и развитии собственной интегрированной и надежной клиентской базы, как основы банковского бизнеса. Если посмотреть на входную и выходную информацию для данного ID, то становится ясно, что по сути мы имеем компактный банковский "аналитический CRM".

Входная информация.

• Fem_Parties - Субъекты (Клиенты и Домашние хозяйства)
• Финансовые инструменты/Лицевые счета
• Fem_Party_Acct_Rel - Взаимоотношения субъектов и финансовых инструментов.

Таблица Fem_Parties поддерживает все демографические данные клиентов и домашних хозяйств (households). Строки таблицы представляют уникальных клиентов и домашние хозяйства, которые могут быть определены при помощи Oracle Warehouse Builder.

Поддерживает следующие типы субъектов:

• Бизнес - клиент (юридическое лицо)
• Бывший бизнес- клиент
• Индивидуальный клиент (физическое лицо)
• Бывший индивидуальный клиент
• Домашнее хозяйство
• Предполагаемый бизнес - клиент
• Предполагаемый индивидуальный клиент
• Другие

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

Данные о взаимоотношении между клиентами и клиентскими счетами (записями инструментальных таблиц) хранятся в таблице Fem_Party_Acct_Rel и выражают отношение многие-ко-многим. Совместные счета (joint account) принадлежат более чем одному клиенту. Эти данные определяют отношение клиента к счету - первичное или вторичное: каждый счет имеет только одного первичного клиента, все другие клиенты (в клиентских отношениях) рассматриваются как вторичные клиенты. Понятно, что наличие механизма трансфертного ценообразования банка на уровне счета при определении выгодности клиента может принести существенную пользу (см. статью о трансфертном ценообразовании).

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

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

Выходная информация.

В процессе выполнения Party Profitability Process ID формируется несколько выходных таблиц, в которых можно выделить следующие показатели:

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

6. МСФО

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

Собственно, ничего удивительного в этом нет, при подготовке отчетности по нескольким стандартам известны следующие методы: трансформация отчетности, трансляция проводок и метод ведения параллельного учета, но, поскольку приближается время ввода в действие нового Положения 302-П (1 января 2008), вкладывать значительные средства в два последних метода вряд ли целесообразно, поэтому метод трансформации отчетности и стал практическим выбором банков, а использование данного метода, конечно, не позволяет формировать банковскую отчетность в автоматическом режиме, как это происходит при формировании обязательной отчетности РПБУ (согласно российским положениям о бухгалтерском учете).

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

В первую очередь, следует отметить два общих положения, без которых формирование МСФО невозможно:

• использование технологии хранилищ данных; основные положения о FDM (Financial Data Manager, хранилище данных OFSA) приведены в статьях цикла;
• моделирование финансовых инструментов; на сайте ЦБ можно найти документ, выдержка из которого достаточно ясно характеризует проблемы, возникающие при решении задач формирования МСФО, и способы их решения:
  "… 5. Для определения справедливой стоимости отдельных инструментов потребуется на основании статистических и экономических данных "смоделировать" определенные рынки инструментов ..."

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

Не секрет, что значительные сложности возникают при определении справедливой стоимости и вообще при применении МСФО 39 "Финансовые инструменты: признание и оценка". Хотя отчеты IAS (МСФО) среди стандартных отчетов OFSA не упоминаются, отчеты FASB, в том числе, FASB 133 "Accounting for Derivative Instruments and Hedging Activities", который по сути является американским аналогом МСФО 39, там имеются. Пример, приведенный в первой статье цикла, показывает балансовый отчет объектов хеджирования (ипотеки) вместе с соответствующими инструментами хеджирования (форвардные контракты), следующий рисунок демонстрирует хеджирование ипотек процентными опционами и связь с МСФО 39.

Пример моделирования cтратегии хеджирования.

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

1. Основные параметры инструмента хеджирования (форвардный контракт, процентный опцион, процентный своп или др.) определяются в Transaction Strategy ID.
2. При помощи Data Filter ID определяется фильтр для выбора сделок по заключенным ипотекам (хеджируемые объекты).
3. Определяются дополнительные предположения, например в Prepayment ID для моделирования предоплаты.
4. Когда все предположения сделаны, Process ID выполняет вычисления и генерирует общий кэш-флоу для ипотечных сделок и инструмента хеджирования. Изменяя некоторые характеристики (кривая доходности, обменный курс, предоплаты и др.), можно повторить вычисления для определения оптимальных параметров инструмента хеджирования.

После этого можно выбрать эффективный ² для хеджирования финансовый инструмент и, собственно, заключить сделку хеджирования, краткое описание упомянутых выше ID можно найти в предыдущих статьях цикла. Следует отметить, что возможности Transaction Strategy ID позволяют определять для моделирования не только инструмент хеджирования, но и хеджируемые объекты.

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

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

Все вышеперечисленные атрибуты являются колонками записей финансовых инструментов, причем текущая рыночная стоимость вычисляется в модуле Risk Manager, в том числе, на уровне записей инструментальных таблиц, примеры вычисления рыночной стоимости приводятся в статье "Процентные ставки".

7. Управленческий учет.

Подготовка информации для внутреннего пользования, рассчитанная на менеджеров различного уровня, является основной целью управленческого учета.

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

Примеры использования таких обязательных в управленческом учете информационных структур, как центры финансовой ответственности и иерархии, приводились неоднократно ранее. Следует также упомянуть Главную Книгу (таблица Ledger_Stat), которая содержит фактические, бюджетные и прогнозные данные, что позволяет легко проводить сравнительный анализ на одном наборе измерений и реально отражать ситуацию, как в банке целиком, так и по филиальной сети (см. набор финансовых элементов в первой статье).

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

• продуктам
• организационной структуре, в том числе, центрам финансовой ответственности
• клиентам, домашним хозяйствам, категориям клиентов
• каналам/услугам.

Это возможно именно благодаря модулю Transfer Pricing, который позволяет учитывать не только прямые доходы и расходы, но и стоимость привлечения/размещения финансовых ресурсов, а модуль Performance Analyzer - объективно оценивать результаты деятельности всех центров ответственности и принимать правильные управленческие решения.

8. Заключение.

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

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

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

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

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

И в завершение скажем несколько слов о возможных рисках при внедрении системы OFSA. Среди их обширного списка обязательно следует отметить такие факторы как последовательность ввода стандартных модулей и последовательность развития дополнительной функциональности OFSA: