Что ждет «Единого клиента» в 2026 году

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

Модуль ядра на ЯБД

Большинство MDM в компаниях разворачивались на Oracle или PostgreSQL. Сегодня оба варианта несут стратегические риски. Oracle — иностранный вендор: лицензии дорожают, да и непонятно, что будет дальше с санкциями. А PostgreSQL упирается в потолок при росте нагрузки. В какой-то момент СУБД начинает деградировать: параллельная запись из множества источников создает блокировки. Чтобы масштабироваться, нужно дорогостоящее железо.

В этом году «Единый клиент» подружится с ЯБД — российской распределенной СУБД с открытым кодом от Яндекса. Это готовый путь миграции как с Oracle, так и с PostgreSQL: переписывать бизнес-логику системы не придется.

Что это даст?

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

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

Карточки-оверлеи

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

Оверлей прикрепляется к существующей карточке как слой — сохраняет связь с источником и не загрязняет основную базу.

Что это даст?

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

Представители юрлиц

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

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

Что это даст?

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

Мониторинг изменений в ЕГРЮЛ

Смена директора, изменение состава учредителей, появление нового адреса или замена ОКВЭД — все это влияет на кредитные риски, лимиты, условия обслуживания и обязательства по 115-ФЗ. «Единый клиент» умеет сверять базу с ЕГРЮЛ, но пока это плановая актуализация: заказчики узнают об изменениях постфактум и реагируют с опозданием.

Теперь будем отслеживать конкретные поля карточки ЕГРЮЛ — в том числе смену руководителя, реорганизацию, запись о ликвидации. При изменении система передаст событие в обратный поток, чтобы фронт-офис мог отреагировать сразу.

Что это даст?

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

Конечные бенефициары

115-ФЗ обязывает верифицировать конечного бенефициара. А цепочка владения бывает многоуровневой: ООО, холдинг, офшор, физлицо — разобрать ее вручную трудно. Ошибка в идентификации — прямой регуляторный риск и потенциальные санкции ЦБ.

«Единый клиент» научится выявлять бенефициара автоматически по связям между объектами.

Что это даст?

В связке с модулем «ЕГРЮЛ Про» и проверкой по спискам Росфинмониторинга инструмент покроет весь цикл работы с клиентом: идентификация → верификация → мониторинг → уведомление.

Расширенная ролевая модель

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

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

• внутри одной сущности — например, физлица розницы отдельно от физлиц корпоративного блока;
• между разными сущностями — физлица, юрлица, договоры.

Роли можно гибко комбинировать.

Что это даст?

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

Проверка действительности паспортов по данным СМЭВ

Недействительный паспорт в клиентской базе — еще один регуляторный риск по 115-ФЗ и потенциальный фрод. Документы теряются, меняются, аннулируются. Без систематической проверки база накапливает «мертвые» записи, которые обнаруживаются только в момент инцидента.

Мы продолжим развивать встроенный модуль проверки паспортов через СМЭВ — государственную систему с актуальными данными МВД о статусе документов.

Что это даст?

Операторы смогут проверять паспорта в любом удобном режиме: пакетом по накопленному объему, в реальном времени при обращении, вручную из карточки или по расписанию. При этом система не будет делать лишних запросов в СМЭВ, если актуальная проверка уже есть. Паспорт со статусом «Недействительный» будет сразу учитываться в контуре противодействия мошенничеству.

Модуль проверяет только паспорта физлиц — загранпаспорт, СНИЛС и ИНН не поддерживаются. Интеграция с шиной СМЭВ настраивается под каждого заказчика.

Чтобы узнать больше об изменениях, пишите на ask@hflabs.ru.