Блокчейн в логистике СНГ: реальные кейсы и ограничения криптоплатежей

Представим поставку, в которой участвуют отправитель, экспедитор, перевозчик и получатель. Груз движется между ними физически. Параллельно стороны подтверждают приёмку, обновляют документы, выставляют счета. Удобно нарисовать всё одной стрелкой, но для проектирования системы нам понадобятся отдельные дорожки.

На дорожке данных главный вопрос: какое событие стороны считают подтверждённым? Например, перевозчик отметил доставку, а получатель ещё не согласовал количество мест этой самой доставки. Это теоретическая ситуация, но она хорошо показывает задачу общего реестра: договориться, чья запись что означает и какое действие запускает. Само слово «доставлено» без такого соглашения мало помогает.

На дорожке денег вопрос другой: кто, кому, сколько и на каком основании платит? Подтверждённая запись может стать основанием для платёжного поручения. Из этого не следует, что деньги должны двигаться в той же системе. Ниже увидим пример, где блокчейн связан с банковскими расчётами.

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

Smart Fuel: данные о заправке и банковские расчёты

В сообщении «Газпром нефти» от 1 марта 2021 года описан завершённый тест Smart Fuel в аэропорту Мурманска. По данным компании, система использовалась более чем на ста регулярных рейсах; партнёрами стали Smartavia, ВТБ и Райффайзенбанк. Заявки на заправку, платёж и обмен учётными документами выполнялись через приложения на планшетах. Компания связала блокчейн с сохранением данных операций и их доступностью для участников. 

Там же описан платёжный модуль ВТБ для расчётов поставщика топлива с авиакомпаниями. Поэтому этот кейс относится не к криптоплатежам, а к автоматизации банковских расчётов. По данным компании, время обработки платежа сократилось с четырёх–пяти дней до пятнадцати секунд.

Для похожего проекта важнее не сам факт использования блокчейна, а момент, когда согласованные данные становятся основанием для платежа. Кто подтверждает объём топлива? Когда сумма становится окончательной? Что происходит при расхождении? Ответы на эти вопросы определяют архитектуру точнее, чем исходное требование «использовать смарт-контракт».

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

AE19 и TradeLens: исторический кейс закрытой платформы

В сентябре 2020 года Maersk описала AE19 как регулярный морской и железнодорожный сервис между Азией и Европой через Россию. Сервис был интегрирован с TradeLens: платформа собирала данные о перевозке от участвующих организаций и передавала их клиентам почти в реальном времени. Это подтверждённый исторический пример использования блокчейн-платформы на маршруте с российским участком.

Но в ноябре 2022 года Maersk объявила о закрытии TradeLens. По объяснению компании, платформе не удалось добиться необходимого уровня отраслевого сотрудничества и коммерческой жизнеспособности. Работу планировали полностью завершить к концу первого квартала 2023 года. Поэтому рассматривать TradeLens как действующий кейс 2026 года нельзя — это исторический пример.

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

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

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

Казахстан–Азербайджан: коридор и цифровые транспортные документы

Министерство транспорта Казахстана сообщило о завершении технической интеграции Track & Trace между Казахстаном и Азербайджаном в рамках Digital Trade Corridor. Сервис позволяет отслеживать местоположение груза и таможенный статус, а также обновлять данные транспортных документов. Это подтверждённый пример интеграции для обмена логистической информацией. 

Использование блокчейна описано отдельно. В презентации Global DTC оператор указывает возможность выпуска электронных коносаментов FIATA eFBL с защитой на основе блокчейна. Global DTC Kazakhstan Ltd также входит в список платформ, подписавших соглашение FIATA о внедрении цифрового FBL. 

Здесь важно разделять подтверждённые факты. Министерство сообщает об интеграции Track & Trace, оператор отдельно описывает работу с eFBL, а FIATA подтверждает участие платформы в программе цифрового коносамента. Эти источники не показывают, что блокчейн используется во всех перевозках по коридору или что eFBL сопровождает каждое отправление.

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

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

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

В России с 1 сентября 2026 года действует закон № 282-ФЗ «О цифровых валютах и цифровых правах». Он сохраняет общий запрет на оплату товаров и услуг цифровой валютой, но делает исключение для внешнеторговых договоров между резидентами и нерезидентами. В том числе речь может идти об оплате товаров, работ и услуг. При этом само исключение не означает, что для конкретной сделки больше нет других требований к расчётам и участникам операции.

Отдельно нужно учитывать иностранные санкционные режимы. Например, OFAC прямо указывает: для лиц, подпадающих под его юрисдикцию, требования санкционного законодательства действуют одинаково независимо от того, проходит операция в обычной или цифровой валюте. Для связанных с Россией операций OFAC отдельно подтверждает тот же принцип. Иными словами, замена банковского перевода криптовалютой сама по себе не делает запрещённую операцию разрешённой.

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

Что проверить до расчёта

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

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

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

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

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

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

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

1. Зафиксируйте проблему и исходный замер. Выберите конкретный документ или повторяющуюся операцию. Измерьте время обработки, число расхождений, ручную нагрузку и стоимость процесса до внедрения.
2. Определите участников и владельцев данных. Зафиксируйте, кто создаёт запись, кто подтверждает событие и кто отвечает за исправление ошибки. Участие ключевых организаций лучше подтвердить до старта пилота.
3. Обоснуйте необходимость общего реестра. Сравните блокчейн-архитектуру с централизованным сервисом. Если обычная база решает ту же задачу, нужно понимать, какую дополнительную ценность даёт распределённый реестр.
4. Проверьте исключения и сценарий выхода. Смоделируйте ошибочный документ, недоступность интеграции и отказ участника подтвердить событие. Проверьте выгрузку истории, сохранение документов и резервный процесс.
5. Отделите расчёты от документооборота. Если в проекте рассматриваются криптоплатежи, их нужно отдельно согласовать с финансовой и юридической службами: договор, контрагенты, ограничения, конвертация и учёт.
6. Заранее задайте критерии продолжения. Сравните пилот с исходным процессом по тем же метрикам. Если нужные участники не подключились, ручная нагрузка не снизилась или затраты выросли без понятного эффекта, стоит пересмотреть сам процесс или архитектуру.

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