← Все моделиОткрыть живое демо →

## 1. Главный месседж для заказчика

Мы строим не “таблицу графика платежей”, а расчетную модель кредитного lifecycle: договор, ставка, выдачи, погашения, начисления, резервы, RWA, финансовый рычаг и отчетные статьи связаны в единую управляемую цепочку.

График платежей в этом подходе — это результат работы расчетного ядра, а не первичный источник логики. Это важно, потому что при изменении ставки, выдаче транша, фактическом платеже, корректировке резерва или изменении сценария не нужно вручную перестраивать Excel-файл: расчет пересчитывает денежные потоки и сразу формирует витрины для отчетности. Такой тезис уже заложен в презентационную линию: cash-flow engine и контрактная модель противопоставляются spreadsheet-подходу, где логика живет в формулах и шаблонах.

## 2. Что именно считает решение

Решение покрывает две бизнесовые ситуации.

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

Фактовый / корректировочный расчет пересчитывает состояние кредита по фактическим событиям. Здесь входом служат уже не только параметры договора, но и события из фактического графика: выдачи, платежи, уплаченные проценты, комиссии. Для этого используется дневная сетка: по каждому договору строится ежедневная временная ось, к ней присоединяются sparse-события, а дальше состояние кредита пересчитывается день за днем. В daily-шаблоне явно заложены loan, payment, paid_interest, фактическая ставка, остаток на дату, ежедневное начисление процентов и IFRS scope.

## 3. Модель данных в бизнесовых терминах

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

Бизнес-объектФизический кубБизнесовый смысл
Параметры договораfin_doc_paramsУсловия договора: сумма кредита, срок, продукт, ставка/спред, коэффициенты резервирования
Прогнозная ключевая ставкаfin_key_rate_frcСценарные ставки для планового расчета
Фактическая ключевая ставкаfin_key_rateСтавки по датам для фактового daily-пересчета
Макропараметры продуктаfin_macroRW и коэффициенты финансового рычага по продукту
График платежейfin_payment_scheduleДетальная расчетная таблица по договору и дате
Отчетность / витринаfin_reportsУниверсальная витрина по статье fin_acc, месяцу, версии, сценарию и значению

Эта структура уже отражена в semantic catalog: key_rate, key_rate_forecast, product_parameters, reporting_forms, contract_parameters и payment_schedule разведены как отдельные бизнес-объекты, а fin_reports хранит значение value по измерениям version, scenario, account/fin_acc и calmonth. Детальный куб fin_payment_schedule содержит основные расчетные показатели: остатки, выдачи, погашения, комиссии, ставки, средний объем, начисленные проценты, IFRS scope, резервы, RWA и финансовый рычаг.

## 4. Бизнес-логика расчета графика платежей

Расчет можно объяснить заказчику как последовательность понятных финансовых шагов.

ШагБизнесовый смысл
1. Формирование временной осиДля плана создается месячный график, для факта — ежедневная сетка по договору до заданной даты расчета.
2. Подтягивание ставокВ плане ставка берется из прогноза ключевой ставки по календарному месяцу; в факте — из фактической ставки по конкретной дате.
3. Расчет движения долгаВыдача увеличивает задолженность, погашение уменьшает задолженность.
4. Расчет остатка на датуОстаток на дату = предыдущий остаток + выдача − погашение.
5. Расчет процентовВ плане проценты считаются по месячной базе, в факте — ежедневно на фактический остаток.
6. Расчет IFRS scopeФормируется экономический объем требований по договору с учетом долга, начислений, погашений и уплаченных процентов.
7. Расчет резервовНа IFRS scope и невыбранный лимит применяются коэффициенты резервирования.
8. Расчет RWA и финансового рычагаНа чистую экспозицию после резервов применяются риск-веса и коэффициенты финансового рычага.
9. Формирование витринРасчетные показатели раскладываются по статьям fin_acc в баланс и P&L.

В обоих графах расширение FinanceModule добавляет над базовым графиком расчеты close_limit, коэффициентов резервирования, резервов, изменений резервов, RWA, финансового рычага, конца месяца и накопленного процента. Эти формулы заложены в financeExtensions планового и фактового графов.

## 5. Описание ключевых показателей

ПоказательБизнесовое названиеБизнесовый смысл
open_limitОстаток НКЛНевыбранный лимит кредитной линии на начало периода. При выдаче кредита лимит уменьшается.
loanСумма выдачиСобытие предоставления денежных средств заемщику.
principal_payment / paymentСумма гашенияПогашение основного долга, уменьшающее задолженность.
balance_at_dateОстаток на датуТекущий остаток долга после выдач и погашений.
commissions_paidПрочие комиссии уплаченныеФактические комиссионные платежи, предусмотренные моделью данных.
commissions_receivedПрочие комиссии полученныеФактические комиссионные поступления, предусмотренные моделью данных.
rate / loan_rateРазмер процентной ставкиСтавка договора: фиксированная или рассчитанная как ключевая ставка плюс спред.
avg_balance / balance_avgСредний объемСредняя экспозиция за период, используемая для аналитики и процентного дохода.
interestНачисление процентовПроцентный доход, начисленный на остаток долга. В факте считается ежедневно.
ifrs_scopeОбъем МСФОЭкономическая экспозиция по договору для целей IFRS/резервирования.
paid_interest_sumПроценты уплаченныеАгрегированная сумма процентов за период, в фактовом графе собирается через месячную агрегацию daily-начислений.
impairment_stageЭтап обесцененияАтрибут модели данных для классификации риска; в текущих формулах P1 напрямую не используется, но модель его поддерживает.
loan_reserve_ratioКоэффициент резерва ссудыНорма резервирования на кредитную экспозицию.
loan_reserveРезерв ссудыРезерв = коэффициент резерва ссуды × IFRS scope.
norev_cl_reserve_ratioКоэффициент резерва НКЛНорма резервирования на невыбранный лимит.
norev_cl_reserveРезерв НКЛРезерв = коэффициент резерва НКЛ × остаток невыбранного лимита.
change_loan_reserveИзменение резервов ссудыДельта резерва ссуды относительно предыдущего периода.
change_novel_cl_loan_reserveИзменение резервов НКЛДельта резерва по невыбранному лимиту относительно предыдущего периода.
rwa_loanRWA ссудыРиск-взвешенная кредитная экспозиция после учета резерва.
rwa_norev_credit_lineRWA НКЛРиск-взвешенная экспозиция по невыбранному лимиту после учета резерва.
fin_leverage_loanФинансовый рычаг ссудыЭкспозиция для расчета финансового рычага по ссуде.
fin_leverage_norev_credit_lineФинансовый рычаг НКЛЭкспозиция для расчета финансового рычага по невыбранному лимиту.

## 6. Как формируются витрины по fin_acc

Витрина fin_reports устроена как универсальная отчетная таблица: расчетный показатель переводится в пару статья fin_acc + значение value, после чего агрегируется по версии, сценарию, месяцу и статье. Это дает важный эффект: один расчетный граф одновременно формирует детальный график платежей и управленческую / финансовую отчетность.

Источник из расчетаСтатья fin_accНазвание статьиБизнесовая интерпретация
ifrs_scopeA3Кредиты предоставленные некредитным организациямБалансовая кредитная экспозиция
-loan_reserveA3.1Резервы по кредитамКонтрактив к кредитному активу
-norev_cl_reserveL12Резервы по условным обязательствам кредитного характераРезерв по невыбранной кредитной линии
interest_cumsumPL1Процентные доходыНакопленный процентный доход
-loan_reserve или движение резерваPL4Создание/восстановление резерва под ожидаемые кредитные убыткиP&L-эффект от резерва по ссуде
-norev_cl_reserve или движение резерваPL13Создание/восстановление прочих резервовP&L-эффект от резерва по НКЛ

В плановом графе результат после FinanceModule фильтруется на отчетные даты, затем отдельные Projection/Derive-ветки назначают статьи A3.1, L12, PL13, A3, PL4, PL1, после чего данные объединяются, получают calmonth, агрегируются и записываются в fin_reports.

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

Важное методологическое уточнение: в текущих графах для PL4 и PL13 используется величина резерва с обратным знаком. Если заказчик хочет видеть строго движение резерва за период, то для P&L-статей логичнее использовать change_loan_reserve и change_novel_cl_loan_reserve, которые уже рассчитываются в FinanceModule.

## 7. Ценность подхода для заказчика

Первое — снижение операционного риска. Расчетная логика больше не живет в Excel-файлах, копиях и ручных формулах. Пользователь собирает расчетный pipeline визуально: читает кубы, применяет финансовый модуль, агрегирует результат и пишет его обратно в EPM. Такой целевой сценарий прямо описан для EPM Financial Builder: аналитик выбирает входной куб, версию, сценарий, продукт, запускает готовый модуль расчета графика, записывает график и агрегированные результаты обратно в целевые кубы.

Второе — plan/fact в одной модели. Плановый расчет и фактовая корректировка используют общий набор бизнес-показателей: долг, проценты, резервы, RWA, финансовый рычаг и статьи отчетности. Это позволяет сравнивать план, факт и сценарии не через отдельные файлы, а через измерения EPM: версия, сценарий, договор, дата, продукт и статья fin_acc.

Третье — explainability. Любая цифра в витрине раскладывается назад до расчетного источника: договор → график → показатель → статья fin_acc → отчетный месяц. Это особенно важно для резервов, RWA и финансового рычага, где заказчику нужно объяснять не только итоговую сумму, но и драйверы: объем экспозиции, ставка, коэффициент резерва, RW и коэффициент leverage.

Четвертое — гибкость кредитного lifecycle. Архитектурно ценность можно формулировать так: кредитная специфика встроена в EPM-ядро через измерения, расчетный движок, события и workflow; модель хранит алгоритм, а не просто готовый график; события вроде траншей, платежей и изменения ставок запускают dynamic rescheduling и сохраняют версии “как было” и “как стало”.

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

## 8. Готовый текст для презентации заказчику

Мы предлагаем не очередной расчетный файл, а управляемую модель кредитного cash-flow внутри EPM.
На вход система получает параметры договора, ставки, макропараметры продукта и фактические события. Расчетное ядро строит плановый или фактический график платежей, рассчитывает остатки, проценты, IFRS-экспозицию, резервы, RWA и финансовый рычаг. Затем эти показатели автоматически раскладываются в финансовые витрины по статьям fin_acc: баланс, процентные доходы и резервные статьи.
Для бизнеса это означает прозрачный и воспроизводимый расчет, единый plan/fact-контур, меньше ручной работы, меньше риска ошибок и возможность быстро подключать новые продукты и сценарии без переписывания Excel-моделей.