У fully structured address кожен компонент передається у власному полі, а AdrLine не використовується. Hybrid address залишає до двох рядків AdrLine для частини реквізитів, але TownName і Country все одно мають бути окремими. З 14 листопада 2026 року CBPR+ не прийматиме повністю неструктуровану адресу.
Постачальник може надіслати коректну на вигляд адресу одним рядком: «Kaiserstrasse 12, 60311 Frankfurt, Germany». Для інвойсу цього достатньо, але платіжний файл має розкласти щонайменше місто й країну по окремих ISO 20022 elements. Якщо ERP не має всіх структурованих полів, hybrid format дає перехідний варіант без вигадування відсутніх даних.
Інформацію та офіційні джерела перевірено 2026-08-03. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | бізнес або приватний клієнт, який ініціює транскордонний банківський платіж |
| Кому | іноземний контрагент або власник рахунку в іншій країні |
| Мета | перевірка формату, статусу чи правил SWIFT та ISO 20022 перед операцією |
| Валюта / інструмент | SWIFT CBPR+, ISO 20022 і повідомлення відповідного платіжного ланцюжка |
| Що змінює висновок | дата релізу, тип повідомлення, банк-учасник, якість адресних і платіжних даних |
Що потрібно знати до платежу
Structured address не використовує AdrLine
Swift визначає fully structured address як набір окремих postal address elements. У такому форматі назву вулиці, номер будинку, індекс, місто й країну передають у відповідних полях, а вільний елемент AdrLine не заповнюють. (Swift — Removal of unstructured address)
Hybrid зберігає не більше двох вільних рядків
Hybrid address поєднує structured elements із максимум двома AdrLine. TownName і Country залишаються обов’язковими окремими елементами, тому перенести всю адресу у два вільні рядки не можна. (Swift — Removal of unstructured address)
Unstructured format припиняється 14 листопада
Після production activation Standards Release 2026 у CBPR+ дозволятимуться fully structured та hybrid addresses. Swift не передбачає окремого contingency для повідомлень, які не відповідають новому address format. (Swift — Call-to-action for November 2026)
Одна адреса може мати два валідні представлення
Реквізити одержувача можна передати fully structured, якщо ERP знає всі компоненти, або hybrid, якщо частина будівлі чи району доступна лише як text line. В обох випадках місто Frankfurt і країна DE мають потрапити у власні поля.
Як порівняти варіанти
| Варіант | Коли розглядати | Що перевірити до дії |
|---|---|---|
| Fully structured | Усі компоненти адреси доступні в master data | AdrLine порожній, а street, building, postcode, TownName і Country розкладені по своїх полях |
| Hybrid | ERP не може надійно розділити окремі деталі будівлі або району | Не більше двох AdrLine та обов’язкові окремі TownName і Country |
| Повернення реквізитів на уточнення | Невідоме місто, країна або юридична адреса суперечить інвойсу | Нове підтвердження від одержувача замість автоматичного розбору сумнівного рядка |
Покрокова підготовка
- Розділіть адресу на компоненти. Винесіть із реквізитів legal name, street name, building number, postcode, town і country; не змінюйте написання за власним припущенням.
- Оберіть формат за якістю даних. Використайте fully structured representation, якщо кожен компонент підтверджений. Якщо неподільною лишається лише частина адреси, сформуйте hybrid representation.
- Створіть два тестові повідомлення. На вигаданому одержувачі сформуйте structured і hybrid versions однієї адреси та порівняйте XML, який фактично отримує банк.
- Додайте негативний тест. Приберіть TownName або перенесіть Country в AdrLine, щоб переконатися, що локальна validation ловить дефект до відправлення у Swift.
- Перевірте обмеження банківського каналу. Підтвердьте з банком підтримку hybrid address, допустимі символи й довжину полів для portal, file upload та host-to-host окремо.
Які дані та документи зібрати
- підтверджені реквізити одержувача з legal name і повною postal address
- mapping таблиця між полями ERP, pain.001 або MT101 і CBPR+ address elements
- XML-приклади fully structured та hybrid address на вигаданих даних
- validation results для позитивних і негативних address tests
- письмові обмеження банку щодо AdrLine, символів і максимальної довжини полів
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
Бухгалтерія імпортера отримала від німецького постачальника адресу одним рядком. ERP уже мала окремі country і postcode, але назва вулиці з номером зберігалася разом. Команда не стала вгадувати будову рядка: запросила місто, записала Frankfurt і DE окремо, а street details тимчасово передала як одну AdrLine у hybrid address. Після тесту банк підтвердив валідність файлу, а supplier master поставили в чергу на повну структуризацію.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- називати hybrid будь-яку адресу, розбиту на два вільні рядки без окремих TownName і Country
- одночасно заповнювати AdrLine та ті самі street details у structured elements
- автоматично визначати країну за мовою або доменом постачальника
- використовувати реальні персональні дані в прикладах для test environment
- перевіряти лише вигляд банківської форми, не переглядаючи створене повідомлення або validation response
Де проходить межа поради
Правила стосуються postal address у Swift CBPR+ після SR2026. Конкретний corporate channel може вимагати додаткові поля або мати власні технічні обмеження, які підтверджує обслуговуючий банк.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay може перевірити повноту реквізитів для доступного маршруту, але не доповнює адресу контрагента непідтвердженими даними. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
Дата редакційної перевірки: 2026-08-03.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.