Фальшивий новий постачальник не повинен потрапити до vendor master лише на підставі першого invoice. Незалежно перевірте існування компанії, домен, контакт, договірну підставу, account holder і того, хто всередині бізнесу замовив товар чи послугу.
До AP надходить invoice від нового logistics vendor, але procurement не знаходить замовлення, а домен відрізняється від сайту реальної компанії. Створення vendor master лише за PDF зробить вигадану сторону «перевіреною» для наступних платежів.
Інформацію та офіційні джерела перевірено 2026-08-02. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | компанія або приватний клієнт, який отримав платіжну інструкцію |
| Кому | постачальник, керівник, marketplace або інша сторона, чию особу треба перевірити |
| Мета | запобігання оплаті вигаданому або підміненому новому постачальнику |
| Валюта / інструмент | invoice, банківський переказ, payment link або payout settings |
| Що змінює висновок | company registry, domain age, internal sponsor, beneficial ownership, account holder і urgency |
Що потрібно знати до платежу
BEC може видавати шахрая за знайомого контрагента
FBI IC3 описує impersonation trusted business contacts як спосіб переконати жертву переказати кошти на рахунок зловмисника. Реальна назва компанії та професійний invoice легко копіюються й не замінюють independent vendor verification. (FBI IC3 — Business Email Compromise)
Ключова контрольна умова
Шахрайський vendor може використовувати назву реальної компанії з іншими контактами або рахунком. (FBI IC3 — Business Email Compromise)
Яку доказову нитку зберегти
Реєстраційний запис доводить існування entity, але не доводить, що sender контролює її або має право на конкретний invoice. (NCSC — Business payment fraud)
Що змінює практичний висновок
Внутрішній requester і procurement trail повинні підтвердити, хто замовив послугу та як був обраний постачальник. (TradePay — оплата інвойсів)
Покрокова підготовка
- Знайдіть внутрішнього власника закупівлі. Вимагайте approved request, PO, contract owner, опис поставки та receipt або acceptance. Якщо жоден підрозділ не замовляв товар чи послугу, не створюйте supplier record і відкрийте incident.
- Верифікуйте entity з незалежних джерел. Перевірте registration number у відповідному реєстрі, офіційний домен і контакт, потім підтвердьте account holder поза invoice. Нового vendor додають дві різні особи; uploader не може одноосібно погодити beneficiary.
- Верифікуйте entity й контакт. Перевірте реєстр, офіційний сайт, домен, адресу та зв’яжіться через незалежно знайдений контакт.
- Підтвердьте internal demand. Зіставте purchase request, approver, contract, delivery evidence і bank account holder до першого платежу.
Які дані та документи зібрати
- оригінальне повідомлення з headers, URL або вкладенням у безпечному incident archive
- incident log із часом виявлення, сумою ризику, акаунтами, діями й контактами банку або платформи
- офіційний registry extract та незалежно перевірені контакти vendor
- purchase request, contract і first-payment due diligence checklist
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
До AP надходить invoice від нового logistics vendor, якого ніхто не може назвати. Procurement не знаходить request, домен відрізняється від реальної компанії; платіж блокують і відкривають incident.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- щодо предмета «перевірка нового vendor до першої оплати» перевіряти підозрілий запит відповіддю на той самий лист або номером із нього; наслідок — втрата зв’язку з метою: запобігання оплаті вигаданому або підміненому новому постачальнику
- під час контролю предмета «перевірка нового vendor до першої оплати» чекати завершення внутрішнього розслідування, якщо кошти вже відправлено й банк треба повідомити негайно; окремої оцінки потребують: company registry, domain age, internal sponsor, beneficial ownership, account holder і urgency
- створювати vendor із даних одного PDF
- пропускати due diligence через невелику тестову суму
Де проходить межа поради
Остаточні вимоги залежать від юрисдикції, банку, платіжного провайдера, статусу сторін і призначення операції.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay приймає таку заявку на індивідуальну перевірку; менеджер підтвердить доступність, курс, підсумкову суму, реквізити та орієнтовний строк до оплати. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
Дата редакційної перевірки: 2026-08-02.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.