Ручные vs авто-выплаты

1) Понятийная рамка

Авто-выплаты — решения «пройти/отклонить/эскалировать» принимаются автоматически на основе правил и скоринга, отправка в коридор осуществляется без участия оператора.

Ручные выплаты — человеческая проверка (фин.оператор/риск-аналитик) подтверждает или отменяет заявку перед отправкой/после возврата.

2) Критерии выбора режима

Когда «авто» по умолчанию

Same-method & return-to-source соблюдены.
ND ≥ 0 (нет отрицательных нетто-депозитов).
KYC уровень ≥ L1, нет активных RG-блокировок.
Риск-скор < порога, нет гео-конфликтов (IP≈KYC≈SIM).
Сумма ≤ pre-approved порога для сегмента.
Метод/коридор — инстантный/надежный с низким возвратом.
Без свежих chargeback/abuse-сигналов.

Когда «ручной» по умолчанию

SoF/SoW требуется (порог/сигнал).
PEP/санк-фазы (fuzzy-хиты) или спорные документы.
GEO-конфликт, подозрение на multi-account/household.
Velocity/amount аномалии (много заявок, крупная сумма).
Вывод на новый реквизит без истории.
FX-арбитражные сценарии, нестандартные коридоры (SWIFT).
Любые исключения правил и возвраты с неясной причиной.

3) Плюсы/минусы

4) Архитектура гибридного конвейера

1. Pre-checks: same-method, ND, RG/KYC, санкции.
2. Risk-скоринг: payment/device/behavior/geo/fx признаки.
3. Децизионер: `AUTO_PASS / MANUAL_REVIEW / DENY`.
4. Очереди: ручная очередь с приоритетами SLA, авто-роутер в коридор.
5. Оркестрация: выбор коридора (instant → fast → standard) по cost/ETA/лимитам.
6. Treasury/FX: pre-funding, лимиты пулов, слippage-гварды.
7. Reconciliation: статусы, возвраты/реверсы, ре-роут/рефанд.
8. Observability: таймлайны, p95/p99, backlog, breach-алерты.

5) Политики (псевдо-DSL)

yaml policy: "payouts_auto_manual_v2"
eligibility:
same_method: true nd_min: 0 kyc_min: L1 routing:
cascade:
- corridor: "INSTANT" when: risk_score < 0. 5 and amount <= preapproved_limit
- corridor: "FAST_A2A" when: risk_score < 0. 65
- corridor: "STANDARD_SEPA" when: else manual_review:
triggers:
- risk_score >= 0. 65
- geo_conflict_score >= 2
- new_beneficiary == true and amount > new_beneficiary_cap
- sanctions_fuzzy_hit == true
- velocity_24h_payouts > 3 or amount_24h > segment_cap
- returns_last_30d >= 1 deny:
rules:
- self_excluded == true
- nd_total < 0 and allow_nd_withdrawal == false limits:
preapproved_limit:
LOW_RISK: {EUR: 2000}
MID_RISK: {EUR: 500}
sla:
auto_p95_minutes: 30 manual_p95_hours: 8 audit:
store_decision_tree: true store_feature_snapshot: true

6) Очереди и приоритеты ручной проверки

1. Старшие суммы с истекающими SLA.

2. Same-method & ND≥0 (быстрый релиз при подтверждении).

3. Мульти-тикеты одного игрока (снизить churn/обращения).

4. Instant-коридоры с деградацией сети (быстрый отбой или разрешение).

5. Остальное.

SLA управления очередью: целевой p95 решения `≤ 4–8 ч` (лицензия/рынок-зависимо).
Инструменты: авто-подсбор документов, checklists, макросы ответов, «Approve with note», «Partial release».

7) UX и коммуникации

Авто-ветка: показываем ETA и статусы («Инициировано», «Зачислено»).
Ручная ветка: честно сообщаем ожидаемое окно (пороговое) и что нужно (список документов/проверок).
Эскалации: уведомления при выходе за SLA, предложение изменить метод (если не нарушает same-method/ND).
История реквизитов: пометка «проверенный» получатель для будущих авто-выплат.

8) Модель данных

sql payout. timeline (
payout_id PK, user_id, amount_minor BIGINT, currency TEXT,
method TEXT, corridor TEXT, provider TEXT, iso2 TEXT,
nd_snapshot NUMERIC, same_method_ok BOOLEAN,
risk_score NUMERIC, decision TEXT, -- AUTO_PASS    MANUAL    DENY reason_codes TEXT[], reviewer TEXT,
t_request TIMESTAMP, t_precheck_ok TIMESTAMP, t_risk_ok TIMESTAMP,
t_decided TIMESTAMP, t_initiated TIMESTAMP, t_posted TIMESTAMP, t_available TIMESTAMP,
status TEXT, meta JSONB
);

review. queue (
ticket_id PK, payout_id FK, priority INT, state TEXT, assignee TEXT,
created_at TIMESTAMP, picked_at TIMESTAMP, resolved_at TIMESTAMP, sla_deadline TIMESTAMP
);

risk. features_snapshot (
payout_id FK, payload JSONB, created_at TIMESTAMP
);

9) SQL-шаблоны

9.1. Доля авто/ручных/отказов и их TTW

sql
SELECT decision,
COUNT() AS cnt,
100. 0 COUNT() / SUM(COUNT()) OVER () AS share_pct,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (COALESCE(t_available, t_decided) - t_request))) AS p95_sec
FROM payout. timeline
WHERE t_request BETWEEN:from AND:to
GROUP BY decision;

9.2. Backlog ручной очереди и просрочки SLA

sql
SELECT
COUNT() FILTER (WHERE state='OPEN') AS open_tickets,
COUNT() FILTER (WHERE sla_deadline < now() AND state IN ('OPEN','IN_PROGRESS')) AS sla_breaches
FROM review. queue;

9.3. Авто-выплаты — breach по коридорам

sql
SELECT corridor,
100. 0 COUNT() FILTER (WHERE EXTRACT(EPOCH FROM (t_available - t_request)) >:p95_target_sec) / NULLIF(COUNT(),0) AS breach_pct
FROM payout. timeline
WHERE decision='AUTO_PASS' AND status='SUCCESS'
AND t_request BETWEEN:from AND:to
GROUP BY 1 ORDER BY breach_pct DESC;

9.4. Конверсия «ручной → разрешено»

sql
SELECT
100. 0 COUNT() FILTER (WHERE status IN ('SUCCESS','INITIATED')) / NULLIF(COUNT(),0) AS manual_approve_rate
FROM payout. timeline
WHERE decision='MANUAL' AND t_decided BETWEEN:from AND:to;

10) Метрики и дашборды

Auto-rate %: доля выплат в авто-ветке.
Manual approve % / deny %, manual p95 TAT (время решения).
TTW p95/p99 по decision/corridor/provider/geo.
SLA-breach % (авто и ручных).
Returns/Reverse % и доля повторных выплат после возврата.
Cost per payout по веткам и коридорам.
ND<0 share среди заявок.
Queue health: open, in-progress, breaches, среднее ожидание.
Complaint/1k payouts и CSAT vs режим.

11) Алерты

Manual backlog spike: `open_tickets` > порога или `manual p95 TAT` > SLA.
Auto p95 breach на коридоре/провайдере.
Returns surge по коду/банку/гео.
ND negative spike в заявках.
Policy drift: выплаты без зафиксированного решения/фич-снапшота.
New beneficiary risk: высокая доля ручных по новым получателям.

12) Плейбуки инцидентов

A. Всплеск ручных (тормозит TTW)

1. Включить pre-approval для low-risk сегментов до X суммы.
2. Увеличить capacity ревью (лонг-day, перекинуть смену).
3. Временно поднять порог risk_score для MANUAL в безопасных GEO/методах.

B. Деградация авто-коридора (p95↑/returns↑)

1. Каскад на альтернативный коридор, снизить лимит per-txn.
2. Обновить ETA пользователям, тикет PSP/банк.
3. Пост-мортем: скорректировать роутинг-веса.

C. Возвраты волной по новому реквизиту

1. Авто-блок «новых» получателей до ручного подтверждения.
2. Предложить игроку сохраненный проверенный реквизит/источник.
3. Авто-refund в игровой кошелек и CTA «выбрать метод».

13) Экономика и компромиссы

Авто удешевляет операционку и повышает CSAT/retention, но требует инвестиций в скоринг/правила/телеметрию.
Ручные дороже, но снижают редкие крупные убытки и важны для регуляторной защиты.
Ищем точку баланса: максимально авто для низкорисковых сегментов и мгновенных коридоров; ручные — для edge-кейсов.

14) A/B-тесты

Пороги `risk_score`, лимиты pre-approval, приоритет коридоров в каскаде.
Копирайт и ETA для ручной ветки.
Guardrails: Returns %, CBR bps, manual p95 TAT, CSAT, Complaints/1k.

15) Best practices (коротко)

1. Default-auto для ND≥0, same-method, KYC L1+, низких сумм и проверенных реквизитов.
2. Policy-as-code + логирование фич/решений, воспроизводимость.
3. Каскад коридоров по cost/ETA/здоровью, авто-failover.
4. Очереди с приоритетом SLA и чек-листы для оператора.
5. Прозрачные ETA и статусы для обеих веток.
6. Pre-funding/лимиты пулов, FX-гварды.
7. Метрики p95/p99 и алерты по хвостам/возвратам/backlog.
8. Пост-инциденты и регулярный тюнинг скоринга/правил.

16) Чек-лист внедрения

• Матрица триггеров AUTO/MANUAL/DENY и versioning.
• Скоринг и «pre-approval» лимиты по сегментам.
• Same-method/ND/KYC/RG/санкции в pre-checks.
• Очереди и приоритеты, SLA и роли.
• Каскады коридоров и health-фид, failover.
• Модель данных и таймлайны, снапшоты фич/решений.
• Дашборды и алерты по TTW/SLA/returns/backlog.
• Плейбуки: деградация, волна возвратов, рост ручных.
• A/B и дата-фриз с лагом на возвраты/CB.
• Регулярные аудиты соответствия лицензиям/политикам.

Резюме

«Ручные vs авто-выплаты» — не выбор «или-или», а стратифицированная система: авто — для предсказуемых безопасных сценариев с сильной телеметрией; ручные — для узких, рискованных и регуляторно чувствительных кейсов. Формализуйте правила как код, измеряйте p95/p99 и backlog, держите каскады коридоров и прозрачные ETA — и вы получите быстрые, надежные и экономически устойчивые выплаты.