Криптобиржа с KYC: как построить безопасную платформу

Этот кейс показывает, как был структурирован проект и какие решения имели значение: автоматическая проверка личности, разделение средств между hot и cold wallet, отслеживаемость операций и контроль доступа. Это не готовый план лицензирования. Регуляторные требования зависят от деятельности, юрисдикции и действующих правил, поэтому юридическая и compliance-команда должна участвовать с самого начала.

Какую проблему решала Crypto.bg?

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

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

• Процесс KYC с проверкой документа, лица и профиля риска.
• Депозиты и вывод средств в левах через банковские интеграции.
• Кошельки с разным подходом к повседневным операциям и основным средствам.
• Order matching engine для limit- и market-ордеров.
• Audit trail действий и транзакций.
• Контроль доступа, двухфакторная аутентификация, rate limiting и защита публичных сервисов.

Проект начался после неудачной попытки с внешней командой. Имевшийся код не соответствовал требованиям безопасности и не включал необходимую compliance-логику. Вместо того чтобы надстраивать систему на нестабильной основе, мы определили, какие части нужно спроектировать заново.

Как мы спроектировали систему?

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

Как работала KYC-верификация?

Для автоматической проверки мы интегрировали Sumsub. Пользователь фотографирует документ, удостоверяющий личность, система извлекает данные с помощью OCR и выполняет проверку liveness. Затем проводятся проверки по санкционным спискам и PEP screening, а профилю присваивается оценка риска.

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

Как мы защитили кошельки и транзакции?

Мы использовали двухуровневую архитектуру wallet. Hot wallet обслуживает повседневные операции и содержит ограниченную часть активов. Основные средства хранятся в cold wallet с multi-signature контролем. При достижении определённого порога автоматический процесс sweep переводит средства из hot wallet в cold wallet.

Private-ключи управляются с помощью HSM. Двухфакторная аутентификация защищает пользовательские и административные профили, а rate limiting и WAF ограничивают злоупотребления публичными endpoints. Эти меры не заменяют процедуры доступа, одобрения и реагирования на инциденты. Они создают техническую основу, на которой эти процедуры могут работать.

Важной частью было и разделение ролей. Сотрудник, который рассматривает KYC-кейс, не должен автоматически иметь те же права, что и администратор wallet-инфраструктуры. Так взлом одного профиля не открывает доступ ко всем системам одновременно.

Как работала торговля на платформе?

Мы разработали custom order matching engine на C# для limit- и market-ордеров. Order book отображался в реальном времени через WebSocket, поэтому странице не приходилось постоянно перезагружаться. Backend был построен на C# .NET, а PostgreSQL и Redis обеспечивали работу с основными данными и кеширование.

У каждого баланса и каждой транзакции должна быть понятная причина и источник. Поэтому логика matching, изменения балансов и административные действия записывались в audit log. Это не обычный лог ошибок. В финансовом ПО должно быть возможно отследить, что произошло, когда и в результате какой операции.

Для интерфейса мы использовали Next.js и компоненты TradingView. Цель заключалась в том, чтобы начинающий пользователь мог купить или продать криптовалюту, не разбираясь во всей внутренней архитектуре, а опытный пользователь имел доступ к order book и графикам.

Какие интеграции были необходимы?

Криптоплатформа не работает изолированно. Она должна обмениваться данными с KYC-провайдером, банковскими системами, blockchain nodes и внутренними сервисами уведомлений и контроля. Каждая интеграция — потенциальная точка отказа, поэтому мы отдельно обрабатывали timeout, повтор запроса, дублированный запрос и частично выполненную операцию.

• Sumsub для проверки документов, liveness и screening.
• Банковские интеграции для депозитов и вывода средств в левах.
• Bitcoin, Ethereum и USDT nodes для операций в blockchain.
• Redis для быстрых временных данных и PostgreSQL для основных записей.
• WebSocket-соединение для обновления рынка в реальном времени.
• WAF, rate limiting и 2FA для защиты публичного и административного доступа.

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

Как проходила разработка такого проекта?

1. 01
   Определение операций и ограничений

   Описываются регистрация, уровни KYC, лимиты, депозиты, вывод средств, ордера, операции с wallet, блокировка профиля и административные роли. Без этого команда начинает писать код, имея неполную картину.

2. 02
   Моделирование данных и прав доступа

   Проектируются профили, балансы, ордера, транзакции, операции в blockchain и audit log. Определяется, какой сотрудник может просматривать, одобрять или изменять каждую информацию.

3. 03
   Разработка критически важных сервисов

   Сначала разрабатываются API, логика matching, ledger, операции с wallet и KYC-интеграция. Визуальные элементы добавляются после того, как основные правила можно протестировать.

4. 04
   Тестирование и контролируемые сценарии

   Проверяются не только успешные операции, но и прерванный банковский запрос, повторный платёж, отклонённый документ, задержка blockchain node и попытка доступа без необходимых прав.

5. 05
   Аудит и подготовка к эксплуатации

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

Какие технологии мы использовали?

Основной стек включал C# .NET 8, микросервисную архитектуру, PostgreSQL, Redis, Next.js 14, компоненты TradingView и blockchain nodes для Bitcoin, Ethereum и USDT. Для безопасности мы использовали HSM, 2FA, rate limiting и WAF, а для KYC — интеграцию с Sumsub.

Микросервисы не всегда лучше монолита. В данном случае разделение имело смысл, поскольку торговля, KYC, операции с wallet и административный контроль связаны с разными рисками и нагрузкой. Если проект меньше, более простая архитектура может быть разумнее и дешевле в обслуживании.

Сколько стоит разработка криптобиржи?

Некорректно называть универсальную цену, ориентируясь только на слова «криптобиржа». Платформа только для покупки и продажи через внешнюю ликвидность — это другой проект по сравнению с собственной биржей с order matching engine, банковскими интеграциями, wallet-инфраструктурой, KYC и административным compliance-модулем.

Чтобы сформировать обоснованное предложение в евро, сначала нужно описать активы, страны, банки, KYC-провайдера, модель хранения и ожидаемую нагрузку. В противном случае низкая начальная цена почти всегда означает, что критически важные части отложены «на потом».

Что мы узнали из проекта?

• Безопасность проектируется с первого дня, а не добавляется перед запуском.
• Compliance должен быть частью продуктового процесса, а не отдельной таблицей за пределами системы.
• Автоматизация полезна в стандартных случаях, но нестандартные ситуации должны передаваться специалисту.
• Аудитный след — это функциональность, а не просто технический лог.
• Пользовательский интерфейс должен скрывать сложность, не скрывая важные ограничения и комиссии.

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