Бухгалтер архітектурної фірми з 12 співробітників отримує лист, який виглядає точнісінько так, ніби його надіслав керуючий партнер: перекажіть $47 000 на новий рахунок постачальника сьогодні ж, це терміново, ми закриваємо питання з платою за дозволи. Вона надсилає переказ. Через двадцять хвилин справжній партнер проходить повз її стіл і запитує, чому досі не сплачено за дозволи. Гроші зникли — переказані на рахунок в іншому штаті й конвертовані в криптовалюту протягом години. Вона телефонує в банк, очікуючи такого ж захисту, який отримала б, якби її особисту дебетову картку шахрайськи використали на заправці. Такого захисту для банківських переказів компаній не існує — і юридична причина цього майже невідома жодному власнику малого бізнесу.
У споживачів є Regulation E — федеральне правило, що реалізує Electronic Fund Transfer Act, яке обмежує відповідальність споживача за несанкціоновані перекази та зобов'язує банки тимчасово зараховувати оспорювані суми на час розслідування. Бізнес такого захисту не має. Комерційні банківські перекази регулюються іншим, старішим і значно менш поблажливим зводом законів: Article 4A Uniform Commercial Code (UCC). Розуміння різниці між цими двома режимами — і того, що насправді потрібно, щоб перекласти відповідальність назад на банк, — це різниця між поверненням шахрайського переказу та списанням збитку на власний рахунок.
Чому Regulation E тут не діє
Захист за Regulation E повністю побудований навколо одного слова: "споживач". Це правило охоплює електронні перекази коштів за участю споживчого рахунку — особистого поточного, особистого ощадного та подібних рахунків, що використовуються переважно для особистих, сімейних чи домашніх потреб. Щойно рахунок стає бізнес-рахунком, а кошти переказуються банківським переказом, дія EFTA та Regulation E повністю припиняється, і натомість застосовується UCC Article 4A.
Article 4A був написаний спеціально для комерційної системи переказу коштів — Fedwire, CHIPS та мережі банків-кореспондентів, що щодня переміщують трильйони доларів між компаніями. Він застосовується виключно до комерційних платіжних доручень і був створений із свідомим компромісом у політиці: оскільки банківські перекази переміщують величезні суми практично миттєво, а остаточність розрахунків має надзвичайне значення для банківської системи, закон покладає більшу частину тягаря запобігання шахрайству на бізнес-клієнта, ніж споживче законодавство покладає на фізичних осіб. Тут немає права на chargeback (оскарження платежу). Немає обов'язкового тимчасового зарахування коштів на час розслідування спору. Немає регуляторного обмеження того, яку суму несанкціонованого переказу бізнес може бути змушений покрити.
Правило, яке визначає, хто покриває збиток
Основне положення Article 4A щодо відповідальності — яке часто цитують як UCC § 4A-202 — на папері звучить нейтрально, а на практиці є безжальним. Якщо банк і його бізнес-клієнт заздалегідь погодили процедуру безпеки для авторизації доручень на переказ, ця процедура є "комерційно обґрунтованою", і банк справді сумлінно дотримувався її під час обробки шахрайського переказу, — збиток лягає на клієнта, навіть якщо переказ насправді ніхто в компанії не авторизував.
Є лише один вихід: клієнт може уникнути відповідальності, довівши, що шахрайство вчинила особа, яка не має жодного стосунку до бізнесу клієнта — жодних скомпрометованих облікових даних співробітників, жодної причетності інсайдера, нічого, що походило б із внутрішніх систем чи персоналу компанії. У випадку шахрайства через компрометацію ділової електронної пошти (BEC) це, як правило, довести неможливо, адже сама схема шахрайства ґрунтується на компрометації або підробці чогось усередині компанії (поштової скриньки співробітника, стосунків із постачальником, звичного стилю спілкування керівника). Закон, по суті, виходить із того, що якщо банк виконав свою роботу, а витік стався десь в орбіті клієнта, збиток несе клієнт.
Що насправді означає "комерційно обґрунтована" процедура
Це формулювання має зрозуміти кожен власник бізнесу, який бореться за відшкодування збитку від шахрайства з переказом, адже саме навколо нього точиться вся боротьба. Суди не запитують, чи була процедура безпеки банку найкращою з доступних технологій, — вони запитують, чи була вона обґрунтованою з огляду на типові патерни транзакцій саме цього клієнта, на ті варіанти безпеки, які банк справді пропонував, і на те, що використовують банки та клієнти в подібному становищі.
Знакову справу, Patco Construction Co. v. People's United Bank (1st Cir. 2012), варто знати хоча б у загальних рисах. Облікові дані компанії, що займається будівництвом, для доступу до онлайн-банкінгу було скомпрометовано, і система банку — попри наявність інструментів, які могли б позначити ці транзакції як незвичайні, — схвалила серію шахрайських переказів, тому що застосовувала однакову, малозахищену процедуру безпеки до кожного клієнта незалежно від типового розміру чи патерну його транзакцій. Апеляційний суд першого округу (First Circuit) постановив, що процедури банку не були комерційно обґрунтованими саме тому, що уніфікований підхід "один розмір для всіх" не відповідає вимозі Article 4A оцінювати безпеку з урахуванням обставин конкретного клієнта — і йдеться не просто про те, "чи використовувався якийсь метод автентифікації", а про те, "чи відповідав цей рівень захисту тому, що зазвичай робить саме цей клієнт".
Практичний урок діє в обидва боки. Якщо ваш банк пропонував вам посилену автентифікацію — подвійну авторизацію, підтвердження зворотним дзвінком, сповіщення про ліміти транзакцій, підтвердження новим отримувачам через окремий канал зв'язку — а ви відмовилися від неї заради зручності, це рішення послаблює вашу позицію, якщо вас пізніше обдурять і ви спробуєте довести, що процедури банку були недостатніми. Компанії, які приймають кожен опційний рівень безпеки, запропонований їхнім банком, тим самим формують доказову базу, яка знадобиться їм, якщо колись доведеться відстоювати позицію у спорі за § 4A-202.
Термін, який знищує більшість позовів ще до їх подання
Навіть законна, доказова претензія щодо шахрайства може загинути через формальність: Article 4A надає клієнтам до одного року з моменту повідомлення, щоб оскаржити банківський переказ, але це лише типовий (default) термін, який сторони можуть скоротити за угодою — і більшість банківських угод про перекази саме так і роблять, зазвичай скорочуючи його до 30 чи 60 днів. Пропустіть це вікно — і транзакція стає остаточною незалежно від того, наскільки очевидно вона була несанкціонованою.
Це настільки ж питання бухгалтерського обліку та внутрішніх процесів, наскільки й юридичне питання. Бізнес, який звіряє свої банківські рахунки щомісяця, а не щотижня чи щодня, може легко витратити весь 30-денний договірний термін повідомлення ще до того, як хтось узагалі помітить шахрайський переказ у виписці. Частота звірки рахунків — це інструмент контролю відповідальності за шахрайство, а не просто вправа на точність — чим швидше виявляється розбіжність, тим більше юридичних варіантів залишається для повернення коштів.
Пастка з номером рахунку, що стоїть за більшістю збитків від BEC
Одне з положень Article 4A пояснює, чому схеми компрометації ділової електронної пошти настільки ефективні й так важко піддаються скасуванню. Коли доручення на переказ містить і ім'я отримувача, і номер рахунку, а на боці отримувача вони насправді не збігаються, банк-отримувач має законне право покладатися лише на номер рахунку — він не зобов'язаний перевіряти, чи відповідає ім'я цьому рахунку. Шахраї постійно цим користуються: підроблений лист вказує справжнє ім'я постачальника, але шахрайський номер рахунку, переказ здійснюється під начебто легітимним ім'ям і потрапляє на рахунок, який контролює зловмисник. Оскільки банк-отримувач із погляду закону не зробив нічого протиправного, застосувати до нього санкції практично неможливо, і боротьба знову зводиться до питання, чи були процедури безпеки банку-відправника комерційно обґрунтованими від самого початку.
Центр скарг на інтернет-злочини ФБР (IC3) зафіксував 24 768 скарг на компрометацію ділової електронної пошти у 2025 році із заявленими збитками у $3,05 мільярда — порівняно з $2,77 мільярда роком раніше — і 86% цих шахрайських платежів пройшли через банківський переказ або ACH, тобто минули всі попередні рівні банківського контролю, не викликавши жодного сповіщення. Такий обсяг існує саме тому, що правова база настільки ускладнює повернення коштів після шахрайського переказу, щойно гроші вже переміщено.
Що це означає для обліку та контролю банківських переказів
Оскільки закон надає такого великого значення процесу, внутрішній контроль над тим, хто може ініціювати переказ і як він перевіряється, — це не просто найкраща операційна практика, а докази, які знадобляться вам у спорі за § 4A-202. Кілька практик мають значно більшу вагу, ніж усвідомлює більшість власників бізнесу:
- Використовуйте кожен рівень автентифікації, який пропонує ваш банк, навіть незручні. Відмова від посиленого захисту заради швидкості — це та єдина модель поведінки, яка найпослідовніше підриває майбутню претензію щодо шахрайства.
- Вимагайте подвійної авторизації для будь-якого нового отримувача або будь-якої зміни банківських реквізитів наявного отримувача, підтвердженої через канал, відмінний від електронної пошти — телефонний дзвінок на відомий номер, а не той, що вказаний у самому підозрілому листі.
- Звіряйте банківські рахунки щонайменше щотижня, якщо бізнес регулярно здійснює перекази. 30-денний договірний термін повідомлення — це проблема не місячного закриття обліку, а середини місяця, якщо шахрайство сталося на початку циклу.
- Ведіть чіткий, датований запис кожного рішення щодо авторизації переказу — хто його схвалив, яким каналом, на підставі якої перевірки. Якщо спір коли-небудь зведеться до питання "чи була процедура банку комерційно обґрунтованою і чи дотримувалися ви власного узгодженого процесу", бізнес із чіткими записами матиме аргументи на свою користь; бізнес без них — ні.
Чіткі, добре промарковані записи транзакцій важливі й з більш прозаїчної причини: точне знання того, коли було надіслано переказ, з якого рахунку і проти якого рахунку-фактури його звірено, — це те, що дозволяє бухгалтеру помітити аномалію за дні, а не за тижні. Текстові, версійовані облікові книги Beancount.io перетворюють кожну транзакцію — включно з вихідними переказами — на датований, придатний для аудиту запис, а не на рядок, загублений у щомісячному PDF-файлі банківської виписки, а саме така прозорість і скорочує проміжок часу між "шахрайство сталося" та "ми його виявили". Почніть безкоштовно і ведіть свої фінансові записи достатньо точно, щоб виявляти проблеми до того, як договірний термін повідомлення закриє двері до їх виправлення.