Часть 1. Информационные структуры и алгоритмы
"Усложнять просто, упрощать сложно"
Законы Мэрфи.
Что такое OFSA, определение.
В настоящее время найти информацию об OFSA в отечественных СМИ (включая конечно и электроные) несложно, но практически вся эта информация носит формальный характер. Сначала идет формально-рекламное определение, потом список функциональных модулей и далее в телеграфном стиле обзор модулей. Отсутствие информации о принципах работы системы часто приводит к ситуации, когда читатель позиционирует OFSA как просто аналитическую систему, в ряду нескольких имеющихся на рынке, а это точка зрения далека от истины.
В настоящей статье деляется попытка выделить отличительные особенности OFSA и дать самое первое приближение (насколько позволяюют рамки статьи) основных принципов работы системы. С этой позиции неформальное определение может выглядеть следующим образом:
OFSA является банковской аналитической системой имитационного моделирования, построенной на основе дисконтированного кэш-флоу; система предназначена для поддержки принятия управленческих решений, оценки финансового состояния банка и прогнозирования.
В этом определении три ключевых элемента:
"банковская система" - OFSA манипулирует данными банковских информационных структур в самом широком спектре - от транзакций до Главной Книги. Кроме банков система может использоваться и в страховых компаниях. "имитационное моделирование" - моделирование поведения системы в различных аспектах и в разных внешних и внутренних условиях с анализом динамических характеристик бизнес-процессов и с анализом распределения ресурсов. В Большом Энциклопедическом словаре "имитация" от латинского imitatio - подражание (кому-либо или чему-либо), воспроизведение. "на основе дисконтированного кэш-флоу" - для оценки текущей рыночной стоимости финансовых инструментов используется принцип суммирования приведенных на сегодняшний день будущих платежей, что дает возможность сравнивать суммы, относящиеся к разным моментам времени с позиции их текущей стоимости.
Подобный подход учитывает:
исходное состояние банковской информации на уровне договоров (контрактов) и порожденные этими договорами транзакции в будущих периодах моделирование "нового бизнеса" в будущих периодах сценарии поведения клиентов в будущих периодах (например, предоплата) сценария развития рынка в будущих периодах (например, кривая доходности) внеэкономические факторы (например, сезонность)
что дает в распоряжение банковского специалиста полную информацию обо всех кэш флоу имевших место на момент анализа, конечно и в том случае, когда момент анализа приходится на будущий период.
Кроме данной статьи предлагаются еще три, более углубленно рассказывающих о некоторых аспектах функционирования системы:
Финансовые Инструменты.
Центральное место в системе занимают т.н. "Финансовые Инструменты" (или просто Инструменты), под которыми понимаются юридически обеспеченные соглашения (договора) находящихся в обращении типов финансовых активов. Каждому Финансовому Инструменту в FDM соответствует отдельная таблица, используемая для хранения информации на уровне договора/лицевого счета (account-level information), например в следующем списке приводятся некоторые предопределенные в системе инструментальные таблицы:
| Commercial_Loan | Коммерческие ссуды |
| Consumer_Loan | Потребительские кредиты |
| Credit_Cards | Кредитные карточки |
| Deposits | Депозиты |
| Forward_Contracts | Форвардные контракты |
| Interst_Rate_Options | Процентные опционы |
| Interest_Rate_Swaps | Процентные свопы |
| Investments | Инвестиции |
| Mortgages | Ипотека |
| Mortgage_Back_Sec | Ценные бумаги, обеспеченные ипотеками |
| Term_Deposits | Срочные депозиты |
| Wholesale_Funding | Оптовый банковский бизнес |
Кроме того, в системе имеется механизм создания новых Инструментальных таблиц, которые будут использоваться наравне с предопределенными финансовыми инструментами.
Каждая строка инструментальной таблицы содержит детальные данные об отдельном счете/договоре на данный момент времени. Несколько "снимков" для одного счета/договора (т.е. записи инструментальной таблицы) идентифицируется разными значениями в колонке As-of-Date.
Структура конкретной инструментальной таблицы позволяет загружать в нее сделки самого разного вида. Вид сделки определяется "типом продукта", например, для инструмента Investments предусмотрено свыше 70 "типов продукта", в том числе:
| Депозитный сертификат | Корпоративная облигация |
| Евродолларовые депозиты | Простая акция |
| Векселя - банков | Привилегированная акция |
| Векселя - корпораций | Варранты |
| Банковский акцепт | Опционы |
Имеется возможность расширять список предопределенных "типов продуктов".
В каждой инструментальной таблице можно выделить следующие группы колонок:
общие для всех инструментов специфические для данного инструмента используемые для вычисления кэш-флоу
Примеры:
Общая информация для всех инструментов:
Код источника данных Уникальный идентификатор записи Код клиента Код филиала
Специфическая информация для данного инструмента, например для Кредитов:
Код просроченной задолженности Статус кредита Код обеспечения
Информация, используемая для вычисления кэш-флоу:
База для начисления процентной ставки Код процентной ставки Код плана счетов Метод и тип амортизации (основная сумма и/или процент) Платежная информация (даты, частоты, значения)
в том числе срок погашения, дата открытия
Информация об остатках (текущий остаток, первоначальный остаток) Информация о ставках (брутто, нетто, трансфертная) Валюта (валюта, в которой договор номинирован) Информация необходимая для моделирования кэпов/флоров, льготного периода
Кэш-флоу процессор (cash flow engine) OFSA использует эти данные (конечно, это далеко не все) для анализа инструментальной записи и генерации значений кэш-флоу (платежи, поступления, проценты и др.), имеется более 50 кэш-флоу колонок, что позволяет дополнительно определять неограниченное число уникальных финансовых инструментов.
OFSA генерирует кэш-флоу как серию событий. В любой день, и с любой частотой, в зависимости от характеристик инструмента, любое из следующих событий может произойти:
Payment (платеж) Payment change (изменение платежа, например, для ипотеки с регулируемой ставкой) Reprice (переоценка) Prepayment (предоплата)
Финансовые элементы.
Финансовый элемент является показателем, которому соответствует определенное экономическое или логическое содержание, значение которого вычисляется и сохраняется в таблицах FDM, в том числе в следующих таблицах:
LEDGER_STAT - Главная Книга, содержит фактические, бюджетные и прогнозные данные. RES_DTL/CONS_DTL - Детальные результаты процессов на основе сценария модуля RM.
Примеры финансовых элементов:
| Начальная брутто-ставка | Процентный кэш-флоу |
| Начальная нетто-ставка | Кредитные проценты |
| Начальная трансфертная ставка | Ставка дисконтирования |
| Исходящий остаток | Рыночная стоимость |
| Средний остаток | Дюрация |
| Остаток после переоценки | Дивиденды |
| Накопленный эффект нереализованной валютной прибыли/убытка в конце периода | Эффект колебания обменного курса на существующем остатке в течение периода |
Значения показателей (финансовых элементов) Главной Книги в общем случае вычисляются в разрезе:
| Org_Unit | Имеются возможности выполнить вычисления с дополнительной детализацией: определить еще одну иерархическую структуру, например "Группировка клиентов" или определить фильтр данных. |
Это позволит получить результат в разрезе групп клиентов или даже для одного клиента.
В системе имеется не менее 180 предопределенных финансовых элементов и существует механизм формирования дополнительных финансовых элементов.
ID-объекты. Информация для моделей.
Как ранее говорилось, разнообразные "ID" определяют параметры обработки, спецификации прогнозирования, сценарии моделирования и предположений, алгоритмы обработки и формирования данных. Результатом работы "ID" является именованный набор информации, имеющий уникальный системный номер. Значения этих именованных ID-объектов можно корректировать, удалять, создавать на их основе новые. Некоторые ID могут ссылаться на другие ID, когда все предположения для прогноза определены, используется Process ID, который ответственен за выполнение вычислений, обработку и генерацию результатов, вычисления могут выполняться и на клиентской машине и на сервере.
Используя модули RM/TP можно получить выходные результаты индикаторов риска, в том числе и значения финансовых элементов, после чего проверить и проанализировать воздействие
прогнозных ставок; нового и текущего бизнеса; предположений поведения клиента на конкретные банковские портфели и в целом на баланс банка и отчет о прибылях и убытках.
Процесс моделирования
Предположения поведения клиентов можно задавать такими компонентами системы, как сезонные платежи и досрочные платежи.
Если финансовый инструмент позволяет заемщику в любой момент частично погасить взятый кредит или даже полное рефинансирование кредита, и если процентные ставки на рынке падают, тогда у заемщика появляется возможность взять кредит с более низкой процентной ставкой, в этом случае может начать работать механизм моделирования досрочных погашений. В общем случае, механизм предварительных платежей настраивается в Prepayment ID, и ставки предварительных платежей определяются сравнением ставки клиента и рыночной ставки. Структура и параметры досрочного погашения меняются во времени, что отражается в модели. Уникальная особенность генерации кэш-флоу в OFSA состоит в том, что происходит разделение фактических данных (инструментальные данные) и модельных предположений (например, допущения по предварительным платежам), что позволяет менять предположения без модификации инструментальных данных.
Например, в модулях RM и TP используется более 20 разных ID, в том числе:
Forecast Rates ID определяет прогнозные процентные ставки и обменные курсы валют. Прогнозные процентные ставки используют, чтобы проектировать кэш-флоу, включая оценку нового бизнеса, переоценку существующего бизнеса, вычислять предоплаты, и определять методы скидки. Прогнозные обменные курсы используются, чтобы объяснить эффекты валютных колебаний на доходе.
Maturity Strategy ID определяет распределение по срокам "новых бизнесов", добавленных в прогнозный период. Объекты Maturity Strategy устанавливаются в разрезе валюты и продукта. Для новых объемов, генерируемых на период моделирования, следует определить сроки погашения и амортизации, применительно к остаткам на начало каждого периода, и также определить распределение сроков погашения для порожденных объемов, например, пораждаемые ипотеки могут быть разделены следующим образом:
25% для 5 Year Term/30 Year Amortization 25% для 7 Year Term/30 Year Amortization 50% для 30 Year Term/30 Year Amortization
Цель Rate Index ID состоит в том, чтобы установить отношения между безрисковыми процентными ставками (IRC) и другими кодами процентных ставок. С этими установленными отношениями, вы можете прогнозировать ставки для любого инструмента, привязанного к IRC и как только безрисковая ставка меняется, соответственно будет изменяться и не безрисковая процентная ставка. Используется только в стохастической обработке, подробнее будет рассказано в статье посвященной процентным ставкам.
Discount Rates ID определяет метод дисконтирования проектируемых кэш-флоу для определения рыночной стоимости. Для каждой комбинации продукт/валюта, можно выбирать свой дисконтный метод.
Transaction Strategy ID Позволяет проверять воздействие различных cтратегий хеджирования, которые интегрированы с основными сценариями модельных предположений. Может использоваться, чтобы моделировать внебалансовые инструменты и транзакции.
Process ID. Когда все предположения для прогноза определены, Process ID выполняет вычисления, обрабатывая и генерируя набор результатов. Process ID требует ввода четырех различных страниц, включая:
Вычисление Ввод/Предположение Режим Процесса Аудит
Иерархические структуры.
Информационные объекты иерархической структуры (в OFSA используется термин Trees) используются для формирования структур подобных "План счетов", "Организационная структура", "Группировки клиентов" и т.п.
Листья являются самым низким уровнем детализации в иерархической структуре. Четыре иерархических структуры являются обязательными для внедрения OFSA:
Common COA (Common Chart of Account) GL Account (General Ledger Account) Org Unit (Organizational Unit) Financial Element.
Первые два объекта являются планами счетов, листья которых связаны отношением "один ко многим". О планах счетов подробнее см. . Иерархическая структура Org Unit определяет организационную структуру финансовой организации, например филиальную сеть банка. Можно определить и дополнительные организационные структуры, например "Группировки клиентов". В контексте модулей OFSA, листья является столбцами таблиц хранилища данных FDM, которые обеспечивает размерность данных.
При использовании модуля "Трансфертное ценообразование" требуется дополнительная настройка организационной структуры.
Для правильного процесса трансфертного ценообразования, организационная единица выполняющая функции Казначейства, должна быть объявлена для организационных единиц привлекающих/размещающих средства.
В приведенном примере, организационной единице "Mortgage Loans" соответствует организационная единица "Funding Center for Org". Подробности см. в . Финансовые элементы, в данной версии системы OFSA не являются в строгом смысле иерархической структурой, данному объекту будет посвящен отдельный раздел.
Кэш-флоу колонки и алгоритмы формирования значений финансовых элементов.
Следует отметить, что кэш-флоу колонки содержат не только данные, характеризующие конкретную запись финансового инструмента (даты, остатки, ставки, коды), но и данные, фактически определяющие алгоритм обработки (например, тип амортизации). Если даты, остатки и ставки, в том или ином виде существуют в АБС, и при загрузке в хранилище данных FDM потребуется только некоторая модификация, то данные, задающие алгоритм обработки записи финансового инструмента, скорее всего, придется формировать в процессе загрузки. И модификация данных и формирование дополнительных данных при загрузке легко выполняются основным инструментом, используемым при формировании хранилища данных FDM - Oracle Warehouse Builder.
В качестве примера кэш-флоу колонок, определяющих алгоритм обработки записи финансового инструмента, рассмотрим: Int_Type, Amrt_Type_Cd и Interest_Rate_Cd.
Колонка INT_TYPE "Синхронизация процентных платежей" определяет порядок платежа для процентных кэш-флоу:
оплата в конце заемного периода (in arrears) оплата в начале каждого периода, авансом (in advance)
Проценты для инструментов с "in advance" делают свой первый платеж по дате происхождения инструментальной записи. Последний платеж, по дате погашения, является только платежом основной суммы.
Колонка AMRT_TYPE_CD "Метод амортизации основной суммы и процентов" определяет методы амортизации основной суммы и процентов. Ниже приведены некоторые значения данной колонки, система позволяет расширять предопределенные значения методов амортизации, определяя пользовательские платежные образцы (User-Defined Payment Patterns):
| "Воздушный шар" | Традиционный фиксированный "Правило 78" - математическая формула, используемая при вычислении убывающего процента и постоянного ежемесячного платежа, когда заемщик оплачивает (до конца) ссуду перед датой погашения. Число 78 = 12+11+10+…3+2+1 - является суммой номеров месяцев в году. |
| Традиционный регулируемый | |
| Простой процент | |
| "Правило 78" | |
| Регулируемая отрицательная амортизация |
Под амортизацией (например для ипотеки), понимается постепенное сокращение ипотечной задолженности посредством регулярно запланированных платежей в пределах срока ссуды, аналогично и для других финансовых инструментов.
Традиционные типы амортизации имеют платежи неравномерно разделенные между основной суммой и процентами. Общая величина платежа (основная сумма + процент) не меняется.
Амортизация "Фиксированная Традиционная"
Основная сумма никогда не оплачивается до срока погашения. Если "Следующая дата платежа" меньше "Срока погашения", выполняются только процентные платежи. Платеж (основная сумма + процент) выполняется по дате погашения.
Амортизация "Простой процент"
Колонка INTEREST_RATE_CD, IRC "Индекс, с помощью которого регулируемая процентная ставка (adjustable rate) связывается с записью финансового инструмента".
Значение такой процентной ставки периодически изменяется, поэтому соответствующие платежи могут увеличиваться или уменьшаться.
Утилита Rate Manager модуля FDM позволяет задавать, для регулируемой процентной ставки, структуру сроков и значения ставок. В конкретном случае, определяемый индекс может быть и кривой доходности. В случае переоценки (или использования льготного периода) для инструментальной записи с регулируемой ставкой, происходит согласование имеющейся информации (с учетом маржи и возможных лимитов кэпов/флоров) для того чтобы получить ставку, которая и применяется к записи инструмента. Для записей инструмента с фиксированной ставкой, которые не имеют ссылки на INTEREST_RATE_CD, по умолчанию используется 0.
В документе "Technical Reference Manual" подробно описываются все кэш-флоу колонки, порядок их формирования, сопутствующие алгоритмы и необходимые проверки.
"Новый бизнес".
Модели новых бизнес инструментов формируются, как прогнозы модулей OFSA, для того чтобы компенсировать процесс затухания кэш-флоу из-за отсутствия банковских операций в будущих периодах для специфических продуктов. Новый бизнес воздействует на общую сумму дохода и рыночную стоимость в будущих периодах. Без нового бизнеса, оба значения сокращаются в будущих периодах, потому что в перспективе, существующие остатки истекут. Доход и рыночная стоимость, связанные с новым бизнесом являются функцией зарегистрированного остатка, зарегистрированной ставки и распределенного по времени общего объема. Остаток и ставка определяются вводом предположений пользователя. Распределенный по времени общий объем является функцией методологии моделирования.
Резервирование нового бизнеса, можно рассматриваться как поступление из трех источников:
Внутренняя пролонгация существующих счетов Перекладывание существующего счета в другие счета "Новые деньги", несвязанные с существующим бизнесом
Для примера, рассмотрим пролонгацию депозитного сертификата. Когда клиент решает пролонгировать депозитный сертификат, фонды перекладываются в новый депозитный сертификат по дате завершения предыдущего депозитного сертификата.
Пример: пролонгация составляет 150% от изменения основной суммы.
Бизнес банка = Текущая позиция + Новый бизнес
Чтобы моделировать новый бизнес для пролонгации, новый бизнес должен быть зарегистрирован на дату изменения основной суммы. Значение нового бизнеса должно быть определено для каждой даты изменения основной суммы во время модельного периода, как показано на рисунке.
В общем случае новый бизнес моделируется в привязке к листьям плана счетов.
Для периода моделирования получим следующие значения для финансовых элементов:
Исходящий остаток на конец периода моделирования (декабрь) = $57.50
Средневзвешенный остаток =
($50 * 4 дня + $52.50 * 10 дней + $57.50 * 17 дней) / 31 день = $54.9193
Первое изменение основной суммы приходится на 5 декабря (50-45), возобновление на 150%, составит 5*150% = 7.5, и поэтому входящий остаток на 5 декабря равен 52.5 (45+7.5).
Разумеется, данный механизм позволяет получить и прогнозный балансовый отчет и прогнозный отчет о прибылях и убытках. В этой связи, особо следует выделить, что в основе моделирования OFSA лежит балансовый подход, в соответствии с которым параметры моделей подбираются и группируются так, что суммарное изменение внутри моделей в каждый момент времени равно нулю, т.е. прогнозный балансовый отчет будет сходится.
Характеристики для моделирования нового бизнеса, определяются для каждой пары продукт/валюта, в том числе для того чтобы правильно генерировать кэш-флоу следует определить:
Фиксированная или регулируемая ставка Амортизация или единовременное погашение по наступлении срока погашения Частота переоценки График периодических платежей Возможности для отрицательной амортизации IRC, используемый для оценки Капитализированные или выплаченные проценты Временная структура (срок погашения)
Пример экранной формы Leaf Characteristics ID, где определяются эти характеристики нового бизнеса, можно найти в .
Следует заметить, что в практике отечественных разработчиков банковского программного обеспечения, подход основанный на "новом бизнесе" еще далек от практического внедрения, смотрите для сравнения "модель пассивной эволюции" используемую некоторыми отечественными разработчиками.
OFSA Основные принципы
,
Компания "ФОРС-Центр разработки",
Департамент по работе с финансовыми институтами
Отчеты.
OFSA предлагает более 60 стандартных отчетов (с учетом вариантов существенно больше) и два подхода получения этих отчетов и проектирования новых отчетов:
применяя Oracle Reports применяя Oracle Discoverer
Отчеты можно получать с использованием Web-браузера, в стандартных промышленных форматах, в том числе и в формате PDF.
В качестве примера стандартного отчета, предлагается отчет FASB 133 "Учет производных финансовых инструментов и деятельности по хеджированию", который требуют обеспечить возможность переоценки на основе текущих цен портфеля ценных бумаг долгосрочных контрактов.
Замечание. FASB, Financial Accounting Standards Board - Совет по стандартам финансового учета.
FASB 133 показывает балансовый отчет хеджированных инструментов вместе с соответствующими производными финансовых инструментов.
Этот отчет включает три варианта:
форвардных контрактов (Forward Contracts) процентных опционов (Interest Rate Options) процентных свопов (Interest Rate Swaps)
В включены инструментальные таблицы:
Forward_Contracts Mortgages
Т.е. один форвардный контракт может хеджировать группу ипотек, связь устанавливается по колонке "Hedge Portfolio Set". Данный отчет также демонстрирует возможности финансовых инструментов, позволяющие устанавливать связи между таблицами, для получения самых сложных отчетов.
И в конце чисто практическое замечание. С одной стороны OFSA предоставляет огромное количество предопределенных (seeded) информационных структур и алгоритмов обработки, что позволяет достаточно быстро приступить к процессу внедрения. В то же время система обладает развитыми инструментальными средствами для разработки собственных информационных объектов и алгоритмов, что несомненно позволит найти место в хранилище данных FDM для уникальных банковских продуктов.
Планы счетов.
Выбор иерархической структуры GL Account является наиболее легким при внедрении, поскольку по существу листья GL Account эквивалентны счетам Главной Книги финансовой организации, т.е. в России это будут счета второго порядка ЦБ.
Определение Common COA (листья продуктов) является наиболее сложной задачей при определении иерархических структур. Должно существовать достаточное число листьев продуктов, для того чтобы генерировать необходимый спектр аналитических данных. Однако создание слишком большого количества продуктовых листьев может излишне утяжелить вычисления. Вообще, специалисты Oracle считают, что от 300 до 500 листьев продуктов достаточно.
Все листья Common COA должны иметь две обязательные характеристики: тип счета (account type) и метод начисления (accrual basis), ниже приведены основные значения данных характеристик.
| Активы, приносящие доход | 30/360 |
| Вне балансовые требования | Actual/360 |
| Непроцентный доход | Actual/ Actual |
| Другие активы | 30/365 |
| Пассивы, с выплатой процентов | 30/Actual |
| Вне балансовые обязательства | Actual/365 |
| Непроцентные расходы | |
| Налоги | |
| Другие пассивы | |
| Капитал | |
| Дивиденды | |
| Процентный доход (нераспределенный) | |
| Процентный расход (нераспределенный) | |
| Статистика |
Типы счетов классифицируют инструменты по их использованию в финансовых отчетах и определяют, как кэш-флоу процессор обрабатывает финансовый инструмент, именно через значение Common COA определяется тип счета индивидуальной записи в инструментальной таблице. Модули RM и TP используют "метод начисления" для определения процентного дохода.
Кроме того, значительное усилие должно быть сделано, чтобы определить отношения "один ко многим" между Common COA и GL Account. Если подобные отношения правильно не определены, то будет трудно выполнить правильный анализ процессов, включающих эти листья.
.
Подобная организация планов счетов, необходима в первую очередь для поддержания основных принципов бухгалтерского учета, в том числе и постоянства правил бухгалтерского учета. Если план счетов ЦБ (т.е. GL Account) может меняться, вспомним хотя бы "подарок" от 20 ноября 2001г. N 1054-У вместе с Приложением 15 "Порядок бухгалтерского учета вложений (инвестиций) в ценные бумаги и операций с ценными бумагами", то Common COA должен оставаться неизменным.
Согласование данных.
Ранее уже упоминался Oracle Warehouse Builder - основной инструмент, используемый при формировании хранилища данных FDM и обеспечивающий технологию ETL: extraction, transformation, loading - "извлечение, преобразование и очистка, загрузка".
Данные, поступающие в хранилище данных FDM из OLTP систем, должны быть не только согласованны, но и приведены к общему формату:
в многофилиальном банке может работать несколько АБС, да и в филиале среднего или крупного банка это не исключение, а скорее правило. филиалы международного банка хранят данные Главной Книги не только в национальных валютах, но и по разным планам счетов. Для проведения общего анализа по всей филиальной сети необходимо привести данные к общей валюте, согласовать планы счетов, кросс-курсы, картотеку клиентов и др.
Кроме того, OFSA имеет собственные программные средства, обеспечивающие согласование данных поступающих из разных источников. Согласование представляет собой процесс сравнения информации из инструментальных таблиц и Главной Книги.
Наиболее общий тип согласования должен сравнить данные остатков инструмента с исходящими остатками Главной Книги на заданную дату. Выше уже упоминалось, что таблица LEDGER_STAT, кроме прогнозных и бюджетных данных, может хранить и фактические (т.е. загруженные) данные. Таким образом, информация исходящих остатков Главной Книги выступает своего рода контрольной суммой по отношению к данным инструментальных таблиц.
Термины и сокращения.
OFSA - Oracle Financial Services Applications
FDM - модуль OFSA Financial Data Manager, "Управление финансовыми данными"
RM - модуль OFSA Risk Manager, "Управление рисками"
BP - модуль OFSA Budgeting and Planning, "Бюджетирование и планирование"
TP - модуль OFSA Transfer Pricing, "Трансфертное ценообразование"
АБС - оперативные Автоматизированные Банковские Системы, OLTP системы
Cash flow engine - кэш-флоу процессор
As-of-Date - Дата, которая определяет период времени для загруженной информации Последняя дата, за которую отчет или процесс содержат данные.
Входная информация.
Когда приступаешь к изучению сложной и большой системы, в такой трудной предметной области, как банковская, очень полезно уже сразу представлять (хотя бы в общих чертах) основные виды входной информации. В самом первом приближении, можно выделить два вида входной информации:
Информация из оперативных банковских систем, поступающая (загрузка/модификация) с заданной периодичностью в финансовое хранилище данных FDM:
Главная Книга Лицевые счета Клиенты Финансовые Инструменты (Сделки, Контракты и т.д.) Транзакции/проводки Иерархические структуры (планы счетов, филиальная сеть, группировки клиентов и т.д.) Справочники
Существует возможность вводить/корректировать некоторые виды приведенной выше информации с использованием экранных форм.
Информация для моделей. Базовыми строительными блоками функциональных модулей OFSA являются "ID", которые определяют параметры обработки, спецификации прогнозирования, сценарии моделирования и предположений, алгоритмы обработки и формирования данных. Формально "ID" состоит из одной или нескольких экранных форм и соответствующих программных кодов, к которому можно обратиться непосредственно из меню.
Например:
Forecast Rates ID определяет прогнозные процентные ставки и обменные курсы валют. Maturity Strategy ID определяет распределение по срокам "новых бизнесов", добавленных в прогнозный период. Leaf Characteristics ID определяет общие атрибуты вычисления для существующих финансовых инструментов, и параметры "новых бизнесов". Этот ID также используется, чтобы определить характеристики "нового бизнеса" по платежам и порядок установки процентных ставок. Forecast Balance ID определяет значение "новых бизнесов", формируемых для отдельного модельного временного интервала на каждом продукте и каждой активной валюте. Для того чтобы создать новое бизнес предположение, выбирается один из семи доступных методов прогноза, фактически это выбор метода для прогнозирования "нового бизнеса".
До сих пор для понятия "новый бизнес" определение не давалось, хотя из контекста следует, что это понятие связано новыми операциями банка в будущих периодах, и на момент последней загрузки данных в хранилище, информация о "новых бизнесах" в хранилище отсутствует, поскольку она отсутствует и в АВС. Более подробно будет обсуждено ниже.
