Operaciones y Cumplimiento → Tipos de licencias y requisitos

Tipos de licencias y requisitos

1) Imagen de los tipos de licencias

• B2C (operador): derecho a ofrecer juegos a los usuarios finales (casino, live, betting, poker, lotto, etc.).
• B2B (proveedor): derecho a proporcionar plataforma/contenido/servicios a los operadores (plataforma, juegos/RNG, estudios en vivo, pagos como proveedor de tecnología, alojamiento).

• Casino/Slots, Live Casino, Sportsbook (fixed-odds, in-play), Poker (P2P), Bingo/Lottery, Fantasy/Skill-based.

• Licencia propia (operador/propietario de la marca).
• White-Label (derecho B2C a través de una licencia de plataforma con sublicencia de marca/autorización).
• Skin/Brand Authorization (conectando marcas adicionales a una licencia existente).
• Modelo distribuido (licencia local + infraestructura cruzada regional, espejos/edge/localización de datos por normas).

2) Requisitos: qué piden los reguladores (marco)

Legal/Corporativo

Beneficiarios, estructura de tenencia, ausencia de sanciones/antecedentes penales.
Presencia local (persona jurídica/representación/oficial responsable).
Contratos con proveedores (B2B), derechos de contenido, alojamiento/centro de datos.

Financiero

Capital social mínimo/reservas, garantías financieras/garantías bancarias.
Cuentas individuales del cliente/segregación de fondos, procedimientos anti-chargeback.
Informes auditados, fuentes de fondos de los beneficiarios (SoF/SoW).

Técnico (plataforma/infraestructura)

Arquitectura, lógica/observabilidad, redundancia, DR/BCP.
Honestidad de juegos: RNG/matemáticas, certificación de contenido, control de cambios de versiones.
Seguridad de la información: encriptación en tránsito, IAM, registro de actividades administrativas.
Restricciones geográficas/localización de datos, protección contra bots y fraudes.

RG/KYC/AML

Edad/verificación de identidad y dirección, RR/sanciones, límites/autoexclusión.
Supervisión de transacciones y comportamientos (velocity, SoF), procedimientos EDD.
Listas de autoexclusión/listas negras, capacitación del personal.

Marketing/Publicidad/Afiliados

Disclemers de edad, prohibición de promesas «libres de riesgo», limitación de canales/franjas horarias.
KYB de afiliados, biblioteca creativa, seguimiento UTM/fuente de tráfico.

Informes y auditorías

Descarga periódica/real-time (GGR, RG, quejas, AML/SAR).
Auditorías externas/internas: t-auditoría, auditoría de juegos/RNG, auditoría de seguridad/privacidad.
Incidente-reporting (notificaciones SLA del regulador/bancos/jugadores).

3) Modelo de datos «registro de licencias» (YAML)

yaml license_id: B2C-CASINO-<COUNTRY>-<NNN>
role: b2c      # b2c      b2b verticals: [casino, live, betting]
jurisdiction: <ISO-2>
holder: <legal_entity>
brands: [brandA, brandB]
local_presence: required  # required      optional      none valid_from: YYYY-MM-DD valid_to: YYYY-MM-DD financial_guarantee: {type: bank_guarantee, amount: <currency_amount>}
tech_requirements:
rng_cert: true siem_logs: true dr_rto: "30m"
data_localization: false rg_kyc_aml:
kyc_levels: [basic, address, edd]
self_exclusion: registry aml_ruleset: "v3. 1"
ads_affiliates:
disclaimers: [age, wagering_conditions]
restricted_channels: [tv_daytime]
reporting:
frequency: monthly formats: [csv, api]
realtime: [rg_cases]
contacts:
compliance_officer: email@domain mlro: aml@domain review_sla_days: 180 status: active

4) El ciclo de vida de la licencia y las obligaciones

4. 1. Reclamación de licencia (Application)

Pre-DD: estructura, SoF/SoW, empresa/agente local, contratos con B2B.
Paquete técnico: esquema arquitectónico, seguridad, BCP/DR, procesos de lanzamiento/cambio, lógica/auditoría.
Contenido: RNG/matemáticas, lista de proveedores, integraciones.
Políticas operativas: RG/KYC/AML, incidentes, publicidad, quejas.
Finanzas: capital/garantías, plan de negocios, previsión de informes e impuestos.

4. 2. Etapa operativa (Post-grant)

Cumplimiento de Policy/Controls-as-Code.
Informes programados, mantenimiento de registros (quejas, casos AML/RG, incidentes).
Negociación de cambios: lanzamientos, nuevos proveedores, cambio de alojamiento/centro de datos, nuevos métodos de pago.

4. 3. Renovación (Renewal)

Certificados RNG/de seguridad actualizados.
Auditoría del período, indicadores RG/AML, estadísticas de quejas.
Confirmación de sostenibilidad financiera/garantías.

4. 4. Cambios (Variation)

Agregar vertical/marca, etiqueta blanca/piel, migración de plataforma.
Notificaciones de cambio de beneficiarios/direcciones.
Cambios en la política publicitaria y la red de afiliados.

5) Matriz de compromisos de rol/vertical (ejemplo)

6) Lista de solicitud (Application Dossier)

Unidad empresarial

• Estructura de propiedad/beneficiarios/SoF/SoW.
• Jurlizo/representante local, autoridad de los oficiales.

• Informes/plan auditados.
• Garantía bancaria/seguro/depósito.

• Arquitectura, observabilidad/lógica/auditoría, CI/CD, gestión de cambios.
• BCP/DR (RTO/RPO, protocolos de prueba), seguridad (cifrado, IAM, secretos).
• RNG/certificación de contenido, control de lanzamientos de juegos.

Operaciones/políticas

• RG/KYC/AML, quejas, incidentes/reporting, sapport/SLA.
• Publicidad/afiliados: reglas, plantillas, biblioteca creativa.

• Formatos de descarga, frecuencias, archivos de prueba, personas de contacto.

7) Control en venta: Policy-/Controls-as-Code

yaml control_id: RG-LIMIT-LOSS-DAILY scope: bets trigger: loss_today > limit_loss_daily actions:
- block: further_bets
- notify: player_template_rg_limit evidence:
fields: [loss_today, limit, messages_sent, ack]
overrides:
- country: <ISO>
set: {limit_loss_daily: <amount>, cool_off_hours: <N>}
owner: rg_officer review_sla_days: 180

yaml control_id: AML-VELOCITY-01 scope: deposits trigger:
expr: rolling_sum(amount, 1h) > baseline_30d3 OR count_unique(payment_method,1h)>=3 actions:
- flag: aml_review
- limit: withdrawals "hold_24h"
- notify: mlro evidence:
store: s3://evidence/aml-velocity/{player_id}/{ts}
owner: mlro

yaml policy_id: RELEASE-GATE-COMPLIANCE require:
- country_overrides_present: true
- report_schemas_valid: true
- rg_controls_enabled: true
- ads_templates_localized: true on_fail: block_release

8) Gestión de cambios bajo licencia (SOP, fragmentos)

SOP: Agregar una nueva marca (skin)

1. Comprobar los términos de la licencia (si la autoridad de marca está permitida).
2. Registrar marca/dominio/localización/etiquetas de edad.
3. Vincular políticas e informes RG/KYC/AML/Ads.
4. Probar informes (brand-split), habilitar el registro.
5. Notificar al regulador/bancos (si es necesario), fijar la evidencia.

SOP: Conexión de un nuevo proveedor de juegos

1. Comprobar el estado/certificados del proveedor en el registro.
2. Conciliar contenido/vertical, configurar RNG/métricas/lógica.
3. Actualizar informes (ID de juego/proveedor).
4. Lanzar el lanzamiento a través de policy-gate, recoger evidence.

9) RACI (funciones)

10) Calendario de compromisos (Calendario de cumplimiento, ejemplo)

Diariamente: RG/AML monitoreo, incidente-reporting en los hechos.
Semanalmente: informes de integración de proveedores/pagos, verificación de alertas de cumplimiento.
Mensualmente: descargas regulatorias (casos GGR/beta/RG), conciliaciones con DWH.
Trimestralmente: t-audit/scan de seguridad, informes de proveedores, rugidos de Policy/Controls.
Semestral/año: renovación de certificados RNG/IB, auditoría de la eficacia de los controles, renovación de licencias/autorizaciones.

11) Anti-patrones

«La licencia está ahí - procesos de sudor»: ausencia de Controles-as-Code, informes y evidencia.
Dos versiones de la verdad: Informes Excel ≠ registros productivos.
Falta de brand-split en los datos, «un montón común» de métricas.
EDDs manuales sin reglamento/tiempo y registro.
Publicidad a través de afiliados sin KYB y bibliotecas creativas.
No hay pruebas de DR/registros de cambios para RNG/juegos.

12) Métricas de madurez

Controles de cobertura: ≥ 95% de puntos críticos (registro/depósito/apuestas/retiros/bonos).
Reporting SLA: tiempo de descarga ≥ 98%, errores esquemáticos = 0.
Evidence completeness: ≥ el 98% de los casos con paquetes correctos.
KPIs RG/AML: proporción de casos evitados/escalados, False Positive ↓ QoQ.
Audit findings TTR: cierre ≤ 90 días.
Revisión de políticas SLA: revisiones atrasadas = 0.

13) 30/60/90 - Plan de aplicación

• Crear un registro de licencias y una taxonomía de requisitos sobre roles/verticales.
• Elevar el conjunto básico Controls-as-Code (RG/AML/reporting).
• Recopilar plantillas de Application Dossier (corporativo/financiero/aquellos/operativo).
• Habilite release-gate compliance en CI.

• Conecte los escaparates de informes y automatice las descargas (brand-split, country-split).
• Incorpore RG/KYC/AML en el flow de productos; Ejecutar evidence-by-design.
• Llevar a cabo la primera auditoría interna y la prueba DR/BCP bajo RTO/RPO con licencia.

• Cubrir con controles ≥ 95% de puntos críticos, Reporting SLA ≥ 98%.
• Formalizar el RACI y el calendario de compromisos; vincular los KPI a los comandos OKR.
• Preparar el paquete para renovar/variar la licencia (variaciones de marcas/verticales).

14) FAQ

P: ¿Qué elegir: licencia propia o etiqueta blanca?
R: Su licencia es superior a SAREH/plazo, pero el control y la evaluación del negocio es mayor. Etiqueta blanca: inicio más rápido, menor flexibilidad/evaluación, dependencia del titular de la licencia.

P: ¿Cómo minimizar los riesgos de denegación de solicitud?
R: Fuerte Techpacket (seguridad/DR/observabilidad), garantías financieras, SoF/SoW transparentes, procesos maduros RG/AML y "evidence-by-design'.

P: ¿Cómo administrar los cambios de proveedores/contenido?
R: A través de procedimientos de variación: preacuerdo, control de versiones de juegos/RNG, reporting y registro de lanzamientos.