До створення платежу зберіть точну legal name одержувача, country, town та доступні street, building і postcode. Для CBPR+ з 14 листопада 2026 року щонайменше TownName і Country мають передаватися окремо незалежно від того, подає компанія заявку через pain.001, MT101 чи proprietary bank channel. BIC та адреса банку не замінюють postal address самого постачальника.
Закупівельна команда часто вносить у ERP лише назву постачальника, IBAN і BIC, а адресу копіює з давнього інвойсу одним рядком. Під час першої великої оплати treasury з’ясовує, що місто відсутнє, юридична назва скорочена, а банківський шаблон не переносить нові поля. Збір даних під час supplier onboarding дешевший за термінове виправлення платежу в день відвантаження.
Інформацію та офіційні джерела перевірено 2026-08-02. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | бізнес або приватний клієнт, який ініціює транскордонний банківський платіж |
| Кому | іноземний контрагент або власник рахунку в іншій країні |
| Мета | перевірка формату, статусу чи правил SWIFT та ISO 20022 перед операцією |
| Валюта / інструмент | SWIFT CBPR+, ISO 20022 і повідомлення відповідного платіжного ланцюжка |
| Що змінює висновок | дата релізу, тип повідомлення, банк-учасник, якість адресних і платіжних даних |
Що потрібно знати до платежу
Корпоративний клієнт відповідає за дані кредитора
Swift радить corporates отримувати адресу creditor через власні канали, зберігати структуровані дані у ERP або treasury system і передавати їх під час payment initiation. Банк не може надійно відновити адресу одержувача з одного номера рахунку. (Swift — Removal of unstructured address)
TownName і Country є мінімумом після cutover
Для CBPR+ адрес parties and agents після 14 листопада 2026 року щонайменше TownName і Country мають бути окремими elements. Решта доступних компонентів передається fully structured або частково через дозволений hybrid format. (Swift — Removal of unstructured address)
Вимога не залежить від способу подання заявки
Swift окремо звертає увагу corporates на всі initiation channels, зокрема MT101, pain.001 і proprietary formats. Дані потрібно перевірити на кожному mapping, бо правильний supplier master ще не гарантує їх перенесення до банку. (Swift — Removal of unstructured address)
Гармонізація стосується значення даних, а не лише XML
Оновлені CPMI requirements формують спільну baseline для cross-border payment data. Послідовні party та address elements потрібні, щоб зменшити truncation і ручний repair між різними системами та юрисдикціями. (BIS/CPMI — Harmonised ISO 20022 data requirements, 2026 update)
Як порівняти варіанти
| Варіант | Коли розглядати | Що перевірити до дії |
|---|---|---|
| Дані від постачальника | Створюється або оновлюється supplier master | Legal name, registered address, town, country, postcode, account number і bank identifier в одному підтвердженні |
| Дані з реєстру | Потрібно звірити юридичну особу та країну реєстрації | Точну entity, актуальний статус і відмінність registered address від payment contact |
| Уточнення банку | Невідомі channel-specific mandatory fields | Підтримуваний format, field mapping, symbols, length і production release |
Покрокова підготовка
- Надішліть стандартний запит постачальнику. Попросіть legal name без маркетингових скорочень, registered postal address, town, country, postcode, IBAN або account number, BIC і назву банку.
- Звірте одержувача з договором. Порівняйте назву та адресу з контрактом, інвойсом і надійним реєстром; розбіжність поверніть procurement та постачальнику до платежу.
- Заповніть окремі поля master data. Збережіть town і country окремо від street lines, визначте джерело кожного значення та дату останнього підтвердження.
- Перевірте всі способи відправлення. Сформуйте тест через pain.001, MT101 або bank portal, якими реально користується компанія, і переконайтеся, що creditor address не обрізається.
- Запровадьте повторну перевірку змін. Будь-яку заміну рахунку, BIC чи адреси підтверджуйте через відомий контакт постачальника, а не відповіддю на лист із новими реквізитами.
Які дані та документи зібрати
- supplier-data form із legal name, registered address, town, country, postcode, account та BIC
- договір та актуальний інвойс із тією самою юридичною особою
- витяг із надійного business register для перевірки entity та address
- запис незалежного callback або іншої перевірки змінених банківських реквізитів
- результат тестового mapping з ERP до кожного робочого bank channel
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
Український дистриб’ютор мав оплатити обладнання французькому виробнику. У старій картці були IBAN, BIC і торговий бренд, але не було міста, а адреса зберігалася одним рядком. Procurement отримав нову форму від фінансового відділу постачальника, звірив legal entity з договором і підтвердив зміну реквізитів через відомий телефон. Treasury внесла Lyon і FR в окремі поля та перевірила pain.001 у тестовому каналі до дати оплати.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- вважати IBAN і BIC достатнім набором даних про одержувача
- копіювати адресу з першого результату пошуку або старого інвойсу без підтвердження постачальника
- зберігати town і country тільки всередині одного address line
- підміняти адресу creditor адресою його банку
- приймати змінені реквізити з листа без незалежної перевірки відомим каналом
Де проходить межа поради
Точний набір полів залежить від країни, платіжної схеми, банку та типу повідомлення. Чекліст не замінює customer due diligence і не підтверджує, що надіслані реквізити належать контрагенту без окремої перевірки.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay може перевірити наданий комплект реквізитів і запитати відсутні дані перед розрахунком маршруту; джерелом юридичної адреси лишається сам контрагент або надійний реєстр. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
- Swift — Removal of unstructured address
- BIS/CPMI — Harmonised ISO 20022 data requirements, 2026 update
Дата редакційної перевірки: 2026-08-02.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.