# Карта функционала ## Карта функционала B2C-сервиса: СБП → USDT → крипто-картовый провайдер → карта клиенту Документ описывает полный функциональный и процессный периметр B2C-сервиса, в рамках которого: * пользователь пополняет кошелёк рублями через СБП * под капотом сервис конвертирует RUB → USDT и пополняет баланс в upstream (крипто-картовый провайдер, например Tevau / Interlace / Qbit / DiPocket / Wallester) * пользователь получает карту по одному из тарифов (виртуальная / физическая, разные лимиты и фичи) и тратит её онлайн / офлайн / через Apple Pay и Google Pay Ниже — полная карта: от фронта до treasury и compliance. Формат единый: что за блок → зачем нужен → что внутри. *** ### Архитектурный слой ``` Пользователь (Web + Telegram Mini App + iOS/Android) │ ▼ ┌────────────────────────────────────────────────────────┐ │ Фронт сервиса: LK, витрина тарифов, блог, FAQ │ └────────────────────────────────────────────────────────┘ │ │ ▼ ▼ ┌─────────────────────────┐ ┌─────────────────────────┐ │ Core backend (API) │◄────►│ KYC-провайдер │ │ - ledger │ │ (Sumsub / Veriff) │ │ - user / cards / tx │ └─────────────────────────┘ │ - rules engine │ │ - reconciliation │ └─────────────────────────┘ │ │ ┌─────────────────────────┐ │ └─────────────►│ Upstream card issuer │ │ │ (Tevau / Interlace / │ │ │ Qbit / DiPocket и др.) │ │ └─────────────────────────┘ ▼ ┌─────────────────────────┐ │ СБП-агент (РФ-юрлицо) │ → ┌─────────────────────────┐ │ приём RUB │ │ OTC-контрагент │ └─────────────────────────┘ │ RUB → USDT │ └─────────────────────────┘ │ ▼ ┌─────────────────────────┐ │ USDT treasury │ │ hot / warm / cold │ └─────────────────────────┘ ``` *** ### 1. Пользовательский фронт #### 1.1. Онбординг и регистрация Зачем: точка входа, от неё зависит конверсия в первый депозит. Для Telegram-аудитории (RU/CIS) критично — быстрая регистрация в 1 клик. Что внутри: * Регистрация: email / телефон / Telegram Login * Верификация email + телефона (OTP) * Мульти-язык: RU + EN * Акцепт ToS / Privacy / Risk Disclosure — версия и timestamp фиксируются * Устройство и сессии: список активных устройств, force logout, device-fingerprint #### 1.2. KYC (три уровня + re-KYC) - сделать для СБП клиентов при пополнениях не с личного банк аккаунта Зачем: upstream-провайдер (Tevau / Interlace / Qbit / DiPocket) обязан провести KYC по своим лицензиям. Без KYC выдать карту невозможно. Уровни нужны, чтобы не отпугивать новичков на витрине, но при этом закрывать риск. Что внутри: * Провайдер: Sumsub / Veriff / Didit / Jumio — выбирается под требования конкретного upstream * Уровни: * Lite (email + телефон) — регистрация, просмотр тарифов, без карты * Basic (паспорт + селфи) — виртуальная карта, базовые лимиты * Enhanced (адрес + Source of Funds) — физическая карта, высокие лимиты, крупные пополнения * Статусы: pending / approved / rejected / review / expired * Re-KYC триггеры: истечение документа, смена гражданства/адреса, срабатывание риск-правил, превышение оборота уровня * API-прокидка KYC-результата в upstream — чтобы пользователь не проходил верификацию дважды * Хранение документов: зашифрованное S3 с access-log; retention согласно политике (обычно 5 лет после закрытия аккаунта) #### 1.3. Витрина тарифов и сравнение карт Зачем: главный инструмент конверсии. По аналогии с WantToPayBot (Prepaid/Easy/Smart/Pro), ПлатиПоМиру (3 tier), Nebeus (Core/Premium). Что внутри: * Сравнительная таблица по колонкам: цена выпуска, обслуживание, комиссия пополнения %, FX %, лимиты (транзакция / день / месяц), срок действия, Apple Pay / Google Pay, тип карты (виртуальная / физическая), BIN-страна - прописать все характеристики наших карт * Фильтры по цели: подписки (Netflix/Spotify), реклама (Facebook/Google Ads), путешествия (Booking/Airbnb), крупные покупки * Сторис из блога: «как оплатили X с нашей карты» #### 1.4. Личный кабинет Зачем: основной рабочий экран пользователя. Что внутри: * Дашборд: балансы (RUB / USD-по-карте), активные карты, 5 последних транзакций * Карты: список, детали (PAN / CVV / Exp показываются через iframe upstream + 3DS-подтверждение), заморозка / разморозка, блокировка, перевыпуск, лимиты (daily / monthly / per-tx / MCC) - в зависимости от функционала что мы можем дать * Транзакции: история, статусы (authorized / cleared / declined / refunded / disputed), фильтры по дате / MCC / сумме / merchant, экспорт CSV * Пополнения: история СБП → $ в кабинете (под капотом покупка USDT), курс (включает комиссию), статус * Профиль: KYC-уровень, загруженные документы, адрес, SOF, billing * Уведомления: email + Telegram + push — по транзакциям, пополнениям, логину, 3DS #### 1.5. Apple Pay / Google Pay — привязка Зачем: ключевая фича для RU-аудитории. Для upstream с token-provisioning (Tevau, DiPocket, Pyypl с оговорками) — работает; для US-BIN с ограничениями (PST.NET) — токенизация блокируется. Что внутри: * Кнопка «Add to Apple Wallet» / «Add to Google Wallet» с push-provisioning через upstream SDK * На витрине тарифов явно: «Apple Pay / Google Pay: да / частично / нет» — по каждому тарифу * В справке: пошаговая инструкция добавления, решение типичных проблем * Учёт ограничений Visa / Mastercard по странам и BIN — не каждая карта может токенизироваться в конкретной юрисдикции пользователя #### 1.6. Telegram-бот и Mini App Зачем: основной канал дистрибуции для RU/CIS (по аналогии с PyyplBot, MaxSwap, ПлатиПоМиру, FlowBit, Antarctic Wallet). Что внутри: * Авторизация через Telegram Login * Быстрые сценарии: баланс, выпуск карты, пополнение (QR СБП), 5 последних транзакций, заморозка, реферальная ссылка * Mini App для полного функционала (LK внутри Telegram) * Уведомления о транзакциях в реальном времени в чат бота * Встроенная поддержка (чат → оператор) * Deeplink на веб-LK #### 1.7. Контентные и legal-страницы Зачем: SEO-трафик (блог), доверие (FAQ, legal), конверсия (лендинги). Что внутри: * Блог: CMS (Ghost / Strapi / Next.js MDX) — гайды «как оплатить Netflix/GPT и пр. из РФ», кейсы, FAQ * FAQ / Help Center с поиском и AI-ассистентом (первая линия) * Сравнительная таблица карт (публичная, без логина) * Лендинги под каналы трафика (Telegram-трафик, реферал, партнёрка) * Legal: ToS, Privacy, Cookie, Risk Disclosure, Complaint Procedure, Refund Policy *** ### 2. Финансовый контур: СБП → USDT → upstream → карта #### 2.1. Приём СБП (депозит в RUB) Зачем: единственный массовый канал пополнения для RU-аудитории. Без него — нет продукта. Что внутри: * Модель юрлица: * вариант A: РФ-юрлицо-оператор + договор с платёжным агентом (есть у ПлатиПоМиру — ООО «КАПИБАРА»; у Citora — ООО «Ситора») * вариант B: работать через агрегатора с интеграцией СБП (CloudPayments / YooKassa / агрегатор с регистрацией BFM у ЦБ) * Генерация уникального QR / динамической ссылки на каждый депозит (по одному уникальному назначению платежа = пользователь) * Имя аккаунта должно совпадать с ФИО плательщика! Или изменено на статичное через поддержку. * Webhook от агрегатора: сверка плательщика (имя должно совпадать с KYC), суммы, назначения * Ограничения 115-ФЗ: лимиты на одного плательщика в сутки / месяц; автоблок на превышение; ручная проверка при срабатывании * Статусы депозита: initiated / paid / credited / failed / refunded #### 2.2. Лимиты 115-ФЗ на стороне СБП-агента Зачем: агент имеет свои лимиты от банка-партнёра и ЦБ. Если один плательщик превысит их — агент блокирует весь поток, и сервис остаётся без СБП. Что внутри: * Мониторинг лимитов: суточный / месячный / годовой по плательщику (ФИО + телефон) * Матчинг плательщик ↔ KYC-анкета — если не совпадает, блокировка депозита * Каскадирование: несколько СБП-агентов одновременно, переключение при приближении к лимиту * Алёрты для операционки при подходе к 80% лимита * Автоматическое предложение альтернативы пользователю (P2P USDT, карта) при отказе в СБП #### 2.3. Конвертация RUB → USDT Зачем: upstream-провайдер (Tevau / Interlace / Qbit) принимает USDT. Промежуточный шаг — обязательный. Что внутри: * Контрагент: OTC-desk, биржа через API (Bybit / OKX / HTX), P2P-поставщик * Курс: индикативный на витрине + финальный после исполнения (fixed-rate окно 3–5 минут) * Spread: 2–7% в зависимости от позиционирования. Это основной источник дохода сервиса — наравне с FX и fee за выпуск * Хеджирование: либо мгновенный свап сразу после прихода RUB, либо position limit + стоп-лосс на открытой позиции * Резерв: часть USDT держится как буфер на мгновенные пополнения (без ожидания исполнения OTC) * Хранение? #### 2.4. Пополнение USDT в upstream Зачем: чтобы у пользователя на карте были деньги. Что внутри: * USDT on-chain в депозитный адрес upstream: * Tevau: USDT \~1% комиссия * Interlace: через CryptoConnect on-ramp * Qbit: через CaaS API (USDT принимается) * DiPocket: fiat SWIFT (USDT не принимается напрямую — нужен дополнительный шаг: USDT → EUR через биржу) * Сети: TRC20 (дешевле), ERC20, BEP20 * Сверка: баланс на стороне upstream = сумма депозитов пользователей (reconciliation каждые N минут, см. §3.5) #### 2.5. Выпуск карты Что внутри: * API-вызов к upstream: create-card с параметрами (user\_id, KYC-ref, тариф, BIN-country) * * * Типы: * виртуальная — выпуск мгновенный * физическая — производство 5–45 дней, доставка курьером / почтой; тарификация доставки отдельно * Привязка PAN ↔ user\_id в БД сервиса * Хранение PAN: НЕ у сервиса, iframe от upstream (PCI-scope делегирован — дешёвый SAQ-A вместо полного PCI DSS Level 1) * Emboss-данные: имя на карте согласно KYC #### 2.6. Пополнение карты (после депозита) Что внутри: * Внутренний перевод USDT-баланса в баланс карты (через upstream API) * Комиссия сервиса: наценка поверх upstream (например, upstream берёт 1%, сервис показывает пользователю 3.5–5%) * Минимум / максимум — по тарифу (у MaxSwap $25, у Valut.net от $5, у PyyplBot от $10) * Отображение в LK: pending → credited, с показом курса и комиссии #### 2.7. FX и interchange Что внутри: * Для клиента наценка по картам +20%/+15%/+10% отображение на фронте * Сервис показывает пользователю списание в РУБ при пополнении * Upstream возвращает cleared-сумму в валюте счёта карты (USD / EUR / HKD) * FX-наценка: сверх upstream-ставки (Tevau 1.2% Visa / 2.5% Mastercard — вы добавляете сверху; типичный end-user FX — 3–7%) * Interchange от схем (Visa/Mastercard) частично возвращается upstream → может идти в cashback-программу или в маржу сервиса #### 2.8. Dispute flow — возвраты и чарджбеки Зачем: пользователи будут спорить — merchant не вернул, сервис недополучен, транзакция двойная. Без процесса теряешь репутацию и upstream начнёт жаловаться. Что внутри: * Форма подачи диспута в LK: тип (merchandise / duplicate / fraud / refund not posted), документы (скриншоты, переписка), сумма * Автоматическая прокидка в upstream (у Tevau, Interlace, DiPocket, Wallester есть dispute API) * Статусы: opened → merchant response → chargeback initiated → won / lost * SLA: первичный ответ пользователю в течении 48 часов, эскалация в upstream в течении 72 часа, итог — до 60 дней (стандарт Visa/Mastercard) * Сегментация: пользователь с high chargeback rate → повышенный риск-скор → возможный soft block * Интеграция в CRM поддержки: тикет = диспут, единый лог (ВАЖНО!) #### 2.9. Вывод и рефанд Что внутри: * Политика: можно указать, что депозиты non-refundable (как у многих retail-сервисов), или разрешить вывод остатка через поддержку * Если разрешено: USDT-адрес (комиссия сети + fee сервиса) или обратный СБП-перевод (с учётом 115-ФЗ — только тому же плательщику) (ВОПРОС?) * Минимум вывода: по экономике (USDT от $20, RUB — от 1000) * Лимиты в день / месяц, AML-скрининг адреса вывода (через Chainalysis / TRM — опционально, но рекомендовано, иначе upstream будет беспокоиться) *** ### 3. Бэкофис, анти-fraud, reconciliation #### 3.1. Admin panel Что внутри: * Пользователи: поиск, карточка, KYC-документы, статусы, заметки * Карты: активные / замороженные / заблокированные, принудительное управление * Транзакции: фильтры по user / amount / status / merchant / MCC; ручное помечение фрода * Депозиты СБП: сверка, ручное разрешение несовпадений плательщик ↔ KYC * Финансовый отчёт: P\&L по дням (spread + fee + FX за минусом upstream-расходов) * Роли: support / compliance / finance / admin — каждый видит своё #### 3.2. Партнёрская и реферальная программы Зачем: рефералка — топ-канал для Telegram-продукта. Партнёрка — для работы с тг-каналами и инфлюенсерами. Что внутри: * Реферал (user → user): уникальная ссылка в Telegram-боте и в LK; бонус — % от первых N пополнений реферала, или фикс за первый депозит от X$ * Партнёрка (B2B): отдельный кабинет для тг-каналов / инфлюенсеров / арбитражников; постбэки (S2S), метрики (клики / регистрации / депозиты / активные карты), периодические выплаты * Методы выплат: RUB на СБП / USDT on-chain * Tier-уровни партнёров: Starter / Pro / VIP с разной комиссией и условиями #### 3.3. Referral anti-abuse Зачем: любая программа с бонусами притягивает мультиаккаунтеров. Без защиты — утечка casha. Что внутри: * Device-fingerprint match: если реферер и реферал на одном устройстве → блок бонуса * IP / подсеть: совпадение — автоматический review * KYC match: один паспорт нельзя использовать в двух аккаунтах * Behavioral: реферал делает 1 минимальный депозит и больше никогда → бонус отзывается * Cooling period на выплату: бонус начисляется через 14–30 дней после активности реферала, не сразу * Лимит на 1 реферера: max N приглашённых в месяц (иначе фарм) * Ручная проверка топ-10% рефереров еженедельно #### 3.4. Anti-fraud rules (заменяет отсутствие собственного AML) Зачем: «AML не нужен» — значит, у вашего юрлица нет собственной AML-лицензии. Но upstream провайдер (Tevau / Interlace / Qbit / DiPocket) обязан по своим лицензиям вести AML — если на их стороне сработает, они заморозят всю программу. Поэтому базовые fraud/risk-правила на вашей стороне обязательны. Что внутри: * Velocity: N депозитов / N часов, N выпусков карт / N дней * Amount thresholds: депозит выше X → ручная проверка, SOF request * Мультиакк: совпадение device / IP / email-pattern / телефона * Chargeback rate: >1% → повышенный риск-скор, soft block на новые карты * Deny-list: email / телефон / device / IBAN — из жалоб и upstream blocklists * Watchlist от merchants: если Merchant X жалуется на сервис — ограничение транзакций туда * Sanctions-check минимум на ФИО и страну (даже без лицензии — формальная проверка, чтобы не оказаться крайним) * Правила хранятся в rules engine (GoRules / Camunda DMN / собственный) — чтобы менять без деплоя #### 3.5. Reconciliation-движок Зачем: без автосверки операционка сожрёт команду. В день 10K депозитов × 3 слоя (СБП / USDT / upstream) = 30K проверок. Ручной режим не работает. Что внутри: * Три слоя сверки: * Слой 1: депозит СБП-агента = баланс RUB в ledger сервиса (на компании) * Слой 2: RUB в ledger = купленный USDT на OTC (с учётом курса и spread) * Слой 3: USDT в treasury = баланс в upstream = баланс в LK пользователя * Frequency: в зависимости от активности пользователей * Разница допусков: порог "мин сумма" — в пределах комиссии сети и окна исполнения * Action при рассогласовании: автоматический тикет в operations с детализацией → ручная проверка * Daily close: фиксированный отчёт за сутки, подписанный finance * Audit log: неизменяемый журнал всех операций (append-only ledger) #### 3.6. Webhooks от upstream Зачем: upstream стучится на вашу сторону при каждом событии — auth / decline / settlement / 3DS challenge / card-status-change. Без обработки этих событий LK пользователя будет отставать от реальности. Что внутри: * Endpoint: публичный HTTPS с mTLS или signature (HMAC) от upstream * Очередь: NATS / RabbitMQ / SQS — с retry и DLQ * Идемпотентность: обработка по event\_id (upstream пришлёт то же событие 3–5 раз при ретраях) * Типы событий: * card.created / card.activated / card.frozen / card.blocked * transaction.auth / .declined / .cleared / .refunded / .reversed * dispute.created / .updated / .resolved * kyc.status\_changed * balance.updated * Мониторинг: время обработки, процент ошибок, DLQ-size — алёрты в PagerDuty / Grafana * Контракты: фиксированные схемы, версионирование — чтобы upstream-апдейт не ломал прод #### 3.7. Поддержка Что внутри: * Каналы: Telegram-чат (первичный для RU), in-app chat, email, FAQ-бот AI * CRM: Intercom / Crisp / helpdesk-инструмент; объединение всех каналов в одно окно * SLA: first response 5–15 минут (RU-аудитория ждёт быстрой поддержки) * Эскалация: L1 (общие вопросы) → L2 (compliance, depos, disputes) → L3 (инженеры, финансы) * База знаний с AI-first-line: бот отвечает на 60–70% простых вопросов, эскалирует остальное * Метрики: CSAT, FRT, AHT, % автоматизации #### 3.8. Device binding + 2FA Зачем: угон аккаунтов — main attack vector на B2C-финтех. Без device-binding злоумышленник с логином и паролем снимает все деньги. Что внутри: * 2FA обязательный: TOTP (Google Authenticator / Authy) + SMS (fallback) + Telegram login подтверждение (для tg-first) * Device binding: при первом входе — уникальный device-token; каждое новое устройство → email-confirmation + уведомление во все связанные каналы * Критичные операции (смена email, вывод, большой депозит) — всегда 2FA * Session TTL: 30 дней с возможностью «log out from all devices» * Anti-credential-stuffing: rate-limit по IP, CAPTCHA при подозрительных попытках * Breach monitoring: при утечке базы на стороне — форс-reset паролей затронутых пользователей #### 3.9. Soft block / cooling period для новых пользователей Зачем: первые 24–48 часов — пик мошеннических регистраций. Карта выпускается мгновенно, пополняется и уходит в обнал. Cooling period — стандартная мера. **- основной риск** Что внутри: * На новом аккаунте первые 48 часов: * максимальный депозит ограничен (например, $200 эквивалент) * выпуск карт — максимум 1 виртуальная * вывод / p2p запрещён * покупки в high-risk MCC — через 3DS-challenge * После прохождения KYC Enhanced cooling period снимается * Exception-лист: пришёл по партнёрскому каналу с хорошей репутацией — сокращённый cooling (12 часов) * Автоматическое снятие лимитов по поведению: нет чарджбеков за первые 7 дней + минимум 3 транзакции → лимиты расширяются *** ### 4. Treasury, кэшбэк, лояльность #### 4.1. Treasury (USDT-баланс сервиса как операционный) - утвердить Зачем: если все средства лежат только на upstream — сервис зависит от них в моменте. Нужен собственный operational USDT и резерв ликвидности. Что внутри: * Трёхуровневое хранение: * hot (2–5% оборота) — мгновенные пополнения upstream, операционные выплаты; hot-wallet с multisig 2-of-3 * warm (15–25%) — ежедневные пополнения, OTC-сделки; hardware-based multisig * cold (70%+) — долгосрочный резерв; hardware wallet в банковской ячейке / MPC-custody (Fireblocks / Copper) * Ликвидность-резерв: запас USDT на 3–7 дней среднего оборота для обеспечения всех выводов без задержки * Чистка активов от санкционных стейблкойнов? перемешка адресов? * Мониторинг: on-chain (Etherscan / Tronscan), внутренний dashboard (баланс по кошелькам, флоу, PnL хеджа) * Политика операций: whitelist адресов, двойная подпись на движения >X$, ежедневная сверка с ledger #### 4.2. Кэшбэк и программа лояльности - вопрос, можем ли мы делать подобный функционал? Зачем: отстройка от конкурентов и удержание. По аналогии с Nexo Card (без годовой платы + крипто-кэшбэк), Wirex (Cryptoback), Nebeus (2–3% при 50+ NBTK). Что внутри: * Варианты: * % от interchange на выбранные MCC (travel, groceries, subscription) * Cashback в USDT / внутренних баллах / нативном токене (если будет) * Tier-based: Basic 0%, Pro 1%, Premium 2–3% (как у Nebeus) * Экономика: interchange 1.5–2.5% (Visa/Mastercard) → часть на пользователя, часть остаётся * Анти-абуз: исключение MCC (ATM, money transfer, crypto purchases), лимиты на выплату в месяц * Формат выплаты: ежемесячно начисление $ на баланс * Geofencing: кэшбэк только на «разрешённые» категории (все что не запрещено Казино, крипто, онлифанс и сервисы поддержки вроде патриона), чтобы не спонсировать нарушение ToS * Не обязательно на MVP: можно добавить в 2-й волне, когда накопится база транзакций для расчёта #### 4.3. Multi-tenant / выделенный BIN-range в upstream Зачем: стандартная BIN-программа upstream — общая с десятками других клиентов. Если кто-то из соседей словит санкционный кейс или массовый фрод — блокируется весь BIN, включая вас. Что внутри: * Запрос к upstream: выделенный BIN-range или sub-program (Tevau / Interlace / Qbit предлагают на объёме от N карт / месяц) * Свой brand на карте (emboss, дизайн, pack) * Изоляция рисков: ваши чарджбеки и фрод-события не смешиваются с чужими * Часто связано с минимальным коммитментом (MOQ) и revenue-share моделью, вместо fixed per-card fee * Доп. плата за настройку (setup fee $10K–$100K в зависимости от upstream) *** ### 5. Безопасность и compliance #### 5.1. Техническая безопасность Что внутри: * 2FA (TOTP + SMS + Telegram) — §3.8 * Device-binding и session management — §3.8 * Rate-limiting на login, выпуск карт, депозиты, вывод * Secrets management: HashiCorp Vault / AWS Secrets Manager / GCP KMS * Шифрование на rest и in-transit: TLS 1.3, AES-256 для документов KYC * SDLC: code review, SAST, DAST, dependency scanning, pentest раз в 6–12 месяцев * PCI DSS: SAQ-A минимум (iframe от upstream; PAN не трогается сервисом) * Мониторинг: WAF / anti-DDoS (Cloudflare / Fastly), SIEM, intrusion detection #### 5.2. Статусная страница Зачем: B2C-финтех без status-page = потеря доверия при первом инциденте. Пользователи должны видеть, что сервис знает о проблеме и работает над ней. Что внутри: * Публичная страница status.yourservice.com * Компоненты: API, LK, Telegram-бот, депозиты СБП, выпуск карт, авторизация транзакций, поддержка * История инцидентов с retroactive post-mortem * Подписка на email / Telegram / RSS * Интеграция с мониторингом (Datadog / PagerDuty → status.io / statuspage.io / Better Stack) * Правила эскалации: инцидент P1 → статус «partial outage» в 5 минут, update каждые 30 минут #### 5.3. Юридический периметр Что внутри: * Юрлицо-оператор (внерегулируемая юрисдикция): HK Ltd / UAE Free Zone / BVI / Seychelles — как у FlowBit Finance, E.Pn, CinCin, Bitfree * РФ-юрлицо (LLC) для агентской работы с СБП и «информационных услуг» — модель Citora (ООО «Ситора») / ПлатиПоМиру (ООО «КАПИБАРА») * Договор между юрлицами: маршрутизация платежа, агентское вознаграждение * 152-ФЗ: согласие на обработку ПДн, локальная БД ПДн россиян (или прокси-слой) * Risk Disclosure: явное указание, что сервис работает через upstream-лицензию, сам не банк / EMI * Документы upstream-договора: MSA, DPA, AML-schedule, SLA — согласованы перед запуском #### 5.4. ToS и продуктовые ограничения Что внутри: * Запрещённые MCC (определяются upstream): gambling, adult, crypto-to-crypto exchanges, прямые AML-триггеры * Sanctioned countries: список из OFAC / EU / UK — автоматический блок * Лимиты оборота на уровне тарифа и соответствие программе upstream * Процедура закрытия аккаунта: 30 дней на вывод остатка, после — freeze * Процедура возврата средств при отказе в KYC * Complaint Procedure: как жаловаться, в какие сроки отвечаем, эскалация *** ### 6. Интеграции (минимальный стек на MVP) | Слой | Сервис | | --------------------------- | ------------------------------------------------------------------------------------------------------ | | KYC | Sumsub / Veriff / Didit / Jumio | | Upstream card issuer | Tevau (HK Visa Principal через Warba) / Interlace / Qbit Network / DiPocket / Wallester (как реселлер) | | OTC RUB↔USDT | OTC-партнёр / биржа через API (Bybit, OKX, HTX) | | СБП | платёжный агент в РФ | | Blockchain nodes | TronGrid, Infura, Alchemy (TRC20 / ERC20 / BEP20) | | Treasury / MPC custody | Fireblocks / Copper / BitGo (для warm-cold); hot — self-custody multisig | | Чат-поддержка | Intercom / Crisp | | Email | Postmark / SendGrid | | SMS | Twilio + РФ-локальный провайдер | | Push | OneSignal / Firebase FCM | | CMS (блог) | Ghost / Strapi / Next.js MDX | | Аналитика | PostHog + GA4 + Mixpanel | | Логи / APM | Datadog / Grafana + Loki + Tempo | | Error tracking | Sentry | | Webhooks broker | NATS / RabbitMQ / SQS | | Secrets | HashiCorp Vault / AWS Secrets Manager | | Status page | Better Stack / Statuspage.io / Instatus | | On-chain risk (опционально) | Chainalysis / TRM Labs / Elliptic | | Sanctions screening | ComplyAdvantage / Refinitiv World-Check | | Anti-fraud rules engine | GoRules / Camunda DMN / self-built | *** ### 7. Продуктовая аналитика — что измерять с 1-го дня Зачем: без аналитики невозможно понять, где отваливается воронка, какой канал трафика окупается, какой тариф самый маржинальный. Что внутри: * Воронка: landing → регистрация → KYC Lite → KYC Basic → первый депозит → выпуск карты → первая транзакция → повторная транзакция * Деньги: средний депозит, GMV (оборот по картам), take rate (spread + FX + ежемесячные fee), ARPU, gross margin * Удержание: D1 / D7 / D30 retention, MAU / WAU / DAU, churn по тарифам * Юнит-экономика: CAC по каналам (Telegram-bot, тг-каналы, блог, реферал, партнёрка), LTV, payback period, LTV/CAC * Техническая: success rate транзакций (>98% целевой), chargeback rate (<1%), время выпуска карты (виртуальная <2 мин), время KYC (Basic <10 мин), uptime >99.9% * Инструменты: PostHog (продуктовая воронка), Mixpanel (сегментация), GA4 (SEO-трафик), BI-слой на metabase / lightdash поверх DWH (ClickHouse / BigQuery) * Tracking-план: единая схема событий, version-controlled, обязательный review при добавлении события *** ### 8. Фазировка запуска (опционально, чтобы не путать MVP и mature-product) #### MVP (первые 3 месяца) * Фронт: веб-LK + Telegram-бот (без Mini App) * Тариф: 1 виртуальная карта (один тариф, fixed pricing) * KYC: 2 уровня (Lite + Basic) * Депозит: СБП + 1 OTC-контрагент, без каскада * Upstream: 1 провайдер (Tevau или Qbit) * Apple Pay / Google Pay: если upstream поддерживает сразу * Support: Telegram-чат + FAQ * Webhooks + reconciliation + anti-fraud rules engine — обязательно * Без: кэшбэк, партнёрка B2B (только рефералка), физические карты, multi-tenant BIN #### V1 (3–6 месяцев) * Tier-тарифы (3 уровня) * Физические карты * Mini App * Партнёрка B2B * Статусная страница * Enhanced KYC уровень * Второй upstream-провайдер (резерв) * Каскад СБП-агентов #### V2 (6–12 месяцев) * Кэшбэк и tier-лояльность * Выделенный BIN-range / sub-program в upstream * Мобильные приложения iOS / Android * API-доступ для B2B-клиентов * Собственный токен / баллы (опционально) * Расширение на SEPA / USD-пополнения для экспат-сегмента --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://alt3-capital.gitbook.io/funding-arbitrage-strategy/cart/dokumentaciya-v0/karta-funkcionala.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.