Tokenización de datos

1) Qué es y por qué

La tokenización es la sustitución de valores sensibles (PII/financieros) por tokens no secretos, de los cuales no es posible recuperar el origen sin tener acceso a un servicio/clave independiente. En iGaming, la tokenización reduce el radio de exposición a fugas y el costo de cumplimiento, simplifica el trabajo con proveedores PSP/KYC y permite que analíticas y ML funcionen con datos sin PII directo.

• Minimizar el almacenamiento de datos PII/financieros «en bruto».
• Limitar la entrega de PII por servicios y logs.
• Simplifique el cumplimiento (KYC/AML, pagos, privacidad, leyes locales).
• Mantener la idoneidad de los datos para análisis/ML a través de tokens estables y circuitos deterministas.

2) Tokenización vs cifrado

Cifrado: conversión reversible; protege durante el almacenamiento/tránsito, pero el secreto permanece en los datos (se necesita una clave).
Tokenización: el origen se sustituye por un identificador de referencia (token); el original se almacena por separado (vault) o no se almacena en absoluto (faultless FPE/DET).
Combinación: PII → token, el original en la caja fuerte está cifrado con HSM/KMS; token en productos/logs, desintoxicación sólo en la «zona limpia».

3) Tipos de tokenización

1. Vault-based (clásico):

Almacén de coincidencias «original ↔ token».
Pros: flexibilidad de formatos, fácil desintoxicación, control de accesos y auditoría.
Contras: la dependencia de la caja fuerte (latency/SPOF), la escala y el DR requieren disciplina.

2. Vaultless/criptográfica (FPE/DET):

Cifrado de almacenamiento de formato (FPE) o cifrado determinista (DET) sin tablas de coincidencia.
Pros: sin caja fuerte, alto rendimiento, tokens estables para joynes.
Contras: es más difícil rotar las llaves y revocar, afinar los criptoparómetros.

3. Tokens hash (con sal/pepper):

Conversión unidireccional para asignaciones (match/link) sin reversibilidad.
Pros: barato y rápido; bueno para de-dup en MDM.
Contras: sin desintoxicación; colisiones y ataques sin sal confiable.

4) Objetos de tokenización en iGaming

KYC: pasaporte/ID, número de documento, fecha de nacimiento, dirección, teléfono, correo electrónico, selfie-biométrica (plantilla o ID de almacenamiento del vendedor).
Pagos: PAN/IBAN, monederos, direcciones criptográficas (incluidos los cheques de importe/formato).
Cuenta/contactos: nombre completo, dirección, teléfono, e-mail, IP/Device ID (con reservas).
Análisis operativo: quejas, tickets, chats - los campos de texto pasan edición/enmascaramiento + tokenización en los enlaces.
Logs/Tracks: bloqueamos PII; permitimos tokens/hashes.

5) Patrones arquitectónicos

5. 1 Zonas y rutas

Zona limpia (Restringido): caja fuerte de tokens, HSM/KMS, desintoxicación, RBAC/ABAC estricto.
Zonas grises (Confidential/Internal): servicios empresariales, análisis/ML; sólo funcionan con tokens/agregados.
Zona de borde (Edge/PSP/KYC): integración; El PII entra inmediatamente en la caja fuerte o permanece «en el vendedor» y es reemplazado por el token de referencia del proveedor.

5. 2 Contratos y esquemas

Los contratos de datos describen: dónde está prohibido el PII, dónde se permite el token, el tipo de token (formato, longitud, FPE/UUID), las reglas de validación y la compatibilidad de las versiones.
Registro de Schema: etiquetas 'pii: true', 'tokenized: true', «clase de sensibilidad» del campo.

5. 3 Determinismo y Joynes

Para joyines estables entre dominios, utilice tokens deterministas (FPE/DET) o hashes persistentes con pepper.
Para UI/sapport, tokens de opaque aleatorios + auditoría de solicitudes de conversión inversa.

6) Llaves, cajas fuertes y desintoxicación

Almacén de claves: KMS/HSM, rotación, delimitación de derechos, doble control.
Caja fuerte de tokens: clúster de conmutación por error, replicación entre regiones, procedimiento «break-glass» con confirmación multifactorial.
Desintoxicación: sólo en la «zona limpia», por el principio de menos derechos; tokens de acceso temporal (Just-In-Time) y auditoría obligatoria.
Rotación: programación de claves (crypto-shredding para revocación), política de pluma-tokenización, período «dual-read».

7) Integraciones: KYC/AML, PSP, proveedores

Proveedores de KYC: almacene sólo tokens en sus registros/archivos; escaneos de origen: ya sea en el vendedor o en el almacenamiento fuera de línea de la «zona limpia».
PSP: El PAN nunca entra en el núcleo; use el token PSP + su token interno para las conexiones de sistema cruzado.
AML/listas de sanciones: partidos a través de PSI/MPC o a través de hashes con sales acordadas en el regulador/socio (de política).

8) Tokenización y análisis/ML

Los fichas se construyen a partir de tokens/agregados (ejemplo: frecuencia de depósitos en token pagador, geo por token IP, KYC repetidos por token-ID).
Para textos: Edición NLP de PII + sustitución de entity.
Para las marcas y A/B: el registro fich marca los signos PII no válidos; policy-as-code en CI bloquea PR con PII en las vitrinas.

9) Políticas de acceso y auditoría

RBAC/ABAC: función, dominio, país, propósito de procesamiento, «por cuánto tiempo»; La desintoxicación es sólo por solicitud con justificación.
Revistas: quién y cuándo solicitó la desintoxicación, en qué contexto, a qué volumen.
DSAR/eliminación: por token encontramos entidades relacionadas; cuando se elimina, «crypto-shred» de las llaves y se limpia la caja fuerte/backups según lo programado.

10) Rendimiento y escala

Hot-path: tokenización sincrónica en el inicio de sesión (KUS/pagos), caché de tokens con TTL en zonas «grises».
Bulk-path: retro-tokenización asíncrona de datos históricos; modo «dual-write/dual-read» durante el período de migración.
Fiabilidad: activo-activo caja fuerte, geo-replicación, presupuesto de latencia, graceful-degradation (máscaras temporales en lugar de desintoxicación).

11) Métricas y SLO

Coverage: una fracción de los campos con 'pii: true' que están tokenizados.
Zero PII in logs: porcentaje de registros/tracks sin PII (objetivo: 100%).
Detokenization MTTR: tiempo medio de ejecución de la solicitud válida (SLO).
Clave hygiene: la puntualidad de la rotación de claves, la singularidad del pepper por dominios.
Incidentes: número de violaciones de las políticas PII y su hora de cierre.
Perf: p95 latencia de tokenización/desintoxicación; Disponibilidad de caja fuerte/agregador.
Analytics fitness: proporción de escaparates/modelos que han cambiado con éxito a tokens sin degradación de calidad.

12) RACI (ejemplo)

Policy & Governance: CDO/DPO (A), Security (C), Domain Owners (C), Council (R/A).
Caja fuerte/llaves: Seguridad/Plataforma (R), CISO/CTO (A), Auditores (C).
Integraciones (KYC/PSP): Payments/KYC Leads (R), Legal (C), Security (C).
Data/ML: Data Owners/Stewards (R), ML Lead (C), Analytics (C).
Operaciones y auditorías: SecOps (R), Auditoría interna (C), DPO (A).

13) Patrones de artefactos

13. 1 Política de tokenización (extracto)

Alcance: qué clases de datos están sujetas a tokenización; excepciones y justificaciones.
Tipo de señal: vault/FPE/DET/hash; formato y longitud.
Acceso: quién puede desintoxicar; proceso de solicitud, registro, vida útil del acceso.
Rotación: gráfico de claves, crypto-shred, backfill/dual-read.
Registros: prohibición de PII; medidas punitivas y un incidente de playbook.

13. 2 Pasaporte de campo tokenizado

Campo/dominio: 'customer _ email '/CRM

Clase de datos: PII/Restringido

Tipo de señal: DET-FPE (dominio guardado), longitud 64

Propósito: dedoop/joynes, comunicaciones a través de proxy

Desintoxicación: prohibida; sólo está permitido para DPO por caso DSAR

Artefactos relacionados: contrato, esquema, reglas DQ (máscara, formato)

13. 3 Lista de comprobación de inicio

• Contratos y esquemas marcados con 'pii '/' tokenized'
• Caja fuerte/HSM desplegados, planes DR/BCP listos
• Los linternas CI bloquean el PII en el código/SQL/logs
• Conjunto de pruebas: ausencia de PII en los logotipos/extractores, correcta formato-máscaras
• Dashboards Coverage/Zero-PII/Perf personalizados
• Equipos capacitados (KYC/Payments/Support/Data/ML)

14) Hoja de ruta para la aplicación

0-30 días (MVP)

1. Inventario de PII/campos y flujos financieros; clasificación.
2. Selección de rutas críticas (KYC, pagos, registros) y tipos de tokens (vault/FPE).
3. Despliegue la caja fuerte con HSM/KMS, implemente la tokenización en la entrada KYC/PSP.
4. Habilitar linternas/enmascaramiento de registros; monitoreo Zero-PII.
5. Política de tokenización y proceso de desintoxicación (solicitudes, auditoría).

30-90 días

1. Retro-tokenización de historias en CRM/facturación/tickets; dual-read.
2. Tokens/hashes deterministas para MDM y análisis; Adaptación de Joynes.
3. Rotación de claves según el calendario; dashboards Coverage/Perf/SLO.
4. Integración con DSAR/eliminación (por token y grafo).
5. Playbook de incidentes y ejercicios (table-top).

3-6 meses

1. Ampliación a proveedores/canales de asociación; tokens de referencia de proveedores externos.
2. Inclusión de PSI/MPC para partidos sancionadores sin PII.
3. Cobertura completa de escaparates/ML en tokens; rechazo de PII en logs prod y tries.
4. Auditorías de cumplimiento y reverticiones anuales de procesos.

15) Anti-patrones

"Tokens en los logs, originales también en los logs': lógica sin máscaras/filtros.
Desintoxicación en el lado de las aplicaciones «por conveniencia» sin auditoría.
Clave única/pepper en todos los dominios y regiones.
No hay rotación de claves ni plan crypto-shred.
FPE sin control de formato/alfabeto → fallas en sistemas de terceros.
La tokenización sin cambios en la analítica/ML → joynas y métricas rotas.

16) Conexión con prácticas vecinas

Data Governance: políticas, roles, catálogos, clasificación.
Origen y ruta de datos: donde se crean/desintoxican los tokens, pista PII.
Aprendizaje confidencial ML/Federated: aprendizaje en tokens/agregados, DP/TEE.
Ética y reducción de sesgos: exclusión de proxy-PII, transparencia.
DSAR/Legal Hold: eliminación/congelación de tokens y llaves.
Observabilidad de datos: Zero-PII en los logs, frescura de los token-streams.

Resultado

La tokenización no es una «cosmética», sino una capa básica de seguridad y cumplimiento. La arquitectura correcta (zonas, caja fuerte/HSM, tokens deterministas para análisis), los procesos rigurosos (accesos, auditorías, rotación) y la disciplina en los logs hacen que la plataforma sea resistente a las fugas y los datos útiles sin riesgos innecesarios.