Банки вимагають від FDIC покласти перевірку гаманців на емітентів стейблкоїнів

Будь-який інженер, який будував конвеєр перевірки санкцій, знає неприємну правду: контурний цикл працює лише тоді, коли ви бачите транзакцію до її завершення. Стейблкоїни розраховуються за секунди через кордони, і FDIC щойно витратив цикл коментарів, виявляючи, що його підконтрольні банки не можуть бачити більшість того, що потребує перевірки. Коментарі, подані минулого тижня, явно вказують на цю прогалину, а операційні наслідки лягають безпосередньо на інженерні команди емітентів.

Суть проблеми

Запропоноване FDIC нормотворення включає зобов'язання FinCEN і OFAC у власну наглядову базу для дозволених емітентів платіжних стейблкоїнів, афільованих з небанківськими членами штату та ощадними асоціаціями штату. Як повідомляє PYMNTS.com, коментарний період завершився у вівторок 4 серпня 2026 року, і відповіді несуть спільне послання: банки підтримують регульований випуск стейблкоїнів, але відмовляються нести відповідальність за активність гаманців, яку вони не можуть спостерігати.

Незалежна асоціація громадських банкірів Америки (ICBA) провела чітку межу. Громадський банк, що веде резервні або операційні рахунки, повинен контролювати власних клієнтів, рахунки та транзакції. Він не повинен контролювати вторинно-ринкові перекази, активність на рівні гаманців або специфічні ризики продукту поза межами свого контролю. Blockchain-аналітика, перевірка гаманців і моніторинг транзакцій, специфічних для стейблкоїнів, на думку ICBA, належать емітенту.

На слайді це виглядає акуратно. У продакшні — ні. Емітент стейблкоїнів зазвичай має прямий огляд подій мінтингу та бернінгу. Все між ними відбувається у публічних блокчейнах, через біржі, кастодіанів та гаманець-додатки, з якими емітент не має жодних договірних відносин. ICBA все одно хоче, щоб емітенти ідентифікували, блокували, заморожували або відхиляли заборонену діяльність, і враховували міксери, обфускацію гаманців, стрибки між мережами, підсанкційні юрисдикції та перекази між on-chain і off-chain системами. Як зазначено в листі, лише періодична перевірка санкційних списків недостатня.

International Bancshares Corp. додала ширшу стурбованість. Сильні стандарти AML і санкцій необхідні, але пропозиція торкається лише одного компонента ризику стейблкоїнів. Шахрайство, шкода споживачам, ухилення від санкцій, витіснення депозитів і ширша нестабільність не вирішуються накладанням існуючих правил відповідності на новий продукт.

Коментатори також вказали, що дублюючий нагляд FDIC, FinCEN і OFAC може сповільнити прийняття рішень, навіть коли базові рейки переміщують цінність через кордони за секунди. За виробничими інцидентами, які я бачив у фінтех-компаніях з мультирегуляторним впливом, саме в цьому часовому розриві фактично накопичуються збитки від шахрайства. Регуляторна книга передбачає час перегляду людиною, якого розрахункова система не надає.

Варіанти на розгляді

З коментарних листів випливають три різні архітектури відповідності, і вони ведуть до дуже різних інженерних дорожніх карт.

Варіант перший: емітент як повностековий спостерігач. Це позиція ICBA. Емітент відповідає за blockchain-аналітику, перевірку гаманців, моніторинг транзакцій, процедури на випадок надзвичайних ситуацій для погашення, документацію порогів сповіщень, оцінку хибнопозитивних і хибнонегативних результатів та зберігання записів розслідувань. Резервні банки обмежуються моніторингом своїх прямих клієнтів, тобто самих емітентів. Чіткі межі, але це ставить кожного емітента в позицію побудови або придбання стеку chain-аналітики, що конкурує з тим, що Chainalysis і TRM продають правоохоронним органам. Дрібні емітенти не можуть нести такі накладні витрати. Це двоє інженерів у штаті ще до написання жодного правила.

Варіант другий: спільні зобов'язання на вторинному ринку. Це позиція Bank Policy Institute і The Clearing House у їхньому спільному листі. Запропонована база, на їхню думку, залишає прогалину, коли платіжні стейблкоїни переходять від емітента на вторинний ринок. Біржі, кастодіани, постачальники послуг цифрових активів та інші посередники, що сприяють вторинно-ринковим транзакціям, також повинні мати чіткіші зобов'язання щодо AML і санкцій. Інакше банки залишаються відповідальними за ризики, створені діяльністю, яку вони не можуть бачити.

Цей варіант чесний з інженерної точки зору. Хто має клієнтські відносини — той і проводить перевірку. Це також вимагає від FDIC координації з майданчиками, які він безпосередньо не наглядає, що політично складніше, ніж писати правила для власних банків. Триваюче перетинання повноважень SEC з крипто-посередниками показує, як швидко ця координація зупиняється.

Варіант третій: відповідальність на етапі проектування. У листі ICBA прихована найгостріша фраза всього коментарного запису: якщо дозволений емітент платіжних стейблкоїнів проектує продукт, що може переміщувати цінність між гаманцями, платформами або юрисдикціями швидше, ніж можуть діяти його санкційні контролі, цей проектний вибір не повинен ставати підставою для зниження відповідальності. У перекладі на інженерну мову: ви не маєте права випускати ERC-20, що стрибає між L2 менш ніж за секунду, а потім стверджувати, що перевірка OFAC працює в нічному пакетному режимі.

Моя думка: варіант третій — єдиний, що витримує контакт з реальною затримкою розрахунків. Варіанти один і два сперечаються про те, хто прибирає. Варіант третій змушує дизайн продукту відповідати швидкості контролю, що і є фактичним інженерним обмеженням.

Що реально варто зробити крипто та DeFi

Інженерні команди емітентів, що вивчають коментарний запис, повинні припинити розглядати відповідність як завдання для наступного етапу і включити її в дизайн протоколу. Лист ICBA фактично вимагає примусового виконання санкцій у реальному часі, а не періодичного оновлення списків. Це означає, що функція заморожування, оракул списку блокувань, повноваження на мінтинг/бернінг і робочий процес ідентифікації погашення повинні бути першокласними компонентами, а не запізнілими думками.

Конкретно, варто зробити три кроки прямо зараз. По-перше, підключіть мінтинг і бернінг до живого санкційного фіду, а не до нічного завдання, і журналюйте кожне рішення з порогом сповіщення, що його спрацював. ICBA спеціально вимагала задокументованих порогів, оцінки хибнопозитивних і хибнонегативних результатів та збережених записів розслідувань. Це вимога до аудиторського сліду, а не побажання.

По-друге, побудуйте шлях ідентифікації погашення до того, як він вам знадобиться. У листі BPI і Clearing House підкреслено сценарій, коли власник отримує стейблкоїни через біржу без жодних прямих відносин з емітентом, а потім приходить за готівкою, коли та біржа зазнає збою або призупиняє виведення коштів. Емітент повинен ідентифікувати та перевірити когось, кому він ніколи не надавав послуг, і потенційно у великих обсягах. Якщо ваше KYC-онбординг передбачає щасливий шлях створення облікового запису, воно впаде під час масового погашення.

По-третє, ставтеся до сторонніх постачальників як до розширення вашого периметра відповідності. ICBA була чіткою: аутсорсинг перевірок ідентичності, скринінгу або моніторингу не звільняє емітента від відповідальності. Який би аналітичний провайдер або KYC-вендор не був у вашому стеку, їхні SLA, списки покриття та процедури ескалації тепер пов'язані з вашими відносинами з регулятором.

Неприємний висновок: більшість емітентів стейблкоїнів, за якими я спостерігав, ставляться до управління списком блокувань як до задачі в системі управління, а не до критично важливого за затримкою сервісу. Цей підхід не виживе в рамках, до яких рухається FDIC.

Підводні камені та граничні випадки

Сценарій масового погашення заслуговує на повний аналіз режимів збоїв. Коли біржа заморожує виведення коштів, запити на погашення надходять до емітента піковим навантаженням від гаманців без жодних попередніх відносин. Ваш вендор верифікації ідентичності обмежує запити. Ваш API перевірки санкцій обмежує запити. Ваша черга підтримки клієнтів вибухає. ICBA закликала FDIC вимагати надзвичайних процедур, що охоплюють ідентифікацію, перевірку санкцій, ескалацію підозрілої діяльності, кадрове забезпечення, ліквідність і комунікації. Сприймайте цей список як посібник, який варто складати вже сьогодні.

Стрибки між мережами — це друга міна. ICBA прямо назвала міксери, обфускацію гаманців, стрибки між мережами та перекази між on-chain і off-chain системами як те, що емітенти повинні враховувати. Якщо ваш токен розгорнуто в кількох L2 і мостах, ваш моніторинг повинен зіставляти адреси в цих середовищах майже в реальному часі. Аналітичні вендори суттєво відрізняються за покриттям. Тестуйте перед підписанням.

Третій підводний камінь: FDIC повинен повідомляти FinCEN щонайменше за 30 днів до певних наглядових або примусових дій. Це вікно координації звучить процедурно, але означає, що ефективний регулятор щодо конкретного інциденту може бути нез'ясованим до того, як ваша юридична команда вже відповіла. Будуйте плани реагування на інциденти, що передбачають участь кількох агентств.

Нарешті, ICBA виступала проти винятків, якщо вони не забезпечують еквівалентної прозорості, прослідковуваності та цінності для правозастосування. Будь-яку пропозицію від вендора, що обіцяє легке виключення з відповідності для вашого продукту, слід розглядати як правовий ризик, а не як скорочення шляху.

Ключові висновки

• Банки чітко повідомили FDIC: провайдери резервних рахунків спостерігають за емітентом, емітент спостерігає за гаманцями. Будуйте свій стек навколо цього розподілу.
• Санкційні контролі повинні працювати зі швидкістю розрахунків. Періодична перевірка списків не відповідатиме стандарту, якого домагається ICBA.
• Погашення — це стрес-тест. Якщо власник, якому ви ніколи не надавали послуг, може прийти за готівкою під час збою біржі, вам потрібен робочий процес ідентифікації та перевірки, що масштабується під піковим навантаженням.
• Аутсорсинг третім сторонам не передає відповідальність. Перевірка вендорів, документація порогів сповіщень і зберігання записів розслідувань тепер є артефактами, що належать емітенту.
• Проектні рішення продукту, що випереджають ваші засоби контролю відповідності, відповідно до ICBA, не є захистом. Узгоджуйте можливості протоколу зі затримкою контролю або скорочуйте можливості.