Manual vs auto-pago

1) Marco conceptual

Auto-pagos - las decisiones de «pasar/rechazar/escalar» se toman automáticamente en función de las reglas y la puntuación, el envío al corredor se realiza sin la participación del operador.

Pagos manuales - verificación humana (fin. operador/analista de riesgo) confirma o cancela la solicitud antes del envío/después de la devolución.

2) Criterios de selección de modo

Cuando «auto» predeterminado

Same-method & return-to-source se cumplen.
ND ≥ 0 (no hay depósitos netos negativos).
Nivel KYC ≥ L1, no hay bloqueos RG activos.
Riesgo-score <umbral, sin geo-conflictos (IP≈KYC≈SIM).
Suma ≤ umbral preapproved para el segmento.
Método/corredor - Instant/fiable con bajo retorno.
Sin señales frescas de chargeback/abuse.

Cuando «manual» es predeterminado

Se requiere SoF/SoW (umbral/señal).
RER/fases de sank (fuzzy-hits) o documentos controvertidos.
Conflicto GEO, sospecha de múltiples cuentas/household.
Velocity/amount anomalías (muchas solicitudes, gran cantidad).
Una conclusión a un nuevo detalle sin historia.
Escenarios de arbitraje FX, corredores no estándar (SWIFT).
Cualquier excepción a las reglas y devoluciones con una razón poco clara.

3) Pros/contras

4) Arquitectura de transportador híbrido

1. Pre-cheques: same-method, ND, RG/KYC, sanciones.
2. Risk-scoring: payment/device/behavior/geo/fx signos.
3. Decisioner: 'AUTO _ PASS/ MANUAL_REVIEW/DENY'.
4. Colas: cola manual con prioridades SLA, enrutador automático en el pasillo.
5. Orquestación: selección del corredor (instant → fast → standard) por costo/ETA/límites.
6. Treasury/FX: pre-funding, límites de pools, slippage-guardianes.
7. Reconciliation: estados, devoluciones/reversos, re-root/refand.
8. Observabilidad: timelines, p95/p99, backlog, breach-alert.

5) Políticas (pseudo-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) Colas y prioridades de verificación manual

1. Sumas mayores con SLA caducadas.

2. Same-method & ND≥0 (lanzamiento rápido cuando se confirma).

3. Multi-tickets de un solo jugador (reducir churn/recursos).

4. Corredores instantáneos con degradación de la red (recuperación rápida o resolución).

5. El resto.

Gestión de colas SLA: solución p95 objetivo '≤ 4-8 h' (licencia/mercado-dependiente).
Herramientas: auto-subensamblaje de documentos, checklists, macros de respuesta, «Approve with note», «Partial release».

7) UX y comunicaciones

Auto-rama: mostramos ETA y los estados («Iniciado», «Acreditado»).
Rama manual: informamos honestamente la ventana esperada (umbral) y lo que se necesita (lista de documentos/comprobaciones).
Escalaciones: notificaciones al salir de SLA, sugerencia para cambiar el método (a menos que viole same-method/ND).
Historial de datos: etiquetado como destinatario «verificado» para futuros pagos automáticos.

8) Modelo de datos

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) Plantillas SQL

9. 1. Proporción de auto/manual/fallas y su 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 de cola manual y retraso de 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. Auto-pagos - breach por los pasillos

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. Conversión de «→ manual permitido»

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) Métricas y dashboards

Auto-rate%: porcentaje de pagos en auto-rama.
Manual approve %/deny%, manual p95 TAT (tiempo de solución).
TTW p95/p99 по decision/corridor/provider/geo.
SLA-breach% (auto y manual).
Returns/Reverse% y parte de los pagos repetidos después de la devolución.
Costo por pago por ramas y pasillos.
ND <0 compartir entre las solicitudes.
Queue health: abierto, en progreso, breaches, espera media.
Complaint/1k payouts y CSAT vs modo.

11) Alertas

Manual backlog spike: 'open _ tickets'> umbral o 'manual p95 TAT'> SLA.
Auto p95 breach en el corredor/proveedor.
Returns surge por código/banco/geo.
ND negative spike en las solicitudes.
Policy drift: pagos sin solución fija/snapshot.
New beneficiary risk: una alta proporción de manual según los nuevos destinatarios.

12) Playbucks de incidentes

A. Ráfaga manual (frena TTW)

1. Habilitar pre-approval para segmentos de bajo riesgo hasta X suma.
2. Aumentar la capacidad con rugido (long-day, extender el turno).
3. Elevar temporalmente el umbral de risk_score para MANUAL en métodos GEO/seguros.

B. Degradación del corredor automático (p95↑/returns↑)

1. Cascada a un corredor alternativo, reducir el límite per-txn.
2. Actualizar ETA a los usuarios, ticket PSP/banco.
3. Post mortem: ajustar los pesos routing.

C. Devoluciones por onda de nuevo requerimiento

1. Auto-bloque de «nuevos» destinatarios antes de la confirmación manual.
2. Ofrecer al jugador un accesorio/fuente probada guardada.
3. Auto-refund en la billetera del juego y CTA «elige el método».

13) La economía y los compromisos

Auto es más barato de operar y aumenta CSAT/retention, pero requiere inversión en puntuación/reglas/telemetría.
Los manuales son más caros, pero reducen las raras pérdidas importantes y son importantes para la protección regulatoria.
Buscamos un punto de equilibrio: máximo auto para segmentos de bajo riesgo y corredores instantáneos; manual - para casos edge.

14) Pruebas A/B

Umbrales 'risk _ score', límites pre-approval, prioridad de corredores en cascada.
Copyright y ETA para la rama manual.
Guardrails: Returns %, CBR bps, manual p95 TAT, CSAT, Complaints/1k.

15) Mejores prácticas (corto)

1. Default-auto para ND≥0, same-method, KYC L1 +, cantidades bajas y datos verificados.
2. Policy-as-code + lógica fich/solutions, reproducibilidad.
3. Cascada de corredores por costa/ETA/salud, auto-failover.
4. Colas con prioridad SLA y listas de comprobación para el operador.
5. ETA transparente y estados para ambas ramas.
6. Pre-funding/pools limites, FX-guardianes.
7. Métricas p95/p99 y alertas por cola/devoluciones/retroceso.
8. Incidentes posteriores y ajuste regular de la puntuación/reglas.

16) Lista de verificación de implementación

• Matriz de disparadores AUTO/MANUAL/DENY y versioning.
• Scoring y «pre-approval» límites por segmentos.
• Same-method/ND/KYC/RG/sanciones en pre-cheques.
• Colas y prioridades, SLA y roles.
• Cascadas de pasillos y feed de salud, failover.
• Modelo de datos y líneas de tiempo, snapshots fich/soluciones.
• Dashboards y alertas por TTW/SLA/returns/backlog.
• Playbucks: degradación, ola de devoluciones, crecimiento manual.
• A/B y friso de datos con un plazo de devolución/SV.
• Auditorías periódicas de cumplimiento de licencias/políticas.

Resumen

El «manual vs auto-payments» no es una opción «o-o», sino un sistema estratificado: auto - para escenarios seguros predecibles con una fuerte telemetría; manual - para casos estrechos, arriesgados y regulativamente sensibles. Formalice las reglas como código, mida p95/p99 y backklog, mantenga cascadas de pasillos y ETA transparentes - y obtendrá pagos rápidos, confiables y económicamente sostenibles.