Сгенерировано Chatgpt
ISO 20022 и комплаенс-скрининг: что структурированные данные действительно меняют в операционном контуре
Переход на ISO 20022 завершён на 98%, но обещанное снижение ложных срабатываний на 25–30% не происходит само по себе. Разбираем, что именно меняет структурированный формат в комплаенс-скрининге, почему 65% сообщений всё ещё содержат неструктурированные адреса и какие пять шагов нужны, чтобы эффект стал реальным.
Платёжные сообщения, которыми банки обмениваются при переводах из одной страны в другую, десятилетиями передавались в «неструктурированном» формате. С марта 2023 года глобальная финансовая инфраструктура переходила на ISO 20022. Ключевая веха была пройдена 22 ноября 2025 года, когда завершился параллельный период MT/ISO 20022 для CBPR+.
Сразу после переходных выходных сообщество достигло 97% внедрения, а к августу 2026 года этот показатель превысил 98%. Именно завершение параллельного периода, а не текущая цифра, стало главным событием миграции.
В старом формате все данные о плательщике, его адресе и стране были записаны одной сплошной строкой. Система скрининга сравнивала эту строку с санкционными списками. Из-за этого возникало множество ошибок: по оценкам SWIFT, 99% сигналов тревоги оказывались ложными.
Новый формат разбивает информацию на отдельные поля: имя, адрес, страна, идентификатор компании. Скрининговая система может сравнивать каждое поле по отдельности. Это позволяет теоретически сократить ложные срабатывания на 25–30%. Однако на практике эффект зависит не от самого формата, а от того, насколько качественно и полностью заполнены эти поля. Если банк не передаёт страну или LEI — улучшения не будет.
По состоянию на август 2026 года более 98% платёжных инструкций в сети SWIFT передаются в новом формате. В разных странах ситуация отличается:
Канада завершила переход на ISO 20022 в ноябре 2025 года, привязав это к глобальному дедлайну Swift. Однако национальная система Lynx внедрила стандарт ещё в марте 2023 года, и к октябрю 2025 года более 98% её сообщений уже были в формате MX. Ноябрь 2025 — это дата окончания сосуществования форматов.
Великобритания готовилась заранее: Банк Англии еще с 2018 года сопровождал подготовку участников CHAPS, ввел строгий контроль за заполнением полей и сделал LEI приоритетом;
в США ключевые системы (CHIPS и Fedwire) уже перешли на новый формат. CHIPS — в апреле 2024, Fedwire — в июле 2025».
Изначально последним рубежом назывался ноябрь 2026 года, когда неструктурированные адреса должны были перестать приниматься в сети SWIFT. Однако в августе 2026 года SWIFT приняла решение о контролируемом продлении сроков. Требование сохраняется, но новая дата не назначена — обновление ожидается не позднее декабря.
Что именно изменилось в данных
До перехода на ISO 20022 все данные о плательщике и получателе передавались в одном текстовом поле. Название компании, улица, город и страна были записаны одной строкой без какой-либо структуры. Это делало автоматическую обработку невозможной. Компьютер не мог понять, где имя, а где адрес, поэтому сравнивал всю строку целиком с чёрными списками.
Это порождало массу ошибок. Например, в старом формате строка могла выглядеть так: «Pierre Dupont, 15 Rue de Rivoli, Paris, France». Если в санкционном списке есть человек с фамилией Dupont — система выдавала ложноположительное срабатывание, даже если речь о другом Дюпоне, проживающем в другой стране и не имеющем отношения к ограничениям.
Система не могла отличить одного однофамильца от другого, потому что у неё не было других данных, кроме строки. Новый стандарт разбивает информацию на отдельные поля.
Теперь для каждого элемента есть своё место:
имя;
адрес;
город;
страна;
почтовый индекс.
Каждый элемент передаётся отдельно. Это позволяет машине понять, что именно и с чем она сравнивает. Это снижает число ложных срабатываний, поскольку система сравнивает отдельные поля, а не всю строку.
Однако частичное совпадение не снимает ограничения автоматически: алерт по-прежнему уходит на ручной разбор, и окончательное решение принимает комплаенс-офицер.
Кроме того, в сообщении появилось чёткое разделение всех сторон платежа. Теперь явно указаны:
плательщик;
получатель;
банк-отправитель;
банк-получатель;
конечный бенефициар;
сторона, по чьему поручению совершается операция.
Это критически важно, потому что у каждой из этих сторон могут быть свои санкционные статусы и риски, и их нужно проверять отдельно. Также в формате появились специальные коды для назначения платежа и возможность передавать идентификаторы юридических лиц, такие как LEI.
Ключевое изменение: система теперь способна отличить одну сторону платежа от другой. Эта структурированность создаёт базу для точного скрининга и снижения числа ошибок.
Как это отражается на скрининге
Новый формат данных напрямую влияет на качество санкционного скрининга. Теоретически он может обеспечить:
Снижение числа ошибок. Система сопоставляет отдельные поля. Случайное совпадение фамилии не вызывает ложную тревогу — проверка идёт по адресу, стране и идентификатору вместе.
Географическая точность: для страны есть отдельное поле. Если платёж идёт из государства с высоким риском, к нему применяются дополнительные проверки.
Прозрачность всех участников. Каждый из них может быть под санкциями. Работая по новым правилам, система должна лучше находить подсанкционных лиц.
Новые сценарии проверок. Например, появилось структурированное поле с кодом цели платежа. Если компания из определённого сектора платит в страну с высоким риском, это сразу заметно.
Важно: все эти улучшения работают только при условии, что поля действительно заполнены.
Почему сам по себе формат не решает задачу
Структурированный формат создаёт техническую возможность для точного скрининга, но сам по себе он её не реализует. Существуют практические проблемы.
1. Неполное заполнение. Передача данных в структурированном виде и их фактическое наличие — разные вещи. Банк может отправить сообщение в формате ISO 20022, но оставить большинство полей пустыми или перенести в них старую текстовую строку «как есть».
По данным SWIFT, на март 2026 года около 65% платёжных сообщений всё ещё содержали неструктурированные адреса. К апрелю этот показатель снизился до 61,2% — динамика есть, но она остаётся неравномерной: значительные части отрасли по всем регионам не успевают завершить переход.
2. Низкое качество исходных данных. Названия компаний пишутся по-разному в разных странах, транслитерация с местных алфавитов создаёт разные варианты написания одного и того же имени. У многих контрагентов, особенно в развивающихся странах, нет идентификатора LEI. Без него система не может однозначно сопоставить плательщика с записью в санкционном списке, и точность скрининга остаётся невысокой.
3. Настройка правил скрининга. Системы мониторинга транзакций десятилетиями калибровались под работу с неструктурированными данными. Они привыкли искать совпадения в сплошном тексте и выдавать сигнал при любом намёке на совпадение.
Переход на структурированные поля требует полной перекалибровки: нужно заново настраивать пороги чувствительности, алгоритмы сопоставления, логику принятия решений. Без этого система будет либо пропускать реальные риски, либо выдавать ложные срабатывания.
4. Слабое звено в цепочке. Трансграничный платёж проходит через несколько банков. Если один из посредников не поддерживает ISO 20022 в полном объёме или передаёт данные в ограниченном формате, вся структурированная информация теряется. На стороне получателя платёж приходит снова в виде неструктурированного текста, и все преимущества нового формата обнуляются.
Итак, ISO 20022 — необходимое, но недостаточное условие для эффективной работы комплаенса. Без дисциплины заполнения данных, чистой базы контрагентов, перекалибровки правил и готовности всех участников цепочки эффект для комплаенс-функции останется минимальным.
Что нужно менять, помимо формата
Необходимо привести в порядок справочники контрагентов. У каждого клиента должен быть структурированный адрес (страна, город, улица, дом) и, по возможности, LEI. Если этих данных нет, собирать их нужно на этапе открытия счёта или инициации платежа. Перенос старых текстовых строк в новые поля не решает проблему.
Системы скрининга, настроенные на работу с неструктурированными данными, не начинают работать лучше автоматически после перехода на новый формат. Пороги чувствительности, алгоритмы сопоставления и логика принятия решений требуют полной перекалибровки и тестирования на исторических данных.
При изменении профиля срабатываний структура очереди для ручного разбора также должна быть пересмотрена. Если ложных сигналов становится меньше, операторы будут обрабатывать, например, не 100 алертов в день, а 70. Однако каждый из них, скорее всего, окажется более сложным и требующим внимательного анализа.
Договорённости с банками-корреспондентами о полноте и формате передаваемых реквизитов становятся ещё важнее в условиях переноса сроков, о которых заявила SWIFT. Gока одни участники цепочки готовятся, другие могут откладывать. Если хотя бы один посредник не передаёт страну или LEI, детализация теряется — и эффект от собственной подготовки обнуляется.
Эффект от всех изменений должен быть измерен. До перехода на новые правила необходимо зафиксировать базовые показатели: долю ложных срабатываний, время обработки алерта, долю ручных разборов и сквозной обработки. После внедрения измерение проводится повторно.
Только сопоставление цифр позволяет доказать, что изменения сработали. Без них любой эффект остаётся гипотетическим.
Важно понимать: полная структурированность адреса не является единственным вариантом соответствия. С ноября 2025 года действует гибридный формат, который сочетает структурированные поля с неструктурированными адресными строками. Минимальное требование для гибридного адреса — город и страна. Банку, который не успевает перевести все справочники в полностью структурированный вид, гибридный формат даёт минимально достаточный уровень соответствия.
| Критерий | Скрининг по неструктурированному сообщению | Скрининг по структурированному сообщению (частичное заполнение) | Скрининг по полностью заполненному структурированному сообщению |
|---|---|---|---|
| Что подаётся на вход | Единое текстовое поле (смесь имени, адреса, страны) | Отдельные поля, но часть данных пуста или перенесена текстом | Все поля заполнены: имя, адрес, страна, LEI, purpose code |
| Типовая причина ложного срабатывания | Совпадение названия города с топонимом под санкциями | Отсутствие страны или LEI, транслитерация имени | Минимальна — сопоставление по типизированным полям |
| Возможность правил по юрисдикции | Отсутствует — страна извлекается из текста | Ограничена — если поле страны заполнено, правило работает | Полная — страна известна и структурирована |
| Прозрачность сторон платежа | Стороны смешаны в одном тексте, ошибки идентификации | Частичная — часть сторон выделена, часть нет | Полная — все стороны явно разделены |
| Основное ограничение | Высокий уровень ложных срабатываний (99% от всех алертов) | Формат есть, но данные не обеспечивают его преимуществ | Требует перекалибровки правил и дисциплины данных |
Выводы
Эффективность ISO 20022 для комплаенс-функции зависит от трёх групп факторов, которые необходимо проверить до начала миграции.
Качество собственных справочников контрагентов и процедур сбора данных с клиентов. Структурированный адрес должен формироваться на этапе открытия счёта или инициации платежа, а не генерироваться на выходе из платёжного сообщения.
Измеримые показатели, фиксируемые до и после внедрения: доля ложных срабатываний (false positive rate), среднее время обработки алерта и доля сквозной обработки (STP) по платежам, проходящим скрининг. Без базовых значений эффект останется недоказуемым.
Договорённости с корреспондентами и клиентами о полноте передаваемых реквизитов, в первую очередь структурированного адреса и LEI. Требование структурированных адресов сохраняется — Swift лишь отложила его введение из-за неравномерной готовности отрасли. Новая дата не назначена, но подготовку останавливать нельзя: когда срок будет объявлен, у отрасли может не остаться времени на доработку.
Часто задаваемые вопросы (FAQ)
Снижает ли переход на структурированный формат количество ложных срабатываний автоматически?
Нет. По данным SWIFT, потенциал снижения составляет 25-30% . Однако этот эффект достигается только при полном заполнении структурированных полей и перекалибровке правил скрининга. Без изменений в процессах и данных преимущества формата не реализуются.
Что происходит с детализацией данных, если один из банков в цепочке передаёт сообщение в ограниченном формате?
Детализация теряется. Если банк-посредник не передаёт структурированные поля (например, использует старый формат или переносит данные текстом), конечный получатель не получает структурированную информацию. Это делает скрининг на стороне получателя столь же неточным, как и до миграции платежных систем.
Какие показатели позволяют доказать эффект от миграции для комплаенс-функции?
Доля ложных срабатываний (false positive rate), среднее время обработки алерта, доля платежей, проходящих сквозную обработку (STP) после скрининга, количество ручных разборов. Измерения должны проводиться на сопоставимой выборке до и после внедрения структурированных данных. SWIFT предлагает сервисы тестирования для оценки влияния нового формата на эффективность фильтров
