Что такое pds в банке

Data Platform для целей формирования регуляторной отчетности

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

Совокупность этих факторов привела к изменению процессов управления данными. Data Platform – подход, который предлагает переосмысление традиционной концепции классического хранилища данных (КХД) с использованием технологий Big Data и новых подходов, применяемых при построении Data Lake платформ. Data Platform позволяет качественно учесть такие важные факторы, как рост количества пользователей, требования к time2customer (обеспечить возможность высокой скорости выполнения изменений), а также стоимость получаемого решения, в том числе, с учётом его дальнейшего масштабирования и развития.

В частности, предлагаем рассмотреть опыт автоматизации отчетности по РСБУ, налоговой отчетности и отчетности в Росфинмониторинг в Национальном Клиринговом Центре (далее – НКЦ).
Выбор архитектуры, позволяющей реализовать решение с учётом нижеизложенных требований, проходил крайне тщательно. В конкурсе участвовали как классические решения, так и несколько «бигдатных» – на Hortonworks и Oracle Appliance.

Предъявлялись основные требованиями к решению:

СУБД систем источников является Oracle, также источниками являются плоские файлы различных форматов и изображения (для целей налогового мониторинга), загрузка отдельной информации производится посредством REST API. Таким образом, появляется задача работы как со структурированными, так и с неструктурированными данными.

Рассмотрим подробнее области хранения данных Hadoop кластера:

Operation Data Store (ODS) – данные хранятся «as is» системы источника, в той же форме и формате, которые определены системой-источником. Для хранения истории по ряду необходимых сущностей реализован дополнительный архивный слой данных (ADS).

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

При обработке дельты (и поддержке историчности) в рамках кластера необходимо учитывать следующее:

Portfolio Data Store (PDS) – область, в которой подготавливаются и хранятся в унифицированном централизованном формате критичные данные, к которым предъявляются повышенные требования по качеству не только данных, но и структуры синтаксиса и семантики. Например, к данным относятся реестры клиентов, сделок, баланс и т.п.

Разработка ETL-процессов ведется на Spark SQL с помощью Datagram. Он относится к классу решений — «акселераторов», и позволяет упростить процесс разработки посредством визуального проектирования и описания преобразований данных с помощью привычного синтаксиса SQL – а в свою очередь, код самих джобов на языке Scala генерируется автоматически. Таким образом, уровень сложности разработки эквивалентен разработке ETL на более традиционных и привычных инструментах таких, как Informatica и IBM InfoSphere DataStage. Следовательно, это не требует дополнительного обучения специалистов или привлечения экспертов со специальными знаниями технологий и языков Big Data.

На следующем этапе рассчитываются отчетные формы. Результаты расчетов помещаются в витрины СУБД Oracle, где на базе Oracle Apex строятся интерактивные отчеты. На первый взгляд может показаться нелогичным использование коммерческого Oracle наряду с open-source технологиями Big Data. Исходя из следующих факторов, было принято решение использовать именно Oracle и Apex:

Поэтому, в случае необходимости расширения под новый класс задач, КХД зачастую сталкивается с фактически новым проектом внедрения с соответствующим T2C, в то время как в Data Platform все данные уже есть в системе и могут быть задействованы в любой момент времени без предварительной подготовки. Например, данные собираются из ODS, оперативно обрабатываются, «прикручиваются» к конкретной задаче и передаются конечному потребителю. Если непосредственное использование показало, что функционал корректен и применим в будущем, то запускается полный процесс, в рамках которого строятся целевые трансформации, подготавливаются или обогащаются портфели данных, задействуется слой витрин и строятся полноценные интерактивные отчеты или выгрузки.

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

Автор материала — Кристина Козлова, менеджер бизнес-направления Big Data Solutions компании «Неофлекс»

Источник

Списание денежных средств с кодом 4000 PDC Raiffeisen

Райффайзенбанк предоставляет финансовые услуги для физических и юридических лиц. Несмотря на долгий срок работы банка, многие его клиенты не понимают некоторые кодовые значения, которые получают в смс-уведомлении или указанные в выписке о движении средств по счету. Например, значение 4000 PDC Raiffeisen.

4000 PDC Raiffeisen — что это?

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

Причины списания

Причиной этому могут стать многочисленные основания, например:

В первом случае основанием может послужить задолженность по:

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

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

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

По приезду на территорию России было выявлено дополнительное списание штрафа, из-за чего баланс счета уходил в минус.

Дополнительной причиной может послужить разница в курсе валют (актуально при использовании счета за границей).

Например, была израсходована 1 тысяча долларов по курсу в 60 рублей, а на период снятия показатель составлял 63. Имеющаяся разница становится причиной дополнительного списания.

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

Что делать, если деньги списали 4000 PDC Raiffeisen

Обнаружив уведомление о списании 4000 PDC Raiffeisen, клиенты банковского учреждения часто не знают причин. В таком случае необходимо обратиться за помощью к уполномоченному менеджеру Райффайзенбанка:

Обращение в офис

В первом случае порядок действий включает в себя:

В заявлении нужно указывать:

На основании сформированного запроса будет произведена проверка, по завершению которой выдается соответствующий ответ.

Обращение через интернет

При обращении через интернет, необходимо:

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

Однако, часто клиентам рекомендуют обратиться лично в филиал банка с паспортом и написать письменное заявление.

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

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

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

Источник

Аутстаффинг, аутсорсинг и PDS: преимущества и различия

Терминология — штука непростая. Одни и те же слова могут означать совсем разные вещи в разных организациях. В Украине большинство малых и средних IТ-компаний называют себя «IT-аутсорсерами». Между тем, крупные и государственные компании, как правило, позиционируют себя не как IТ-аутсорсинг, а, скорее, как компании, работающие в областях разработки продуктов и управляемых услуг – Product Development Services.

Со временем даже небольшие компании постепенно стали позиционировать себя как «разработчики ПО на заказ» (Custom Software Development), заменив этим «аутсорсинг».

Итак, давайте разберемся, что к чему, базируясь на наших знаниях об IT-сфере и IT-рынке.

Я имел удовольствие работать в нескольких компаниях, в том числе, в стартапах, в очень маленьких частных IT-аутсорсерах и на крупных предприятиях с десятками тысяч человек на борту.

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

Давайте посмотрим на сводную таблицу, а позже пройдемся по каждой категории.

Это вид сотрудничества наиболее прост для понимания. Клиент испытывает нехватку рабочей силы и нуждается в большем количестве сотрудников для выполнения работы. Задача клиента — увеличить производительность команды. Поэтому клиент нанимает сотрудников из офшорной компании для ускорения процесса разработки.

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

Ответственность за качество

Аутсорс проекты также часто называют «дополнением персонала» (Staf Augementation).

Поставщик пополняет существующую команду клиента своими сотрудниками. Ответственность за сроки, качество и бюджет несет менеджер. А менеджер — сотрудник компании клиента.

Модель аутстаффинга работает по схеме обмена «время на деньги». Оплата может быть организована в виде почасовых тарифов, или в виде модели Cost+. Клиенты покупают час работы, а продавец получает прибыль от проданных часов.

Ключ к получению большего дохода в области аутстаффинга — продажа большего количества часов. Например, имея больше людей в наличии.

Чем больше людей, тем больше денег.

Источник дохода — трудовые ресурсы.

Аутсорсинг — передача одной из бизнес-функций стороннему провайдеру. Компания может передать на аутсорсинг свое производство, бухгалтерский учет, разработку, тестирование, поддержку или центр обработки звонков и т. д.

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

Управление аутсорс проектом может иметь сложную структуру. Как правило, частично управление осуществляется на стороне клиента (управление продуктами, программами), а частично — на стороне поставщика (менеджер проекта, тимлид, Proxy Product Owner).

Ответственность за качество

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

Здесь действует то же правило: чем больше людей, тем больше денег. Но для поставщика, лучше не ограничиваться только этим правилом. Процессы, методологии разработки, готовые решения, автоматизация и многое другое — все это ускорители решений (Solution Accelerators). Внедряя стандарты и автоматизацию стандартных решений, компания может избежать повторного изобретения велосипеда для множественных проектов. Все это именуется термином «операционная эффективность» (operational excellence). Сокращение расходов при повышении операционной эффективности дает дополнительную прибыль.

Другими словами, при правильном подходе, для заказчика не будет разницы, если разработчик Иван выйдет из проекта, а QA-специалист Петр автоматизирует свои тесты. Пока команда разработчиков обеспечивает результаты, которые она должна обеспечивать, никого не волнует, как это делается.

Источник дохода — операционное совершенство.

Когда я впервые познакомился с термином «Услуги по разработке продуктов» (Product Development Services, PDS), я работал в IT-компании со штатом более 10 000 сотрудников. Компания инициировала серию событий для ознакомления сотрудников с моделью PDS Delivery. Одним из примеров для разработчиков было: «Вы перестаете думать, что бизнес заказчик хочет, чтобы эта кнопка была красного цвета, он платит – мы перекрашиваем. Вы начинаете думать, как конечный пользователь хотел бы использовать эту кнопку. И исходя из этого, советуетесь с заказчиком, как изменение цвета кнопки повлияет на комфорт конечного пользователя от работы с продуктом».

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

Чтобы иметь возможность предоставлять услуги по разработке продуктов (PDS), компания-поставщик должна наработать опыт и знания в области бизнес-анализа, управления проектами, управления продуктами (Product Ownership) и знание отраслей (domains), в которых работают клиенты.

Поэтому на PDS проектах, как правило, есть роли Проектного менеджера, Владельца продукта (Product Owner), Архитектора, Руководителей направлений (QA Lead, DevOps Lead и т. д.). В некоторых случаях эти роли могут дополнять или зеркально отображать соответствующие роли на стороне клиента. В других случаях эти роли позиционируют как роли со стороны поставщика, заказчик только формулирует бизнес-задачу. Вендор сам превращает ее в требования, помогает с анализом рынка, строит архитектуру, процесс разработки и контроля качества и т. д.

Кроме того, компания получает возможность создавать центры компетенций и доменные практики. Люди в них могут работать не в рамках конкретного проекта или группы проектов. Основная задача практик и центров компетенции — приобретать и развивать знания в конкретных областях. Например, медицина, автомобилестроение, электронная коммерция, банкинг (Health Care, Automotive, e-Commerce, Finance and Banking)

Это дает компании-поставщику гораздо больше свободы. Команды могут организовать удобные процессы, выбирать и адаптировать свои методологии.

Ответственность за качество

Когда управление продуктами (Product Management) и проектами (Project Management) осуществляется на стороне поставщика, это означает не только свободу, но и полную ответственность за поставку программного продукта включая соблюдение сроков, бюджетов и уровня качества. Таким образом, ответственность за качество лежит на поставщике.

В PDS-проектах компания по-прежнему зарабатывает больше денег, имея больше людей. Но это становится побочным эффектом. Источник дохода — интеллектуальный продукт. Он может принимать разные формы, например, более высокие почасовые тарифы (рейты) для инженеров с более высокой квалификацией и/или дополнительными знаниями в индустрии и бизнесе. Или в форме фаз и сервисов, генерирующих интеллектуальный продукт. Например, фазы проектирования (Solution Design), бизнес-анализа, аудита, а также сервисы разработки, тестирования, поддержки (support and maintenance).

Как правило, чем больше рисков и ответственности берет на себя поставщик, тем выше его прибыль.

Будучи IT-компанией, мы являемся поставщиком для наших клиентов, поставщиком IT-услуг. Существует классическая категоризация поставщиков.

Давайте на нее посмотрим.

(Commodity) Сырьевые, широкого потребления: для поставщиков, предоставляющих недорогие или легкодоступные продукты или услуги, которым легко найти альтернативу.

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

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

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

Занимаясь аутстаффингом, поставщик попадает в категорию Commodity — сырьевой поставщик, или поставщик продуктов / услуг широкого потребления. Серьезные риски отсутствуют, и альтернативы могут быть найдены и задействованы достаточно быстро. Аутсафинговая компания, по факту, покупает час работы у программиста и продает этот час со своей маржей клиенту.

Аутсорсинг-компания может быть и операционным, и тактическим поставщиком, в зависимости от уровня вовлечения (влияния) и важности для бизнеса клиента. Чем больше ответственности и рисков поставщик готов брать на себя, тем выше его важность и влияние на бизнес заказчика, тем ближе он к стратегическому партнерству.

Зрелые IT-компании стремятся внедрять PDS- и Managed Services-подходы, потому что стремятся достичь стратегического партнерства с клиентами, стать технологическими партнерами для бизнеса, а не поставщиками трудовых ресурсов.

Пребывание в категории commodity ограничивает цены (и, в свою очередь, заработную плату). Они не могут быть выше рыночной. Множество поставщиков аутстаффинга в погоне за максимальными доходами исчерпывают рынок труда и снижают критерии для входа в профессию. Именно это и происходит на украинском рынке труда в индустрии IТ.

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

В менеджмент— улучшать организационную и управленческую культуру. Инвестировать в обучение руководителей, изучение методологий и лучших практик (best practices).

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

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

Цена этому – принимать риски и нести ответственность за результат.

Надеюсь, вам понравилась статья. Полностью охватить такую широкую тему в одной статье непросто. Пожалуйста, поделитесь своим опытом, вопросами и комментариями. Обратная связь всегда вызывает интерес и мотивирует.

Источник

ML и DS оттенки кредитного риск-менеджмента | Компоненты

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

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

За подробностями добро пожаловать под кат.

PD или как ковер задает стиль всей комнате

Определение дефолта

Начнем с главной компоненты, которую необходимо оценивать (например, в случае базового или продвинутого ПВР) PD (a. k. a. probability of default) – вероятность дефолта клиента. В качестве свидетельства о дефолте клиента могут выступать разные события в кредитной истории. Часто – это просрочка платежа по кредитному договору 90 и более дней.

Для подсчета количества дней просрочки существует два метода: LIFO (last in first out) и FIFO (first in first out) [1]:

Для определения дефолта необходимо задать следующие три атрибута:

Но этого недостаточно для формирования целевого события. У целевого события есть еще один важный атрибут: горизонт сбора информации о дефолте, или горизонт моделирования.

Определение длины горизонта

Информация о дефолте используется для оценки ожидаемых потерь, под которые банк осуществляет резервирование. В этом случае возникает вопрос, а на каком периоде смотреть выходы в дефолт? Важно ли это? С точки зрения бизнеса, важно понимать период планирования, с точки зрения моделей мы хотим выбрать такой период, в котором будет охвачено не менее 80%-90% всех возможных выходов в дефолт для всех открытых и не находящихся в дефолте договоров на текущий момент времени.

Для целей выбора длины горизонта может быть использован винтажный анализ [2]. Он заключается в построении графической аналитики и последующего вывода о данных по ней. График может быть построен так:

При построении графика выше для каждой когорты было рассчитано значение, составляющее 80% от максимального числа наблюдений, вышедших в дефолт, а диапазон полученных значений обозначен серой полосой. По графику можно сделать вывод о том, что оптимальная длина горизонта лежит в интервале 6-8 месяцев.

Сегментирование выборки

Некоторые атрибуты настолько сильно коррелируют с целевой переменной, что вклад остальных практически нивелируется. Это приводит к моделям с плохим ранжированием внутри группы с одинаковым значением «главного» атрибута. Во избежание такой ситуации используют подход сегментации, в рамках которого выборку делят на два или несколько сегментов — по одному на каждое значение «главного» атрибута (драйвера), и для каждого из них строят отдельную модель. В кредитном риске один из таких драйверов – наличие или длительность просрочки по платежу.

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

Альтернативно можно разделить выборки на сегменты с просрочками за историю (I) и без просрочек за историю (II).

Необходимое условие для сегментации – достаточное количество дефолтных наблюдений в каждом из сегментов. А для того, чтобы выяснить целесообразность и границы новых сегментов используется roll-rate анализ [3]. Он заключается в разделении выборки на подсегменты на основании значений величины текущей просрочки и сравнении между ними среднего уровня дефолта. Те группы, уровень дефолта которых значимо различается, имеет смысл моделировать по отдельности.

Рассмотрим, например, сегментацию наблюдений по величине просрочки. На картинке ниже в качестве примера выделены следующие 5 сегментов, соответствующих интервалам (бакетам) значений просрочки: 0-4 дня, 5-14 дней, 15-29 дней, 30-59 дней, 60-89 дней. Эти сегменты рассматриваются в нескольких моментах времени: HY1_2015, HY2_2015 — соответственно, первое и второе полугодия 2015 года, HY1_2016, HY2_2016 — соответственно, первое и второе полугодия 2016 года. В процессе анализа нас интересует динамика выхода наблюдений в просрочку более 89 дней, поэтому для каждого из этих сегментов подсчитан процент клиентов, просрочка которых на горизонте наблюдения составила более 89 дней.

По графику можно сделать следующие выводы:

EAD (Деньги в дефолте)

После того, как оценена вероятность дефолта заемщика, ставится вопрос – с какой суммой задолженности заемщик уйдет в дефолт? Эта сумма линейно влияет на размер ожидаемых потерь и, соответственно, объем резервов, и называется exposure at default – требования в дефолте. Итак, EAD – exposure at default – кредитные обязательства по договору на момент дефолта.

Напрямую, как правило, EAD не моделируют. Так как эта величина – денежная, её распределение не носит нормальный характер: в выборке могут присутствовать наблюдения очень большие и очень маленькие, не являющиеся при этом аномалиями. В зависимости от специфики портфеля можно выбрать разные целевые переменные – об этом подробнее будет сказано в последующих статьях цикла, но наиболее широко используемая – CCF – credit conversion factor – коэффициент кредитной конверсии – вычисляется следующим образом:

где:
Balance – сумма средств, которые клиент должен банку в момент наблюдения,
Limit – доступный клиенту лимит,
EAD – сумма средств, который клиент должен банку в момент дефолта.

Получается, что CCF – это та часть доступных на момент наблюдения средств, которая будет использована клиентом к моменту дефолта.

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

Все описанное выше касалось денег до дефолта и во время него. А что происходит сразу после? Об этом компонента LGD.

LGD («Где деньги, Лебовски?»)

Даже в случае дефолта заемщика, часть средств возвращается в банк:

Поскольку временной интервал, на котором происходит т.н. «восстановление» (возвращение долга), может варьироваться поклиентно, возникает необходимость определить длину горизонта восстановления, на котором будет рассчитываться целевая переменная. На длину горизонта влияет в первую очередь доступность достаточного временного периода в данных для моделирования. Обычно длина горизонта лежит в диапазоне 3-5 лет после дефолта.

В общем случае LGD рассчитывается формуле:

где:
Ri – денежный поток от клиента (выплаты, реализация залога и др.), полученный на горизонте восстановления после дефолта,
T – временной период от момента учета возмещения после момента дефолта (в годах).

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

Суммы возмещения, затрат и продажи долга при дисконтировании умножаются на «фактор дисконтирования» [4] P(T):

T – временной период от момента учета возмещения после момента дефолта (в годах),
r – ставка дисконтирования.

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

С компонентами, в первом приближении, понятно: все разные, а моделировать их нужно вместе! Есть ли какой-то подход, который позволит более-менее единообразно отобрать переменные для моделей и выбрать наиболее оптимальную комбинацию? Можно попробовать. О возможном варианте далее.

«Великолепный план, Уолтер … надёжный как … швейцарские часы» или pipeline разработки

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

Подготовка данных

Подготовка данных включает в себя формирование трёх сущностей: наблюдения (сегмент), витрина дефолтов, витрина атрибутов,- с единым внешним ключом — ID заемщика или договора и временная метка.

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

Каждое наблюдение – ID заемщика или договора и временная метка; другими словами, нас интересует состояние заемщика или договора на конкретную дату. Обычно используются наблюдения, соответствующие временным срезам, отстоящим друг от друга на равные промежутки времени (например, квартальным).

В случае задачи резервирования объем данных должен включать в себя полный экономический цикл, что составляет примерно 5-7 лет.

Для формирования выборки необходимо учитывать горизонт.

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

Из-за необходимости учитывать период сбора, оптимальная глубина данных составляет 2-3 горизонта наблюдения.

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

В таблице под катом перечислены основные группы и примеры атрибутов широкого списка переменных.

Один из способов увеличения интерпретируемости и стабильности модели – это использование в качестве атрибутов не абсолютных значений признаков, а относительных: нормированных, например, на доход (выручку) или отражающих тренд/динамику показателя на временном интервале.

Однофакторный анализ

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

Для проведения однофакторного анализа необходимо разбить выборку на выборки для разработки (train) и тестирования (test). Выборка для тестирования может быть сформирована одним из следующих способов:

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

Многофакторный анализ и финальная модель

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

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

Две самые распространенные модели для прогноза вероятности дефолта – это:

где:
DistrGood – отношение числа недефолтных наблюдений, имевших значение атрибута из данного бина, к общему числу недефолтных наблюдений;
DistrBad – отношение числа дефолтных наблюдений, имевших значение атрибута из данного бина, к общему числу дефолтных наблюдений.

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

Одним из недостатков подхода с использованием значений WOE вместо реальных значений атрибута являются потенциально возможные скачки значений вероятности дефолта (PD). Для решения указанной проблемы может использоваться сглаживание порогов функции WOE с целью создания непрерывных «плавных» переходов между соседними значениями WOE. Чаще всего сглаживание может производиться с помощью сигмоиды или гиперболического тангенса.

После описанных выше преобразований над атрибутами модель логистической регрессии строится над преобразованными атрибутами. Для выбора оптимальной комбинации факторов может быть использовано несколько подходов: [6]:

При построении модели в качестве оптимизируемой метрики могут быть использованы информационные критерии (например, SBC [8], AIC [9]). Разбиение атрибутов на группы и расчет значений WOE производится на выборке для разработки, а затем сформированный биннинг и соответствующие ему значения WOE транслируются в выборку для тестирования.

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

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

Сводная таблица по компонентам

Выводы

Итак, в статье мы провели детализацию особенностей моделирования компонент ожидаемых потерь: PD, LGD и EAD.

Главный вывод можно сформулировать следующим образом: прежде чем мы дойдем до import xgboost as xgb ML необходимо существенную часть времени потратить на аналитику и учитывать особенности бизнес-процессов при разработке и тестировании модели. Формулу для DS, применительно к нашим компонентам, можно записать в следующем виде:

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

Авторы статьи: Александр Бородин (abv_gbc), Алиса Пугачёва (alisaalisa),
Артём Савинов (artysav), Илья Могильников (eienkotowaru).

Список использованных терминов и сокращений

Источник