TL;DR. Спустя девять месяцев после дедлайна IPR Verification of Payee — утилита для каждого PSP еврозоны. Сложны неполные совпадения, пакетные файлы и ответственность.

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

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

Verification of Payee в продакшене: девять месяцев неполных совпадений, пакетных файлов и неоценённой ответственности

Проверка получателя платежа перестала быть продуктом в тот день, когда стала обязанностью. С 9 октября 2025 года каждый поставщик платёжных услуг в государстве-члене еврозоны обязан предоставлять Verification of Payee по кредитовым переводам бесплатно — согласно Регламенту (ЕС) 2024/886. Сама проверка несложна: сравнить указанное имя с именем, закреплённым за счётом, и дать ответ. Трудным оказалось всё, что вокруг: бюджет ответа в пять секунд, промежуточный ответ, который не «да» и не «нет», корпоративные файлы, которые нужно разобрать на строки, прежде чем проверять, и граница ответственности, которую и регламент, и свод правил схемы проводить отказываются.

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

Обязанность широка и не оплачивается. Регламент (ЕС) 2024/886 требует от PSP предоставлять Verification of Payee плательщику бесплатно по всем попадающим в периметр кредитовым переводам; провайдеры еврозоны работают с 9 октября 2025 года, провайдеры за её пределами подключаются по более позднему графику. Возместить затраты комиссией нельзя.

Интероперабельность вынесена вовне. Вместо того чтобы соединять каждый PSP с каждым, схема Европейского платёжного совета маршрутизирует запросы через Routing and/or Verification Mechanisms, проходящие квалификацию EPC. Это решение закрыло вопрос достижимости и породило зависимость от третьей стороны, место которой — в реестре операционной устойчивости.

Задержка — это условие схемы, а не выбранный вами SLO. Схема устанавливает максимум в пять секунд на получение ответа запрашивающим PSP, а на практике целевой показатель существенно ниже. Тайм-аут — не сбой, от которого можно уберечь плательщика; это ответ, и означает он «проверить не удалось».

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

Регламент превратил проверку в инфраструктуру

Десять лет сверка имени была национальной инициативой и конкурентным сюжетом. Нидерланды и Великобритания построили схемы и продвигали снижение мошенничества. Регламент (ЕС) 2024/886 закрыл эту рамку по всей еврозоне, сделав проверку обязательной, бесплатной и всеобщей.

Три свойства обязанности значат больше остальных.

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

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

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

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

Что на самом деле требует схема

Схема EPC определяет обмен сообщениями и, что важнее, словарь ответа. Запрашивающий PSP спрашивает; отвечающий PSP — тот, у которого открыт счёт за этим IBAN, — возвращает классификацию, а не полное имя владельца счёта.

Таблица 1. Типы ответов и что каждый из них обязывает

Ответ	Что означает	Что видит плательщик	Что PSP обязан подтвердить документально
Совпадение	Указанное имя соответствует имени, закреплённому за счётом	Продолжение без трения	Что проверка выполнена и ответ зафиксирован
Неполное совпадение	Имена близки, но не идентичны: сокращение, коммерческое наименование, переставленные элементы	Предупреждение, а по замыслу схемы — и фактическое имя по счёту, чтобы плательщик мог рассудить сам	Точную показанную строку, отметку времени и последующий выбор плательщика
Несовпадение	Имя не соответствует счёту	Явное предупреждение до авторизации	Содержание предупреждения и факт его игнорирования, если он был
Проверка невозможна	Ответа в отведённое окно нет либо отвечающая сторона не может обслужить запрос	Нейтральное сообщение о том, что проверку завершить не удалось	Причину сбоя и то, что плательщик был об этом уведомлён

Четвёртую строку большинство программ спроектировало слабее всего. Тайм-аут — не внутренняя ошибка, которую можно проглотить. Это предусмотренный схемой исход с обязательным раскрытием, и он будет происходить: при инцидентах на стороне отвечающего PSP, при деградации RVM или просто из-за разброса сетевых задержек у самого потолка.

Интероперабельность обеспечивают Routing and/or Verification Mechanisms. PSP может подключаться к контрагентам через RVM, а не выстраивать двустороннюю достижимость с каждой организацией в SEPA; при этом RVM обязаны пройти квалификацию EPC. Архитектурно решение верное — альтернатива представляет собой нереализуемую полносвязную сеть, — но оно вводит концентрированную третью сторону прямо в путь авторизации регулируемой платёжной услуги. Место этому — в реестре информации по DORA и в анализе риска концентрации, а не только в досье поставщика.

Неполное совпадение и есть вся проблема

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

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

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

Два проектных обязательства заметно меняют исход.

Показывайте имя, а не только вердикт. Предупреждение «данные не совпадают в точности» не даёт плательщику ничего, с чем можно работать. Замысел схемы предусматривает возврат имени по счёту при неполных совпадениях именно для того, чтобы плательщик распознал: «ACME Trading Ltd» и «Acme Trading Limited» — один и тот же контрагент, а «A. Trading Services» — нет.

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

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

Пакетные файлы сломали модель, и точкой контроля стал отказ от услуги

Розничные разовые платежи никогда не были трудным случаем. Трудным были корпоративные платёжные файлы.

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

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

Для команд корпоративного банкинга отсюда следуют два вывода.

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

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

Граница ответственности, которую никто не провёл

Схема определяет ответы. Последствий она не определяет. В этом разрыве и разместятся споры ближайших нескольких лет.

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

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

Для организаций, предпочитающих формировать этот исход, а не принимать его, отсюда следуют три вещи.

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

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

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

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

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

Оснастите телеметрией середину. Отчитывайтесь о доле неполных совпадений, доле проигнорированных предупреждений и доле оспоренных среди проигнорированных — помесячным рядом, с разрезом по каналам и типам клиентов. Эти три показателя говорят, работает ли контроль; объём проверок не говорит ничего.
Относитесь к RVM как к критически важной третьей стороне. Он стоит в пути авторизации. Ему нужны план выхода, анализ заменяемости и интеграция в реагирование на инциденты — наравне с любым другим критически важным поставщиком.
Спроектируйте путь тайм-аута осознанно. Решите и задокументируйте, блокирует ли исход «проверка невозможна», предупреждает или пропускает — по каждому каналу и по каждому диапазону сумм. Умолчание в виде молчания — это решение, принятое бездействием.
Перенесите корпоративную проверку выше по потоку. Предлагайте проверку при заведении бенефициара и при изменении банковских реквизитов как постоянную услугу. Она снижает задержку платёжного прогона, усиливает контроль и представляет собой настоящее коммерческое предложение в регламенте, который в остальном взимать плату запрещает.
Переаттестуйте каждый пакетный отказ от услуги. Поставьте срок действия. Назначьте владельца. Сделайте продление решением, а не отсутствием решения.
Готовьтесь к неевровому траншу. Провайдеры за пределами еврозоны попадают в периметр по более позднему графику, уходящему в 2027 год. Организациям, работающим и там и там, следует строить одну возможность, а не две.

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

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

Распространяется ли Verification of Payee только на мгновенные платежи?
Нет. Хотя требование было введено через регламент мгновенных платежей, обязанность проверки распространяется на попадающие в периметр кредитовые переводы в целом, включая обычные кредитовые переводы SEPA, а не только на SCT Inst. Программы, ограниченные периметром мгновенных платежей, недооценили поверхность интеграции.

Может ли банк брать плату за Verification of Payee?
С плательщика за услугу, требуемую Article 5c, — нет: регламент требует предоставлять её бесплатно. Смежные услуги, выходящие за рамки обязанности, например проверка бенефициаров при заведении или при изменении банковских реквизитов для корпоративных клиентов, под это ограничение не подпадают — именно там коммерческое предложение существует законно.

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

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

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

Источники

Европейский парламент и Совет Европейского союза, 2024. Регламент (ЕС) 2024/886, вносящий изменения в Регламенты (ЕС) № 260/2012 и (ЕС) 2021/1230 в части мгновенных кредитовых переводов в евро. Брюссель: Официальный журнал Европейского союза. Доступно по адресу: Европейский парламент и Совет Европейского союза, 2024..
Европейский центральный банк, 2026. Регламент мгновенных платежей. Франкфурт-на-Майне: Европейский центральный банк. Доступно по адресу: Европейский центральный банк, 2026..
Европейская комиссия, 2025. Разъяснение требований регламента мгновенных платежей. Брюссель: Генеральный директорат по финансовой стабильности, финансовым услугам и союзу рынков капитала. Доступно по адресу: Европейская комиссия, 2025..
Европейский платёжный совет, 2025. Схема Verification of Payee. Брюссель: EPC. Доступно по адресу: Европейский платёжный совет, 2025..
Европейский платёжный совет, 2025. Свод правил схемы Verification of Payee — часто задаваемые вопросы. Брюссель: EPC. Доступно по адресу: Европейский платёжный совет, 2025..
Европейский платёжный совет, 2025. Разъяснения о предоставлении услуг VOP для пакетных файлов. Брюссель: EPC. Доступно по адресу: Европейский платёжный совет, 2025..
Европейский платёжный совет, 2025. Routing and/or Verification Mechanisms для схемы Verification of Payee. Брюссель: EPC. Доступно по адресу: Европейский платёжный совет, 2025..

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

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

Verification of Payee в проде: неполные совпадения и ответственность — Sebastien Rousseau

Спустя девять месяцев после дедлайна IPR Verification of Payee — утилита для каждого PSP еврозоны. Сложны неполные совпадения, пакетные файлы и ответственность.

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

Verification of Payee в проде: неполные совпадения и ответственность — Sebastien Rousseau

Спустя девять месяцев после дедлайна IPR Verification of Payee — утилита для каждого PSP еврозоны. Сложны неполные совпадения, пакетные файлы и ответственность.

Originally published at https://sebastienrousseau.com/ru/2026-07-27-verification-of-payee-production-vop-ipr-banks-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER