Начните с права, а не с токена
Одинаково выглядящие записи могут означать денежное требование, право на ценную бумагу, доступ к сервису, подтверждение происхождения, цифровую валюту или просто технический идентификатор. Название токена не определяет его режим.
Для каждого объекта опишите эмитента, обязанное лицо, содержание права, условия возникновения и погашения, допустимых владельцев, место официального учёта и порядок разрешения спора. Если право существует только в договоре, а токен служит ссылкой, именно договор остаётся главным источником обязательства.
Разделяйте ЦФА и цифровую валюту
В российском контуре ЦФА являются цифровыми правами, включая определённые денежные требования и иные прямо предусмотренные законом права. Их выпуск и обращение проходят в информационных системах операторов, включённых Банком России в реестр. ЦФА не являются средством платежа.
Цифровая валюта имеет иной режим и инфраструктуру. Нельзя переносить на неё процессы, лимиты и контрольную модель ЦФА только потому, что обе технологии могут использовать распределённый реестр. Перед операцией юридическая и финансовая функции должны подтвердить актуальный режим конкретного объекта и участника.
Постройте реестр цифровых активов
Внутренний реестр должен связывать внешний идентификатор актива с договором или решением о выпуске, оператором, владельцем внутри организации, кошельком или счётом, стоимостью приобретения, ограничениями, сроками, событиями дохода и погашения.
Для каждой записи храните источник оценки, дату курса, комиссию, подтверждающий документ и ссылку на внешнюю операцию. Реестр не заменяет официальный учёт оператора или бухгалтерскую систему, а соединяет их для контроля и аудита.
Разделите инициирование, подтверждение и хранение
Один сотрудник не должен единолично создать адрес, инициировать перевод и подтвердить его учёт. Используйте матрицу полномочий, лимиты по сумме и виду актива, многостороннее подтверждение, белые списки адресов и задержку для критичных операций.
Ключи рассматриваются как средство доступа к активу. Нужны регламент создания, защищённое хранение, резервирование, ротация, отзыв, восстановление и действия при компрометации. Секрет в таблице, почте или переменной окружения обычного приложения не обеспечивает достаточного контроля.
Учёт должен начинаться до первой сделки
До приобретения или выпуска согласуйте первичные документы, момент признания, модель оценки, обработку комиссий, переоценку, обесценение, доход, выбытие и раскрытие. Автоматическая выгрузка из платформы не гарантирует корректной классификации в учёте.
Ежедневная или периодическая сверка сопоставляет внутренний реестр, данные оператора, бухгалтерскую систему и подтверждения блокчейна. Расхождение блокирует дальнейшее движение соответствующего актива до разбора.
Контрагент и оператор входят в модель риска
Проверьте, присутствует ли оператор в актуальном реестре регулятора, какие правила информационной системы действуют, как восстанавливается доступ, где находятся данные, как исполняются судебные решения и что произойдёт при прекращении работы платформы.
Для контрагента фиксируются идентификация, полномочия, адреса, санкционные и иные обязательные проверки, экономический смысл операции и источник средств там, где это требуется. Технически успешный перевод не означает, что операция допустима и правильно отражена.
Готовность подтверждается контрольным сценарием
Проведите сквозной тест: утверждение операции, создание заявки, подписание, исполнение, получение подтверждения, отражение в реестре и учёте, сверка, отчётность и восстановление доступа. Затем отработайте ошибочный адрес, потерю ключа, недоступность оператора, спор и выявление операции после закрытия периода.
Компания готова к цифровым активам, когда может назвать владельца процесса, показать основание каждой записи, доказать разделение полномочий, восстановить историю оценки и безопасно остановить операцию. Покупка кошелька или интеграция API сама по себе такой готовности не создаёт.