Кошелёк выходит в декабре. Банки обязаны принять его через год.

TL;DR. Государства ЕС обязаны выпустить кошелёк EUDI к декабрю 2026 года. Банки обязаны принимать его с декабря 2027 года. Эти двенадцать месяцев и есть проблема.

Ключевые выводы

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

Десять лет банки владели логином. Организация выпускала удостоверение, проводила аутентификацию, вела аудиторский след и решала, что означает «проверено». Регламент о европейской цифровой идентичности прекращает этот порядок, нигде не заявляя об этом прямо. Он требует от каждого государства-члена сделать кошелёк доступным гражданам к декабрю 2026 года и требует от банков — названных по отрасли, а не выведенных по смыслу, — принимать этот кошелёк для усиленной аутентификации пользователя к декабрю 2027 года. Между этими двумя датами лежит год, в котором удостоверение уже существует, клиенты его носят, а обязанность ещё не наступила. Большинство организаций считают этот год запасом времени. Это окно для стройки.

Краткая сводка для руководства

Это устоявшееся право, в отличие от большей части повестки 2026 года. Regulation (EU) 2024/1183 действует. Даты зафиксированы в тексте, а не висят в трилоге, и это делает программу одной из немногих, под которые можно планировать с уверенностью.

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

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

Сложное начинается после того, как удостоверение проверено. Криптографически действительное предъявление говорит, что держатель — тот, кем его называет государство. Оно не говорит, тот ли это человек, который открыл счёт в 2014 году.

Две даты, один разрыв

Начните со сроков, потому что почти всякое неверное прочтение этого досье рождается из склеивания двух дат в одну.

Regulation (EU) 2024/1183 внёс изменения в исходный регламент eIDAS, Regulation (EU) No 910/2014, и вступил в силу в мае 2024 года. Он дал Комиссии мандат принимать имплементационные акты, определяющие, как кошельки строятся, сертифицируются, регистрируются и используются, и установил два обязательства, идущие по разным часам.

Первое ложится на государства-члены. К 24 декабря 2026 года каждое обязано сделать доступным гражданам и резидентам как минимум один европейский кошелёк цифровой идентичности. Это обязательство предоставления: государство или назначенная им сторона выдаёт кошелёк, и с физических лиц плата не взимается.

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

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

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

Доверяющая сторона — правовая роль, а не паттерн интеграции

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

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

Отсюда следуют три вывода, и ни один из них не инженерная задача.

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

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

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

Таблица 1. Где находится банк до и после

Измерение	Идентичность, принадлежащая банку (сегодня)	Кошелёк EUDI (статья 5f)
Кто выпускает удостоверение	Банк, после собственного приёма на обслуживание	Государство-член или назначенный поставщик
Кто решает, что оно действительно	Банк, по собственным записям	Банк, по подписи и статусу эмитента
Что контролирует клиент	Немногое; отношения держит банк	Какие атрибуты раскрываются при каждом предъявлении
Что банк обязан делать	То, что позволяет его риск-аппетит	Принять предъявление, когда пользователь просит
Условие участия	Ничего сверх собственных систем	Регистрация как доверяющей стороны по статье 5b
Цена запроса дополнительных данных	Внутреннее продуктовое решение	Изменение зарегистрированного, заявленного объёма

Кошелёк не отменяет усиленную аутентификацию клиента

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

Усиленная аутентификация клиента по Directive (EU) 2015/2366 и регуляторные технические стандарты в Commission Delegated Regulation (EU) 2018/389 продолжают определять, как поставщики платёжных услуг аутентифицируют плательщиков и авторизуют операции. Обязанность по статье 5f накладывается поверх, а не подменяет их. Банк по-прежнему обязан выполнять требования SCA; дополнительно он обязан принять кошелёк, когда клиент предлагает его для усиленной аутентификации пользователя.

Практический вопрос, следовательно, не «заменяет ли кошелёк наши факторы SCA», а «что предъявление кошелька добавляет к аутентификации, соответствующей SCA, и что мы по-прежнему обязаны делать сами». Это архитектурный вопрос с реальным ответом, и разобраться с ним стоит до крайнего срока, а не во время него: два режима написаны разными инструментами для разных целей, а встречаются они внутри вашего сервиса аутентификации.

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

Чего проверка вам не сообщает

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

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

Оно не говорит вам, что этот человек — тот клиент, который открыл счёт.

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

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

Таблица 2. На что на самом деле раскладывается проект

Направление работ	Зависит от существования кошелька?	Можно начать сейчас
Регистрация доверяющей стороны в каждом государстве-члене учреждения	Нужен работающий регистрирующий орган	Определить объём атрибутов, который вы заявите
Проверка предъявления, работа со списком доверия и отзывом	Да, для сквозного тестирования	Выбор протокола и проектирование сервиса
Привязка проверенной идентичности к существующей записи клиента	Нет	Да — это самое длинное звено
Согласование приёма кошелька с обязанностями по SCA	Нет	Да
Ответственность, инциденты и споры по удостоверению, которое вы не выпускали	Нет	Да
Пересмотр существующих сценариев на минимизацию атрибутов	Нет	Да

Четыре из шести не ждут ничего.

Операционный сценарий действий

Шесть шагов в том порядке, в каком я бы их выстроил.

Назначьте ответственного владельца. Тема лежит на стыке идентификации, приёма на обслуживание, платежей и юридической функции, а в большинстве банков это означает, что она не лежит нигде. Приём кошелька проваливается как федеративная инициатива.
Определите объём атрибутов до того, как спросит регистрирующий орган. Регистрация декларирует, что вы будете запрашивать. Выведите минимум, который поддерживает ваши сценарии: заявленный объём проще осознанно расширить, чем сузить после проверки приватности.
Начните задачу привязки сейчас. Сопоставление государственной идентичности с существующей записью клиента — направление с самым длинным хвостом и наименьшим числом зависимостей. Оно же определяет, станет приём хорошим опытом или очередью в поддержку.
Запишите согласование с SCA. Задокументируйте, как предъявление кошелька взаимодействует с вашими действующими факторами аутентификации и где два режима встречаются. Сделайте это архитектурным решением в реестре, а не слайдом.
Смоделируйте сценарии отказа, которыми вы никогда не владели. Устаревший отзыв, недоступность эмитента, проверка, срабатывающая «в пропуск». Вы не выпускали это удостоверение; исходите из того, что эти отказы вам не подконтрольны, и проектируйте соответственно.
Используйте двенадцать месяцев разрыва осознанно. Кошельки работают с декабря 2026 года. Считайте 2027 год годом, когда вы эксплуатируете возможность, а не годом, когда вы её строите.

Эпоха открытого банкинга научила банки, что предписанный интерфейс редко бывает просто интерфейсом. Тот же урок приходит через другой инструмент. Организации, которые прочтут статью 5f как задачу на интеграцию, в срок сдадут соответствующий требованиям поток предъявления и всё равно не смогут ответить на единственный вопрос, который имеет значение у стойки: человек, держащий этот кошелёк, — тот ли это человек, чей счёт вы собираетесь открыть?

Часто задаваемые вопросы

Когда именно банк обязан принимать кошелёк?
К 24 декабря 2027 года — для крупных и средних доверяющих сторон, которые по закону или по договору обязаны использовать усиленную аутентификацию пользователя и работают в перечисленной отрасли, включая банковские и финансовые услуги. Отдельная обязанность государств-членов сделать доступным как минимум один кошелёк наступает годом раньше, к 24 декабря 2026 года.

Это решённый вопрос или даты могут сдвинуться?
Regulation (EU) 2024/1183 действует, и даты стоят в принятом тексте, а не в проекте, который ещё обсуждают. Это делает их существенно твёрже большинства того, под что банки сейчас планируют, и это одна из причин, по которым досье вознаграждает раннюю работу.

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

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

Мы не учреждены в ЕС. Достаёт ли это до нас?
Обязанность приёма по статье 5f привязана к доверяющим сторонам, работающим в перечисленных отраслях в рамках правового поля Союза, а обязанность регистрации привязана к государству-члену учреждения. Ответ определяют структура группы и место учреждения каждого регулируемого лица; это юридический вопрос, который стоит решить рано, а не технический.

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

Источники

Европейский парламент и Совет Европейского союза, 2024. Regulation (EU) 2024/1183 о внесении изменений в Regulation (EU) No 910/2014 в части создания Европейской системы цифровой идентичности. Брюссель: Официальный журнал Европейского союза. Доступно по адресу: Европейский парламент и Совет Европейского союза, 2024..
Европейская комиссия, 2026. Европейский кошелёк цифровой идентичности. Брюссель: Генеральный директорат по коммуникационным сетям, контенту и технологиям. Доступно по адресу: Европейская комиссия, 2026..
Европейская комиссия, 2026. Архитектурная и справочная основа кошелька EUDI. Брюссель: Европейская комиссия. Доступно по адресу: Европейская комиссия, 2026..
Европейский парламент и Совет Европейского союза, 2015. Directive (EU) 2015/2366 о платёжных услугах на внутреннем рынке (PSD2). Брюссель: Официальный журнал Европейского союза. Доступно по адресу: Европейский парламент и Совет Европейского союза, 2015..
Европейская комиссия, 2018. Commission Delegated Regulation (EU) 2018/389, дополняющий Directive (EU) 2015/2366 в части регуляторных технических стандартов усиленной аутентификации клиента. Брюссель: Официальный журнал Европейского союза. Доступно по адресу: Европейская комиссия, 2018..
OpenID Foundation, 2026. OpenID for Verifiable Presentations. Сан-Рамон: OpenID Foundation. Доступно по адресу: OpenID Foundation, 2026..

Последняя проверка 2026-08-08.

Опубликовать заново

Кошелёк выходит в декабре. Банки обязаны принять его через год. — Sebastien Rousseau

Государства ЕС обязаны выпустить кошелёк EUDI к декабрю 2026 года. Банки обязаны принимать его с декабря 2027 года. Эти двенадцать месяцев и есть проблема.

Эта статья распространяется по лицензии Creative Commons Attribution 4.0 International. При повторной публикации требуется указание канонической ссылки.

Кошелёк выходит в декабре. Банки обязаны принять его через год. — Sebastien Rousseau

Государства ЕС обязаны выпустить кошелёк EUDI к декабрю 2026 года. Банки обязаны принимать его с декабря 2027 года. Эти двенадцать месяцев и есть проблема.

Originally published at https://sebastienrousseau.com/ru/2026-08-01-eudi-wallet-eidas-2-banks-relying-party-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER