# Критика PRD v1 (с позиции бизнеса)

**Дата:** 2026-05-16
**Автор:** AI assistant (играет роль скептичного бизнес-партнёра)
**Что критикуется:** `docs/affiliate-prd-v1.md`

---

## A. Критика бизнес-модели (top priority)

### A1. ⚠ Profit-based ставка как default — плохо для партнёра

**Проблема:** в PRD v1 базовая модель = **30% от profit_usdt**. Партнёр не видит и не понимает заранее, сколько получит, потому что `profit_usdt = (indicative_rate − applied_rate) × ...` — это **наша внутренняя кухня**. На одной и той же сделке $1000 → партнёр может получить $9 (markup 3%) или $1 (markup 0.3%). У партнёра ощущение «крутят циферки» под него.

Из research: индустрия делает revenue share **от торговой комиссии** — а у нас комиссия = наш markup, и для P2P/OTC лучше платить **от объёма** (как BestChange, ChangeNOW, SimpleSwap), потому что объём прозрачен. Бирже не страшно отдать % от fee, потому что fee известна заранее.

**Решение для v2:**
- Default-модель = **% от volume в USDT эквиваленте**, ставка ~0.3% от оборота (примерно эквивалент 30% от типичного 1% markup'а)
- Опция «profit-based 30%» — для **VIP-партнёров с подписанным контрактом**, где partner понимает риски
- В UI кабинета партнёр видит «ваша ставка: 0.3% с каждого USDT оборота приведённых клиентов» — кристально понятно

### A2. ⚠ Lifetime-привязка — обязательство навечно

**Проблема:** в PRD v1 — lifetime после первой сделки клиента. Это значит, что если партнёр привёл клиента в 2026, а клиент сам по себе торгует у нас 5 лет — мы платим партнёру все 5 лет. Партнёр давно не сделал ничего для нас, но получает комиссию.

Forex IB-индустрия (зрелее криптовалютной) активно ограничивает: Coinbase = 3 месяца активности, многие брокеры = downgrade при отсутствии новых рефералов.

**Решение для v2:**
- Default attribution = **24 месяца** с момента первой сделки клиента (после — клиент «отвязывается», т.е. новые сделки уже не дают комиссию)
- Опция «lifetime» — для VIP-партнёров (с обоснованием, например, эксклюзивный канал)
- При установлении ставки в программе ясно показывать: «24 месяца с первой сделки»

### A3. ⚠ Cap 200 USDT на одну сделку — мешает крупным сделкам

**Проблема:** туристический бизнес — это иногда большие транзакции. Сделка $100k с маржой 1% = $1000 profit, партнёру 30% = $300. **Cap 200 USDT режет $100 — партнёр демотивирован приводить «жирных» клиентов.**

**Решение для v2:**
- Убрать абсолютный cap
- Добавить **относительный**: комиссия не больше 50% от profit на этой сделке (защита от случая когда мы продали себе в минус, а партнёру всё равно платим)
- Для volume-based — дополнительный sanity check: комиссия ≤ 1% от volume (даже если ставка случайно выставлена 5%, не платим больше 1%)

### A4. ⚠ Минимум $5 profit на сделку — отрезает мелких туристов

**Проблема:** турист меняет $50, profit $1–2. PRD v1 говорит «не начислять, если меньше $5» — но это **именно те сделки**, которые приводят локальные блогеры в Анталье. Если отрезаем — теряем мотивацию у блогеров вести трафик «средних людей».

**Решение для v2:**
- Убрать минимум на сделку
- Минимум только на **payout** (50 USDT = ~100 сделок × $1 комиссия)
- Это не пишет copies-комиссий «по копейкам» — мы и так храним per-deal, БД не страдает

### A5. ⚠ Self-referral блокировка слабая

**Проблема:** v1 проверяет совпадение `tg_username` и `phone`. Любой крипто-партнёр держит 3+ TG-аккаунта и Spare-симку. **Лже-нулевой барьер.**

**Решение для v2:**
- У нас уже есть KYC клиента (passport_id для крипты ≥ $425 по MASAK). Использовать **совпадение passport-id** как primary check
- Дополнительно: при регистрации партнёра — обязательно паспорт + селфи (для MVP можно отложить до первой выплаты)
- Self-referral по passport-match → автоматический `voided` + alert админу

---

## B. Юридический / compliance

### B1. ⚠ CMB лицензия — недо-оценил риск

**Проблема:** в PRD v1 я написал «не для MVP, через 6–12 месяцев». Но публичная **партнёрская программа с маркетингом на турецком языке** — это **прямое продвижение крипто-услуг в Турции**. Binance именно из-за этого закрыл retail referral в Турции в октябре 2024. Уголовка 3–5 лет за нелицензированный CASP.

**Решение для v2:**
- **MVP запуск только с не-турецкими партнёрами** (русско/англо/немецкоязычные TG-каналы)
- Партнёрам из Турции — пока не предлагаем программу
- Турецким клиентам пока приходят через прямой маркетинг (без партнёрских ссылок)
- **До получения CMB-статуса (или ясности с регулятором) не делать публичную страницу «Стать партнёром» на турецком**
- В PRD это должно быть выделено как **блокирующее ограничение**, не «нюанс»

### B2. ⚠ Withholding tax 1% — нет процедуры

**Проблема:** с 2025 Турция требует удерживать 1% с платежей intermediary-провайдерам. Это означает: при выплате 100 USDT партнёру резиденту TR мы должны **удержать 1 USDT и передать в налоговую**. PRD v1 говорит «обозначить в договоре» — но нет реализации.

**Решение для v2:**
- Поле `affiliates.is_tr_tax_resident BOOLEAN`
- При выплате если TR-resident: фактически переводим (amount − 1%)
- В UI партнёра: «к выплате 100 USDT, к вашей получке 99 USDT (1% удержание по TR-закону)»
- Раз в месяц — отчёт для бухгалтерии: сумма удержанных таксов

### B3. ⚠ Запрещённые юрисдикции для рефералов

**Проблема:** в v1 я задал вопрос «пускаем партнёров из РФ/Беларуси/Ирана?» но не ответил.

**Решение для v2:**
- Партнёры — только из не-санкционных стран (стандарт FATF/OFAC)
- Рефералы (клиенты) тоже — проверка страны KYC
- **RU/BY** — пока **не блокируем** (это значительная часть нашего клиентского рынка в Анталье), но мониторим санкции
- При выплате партнёру: страна payout-кошелька не должна быть в списке OFAC

---

## C. Технические

### C1. ⚠ Accrual в той же транзакции — риск каскадного падения

**Проблема:** PRD v1: «accrue в той же транзакции что и Deal → done». Если код accrue падает → откатывается сделка. Мы рискуем потерять реальные сделки из-за бага в новом модуле.

**Решение для v2:**
- Accrue **после** commit сделки (post-commit hook или event)
- Если accrue упал — пишется в `audit_log` ошибка, сделка остаётся как есть
- Cron-job каждые 15 минут пытается переначислить не-обработанные сделки (`Deal.commission_calculated_at IS NULL AND deal.status='done'`)
- Это **eventual consistency**, для аффилиатных комиссий — приемлемо

### C2. ⚠ Hold-cron каждый час — overkill

**Проблема:** 150 сделок/мес = 5 в день. Hold-cron каждый час делает SELECT по нескольким строкам и обновляет 0–1 запись. Это бесполезный шум в логах и небольшой DB load.

**Решение для v2:**
- Hold-cron **раз в сутки** в 04:00 UTC (после bgblock-sync и backup)
- Если партнёр запрашивает payout раньше hold-окна (например, через 6 дней вместо 7) — UI говорит «доступно через 18 часов»

### C3. ⚠ `payout_op_id` — admin выбирает Operation, но где её взять?

**Проблема:** в нашей системе `Operation` создаётся **только из Deal**. Payout — это не Deal, это вывод нашим партнёрам. PRD v1 не описал, как admin создаёт эту Operation.

**Решение для v2:**
- Новый `op_type='payout'` (или вернее — добавить kind, чтобы не конфликтовать с `crypto_out` от Deal)
- При approve payout admin вводит TX-hash реальной USDT-TRC20 транзакции, система создаёт Operation с `source='payout'`, привязывает к `payout_request`
- `reconcile.py` потом найдёт эту on-chain tx и свяжет

### C4. ⚠ TRC20 network fee — кто платит?

**Проблема:** транзакция USDT-TRC20 стоит ~1.5 USDT (TRX-fee + bandwidth). При выплате 50 USDT — это 3% нашей комиссии. PRD v1 умолчал.

**Решение для v2:**
- Опция в программе: `payout_fee_borne_by` = `affiliate` | `house`
- Default = `affiliate` (партнёр получает amount − network fee)
- В UI кабинета: «50.00 USDT − 1.50 USDT (network fee) = 48.50 USDT»
- Прозрачно, защищает нашу экономику

### C5. ⚠ Маркетинговые материалы — не реализовано в скоупе

**Проблема:** PRD v1 в одном из разделов упомянул «баннеры на 3 языках» как фичу партнёрского кабинета. **Кто их рисует?** Bybit и BestChange предоставляют — но они большие. У нас нет дизайнера в скоупе.

**Решение для v2:**
- **На MVP — никаких материалов не предоставляем**
- Партнёрский кабинет показывает только: ref-ссылку, QR-код (auto-gen), краткий «pitch» текст в README на 3 языках
- Партнёр сам делает свои креативы (это норма для small partner-программ)

---

## D. Что упущено в v1

### D1. Refund / reverse scenarios

**Проблема:** в PRD сказано «cancel deal → reverse entry». Но **что если комиссия уже paid?** Баланс уйдёт в минус.

**Решение для v2 (политика):**
- Минусовой баланс **списывается** с будущих available-комиссий партнёра (как chargeback)
- Если партнёр больше не активен → списываем убыток (но логируем для последующего возврата при возобновлении)
- Минимизируем риск: hold 7 дней покрывает большинство возвратов (cancel в первый день не редкость, но через 7 дней — крайне редко)

### D2. Tax-report для бухгалтерии

**Проблема:** не сделал export commission по партнёру за период для бухгалтерии (потребуется для турецкой налоговой отчётности).

**Решение для v2:**
- Страница `/payouts/tax-report?from=Y-M-D&to=Y-M-D` → CSV: партнёр, tax-id, сумма выплат, удержанный withholding tax
- Раз в месяц для бухгалтерии

### D3. Performance review партнёров (downgrade)

**Проблема:** tier-bonuses (Bronze/Silver/Gold) описал, но не сказал как ПЕРЕСМАТРИВАТЬ.

**Решение для v2:**
- В фазе 2 — cron-job ежемесячно (1-го числа) переоценивает партнёров по объёму прошлого месяца
- Upgrade — мгновенно
- Downgrade — с **2-месячным protection period** (как Binance) для предотвращения шоков
- Партнёр в кабинете видит «вы стали Silver! Ваша ставка 35%»

### D4. Что если клиент хочет отвязаться от партнёра?

**Проблема:** PRD не учитывает opt-out. Клиент узнал что менеджер платит блогеру и хочет это прекратить (например, лично с блогером отношения испортились).

**Решение для v2:**
- В карточке клиента (видна admin/manager) — кнопка «отвязать от партнёра» с reason
- Старые комиссии остаются (snapshot), новые сделки — без партнёра
- Логируется в audit
- Не разглашаем партнёру причину

### D5. KPI слишком оптимистичные

**Проблема:** «20% новых клиентов через 6 месяцев» — у нас сейчас ~150 сделок/мес от прямых, +30 от партнёров за 6 месяцев — это малореально для начала. Реалистично 5–15% в первый год.

**Решение для v2:**
- KPI 3 мес: 5–8% сделок от партнёров
- KPI 6 мес: 10–15%
- KPI 12 мес: 20%

### D6. Нет финансовой модели

**Проблема:** PRD не показывает «сколько мы потратим / сколько заработаем».

**Решение для v2:**
- Простой расчёт через 6 месяцев:
  - **Сценарий A (консервативный):** 5 партнёров × 5 клиентов × 3 сделки × $30 profit = $2250 → партнёрам $675 (30%) → нам **+$1575**
  - **Сценарий B (целевой):** 15 партнёров × 8 клиентов × 4 сделки × $40 profit = $19200 → партнёрам $5760 → нам **+$13440**
  - **Сценарий C (стресс):** партнёры приводят клиентов которые мы и так бы получили → ROI близкий к 0, но партнёрский рост = долгосрочный канал

---

## E. Стилистические / структурные

### E1. PRD слишком длинный (16 разделов)

Для бизнеса полезно сократить до 8–10 разделов с executive summary и техническими деталями в приложении.

### E2. Слишком много открытых вопросов (10 штук)

В v2 нужно явно дать **дефолтные ответы** на каждый вопрос — пусть пользователь корректирует, а не выбирает с нуля.

### E3. Нет ROADMAP-таблицы со сроками

Нужна сводная: что-кто-когда. Без неё трудно планировать.

---

## F. Итог: что критично исправить в v2

| Категория | Изменение |
|---|---|
| **Модель** | Default = % от volume (0.3%), profit-based как опция для VIP |
| **Attribution** | 24 месяца default, lifetime — опция |
| **Cap** | Убрать абсолютный, использовать относительный (≤50% profit / ≤1% volume) |
| **Min на сделку** | Убрать вообще, только min на payout |
| **Self-referral** | По passport-id из KYC |
| **CMB compliance** | Только не-турецкие партнёры на MVP, явный блок |
| **Withholding tax** | Реализовать удержание для TR-residents |
| **Accrual** | Post-commit, eventual consistency |
| **Hold-cron** | Daily, не hourly |
| **Payout Operation** | Новый источник `source='payout'`, не от Deal |
| **TRC20 fee** | Удерживаем с партнёра |
| **Marketing materials** | Не предоставляем на MVP |
| **Refund** | Минус-баланс → списываем с available, если нет — терпим |
| **Tax report** | Добавить export для бухгалтерии |
| **Tier downgrade** | Protection period 2 мес |
| **Opt-out клиента** | Кнопка в карточке для admin/manager |
| **KPI** | Реалистичнее (5–8% на 3 мес, 10–15% на 6 мес) |
| **Финмодель** | Добавить 3 сценария расчёта |
| **Open questions** | Дать дефолтные ответы |

---

**Следующий шаг:** PRD v2 с применением этих исправлений.