[Data Mining, Машинное обучение, Искусственный интеллект, Финансы в IT, Data Engineering] Специфические задачи Data Science в Банке
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В течение последних пяти лет я проработал в Центральном Аппарате Сбербанка в Управлении Валидации моделей машинного обучения (machine learning, ML) и видел много «узких мест», которые возникают при разработке и валидации моделей машинного обучения.
В этой статье сначала предполагал рассмотреть основные информационные системы некоторого абстрактного Банка X, поскольку именно на базе уже сложившихся информационных систем строится работа дата-аналитиков, а также обучаются и работают ML-алгоритмы принятия решений. Но, когда начал писать, вдруг обнаружил, что на самом деле намного интереснее обсудить ряд тем и подзадач, которые всплывают при построении и валидации самых базовых моделей Банка, то есть моделей кредитного риска.
Риск-менеджмент и расчет кредитного риска можно считать прародителями data science в Банке, так как управление кредитным риском является исконно банковской прерогативой. Именно умелое управление рисками позволяет банкам предложить что-то ценное рынку кредитно-финансовых отношений. Представление о том, что банк просто кладет себе в карман процентную маржу между процентом по кредиту и процентом по вкладу в корне не верно, хотя мне иногда приходится такое слышать от людей незнакомых с внутренней кухней банковского бизнеса.
Банк с одной стороны берет на себя все риски невозврата кредита, а с другой стороны дает гарантии вкладчику о возврате вложенных средств. Альтернатива вкладу в Банке, одолжить свои деньги напрямую заемщику без гарантий возврата. Банк же в свою очередь способен давать гарантии, так как с одной стороны обладает «подушкой безопасности» в виде основного капитала и изначально закладывает потери от невозврата кредитов в свои финансовые показатели («формирует резервы»). С другой стороны Банк умеет просчитывать вероятность того, что выданный им кредит заемщик не вернет. Конечно же никто не может предсказать в точности, вернет ли долг конкретное физическое лицо или компания, но в среднем по большому числу заемщиков вероятность оценить можно.
Банк будет финансово устойчивым только в том случае, если та прибыль, которую он зарабатывает на процентной марже покроет убытки от невозврата кредитов и прочие сопутствующие расходы Банка.
Устоявшаяся банковская практика
Перед тем, как перейти к обсуждению прогнозных моделей и непосредственно задач data science, буквально на минуту остановимся на специфике того, как банк работает с клиентом. Банк, и особенно крупный банк, это хорошо организованная система, в которой прописывается буквально каждый шаг. Это касается и взаимодействия с заемщиками.
В частности в отношении заемщиков часто применяется такое понятие, как «дефолт». Дефолт — это статус, который присваивается клиенту в том случае, когда появляется почти полная уверенность, что клиент деньги банку уже не вернет, по крайней мере в полном объеме. О правилах и процедурах, по которым клиентам присваивается статус дефолта договариваются на уровне специально созданной для этого рабочей группы. А затем вышеоговоренные правила прописывают во внутренней нормативной документации.
Если клиенту присвоен статус дефолта, обычно говорят, что «клиент вышел в дефолт». С точки зрения процессов Банка это означает, что будут запущены определенные процедуры взаимодействия с клиентом. Возможно будет решаться вопрос о банкротстве заемщика, Банк попытается реализовать заложенное имущество, взыскать денежные средства с поручителей или продать долг должника коллекторам и т.д.
Так уж исторически сложилось, что ожидаемые потери от невозврата кредитов принято раскладывать на три компоненты:
EL = PD*EAD*LGD
где EL — expected loss, ожидаемые потери;
PD — probability at default, вероятность того, что заемщику будет присвоен статус дефолта в течение следующего года, начиная с даты оценки;
EAD — exposure at default, все те денежные средства, которые клиент на дату «выхода в дефолт» должен вернуть Банку, включая как выданную денежную сумму, так и проценты, штрафы и комиссии;
LGD — loss given default, доля от общей задолженности заемщика перед банком, которую Банк себе уже не вернет. То есть это чистая потеря для Банка;
Если я где-то отхожу от учебных определений и понятий, то заранее прошу прощения, поскольку основная моя цель — это не написать правильный пересказ учебников, а ухватить суть существующих проблем. Для это приходится порой рассуждать «на пальцах».
Попробуем теперь сформулировать типовую задачу для дата-сайентиста. Первое, что стоит уметь прогнозировать — это вероятность дефолта PD. Здесь все кажется просто. У нас задача бинарной классификации. Дайте же нам данные с истинной меткой класса и всеми факторами и мы быстро соберем скрипт с двойной кросс-валидацией и подбором всех гиперпараметров, выберем модель с лучшей метрикой Джини и все будет в порядке. Но почему-то в реальности так не получается.
Нет никакой истинной метки класса
На самом деле истинную метку класса (таргет) мы не знаем. По идее таргет — это бинарная переменная, равная нулю, если заемщик «здоровый», и равная единице, если заемщику присвоен статус «дефолт». Но проблема-то в том, что правила, по которым определяется дефолт, придумываем мы сами. Стоит изменить правила и модель уже не работает даже на тренировочных исторических данных.
Мы плохо знаем своего клиента
С накоплением истории выданных кредитов появляется желание построить более сложные модели, а для этого нужны дополнительные сведения о клиентах. Тут-то и выясняется, что раньше нам эти сведения были не нужны, и соответственно их никто и не собирал. Как результат в собранных выборках много пропусков, что сводит на нет саму идею построить более «информированную модель». И, если бы только это.
Наличие большого числа клиентов вызывает соблазн разбить их не сегменты, в рамках которых построить более «узкие» и в тоже время более точные модели. Но ведь разбиение на сегменты выполняется тоже по какому-то правилу, а это правило строится на все тех же данных о клиентах. И что мы имеем? А мы имеем пропуски в данных, а соотвенно не всегда можем даже понять к какому именно сегменту отнести того или иного клиента.
Регулятор требует делать модели интерпретируемыми
Говоря «регулятор», я имею в виду Центробанк, который требует делать модели понятными. Должен быть понятен не только сам прогноз, но и правила, по которым этот прогноз был сделан. Справедливости ради, скажу, что в большей мере такое правило касается только так называемых «регуляторных» моделей. Регулятор в целях обеспечения устойчивости банковской системы в целом постоянно мониторит деятельность банков по ряду ключевых показателей, среди которых, например, находится расчет достаточности капитала на покрытие непредвиденных потерь во время возможных экономических и финансовых кризисов.
Что означает требование к интерпретируемости? А означает оно, что в большинстве случаев придется довольствоваться моделями в виде логистической регрессии или дерева решений. Про нейронные сети, ансамбли, стекинги и прочие «современные» архитекторы придется забыть.
Прокрустово ложе устоявшейся банковской практики
Отраслевой стандарт де-факто требует оценивать ожидаемые потери как произведение трех величин: PD, EAD и LGD. Это справедливо только в том случае, когда события развиваются по одному и тому же сценарию. Клиент либо возвращает кредит, либо нет. В первом случае, считается что никаких потерь нет. Во втором же случае, предполагается наличие некоторой суммы под риском (EAD).
На практике, платежное поведение клиентов не сводится к двум простым вариантам, а граница между этими вариантами весьма условна. Заемщик может выйти в дефолт и через месяц, и через год, и через два, а затем после того, как ему присвоят статус «дефолт», вдруг вернуться к платежам и выплатить весь кредит. Более того, отклонения от графика платежей могут быть и по суммам и по срокам, с опережением или наоборот отставанием от графика. Финансовый результат для Банка во всех случаях будет разный.
Я не говорю, что нельзя свести все разнообразие вариантов поведения заемщика к схеме расчета трех компонент в принципе. Конечно же все зависит от задачи. Где мы потом хотим эту модель применить? Если для оценки кредитного риска по пулам (группам) заемщиков, то все возможные отклонения учитываются различными калибровками и расчетом средневзвешенных значений. Но, если наша цель заключается в персонализации подхода при выдаче кредита, в том числе в персональном подборе предложений, важным становится прогноз потока платежей со стороны клиента или прогноз чистой приведенной стоимости.
На чем спотыкаются продвинутые data-driven альтернативы
Надо понимать, что вся отраслевая банковская практика была сформирована в те годы, когда не было никакой Big Data или машинного обучения, а все вычисления сводились к построению скоринговых карт. Брали все существенные факторы, влияющие на кредитоспособность заемщика, и оценивали в виде баллов, далее эти баллы суммировали и по сумме баллов определяли выдавать или не выдавать кредит.
С накоплением истории выданных кредитов и развитием вычислительной техники процедуры принятия решений в Банке постепенно усложнялись. Скоркарты превратились в модели логистической регрессии, которые строятся скриптами на python. Клиентов и продукты Банка начали сегментировать для того, чтобы внутри каждого сегмента строить свои узкозаточенные модели. С другой стороны с ростом объемов хранилищ данных появилась возможность собирать и вместе хранить все больше и больше информации во взаимосвязанном виде.
В конечном итоге все движется к идее, когда для каждого пришедшего клиента будет почти мгновенно обнаруживаться наилучшее предложение (оптимальный банковский продукт), которое бы максимизировало CLTV (customer lifetime value) на заданном временном горизонте, либо иную метрику в зависимости от текущего состояния Банка и целей его стейкхолдеров.
Почему бы для решения вышеописанной задачи не применить мощную нейросеть (то есть пресловутый «искусственный интеллект»)? Перечислю несколько мешающих этому обстоятельств:
— Центробанк требует, чтобы модели участвующие в расчете достаточности капитала применялись в «живом» кредитном процессе. То есть именно эти модели должны применяться в принятии решений о выдаче кредитов, быть интерпретируемыми и проходить ряд обязательных валидационных тестов;
— базы клиентских данных постоянно расширяются и дополняются. Например, относительно новыми видами данных является биометрия, веб-аналитика, аналитика мобильных приложений, скоринг социальных сетей. Добавление новых атрибутов происходит в динамике, а соответственно исторических данных по ним у нас практически нет;
— продукты и процессы Банка постоянно видоизменяются и требуется перерасчет CLTV по клиентам и расчет NPV (net present value) по новым продуктам. А для того, чтобы построить модель приемлемого качества надо подождать несколько лет, накопить исторические данные и вычислить фактические значения CLTV или NPV на выборке из реальных заемщиков;
Итог:
При всем желании нельзя рассматривать построение прогнозных моделей в Банке как чисто математическую задачу. На практике решаются бизнес-задачи, которые ко всему прочему сильно переплетены с требованиями регулятора в лице Центробанка.
Порой кажется, что в банковскую область могут проникнуть компании извне с сильным data science и поменять правила игры. Но для того, чтобы выдавать кредиты, надо играть по общим правилам, а следовательно становится Банком со всеми вытекающими последствиями.
Появление нового крутого финтех-стартапа в кредитовании, по-видимому, в большей степени завязано на поиск лазеек в правовом поле, чем на внедрение инноваций в машинном обучении.
===========
Источник:
habr.com
===========
Похожие новости:
- [MySQL, PostgreSQL, Веб-аналитика, DevOps] Подключение БД с SSH-туннелем к PowerBI
- [Платежные системы, Финансы в IT] В Apple Pay добавят карты «Мир»
- [Программирование, Учебный процесс в IT, Карьера в IT-индустрии, Конференции] Бесплатные онлайн-мероприятия по разработке (1 марта — 7 марта 2021)
- [Мессенджеры, IT-инфраструктура, Финансы в IT, IT-компании] VTimes: проблемы, планы и финансовые показатели Telegram, о которых узнали потенциальные покупатели облигаций
- [Разработка мобильных приложений, Венчурные инвестиции, Монетизация мобильных приложений, Развитие стартапа, Финансы в IT] Визионер Андрей Андреев запустил сервис аудиоэфиров Stereo ещё до появления Clubhouse
- [Бизнес-модели, Финансы в IT] Продаете цифровые товары или услуги в ЕС? Тогда мы идем к вам! VAT Moss: как платить НДС в ЕC
- [Алгоритмы, Читальный зал, Искусственный интеллект, Логические игры] Шахматные алгоритмы, которые думают почти так же, как человек, только лучше
- [Социальные сети и сообщества, Финансы в IT] ByteDance выплатит $92 млн по коллективному иску о нарушениях конфиденциальности в США
- [Информационная безопасность, Машинное обучение, Социальные сети и сообщества] Администраторы «ВКонтакте» смогут бороться с угрозами в комментариях с помощью нейросети
- [Data Mining, R, Управление продуктом] Продуктовая аналитика на практике при помощи R
Теги для поиска: #_data_mining, #_mashinnoe_obuchenie (Машинное обучение), #_iskusstvennyj_intellekt (Искусственный интеллект), #_finansy_v_it (Финансы в IT), #_data_engineering, #_bank (банк), #_data_science, #_machine_learning, #_mashinnoe_obuchenie (машинное обучение), #_analitika (аналитика), #_biznesanalitika (бизнес-аналитика), #_data_mining, #_mashinnoe_obuchenie (
Машинное обучение
), #_iskusstvennyj_intellekt (
Искусственный интеллект
), #_finansy_v_it (
Финансы в IT
), #_data_engineering
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:35
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 В течение последних пяти лет я проработал в Центральном Аппарате Сбербанка в Управлении Валидации моделей машинного обучения (machine learning, ML) и видел много «узких мест», которые возникают при разработке и валидации моделей машинного обучения. В этой статье сначала предполагал рассмотреть основные информационные системы некоторого абстрактного Банка X, поскольку именно на базе уже сложившихся информационных систем строится работа дата-аналитиков, а также обучаются и работают ML-алгоритмы принятия решений. Но, когда начал писать, вдруг обнаружил, что на самом деле намного интереснее обсудить ряд тем и подзадач, которые всплывают при построении и валидации самых базовых моделей Банка, то есть моделей кредитного риска. Риск-менеджмент и расчет кредитного риска можно считать прародителями data science в Банке, так как управление кредитным риском является исконно банковской прерогативой. Именно умелое управление рисками позволяет банкам предложить что-то ценное рынку кредитно-финансовых отношений. Представление о том, что банк просто кладет себе в карман процентную маржу между процентом по кредиту и процентом по вкладу в корне не верно, хотя мне иногда приходится такое слышать от людей незнакомых с внутренней кухней банковского бизнеса. Банк с одной стороны берет на себя все риски невозврата кредита, а с другой стороны дает гарантии вкладчику о возврате вложенных средств. Альтернатива вкладу в Банке, одолжить свои деньги напрямую заемщику без гарантий возврата. Банк же в свою очередь способен давать гарантии, так как с одной стороны обладает «подушкой безопасности» в виде основного капитала и изначально закладывает потери от невозврата кредитов в свои финансовые показатели («формирует резервы»). С другой стороны Банк умеет просчитывать вероятность того, что выданный им кредит заемщик не вернет. Конечно же никто не может предсказать в точности, вернет ли долг конкретное физическое лицо или компания, но в среднем по большому числу заемщиков вероятность оценить можно. Банк будет финансово устойчивым только в том случае, если та прибыль, которую он зарабатывает на процентной марже покроет убытки от невозврата кредитов и прочие сопутствующие расходы Банка. Устоявшаяся банковская практика Перед тем, как перейти к обсуждению прогнозных моделей и непосредственно задач data science, буквально на минуту остановимся на специфике того, как банк работает с клиентом. Банк, и особенно крупный банк, это хорошо организованная система, в которой прописывается буквально каждый шаг. Это касается и взаимодействия с заемщиками. В частности в отношении заемщиков часто применяется такое понятие, как «дефолт». Дефолт — это статус, который присваивается клиенту в том случае, когда появляется почти полная уверенность, что клиент деньги банку уже не вернет, по крайней мере в полном объеме. О правилах и процедурах, по которым клиентам присваивается статус дефолта договариваются на уровне специально созданной для этого рабочей группы. А затем вышеоговоренные правила прописывают во внутренней нормативной документации. Если клиенту присвоен статус дефолта, обычно говорят, что «клиент вышел в дефолт». С точки зрения процессов Банка это означает, что будут запущены определенные процедуры взаимодействия с клиентом. Возможно будет решаться вопрос о банкротстве заемщика, Банк попытается реализовать заложенное имущество, взыскать денежные средства с поручителей или продать долг должника коллекторам и т.д. Так уж исторически сложилось, что ожидаемые потери от невозврата кредитов принято раскладывать на три компоненты: EL = PD*EAD*LGD где EL — expected loss, ожидаемые потери; PD — probability at default, вероятность того, что заемщику будет присвоен статус дефолта в течение следующего года, начиная с даты оценки; EAD — exposure at default, все те денежные средства, которые клиент на дату «выхода в дефолт» должен вернуть Банку, включая как выданную денежную сумму, так и проценты, штрафы и комиссии; LGD — loss given default, доля от общей задолженности заемщика перед банком, которую Банк себе уже не вернет. То есть это чистая потеря для Банка; Если я где-то отхожу от учебных определений и понятий, то заранее прошу прощения, поскольку основная моя цель — это не написать правильный пересказ учебников, а ухватить суть существующих проблем. Для это приходится порой рассуждать «на пальцах». Попробуем теперь сформулировать типовую задачу для дата-сайентиста. Первое, что стоит уметь прогнозировать — это вероятность дефолта PD. Здесь все кажется просто. У нас задача бинарной классификации. Дайте же нам данные с истинной меткой класса и всеми факторами и мы быстро соберем скрипт с двойной кросс-валидацией и подбором всех гиперпараметров, выберем модель с лучшей метрикой Джини и все будет в порядке. Но почему-то в реальности так не получается. Нет никакой истинной метки класса На самом деле истинную метку класса (таргет) мы не знаем. По идее таргет — это бинарная переменная, равная нулю, если заемщик «здоровый», и равная единице, если заемщику присвоен статус «дефолт». Но проблема-то в том, что правила, по которым определяется дефолт, придумываем мы сами. Стоит изменить правила и модель уже не работает даже на тренировочных исторических данных. Мы плохо знаем своего клиента С накоплением истории выданных кредитов появляется желание построить более сложные модели, а для этого нужны дополнительные сведения о клиентах. Тут-то и выясняется, что раньше нам эти сведения были не нужны, и соответственно их никто и не собирал. Как результат в собранных выборках много пропусков, что сводит на нет саму идею построить более «информированную модель». И, если бы только это. Наличие большого числа клиентов вызывает соблазн разбить их не сегменты, в рамках которых построить более «узкие» и в тоже время более точные модели. Но ведь разбиение на сегменты выполняется тоже по какому-то правилу, а это правило строится на все тех же данных о клиентах. И что мы имеем? А мы имеем пропуски в данных, а соотвенно не всегда можем даже понять к какому именно сегменту отнести того или иного клиента. Регулятор требует делать модели интерпретируемыми Говоря «регулятор», я имею в виду Центробанк, который требует делать модели понятными. Должен быть понятен не только сам прогноз, но и правила, по которым этот прогноз был сделан. Справедливости ради, скажу, что в большей мере такое правило касается только так называемых «регуляторных» моделей. Регулятор в целях обеспечения устойчивости банковской системы в целом постоянно мониторит деятельность банков по ряду ключевых показателей, среди которых, например, находится расчет достаточности капитала на покрытие непредвиденных потерь во время возможных экономических и финансовых кризисов. Что означает требование к интерпретируемости? А означает оно, что в большинстве случаев придется довольствоваться моделями в виде логистической регрессии или дерева решений. Про нейронные сети, ансамбли, стекинги и прочие «современные» архитекторы придется забыть. Прокрустово ложе устоявшейся банковской практики Отраслевой стандарт де-факто требует оценивать ожидаемые потери как произведение трех величин: PD, EAD и LGD. Это справедливо только в том случае, когда события развиваются по одному и тому же сценарию. Клиент либо возвращает кредит, либо нет. В первом случае, считается что никаких потерь нет. Во втором же случае, предполагается наличие некоторой суммы под риском (EAD). На практике, платежное поведение клиентов не сводится к двум простым вариантам, а граница между этими вариантами весьма условна. Заемщик может выйти в дефолт и через месяц, и через год, и через два, а затем после того, как ему присвоят статус «дефолт», вдруг вернуться к платежам и выплатить весь кредит. Более того, отклонения от графика платежей могут быть и по суммам и по срокам, с опережением или наоборот отставанием от графика. Финансовый результат для Банка во всех случаях будет разный. Я не говорю, что нельзя свести все разнообразие вариантов поведения заемщика к схеме расчета трех компонент в принципе. Конечно же все зависит от задачи. Где мы потом хотим эту модель применить? Если для оценки кредитного риска по пулам (группам) заемщиков, то все возможные отклонения учитываются различными калибровками и расчетом средневзвешенных значений. Но, если наша цель заключается в персонализации подхода при выдаче кредита, в том числе в персональном подборе предложений, важным становится прогноз потока платежей со стороны клиента или прогноз чистой приведенной стоимости. На чем спотыкаются продвинутые data-driven альтернативы Надо понимать, что вся отраслевая банковская практика была сформирована в те годы, когда не было никакой Big Data или машинного обучения, а все вычисления сводились к построению скоринговых карт. Брали все существенные факторы, влияющие на кредитоспособность заемщика, и оценивали в виде баллов, далее эти баллы суммировали и по сумме баллов определяли выдавать или не выдавать кредит. С накоплением истории выданных кредитов и развитием вычислительной техники процедуры принятия решений в Банке постепенно усложнялись. Скоркарты превратились в модели логистической регрессии, которые строятся скриптами на python. Клиентов и продукты Банка начали сегментировать для того, чтобы внутри каждого сегмента строить свои узкозаточенные модели. С другой стороны с ростом объемов хранилищ данных появилась возможность собирать и вместе хранить все больше и больше информации во взаимосвязанном виде. В конечном итоге все движется к идее, когда для каждого пришедшего клиента будет почти мгновенно обнаруживаться наилучшее предложение (оптимальный банковский продукт), которое бы максимизировало CLTV (customer lifetime value) на заданном временном горизонте, либо иную метрику в зависимости от текущего состояния Банка и целей его стейкхолдеров. Почему бы для решения вышеописанной задачи не применить мощную нейросеть (то есть пресловутый «искусственный интеллект»)? Перечислю несколько мешающих этому обстоятельств: — Центробанк требует, чтобы модели участвующие в расчете достаточности капитала применялись в «живом» кредитном процессе. То есть именно эти модели должны применяться в принятии решений о выдаче кредитов, быть интерпретируемыми и проходить ряд обязательных валидационных тестов; — базы клиентских данных постоянно расширяются и дополняются. Например, относительно новыми видами данных является биометрия, веб-аналитика, аналитика мобильных приложений, скоринг социальных сетей. Добавление новых атрибутов происходит в динамике, а соответственно исторических данных по ним у нас практически нет; — продукты и процессы Банка постоянно видоизменяются и требуется перерасчет CLTV по клиентам и расчет NPV (net present value) по новым продуктам. А для того, чтобы построить модель приемлемого качества надо подождать несколько лет, накопить исторические данные и вычислить фактические значения CLTV или NPV на выборке из реальных заемщиков; Итог: При всем желании нельзя рассматривать построение прогнозных моделей в Банке как чисто математическую задачу. На практике решаются бизнес-задачи, которые ко всему прочему сильно переплетены с требованиями регулятора в лице Центробанка. Порой кажется, что в банковскую область могут проникнуть компании извне с сильным data science и поменять правила игры. Но для того, чтобы выдавать кредиты, надо играть по общим правилам, а следовательно становится Банком со всеми вытекающими последствиями. Появление нового крутого финтех-стартапа в кредитовании, по-видимому, в большей степени завязано на поиск лазеек в правовом поле, чем на внедрение инноваций в машинном обучении. =========== Источник: habr.com =========== Похожие новости:
Машинное обучение ), #_iskusstvennyj_intellekt ( Искусственный интеллект ), #_finansy_v_it ( Финансы в IT ), #_data_engineering |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:35
Часовой пояс: UTC + 5