Что такое скоринг тинькофф

Обновлено: 18.04.2024

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

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

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

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

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

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

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

Последний шаг — зарегистрироваться на сайте БКИ и подтвердить личность через госуслуги, если сайт вам это предложит. Так как еще не у всех бюро работает подтверждение личности через госуслуги, возможно, придется пройтись по нескольким сайтам из списка ваших БКИ.

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

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

Задача нетривиальная и может быть решена множеством способов, в чем мы убедились на демонстрации финальных презентаций проектов участников. На хакатоне было 6 команд по 5 человек, у всех участников были хорошие проекты, но наша платформа оказалась наиболее конкурентоспособной. У нас получился очень интересный проект, о котором я хотел бы рассказать в данной статье.

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

Что такое скоринг

Например, клиент обращается к нам с просьбой выдать ему кредит, или открыть у нас счет ИП. Если мы планируем выдать ему кредит, то нужно оценить его платежеспособность, а если счёт ИП, то нужно быть уверенными что клиент не будет проводить мошеннические операции.

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

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

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

Для поставленной задачи у нас уже используется специализированная система принятия решений IBM WebSphere ILOG JRules BRMS, которая, на основе заданных аналитиками, технологами и разработчиками правил решает, одобрить тот или иной банковский продукт клиенту или отказать.

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

Поставленная задача

Хакатон проводился 23 февраля. Участникам была предложена боевая задача: разработать систему принятия решений, которая должна была соответствовать ряду условий.

Нам рассказали, как функционирует существующая система и какие сложности возникают при ее эксплуатации, а также какие бизнес-цели должна преследовать разрабатываемая платформа. У системы должен быть быстрый time-to-market разрабатываемых правил, чтобы рабочий код аналитиков попадал в продакшн как можно быстрее. А для входящего потока заявок время принятия решения должно стремиться к минимуму. Также разрабатываемая система должна иметь возможности cross-sell, чтобы давать клиенту возможность приобрести другие продукты компании в случае их одобрения с нашей стороны и потенциальной заинтересованности со стороны клиента.

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

Что касается технологий, то тут всем участникам была предоставлена полнейшая свобода выбора. Можно было использовать любые концепции и технологии: Data streaming, machine learning, event sourcing, big data и другие.

Наше решение

Проведя небольшой мозговой штурм мы решили, что для выполнения поставленной задачи идеально подойдет FaaS решение.

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

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

Аналитик пишет скрипт, правило, или ML модель, основываясь на данных из хранилища. В рамках хакатона мы решили использовать Mongodb, но выбор системы хранения данных здесь не принципиален.
После тестирования разработанных правил на исторических данных, аналитик заливает свой код в админку.
С целью обеспечения версионирования весь код будет попадать в Git-репозитории.
Через админку можно будет развернуть код в облаке как отдельный функциональный Serverless модуль.

Еще до хакатона мы определились с Serverless-фреймворком, который будем использовать. На сегодняшний день на рынке довольно много технологий реализующих данный подход. Наиболее популярными решениями в рамках Kubernetes архитектуры являются Fission, Open FaaS и Kubeless. Есть даже неплохая статья с их описанием и сравнительным анализом.

Взвесив все плюсы и минусы мы остановили свой выбор на Fission. Данный Serverless-фреймворк довольно прост в управлении и удовлетворяет требованиям поставленной задачи.

Для работы с Fission необходимо понимать две основные концепции: function и environment. Функцией (function) является кусок кода написанный на одном из языков для которого есть Fission-окружение (environment). Список реализованных в рамках данного фреймворка окружений включает в себя Python, JS, Go, JVM и множество других популярных языков и технологий.

Также Fission способен выполнять функции, разбитые на несколько файлов, предварительно упакованные в архив. Работа Fission в кластере Kubernetes обеспечивается специализированными подами, управление которыми берет на себя сам фреймворк. Для осуществления взаимодействия с подами кластера, на каждую функцию необходимо назначить свой роут, и в который можно передавать GET параметры или request body в случае POST запроса.

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

В предложенном нами решении отсутствует необходимость релиза правил, код легко разворачивается по одному нажатию кнопки. Так же управление инфраструктурой в Kubernetes позволяет не думать о нагрузке и масштабировании, подобные проблемы решаются «из коробки». А использование единого хранилища данных избавляет от необходимости сопоставления real-time данных с историческими, что упрощает работу аналитика.

Что у нас получилось

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

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

Архитектура нашего проекта была следующей:

На данной схеме указаны две точки входа, аналитик (основной пользователь нашей системы) и клиент.

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

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

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

Фронтенд у нас был написан на Angular 7 с использованием банковского UI Kit. Финальный вариант админки выглядел следующим образом:

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

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

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

Бэкенд платформы был написан на Java и реализован как Spring Boot приложение. Для хранения данных админки мы изначально планировали использовать Postgres, но, в рамках хакатона, решили ограничиться простеньким H2, в целях экономии времени. На бэке была реализована интеграция с Bitbucket, для версионирования функций обогащения запросов и скриптов правил. Для интеграции с удаленными Git репозиториями использовалась библитека JGit, которая является своего рода оберткой над CLI командами, позволяющая исполнять любые git инструкции, используя удобный программный интерфейс. Так у нас было два отдельных репозитория, для функций обогащения и правил, а все скрипты разложены по директориям. Через UI можно было выбрать последний коммит скрипта произвольной ветки репозитория. При внесения правок в код через админку в удаленных репозиториях создавались коммиты измененного кода.

Для реализации нашей идеи нам была необходима подходящая инфраструктура. Мы приняли решение развернуть наш Kubernetes кластер в облаке. Наш выбор остановился на Google Cloud Platform. Serverless-фреймворк Fission был установлен в кластере Kubernetes, который мы развернули в Gcloud. Первоначально сервис обогащения исходных данных был реализован отдельным Java-приложением обернутым в Pod внутри кластера k8s. Но после предварительной демонстрации нашего проекта в середине хакатона, нам порекомендовали сделать Enrichment сервис более гибким, чтобы предоставить возможность выбирать, как обогащать сырые данных входящих заявок. И нам ничего не оставалось, кроме как сделать сервис обогащения также Serverless.

Для работы с Fission мы использовали Fission CLI, которую необходимо устанавливать поверх Kubernetes CLI. Деплой функций в k8s кластер довольно прост, необходимо лишь назначить для функции внутренний роут и ingress для разрешения входящего трафика, если необходим доступ вне кластера. Развертывание одной функции как правило занимает не более 10 секунд.

Финальный показ проекта и подведение итогов

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

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

Клиент помимо отказа или одобрения также получал список других продуктов, запросы на которые мы отправляли параллельно. Так мы продемонстрировали возможность cross-sale в нашей платформе.

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

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

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

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

Знакомьтесь: библиотека TiRecycler

Всем привет! Меня зовут Александр Гузенко, и в Тинькофф я занимаюсь всякими техническими вещами вроде CI/CD, gradle и внедрением новых подходов. Хочу рассказать вам про библиотеку, которую мы создали в команде Тинькофф Бизнеса, когда столкнулись с многословными адаптер-делегатами.

Дополнительные временные ряды в ETNA

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

Использование Gatling. Тестирование gRPC

Всем привет! Команда тестирования производительности Тинькофф продолжает цикл статей о нагрузочном тестировании различных протоколов с помощью Gatling.

Gatling. Тестирование JDBC

Тинькофф Инвестиции про новую версию API и конкурс торговых роботов

Привет! На связи команда Тинькофф Инвестиций. Мы запустили новую версию программного интерфейса для алгоритмического трейдинга. Расскажем про Tinkoff Invest API и что новенького в сервисе.

Как мы научили «AI да Пушкин» создавать стихи и какие еще технологии использовали

Привет! Недавно мы представили проект «AI да Пушкин». Благодаря нейросетям поэт генерирует четверостишия по первым словам, которые предлагает пользователь. А затем читает вслух то, что получилось. Увидеть и услышать, как это происходит, можно на сайте проекта. А мы расскажем, как решили проблему отсутствия рифмы с помощью контролируемой генерации текста и какие технологии использовали, чтобы сделать проект более эффектным.

Как мы ускоряли е2е-тесты на Cypress в GitLab

Всем привет! На связи Николай Мезинов, разработчик фронтенда в продуктовой команде DevPlatform. Хочу поделиться опытом, как мы ускоряли прохождение e2e-тестов на Cypress в пайплайнах GitLab.

Как сделать инициирующую загрузку в NiFi

Давайте поговорим про Apache NiFi. Этот ETL-инструмент все чаще используют при загрузке данных в хранилище, правда, не всегда по назначению. Об одном из таких сценариев я рассказывал на конференции SmartData. Видео можно посмотреть на Ютубе, но я все равно рекомендую вам прочитать этот текст: здесь я собрал новые мысли и идеи. Речь пойдет об инициирующей загрузке, или перегрузке данных из источника.

Всем привет! Это команда тестирования производительности Тинькофф, и мы продолжаем цикл статей о Gatling.

Как сохранять историю процессов в Camunda без вреда для них

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

Как прогнозировать временные ряды с ETNA

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

[Под катом много картинок и GIF]

Использование Gatling. Введение

Привет! Мы — команда тестирования производительности в Тинькофф, и мы любим инструмент Gatling. В цикле статей мы расскажем об использовании Gatling и дополнительных инструментов, упрощающих разработку скриптов.

Возможно, вы уже читали наши статьи про Gatling: первую и вторую. Они успели устареть, поэтому мы решили вернуться с обновленной информацией.

Зачем системному аналитику читать «Чистую архитектуру» Роберта Мартина

Меня зовут Сергей Марков, я системный аналитик бэковой части в Академии Инвестиций Тинькофф.

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

Кто такой data-инженер в Тинькофф и как им стать

Привет! Меня зовут Михаил Иванов, я работаю архитектором DWH в Тинькофф и занимаюсь развитием Batch ETL направления платформы обработки данных. Я расскажу о направлении data engineering в Тинькофф, о том, чем занимаются data-инженеры и как попасть к нам в команду.

100 символов, или Как влияет длина строки на читаемость текста

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

Роберт Брингхерст в книге «Основы стиля в типографике» говорит, что оптимальное значение длины строки составляет от 45 до 75 знаков. 66 — идеальный вариант, а для многоколонного набора — 40—50 знаков.

Максим Ильяхов пишет, что за максимум берет 75 знаков, — столько помещается на страницу А4 с полями при наборе 12-м кеглем.

Smashing Magazine в 2009 году провели исследование и выяснили, что средний результат символов на строку равен 88,74, а среднее значение изменяется от 75 до 85.

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

Кредитный рейтинг и кредитную историю часто путают. Поясню, почему это не одно и то же и чем они отличаются.

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

Пример отчета. Сама кредитная история состоит из четырех частей:

В титульной части указаны стандартные общие данные о субъекте кредитной истории: ФИО, паспортные данные, ИНН и СНИЛС.
В основной — сведения о текущих кредитах и вступивших в силу решениях суда о взыскании денежных средств, о банкротстве, а также скоринговый балл заемщика, если БКИ его рассчитывает.
В информационной части — какие заявки подавал человек на кредит и результат рассмотрения: выдан кредит или нет.
Закрытую часть видит только заемщик. В ней указаны все, кто когда-либо запрашивал кредитную историю субъекта и кто передавал в нее информацию.

На основе кредитной истории формируется кредитный отчет, который отражает ее содержание.

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

Как формируется рейтинг

Единой формулы расчета или требований к кредитному рейтингу нет, каждое бюро рассчитывает его исходя из своих критериев. Это связано с тем, что сейчас в РФ действует сразу несколько БКИ. Организации, которые обязаны передавать информацию в БКИ, должны сотрудничать хотя бы с одним бюро. С каким именно — каждый кредитор решает сам. При этом некоторые организации передают информацию сразу в несколько бюро — ограничений тут нет.

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

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

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

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

Мой кредитный рейтинг, по данным «Эквифакса», составляет 591 балл. Это очень плохо. Связано это с тем, что я никогда не оформляла кредиты, при этом в моей кредитной истории есть одна заявка с отказом

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

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

Что означают баллы рейтинга

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

Шкала «Эквифакс». По шкале БКИ «Эквифакс» можно набрать от 0 до 999 баллов.

Шкала кредитного бюро «Русский стандарт». В этом бюро присваивается от 0 до 620 баллов. В кредитном рейтинге этого БКИ есть рекомендации в зависимости от того, какой рейтинг получил человек. При этом по поводу части рекомендаций есть вопросы.

Например, некоторые банки обращают внимание, где именно заемщик берет займы. Если клиент обращается за займом в МФО, некоторые банки могут оценивать это негативно: если потенциальный клиент обращается за деньгами на короткий срок, возможно, у него проблемы и не стоит ему выдавать кредит.

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

выше 961 балла — очень высокий рейтинг;
801—960 — хорошая кредитная история;
721—800 — нормальная кредитная история;
641—720 — плохая кредитная история;
ниже 640 — очень плохая кредитная история.

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

В НБКИ шкала баллов до 850. Мой кредитный рейтинг не рассчитывается из-за отсутствия кредитной истории в этом бюро, поскольку недавно я поменяла паспорт. По новым паспортным данным никакой информации обо мне нет — с момента, как я получила новый паспорт, ни одна организация не запрашивала доступа к моей кредитной истории

На что влияет рейтинг

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

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

Как узнать кредитный рейтинг

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

Посредники сделают запрос в Центральный каталог кредитных историй, узнают, в каких БКИ хранится ваша кредитная история, и выдадут один или несколько отчетов. Если решите действовать самостоятельно — сначала придется узнать, в каких кредитных бюро есть ваша кредитная история. О том, как это сделать, мы рассказывали.

Через госуслуги. Если у вас есть учетная запись на госуслугах, зайдите на портал и закажите список БКИ, где хранится ваша история. Саму кредитную историю заказать на госуслугах нельзя.

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

Проверка в НБКИ. Кредитный рейтинг можно узнать бесплатно в личном кабинете на сайте бюро.

Проверка в ОКБ и «Эквифаксе». Эти бюро указывают кредитный рейтинг в кредитном отчете, поэтому два раза в год его можно получить бесплатно. Для этого их надо заказать на сайте бюро. Также «Эквифакс» дублирует информацию в личном кабинете на своем сайте и там же дает расшифровку текущей оценки.

Проверка в КБРС. Предоставляет кредитный рейтинг по запросу за отдельную плату или при заказе кредитного отчета.

Стоимость проверки

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

Стоимость проверки в разных БКИ. В НБКИ кредитный рейтинг можно бесплатно посмотреть в личном кабинете. За 699 рублей можно увидеть, как менялся кредитный рейтинг за последний год.

БКИ «Эквифакс» указывает кредитный рейтинг в личном кабинете у себя на сайте, а также его можно увидеть в кредитном отчете.

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

Узнать свой кредитный рейтинг в КБРС можно за 40 Р . Для этого нужно зайти в личный кабинет с помощью учетной записи на госуслугах.

Мой кредитный рейтинг в личном кабинете «Эквифакса» сейчас выглядит так. Я никогда не оформляла кредит, но у меня висит один отказ в кредите еще с 2016 года. При подаче заявки я допустила опечатку в данных, и пришел отказ

Как повысить кредитный рейтинг

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

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

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

В любом случае решать, выдавать кредит или нет, будет банк, а не БКИ. И он принимает решение не только на основании кредитной истории, но и на основе других факторов.

•Совет директоров в качестве дивидендов за 2021 г. рекомендовал выплатить 0,64₽ на 1 акцию. Открыв данную акцию в приложении —> вкладка Дивиденды, мы с Вами увидим, что ❗последним днем покупки акций $ SGZH

📌4 причины, почему стоит сохранить валютные фонды Сегодня Мосбиржа возобновила торги четырьмя нашими валютными фондами: Тинькофф Semiconductors, Тинькофф CyberSecurity, Тинькофф BuyBack Leaders и Тинькофф AI-Robotics. 🧐Рассказываем, почему стоит сохранить валютные фонды в своем портфеле: 1. Полупроводники ( $ TSOX

) по-прежнему остаются одним из самых перспективных направлений для инвестиций, так как глобальный дефицит полупроводников, как ожидается, будет устранен не раньше 2023 года. Это же относится и к сфере кибербезопасности ( $ TCBR

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

ЧТО НУЖНО ЗНАТЬ ПРО ГАЗ?👨‍🏫 📝Природный газ – газообразное ископаемое топливо, которое состоит почти полностью (70-98%) из метана (СН4) и других примесей – этана, пропана, бутана, пентана, гелия, водорода, сероводорода и др. Это важное топливо для электрогенерации, а также сырье для газохимии. Считается наиболее экологичным ископаемым топливом, поскольку при сгорании выделяет наименьшее количество парникового углекислого газа и других веществ. 📝СПГ (сжиженный природный газ) – производится на специальных заводах путем охлаждения природного газа до -162 градусов по Цельсию. Крупнейшие производители и экспортеры СПГ – Катар, США, Австралия. СПГ транспортируется в специальных кораблях – танкерах, которые поддерживают температуру и жидкое состояние топлива. Однако оно все равно испаряется – и этот газ используется для питания танкера. СПГ мобильнее трубопроводного газа, который может поставляться по газотранспортной системе. Нередки случаи, когда СПГ-танкеры в море в течение короткого времени несколько раз меняют владельцев и точки назначения в ходе трейдинга. Как правило, стоимость СПГ выше за счет дороговизны производства, издержек на транспортировку и регазификацию в точке назначения. 📝КПГ (компримированный природный газ) – сжатый природный газ, который используется в транспортных средствах. 📝ПХГ (подземное хранилище газа) - важный объект газовой инфраструктуры, предназначенный для хранения топлива, которое позволяет «сглаживать» колебания в уровнях потребления. Хранилища оборудуются в отработанных газовых месторождениях, выработанных подземных залежах угля, солевых пластах, пористых породах. 📝СУГ (сжиженные углеводородные газы) – это смесь пропан-бутан. СУГ – это тоже топливо, но не является природным газом. Это продукт газопереработки. СУГ взрывоопаснее, чем газ, поскольку «стелется» по земле и может накапливаться в углублениях. В то же время обычный метан быстро улетучивается в атмосферу. 🤓Интересный факт: крупнейшим потребителем газа в России является сама газотранспортная система (ГТС), состоящая из газопроводов, хранилищ, компрессоров, газоизмерительных и газораспределительных станций $ GAZP

Экономические кризисы за последние 20 лет уже не в новинку. Возникают они неожиданно, вроде бы похожи друг на друга и каждый раз вызывают у простых людей раздражение действиями политиков и экономистов. Неужели так сложно подготовиться к кризису?

Автор статьи

Куприянов Денис Юрьевич

Юрист частного права

Страница автора

Читайте также: