Ручні vs авто-виплати

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

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

Ручні виплати - людська перевірка (фін. оператор/ризик-аналітик) підтверджує або скасовує заявку перед відправленням/після повернення.

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

2) Критерії вибору режиму

Коли «авто» за замовчуванням

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

Коли «ручний» за замовчуванням

SoF/SoW потрібно (поріг/сигнал).
РЕР/санк-фази (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 і дата-фриз з лагом на повернення/СВ.
• Регулярні аудити відповідності ліцензіям/політикам.

Резюме

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