Промышленные технологии управления рисками

Дата публикации: 
28.06.2015

управление рисками

Современный рынок бюро кредитных историй консолидирован тремя крупнейшими игроками. Это Национальное бюро кредитных историй (НБКИ), содержащее данные о 105 млн кредитов, кредитное бюро Equifax (104 млн) и Объединенное кредитное бюро (95 млн). При этом все бюро предоставляют кредитные отчеты в различных форматах, что усложняет работу внутренних подразделений банков по сведению данных, в том числе для смежных информационных систем банка (CRM, АБС и пр.). Статья посвящена сервису унифицированных и сводных отчетов CreditRegistry Enterprise, помогающему решить эту проблему.

Дополнительное ограничение на обработку кредитных отчетов накладывает российское законодательство, запрещающее передачу данных из кредитного отчета (сведения, входящие в кредитный отчет, относятся к персональным данным) на обработку во внешние информационные системы. Единственным промышленным решением для банков по унификации кредитных отчетов из разных бюро является сервис унифицированных и сводных отчетов CreditRegistry Enterprise, поставляемый на рынок ЗАО "МТЦ".

 

Проблема разных форматов и различного набора данных

 

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

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

- различными принципами формирования отчетов БКИ;

- различными, зачастую принципиально разными, форматами представления данных отчетов БКИ;

- недостаточно полной формализацией представляемых данных;

- различиями между данными, получаемыми в рамках дополнительных услуг различных БКИ, по форматам и семантике и т.д.

Это приводит к различным негативным последствиям, среди которых особо выделяются следующие.

1. Сотрудники банка вынуждены тратить большое количество времени на анализ отчетов различных БКИ.

2. Если отчеты БКИ являются входными данными для других смежных информационных систем банка (CRM, АБС и пр.), необходимо обеспечивать в этих системах поддержку форматов различных БКИ.

3. Необходимо в смежных банковских системах предусматривать сложные алгоритмы нормализации и сведения данных.

4. Зачастую решение о выдаче нового кредита принимается на основании агрегированных данных по всем кредитам заемщика.

 

Описание решения

 

Для решения существующих проблем банкам приходилось разрабатывать специализированные модули по обработке кредитных отчетов из различных БКИ. Однако в последнее время все большую популярность приобретает универсальное решение ЗАО "МТЦ". Появление CreditRegistry Enterprise (CRE) стало возможным благодаря осознанию значительного опыта по реализации отдельных модулей доработки кредитных отчетов. CreditRegistry Enterprise сегодня - эффективное решение, включающее:

- представление данных различных БКИ в унифицированной форме, называемой Единым форматом;

- сведение отчетов различных БКИ в единый отчет Единого формата;

- агрегирование данных по кредитам заемщика и предоставление их в рамках документа Единого формата.

 

Унификация

 

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

CRE осуществляет преобразование формата отчета различных БКИ к Единому формату. Поддерживаются форматы следующих бюро:

- НБКИ;

- Equifax;

- ОКБ;

- БРС.

Единый формат представляет следующие сведения:

1. Данные о субъекте:

- фамилия, имя, отчество;

- сведения о смене фамилии;

- дата и место рождения;

- пол;

- гражданство.

2. Информация о документах субъекта (номер, место и дата выдачи и пр.).

3. Информация об адресах и телефонах.

4. Сведения о работодателях.

5. Данные о кредитных договорах. По каждому кредитному договору документ содержит следующие сведения:

- номер договора и отношение банка к договору (свой/чужой);

- отношение субъекта к договору;

- даты открытия договора, плановая и фактическая даты закрытия;

- тип кредита;

- статус договора;

- сведения о дисциплине исполнения обязательств (как по месяцам, так и обобщенно: количество просрочек различной длины, максимальный объем просроченной задолженности, текущее количество дней просрочки);

- частота платежей;

- сумма кредита и текущий лимит;

- текущая задолженность и оставшаяся непогашенная задолженность;

- размер платежа и др.

6. Агрегированные данные по кредитным договорам. Подробности по агрегированию см. в разделе "Агрегирование".

7. Данные скоринговых сервисов.

8. Данные о проверках в федеральных службах и базах данных.

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

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

Документ Единого формата представляется в виде XML. Кроме того, данные Единого формата доступны в реляционной форме (см. раздел "Интерфейсы").

 

Сведение данных

 

Если банк запрашивает кредитную историю субъекта из различных бюро, весьма вероятно, что полученные фактические данные будут дополнять друг друга. Кроме того, возможно, что одни и те же данные в различных бюро представлены различными форматами или записью (характерно, например, для почтовых адресов и номеров документов).

CreditRegistry Enterprise предлагает сервис сведения ответов различных бюро в один документ Единого формата. CRE выполняет следующие операции:

1. Приведение всех отчетов различных БКИ к Единому формату.

2. Выявление общих данных для всех участвующих в сведении отчетов с учетом возможных различий в форме записи и представления тех или иных сведений.

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

4. Объединение непересекающихся данных.

5. Дополнение документа информацией об источниках сведений, датой и другими техническими данными.

6. Вычисление агрегированных данных по результатам сведения.

В результате этой операции CRE представляет документ Единого формата, содержащий данные всех БКИ с учетом возможности их пересечения и дополнения друг другом, а также агрегированные данные по всем уникальным счетам. Эти данные без необходимости дальнейшей предобработки применимы для принятия решения о кредитовании, бизнес-аналитики, риск-менеджмента и других нужд бизнеса.

 

Агрегирование

 

Информация о кредитной активности

 

Агрегирование представляет собой аналитическую обработку данных кредитной истории субъекта, полученных от одного или нескольких БКИ. К основным данным, получаемым в результате, можно отнести следующие:

- общее количество кредитов, в которых фигурирует субъект;

- общее количество кредитов, в которых фигурирует субъект, с разбиением по типам (потребительский/автокредит/ипотека и т.д.);

- количество кредитов, в которых субъект является основным заемщиком/созаемщиком и т.д.;

- даты открытия первого и последнего кредитных договоров;

- наивысший текущий просроченный статус;

- общее число судебных элементов;

- общее количество записей из официальных источников;

- информация о запросах в БКИ:

1) период, прошедший с момента последнего запроса;

2) количество запросов в бюро за последние 3/6/9/12 месяцев и за все время;

- исторически наихудший платежный статус;

- общее число просрочек по всем договорам:

1) до 5 дней/от 5 до 29 дней/от 30 до 59 дней/от 60 до 89 дней/более 90 дней;

2) до 30 дней/от 30 до 59 дней/от 60 до 89 дней/более 90 дней за последний год.

 

Платежная нагрузка клиента

 

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

Информация о платежной нагрузке клиента выдается в рублях даже в случае, если у субъекта имеются кредиты в иностранной валюте. При расчете платежной нагрузки используется курс, задаваемый с помощью записи в базе данных. Если курс через базу данных не определен, CRE обращается к соответствующему сервису Банка России или (в случае недоступности сервиса) использует курс по умолчанию. Таким образом, CRE позволяет гибко задавать внутренние курсы валют и (или) использовать курс Банка России.

 

Критерии

 

Документ Единого формата содержит ряд полей, индицирующих определенные признаки. Таких признаков предусмотрено шесть:

1) признак того, что есть кредитные договоры с негативными статусами;

2) признак того, что есть кредитные договоры с просрочками более 59 дней за последний год активности договора;

3) признак того, что есть кредитные договоры с просрочками 3059 дней более двух раз за последний год активности договора;

4) признак того, что есть кредитные договоры с просрочками 3059 дней более одного раза за последний год активности договора;

5) признак того, что есть кредитные договоры с просрочками 529 дней более трех раз за последние 12 месяцев;

6) признак того, что есть активные кредиты, выданные шесть и более месяцев назад, по которым клиент является заемщиком или созаемщиком.

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

 

Интерфейсы

 

Интерфейс пользователя

 

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

- производить запрос кредитной истории по одному субъекту в одно или несколько БКИ с определением режима использования кеша;

- просматривать полученные отчеты в унифицированном формате вне зависимости от источника(ов) сведений;

- получать отчет в виде печатной формы;

- осуществлять быстрый переход к оригинальным отчетам БКИ.

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

 

Веб-сервис

 

Для взаимодействия со смежными банковскими системами, такими как CRM, АБС и пр., в CRE предусмотрен интерфейс веб-сервисов, который в полной мере поддерживает функции Единого формата.

API веб-сервиса предусматривает ряд методов, ориентированных на унификацию и сведение.

 

Методы, ориентированные на унификацию и сведение данных

 

 

Метод processRequest позволяет произвести запрос в определенное БКИ. Результирующий отчет будет представлен в Едином формате. Метод позволяет определить глубину использования кеша, что обеспечивает возможность минимизировать запросы в БКИ в рамках внутренней политики банка.

Метод groupRequest используется для осуществления группового запроса в несколько БКИ. В ходе работы метода CRE осуществит серию запросов в указанные бюро (с помощью параметров вызова) и произведет унификацию и сведение результатов. Результатом работы метода будет отчет Единого формата. Аналогично методу processRequest метод groupRequest поддерживает возможность определения глубины использования кеша.

Метод joinUidResponses предназначен для сведения нескольких ранее полученных отчетов БКИ. В ходе работы метода никаких запросов в бюро не производится. При вызове следует указать список отчетов, которые будут сведены в один документ Единого формата.

Метод joinApplicationResponses по назначению аналогичен методу joinUidResponses, однако выбор отчетов осуществляется не по перечню, а по единому идентификатору кредитной заявки, в рамках которой ранее выполнялся групповой запрос в несколько бюро.

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

Каждый метод, помимо параметров аутентификации, принимает свой набор параметров, соответствующий семантике вызова. Все методы в качестве результата своей работы возвращают ответ, содержащий в себе следующее: уровень кеша, который использовался при запросе (поле cacheUse); дата и время создания отчета (поле created); уникальный идентификатор отчета (поле uid); идентификатор кредитной заявки, в рамках которой производился(лись) запрос(ы) (поле uidApplication); код отчета (поле reportCode); документ Единого формата (поле response). Данное поле содержит экранированный XML-документ, соответствующий схеме Единого формата с результатами унификации и сведения (для методов groupRequest, joinUidResponses и joinApplicationResponses).

Ниже приведен ряд сценариев применения функциональности сведения и унификации.

1. Потенциальный заемщик запрашивает кредит. Кредитный инспектор с помощью интерфейса пользователя (или CRM-система с помощью метода groupRequest веб-сервиса) запрашивает у CRE отчет. Система запрашивает кредитные истории во всех доступных БКИ, производит унификацию и сведение. На основе сведенного отчета кредитным инспектором принимается решение о предоставлении кредита.

2. Потенциальный заемщик запрашивает кредит. Фронтальная система банка последовательно запрашивает у CRE с помощью метода processRequest унифицированный отчет во всех доступных БКИ. Каждый раз фронтальная система анализирует ответ на определенные критерии, препятствующие выдаче кредита; в случае обнаружения такого стоп-фактора клиенту отказывается в получении кредита, а запросы в оставшиеся бюро не производятся. Если стоп-факторов нет, фронтальная система запрашивает у CRE сведение на основании кредитной заявки с помощью метода joinApplicationResponses. Кредитный инспектор анализирует сведенный отчет и принимает окончательное решение.

3. Потенциальный заемщик запрашивает крупный кредит. Кредитный инспектор производит запрос кредитной истории по одному из перечисленных выше сценариев. Кредит предварительно одобряется. Перед непосредственным перечислением средств клиенту производится повторная проверка. Осуществляется запрос к CRE с применением кеша; CRE, в соответствии с правилами повторного использования отчетов, при необходимости производит повторный запрос кредитной истории. На основании обновленного сведенного отчета принимается решение о выдаче денег.

4. ИТ-система службы безопасности с помощью метода joinUidResponses веб-сервиса получает унифицированный отчет по всем данным, которые имеются в системе.

 

Выводы

 

CreditRegistry Enterprise предоставляет удобный сервис унификации и сведения, доступный через различные интерфейсы. Сегодня это единственное промышленное решение, позволяющее автоматизировать работу с различными БКИ в соответствии с российским законодательством и прогнозируемым экономическим эффектом:

- нет необходимости обучать сотрудников специфической для каждого отдельного бюро форме отчетности;

- сотрудники банка могут сосредоточиться на анализе информации о клиенте и не тратить время на компиляцию сводного представления о состоянии дел клиента в уме;

- существует единая логика обработки кредитных историй;

- существует возможность простого расширения отчета;

- существует возможность дополнительной автоматизации процесса одобрения кредита;

- нет необходимости поддерживать форматы различных бюро. При расширении списка БКИ банку не требуется внедрение нового формата;

- за счет гибкой возможности повторного применения данных, получаемых от БКИ, банк может создавать сбалансированную политику пользования услугами различных бюро;

- сервис подчиняется стандартным единым правилам разграничения доступа и потому обеспечивает должный уровень безопасности;

- богатый набор интерфейсов взаимодействия позволяет применять CRE как на рабочем месте сотрудника банка, так и в ИТ-среде банка, включая SOA и базы данных.