GH GambleHub

Pagamenti manuali vs auto

1) Cornice comprensibile

Pagamenti auto - Le decisioni «passare/rifiutare/scalare» vengono prese automaticamente sulla base delle regole e scorciatoie, e l'invio al corridoio avviene senza la partecipazione dell'operatore.

I pagamenti manuali sono un controllo umano. operatore/risk analyst) conferma o annulla la richiesta prima dell'invio/dopo il rimborso.

💡 Obiettivo: massimizzare la quota di rimborsi automatici mantenendo il rischio accettabile e rispettando i requisiti regolatori. Il ramo manuale è la rete di assicurazione, non il default.

2) Criteri di selezione della modalità

Quando «auto» predefinita

Same-method & return-to-source sono stati rispettati.
ND 0 (nessun deposito netto negativo).
Livello KYC ≥ L1, nessun blocco RG attivo.
Rischio-scansione <soglia, nessun conflitto geo (IP≈KYC≈SIM).
Somma della soglia pre-approved per il segmento.
Metodo/corridoio - istantaneo/affidabile a basso ritorno.
Senza i nuovi proveback/abuse-segnali.

Quando predefinito manuale

SoF/SoW richiesto (soglia/segnale).
RER/slitta-fasi (fuzzy-heat) o documenti controversi.
Conflitto GEO, sospetto multi-account/household.
Velocity/amount anomalie (un sacco di richieste, una grossa somma).
Porta a un nuovo oggetto senza storia.
Script di arbitraggio FX, corridoi non standard (SWIFT).
Tutte le eccezioni di regole e restituzioni non sono chiare.

3) Pro/contro

CriteriPagamenti autoPagamenti manuali
TTW/SLAminimi, p95 in minutidipende dalla coda (orologio)
CostoNOCE/operatori sottoOPEX superiore; rischio minore
Rischiodipende dalla qualità delle regole/screeningMeglio con le valigette edge
Scalascalabili facilmenteristretto - persone
UX/CSATelevata (immediata)sotto (attesa/ticket)
Compilazionerichiede un controllo rigorosomigliore per casi opachi

4) Architettura della catena ibrida di montaggio

1. Pre-checks: same-method, ND, RG/KYC, sanzioni.
2. Risk-screening: payment/device/behavior/geo/fx segni.
3. Decisionatore: 'AUTO _ PASS/MANUAL _ REVIEW/DENY'.
4. Code: coda manuale con priorità SLA, router auto in corridoio.
5. Orchestrazione: selezione del corridoio (instant n'fast standard) per cost/ETA/limiti.
6. Treasury/FX: pre-funding, limiti dei pool, slippage-guarda.
7. Recordation - States, restituzioni/reverse, re-root/refand.
8. Osservabilità: timeline, p95/p99, backlog, breach-alert.

5) Criteri (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) Code e priorità di controllo manuale

Priorità (da maggiore a minore):

1. Importi senior in scadenza SLA.

2. Same-method & ND≥0 (rilascio rapido quando confermato).

3. Multi-ticket di un giocatore (riduzione churn/conversione).

4. Corridoi istanti con degrado di rete (disconnessione rapida o risoluzione).

5. Il resto.

SLA gestione code: soluzione target p95 «4-8 ore» (licenza/mercato-dipendente).
Strumenti: sottoassieme automatico dei documenti, checklists, macro risposte, Approve with note, Partial release.

7) UX e comunicazioni

Ramo auto - Mostra gli stati e gli stati ETA (Inizializzato, Iscritto).
Il ramo manuale indica onestamente la finestra prevista (soglia) e ciò che è necessario (elenco documenti/controlli).
Escalation: notifiche quando esci dalla SLA, suggerimento di modificare il metodo (a meno che non violi same-method/ND).
Cronologia delle informazioni: contrassegna il destinatario collaudato per i futuri pagamenti automatici.

8) Modello di dati

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

9. 1. Quota di auto/manuali/guasti e loro 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 coda manuale e ritardo 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. Pagamento auto - breach nei corridoi

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. La conversione «manuale» è consentita

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) Metriche e dashboard

Auto-rate%: percentuale di pagamento nel ramo auto.
Manuale approve %/deny%, manuale p95 TAT (tempo di soluzione).
TTW p95/p99 по decision/corridor/provider/geo.
SLA-breach% (auto e manuale).
Returns/Reverse% e la percentuale di rimborsi dopo il rimborso.
Cost per payout su rami e corridoi.
ND <0 share tra le richieste.
Queue health: open, in-progress, breaches, attesa media.
Modalità Complaint/1k payouts e CSAT vs.

11) Alerte

Manual backlog spike: 'open _ tickets'> soglia o 'manual p95 TAT'> SLA.
Auto p95 breach sul corridoio/provider.
Returns surge per codice/barattolo/geo.
ND negative spike nelle richieste.
Policy draft - pagamenti senza soluzione/fich-snashot fissata.
Nuovo beneficenza risk: alta percentuale di nuovi destinatari manuali.

12) Playbook incidenti

A. Slancio manuale (frena TTW)

1. Abilita pre-approval per i segmenti low-risk fino a X importo.
2. Aumenta la capacity con la ruspa (long-day, sovrascrivere il cambio).
3. Alza temporaneamente la soglia risk _ score per MANUAL con metodi/metodi GEO sicuri.

B. Degrado del corridoio auto (p95↑/returns↑)

1. Cascata per corridoio alternativo, abbassare il limite per-txn.
2. Aggiorna l'ETA agli utenti, ticket PSP/banca.
3. Post mortem: aggiustare il peso del routing.

C. Restituzioni da onda con nuova identità

1. Unità auto «nuovi» destinatari prima della conferma manuale.
2. Suggerisci al giocatore l'identità/origine salvata.
3. Auto-refund nel portafoglio di gioco e CTA «scegliere il metodo».

13) Economia e compromessi

L'auto aumenta il costo dell'operatività e aumenta la CSAT/retrazione, ma richiede investimenti in screening/regole/telemetria.
Manuale è più costoso, ma riduce le perdite ingenti rare ed è importante per la protezione regolatoria.
Cerchiamo un punto di equilibrio, il massimo per i segmenti a basso rischio e i corridoi istantanei; manuale per le valigette edge.

14) Test A/B

Soglie «risk _ score», limiti pre-approval, priorità corridoi a cascata.
Copirate e ETA per il ramo manuale.
Guardrails: Returns %, CBR bps, manual p95 TAT, CSAT, Complaints/1k.

15) Best practices (breve)

1. Default-auto per ND≥0, same-method, KYC L1 +, bassi importi e informazioni verificate.
2. Policy-as-code + logica/soluzioni, riproduzione.
3. Cascata di corridoi cost/ETA/salute, auto-failover.
4. Code con priorità SLA e scontrini per l'operatore.
5. L'ETA trasparente e gli stati per entrambi i rami.
6. Pre-funding/limiti dei pool, FX-guarda.
7. Metriche p95/p99 e alert di coda/ritorno/backlog.
8. Post-incidenti e regolari sintonizzazioni/regolamenti.

16) Assegno-foglio di implementazione

  • Matrice di trigger AUTO/MANUAL/DENY e versioning.
  • Scorri e limiti pre-approval per segmenti.
  • Same-method/ND/KYC/RG/sanzioni pre-checks.
  • Code e priorità, SLA e ruoli.
  • Cascate corridoi e health-fid, failover.
  • Modello di dati e timeline, snapshot fich/soluzioni.
  • Dashboard e alert per TTW/SLA/returns/backlog.
  • Playbook: degrado, ondata di ritorni, crescita manuale.
  • A/B e data-frise con lame per i rimborsi/SAN.
  • Controlli regolari di conformità a licenze/regole.

Riepilogo

«Pagamenti manuali vs» non è una scelta «o-o», ma un sistema stratificato: auto - per scenari sicuri prevedibili con una forte telemetria; manuale per valigette strette, rischiose e regolatorie. Formalizzare le regole come codice, misurare p95/p99 e backlog, mantenere cascate di corridoi e trasparenti ETA - e ottenere pagamenti rapidi, affidabili ed economicamente sostenibili.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Telegram
@Gamble_GC
Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.