Обменник криптовалют на базе облачного депозитария: сложности, объём работы и архитектура

Закон затрагивает всех, кто работает с криптовалютой: обменники, биржи, брокеров, депозитариев. Работать без лицензии с июля 2027 года будет нельзя. Эта статья — для банков, которые хотят предложить своим клиентам покупку и продажу криптовалюты, и для действующих обменников, которые рады появлению правовой рамки и хотят работать в легальном поле.

В предыдущей статье мы подробно разобрали первый и самый инфраструктурно тяжёлый компонент — цифровой депозитарий: что это за сущность, из каких модулей состоит и почему его разработка занимает больше года. Эта статья — про организацию, осуществляющую обмен цифровой валюты (далее — обменник). Именно с обменника большинство банков и финтех-компаний начнут свой путь на легальный крипторынок, потому что это самый быстрый способ монетизировать новую лицензию и самый понятный продукт для клиентской базы. Мы разберём, из чего он состоит, насколько сложно его разработать и почему даже при использовании стороннего депозитария объём работы остаётся впечатляющим.

Определение

Закон вводит специальный термин — «организация, осуществляющая обмен цифровой валюты» (ст. 18). Это юридическое лицо, которое систематически совершает сделки купли-продажи и мены цифровых валют от своего имени и за свой счёт. Принципиальное слово здесь — «от своего имени». Обменник не сводит покупателя с продавцом (это делает биржа). Обменник сам выступает контрагентом: он продаёт клиенту криптовалюту со своего казначейского счёта или покупает её у клиента за рубли. Зарабатывает обменник на спреде (разнице между ценой покупки и продажи) и комиссии за операцию.

Порог систематичности установлен прямо в законе: две или более сделки в течение месяца на совокупную сумму свыше 3,5 миллиона рублей. Ниже этого порога — формально не обменник. Выше — нужна лицензия.

Чем обменник отличается от биржи и депозитария

Три участника рынка делают принципиально разные вещи:

• Биржа (организатор торгов) сводит покупателей и продавцов. Она не владеет активами, которыми торгуют на её площадке, — она предоставляет инфраструктуру для организованных торгов.
• Депозитарий хранит активы и ведёт учёт. Он не торгует и не обменивает — он фиксирует, кому что принадлежит, контролирует каждую транзакцию и обеспечивает безопасность ключей.
• Обменник торгует. Он покупает и продаёт криптовалюту за свой счёт, берёт на себя рыночный риск, устанавливает котировки и зарабатывает на спреде и комиссиях.

Лицензирование

Для работы обменник должен быть включён в реестр Банка России и в течение 90 дней вступить в саморегулируемую организацию (СРО). Обменник обязан иметь номинальный счёт в кредитной организации с рейтингом не ниже уровня, установленного Советом директоров ЦБ. Кроме того, обменник — полноценный субъект 115-ФЗ, со всеми обязанностями по идентификации клиентов, мониторингу операций и отчётности перед Росфинмониторингом.

Легальная работа с криптовалютой невозможна без депозитария — именно он хранит ключи, ведёт счета и подписывает каждую транзакцию. Но обязательно ли строить собственный депозитарий, чтобы запустить обменник? Нет. Закон разделяет лицензию депозитария (ст. 26) и лицензию обменника (ст. 32) — это два разных вида деятельности, два отдельных включения в реестр Банка России. Обменник может использовать чужой депозитарий как инфраструктуру — так же, как брокер использует НРД для учёта ценных бумаг, не строя собственный депозитарий.

Депозитарий в собственном контуре (on-premise) — история для крупных банков, у которых есть ресурсы на содержание HSM модуля, команды эксплуатации и безопасников. Даже если не строить депозитарий с нуля, а развернуть готовое решение у себя, стоимость эксплуатации остаётся очень высокой. Для средних и небольших банков, а тем более для обменников и финтех-компаний, это экономически нецелесообразно. Для них есть альтернатива: использовать сторонний депозитарий по API, а самим сосредоточиться на торговле, клиентском интерфейсе, compliance и расчётах.

Схематично это выглядит так: клиент взаимодействует с приложением обменника, обменник через API передаёт распоряжения депозитарию, тот исполняет операции на блокчейне. Фиатная часть (рубли) проходит через банковский контур оператора.

Что закрывает облачный депозитарий

Модель привлекательна тем, что снимает с оператора самые тяжёлые инфраструктурные задачи — управление ключами, блокчейн-коннекторы, on-chain сверку, HSM. Но она не превращает обменник в «лёгкий MVP на три месяца». За фасадом простой кнопки «Купить BTC» скрывается полноценная финтех-платформа с собственными рисками, лицензионными обязательствами и десятком модулей, которые нужно спроектировать, построить и эксплуатировать.

Если оператор обменника использует внешний депозитарий, ему не нужно строить самостоятельно:

Систему цифровых счетов. Все 11+ типов счетов — от счёта обладателя до казначейского — ведёт депозитарий. Обменник вызывает API: «открой счёт», «зачисли 0.5 BTC», «покажи баланс». Архитектура счетов, расширяемость при появлении новых типов, аудит-трейл депозитарного уровня — всё на стороне провайдера.

Управление ключами и HSM. Генерация приватных ключей, хранение в аппаратных модулях безопасности, подписание on-chain транзакций — самый чувствительный и дорогой компонент депозитария. Сюда же входит механизм ротации ключей и смены кошельков — например, если эмитент стейблкоина решит заблокировать адрес, активы нужно оперативно перевести на новый. При облачной модели обменнику не нужен собственный HSM, не нужна команда криптографов, не нужна церемония ключей. Каждая исходящая транзакция подписывается внутри депозитария после прохождения approval workflow.

Блокчейн-коннекторы. Подключение к нодам Bitcoin, Ethereum, Tron и других сетей, мониторинг входящих транзакций, отслеживание подтверждений, обработка реорганизаций цепочки — всё это делает депозитарий. Обменнику не нужно поднимать собственные ноды и содержать команду блокчейн-инженеров.

On-chain сверку. Ежедневная сверка внутренних балансов с фактическими данными в блокчейне — обязательное требование закона. Депозитарий выполняет её самостоятельно и предоставляет обменнику отчёт.

Цифровой анализ входящих транзакций. Проверка происхождения средств через blockchain analytics — скоринг адресов, выявление связей с незаконной деятельностью — обязанность депозитария.

Что остаётся на стороне оператора обменника

Облачный депозитарий снимает инфраструктурный слой — но бизнес-логика обменника, его регуляторные обязанности и рыночные риски остаются полностью на операторе.

Котировки, спред и казначейство. Обменник торгует за свой счёт, а это значит, что ему нужен собственный treasury, отвечающий за управление запасами криптовалюты и рублёвой ликвидностью. Т.е. нужно продумать откуда брать криптовалюту для продажи клиентам (закупать на внешних биржах? у маркет-мейкера? у провайдера ликвидности?), по какой цене продавать, как хеджировать рыночный риск, если курс резко двинулся, пока обменник держит открытую позицию. Нужны источники котировок в реальном времени — агрегация цен с нескольких бирж, расчёт справедливого mid-price, определение спреда. Нужна система управления собственной позицией: лимиты на объём крипты, которую обменник держит на балансе, правила автоматической ребалансировки (если продали слишком много — докупить, если накопилось слишком много — продать), алерты при резких движениях рынка, когда спред может стать убыточным. Депозитарий не лезет в ваш бизнес.

Клиентский интерфейс и оркестрация сделки. Весь UX — от экрана покупки до истории операций — строит обменник. Для клиента всё выглядит просто: нажал «Купить», увидел результат. Но за этим стоит многошаговый процесс, в котором участвуют несколько систем одновременно. Сначала нужно показать актуальную котировку и зафиксировать цену на короткий интервал (обычно 10–30 секунд), пока клиент подтверждает сделку. Затем — списать рубли с банковского счёта. Затем — вызвать API депозитария для зачисления криптовалюты на цифровой счёт клиента. Если на любом из этих шагов произошёл сбой — таймаут, отказ банка, ошибка на стороне депозитария — нужно корректно откатить операцию: вернуть рубли, не зачислить крипту, уведомить клиента. Этот процесс называется DVP (delivery vs payment) — одновременная доставка актива и списание оплаты. Его оркестрация целиком на стороне обменника, и от её качества зависит, будут ли клиенты видеть «зависшие» операции и писать в поддержку.

Compliance на уровне продукта. Депозитарий проводит KYC при открытии счёта и проверяет входящие транзакции. Но обменник обязан самостоятельно контролировать лимиты покупки для неквалифицированных инвесторов — а значит, для каждого клиента нужно в реальном времени отслеживать, сколько он уже купил за текущий год, и блокировать сделку при исчерпании лимита. Причём блокировка — это не просто отказ: нужно корректно уведомить клиента, объяснить причину, предложить пройти тестирование на квалифицированного инвестора, если это возможно. Помимо лимитов — обязательное тестирование клиентов перед первой покупкой, показ уведомлений о рисках перед каждой сделкой, собственный мониторинг подозрительных операций. У обменника — своя лицензия, своя ответственность перед регулятором.

Регуляторная отчётность обменника. Обменник обязан вести собственные реестры сделок (ст. 38), формировать отчётность для Банка России (ст. 43, 48), раскрывать информацию, отвечать на запросы госорганов. Часть исходных данных приходит из депозитария, но агрегация, форматирование и отправка — на операторе. Соответственно, нужно корректно собирать данные из нескольких источников (собственный учёт, API депозитария, банковский контур), приводить их к форматам регулятора и отправлять в установленные сроки. Это отдельный софт и отдельная команда — люди, которые понимают требования ЦБ и Росфинмониторинга и умеют работать с отчётными формами.

Внутренний контроль и управление рисками. По ст. 45–46 обменник обязан иметь систему внутреннего контроля и систему управления рисками. Для обменника ключевые риски — рыночный (волатильность крипты), ликвидности (нехватка актива для продажи), контрагентский (если используется внешний LP), операционный (сбои в интеграции с депозитарием).

Риски облачной модели

Модель «чужой депозитарий по API» привлекательна по скорости запуска, но несёт собственные риски, которые нужно оценивать заранее.

Зависимость от SLA провайдера. Если API депозитария «лежит» — обменник не может исполнять сделки. У оператора нет контроля над доступностью чужой инфраструктуры. Нужно договорное SLA с финансовой ответственностью — и архитектура, способная корректно обрабатывать недоступность депозитария.

Размытая ответственность при инцидентах. Если клиент потерял активы из-за ошибки на стороне депозитария — перед клиентом отвечает оператор обменника. Юридическая модель разграничения ответственности между обменником и облачным депозитарием должна быть проработана до запуска.

Ограничения API. Облачный депозитарий предоставляет стандартизированный набор операций. Если обменнику нужен нестандартный сценарий — например, условное исполнение, специфический тип блокировки, нетиповой формат отчёта — он зависит от roadmap провайдера. Кастомизация в облачной модели всегда дороже и медленнее, чем при собственном решении.

Регуляторная неопределённость. Допустимость облачной модели для конкретного типа оператора (особенно для банков) пока не регламентирована прямо. Требования ЦБ к защите данных, к локализации инфраструктуры, к контролю оператора над ключами — всё это может измениться подзаконными актами. Юридическая проработка необходима до принятия архитектурного решения.

Обменник может строить банк — встраивая его в своё мобильное приложение. А может — финтех-компания, получившая лицензию обменника и работающая самостоятельно. Сложности и объём работы для этих двух сценариев существенно различаются.

Банк

Преимущества. У банка уже есть верифицированная клиентская база — миллионы пользователей с пройденным KYC. Не нужно заставлять клиента загружать паспорт заново: достаточно синхронизировать данные с облачным депозитарием. Фиатные расчёты идут через собственную инфраструктуру — номинальный счёт, процессинг платежей. Антифрод и комплаенс-процессы уже выстроены для банковских операций — их нужно расширить, но не строить с нуля. Служба поддержки уже умеет работать с блокировками по 115-ФЗ и запросами госорганов.

Сложности. Встраивание крипто-обменника в банковское приложение — это проект на стыке двух миров с разной скоростью. Банковский IT-ландшафт — это legacy-системы, длинные циклы согласования с информационной безопасностью, жёсткие процедуры change management. Крипторынок работает 24/7, цены меняются каждую секунду, а клиенты ожидают мгновенного исполнения. Согласование API-интеграции с внешним депозитарием через банковский ИБ-комитет может занять месяцы. Добавьте сюда конфликт приоритетов: команда мобильного приложения загружена бэклогом из сотен задач, и встраивание нового раздела «Крипто» конкурирует с кредитными продуктами и платежами за внимание разработчиков.

Финтех

Преимущества. Нет бюрократии банковского IT-ландшафта. Можно строить архитектуру с чистого листа, выбирать стек без ограничений legacy-систем, двигаться быстрее. Команда полностью сфокусирована на одном продукте.

Сложности. Всё, что банку достаётся «бесплатно», финтеху нужно строить или покупать. KYC и AML — интеграция со сторонними провайдерами (SumSub, IDX, верификация через Госуслуги) или собственная система. Номинальный счёт — договор с банком, рейтинг которого соответствует требованиям ЦБ. Антифрод — новая интеграция, а не расширение существующей. Служба поддержки — с нуля, включая найм людей, которые понимают и криптовалюты, и 115-ФЗ. И главное — нет клиентской базы. Нужен полноценный маркетинг, привлечение, удержание. Для финтеха обменник — это не дополнительный раздел в приложении с миллионами пользователей, а самостоятельный продукт, который должен набрать аудиторию в конкуренции с банками.

Верхнеуровнево продукт обменника состоит из семи модулей. Для каждого из них разберём: что именно он делает, что закрывает облачный депозитарий, что строит оператор самостоятельно, в чём ключевые сложности и каков качественный объём работы.

Клиентский фронт

Что включает: личный кабинет, экраны сделок и заявок, тестирование инвесторов, уведомления о рисках, обращения в поддержку, документы (выписки, справки).

Что даёт депозитарий: ничего. Клиентский интерфейс — целиком зона ответственности обменника. Депозитарий предоставляет API для получения данных (баланс счёта, история операций), но весь UX — на операторе.

Что строим сами: полный клиентский путь от регистрации до совершения сделки. Для банка — встраивание в существующее мобильное приложение (iOS, Android, веб). Для финтеха — создание приложения с нуля.

Ключевые сложности. Обязательное тестирование физических лиц перед покупкой криптовалюты (ст. 32) — нужен интерактивный тест с фиксацией результата. Обязательное уведомление о рисках перед каждой сделкой (ст. 31) — не просто «галочка», а юридически значимый документ, содержание которого определит ЦБ. Отображение статусов при многошаговом DVP: клиент нажал «Купить», рубли списались, но крипта ещё не зачислена — нужно показать промежуточное состояние, а не пустой экран. Самостоятельная загрузка документов: физлицам — выписки для налоговой, юрлицам — отчёты для бухгалтерии в определённом формате.

Модуль обмена

Что включает: котировки, купля-продажа, мена цифровых валют, DVP (delivery vs payment), лимиты, управление собственным портфелем и ликвидностью.

Что даёт депозитарий: только API для исполнения крипто-стороны сделки — зачисление, списание, перевод между счетами. Всю торговую логику обменник строит сам.

Что строим сами: полный торговый движок.

Ключевые сложности. Это самый сложный и уникальный модуль обменника — именно он отличает обменник от всех остальных участников рынка.

Комплаенс-модуль

Что включает: KYC — идентификация клиента (паспорт, СНИЛС, проверка через Госуслуги или вручную). AML/CFT — мониторинг операций на предмет отмывания денег и финансирования терроризма, формирование отчётов для Росфинмониторинга. Проверка по санкционным спискам — сверка каждого клиента с перечнями экстремистов, террористов, санкционных лиц при каждой операции. Признание квалифицированных инвесторов — процедура присвоения статуса, от которого зависят лимиты и доступные активы. Тестирование физических лиц — обязательный тест перед первой покупкой, фиксация результата. Антифрод — выявление мошеннических операций, совершаемых без ведома клиента или с использованием чужих данных.

Что даёт депозитарий: KYC на уровне цифрового счёта (идентификация при открытии), AML-проверку входящих on-chain транзакций, blockchain analytics. Но это compliance депозитарного уровня — он не покрывает обязательства обменника.

Что строим сами: compliance на уровне сделки. Обменник — самостоятельный субъект 115-ФЗ с собственными обязанностями.

Ключевые сложности. На стыке обменника и депозитария возникает зона дублирования: оба обязаны идентифицировать клиента, оба обязаны мониторить операции. Чтобы клиент не проходил KYC дважды, нужна оркестрация — единый customer profile, синхронизация статусов между двумя системами. При этом ответственность не делегируется: если обменник пропустил подозрительную операцию — наказывают обменник, даже если депозитарий её тоже не поймал.

Тестирование инвесторов — отдельный процесс, который обменник обязан проводить самостоятельно. Формат и содержание теста определит Банк России, но инфраструктуру для его проведения (интерфейс, фиксация результатов, хранение) строит оператор.

Антифрод для обменника имеет свою специфику по сравнению с банковским: нетипичные паттерны покупок крипты, попытки обойти лимиты через дробление сделок, использование чужих аккаунтов для покупки.

Модуль расчётов

Что включает: банковские платежи, цифровые счета, адреса-идентификаторы, интеграция с депозитарием, сверка.

Что даёт депозитарий: цифровые счета, адреса-идентификаторы, on-chain операции, on-chain сверку. Это основная зона, где облачная модель экономит больше всего — обменнику не нужно строить ядро учётной системы.

Что строим сами: фиатную часть расчётов и операционную сверку.

Ключевые сложности. Банковские платежи — это не просто «списать рубли». Нужно обеспечить интеграцию с платёжной системой банка (для банка-оператора) или настроить расчёты через номинальный счёт (для финтеха). Нужен процессинг возвратов, обработка отклонённых платежей, контроль остатков на номинальном счёте.

Отдельная задача — операционная сверка. Депозитарий сверяет on-chain балансы с данными своей учётной системы. Но обменнику нужна ещё одна сверка: рубли ↔ крипта ↔ сделки. Клиент купил BTC за 100 000 рублей — действительно ли рубли зачислены, крипта отправлена, комиссия корректна? Эта трёхсторонняя сверка (фиатный баланс, крипто-баланс в депозитарии, реестр сделок обменника) — задача оператора.

Регуляторный модуль

Что включает: отчётность Банку России, отчётность в Росфинмониторинг, обработка запросов органов, реестры операций, раскрытие информации, исполнение предписаний.

Что даёт депозитарий: депозитарий ведёт свою отчётность, но она не заменяет отчётность обменника. Часть исходных данных (балансы, операции по цифровым счетам) обменник получает через API депозитария.

Что строим сами: весь регуляторный модуль обменника.

Ключевые сложности. Обменник обязан вести собственные реестры сделок (ст. 38) и формировать отчётность в форматах, которые установит ЦБ (ст. 43, 48). Сейчас эти форматы не определены — а значит, архитектура модуля должна быть достаточно гибкой, чтобы адаптироваться к ещё не существующим требованиям.

Workflow на запросы госорганов — ФСБ, ФНС, суды, Росфинмониторинг — обменник обязан обрабатывать самостоятельно, даже если активы клиента учитываются в чужом депозитарии. Пришёл запрос суда на блокировку — обменник приостанавливает торговлю и передаёт распоряжение депозитарию. Пришёл запрос ФНС — обменник предоставляет данные из своих реестров. Это не перекладывается на провайдера.

Модуль управления рисками и контроля

Что включает: управление рисками — методология оценки и контроля рыночных, операционных и кредитных рисков обменника. Внутренний контроль — проверка того, что сотрудники и системы действуют в рамках установленных правил и лимитов. Инциденты — регистрация, расследование и устранение сбоев, утечек, нарушений. Аудит — регулярная независимая проверка всех процессов и их соответствия требованиям регулятора.

Что даёт депозитарий: ничего. Это полностью зона ответственности обменника как отдельного лицензированного участника.

Что строим сами: систему управления рисками и систему внутреннего контроля (ст. 45–46).

Ключевые сложности. Риски обменника принципиально отличаются от рисков депозитария. Депозитарий в первую очередь управляет операционным риском и риском безопасности (взлом, потеря ключей). Обменник добавляет к этому рыночный риск (колебания курса криптовалют при наличии открытой позиции), риск ликвидности (нехватка актива для исполнения сделки), контрагентский риск (если обменник получает ликвидность от внешнего провайдера — что будет, если тот обанкротится?), операционный риск (сбои в интеграции с депозитарием или банком).

Для банка этот модуль — расширение существующей системы управления рисками: добавление новых классов рисков к уже работающей методологии. Для финтеха — построение с нуля, включая найм риск-офицеров и комплаенс-менеджеров. Причём дело не только в софте — нужна организационная зрелость: политики, процедуры, комитеты, отчётные линии.

Сервисный модуль

Что включает: RBAC (ролевой доступ), электронная подпись, журнал аудита, документооборот, уведомления, резервное копирование.

Что даёт депозитарий: собственный аудит-трейл on-chain операций, но он не заменяет аудит обменника.

Что строим сами: инфраструктурный слой приложения.

Ключевые сложности. RBAC для обменника — это десятки ролей: оператор, комплаенс-офицер, риск-менеджер, администратор, оператор поддержки. Каждая роль видит разный набор данных и имеет разные полномочия. Журнал аудита обменника должен фиксировать каждое действие каждого пользователя — и храниться не менее 5 лет.

Электронная подпись по ГОСТ — обязательна для юридически значимых документов: договоров с клиентами, регуляторной отчётности, уведомлений о блокировках. 

Отдельный пласт работы - защита персональных данных и платёжной информации. Обменник хранит паспортные данные клиентов, результаты KYC-проверок, платёжные реквизиты, историю операций — всё это подпадает под 152-ФЗ «О персональных данных». Нужна классификация информационной системы персональных данных, уведомление Роскомнадзора, политика обработки, сбор согласий. Режим конфиденциальности клиентских данных по новому закону аналогичен банковской тайне (ст. 37) — раскрытие допускается только по решению суда или запросу уполномоченных органов. Данные должны шифроваться и в хранении, и при передаче, причём для российского контура — сертифицированными средствами криптографической защиты. Если обменник принимает оплату банковскими картами — добавляется соответствие стандарту PCI DSS. Всё это требует аудита информационной безопасности, регулярного тестирования на проникновение и подготовки документации для регулятора. Для банка часть этой инфраструктуры уже существует, для финтеха — строится с нуля и может стать одной из самых дорогих статей расходов.

Срок до запуска. При условии, что API стороннего депозитария уже готов к интеграции, реалистичный срок разработки обменника — от девяти-двенадцати месяцев для банка и от двенадцати-восемнадцати для финтеха. Это при параллельной работе над несколькими модулями и при условии, что команда уже сформирована.

Команда. Обменник на стороннем депозитарии требует от 20–25 человек. Почему так много, если депозитарий чужой? Потому что модулей восемь, и каждому нужны свои люди:

• Backend-разработчики (торговый движок, казначейство, оркестрация DVP, интеграция с депозитарием и банком) — от 4 человек
• Фронтенд/мобильная разработка (iOS, Android, веб-ЛК) — от 3 человек
• UX/UI-дизайнер — от 1 человека
• QA и автоматизация тестирования — от 2 человек
• DevOps / инфраструктура — от 2 человек
• Системные и бизнес-аналитики — от 2 человек
• Комплаенс-офицеры (KYC/AML, работа с Росфинмониторингом, запросы органов) — от 2 человек
• Риск-менеджеры (рыночный риск, лимиты позиции, внутренний контроль) — от 1 человека
• Служба поддержки (блокировки, спорные операции, консультации клиентов) — от 3 человек
• Продуктовый менеджер, проектный менеджер — 2 человека

Часть экспертизы по блокчейну всё равно нужна — хотя бы один-два специалиста, понимающих, как работает API депозитария, что означают статусы on-chain транзакций и как обрабатывать edge-cases (реорганизации, задержки подтверждений).

Затраты. Капитальные расходы на HSM и ноды отсутствуют — их заменяет подписка на сервис депозитария. Но сэкономленные на инфраструктуре деньги уходят на интеграцию, оплату сервиса провайдера и на построение того, что депозитарий не закрывает: казначейство, compliance, регуляторная отчётность, клиентский продукт.

Всё, что описано выше, — это обменник для физических лиц. Если в продукт добавляется обслуживание юрлиц, картина меняется существенно. Это не просто «ещё один тип клиента» — это другие процессы, другие документы, другие сценарии и дополнительная команда.

KYC юрлиц — принципиально другой процесс. Идентификация физлица — это паспорт и проверка по спискам. Идентификация юрлица — это пакет документов: устав, выписка из ЕГРЮЛ, решение о назначении руководителя, цепочка бенефициарных владельцев (UBO) с проверкой каждого из них до конечного физлица. Если юрлицо иностранное — перевод документов, апостиль, проверка по зарубежным реестрам. Это отдельный workflow в системе, отдельные экраны в интерфейсе и отдельная экспертиза у комплаенс-офицеров.

ВЭД-расчёты — основной сценарий для юрлиц. Закон разрешает использование криптовалюты для расчётов по внешнеторговым контрактам. Для обменника это означает: проверка наличия ВЭД-контракта, верификация контрагента-нерезидента, привязка каждого платежа к конкретной поставке, контроль валютного законодательства. Каждая ВЭД-операция — это не «купил BTC за рубли», а многоступенчатый процесс с документальным подтверждением на каждом шаге. Отдельный модуль, отдельная отчётность.

Документооборот. Юрлицам нужны закрывающие документы по каждой сделке: акты, счета-фактуры, подтверждения для бухгалтерии в определённых форматах. Физлицу достаточно выписки в личном кабинете — юрлицу нужен пакет документов, который примет его бухгалтер и налоговая. Это дополнительная логика генерации документов и интеграция с системами электронного документооборота.

Лимиты и квалификация. Для юрлиц не действуют те же ограничения, что для неквалифицированных физлиц — нет годового лимита покупки, нет обязательного тестирования. Но есть свои ограничения: валютный контроль, требования к обоснованию операций, усиленный мониторинг по 115-ФЗ для крупных сумм.

Поддержка. Корпоративные клиенты ожидают другой уровень сервиса: выделенный менеджер, ускоренная реакция на блокировки (остановка платежа может сорвать поставку), помощь с подготовкой документов для налоговой и аудиторов.

Влияние на команду и сроки. Добавление юрлиц увеличивает объём работы примерно на треть: отдельный KYC-процесс, ВЭД-модуль, генерация документов, расширение поддержки. К команде добавляются B2B-менеджеры, юристы по внешнеэкономической деятельности и валютному контролю. Сроки разработки увеличиваются на три-шесть месяцев в зависимости от глубины ВЭД-функционала.

Ряд ключевых параметров, которые напрямую повлияют на архитектуру и бизнес-модель обменника, пока не установлен — они будут определены подзаконными актами Банка России.

Предельная сумма покупки ЦВ для неквалифицированных инвесторов. Закон говорит, что лимит будет, но конкретная цифра не названа. От неё зависит, насколько массовым будет продукт: лимит в 100 тысяч рублей в год — это совсем другой бизнес, чем лимит в миллион.

Перечень ЦВ, допущенных к торгам. Неквалифицированные инвесторы смогут покупать только те криптовалюты, которые прошли листинг на российских организованных торгах. Какие именно — пока неизвестно. От этого зависит ассортимент обменника.

Тарифный потолок комиссий. Закон предусматривает возможность установления максимальной платы за операции. Если потолок будет низким — бизнес-модель обменника, основанная на спреде и комиссиях, может оказаться нерентабельной.

Требования к внутреннему контролю обменника (ст. 46). Конкретный скоуп системы внутреннего контроля и управления рисками — сейчас это заглушка «определит ЦБ». Архитектура модуля должна быть достаточно гибкой.

Порядок тестирования физических лиц (ст. 32). Содержание и формат обязательного теста — пока не определены. Нужно заложить в архитектуру возможность быстро изменить тест после выхода подзаконного акта.

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

Обменник криптовалют на базе облачного депозитария — это не «облегчённый депозитарий» и не «MVP на три месяца». Это полноценный лицензируемый финтех-продукт с собственной лицензией (ст. 18), собственной регуляторной ответственностью и уникальными рисками, которые не покрывает ни один провайдер.

Сторонний депозитарий снимает инфраструктурный слой — но, как мы показали выше, то, что остаётся на стороне обменника, представляет собой полноценную финтех-платформу из восьми модулей со своими сложностями и рисками.

Реалистичный срок разработки обменника — от девяти-двенадцати месяцев для банка с готовой инфраструктурой и от двенадцати-восемнадцати для финтеха. И это при условии, что API облачного депозитария уже готов к интеграции. Параллельно с разработкой идёт организационная подготовка: получение лицензии, вступление в СРО, формирование казначейской политики, найм и обучение комплаенс-офицеров и операторов поддержки, которые понимают специфику крипторынка.

Добавьте к техническим и организационным срокам неопределённость подзаконных актов: лимиты, форматы отчётности, перечень допущенных ЦВ, требования к внутреннему контролю — всё это будет уточняться уже после принятия закона. Часть архитектурных решений придётся принимать в условиях неполной информации и переделывать, когда правоприменительная практика устоится.

Вы увидели, сколько работы предстоит, какая команда нужна и сколько времени займёт путь до запуска. Готовы ли вы к этому и сойдётся ли экономика продукта с такими вводными — вопрос, на который каждый отвечает сам. Спрос на криптовалюту в России измеряется миллионами пользователей, и с вступлением закона в силу легальный канал станет единственным вариантом. Вопрос не в том, будут ли клиенты, а в том, хватит ли маржи при конкретных лимитах и тарифных потолках, которые установит ЦБ. Но в любом случае, понимание полного объёма работы до старта — это то, что отличает проект с управляемыми рисками от проекта, который остановится на полпути из-за неучтённых затрат.