Описание

Описание MVP DARCA

Info

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

---

Краткий обзор MVP

Пилот в России стал практическим стресс-тестом “фиат + крипто в одном приложении”: мы проверили привычку, доверие, предсказуемость критических действий и устойчивость операций.

Note

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

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

В пилоте мы сознательно держали фокус на том, что создаёт привычку и доверие:

• быстро доводим до первой ценности (первое пополнение, первая операция, первый внутренний перевод)
• делаем критические действия предсказуемыми (статусы, подтверждения, понятный результат до нажатия “подтвердить”)
• проверяем продукт на реальном объёме операций, а не в лабораторном режиме

Tip

Мы оцениваем MVP не “по словам”, а по тому, как пользователь проходит путь: где ускоряется, где ошибается, где возвращается, и какие действия становятся регулярными.

Условия пилота: период и география

География: Россия.
Период: октябрь 2024 - май 2025.

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

Что было “в продукте” в рамках MVP

MVP был собран как управляемый набор контуров, который закрывает ежедневные сценарии и даёт основу для входа-выхода, при этом сохраняя цельность “всё в одном месте”.

Сначала - базовый контур активов: одновременно фиат и крипто.

• Фиатные балансы: RUB и USD
• Крипто-активы: USDT (TRC-20), TRX, USDT (BEP-20), BNB

На этой базе работали ключевые пользовательские действия и “петля привычки”:

• пополнения и транзакции внутри приложения
• мгновенные внутренние переводы без комиссии как основа “ежедневного” сценария
• крипто-транзакции (в рамках поддерживаемых сетей)

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

• внутренний мгновенный обменник (с предпросмотром итогового результата до подтверждения)
• P2P-маркетплейс как гибкий контур входа/выхода

И отдельно - ранний тест спроса на новый класс активов:

• покупка RWA в формате доли недвижимости как тест интереса и сценария “инвест-актива в кошельке”

Чтобы финансовый продукт выдерживал реальную эксплуатацию, в MVP также работали обязательные контуры качества:

• чат-поддержка внутри приложения
• базовые KYC-процедуры и риск-контроль в рамках пилота
• мониторинг стабильности и операционные процессы для качества сервиса

Example

Важно, что эти блоки проверялись не отдельно, а как единый путь: активы → действие → предсказуемый результат → повторяемость.

Что мы сознательно НЕ пытались сделать в MVP

MVP был построен так, чтобы давать чистые сигналы, а не имитировать “идеальный суперапп”. Поэтому мы сознательно удержали объём в зоне проверки базовой ценности, не размывая картину лишними слоями.

Warning

Чем больше “всего сразу” в пилоте, тем больше шум в данных и тем сложнее понять, что реально влияет на поведение пользователей.

В MVP мы не включали:

• расширенную линейку активов и сетей “всё сразу”
• сложные инвестиционные продукты и комбинированные стратегии
• полноценные подписочные уровни и глубокую тарифную сетку
• тяжёлую корпоративную автоматизацию (ERP-интеграции, массовые корпоративные роли, сложные регламенты)
• витрину “всех возможных модулей” - в MVP мы оставили только те модули, которые критичны для проверки спроса и поведения

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

Пользователи и сценарии использования

MVP проектировался вокруг повторяемых пользовательских маршрутов: быстрые переводы, обмен, P2P и ранний спрос на RWA как “инвест-актив в кошельке”.

Info

Мы описываем MVP через поведение и сценарии, потому что именно так видно, что продукт реально используют, а не просто “посмотрели”.

Кого мы проверяли на MVP: сегменты, где “боль” измеряется действиями

Мы запускали MVP не “для всех сразу”, а для аудиторий, где ценность проявляется быстро и измеримо: через депозиты, транзакции, повторяемость и выбор инструментов (внутренние переводы, обмен, P2P).

Ключевые сегменты:

• Retail-пользователи (частные лица)
  Люди, которым нужен быстрый перевод и понятный статус операции. Это же аудитория, которая хочет “крипто без боли”: пополнить, купить/обменять, отправить или вывести, не погружаясь в сложные процессы и не собирая инфраструктуру из множества сервисов. Для части пользователей важен Peer-to-peer как контур входа/выхода: им критичны гибкость и скорость закрытия сделок. И отдельно - те, кто осознанно хочет держать фиат и крипто в одном месте, чтобы не дробить баланс и действия.

• Power users (активные пользователи)
  Это аудитория, которая не делает 1-2 операции “на пробу”, а регулярно использует продукт, комбинируя несколько функций. Они дают самый честный сигнал зрелости: если им удобно, продукт выдерживает масштабирование.

• Бизнес-сценарии (как контур MVP)
  В рамках пилота мы также проверяли практический сценарий, когда бизнесу нужно принимать платежи и работать с крипто-операциями в связке с понятной “банковской” логикой. При этом бизнес-контур держали компактным, чтобы не размывать основной фокус - проверку массовых пользовательских сценариев.

Tip

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

Персоны: какие роли мы видели в продукте и что для них было критично

Чтобы MVP воспринимался как цельная система, мы описываем его через персоны и их реальные маршруты, а не через список функций.

Персона 1 - “Мне нужен быстрый перевод”
Человек хочет отправить средства другому пользователю быстро и без лишних шагов. Важен мгновенный статус и ощущение, что перевод работает “как сообщение”. В метриках MVP это подтверждается тем, что внутренние операции отображались и подтверждались менее чем за 1 секунду.

Персона 2 - “Я хочу крипто без боли”
Человек хранит и использует крипто-активы, но ему важно отсутствие лишних сложностей и ошибок. Ключевой момент ценности - предсказуемость результата: до подтверждения видно, что отдаёшь и что получишь (You pay / You receive).

Персона 3 - “P2P как вход/выход”
Пользователь покупает и продаёт через P2P и ожидает быстрое закрытие сделок и понятную механику споров. Метрики это показывают: median close time ~17 минут, dispute rate ~1.8%.

Персона 4 - “Я тестирую RWA”
Пользователь хочет увидеть реальный актив в понятном цифровом виде. В MVP мы проверяли спрос на RWA в формате доли недвижимости как сценарий “инвест-актива в кошельке”. Это подтверждается цифрами: waitlist 1 328, закрытый тест 133, тестовые инвестиции ~$0.32M.

Note

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

Повторяемые сценарии: как пользователь реально проходил путь

Мы смотрели на MVP как на набор сценариев, которые должны стать регулярными. Поэтому фиксировали не “наличие функции”, а маршрут и результат.

Сценарий A - “Первый быстрый успех”
Регистрация → (при необходимости) KYC → первый депозит/активация → первая транзакция.
Этот сценарий определяет, понял ли пользователь продукт за первые минуты. Метрики подтверждают, что воронка доходила до действий: из 42 653 регистраций KYC прошли 26 879, а “1+ транзакция ever” сделали 26 044 пользователей.

Сценарий B - “Внутренний перевод как ежедневное действие”
Выбор получателя → сумма → подтверждение → мгновенный статус и получение.
В MVP внутренние операции стали одним из ключевых драйверов: доля внутренних операций 34%, подтверждение/статус меньше 1 секунды.

Сценарий C - “Обмен внутри приложения”
Выбор пары → ввод суммы → предпросмотр результата (You pay / You receive) → подтверждение → исполнение → статус.
В обменнике был зафиксирован существенный объём: ~$8.1M.

Сценарий D - “P2P как контур входа/выхода”
Выбор оффера → фиксация условий → Escrow → подтверждение оплаты → завершение → результат.
В метриках: объём P2P ~$9.1M, 34 839 сделок, median close ~17 минут, dispute rate ~1.8%.

Сценарий E - “RWA как новый класс актива”
Ознакомление → лист ожидания → закрытый тест → тестовая покупка → отображение в портфеле.
Мы проверяли интерес, понятность UX и доверие к активу “из реального мира”.

Example

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

Что показало поведение пользователей

MVP дал главное: пользователи не просто “зарегистрировались”, а дошли до действий и повторяемости. Это видно по сочетанию стабильных MAU/DAU, retention и существенного транзакционного объёма в разных контурах (внутренние переводы, обмен, P2P, RWA).

Активы, сети и платёжные контуры MVP

Мы сознательно ограничили набор активов и сетей, чтобы проверить скорость, стабильность и предсказуемость операций на реальном спросе без распыления на “всё сразу”.

Info

MVP строился вокруг логики управляемого периметра: меньше активов и сетей, но выше качество, проще контроль риска и быстрее итерации.

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

Фиатный контур: базовые валюты

В пилоте были доступны фиатные балансы:

• RUB
• USD

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

Note

Наличие фиатного контура в MVP позволило проверять сценарии “вход-выход” и P2P без необходимости уходить в сторонние приложения и банки, а значит мы быстрее увидели, где именно возникает трение и ошибки.

Крипто-контур: активы MVP

В пилоте были доступны крипто-активы:

• USDT (TRC-20)
• TRX
• USDT (BEP-20)
• BNB

Выбор был сделан в пользу тех активов, которые наиболее практичны для массовых сценариев: хранение “цифрового доллара” и быстрые переводы, а также достаточная ликвидность для обмена и P2P.

Сетевые контуры: где происходили крипто-операции

Крипто-операции в MVP были сосредоточены в сетях:

• TRC-20 (для USDT и TRX)
• BEP-20 (для USDT и BNB)

Этот выбор позволил проверить реальные пользовательские риски, которые характерны для рынка: ошибки “не та сеть”, “не тот адрес”, ожидания “внутри бесплатно” и т.д., и одновременно держать стоимость и скорость операций в понятных рамках.

Warning

Ограничение сетей в MVP было не “урезанием продукта”, а способом обеспечить качество и контроль риска на этапе, когда важнее всего подтвердить жизнеспособность ядра.

Платёжные и транзакционные контуры: что реально работало

Чтобы у пользователя была цельная система, в MVP работали ключевые контуры действий:

1) Внутренние транзакции внутри приложения
Это основа ежедневного поведения:

• пополнения и операции внутри приложения
• мгновенные внутренние переводы без комиссии

Именно этот контур проверял, можем ли мы дать ощущение “банка-мессенджера”, где деньги перемещаются так же просто, как сообщение.

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

3) Контур мгновенного обмена
В MVP работал внутренний мгновенный обменник, который решает проблему неожиданной цены и “скрытого результата”: пользователь видит итог до подтверждения и понимает, что произойдёт.

4) Контур P2P
P2P-маркетплейс был подключён как способ входа-выхода и альтернативный контур ликвидности, который проверяет скорость закрытия сделок, стабильность и работу арбитража.

5) Ранний контур RWA
Чтобы проверить спрос на “инвест-актив в кошельке”, в MVP была доступна покупка RWA в формате доли недвижимости.

Example

В сумме эти контуры закрывали главный тест MVP: может ли пользователь пройти путь “фиат → крипто → обмен → P2P/перевод → обратно” в одном приложении, без фрагментации и без необходимости собирать свой стек из нескольких сервисов.

Внутренние переводы

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

Info

Внутренние переводы в MVP - это не “дополнительная функция”, а базовый механизм, который создаёт повторяемость, снижает ошибки и убирает фрагментацию между сервисами.

Как это работало в MVP

Внутри приложения пользователь мог переводить средства другим пользователям в рамках экосистемы, получая понятный и быстрый опыт: “отправил - получил - вижу статус”.

Ключевые свойства внутреннего контура в MVP:

• мгновенность подтверждения и отображения статуса
  Внутренние операции отображались и подтверждались менее чем за 1 секунду.
• без комиссии внутри экосистемы
  Пользователь не думает о сетевых комиссиях и не вынужден держать отдельный баланс “на оплату газа” только ради того, чтобы отправить деньги другому человеку.
• предсказуемый результат
  Пользователь видит итог и статус сразу, без “подвешенных” состояний, которые типичны для внешних сетевых операций.

Note

Именно внутренние переводы формируют ощущение “банк работает как мессенджер”: деньги перемещаются так же просто, как сообщение, и это резко снижает барьер регулярного использования.

Почему этот контур важен для рынка

Этот механизм напрямую закрывает рыночные проблемы, которые мы видим у пользователей:

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

Что показали данные MVP

Внутренние переводы стали одним из самых сильных контуров использования:

• доля внутренних операций составила 34% всех операций
• подтверждение и отображение статуса происходило меньше 1 секунды

Это важный сигнал: пользователи не просто пробуют внутренний перевод, а реально включают его в повседневное поведение.

Tip

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

Внутренний мгновенный обменник

Обменник в MVP закрыл “самую болезненную” часть крипто-опыта: конвертацию между активами без лишних шагов, без фрагментации и с понятным итогом до подтверждения.

Info

Внутренний обменник - это механизм, который превращает “крипто-кошелёк” в финансовый инструмент: пользователь может быстро менять структуру баланса под задачу и делать это в одном месте.

Как это работало в MVP

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

Ключевой принцип обменника в MVP - предсказуемость результата. Перед подтверждением операции пользователь видит итог:

• что именно спишется
• что именно зачислится
• в каком активе будет результат

Это снижает один из главных источников недоверия на рынке: когда человек совершает обмен, а итоговая сумма и условия “всплывают” постфактум.

Note

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

Почему этот контур важен для рынка

Обмен - это не “дополнительная функция”, а узел, через который проходят многие сценарии:

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

Именно здесь у большинства продуктов возникают проблемы: разрыв UX, непонятная цена, сложность и ощущение “меня обманут”.

В MVP обменник снижает эти проблемы за счёт:

• простоты (без перехода в сторонние сервисы)
• скорости (мгновенное исполнение внутри)
• прозрачности (итог виден до подтверждения)

Warning

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

Что показали данные MVP

Обменник в MVP зафиксировал реальный транзакционный объём:

• общий объём через обменник составил ~$8.1M

Это подтверждает, что обмен был не “фичей для галочки”, а реально используемым контуром в ежедневных маршрутах.

Tip

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

P2P-маркетплейс

P2P в MVP стал контуром входа и выхода и проверкой доверия: скорость закрытия, работа escrow и управляемость споров показывают, выдерживает ли продукт реальный рынок.

Info

P2P в MVP - это не “биржа ради биржи”, а рыночный контур, который помогает пользователю решить практическую задачу: купить или продать актив в удобном формате, оставаясь в рамках одной экосистемы.

Как это работало в MVP

В MVP был запущен P2P-маркетплейс с понятной логикой сделки, где важны три вещи: фиксация условий, безопасность расчётов и быстрый финал.

Ключевой принцип - сделка должна быть управляемой и предсказуемой:

• условия сделки фиксируются в момент выбора оффера
• актив резервируется через Escrow, чтобы сделка не зависела от “честного слова”
• при корректном выполнении условий сделка закрывается, а актив переходит покупателю

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

Note

В MVP P2P был важен как проверка доверия: если пользователь верит, что сделка закрывается честно и быстро, он возвращается и начинает использовать контур регулярно.

Почему этот контур важен для рынка

P2P решает несколько типичных рыночных проблем, которые напрямую влияют на массовое принятие:

• фрагментация
  Пользователь не уходит в отдельную биржу или сервис - вход/выход происходит в рамках одной системы.
• непредсказуемость результата
  Сделка имеет понятный статус, escrow и логику завершения.
• риски споров
  Споры не разрушают продукт, если есть прозрачный контур арбитража и управляемость сценариев.
• скорость
  Для массового пользователя важно не “самое выгодное”, а “достаточно выгодно и быстро”, чтобы операция не превращалась в стресс.

Warning

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

Что показали данные MVP

P2P-контур в пилоте показал существенную активность и объём:

• общий объём P2P составил ~$9.1M
• количество сделок: 34 839
• медианное время закрытия: ~17 минут
• доля споров: ~1.8%

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

Tip

P2P усиливает экосистему: он создаёт дополнительную ликвидность внутри и снижает зависимость пользователя от внешних площадок, сохраняя контроль опыта и качество сервиса.

RWA (ранний модуль: доля недвижимости)

RWA в MVP был включён как ранний тест спроса: можем ли мы превратить “инвест-актив из реального мира” в понятный цифровой инструмент внутри кошелька.

Info

RWA в MVP - это не попытка “сразу построить большой рынок”, а проверка ключевого тезиса: пользователь готов покупать реальный актив в форме цифровой доли, если интерфейс прозрачен, а правила понятны.

Зачем мы включили RWA в MVP

Мы подключили RWA на раннем этапе, чтобы проверить три фундаментальные вещи:

• интерес пользователей к активам “вне крипто” (не только токены и монеты, но и “реальный мир”)
• понимание продукта: может ли пользователь быстро объяснить себе, что он покупает и почему это имеет смысл
• доверие к механике: готов ли человек хранить и управлять таким активом внутри одного приложения

Именно поэтому мы выбрали формат доли недвижимости - он понятен рынку и легко ложится на “портфельную” логику: актив может быть частью стратегии, а не “ставкой на цену монеты”.

Note

Добавление RWA в MVP позволило протестировать не только продуктовую идею, но и то, как меняется поведение: появляются ли новые типы пользователей, растёт ли доверие и удержание за счёт “долгого” актива в портфеле.

Как это выглядело в MVP

В MVP RWA был подключён как ограниченный контур, ориентированный на проверку спроса и UX. Пользователь мог:

• увидеть актив как часть портфеля
• попасть в лист ожидания
• участвовать в закрытом тесте
• сделать тестовую покупку

Это был намеренно “управляемый” режим, чтобы собрать качественные сигналы и не превращать MVP в юридически и операционно тяжёлую систему на раннем этапе.

Warning

На этапе MVP RWA работал как ранняя проверка интереса и механики. Мы сознательно не раскрывали весь потенциал RWA, чтобы не размывать цель пилота и не усложнять продуктовую картину.

Что показали данные MVP

RWA показал самостоятельный спрос и готовность пользователей к новому классу активов:

• лист ожидания: 1 328
• закрытый тест: 133
• тестовые инвестиции: ~$0.32M

Это важный сигнал: даже в раннем формате, без “полной витрины” и без масштабной маркетинговой машины, пользователи проявили интерес и совершили реальные действия.

Tip

RWA в MVP стал подтверждением, что DARCA может быть не только “кошельком и переводами”, но и основой для долгосрочных финансовых продуктов, которые повышают удержание и расширяют рынок.

Поддержка и коммуникации внутри MVP

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

Info

В финансовом продукте поддержка - это часть системы надёжности: она влияет на удержание так же, как скорость транзакций и качество UX.

Что было реализовано в MVP

В пилоте был включён in-app чат, который решал две задачи одновременно:

• помогал пользователю пройти критические действия (переводы, обмен, P2P) без “паники” и ошибок
• собирал сигналы о том, где продукт ломается на реальном поведении, чтобы мы могли быстро чинить первопричины

Коммуникации строились вокруг простого принципа: если пользователь ошибся или не понял механику, задача поддержки - не “прочитать инструкцию”, а довести до результата, сохранив доверие к продукту.

Note

Мы не рассматривали поддержку как “добавочный сервис”. В MVP это был контур, который удерживал качество и позволял безопасно масштабировать продукт.

Какие темы обращений доминировали и почему это важно

В MVP мы увидели типичный паттерн рынка: пользователи чаще всего сталкиваются не с “техническими багами”, а с ошибками и ожиданиями, которые формируются старым опытом.

Наиболее частые причины обращений:

• ошибки адреса (не туда отправили)
• ошибки сети (выбрали не ту сеть)
• ожидание, что “везде будет без комиссии”, потому что привыкли к внутренним безкомиссионным переводам
  Пользователи часто не держали средства для оплаты сетевой комиссии при внешних отправках, и поддержке приходилось объяснять, что “без комиссии” относится к внутренним переводам, а внешние комиссии - это стандартная комиссия сети, а не комиссия банка.

Эти обращения важны тем, что показывают, где именно рынок теряет доверие. И одновременно - где продукт может стать сильнее: снижать ошибки интерфейсом, предупреждениями и обучением, а поддержку постепенно превращать из “пожарной команды” в инструмент повышения качества.

Tip

Каждый такой кейс - это не “минус”, а материал для улучшений: если снизить частоту ошибок “адрес/сеть” и недопонимания комиссий, падает нагрузка на поддержку и растёт конверсия в повторное использование.

Почему коммуникации внутри MVP были критичны

Поддержка в MVP напрямую работала против ключевых рыночных проблем:

• против низкого качества обслуживания (быстрый контакт и понятное решение)
• против фрагментации (не надо “искать решение” по чатам и форумам - всё в одном месте)
• против ошибок пользователя, которые в крипто часто необратимы и стоят денег

Именно поэтому в MVP поддержка и коммуникации рассматривались как часть “ядра надёжности”, а не как опция.

Warning

В крипто-продуктах ошибки пользователя часто необратимы. Если продукт не даёт поддержки и объяснений “в моменте”, он теряет доверие быстрее, чем в классическом банкинге.

Надёжность, безопасность и контроль рисков (публичная рамка)

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

Info

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

Надёжность как продуктовая функция, а не “техническая деталь”

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

• понятные статусы критических операций (переводы, обмен, P2P)
• контроль целостности транзакций и корректности зачислений
• операционный мониторинг стабильности, чтобы реальный пользовательский поток не превращался в “эксперимент”

Note

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

Базовая безопасность в MVP: что было включено

В пилоте работали базовые контуры, которые позволяют финансовому продукту существовать в реальности:

• базовые процедуры KYC в рамках пилота
• минимально необходимый риск-контроль по операциям и поведению
• контроль доступов на уровне приложения и стандартные меры защиты пользовательской сессии
• фиксация и разбор спорных ситуаций в P2P как часть контроля доверия

При этом мы сознательно не “перегружали” MVP тяжёлыми мерами, которые мешают скорости и первому впечатлению, потому что задача пилота была проверить жизнеспособность ядра и пользовательские маршруты.

Warning

Важно: мы не раскрываем публично конкретные пороги, триггеры и внутренние правила антифрода. Это защищает систему, а не “прячет информацию”.

Контроль рисков: как мы удерживали систему управляемой

В MVP мы применяли подход управляемого периметра, чтобы одновременно сохранять удобство и не допускать перекоса в риск:

• ограниченный набор активов и сетей в пилоте, чтобы снизить вероятность ошибок и спорных сценариев
• риск-ограничения и проверки в рамках пилота (по принципу: “безопаснее по умолчанию”)
• поддержка внутри приложения как инструмент снижения рисков ошибок пользователя (адрес, сеть, ожидания по комиссиям)

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

Tip

Там, где рынок обычно “лечит” риск только ограничениями, мы в MVP одновременно лечили его и продуктом: предупреждениями, объяснениями, маршрутами без лишних ошибок и поддержкой в момент действия.

Как это масштабируется дальше

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

Завершение пилота и защита пользователей

Завершение MVP было выстроено как управляемый процесс: без подвешенных операций, с чистой финальной сверкой и приоритетом защиты средств - доверие сохраняется действиями.

Info

Завершение пилота - это часть механики доверия: рынок запоминает не только запуск, но и то, как система закрывает цикл.

10.1. Почему мы остановили регистрацию

Регистрация новых пользователей в MVP была приостановлена по внешним административно-политическим причинам, которые сделали невозможным продолжение расширения пилота в прежнем формате.

Важно: это не было связано с “поломкой продукта”. Решение было вызвано внешними условиями. Поэтому завершение MVP мы выстроили как управляемый процесс, где приоритеты неизменны:

• защита пользователей
• корректность операций
• прозрачная финальная сверка

Note

В финансовом продукте критична предсказуемость: пользователь должен понимать, что происходит с его средствами и статусами, даже когда внешняя среда меняется.

---

10.2. Как мы завершали пилот: controlled wind-down

Мы завершали пилот не “резко выключив систему”, а в режиме controlled wind-down - когда продукт продолжает работать для существующих пользователей, а команда целенаправленно закрывает риски, долги и операционные хвосты.

Что было сделано в рамках управляемого завершения:

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

И ключевой факт завершения: все активы были полностью переданы пользователям - мы обеспечили корректный и безопасный выход из пилота без “зависших” средств и неопределённости.

Warning

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

---

10.3. Что даёт такой финал для следующего этапа

Завершение пилота “без хвостов” фиксирует:

• чистую базу без подвешенных статусов
• подтверждённые продуктовые выводы и поведенческие данные
• укреплённые контуры надёжности и контроля рисков

Tip

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