Afinación de reglas y antifraude

TL; DR

El antifraude no es una «captura de intrusos», sino una optimización de las ganancias: minimizamos el Expected Loss (EL) de Frod y Charjbacks al limitar el Costo de la Fricción (CoF) y el AR_net. Diagrama básico: puntuación (ML) → umbral/leñador step-up → reglas (policy & velocity) → verificación manual. El éxito lo dan: etiquetas limpias, fijas estables, umbral calibrado económicamente, lanzamientos canarios, estricta idempotencia y manejabilidad de la normativa.

1) Producción económica

• `EL = P_fraud(tx) × Exposure(tx)`; normalmente 'Exposure = captured_amount'.

• `CoF = (Abandon_on_Friction × LTV_new/ret) + Opex_review + Fees_stepup`.

• `Profit = GGR − Cost_payments − EL − CoF`.

Umbral óptimo 'τ': seleccionamos score-cutoff para que 'd (Profit )/d τ = 0', o por min grid ('EL + CoF'). En la práctica, es un ROC/PR costoso-sensitivo con escalas: 'w _ fraud = Exposure', 'w _ fp = LTV_loss + opex'.

2) Lesenka de autenticación (step-up ladder)

1. Auto-approve (bajo riesgo): paso instantáneo, 3DS frictionless donde se puede.
2. Step-up A: 3DS challenge / SCA / device-challenge / reCAPTCHA.
3. Step-up B: легкий KYC (doc selfie/face-match, liveness).
4. Revisión manual: caso de un analista (SLA, reason-codes).
5. Auto-decline: alto riesgo/sanciones/mulas/anomalías de cupones.

El umbral/rama depende de la puntuación de puntuación, la suma ('ticket _ size'), el país, el BIN/issuer, el fich de comportamiento y el contexto (campañas de bonificación, ventanas nocturnas, velocity).

3) Señales y fichas (base mínima)

Pago: BIN/IIN, issuer_country, ECI/3DS flow, AVS/CVV match, códigos soft-decline, devoluciones/disputes en el historial.
Conductual: velocidad de eventos (velocity: 'cards/device/ip/email'), hora del día, first-seen/last-seen, «topología» de cuentas (grafo-comunicaciones: dispositivos/tarjetas/carteras comunes).
Dispositivo/red: dispositivo fingerprint, emuladores/jail/root, proxy/VPN/TOR, ASN/hosting.
Anti-bonus: referencias sindicales, bonificaciones de «bombeo», patrones anómalos depozit→vyvod sin jugar.
Pagos/carteras/vales: repeticiones de PIN, geo-mismatch, redimas de «velocidad», cascadas de muling.
KYC/KYB: nivel, validación, banderas SoF/SoW.
Sanciones/RER/hojas de flujo: coincidencias en las listas, fuzzie-match FIO/direcciones.

4) Pila: ML + reglas

5) Métricas de calidad (con bases claras)

AR_clean = `Auth_Approved / (Auth_Attempted − Fraud_preblocked − Abandon_3DS)`

Fraud Rate (por capturas) = 'Fraud _ captured _ amount/ Captured_amount'

Chargeback Rate = 'Chargeback _ count/ Captured_Tx' (o por suma)

False Positive Rate (FP) = `Legit_declined / Legit_attempted`

Step-up Rate = `StepUp_tx / Auth_Attempted`, Abandon_on_StepUp

Auto-approve %, Manual review %, Review SLA/TtA

Net Profit uplift después de la afinación (control AB-diferencia EL + CoF vs).

Puntos de referencia: FP en nuevos usuarios ≤ 1-2% (en volumen), Fraud (en suma) - en el corredor de licencias/circuitos objetivo.

6) Umbrales y políticas de normas

6. 1 Calibración del umbral

Construimos costa-curva: para cada 'τ' contamos 'EL (τ) + CoF (τ)'.
Elegimos 'τ' con un mínimo. Para un alto ticket, el «τ _ hi» separado.

6. 2 Reglas modelo (pseudocódigo)

yaml
- name: SANCTIONS_HIT when: sanctions_match==true action: DECLINE reason: "Sanctions/PEP match"

- name: BIN_RISKY_3DS when: bin in RISKY_BINS and score in [τ_low, τ_mid)
action: STEPUP_3DS

- name: DEVICE_VELOCITY_LOCK when: device_id in last_10min.deposits > 3 action: DECLINE_TEMPORARY ttl: 2h

- name: BONUS_ABUSE_GUARD when: (bonus_received and gameplay_turnover < Xdeposit_amount) and payout_request action: HOLD_REVIEW reason: "Turnover not met"

6. 3 Límites dinámicos

Límite de cantidad y número de transacciones por nivel de riesgo (risk-tier): 'R1/R2/R3'.
Límites adaptativos para nuevas cuentas, calentadas con una buena historia.

7) Ciclo de vida de las reglas (gobierno)

DSL/Registro de reglas con versiones, propietario y descripción del efecto.
Shadow mode → canary (5–10%) → full rollout.
RACI: Owner (Payments Risk), Approver (Compliance/Legal), Consulted (Support/Treasury), Informed (Ops).
Registro de auditoría: quién/cuándo cambió qué métricas/AV, revertir.
Fecha de caducidad de la regla y revalorización (por ejemplo, 30/60 días).

8) Datos y formación de modelos

Splits en el tiempo, sin fugas (features sólo desde la ventana pasada).
Etiqueta de destino: confirmed fraud/chargeback; etiquetas individuales de bonus abuse.
Reweighing clases por suma (amount-weighted loss).
Drift-monitoring: PSI para Fiech clave, KS para Skors, estabilidad baseline.
Desencadenadores Retrain: PSI> 0. 25, caída de KS, cambio de tráfico/jurisdicciones.

9) Explicabilidad y sapport

Para cada decisión, generamos reason_codes (hasta 5 razones) con pistas humanizables.
Macros de sapport por step-up/fallas (3DS, KYC, turnover).
Esporas/Dispouts: la retroalimentación cae en el labeling pipeline (cerramos el ciclo).

10) Cumplimiento y privacidad

GDPR/DSAR: derecho a explicar la decisión; minimización de los PII; hashing (salted) ID (email/phone/PAN-token).
PCI-DSS: hilos PAN-safe, tokenización.
Sanciones/AML: circuito separado de cribado + escalamiento MLRO.
Retention: políticas de retención de señales y justificaciones de soluciones.

11) Monitoreo y alertas (hora/día)

AR_clean, Fraud (amt%), FP (retention-weighted), Step-up/Abandon, Review SLA, Chargeback Rate (lagged).
Spikes velocity, crecimiento de alojamiento TOR/Proxy/ASN, degradación BIN, cupón redimensional.
Alertas en: FP> pasillo, Fraud> target, Abandon> bases + X p.p., deriva PSI/KS.

12) Cortes SQL (ejemplo)

12. 1 Métricas básicas

sql
WITH base AS (
SELECT
DATE_TRUNC('day', attempt_ts) d, country, provider, method_code,
COUNT() FILTER (WHERE auth_status='ATTEMPTED') AS attempted,
COUNT() FILTER (WHERE auth_status='APPROVED') AS approved,
COUNT() FILTER (WHERE decision='DECLINE' AND label='LEGIT') AS fp_cnt,
SUM(captured_amount) AS cap_amt,
SUM(CASE WHEN label='FRAUD' THEN captured_amount ELSE 0 END) AS fraud_amt
FROM payments_flat
GROUP BY 1,2,3,4
)
SELECT d, country, provider, method_code,
approved::decimal/NULLIF(attempted,0) AS ar_clean,
fraud_amt::decimal/NULLIF(cap_amt,0)  AS fraud_rate_amt,
fp_cnt::decimal/NULLIF(attempted,0)  AS fp_rate
FROM base;

12. 2 Proporción de step-up y fallas por rebote

sql
SELECT
DATE_TRUNC('day', attempt_ts) d,
WIDTH_BUCKET(score, 0, 1, 10) AS bucket,
AVG(CASE WHEN decision='STEPUP' THEN 1 ELSE 0 END) AS stepup_share,
AVG(CASE WHEN decision='DECLINE' THEN 1 ELSE 0 END) AS decline_share,
AVG(CASE WHEN stepup_abandon THEN 1 ELSE 0 END) AS abandon_after_stepup
FROM risk_events
GROUP BY 1,2
ORDER BY d, bucket;

13) Playbucks de afinación

El crecimiento de Fraud (amt%) con FP estable → elevar la 'τ', reforzar la velocidad por dispositivos/ASN, habilitar la 3DS-challenge en BIN vulnerables.
Alta FP en los nuevos → suavizar 'τ' para bajo ticket, traducir la parte en Step-up A en lugar de desviar.
Abandon en 3DS↑ → negociar con PSP sobre los parámetros 3DS2, mejorar UX, reducir el paso en los móviles para bajo riesgo.
Redes de bonos sindividuales → fichas gráficas, límite de pagos «paralelos», reglas turnover.
Anomalías de cupón → velocity por PIN/retailer/geo, device-binding, hold antes de la verificación.

14) Implementación: lista de verificación

• Calibración económica del umbral ('EL + CoF'), individuales 'τ' por segmentos.
• Registro de reglas (DSL), shadow→canary→rollout, auditoría y reversión.
• Reason-codes y patrones de comunicación.
• Monitoreo de PSI/KS, derivación de fich/skors, retrain regular.
• Canal de retroalimentación (disputy→leybly).
• Las políticas KYC/step-up, SLA review y TtA/TtR.
• Privacidad: hash ID, minimizar PII.

15) Resumen

La afinación antifraude es la optimización de beneficios del sistema con fricción controlada: ML-scoring + step-up de madera elaborada, reglas legales estrictas y límites de velocidad ordenados. La calibración económica del umbral, las etiquetas limpias, los pliegos canarios y la rigurosa manejabilidad dan un Fraud bajo en cantidad, un FP bajo en los nuevos, un AR_net alto sin sorpresas para el cumplimiento y el UX.