Políticas de conclusiones: plazos y KYC
1) Por qué formalizar la política de conclusiones
Las conclusiones (payouts/withdrawals) son la sección más sensible del embudo de pago: afectan a NPS/Retention, cumplimiento regulatorio y perfil de riesgo. Política clara:- reduce el nivel de tickets y escaladas ("¿cuándo vendrá el dinero? »);
- proporciona cumplimiento AML/KYC (edad, sanciones, SoF/SoW);
- reduce los feudos/charjbecks y las disputas arbitrales;
- proporciona SLAs predecibles para finanzas/sapport/marketing.
2) Clasificación de rieles y velocidad esperada
3) Niveles de KYC e impacto en las conclusiones
Principio: cuanto más alto es KYC, más anchos son los rieles disponibles y mayores son los límites/velocidad.
Básico (simplificado): límites pequeños; sólo se permiten «lentos» o salidas internas (por billetera/A2A restringida).
KYC completo (ID + Dirección + Vida): límites estándar; acceso a raíles bancarios, Push-to-Card, circuitos rápidos locales.
EDD (ampliado): grandes cantidades/pagos frecuentes; requiere SoF/SoW (fuente de fondos/estado), listas blancas de destinatarios, procesamiento acelerado.
Step-up-desencadenantes: gran cantidad, nuevo destinatario, dispositivo/geo atípico, exceso de velocidad, MCC de alto riesgo (iGaming, quasi caché), ganancias acumuladas.
4) Límites y antifraude en las conclusiones
Diseñar umbrales de niveles:- Per-transaction / Daily / Weekly / Monthly caps.
- Velocity: N pagos/hora, cantidades por ventana deslizante, frecuencia de cambio de datos.
- Nuevos destinatarios: rebajado de sar/cooling-off obligatorio (por ejemplo, 12-24 h) y step-up.
- Geo/sanciones: listas deny/allow, prohibición de ciertos países/bancos.
- Perfil de riesgo: multiplicadores de límites por score de cliente/sesión.
- Payout-lock: bloqueo temporal tras anomalías/chargeback/ODR, hasta que se complete la validación.
5) Estados de pago y modelo operativo
Taxonomía unificada (ejemplo):- 'requested' - consulta del usuario
- 'queued' - puesto en cola de pagos
- 'processing' - en el procesamiento con el proveedor/banco
- 'sent' - enviado al raíl (hay UTR/ARN/Trace)
- 'settled' - Acreditación confirmada del destinatario/No Finish
- 'failed' - falla de riel/banco
- 'reversed/returned' - reintegro (ACH-R, SEPA return, FPS reject)
- 'on _ hold' - verificación de cumplimiento/EDD/SoF
- 'cancelado' - cancelado por el usuario/operador
Artefactos: 'payoutId', 'requestId' (idempotencia), 'beneficiaryId', 'rail', 'amount/currency', 'UTR/ARN/Trace', códigos de fallo.
6) Cola de pagos y arquitectura de núcleo
Componentes:- Orchestrator (máquina de estado): enrutamiento por raíles/límites/zonas de tiempo.
- Scheduler: contabilidad de corte/vacaciones (per-rail/per-country).
- Idempotency: clave en 'requestId' + deduplicación de eventos.
- Webhooks del proveedor: firma/NMAS, retras con backoff, DLQ.
- Reconciliation: auto-recon por registro (diario) + recon completo periódico; Almacenamiento UTR/ARN.
- Motor de políticas: reglas de CUS/límites/puntuación y causas de denegación (explainability).
- Treasury/Liquidity: monitoreo de residuos de PSP/bancos, prefundación bajo raíles rápidos, rebalance.
7) Liquidez y Prefundación
Los raíles rápidos (RTP/FPS/PIX/Push-to-Card/e-wallets) a menudo requieren prefundación.
Mantenga los límites en el proveedor y el rebalance automático (sweep) entre las cuentas.
Brecha de caja: separe la contabilidad de los pagos «prometidos» de los adeudos reales.
Introduzca el método de desactivación automática en caso de caída de liquidez (cambie temporalmente a carriles lentos).
8) Comunicaciones y UX
Mostrar la fecha/hora de llegada esperada teniendo en cuenta el riel, corte-apagado y TZ del usuario.
Los estados explicables son: «en la verificación KYC/SoF», «esperamos una ventana bancaria», «enviado: número UTR/ARN».
Preguntas frecuentes en el producto: límites, plazos, raíles soportados, qué es SoF/SoW, por qué se rechaza la solicitud.
Nuevos destinatarios: advertencia de la colina/step-up, confirmación de datos (micro-depósito/1-cent check, test payout).
Anti-error UX: máscara IBAN/BIC, validación de formato, sugerencia de código BSB/Sort, guardar las «plantillas» de los destinatarios.
Cooldown: latencia suave para perfiles de alto riesgo con causa transparente.
9) Cumplimiento: KYC/AML/EDD/SoF/SoW
KYC: ID, dirección, liveness; edad y geo-bloques.
Sanctions/PEP: cribado al onboarding y cíclico; antes de los pagos importantes - cheque repetido.
SoF/SoW: confirmación de la fuente de fondos/estado (estados bancarios, certificados de ingresos, contrato).
Gestión de casos: registro de soluciones, SLA de procesamiento, audit-trail.
Juego responsable (para iGaming): colinas de retiro de fondos de bonificación, cheques de autoexclusión, límites «responsables» de día/semana.
10) Errores y devoluciones en los rieles (qué tener en cuenta)
ACH: devoluciones (R01... R10), ventanas NACHA, hojas de bloques.
SEPA: Reject/Return/Recall; La validación IBAN, la causa del código (AC04, AG01, etc.).
FPS/RTP/PIX: generalmente, finalidad; la devolución es una operación contraria independiente.
Push-to-Card: puede haber retrasos en el emisor/desviación por límites.
SWIFT: comisiones de corresponsales, «fees lifting», retrasos en el cumplimiento del banco receptor.
11) Economía y Comisiones
Modelo FEE: fix/porcentaje, umbrales por importe, margen FX, tarifas individuales para carriles rápidos.
Niveles de KYC ↔ tarifas: VIP/EDD - por debajo de la comisión/prioridad; Basic - mayor costo de mantenimiento.
Costos antifraude: costo de las inspecciones/inversiones, porcentaje de reembolsos/rechazos.
Optimización: agrupación de pagos (batch), programación de rieles «lentos» en off-peak, selección de rieles según la cantidad/país/hora del día.
12) KPI/métricas para administración
SLA cumplimiento:% de los pagos que llegaron dentro del plazo prometido.
Time-to-Cash: mediana/95-percentil del tiempo hasta 'settled'.
Volver/Reject rate por raíles y razones (códigos).
Compartir por rail: la distribución por métodos y su approve/settle.
ODR/quejas por retrasos/denegaciones.
Tasa Hold/EDD: porcentaje de pagos que han sido verificados manualmente; tiempo medio de decisión.
Liquidity uptime: tiempo en el que los rieles rápidos están disponibles.
Cost per payout и FX impact.
13) Lista de comprobación de inicio de la política de salida
1. Matriz de rieles: país/moneda/límites/plazos/corte-apagado/vacaciones - en el servicio de configuración.
2. Motor de políticas: reglas KYC/limites/velocity/EDD con logs explain.
3. Orquestador de pagos: cola, retraídas, idempotencia, webhooks con HMAC.
4. Treasury: prefundación de rieles rápidos, auto-rebalance, límites en el proveedor.
5. KYC/AML/SoF/SoW: proveedores, playbooks, SLA, escaladas.
6. UX/Comunicación: ETA en riel, estados, UTR/ARN, causas comprensibles de las colinas/rechazos.
7. Recon: daily auto-recon + full-recon; alertas al "éxito sin registro", "aging payouts'.
8. Monitoreo: dashboards KPI, alarmas de liquidez/fallas/crecimiento de devoluciones.
9. Paquete de prueba: e2e para cada carril (éxito/fracaso/retorno), nuevo destinatario, cantidad grande, tiempo de espera del proveedor.
14) Plantilla de sección de política (para ToS/wiki)
Plazos:- SEPA: T + 1 BD (hasta las 15:00 CET), SEPA Instant - normalmente durante 30 minutos.
- FPS/PIX/RTP: normalmente modo minuto, pero es posible realizar verificaciones de hasta 24 h para nuevos destinatarios.
- ACH: T+1–T+2 BD; Same Day ACH - Cuando se presenta a un banco de kat-off.
- Hasta € X/día - Básico, más - se requiere ID + selfie; más de € Y - SoF/SoW.
- Nuevo receptor - hasta 24 h de colina segura.
- Per-txn: …, Daily: …, Weekly: … (dinámicamente por nivel/riesgo).
- SEPA/FPS — …, SWIFT — … (+ comisiones de corresponsales), Push-to-Card -....
- En el caso de Reject/Return, los fondos volverán al balance dentro de...; La razón de la notificación (código/descripción).
15) Respuestas rápidas para sapport
¿Cuándo llegará el dinero? - Para {rail} espere hasta {ETA}. Su UTR/ARN: {código}.
¿Por qué la colina? - Funcionaron las reglas de seguridad (nuevo receptor/suma/geo). Por favor, descargue el documento {SoF/ID}.
¿Es posible más rápido? - {raíl rápido} necesitará prefundar/otro límite; sugeriremos un método alternativo.
¿Por qué la denegación? - El banco del destinatario rechazó (código {X}). Compruebe los detalles o seleccione otro riel.
Resumen
Fuerte política de inferencia = plazos transparentes + límites predecibles KYC + orquestación de rieles confiable. Mantenga las reglas en la configuración, use el motor de políticas con logs de explosión, proporcione idempotencia/Recon/Webhooks, administre liquidez y prefundación y comunique con el usuario la ETA + UTR/ARN exacta. Así que reduce el riesgo, mantiene el cumplimiento y aumenta la confianza sin sacrificar la velocidad de pago.