Verification of Payee повертає результат порівняння введеного IBAN з name account holder до платежу. Match означає збіг; Close Match — схоже, але не тотожне ім’я; No Match — суттєву невідповідність; Other охоплює випадки, коли однозначне порівняння не виконано. Жоден response не змінює реквізити автоматично й не гарантує чесність одержувача.
Платник вводить «Acme Shop», а account належить «ACME Trading GmbH». Close Match може відображати торгову назву, помилку або зовсім іншу компанію. Якщо сервіс повертає suggested name, його не слід сліпо приймати: контрагент має незалежно підтвердити legal entity та IBAN.
Інформацію та офіційні джерела перевірено 2026-08-02. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | власник рахунку або компанія, що ініціює платіж у євро |
| Кому | фізична чи юридична особа з рахунком у зоні доступності схеми |
| Мета | перевірка схеми SEPA, швидкості, VOP і правил конкретного PSP |
| Валюта / інструмент | SCT, SCT Inst, VOP або миттєвий переказ СЕП України залежно від теми |
| Що змінює висновок | країна PSP, участь у схемі, валюта рахунку, effective date і доступність у провайдера |
Що потрібно знати до платежу
VoP працює до initiation
PSP інформує платника про discrepancy між account identifier і intended payee name до авторизації credit transfer, щоб знизити ризик misdirection та fraud. (EPC — Verification of Payee)
EPC передбачає кілька outcome categories
Клієнтський flow розрізняє Match, Close Match, No Match та інші responses, а не зводить перевірку до одного pass/fail indicator. (EPC — Verification of Payee)
VoP застосовується до SCT і SCT Inst
IPR вимагає payee verification як для standard, так і для instant euro credit transfers; speed rail не змінює сенс name check. (EPC — Verification of Payee)
Technical unavailable не є No Match
Якщо запит не виконався через timeout, unreachable PSP або invalid input, система не має доказу невідповідності імені. Такий стан потребує окремого пояснення та рішення платника.
Як порівняти варіанти
| Варіант | Коли розглядати | Що перевірити до дії |
|---|---|---|
| Match | Name і account identifier узгоджені за правилами сервісу | Суму, призначення та legitimacy request незалежно від збігу |
| Close Match | Є близьке написання або returned name | Legal name, trade name, typo та підтвердження beneficiary |
| No Match або Other | Збігу немає чи verification не завершена | Причину response, account details і безпечний контакт до авторизації |
Покрокова підготовка
- Вводьте ім’я з надійного документа. Копіюйте legal name з договору або підтверджених реквізитів, не з display name у месенджері.
- Прочитайте точну category. Розрізніть Close Match, No Match, unavailable та invalid request; колір банера не замінює текст response.
- Порівняйте returned name. Якщо PSP показує suggested value, звірте його з legal entity і не приймайте автоматичну заміну без контакту.
- Підтвердьте розбіжність іншим каналом. Зателефонуйте за відомим номером або використайте раніше погоджений контакт, особливо після зміни IBAN.
- Збережіть рішення платника. Для business payment зафіксуйте response, хто дозволив continuation і яке evidence пояснює mismatch.
Які дані та документи зібрати
- VoP response із category та timestamp
- договір або invoice з legal beneficiary name
- первинне підтвердження IBAN від одержувача
- запис callback для close/no match
- approval record, якщо платіж продовжено після warning
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
Компанія вводила назву польського перевізника зі скороченням і отримала Close Match із повною назвою sp. z o.o. Procurement звірив її з договором і польським реєстром, потім підтвердив IBAN за старим номером телефону. Платіж дозволили з документованим поясненням. Через тиждень No Match для іншого рахунку зупинив підміну реквізитів у зламаній email thread.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- трактувати Close Match як автоматичний дозвіл на відправлення
- замінювати beneficiary name на suggested value без перевірки
- вважати technical unavailable доказом шахрайства або No Match
- ігнорувати Match і не перевіряти purpose та суму
- продовжувати після warning без запису, хто підтвердив реквізити
Де проходить межа поради
Алгоритми normalization та customer display відрізняються між VOP implementations. Response є risk signal до платежу, а не підтвердження identity, contractual entitlement або final credit.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay враховує доступний name-check response і просить пояснити mismatch; сервіс не підміняє незалежне підтвердження реквізитів контрагента. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
Дата редакційної перевірки: 2026-08-02.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.