| 
|
|
|
|
В данной статье будет расширена и дополнена информация о хранилище данных OFSA FDM, приведенная в предыдущих статьях цикла. Следует еще раз напомнить, что, кроме банков, система может использоваться и в страховых компаниях, механизмы обработки общие, а некоторые основные различия, имеющиеся в объектах базы данных, будут упомянуты по ходу статьи.
ODBC-источники
Финансовые инструменты. Финансовые инструменты (или просто инструменты) занимают центральное место в системе, для них вполне подходит определении, данное в МСФО 39: Финансовый инструмент - это любой договор, посредством которого одновременно возникает финансовый актив у одной компании и финансовое обязательство или долевой инструмент у другой.
Круг финансовых инструментов простирается от традиционных первичных инструментов, таких как облигации, до различных форм производных финансовых инструментов.
Каждому финансовому инструменту в FDM соответствует отдельная таблица, используемая для хранения информации на уровне договора/лицевого счета (account-level information), например, в списке ниже приводятся некоторые предопределенные в системе инструментальные таблицы:
| Commercial_Loan | Коммерческие ссуды |
| Consumer_Loan | Потребительские кредиты |
| Credit_Cards | Кредитные карточки |
| Deposits | Депозиты |
| Forward_Contracts | Форвардные контракты |
| Interest_Rate_Options | Процентные опционы |
| Interest_Rate_Swaps | Процентные свопы |
| Investments | Инвестиции |
| Mortgages | Ипотека |
| Mortgage_Back_Sec | Ценные бумаги, обеспеченные ипотеками |
| Term_Deposits | Срочные депозиты |
| Wholesale_Funding | Оптовый банковский бизнес |
| Pl_Vehicle_Policies* | Страхование личного автотранспорта |
| Term_Life_Policies* | Полис срочного страхования жизни |
| Umbrella_Policies* | Полис по страхованию ответственности, всеобъемлющий (зонтик) |
Последние три финансовых инструмента (отмечены *) относятся к страхованию.
OFSA FDM позволяет не только создавать новые инструментальные таблицы, но и вводить дополнительные колонки для существующих таблиц - так что, дополнить преднастроенную схему базы данных OFSA, как до требований ЦБ, так и по индивидуальным требованиям банка, не представит затруднений.
Каждая строка инструментальной таблицы содержит детальные данные об отдельном счете/договоре на данный момент времени. Несколько снимков для одного счета/договора (т.е. записи инструментальной таблицы) идентифицируются разными значениями даты в колонке As-of-Date.
Структура конкретной инструментальной таблицы позволяет загружать в нее сделки самого разного вида. Вид сделки в рамках инструментальной таблицы определяется типом продукта, например, для инструмента Investments предусмотрено свыше 70 типов продукта.
Имеется возможность расширять список предопределенных типов продуктов.
В каждой инструментальной таблице можно выделить следующие группы колонок:
Примеры:
Общая информация для всех инструментов:
Специфическая информация для данного инструмента, например, для Кредитов:
Информация, используемая для вычисления кэш-флоу:
Содержательно значения для первых трех Leaf Columns определяются в процессе внедрения, в то время как финансовые элементы являются предопределенными, достаточно подробно данная тема освящена в статье OFSA. Основные принципы.
Часть 1. Информационные структуры и алгоритмы.
В демонстрационной базе данных OFSA можно найти примеры дополнительных Leaf Columns, определенных пользователем (и, соответственно, иерархических структур) как для банков, так и для страхования, в том числе:
Подобные столбцы Leaf могут пригодиться при анализе услуг/каналов в связи с бурным развитием онлайнового бизнеса и новых информационных технологий. Банк может определить, какие из его каналов поставки более выгодны, и перемещать своих клиентов соответственно.
Моделирование жизненного цикла клиента предполагает использование различных продуктов и услуг в определенные периоды его жизни. Например, клиенту в 17-20 лет может потребоваться студенческая ссуда, затем - автомобильная ссуда, ипотека на жилищное строительство и др. Справочники OFSA FDM содержит значительное число преднастроенных справочников, в документации на них часто ссылаются как на MLS (multi-language support) таблицы. Примеры использования кодов подобных таблиц можно найти в статье OFSA.
Основные принципы. Часть 1. Информационные структуры и алгоритмы:
| - Ofsa_Accrual_Basis_Mls | Базис, по которому происходит расчет наращиваемых процентов |
| - Ofsa_Interest_Timing_Type_Mls | Проценты: в начале или в конце периода |
| - Ofsa_Compound_Basis_Mls | Порядок исчисления сложных процентов |
| - Ofsa_Amortization_Type_Mls | Типы амортизации, основной суммы и процентов |
Для страхования имеется свой набор специфических преднастроенных справочников, например, Ofsa_Tobacco_Type_Mls:
| - Сигареты | - Жевательный табак |
| - Сигары | - Нюхательный табак |
| - Трубка | - Бездымный Табак и др. |
Как определить дополнительный справочник, см. в разделе Метаданные. Транзакции/проводки
Хранят информацию о величине транзакции по каналу, типу и продукту для каждого счета клиента (записи инструментальной таблицы). Обычно хранят величину транзакции по типу операции, например, выдача наличных денег банкоматом.
Transaction ID и Channel ID обычно определяются как пользовательские листья. Клиенты
См. ниже раздел Анализ клиентской базы, CRM Главная Книга
Уровень агрегации Ledger_Stat определяется набором определенных Leaf Columns плюс валюта, дата и еще тип данных: фактические, бюджетные и прогнозные.
Таблица базы данных Ledger_Stat содержит итоговые данные из таблиц уровня договора/лицевого счета.
Информация Главной Книги используется для разных целей (пример для трансфертного ценообразования приводится в четвертой статье цикла), в том числе, и для проверки оперативных данных, поступающих в таблицы финансовых инструментов, подробности см. в следующем разделе.
Таким образом, измерения (обязательные и новые) и, соответственно, заполненные финансовые инструменты (в том числе, с детальной информацией о платежах, ставках, переоценке, предоплате и др.), связанные с массивом клиентов, и позволяют выполнять детальный анализ и прогноз по продуктам, подразделениям и клиентам. 3. Согласование, преобразование и очистка данных.
Кроме возможностей OWB по преобразованию и очистке данных, система OFSA использует собственные программные средства, обеспечивающие очистку и согласование данных, поступающих из разных источников.
Согласование 1 представляет собой процесс сравнения информации из инструментальных таблиц и Главной Книги. Наиболее общий тип согласования предусматривает сравнение данных остатков инструмента с исходящими остатками Главной Книги на заданную дату.
Чтобы использовать объекты базы данных в приложениях 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 определяет значения плана счетов.
Увеличить
FDM Типы Данных - идентифицируют первичную цель колонки
Колонки С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 могут быть назначены:
| - Instrument | Супертип для всех Инструментальных таблиц |
| - Portfolio | Определяет набор столбцов, общих для всех инструментальных таблиц |
| - TP Non-Cash Flow | Идентифицирует Non-Cash Flow объекты для Transfer Pricing обработки |
| - Instrument Profitability | Идентифицирует объекты для обработки аллокаций (Allocation) |
| - Data Correction | Идентифицирует объекты для использования с приложением Balance and Control |
| - TP Option Costing | Идентифицирует объекты для обработки Transfer Pricing Option Costing. |
Например, любая таблица или представление с табличной классификацией TP Cash Flow или TP Non-Cash Flow появляется в списке таблиц Transfer Pricing Process ID. Табличная Классификация Portfolio определяет набор столбцов, общий для всех инструментальных таблиц.
Метаданные позволяют выделить следующие группы справочников:
| - Резервируемые FDM | База для начисления процентной ставки по счету - все коды - справочники являются предопределенными. |
| - Редактируемые пользователем | Метод амортизации основной суммы и процентов - коды в интервале 1-999 предопределенные, коды 1000 и выше задаются в Определяемом пользователем платежном образце модулей RM или TP. Пользователь определяет дополнительный метод амортизации основной суммы и процентов, см. далее рисунок. |
| - Определенные пользователем | Тип продукта для финансовых инструментов. |
Данные примеры справочников можно найти в первой статье.
Увеличить
Использование Определяемого пользователем платежного образца.
Необходимо создавать платежный образец для 4-х летнего кредита с нерегулярными плановыми платежами.
Платежи для первых 12 месяцев являются только процентными платежами, следующие 35 платежей составляют половину от текущего планового платежа, и последний платеж является balloon платежом для остатка кредита. Запись в справочнике появляется автоматически при создании нового платежного образца. При помощи возможностей Correction Rule ID создается бизнес - правило (проверка и корректировка) для продуктов данного вида.
См. раздел Согласование, преобразование и очистка данных.
Функциональность по разграничению доступа позволяет администрировать привилегии и на уровне приложений, и на уровне базы данных, включая витрину обработки и витрину отчетности. Приложение FDM Administration использует такие понятия, как группы пользователей и профили безопасности, которые минимизируют трудозатраты на администрирование. Для тех требований, которые не могут быть реализованы через стандартные (предопределенные) роли, группы и профили, FDM Administration позволяет создавать и регистрировать свои собственные роли, группы и профили.
5. Анализ клиентской базы, CRM.
Возможности модуля Performance Analyzer до сих пор не рассматривались. Основная (оригинальная) функциональность модуля сосредоточена в следующих ID:
Allocation ID позволяет выполнять разнесения (аллокации) самого разного типа (используя информацию как Главной Книги, так и финансовых инструментов), в том числе:
Например, можно выполнить разнесение непроцентных расходов в разрезе Org Unit/Common COA для ипотечных счетов, разнесение, пропорционально числу ипотечных счетов, для комбинации Org Unit/Common COA.
В данной статье речь идет исключительно о Party Profitability Process ID, т.е. о бизнес- правиле, которое предлагает законченное решение для определения степени коммерческой привлекательности клиента или, как прямо приводится в документации, ...дает организациям всех размеров необходимую информацию для выбора что делать, с кем, когда, и как, отвечая на следующие вопросы:
Фактически речь идет о формировании и развитии собственной интегрированной и надежной клиентской базы, как основы банковского бизнеса. Если посмотреть на входную и выходную информацию для данного ID, то становится ясно, что по сути мы имеем компактный банковский аналитический CRM.
Входная информация.
Таблица 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), помогающих аудиторам или квалифицированным специалистам банка формировать МСФО, поскольку различие между РПБУ и МСФО не позволяет осуществлять механическое выполнение метода трансформации, используя исключительно счета и обороты.
В первую очередь, следует отметить два общих положения, без которых формирование МСФО невозможно:
О возможностях моделирования в системе OFSA достаточно много говорится в первых четырех статьях цикла, следует подчеркнуть, что имитационное моделирование является одной из наиболее ярких и выигрышных сторон системы OFSA, пример моделирования cтратегии хеджирования будет приведен ниже в этом разделе.
Не секрет, что значительные сложности возникают при определении справедливой стоимости и вообще при применении МСФО 39 Финансовые инструменты: признание и оценка. Хотя отчеты IAS (МСФО) среди стандартных отчетов OFSA не упоминаются, отчеты FASB, в том числе, FASB 133 Accounting for Derivative Instruments and Hedging Activities, который по сути является американским аналогом МСФО 39, там имеются.
Пример, приведенный в первой статье цикла, показывает балансовый отчет объектов хеджирования (ипотеки) вместе с соответствующими инструментами хеджирования (форвардные контракты), следующий рисунок демонстрирует хеджирование ипотек процентными опционами и связь с МСФО 39.
Рассматривается чисто гипотетический эпизод банковской технологии. После заключения ряда ипотечных договоров для уменьшения существующих рыночных процентных и валютных рисков возникает необходимость определить параметры соответствующего инструмента хеджирования.
После этого можно выбрать эффективный 2 для хеджирования финансовый инструмент и, собственно, заключить сделку хеджирования, краткое описание упомянутых выше ID можно найти в предыдущих статьях цикла. Следует отметить, что возможности Transaction Strategy ID позволяют определять для моделирования не только инструмент хеджирования, но и хеджируемые объекты.
Отражаемая в отчетности справедливая стоимость финансового инструмента зависит от типа инструмента, метода оценки и дат (заключения сделки, проведения расчетов). В основе методов оценки должны лежать исходные данные о ставках за досрочное погашение, норме оценочных убытков по выданным кредитам, а также исходные данные о процентной ставке и коэффициенте дисконтирования.
В качестве справедливой стоимости выступают различные виды или комбинации таких показателей как: остаток на дату происхождения, рыночная стоимость на дату происхождения, текущий балансовый остаток, текущая (вычисленная) рыночная стоимость и др. Справедливая стоимость часто определяется на основе рыночной стоимости, в других случаях, например, для счетов ностро, равна их балансовой стоимости, и т.п.
Все вышеперечисленные атрибуты являются колонками записей финансовых инструментов, причем текущая рыночная стоимость вычисляется в модуле Risk Manager, в том числе, на уровне записей инструментальных таблиц, примеры вычисления рыночной стоимости приводятся в статье Процентные ставки. 7. Управленческий учет.
Подготовка информации для внутреннего пользования, рассчитанная на менеджеров различного уровня, является основной целью управленческого учета.
Специалисты по-разному определяют список задач управленческого учета, поэтому приведенный ниже перечень, конечно, не является ни сокращенным, ни избыточным, а приводится исключительно в иллюстративных целях, для сопоставления с функциональностью OFSA:
Задача Модуль
| - трансфертное ценообразование | Transfer Pricing |
| - разнесение затрат | Performance Analyzer |
| - управление активами и пассивами | Risk Manager, Performance Analyzer |
| - управление рисками, в т.ч. EaR, VaR | Risk Manager |
| - прогнозный баланс, прогнозный отчет о прибылях и убытках | Risk Manager |
| - консолидированная и аналитическая отчетность | FDM, Discoverer |
| - планирование и бюджетирование | Budgeting Planning |
Примеры использования таких обязательных в управленческом учете информационных структур, как центры финансовой ответственности и иерархии, приводились неоднократно ранее. Следует также упомянуть Главную Книгу (таблица Ledger_Stat), которая содержит фактические, бюджетные и прогнозные данные, что позволяет легко проводить сравнительный анализ на одном наборе измерений и реально отражать ситуацию, как в банке целиком, так и по филиальной сети (см. набор финансовых элементов в первой статье).
Исходя из имеющихся в хранилище данных размерностей и таким функциональностям, как трансфертное ценообразование, разнесение затрат и др., можно надежно определить источники формирования прибыли банка по: