MT → MX: дедлайн уже идёт. Банку нужен контролируемый переход без переделки всего канала.
Эпоха текстового SWIFT MT для трансграничных инструкций закрыта по календарю CBPR+. Впереди жёсткие требования к структуре данных — особенно к адресу. Промедление = плата за перевод, возвраты и риск предписаний.
Ключевой ориентир: 14 ноября 2026 — неструктурированный адрес в CBPR+ больше не принимается
Конфиденциально · пилот odgiso20022.mx
Календарь SWIFT / CBPR+
Что уже произошло и что осталось
22 ноября 2025
Конец coexistence
Совместное «легальное» существование MT и MX для инструкций CBPR+ завершено. MX — основной формат.
С 1 января 2026
Платный contingency
Перевод MT→MX «на лету» и contingency-обработка у SWIFT — платные услуги. Чем дольше тянете — тем дороже операционный хвост.
14 ноября 2026
Адрес только structured / hybrid
Неструктурированный адрес — отказ на уровне сети (NAK). Contingency для адреса SWIFT не даёт.
Для банка в Казахстане это не «чужая европейская тема»: любой платёж по коридору SWIFT идёт в ту же схему.
Цена задержки
Где банк теряет деньги и репутацию
Прямые и косвенные затраты
Счета SWIFT за in-flow translation / contingency
Repair fee и запросы корреспондентов
Ручная доводка сообщений в операциях
Возвраты клиенту → жалобы, отток
Регулятор и надзор
Риск предписаний и штрафов за неготовность канала к формату
Неверный / неполный MX при проверках качества данных
Давление по операционной устойчивости трансграничных платежей
Формулировка для встречи: мы снижаем риск формата и операционных потерь. Мы не обещаем «обнулить все санкции регулятора» — решение и комплаенс остаются у банка.
Ловушка «просто поставим транслятор»
Транслятор MT→MX не создаёт данные, которых не было
Клиент ввёл адрес одной строкой, без города/индекса/страны по полям — транслятор не «угадает» структуру CBPR+.
Нет purpose code, UETR, разнесённого адреса — на выходе «бедный» MX и высокий шанс query / return.
Переписать весь интернет-банк и все корпоративные каналы за месяцы — дорого и рискованно для релиза.
Нужен контролируемый мост: качество данных в точке ввода + готовый MX, без CAPEX «всё сразу».
Решение
Что даёт программа ODG-PASS
ODG-PASS формирует корректные структурированные платёжные данные — от клиента к банку.
Клиент (или операционист) заполняет поля ISO 20022, а не «свободный текст».
Проверка до отправки: IBAN, BIC, обязательные элементы, адрес, назначение.
Выход: pain.001 (инициация) и pacs.008 (межбанк) — один набор данных.
Светофор 🟢🟡🔴 — подсказка по полю; исполнение платежа — в вашем банке.
Экономика для банка
Экономия внедрения и уход от штрафов за формат
Меньше CAPEX на срочный рефакторинг
Не надо сразу переписывать весь ДБО
Validation API: кнопка «Проверить» в существующем интернет-банке
Или терминал / мост для корпоратов на период миграции
Пилот на 1 канал / 1 коридор — измеримый старт
Основной CAPEX на «все экраны сразу» можно разнести во времени
Ниже штрафы и операционные потери
Риск формата ↓
Меньше MX с дырами в структуре → меньше оснований для претензий надзора по качеству данных
Меньше зависимости от платного SWIFT-перевода «на лету»
Меньше repair / возвратов из‑за адреса и полей
Готовность к дедлайну 14.11.2026 по structured address
Итог в одном числе для CFO: стоимость модуля и пилота ≪ стоимость срочной переделки всех каналов + плата за contingency + repair.
Подробнее · что именно закрываем
Слой данных до вашего ядра
Клиентский контур
Структурированный адрес (улица, дом, город, индекс, страна)
Purpose code + описание
EndToEndId + UETR
IBAN MOD-97 · BIC ISO 9362
Понятное «исправьте поле X»
Артефакты для банка
pain.001.001.09 — инициация клиент→банк
pacs.008.001.08 — FI-to-FI слой
Совместимость с проверками CBPR+
Не подменяет AML/CFT банка
Не блокирует платёж — только сигнал
Сигнал для клиента и операций
Светофор — guidance, не вердикт банка
🟢
Структура готова
Данные согласованы. Отправку клиент делает у вас.
🟡
Уточнить
Есть замечания (адрес, референс, путь) — не запрет.
🔴
Исправить поле
Конкретное поле до попадания в ваш конвейер.
Для ИБ и compliance: мы не принимаем решение по платежу и не заменяем ваш screening.
Доказательство · июль 2026
MX из терминала проходит внешние схемы
✓ XSD + usagepain.001 · SWIFT CBPR Star
✓ XSD + usagepacs.008 SR2026 · SWIFT CBPR Star
✓ OKНезависимый ISO 20022 validator
Аргумент для IT: это не «красивый демо-XML», а структура, которую принимает внешняя проверка CBPR+ до вашего конвейера.
Модель внедрения
Быстрый старт без ключей банка — и пилот внутри
Mode 1 · сегодня
Публичный gateway
Демо и обучение на odgiso20022.mx. Без секретов банка. Показать бизнесу и операциям «как выглядит MX» за 30 минут.
Mode 2 · пилот
В периметре банка
Validation API в VPC / интернет-банке. Клиент не уходит с сайта банка. Sandbox-ключи только у вас.
Клиент в ДБО → «Проверить / Подготовить MX»
↓
ODG-PASS Validation (контур банка или API)
↓ 🟢🟡🔴 + pain.001 / pacs.008
Ваш ingest → ядро / SWIFT
(исполнение только у банка)
Казахстан
Почему это релевантно банку в РК
Трансграничные платежи клиентов идут в SWIFT CBPR+ — календарь дедлайнов общий.
Давление на качество MX и адрес к ноябрю 2026 — отдельный проект, если канал всё ещё «как MT».
СМБ и корпораты вводят данные вне полного контроля банка — ODG закрывает именно эту дыру.
Пилот можно ограничить одним коридором (EU / GCC / Азия) и одним продуктом ДБО — без «большого взрыва».
Границы ответственности
Честный периметр для ИБ и надзора
Не зона ODG-PASS
Исполнение и клиринг
Живой AML / санкционный screening банка
Подмена решения compliance
Хранение sandbox-ключей на публичном сайте
Зона ODG-PASS
Структура ISO 20022 (pain / pacs)
Проверка полей до отправки
Снижение риска формата и repair
Мост миграции без полного CAPEX сразу
Пилот · 4 шага
Как стартовать до ноября 2026
1. NDA · этот бриф + техпакет for-banks
2. Демо 45 мин: ошибка → 🔴 → исправление → CBPR ✓
3. Security review: зоны доверия, API в песочнице
4. Узкий пилот · метрики: доля MX без repair, готовность адреса к 14.11.2026
Цель: снизить стоимость перехода и убрать форматные основания для претензий — измеримо.