Риск менеджмент - Анализ концентрации риска по клиентским группам отраслям и поставщикам с контролем лимитов

В лизинговых операциях значительную роль играет распределение объёмов и задолженностей между клиентскими группами, отраслями и поставщиками. Анализ концентрации риска в BI-среде позволяет не только выявлять узкие места в портфеле, но и формировать практические действия по ограничению риска через лимитирование экспозиции, автоматизированное оповещение и управляемые процессы. Глава сочетает концептуальные основы, архитектурные решения и конкретные подходы к реализации в современных информационных системах лизинга.

В условиях повышенной волатильности рынков и фрагментации цепочек поставок концентрационные эффекты могут проявляться как на уровне отдельных клиентов, так и на уровне отраслевых сегментов или ключевых поставщиков. Эффективная система управления такими рисками строится на трех китах: качественной и полной базе данных, корректно спроектированной аналитической модели концентрации и устойчивой инфраструктуре для мониторинга лимитов и обработки исключений. В рамках данной главы рассматриваются принципы построения архитектуры данных, методы расчёта концентрации, процедуры контроля лимитов и сценарии внедрения в стандартные BI-цепочки лизингового бизнеса.

Краткое содержание главы

Определение и структура концентрационного риска в лизинге: что измеряем и зачем.
Архитектура данных и моделирование содержания риска: факты, измерения и справочные измерения.
Метрика концентрации риска и способы их расчёта: CR4, HHI, пороги риска и адаптация под бизнес-аппетит.
Контроль лимитов, процессы мониторинга и управление отклонениями: правила, workflow, автоматизация.
Интеграции, внедрение и практические кейсы: изначальная настройка, оркестрация процессов, примеры запросов и сценариев.
Управление качеством данных и устойчивостью решений: качество источников, когорта измерений, аудит и регулятивные требования.

Архитектура данных для анализа концентрации риска

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

Фактовая модель риска: таблица f_risk_exposure, фиксирующая по каждой сделке/контракту или агрегированной экспозиции сумму экспозиции, валюту, дату отчета, идентификаторы клиента, отрасли и поставщиков. В связке с dimension-таблицами формируется концентрированная аналитика в разрезе времени, отраслей и темпов роста.
Справочные измерения: dim_client_group, dim_industry, dim_supplier, dim_currency, dim_time. Эти таблицы обеспечивают единицу измерения и единообразие атрибутов. Модель должны поддерживать иерархии (например, отрасль > подотрасль, поставщик > ключевой поставщик), чтобы позволить drill-down и roll-up в дашбордах.
Учет валют и конверсионные механизмы: экспозиции часто деноминированы в разных валютах. Архитектура должна включать единый курс конвертации на момент позиции или на момент расчета для консолидации в базовом базовом курсе, чтобы избежать искажений при сравнении по сегментам.
Источники данных и линейка качества: CRM/ERP-системы, договорная база, учетная система поставщиков, источники контрактной информации и платежей. Архитектура требует явного контроля за данными об экспозициях, валидности связей между фактами и измерениями, а также прослеживаемости пути данных (data lineage).
Концепция data lake - data warehouse: для лизинга чаще применим гибридный подход "lakehouse" или well-constructed star‑/snowflake‑схемы. В современных стэках возможно использованию ClickHouse или Snowflake как аналитической базы, а dbt - как слой трансформаций, обеспечивающий повторяемость и тестируемость моделей.
Безопасность и доступ: роль‑ориентированные политики доступа, минимизация рисков через сегментацию данных, аудит доступа и журналирование изменений. В рамках риск‑менеджмента это критично для соблюдения регуляторных требований и внутренних стандартов контроля.
Интеграционные точки: интеграция с системами лимитирования и оповещения, ERP/CRM‑модулями, BI‑платформами и workflow‑менеджерами. Важно обеспечить API‑уровень доступа для выдачи статусов лимитов в реальном времени и передачу событий об отклонениях в установленном порядке.

Принципы реализации ориентированы на модульность и расширяемость. В архитектуре можно рассмотреть два варианта реализации: классическую «базу данных»-ориентированную схему и «хайбрид»-архитектуру, где аналитика формируется на data lakehouse с поддержкой облачных вычислений и управляемыми сервисами оркестрации. В качестве примеров инструментов, которые часто применяются в отрасли, упоминаются:

ClickHouse для высокоскоростной аналитики по экспозициям и концентрационным метрикам на больших объемах данных.
dbt как слой трансформаций и обеспечения качества данных, тестирования и документации моделей.
Apache Airflow или облачные альтернативы (например, управляемые сервисы конвейеров).

Подход к архитектуре должен учитывать требования к агрегации по сегментам, возможность расчета показателей концентрации за произвольный временной интервал и поддержку сценариев поведения лимитов в реальном времени или near real‑time.

-- Пример упрощенного ER-уровня для анализа концентрации риска
-- Таблица фактов экспозиции
CREATE TABLE f_risk_exposure (
  exposure_id BIGINT PRIMARY KEY,
  contract_id BIGINT,
  date DATE,
  client_id BIGINT,
  client_group_id BIGINT,
  industry_id BIGINT,
  supplier_id BIGINT,
  exposure_amount DECIMAL(18,2),
  currency_code VARCHAR(3)
);

-- Таблицы измерений
CREATE TABLE dim_client_group (
  client_group_id BIGINT PRIMARY KEY,
  group_name VARCHAR(100)
);

CREATE TABLE dim_industry (
  industry_id BIGINT PRIMARY KEY,
  industry_name VARCHAR(100)
);

CREATE TABLE dim_supplier (
  supplier_id BIGINT PRIMARY KEY,
  supplier_name VARCHAR(100)
);

CREATE TABLE dim_currency (
  currency_code VARCHAR(3) PRIMARY KEY,
  fx_to_base DECIMAL(18,6) -- курс конвертации к базовой валюте на дату расчета
);

CREATE TABLE dim_time (
  date_key DATE PRIMARY KEY,
  year INT,
  quarter INT,
  month INT
);

Модели концентрации риска и метрики

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

Экспозиция по сегментам: сумма экспозиций по каждому отраслевому сегменту, клиентской группе и поставщику в заданный период. Это базовый входной параметр для последующих нормализаций и расчётов концентрации.
Распределение долей (shares) и концентрированные индексы: для каждой единицы анализа рассчитывается доля экспозиции i относительно общей экспозиции по соответствующей группе (например, по отрасли или по портфелю в целом).
Индекс Херфиндаhlа-Хиршмана (HHI): показатель, равный сумме квадратов долей экспозиции всех элементов в группе. HHI близкий к 1 означает высокую концентрацию, ближе к 0 - более диверсифицированный риск.
Критические пороги и пороговые расстояния: на основе бизнес‑аппетита устанавливаются целевые пороги для CR4, HHI и отдельных долей по отраслевым и поставщикам сегментам. Порог может зависеть от валют, географии и стадии портфеля.
CR4 и другие концентрационные пороги: сводный показатель доли 4 крупнейших клиентов/групп внутри отрасли или по рынку в целом. CR4 = сумма долей 4 крупнейших элементов, деленная на общую экспозицию в рамках выбранной среза.
Нормализация валют и времени: для измерений, привязанных к доллару или базовой валюте, применяется конвертация на конкретную дату отчета, чтобы исключить искажения от курсовых движений.

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

-- Пример расчета HHI по отрасли в базовой валюте
WITH total_exposure AS (
  SELECT
    industry_id,
    SUM(exposure_amount) AS total_industry_exposure
  FROM f_risk_exposure
  GROUP BY industry_id
),
shares AS (
  SELECT
    f.industry_id,
    f.client_group_id,
    SUM(f.exposure_amount) / t.total_industry_exposure AS share
  FROM f_risk_exposure f
  JOIN total_exposure t
## ON f.industry_id = t.industry_id
  GROUP BY f.industry_id, f.client_group_id, t.total_industry_exposure
),
hhI AS (
  SELECT
    industry_id,
    SUM(share * share) AS HHI
  FROM shares
  GROUP BY industry_id
)
SELECT * FROM hhI
ORDER BY HHI DESC;

В дополнение к HHI полезна комбинация с CR4, чтобы не ограничиваться только суммой квадратов долей. Пример запроса для вычисления CR4 по отрасли и по портфелю:

-- Пример вычисления CR4 по отрасли
WITH ranked AS (
  SELECT
    industry_id,
    client_group_id,
## SUM(exposure_amount) AS exposure,
    ROW_NUMBER() OVER (PARTITION BY industry_id ORDER BY SUM(exposure_amount) DESC) AS rn
  FROM f_risk_exposure
  GROUP BY industry_id, client_group_id
),
tot AS (
  SELECT industry_id, SUM(exposure) AS total_exposure FROM ranked GROUP BY industry_id
),
joined AS (
  SELECT r.industry_id, r.client_group_id, r.exposure, t.total_exposure
  FROM ranked r JOIN tot t ON r.industry_id = t.industry_id
)
SELECT
  industry_id,
  SUM(CASE WHEN rn Эти примеры демонстрируют базовые подходы к вычислениям. На практике применяются дополнительные уровни агрегации (например, по региону, валюте, сегменту продаж и каналу сбыта), а также учет скорректированной экспозиции в случае секторальных изменений и переоценки контрактов. Важно не ограничиваться одной метрикой: набор индикаторов должен соответствовать конкретной бизнес‑задаче, учитывать риск-аппетит организации и сценарии стресс‑тестирования.
 
Параметризация порогов и адаптивность к изменению бизнес-модели

Базовый уровень порогов следует устанавливать на основе анализа исторических данных и стресс‑тестирования портфеля. Порог может быть динамичным: при росте доли крупнейших клиентов или при изменении состава поставщиков параметры концентрации должны перерасчитываться и скорректироваться.
Важно иметь режим “толерантности к шуму” - не каждый временной скачок должен приводить к тревоге. Включаются временные окна (например, 3-6 кварталов) для подтверждения корректной динамики.
Необходимо предусмотреть сценарии реакции на порог: alert, warning, formal breach, требование подтверждения и возможность применения автоматических ограничений или ручной авторизации.

Контроль лимитов и процедуры управления отклонениями

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

Типы лимитов: лимиты по отраслям, по клиентским группам, по поставщикам, по валютам и по географическим сегментам. Кроме того, лимиты могут применяться к совокупной экспозиции по конкретному контракту или к совокупной экспозиции по определенной группе клиентов.
Этапы контроля: мониторинг экспозиции в реальном времени или near real‑time, сравнение с установленными лимитами, формирование оповещений и автоматическое применение ограничений (например, запрет на новые сделки, требование дополнительной одобрительной подписи, запуск процесса управляемого изменения лимита).
Workflow по обработке Breach: идентификация нарушителя, уведомление владельца риска, формирование запроса на корректирующую работу, эскалация до совета риска при критических отклонениях, документирование решения и обновление лимитов.
Аудит и регулятивная полнота: каждый шаг процесса должен быть детализированно зафиксирован. В BI-среде это достигается через журнал изменений лимитов, версии правил, историю одобрений и связь с данными источника.

Внедрение автоматизации лимитов требует сочетания данных, правил и процессов. Архитектурно это реализуется через событийно-ориентированные каналы передачи состояния риска (например, через Kafka или аналогичный брокер сообщений), интеграцию с системой управления лимитами и BI‑слоем, который показывает текущее состояние лимитов и прогнозируемые тренды. В рамках данного раздела полезно зафиксировать следующие принципы:

Прозрачность и прослеживаемость: каждое нарушение лимита должно иметь источник, время, контекст и владельца.
Гибкость управления правилами: возможность легко модифицировать пороги лимитов, добавлять исключения и временные адаптации под рыночную конъюнктуру.
Автоматизация с контролем риска: автоматическое применение ограничений при breach и отдельное управление исключениями на основе бизнес‑контекста.
Соответствие регуляторным требованиям: хранение истории изменений и обоснований, а также возможность аудита по требованию.

Готовые примеры реализации ограничений в BI-платформе могут включать:

Поле «limit_status» в представлениях по отраслям/клиентским группам, которое меняется на «OK»/«BREACH» в зависимости от текущего значения экспозиции и заданного лимита.

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

-- Пример простого правила: определить, что экспозиция по отрасли превышает лимит
SELECT industry_id, SUM(exposure_amount) AS total_exposure, limit_amount,
       CASE WHEN SUM(exposure_amount) > limit_amount THEN 'BREACH' ELSE 'OK' END AS status
## FROM f_risk_exposure re
JOIN dim_industry di ON re.industry_id = di.industry_id
JOIN industry_limits il ON il.industry_id = di.industry_id
GROUP BY industry_id, limit_amount;

-- Пример автоматического уведомления в случае BREACH (упрощенный вариант)
-- Псевдокод для бизнес-логики в оркестраторе
## IF status = 'BREACH' THEN
  trigger_alert(to: risk_owner_email, subject: 'Concentration limit breach', body: 'Industry X breached limit Y');
  flag_limit_for_review(industry_id);
END IF;

Интеграции и процессы внедрения

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

Источники данных и ETL/ELT‑пайплайны: обеспечить инкрементальные обновления экспозиции, корректное управление версиями курсов конвертации валюты, обработку пропусков и ошибок синхронизации. Рекомендуется использовать современные оркестраторы (например, Apache Airflow) и трансформационные инструменты (dbt) для обеспечения повторяемости и модульности конвейеров.
Управление качеством данных: данные экспозиции должны проходить через проверки на полноту, согласованность и валидность. Включаются проверки на дубликаты контрактов, согласование курсов валют, контроль за логическими связями между фактами и измерениями.
Логика лимитов и конфигурации: хранение правил и лимитов в отдельной конфигурационной области, чтобы их можно было адаптировать без переработки моделей. Включается поддержка версионирования правил и тестирования изменений на историческом наборе данных.
Архитектура интеграции BI: создание единых дашбордов и отчетных панелей, которые позволяют анализировать концентрацию на уровнях: портфель, отрасль, клиентская группа, поставщик, регион. В рамках интеграции полезно предусмотреть API‑доступ к метрикам концентрации для внешних систем риск‑менеджмента.
Внедрение и эксплуатация: поэтапная реализация с пилотной зоной, затем постепенное расширение по сегментам портфеля. Важно обеспечить обучение бизнес‑пользователей и устойчивость к изменениям в источниках данных и бизнес‑правилах.

Использование инструментов открытых решений и отечественных экосистем может существенно снизить время внедрения. Например:

dbt для организации трансформаций и тестирования моделей.
Apache Airflow как оркестратор конвейеров.
ClickHouse или Cloud‑ориентированные аналитические базы для быстрой агрегации и интерактивной аналитики.
В рамках российского контекста возможна интеграция с локальными решениями данных и сервисами, сохраняя принципы открытости и совместимости.

Пример реализации: кейсы и SQL‑алгоритмы

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

Расчёт экспозиции по отрасли и по клиентской группе в рамках базовой валюты и выбранного периода.

Расчёт HHI и CR4 по отрасли.

-- Расчёт общей экспозиции по отрасли на период
WITH period AS (
  SELECT DATE '2025-12-31' AS end_date
),
industry_exposure AS (
  SELECT
    di.industry_id,
    SUM(CASE WHEN re.date -- Расчёт HHI по отрасли (упрощённый вариант)
## WITH total AS (
  SELECT industry_id, SUM(exposure_amount) AS total_exposure
  FROM f_risk_exposure
  GROUP BY industry_id
),
shares AS (
  SELECT industry_id, client_group_id, SUM(exposure_amount) / t.total_exposure AS share
## FROM f_risk_exposure f
  JOIN total t ON t.industry_id = f.industry_id
  GROUP BY industry_id, client_group_id, t.total_exposure
),
hhI AS (
  SELECT industry_id, SUM(share * share) AS HHI
  FROM shares
  GROUP BY industry_id
)
SELECT * FROM hhI ORDER BY HHI DESC;
-- CR4 по отрасли (на примере 4 крупнейших клиентов в каждой отрасли)
WITH ranked AS (
  SELECT
    industry_id,
    client_group_id,
## SUM(exposure_amount) AS exposure,
    ROW_NUMBER() OVER (PARTITION BY industry_id ORDER BY SUM(exposure_amount) DESC) AS rn
  FROM f_risk_exposure
  GROUP BY industry_id, client_group_id
),
tot AS (
  SELECT industry_id, SUM(exposure) AS total_exposure
  FROM ranked
  GROUP BY industry_id
)
SELECT
  r.industry_id,
  SUM(CASE WHEN r.rn Эти запросы иллюстрируют концептуальные принципы, но в реальной системе они дополняются обработкой ошибок, учётной политикой по валюте, индикаторами качества данных и тестами на сценарии стресс‑теста. Визуализация результатов возможна в BI‑инструментах типа Power BI или Tableau. Важной частью является организация детализированных дашбордов, которые позволяют диверсифицировать риск по каждому сегменту и проследить динамику параметров концентрации в разрезе времени.

Управление качеством данных и устойчивостью решений

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

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

Key takeaways

Анализ концентрации риска в BI‑лизинге требует целостной архитектуры данных, где экспозиции, отрасли и поставщики связаны через единые измерения и поддерживают многоуровневый drill‑down.
Метрики концентрации, такие как HHI и CR4, позволяют оценить диверсификацию портфеля и определить направления для маппинга лимитов. В сочетании они дают целостное представление о рисках.
Контроль лимитов и процедуры управления отклонениями должны быть интегрированы в бизнес‑процессы, поддержаны автоматизацией и сопровождаться аудитом и прозрачной документацией.
Интеграции и процессы внедрения требуют модульности, повторяемости трансформаций, использования CI/CD‑практик для моделей и устойчивой архитектуры конвейеров.
Управление качеством данных критично: данные экспозиции должны быть полноюными, согласованными и валидируемыми; без этого риск‑аналитика теряет доверие и управленческая ценность.
В современных стэках BI лизинга возможно сочетать локальные и облачные решения: dbt, Airflow, ClickHouse, а также облачные аналоги - для обеспечения гибкости и масштабируемости.
Внедрение лимитного контроля требует не только технических инструментов, но и компетентной организационной части: роли, процессы эскалирования, регламенты и подготовка персонала.
Валютная конвертация и нормализация данных должны быть учтены на уровне моделей, чтобы избежать искажений и обеспечить сопоставимость результатов за периоды.
Примерные кейсы и запросы демонстрируют принципы, но реальная система требует адаптивности к бизнес‑контексту, стресс‑тестированиям и постоянной оптимизации процессов.

FAQ

Что именно обозначает концентрация риска в контексте лизинга?

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

Какие данные и измерения необходимы для анализа концентрации?

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

Какие метрики выбрать для оценки риска и почему?

Основные метрики: HHI и CR4. HHI измеряет уровень концентрации на уровне отраслей или портфеля и показывает общую диверсификацию; CR4 фокусируется на доли четырех крупнейших элементов внутри сегмента. Комбинация обеих метрик обеспечивает широкий взгляд на уровень концентрации и позволяет управлять исключениями и лимитами на практике.

Как организовать автоматическое управление лимитами?

Необходимо разделить роли: риск‑менеджер устанавливает лимиты, бизнес‑владельцы контрагентов контролируют их исполнение, BI‑слой предоставляет мониторинг, а workflow‑сервер обрабатывает breach, уведомления и процессы утверждений. Важна возможность автоматического применения ограничений при breach и наличие процедур для исключений с подтверждением.

Какие архитектурные решения поддерживают гибкость и масштабируемость?

Стратегия «lakehouse» или гибридная архитектура на базе OLAP‑кластеров (ClickHouse, Snowflake) плюс слой трансформаций dbt. Оркестрация конвейеров через Airflow, использование единых API для обновления лимитов и интеграции с BI‑платформами. Важно обеспечить линейку валидируемых параметров и возможности drill‑down в дашбордах.

Какие практические ограничения и риски существуют?

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

Какой подход к внедрению выбрать в организации?

Рекомендуется поэтапный подход: пилот в одном бизнес‑сегменте, затем расширение на остальные отрасли и поставщиков. В процессе следует обеспечивать обучение пользователей, создание референсных дашбордов и настройку автоматизации для стандартных сценариев (alerts, breaches) с документированной регламентной базой.

Какие примеры инструментов чаще всего применяются в таких проектах?

dbt для трансформаций, Apache Airflow для оркестрации, ClickHouse как аналитическая база, BI‑платформы (Power BI/Tableau) для визуализации, а в российской практике возможно использование локальных инфраструктурных решений в рамках регуляторной совместимости. Важно соблюдать баланс: развивать архитектуру и процессы без перегрузки технологическим лоскутом.

Как учитывать изменение бизнеса и рыночной ситуации в порогах лимитов?

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

Как обеспечить устойчивость и качество данных при интеграции с внешними системами?

Необходимо обеспечить управляемую цепочку данных: MDM‑процедуры для единообразных идентификаторов, проверки на дубликаты, мониторинг целостности данных, согласование форматов и версий. Виде сертификации данных и процедуры аудита должны быть встроены в процесс, чтобы сохранять доверие к аналитическим выводам в BI.

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

← Предыдущая статья

Риск менеджмент - Оценка ожидаемых потерь по портфелю с детализацией по продуктам, отраслям, регионам и винтажам

Следующая статья →

Риск менеджмент - Мониторинг качества нового портфеля по винтажам выдачи ранняя просрочка и ранние дефолты