Банківська інфраструктура

MT103 і pacs.008: у чому різниця старого та нового формату SWIFT

MT103 і pacs.008 без міфів: різниця форматів, що змінилося після CBPR+ coexistence та яке підтвердження платежу просити у банку.

Схема TradePay до теми «MT103 і pacs.008: у чому різниця старого та нового формату SWIFT»
Зображення: Редакція TradePay TradePay Blog — оригінальна редакційна графіка © TradePay. Усі права захищено

MT103 — legacy FIN message для customer credit transfer, а pacs.008 — його ISO 20022 counterpart для FI-to-FI customer credit transfer у CBPR+. Після 22 листопада 2025 року native pacs.008 є цільовим міжбанківським форматом, тоді як звичайний MT103 може проходити лише платний contingency conversion. Клієнтський PDF із назвою MT103 не показує повний технічний маршрут і не гарантує зарахування.

Контрагенти часто просять «скинути MT103» незалежно від формату, яким банки реально обмінялися повідомленнями. Банк може створити pacs.008, а клієнту видати знайоме payment confirmation; інший банк ще приймає legacy instruction і конвертує його перед FINplus. Для пошуку затримки важливі UETR, transaction reference і статус, а не заголовок PDF.

Інформацію та офіційні джерела перевірено 2026-08-02. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.

Межі цього матеріалу

Параметр Сценарій
Хто платить бізнес або приватний клієнт, який ініціює транскордонний банківський платіж
Кому іноземний контрагент або власник рахунку в іншій країні
Мета перевірка формату, статусу чи правил SWIFT та ISO 20022 перед операцією
Валюта / інструмент SWIFT CBPR+, ISO 20022 і повідомлення відповідного платіжного ланцюжка
Що змінює висновок дата релізу, тип повідомлення, банк-учасник, якість адресних і платіжних даних

Що потрібно знати до платежу

Coexistence для payment instructions завершилося

Swift завершив період співіснування MT та ISO 20022 для cross-border payment instructions 22 листопада 2025 року. Від цієї дати ISO 20022 став стандартним форматом обміну для відповідного CBPR+ traffic. (Swift — What happens when payments coexistence ends)

Звичайний MT103 лишився contingency route

Swift відносить MT103 до повідомлень, які можуть пройти chargeable contingency processing: validation, conversion в ISO 20022 і доставку через FINplus. Це відрізняється від MT103 REMIT, який після cutover належить до unsupported і отримує NAK. (Swift — What happens when payments coexistence ends)

pacs.008 переносить структуровані ISO 20022 data

ISO 20022 дає окремі elements для parties, agents, addresses, purpose і remittance information. CPMI пов’язує узгоджене використання таких даних зі зменшенням truncation та кращими straight-through processing, compliance і fraud controls. (BIS/CPMI — Harmonised ISO 20022 data requirements, 2026 update)

Confirmation і settlement — не одне й те саме

Банківська квитанція підтверджує прийняття або відправлення доручення на певному етапі. Фактичне зарахування одержувачу встановлюють за статусом банку, tracking за UETR та підтвердженням beneficiary, особливо якщо платіж затримався.

Як порівняти варіанти

Варіант Коли розглядати Що перевірити до дії
Native pacs.008 Банківський ланцюжок працює в ISO 20022 без legacy conversion Message reference, UETR, збереження party та remittance fields і поточний status
Contingency MT103 Legacy application ще формує eligible MT instruction Conversion fee, validation result, строк підтримки та ризик втрати даних під час mapping
Клієнтське payment confirmation Постачальнику потрібен доказ ініціювання Amount, currency, parties, value date, bank reference, UETR і відсутність зайвих персональних даних

Покрокова підготовка

  1. Уточніть мету запиту. Запитайте контрагента, чи йому потрібне підтвердження відправлення, UETR для tracking, реквізити платежу або доказ фактичного credit.
  2. Отримайте reference та UETR. Збережіть bank transaction reference і UETR відразу після прийняття доручення; вони корисніші для investigation, ніж назва експортованого файла.
  3. З’ясуйте міжбанківський формат. Якщо це важливо для reconciliation або проєкту міграції, попросіть банк підтвердити native pacs.008 чи contingency conversion з MT103.
  4. Звірте дані безпечного підтвердження. Перед передачею постачальнику перевірте amount, currency, beneficiary, value date і reference та приховайте account data, які не потрібні одержувачу.
  5. Відстежуйте затримку за статусом. Якщо кошти не надійшли у звичайний строк, відкрийте investigation у банку з UETR, а не надсилайте повторний платіж лише через відсутність credit.

Які дані та документи зібрати

  • payment confirmation банку з amount, currency, parties, value date і transaction reference
  • UETR для tracking транскордонного платежу
  • статус або відповідь банку щодо acceptance, delivery, reject чи investigation
  • підтвердження beneficiary про credit або виписка, якщо це потрібно для звірки
  • опис банківського каналу та contingency fees для регулярних legacy flows

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

Практичний сценарій

Польський постачальник попросив українського імпортера надіслати MT103 на суму 36 000 EUR. Банк імпортера видав PDF із реквізитами, але support підтвердив, що міжбанківський message був native pacs.008. Імпортер передав постачальнику скорочене confirmation та UETR. Коли credit затримався, обидві сторони використали UETR для investigation замість суперечки про те, чи є документ «справжнім MT103».

Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.

Типові помилки

  • стверджувати, що MT103 і pacs.008 є одним повідомленням лише з різним розширенням файла
  • говорити, що всі MT103 перестали існувати 22 листопада 2025 року без пояснення contingency processing
  • плутати звичайний MT103 з unsupported MT103 REMIT
  • вважати PDF або скриншот доказом остаточного зарахування beneficiary
  • відправляти дублікат платежу до investigation за UETR і перевірки статусу

Де проходить межа поради

Порівняння стосується Swift CBPR+ payment instructions. Клієнтські виписки, domestic rails, банк-клієнт interfaces і назви confirmation documents можуть використовувати інші формати та терміни.

Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.

Як перейти від статті до конкретної заявки

TradePay може використати реквізити й UETR для перевірки конкретної операції, але не називає платіж зарахованим лише на підставі PDF із банківської системи. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.

За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.

Важливо

Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.

Джерела та перевірка

  1. Swift — What happens when payments coexistence ends
  2. Swift — CBPR+ roadmap beyond SR2025
  3. BIS/CPMI — Harmonised ISO 20022 data requirements, 2026 update

Дата редакційної перевірки: 2026-08-02.

TradePay Desk

Перевірте маршрут до відправлення коштів

Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.

Уточнити маршрут Читати в Telegram

Зворотний зв’язок

Наскільки корисним був матеріал?

Оцінка допомагає редакції обирати теми та оновлювати пояснення.