Cadenas de pago y priorización

1) Concepto de cadena de pago

Cadena de pago (payout chain): lista ordenada de los rieles/proveedores por los que el orquestador intenta sucesivamente realizar el pago hasta que recibe la confirmación del envío ('nat') o la acreditación ('settled').
El objetivo es minimizar el tiempo antes del dinero bajo las restricciones dadas: KYC/AML, límites, liquidez, valor, kat-offs, geo/moneda, perfil de riesgo.

• Rail primario (el riel preferido para el segmento).
• Fallbacks (alternativas por SLA/costo/disponibilidad).
• Rules (condiciones de conmutación) y Constraints (restricciones/límites rígidos).
• Señales de salud (approve/settle/latency/bugs) y Liquidez (balances/prefunding).

2) Criterios de priorización de rieles

1. SLA/velocidad: min/horas/días bancarios; disponibilidad 24/7 (RTP/FPS/Pix) contra D + N (ACH/SEPA).
2. Costo: fix +%, margen FX, tarifas de proveedor; costo-modelo interno.
3. Liquidez: saldo disponible del proveedor/corset, requisitos de prefundación.
4. Compatibilidad: moneda/país del destinatario, formato de datos (IBAN/CLABE/Routing/Sort/PIX-key).
5. Límites: per-txn/daily/weekly en el proveedor y en el destinatario (banco/cartera).
6. Riesgo/CUS: nivel de cliente, SoF/SoW, sanciones/RER, velocity, nuevo beneficiario.
7. Fiabilidad: métricas actuales de fallos, retrasos, devoluciones (reject/return).
8. Kat-offs y calendarios: vacaciones locales, cut-off banco; TZ del remitente/destinatario.
9. Preferencias del producto: VIP/afiliados/jackpots - perfiles individuales.

3) Matriz de orquestación (ejemplo de lógica)

≤ €1k, EU, Full KYC → SEPA Instant → (folback) SEPA SCT → (después de cut-off) el próximo BD.
≤ £250k, UK, 24/7, VIP → FPS (primario), con retrasos> P95 - cambiar al proveedor # 2.
US ≤ $5k → RTP; si el banco del destinatario no admite - Same Day ACH; si la ventana está cerrada - ACH Next Day.
BR → Pix (primary); con los riziques/límites del banco → Pix con tajada reducida o e-wallet payout.
Tarjeta (global) → Push-to-Card (OCT) para envíos rápidos, pero caros y limitables.
Un border cruzado → un e-wallet local (donde hay) → de lo contrario SWIFT con el cálculo de las tasas generales y ETA.

Todos los umbrales y listas numéricas están en la configuración, no en el código.

4) Arquitectura del orquestador de cadenas

• Decision Engine (política): aplica las reglas de selección de rieles y folbacks (políticas declarativas, versionamiento).
• Payout Orchestrator — state machine: `requested → queued → processing → sent/failed → settled/returned`.
• Liquidity/Treasury - balances de proveedores, prefundación, auto-rebalance, límites por proveedor/día.
• Calendar/Scheduler - cut-off, vacaciones por país/moneda, ranuras de envío de batches.
• Provider Adapter Layer - unificación de API, mapping de códigos de estado, idempotencia.
• Reconciliation - auto-conciliación de registros/extractos, descarga UTR/ARN/Trace.
• Compliance - KYC/AML/sanciones/SoF/SoW y gestión de casos.

• Idempotencia ('requestId'), dedoup de eventos, DLQ/retrai c backoff/jitter.
• Observabilidad: rastreo, eventos de orquestación, temporizadores de proveedores.

5) Folback, degradación y escenarios «grises»

Fallback basado en tiempo: si 'processing' ha superado el umbral (por ejemplo, el percentil 90) - cambiar al siguiente raíl (con el primer intento cancelado/void, si es válido).
Health-based: con el crecimiento de 'reject/return' o la caída del approve es la eliminación del proveedor.
Liquidity-based: la escasez de prefundación → ocultar temporalmente los rieles rápidos, ofrecer lento.
Risk-based: en alto riesgo - la prohibición de fast-rails, una colina obligatoria/step-up.
Grey window: noches/vacaciones → auto-planeación en la ventana más cercana; un ETA honesto en IU.

6) Costo y calificación de los rieles

• `eff_cost = fixed_fee + percent_fee amount + FX_margin + failure_cost fail_prob + support_cost`.

• `score = w_slaSLA + w_cost(1/eff_cost) + w_reliabilitysuccess_rate − w_riskrisk_score − w_opsoperational_load`.
• Pesa - Configurable; comparar por segmentos (geo/suma/VIP).

7) Liquidez y Prefundación

Los rieles rápidos requieren prepago: mantenga los mínimos en las cuentas de los proveedores.
Auto-rebalance: reglas de barrido entre billeteras/bancos en los umbrales.
Circuit-breakers: con un residuo <umbral, el método de desactivación automática en la cadena.
Cashbook: separe la contabilidad de los pagos prometidos de los adeudos reales; Control de la brecha de caja.

8) Planificación: batches, kat-offs y calendarios

Batching reduce el costo de SWIFT/ACH/SEPA SCT, pero aumenta la latencia - regula por importe/prioridad.
Cut-off aware: si la solicitud llegó después del corte-off - inmediatamente mostrar ETA para el próximo BD.
API de vacaciones: guarde las vacaciones regionales; para cross-TZ, muestre la hora local del destinatario.

9) Riesgo y KYC en las cadenas

Nuevo beneficiario/gran cantidad → cool-off + step-up, prohibición de fast-rails.
Umbrales → requisito SoF/SoW; antes de la provisión - riel «lento».
Geo/sanciones/RR → duro deny, no hay rutas alternativas.
Velocity: N pagos/día/semana; superando la → de descarga del carril en la cadena.

10) Estados y artefactos

• `requested → queued → processing → sent(UTR/ARN) → settled | failed | returned | on_hold | canceled`.
• Храните: `payoutId`, `beneficiaryId`, `rail`, `provider`, `amount/currency`, `fees`, `ETA`, `UTR/ARN/Trace`, reason-codes, `attempts[]`.

11) Conciliación y registro

Daily auto-recon: descarga de registros, match por 'payoutId/UTR/amount/date'.
Full-recon: control periódico de extremo a extremo (registros/extractos/GL).
Alertas: «éxito sin registro», «aging processing», «doble amb», «silencio del proveedor».

12) UX y comunicación

Exhibición de ETA sobre el raíl y el motivo de la elección («más rápido/más barato/después de cortar-apagar»).
Estados transparentes con UTR/ARN/Trace.
Para folback, un aviso explícito es: "cambiado a {rail} debido a la demora/liquidez; nueva ETA"....
Para VIP, la opción es «acelerar» (otro carril/comisión).
Para los nuevos destinatarios - advertencia de la colina/step-up.

13) KPI и SLO

Tasa on time (% de los pagos que llegaron antes de lo prometido por ETA).
Median/P95 time-to-settle en rieles/proveedores/geo.
Regect/Return rate y distribución de causas.
Tasa de Fallback y su impacto en SLA/costo.
Liquidity uptime (tiempo de disponibilidad de raíles rápidos).
Costo por pago y participación en FX.
Support load (tickets de pago/1k) y NPS para los retiros.

14) Lista de comprobación de inicio de cadena

1. Catálogo de rieles: países/monedas/límites/comisiones/ETA/corte-apagado/vacaciones.
2. Policy Engine: reglas declarativas de priorización + explain-razones de la decisión.
3. Salud de los proveedores: métricas, muestras de salud, autocaravanas.
4. Treasury: prefundación, límites en el proveedor, auto-rebalance.
5. Idempotencia y DLQ: protección contra tomas/repeticiones, retraídas seguras.
6. Webhooks/HMAC: verificación de firmas, tiempos de espera, repetición de entrega.
7. Recon: daily + full, alertas en rassincrones.
8. UX: ETA, status, UTR/ARN, textos de las causas folback/hold.
9. KYC/AML: step-up sobre nuevos beneficiarios/grandes sumas, procedimientos SoF/SoW.
10. Sistema de prueba: éxito/fracaso/retorno, tiempo/liquidez, corte-apagado/vacaciones, degradación del proveedor.

15) Mini pseudocódigo del solucionador

rail_list = rank_by(score(amount, geo, kyc, risk, sla, cost, liquidity, health))
for rail in rail_list:
if violates_constraints(rail, geo, kyc, sanctions, limits): continue if not has_liquidity(rail): continue attempt = send_payout(rail)
if attempt. status in {SENT, SETTLED}: return success(attempt)
if is_retryable(attempt): continue return fail_with_reason(best_reason_collected)

Resumen

Las cadenas de pago son el enrutamiento inteligente entre velocidad, precio, riesgo y disposición operativa. Mantener las reglas y métricas en el decomiso, decidir en función de la función de puntuación teniendo en cuenta la liquidez y la salud de los proveedores, garantizar la idempotencia, el folback y una ETA honesta. Así que reduce el costo y las devoluciones, mantiene el SLA y la confianza de los usuarios - especialmente en segmentos sensibles como iGaming y el border cruzado.