Часть 18. Витрина кредитного портфеля

Кредитный портфель показывает, как SDD Data работает с агрегированной отчётностью. Здесь опасность не в PII, а в неверной интерпретации stage, principal, просрочки и качества портфеля. Маленькое изменение правила может изменить отчётность.

Учебный mart

mart_credit_portfolio_quality агрегирует кредиты по stage. Минимальный контракт:

• stage not null;
• principal агрегируется воспроизводимо;
• просрочка не теряется;
• источник stage описан;
• бизнес-интерпретация не придумывается агентом.

Что значит stage

В реальном банке stage может быть связан с IFRS 9, risk methodology и регуляторной отчётностью. В учебном примере stage — синтетический признак. Это нужно явно написать, чтобы агент не начал добавлять «улучшенную» методологию.

Плохая спецификация:

Посчитать качество кредитного портфеля.

Хорошая спецификация:

Группировать синтетические кредиты по исходному `stage`. Показывать
`loan_count` и `principal_rub`. Не выводить правила staging по IFRS. Трактовать
`stage` как поле источника.

Проверочные факты

• stage not null;

• суммы principal не отрицательные, если это задано правилами источника;
• количество строк соответствует количеству stage-значений;
• ревьюер подтвердил, что stage не переопределён в SQL;
• заметка о влиянии на контракт фиксирует, что методология не изменилась.

Qwen-запрос

Сравни stg_loans и mart_credit_portfolio_quality.
Покажи, какие бизнес-допущения делает SQL.
Отдели факты источника от выведенных правил. Файлы не меняй.

Минимальный выход

После главы создайте заметку ревью по кредитной витрине:

Исходный stage:
Агрегация:
Показатели:
Допущения:
Проверка:
Требуется подтверждение:

Разбор для читателя

Кредитная витрина показывает другой тип риска: здесь опасна не только утечка PII, но и ложная методология. Слова stage, просрочка, principal, качество портфеля выглядят как элементы серьёзной банковской модели. Агент может попытаться «улучшить» пример знаниями об IFRS 9, PD, LGD или ECL. Для учебника это ошибка, если такие решения не записаны в спецификации и не подтверждены человеком.

Поэтому stage в примере трактуется как поле источника. Мы не утверждаем, что

оно рассчитано по правильной методологии. Мы только агрегируем синтетический портфель по этому признаку и проверяем базовые инварианты: stage не пустой, суммы неотрицательные, principal воспроизводимо агрегируется. Такая честность важнее мнимой полноты. Учебная витрина должна ясно говорить, где заканчивается пример и начинается реальная банковская методология.

В кредитных данных особенно полезно отделять факт источника от интерпретации. days_past_due может быть числом из системы. Решение, как оно влияет на качество портфеля — уже методология. principal_rub может быть остатком или исходной суммой. Если это не уточнено, агрегат выглядит убедительно, но может означать разные вещи. Спецификация должна либо закрыть вопрос, либо явно оставить его открытым.

Хороший отчёт ревьюера по кредитной витрине не пытается стать кредитным комитетом. Он проверяет границы: SQL не переопределил stage, суммы не ушли в отрицательные значения, витрина не заявляет больше, чем умеет доказать. Это скромная роль, но она предотвращает главный учебный дефект — уверенный текст вокруг недоказанной методологии.

Практика

Найдите в кредитной витрине одно поле, которое выглядит методологическим.

Запишите, является ли оно факт источника, учебным упрощением или требует отдельной банковской спецификации.

Типичная ошибка

Добавлять «правильную» банковскую методологию без спецификации. Агент может знать слова IFRS, PD, LGD, ECL, но в учебном проекте это внешние понятия. Их нельзя внедрять без отдельной продуктовой спецификации.

Контрольные вопросы

1. Почему источник stage нельзя молча переопределять?
2. Какие проверки нужны для агрегированной кредитной витрины?
3. Где проходит граница между учебной витриной и реальной методологией?