Hot/Cold monederos y política de acceso

1) Por qué dividir en Hot/Warm/Cold

• Hot - depósitos/retiros operativos (T0/T + 1), retrasos mínimos, saldo limitado.
• Warm - pools intermedios para recargos hot y grandes pagos regulares.
• Cold: almacenamiento a largo plazo (reservas/tesorería), lo más aislado posible de la red.

Resultado: menos riesgos operativos y SLA predecibles en exposición controlada.

2) Arquitectura de referencia del almacenamiento

Capas y su función

Hot (en línea, automatizado): firma pagos pequeños/medianos dentro de los límites diarios. Protección - HSM/KMS, motor de políticas, alertas.
Warm (módulo parcialmente en línea/hardware): pagos de batch, recarga hot, límites elevados, confirmación manual.
Cold (offline/air-gapped): multicig/MRS; las operaciones son raras, por procedimiento con acceso físico y registro.

Tecnología

HSM/KMS para claves y tokens hot/warm;

Multicig m-of-n o MPC para warm/cold;

Motor de políticas (límites, 4 ojos, listas de direcciones permitidas, ventanas de tiempo);

Relay privado/protección MEV para transacciones de gran tamaño.

3) Política de acceso (Access Policy)

3. 1 Principios

Privilegios más pequeños (PoLP): acceso exactamente por rol y zona (hot/warm/cold).
Reparto de responsabilidades (SoD): diferentes personas/servicios inician, afirman, firman, lanzan.
4-ojo: mínimo dos aprobaciones independientes para operaciones críticas (límites, listas de direcciones, warm→hot).
Aislamiento de contornos: prod ≠ stage; ACL de red, credenciales individuales.

3. 2 Roles

Operador (Payments): crea pagos/batches dentro de los límites.
Approver (Treasury/Risk): aprobación por encima de los umbrales, whitelist/hold.
Custodian (Key Owner): participación en multicines/MRS para warm/cold.
Compliance: soluciones holds/EDD/SAR, Travel Rule/KYT.
Seguridad: gestión de HSM/KMS, rotación de claves, incidentes.

4) Límites y guardrails

Whitelist/denylist: libreta de direcciones con TTL, umbrales KYT y confirmación obligatoria de propiedad (para unhosted).

5) Flujos operativos

5. 1 Recarga hot de warm

1. Monitoreo de 'hot _ balance <threshold' → solicitud de reposición.
2. CUT/sanciones en las direcciones de destino → recogida de batch.
3. Doble aprobación (4-ojo), firma (warm multicig/MRS).
4. Traducción y grabación en el sello; alerta de cambio de límites.

5. 2 Pagos de hot

Automáticamente dentro de los límites per-tx y per-day.
En caso de exceso, una escalada en warm: batch/lanzamiento parcial + verificación RBA (SoF/KYT/Travel Rule).

5. 3 Rebalance warm↔cold

Periódico (semanal/por umbral) o por decisión del Tesoro; firma offline, dos canales de confirmación independientes, revista.

6) Seguridad clave

Generación y almacenamiento: sólo en HSM/air-gapped; negarse a exportar claves privadas.
Rotación: programada (N meses), no programada en caso de incidente; Procedimientos de revocación documentados.
Backup/Shard-management: bolas cifradas (MPC) en diferentes ubicaciones/jurisdicciones; pruebas de recuperación periódicas.
Perímetro de red: IP allow-list, mTLS, webhooks firmados, monitoreo de anomalías.
Change-control: RFC para cambiar políticas/límites, registro de cambios (immutable).

7) Cumplimiento y control

COT/sanciones: pre-check para la entrada/salida; diferentes perfiles de riesgo por red.
Regla de viaje: para VASP↔VASP: IVMS101, réplica de mensajes y resultados de entrega.
RBA: los límites/confirmaciones dependen del segmento de riesgo y la cantidad.
Auditoría: pista completa: quién/cuándo/qué inició/aprobó/firmó; versión de las reglas en el momento de la operación.
GDPR/PII: minimización, tokenización de ID, almacenamiento separado de PAN de pago.

8) Observabilidad, registros y reconsilación

Lager: mapping 'invoice/withdrawal ↔ txid ↔ wallet (subaccount)' por red/activo.
Reconsificación T + 0/T + 1: importes, comisiones, tasa (fuente de precios, timestamp), saldos sin cubrir.
Monitoreo: balance hot/warm/cold, velocidad de confirmación, fee, pagos anormales, conmutación de red de respaldo.
Alertas: superación de límites/velocity, nuevas direcciones fuera de whitelist, discrepancias de conciliación.

9) Playbucks de incidentes

Filtración/compromiso hot: eliminación inmediata de los límites a cero, transferencia de residuos a warm/cold, rotación de claves, investigación, informe a reguladores/socios.
Anomalías de pago: freeze batch, KYT re-check, solicitud de SoF, liberación parcial de la parte segura.
Degradación de la red/tormenta fee: auto switch-over a la red/método de respaldo, actualización de ETA a IU.
No disponible para el proveedor de custody/RPC: failover, lanzamiento manual de pagos críticos a través de warm, análisis post-incidente.
Cambio de políticas no autorizado: rollback automático, notificación SecOps/Compliance, informe de auditoría.

10) Métricas y OKR

Seguridad/cumplimiento

Participación de activos en cold/warm/hot (rangos objetivo), número de infracciones de límites.
KYT reject%, hits sancionadores, SAR-conversion (si corresponde).
Número de cambios de directivas/mes, solicitudes de aumento de límites válidas/rechazadas.

Confiabilidad/operaciones

Time-to-Payout p50/p95 para rutas hot/warm.
Frecuencia de recarga hot, tamaño promedio de recarga.
Porcentaje de pago automático vs manual, incidentes/trimestre.

Economía/UX

Costo per Approved (todo en una red/activo), un porcentaje fee de la cantidad.
Errores de red/memo/etiqueta, cantidad de release parcial, tickets de latencia.

11) Anti-patrones

Bolsos calientes abarrotados sin capuchas diurnas rígidas.
Un proveedor de castodial/una red sin reserva → SPOF.
Ausencia de 4 ojos y SoD en la cirugía warm/cold.
Llaves sin HSM/KMS, sin rotación regular/pruebas de recuperación.
No hay whitelist/TTL y KYT antes de la retirada - mayor riesgo.
Cambiar los límites «por mensajero» sin RFC/auditoría.
Falta de idempotencia y anti-toma en los retiros - dobles descargas.

12) Lista de verificación de implementación (corta)

• Matriz de capas: hot/warm/cold con límites per-tx/per-day y acciones de activos.
• Roles y SoD: Operator/Approver/Custodian/Compliance/Security, 4 ojos.
• HSM/KMS para hot/warm, multicine/MRS para warm/cold, firma offline.
• Dirección whitelist/denylist con TTL, umbrales KYT, confirmación de propiedad.
• Procesos: recarga hot, pago de batch de warm, rebalance en cold.
• Observabilidad: etiqueta, reconsilación de T + 0/T + 1, alertas de excesos.
• Incidencias de playbooks: compromiso, degradación de la red, inaccesibilidad del proveedor.
• Rule/IVMS101 de viajes, políticas de RBA, auditoría de cambios.
• Idempotencia, anti-toma, backoff + jitter; Webhooks firmados.
• Pruebas regulares de recuperación de llaves y ejercicios de incidentes.

13) Resumen

La estrategia correcta de hot/warm/cold no es simplemente «tres billeteras», sino un modo de gestión de riesgos y acceso: límites y 4 ojos, HSM/KMS y multicine/MRS, KYT/Travel Rule y RBA, procedimientos claros de reposición y pago, observabilidad y playbucks. Este circuito proporciona pagos rápidos desde hot con una exposición mínima de activos y resistencia a incidentes, la base de una infraestructura de pago segura y rentable de iGaming.