Подразделение по участникам рынка Комиссии по торговле товарными фьючерсами США (CFTC) объявило о позиции no-action для поставщиков пассивного программного обеспечения. При соблюдении условий сотрудники подразделения не будут рекомендовать Комиссии принудительные меры против таких поставщиков за отсутствие регистрации в качестве introducing broker или связанного с ним лица – но только в отношении предоставления и продвижения ПО, которое помогает пользователям торговать через зарегистрированных посредников и площадки.
Что именно решила CFTC
Позиция опубликована 17 сентября 2026 года и основана на разъяснительном письме ведомства. CFTC сообщает, что мера распространяется на поставщиков пассивного ПО и их соответствующий персонал, если они отвечают заданным критериям. В описании названы пользователи, которые через это программное обеспечение взаимодействуют с зарегистрированными futures commission merchants (FCM), introducing brokers (IB) и designated contract markets (DCM).
Смысл здесь не в освобождении криптовалютных сервисов от регулирования вообще. Ведомство говорит об ограниченной позиции сотрудников по конкретному вопросу регистрации introducing broker. Она относится к определённой деятельности и не отменяет остальные применимые требования. Ключевое слово – passive: программное обеспечение предоставляет техническую возможность, но правовая оценка зависит от фактической роли поставщика, его маркетинга и соблюдения всех условий письма.
Что понимается под пассивным ПО
В широком смысле пассивным можно назвать инструмент, который пользователь запускает для взаимодействия с торговой инфраструктурой, но который сам не превращается в посредника, принимающего решения за клиента. Однако одно только название продукта не решает, к какой категории он относится. Если сервис начинает направлять пользователя, подбирать ему контрагентов, влиять на исполнение заявки или заниматься иной деятельностью, юридическая картина может отличаться.
Поэтому разработчики не должны воспринимать релиз CFTC как простую отметку «приложение не регулируется». Значение имеют конкретные функции, рекламные заявления, договоры и то, кто контролирует транзакцию. CFTC указывает, что льгота действует при выполнении определённых условий; для практического вывода необходимо читать само письмо и анализировать реальную модель работы. Пресс-релиз не перечисляет все операционные детали.
Что такое no-action позиция
No-action – это позиция сотрудников ведомства о том, что они не станут рекомендовать Комиссии принудительные меры при соблюдении описанных условий. Это не тождественно правилу, принятому Комиссией после полноценного нормотворческого процесса, и не означает судебного иммунитета. Она также не обязывает всех регуляторов или суды одинаково оценивать аналогичный продукт.
Для бизнеса разница существенна: письмо может дать предсказуемость внутри указанной области, но не должно расширяться на другие услуги по аналогии без проверки. Если поставщик совмещает пассивное программное обеспечение с хранением средств, посредническими услугами или самостоятельным управлением сделками, оценка должна учитывать весь набор функций. Пользователь также должен понимать, с какой зарегистрированной организацией он фактически взаимодействует.
Как новость связана с криптоприложениями
Многие криптопродукты соединяют пользовательский интерфейс, кошелёк, маршрутизацию и доступ к торговой площадке. Эта архитектура может выглядеть как единый сервис, хотя роли распределены между разработчиком интерфейса, оператором приложения, биржей и посредником. Позиция CFTC поднимает вопрос, где заканчивается инструмент и начинается регулируемая посредническая деятельность. Ответ зависит от конкретных фактов, а не от маркетингового обозначения «некастодиальный» или «автоматический».
Пользователю полезно проверять, кому он передаёт поручение и кто отвечает за его исполнение. При использовании смарт-контракта отдельно нужно понимать, кто может обновлять код, менять параметры или останавливать работу. Наши материалы объясняют, как устроены прокси и обновляемые контракты и как проверить владельцев мультиподписи. Техническая автономность не является автоматическим подтверждением регуляторного статуса сервиса.
Что стоит проверить разработчикам и клиентам
Разработчикам следует сверить продукт с точным текстом позиции, зафиксировать роли каждого участника, проверить процесс маркетинга и определить, где клиент заключает отношения с зарегистрированным FCM, IB или DCM. Важны договоры и операционные потоки, а не только описание интерфейса. Если продукт изменится, старый вывод о соответствии позиции может больше не применяться.
Клиентам не следует делать вывод, что приложение прошло проверку CFTC, только потому что отрасль получила такую позицию. Письмо обращено к поставщикам и ограничено регистрационным вопросом. Перед торговлей нужно отдельно проверить площадку, риск самого актива, условия хранения и защиту от потери ключей. Общие шаги по оценке контрагентов изложены в руководстве о том, как проверять эмитента цифрового актива.
Практический вывод
Объявление CFTC может снизить неопределённость для части разработчиков торгового ПО, но только в пределах описанной деятельности и условий. Оно не является общим разрешением на криптовалютные сервисы и не заменяет регистрацию, если она требуется по другим основаниям. Для пользователя главное – видеть, кто именно предоставляет услугу, кто исполняет сделку и какие права остаются у клиента при сбое.
Почему границы инструмента важны
Одинаковый экран может скрывать разные юридические роли. Один сервис только отображает информацию, другой передаёт поручение, а третий может подбирать условия или управлять маршрутом исполнения. Для определения статуса важен весь путь сделки: кто ведёт клиента, кто получает вознаграждение, кто соединяет его с зарегистрированной организацией и где находится контроль над процессом. Письмо CFTC помогает очертить узкую область для пассивных поставщиков, но не заменяет этот анализ и не гарантирует одинаковый вывод для всех приложений.
В частности, использование открытого кода или смарт-контракта само по себе не отвечает на вопрос, является ли деятельность пассивной. Нужно оценивать фактические функции и отношения с пользователем, а также условия, перечисленные в разъяснении. Именно поэтому поставщику полезно документировать устройство продукта и повторно проверять позицию после каждого существенного изменения сервиса.
