З 14 листопада 2026 року CBPR+ прийматиме для сторін та агентів лише fully structured або hybrid postal address. Щонайменше TownName і Country мають передаватися в окремих елементах. Бізнесу потрібно виправити адреси контрагентів у master data та протестувати їх у кожному банківському каналі до cutover.
У багатьох ERP місто, індекс, вулиця й країна досі зберігаються одним рядком. Такий запис може нормально виглядати в інвойсі, але після перетворення на CBPR+ повідомлення не дає банку окремих TownName і Country. Особливо ризикують компанії з великим каталогом постачальників та кількома форматами відправлення: portal, host-to-host, pain.001 і MT101.
Інформацію та офіційні джерела перевірено 2026-08-03. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | бізнес або приватний клієнт, який ініціює транскордонний банківський платіж |
| Кому | іноземний контрагент або власник рахунку в іншій країні |
| Мета | перевірка формату, статусу чи правил SWIFT та ISO 20022 перед операцією |
| Валюта / інструмент | SWIFT CBPR+, ISO 20022 і повідомлення відповідного платіжного ланцюжка |
| Що змінює висновок | дата релізу, тип повідомлення, банк-учасник, якість адресних і платіжних даних |
Що потрібно знати до платежу
Повністю неструктурована адреса припиняє бути допустимою
Swift встановив 14 листопада 2026 року як дату, після якої у CBPR+ дозволені fully structured або hybrid postal addresses. Для адрес agents and parties TownName і Country мають бути передані в окремих полях щонайменше. (Swift — Removal of unstructured address)
Окремого contingency для невалідної адреси немає
Swift попереджає, що для non-compliant postal address не передбачено спеціального механізму продовження обробки. Повідомлення з відсутніми або неправильно структурованими даними можуть бути відхилені чи затримані в платіжному ланцюжку. (Swift — Call-to-action for November 2026)
Cutover входить до Standards Release 2026
Календар Standards Release 2026 розділяє публікацію usage guidelines, schemas, pilot testing та production activation. Це дає банкам і корпоративним клієнтам окремі вікна для розробки, перевірки mapping і переходу. (Swift — Standards releases)
Виправляти треба джерело даних
Ручне редагування однієї платіжної форми не усуває дефект у supplier master. Стійке рішення починається з окремих полів міста й країни в ERP, після чого перевіряється їх перенесення до повідомлення банку.
Як порівняти варіанти
| Варіант | Коли розглядати | Що перевірити до дії |
|---|---|---|
| Fully structured address | ERP зберігає компоненти адреси окремо | TownName, Country та інші доступні structured elements без AdrLine |
| Hybrid address | Частина адреси ще надходить в AddressLine | Окремі TownName і Country, не більше дозволеної кількості AddressLine та підтримка банком |
| Платіж після виправлення | Місто або країну неможливо надійно визначити | Оновлені реквізити від контрагента, а не припущення бухгалтера |
Покрокова підготовка
- Знайдіть неструктуровані записи. Вивантажте активних іноземних одержувачів і позначте адреси, де місто та країна сховані в одному вільному рядку або відсутні.
- Запитайте дані у контрагентів. Отримайте legal name, country, town, street, building і postcode безпосередньо від одержувача та звірте їх з інвойсом і банківськими реквізитами.
- Оновіть mapping каналів. Перевірте, як ERP, pain.001, MT101 option F і proprietary portal передають TownName та Country; один правильний екран не доводить правильність downstream message.
- Пройдіть негативні тести. Надішліть у test environment валідний structured приклад, hybrid приклад і повідомлення без міста, щоб команда побачила фактичні validation responses.
- Закрийте cutover-план. Призначте owner для supplier master, bank formats і production monitoring, а також погодьте спосіб виправлення та повторної відправки rejected payment.
Які дані та документи зібрати
- експорт supplier master з окремими полями legal name, town, country, street і postcode
- актуальні реквізити та підтвердження адреси від кожного критичного одержувача
- field mapping ERP → bank channel → CBPR+ message для всіх способів відправлення
- test evidence з accepted і rejected address examples та кодами validation
- cutover checklist із власниками, датами, rollback і процедурою payment repair
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
Український імпортер обладнання мав у ERP адресу чеського постачальника одним рядком: назва вулиці, Брно, індекс і CZ. Під час pilot test банк показав, що Country передається окремо, а TownName лишається порожнім. Компанія запросила структуровані реквізити, рознесла адресу в supplier master і повторила тест через pain.001. До production залишився контрольний звіт, а не усна обіцянка розробника.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- плутати SWIFT cutover 14 листопада з окремими датами SEPA rulebooks
- копіювати місто й країну в AddressLine, залишаючи TownName та Country порожніми
- виправити bank portal, але не змінити ERP, host-to-host file і MT101 template
- вигадувати місто за поштовим індексом замість отримання підтвердження від beneficiary
- очікувати, що будь-яка невалідна адреса буде автоматично виправлена посередником
Де проходить межа поради
Вимога стосується postal address у визначеному CBPR+ scope, а не всіх реквізитів кожного внутрішнього платежу. Конкретний customer channel, формат ініціації та readiness підтверджує банк, який приймає інструкцію.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay може перевірити платіжну заявку та реквізити одержувача перед вибором маршруту; доступність, підсумкова сума й орієнтовний строк підтверджуються індивідуально. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
- Swift — Removal of unstructured address
- Swift — Call-to-action for November 2026
- Swift — Standards releases
Дата редакційної перевірки: 2026-08-03.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.