Una cuenta en una plataforma de iGaming regulada está protegida por dos comprobaciones que se confunden constantemente entre sí. La acreditación de edad responde si esta persona puede jugar. La verificación de identidad responde quién es esta persona, para que la cuenta, el dinero y el registro regulatorio se vinculen al mismo ser humano. Ninguna sustituye a la otra, y una plataforma que implementa bien una de ellas puede fallar la otra, porque la evidencia que cada una necesita no es la misma evidencia.
Para el responsable de cumplimiento, el arquitecto de plataforma o el proveedor de identidad de un operador, el artefacto de entrega es un paquete de control de verificación: la obligación que activa la comprobación, el nivel de garantía que debe alcanzar, la clase de evidencia que puede aceptar, la regla temporal que decide cuándo se ejecuta, el registro que prueba que se ejecutó y el comportamiento definido para cada desenlace que no sea un paso limpio.
La acreditación de edad y la verificación de identidad responden a preguntas distintas
El código de responsabilidad social 3.2.11 de Gran Bretaña para operadores a distancia exige que los titulares dispongan de procedimientos y los apliquen para verificar la edad de un cliente antes de que ese cliente pueda depositar fondos, acceder a versiones gratuitas de juegos de azar o jugar con su propio dinero o con cualquier apuesta o bono gratuito. Conviene fijarse en lo que contiene esa lista: una versión gratuita de un juego está dentro del límite. Una superficie que los equipos de producto consideran marketing queda detrás de una barrera de edad igual que una cartera de dinero real.
La condición de licencia 17.1.1 pide otra cosa. Los titulares deben obtener y verificar información para establecer la identidad de un cliente antes de que se le permita jugar, y esa información debe incluir el nombre, la dirección y la fecha de nacimiento del cliente. Una obligación es un predicado de umbral sobre la edad; la otra es un registro de identidad con tres componentes. Un único «paso de KYC» en el flujo de caja suele satisfacer la segunda y dar por supuesta la primera.
Ambas obligaciones están además acotadas, y ese alcance forma parte del diseño. La 3.2.11 se aplica a todas las licencias a distancia excepto las de lotería, las técnicas de máquinas de juego, el software de juego, el anfitrión y las licencias accesorias de casino y bingo a distancia; la 17.1.1 tiene sus propias excepciones declaradas, incluidas las licencias de lotería que solo ofrecen loterías de baja frecuencia o de suscripción. La lógica de verificación debe ser por tanto una decisión por licencia y no un interruptor global. Un proveedor que codifica «verificar siempre» para un cliente se encuentra con la lista de excepciones cuando se audita la clase de licencia del segundo.
Elija un nivel de garantía y después la ruta de evidencia
Los marcos de prueba de identidad describen niveles antes de describir métodos. La SP 800-63A-4 del NIST, publicada en su versión final el 31 de julio de 2025 y que sustituye a la SP 800-63A, define requisitos técnicos para tres niveles de garantía de identidad y trata el nivel como la decisión que toma la organización. El marco británico de servicios de verificación digital tiene la misma forma: la Data (Use and Access) Act 2025 creó un registro legal de proveedores de servicios de verificación digital, y el marco de confianza que lo sustenta define niveles de confianza.
La consecuencia para la ingeniería es que el nivel de garantía decide qué rutas de evidencia son admisibles. Un nombre contrastado contra un conjunto de datos de referencia, una imagen de documento contrastada con una prueba de vida y una comparación supervisada de una persona con un documento son clases distintas de evidencia, y ninguna puntuación de riesgo convierte una clase más débil en una más fuerte. Escriba el nivel previsto por comprobación, elija después la evidencia y registre qué ruta se ejecutó realmente. Cuando un revisor pregunte por qué se verificó una cuenta, «el proveedor devolvió un aprobado» no es un registro de una ruta de evidencia.
Mantenga también las tres preguntas separadas en el modelo de datos: si esta persona tiene edad suficiente, si esta persona es quien dice ser y si la sesión que tenemos delante sigue siendo esa persona. Conllevan costes de fallo distintos y disparadores de recomprobación distintos, y la guía de control de acceso al back office cubre el lado de privilegios de la tercera pregunta.
Verifique antes de que el valor se mueva, no en la pantalla de retirada
El momento es donde suele perderse un diseño defendible. La condición 17.1.1 establece que una solicitud de retirada de fondos de un cliente no debe convertirse en la exigencia de información adicional como condición para el retiro si el titular podría haber solicitado razonablemente esa información antes. Esa frase es una instrucción de arquitectura: la verificación pertenece al punto en que la cuenta adquiere valor o antes, no al momento en que el jugador pide su dinero.
El reglamento de la UE dice lo mismo desde el otro lado. El Reglamento (UE) 2024/1624, la norma contra el blanqueo de capitales del paquete de 2024 que se aplica directamente desde el 10 de julio de 2027, exige en el artículo 23 que la verificación de la identidad del cliente y del titular real se realice antes del establecimiento de una relación de negocio o de la ejecución de una transacción ocasional. La excepción del mismo artículo permite completarla durante el establecimiento solo cuando sea necesario para no interrumpir el desarrollo normal del negocio y exista poco riesgo de blanqueo de capitales o financiación del terrorismo, y obliga a completar esos procedimientos lo antes posible tras el contacto inicial. Es una excepción estrecha con una condición documentada, no una licencia general para terminar más tarde.
Un diseño que aparca la comprobación en el paso de retirada hace por tanto dos cosas malas a la vez. Debilita la evidencia de la propia plataforma, porque el historial de la cuenta lo construyó una persona cuya identidad el operador nunca estableció; y convierte un paso de alta en un incidente de experiencia de cliente en el momento más sensible de la relación.
Trate los umbrales como configuración versionada
Los requisitos de edad e identidad rara vez son reglas de «siempre». Son reglas de umbral y disparador que se mueven según un calendario. Según el reglamento contra el blanqueo, los proveedores de servicios de juego deben aplicar la diligencia debida no solo al establecer una relación, sino también al cobrar ganancias, al apostar un importe o en ambos casos, cuando realicen transacciones de al menos 2 000 EUR o su equivalente, ya sea en una sola operación o mediante transacciones vinculadas. El artículo 19(9) exige después que la autoridad de la UE contra el blanqueo de capitales elabore proyectos de normas técnicas de regulación que especifiquen valores inferiores para entidades y transacciones de mayor riesgo, los valores de transacción correspondientes, los criterios para identificar transacciones ocasionales y relaciones de negocio, y los criterios para identificar transacciones vinculadas. Esos criterios deciden si dos apuestas de una misma persona son una transacción o dos, lo que es una cuestión de modelado de datos antes de ser una cuestión de cumplimiento.
Las normas técnicas de Gran Bretaña se mueven con su propio calendario. Las normas técnicas de juego a distancia y software de la Gambling Commission incluyen un cambio con efecto desde el 30 de septiembre de 2026 en la RTS 12B, la norma de límites financieros, incluido el requisito de que el sistema de juego impida al cliente seguir depositando una vez alcanzado un límite de depósito hasta que se reinicie el periodo definido o el cliente realice la acción para aumentarlo, sujeto al periodo estándar de reflexión de 24 horas.
La lección de diseño no es qué número es correcto este mes. Es que los umbrales, los eventos disparadores, las ventanas de vinculación y los periodos de reflexión pertenecen a una configuración versionada con un registro de qué versión estaba activa cuando se tomó una decisión concreta. Una plataforma que publica umbrales como constantes vuelve a lanzar software cada vez que un regulador mueve un valor, y no puede decir después qué reglas gobernaron una decisión tomada tres años antes.
Acepte las credenciales que exigirán sus mercados
Europa está construyendo una capa de identidad basada en carteras, y la obligación de aceptación lleva fecha. El Reglamento (UE) 2024/1183 exige, en el artículo 5a, que cada Estado miembro proporcione al menos una Cartera Europea de Identidad Digital en los 24 meses siguientes a la entrada en vigor de los actos de ejecución, con nivel de garantía alto y capacidad de divulgación selectiva, de modo que una cartera pueda presentar un hecho sin presentar el documento del que procede. El artículo 5f(2) exige que las partes usuarias privadas, salvo las microempresas y pequeñas empresas según la recomendación citada, que estén obligadas por el Derecho de la Unión o nacional, o por obligación contractual, a utilizar autenticación fuerte de usuario para la identificación en línea, acepten también esas carteras, a más tardar 36 meses después de la entrada en vigor de esos actos de ejecución y solo a petición voluntaria del usuario. Los ámbitos que ese artículo enumera como ejemplos son transporte, energía, banca, servicios financieros, seguridad social, salud, agua potable, servicios postales, infraestructura digital, educación y telecomunicaciones. El juego no figura ahí, así que la posición de un operador depende de si una norma o un contrato que le vincula exige autenticación fuerte de usuario, y esa es una pregunta que se responde por mercado y no por suposición.
Dos propiedades del marco condicionan la integración más que la fecha. El artículo 5a(15) establece que el uso de las carteras es voluntario y que el acceso a servicios públicos y privados no debe restringirse ni resultar desventajoso para quien no las use, lo que significa que la vía documental existente no puede retirarse como si fuera una comodidad. Y el artículo 5a(4) exige divulgación selectiva, de modo que la solicitud que envía la plataforma debería pedir un predicado sobre la edad y no una fecha de nacimiento, y debería pedir atributos de identidad solo cuando una obligación los necesite de verdad. Una caja que exige un conjunto completo de atributos cuando la obligación es un umbral de edad ha construido una integración de cartera más difícil de defender ante una revisión de protección de datos y peor para el jugador.
El Reino Unido ha tomado una ruta distinta hacia el mismo destino, y su mecanismo es instructivo porque es explícitamente condicional. La Licensing Act 2003 (Mandatory Licensing Conditions) (Amendment) Order 2026 permite que los locales autorizados de Inglaterra y Gales acepten identificación digital para las comprobaciones de edad, pero solo cuando la persona responsable esté cubierta por un acuerdo con un proveedor registrado en el registro legal de servicios de verificación digital, el proveedor confirme si se ha alcanzado el umbral de edad y la identificación entregada alcance al menos un nivel de confianza medio según la versión correspondiente del marco de confianza. El material explicativo publicado es explícito en que una simple inspección visual de un documento digital no es suficiente. Esa es la forma de una comprobación de edad apta para cumplimiento: un verificador registrado, un nivel de confianza declarado y un servicio que responde directamente a la pregunta de la edad en lugar de entregar una imagen.
Conserve la evidencia, no solo la decisión
Las decisiones de verificación envejecen mal cuando no se conserva la evidencia que las sustenta. El artículo 77(1)(a) del reglamento contra el blanqueo exige que los sujetos obligados conserven una copia de los documentos y la información obtenidos al aplicar la diligencia debida, incluida la información obtenida mediante medios de identificación electrónica, y que garanticen que los registros conservados no estén censurados. El artículo 77(2) permite conservar referencias a esa información en lugar de copias, pero solo cuando la naturaleza y el método de conservación permitan facilitar la información de inmediato a las autoridades competentes y la información no pueda modificarse ni alterarse, y solo cuando las categorías en las que se aplica esa sustitución estén definidas en los procedimientos internos de la propia entidad. El artículo 77(3) fija un periodo de conservación de cinco años desde la terminación de la relación de negocio, la transacción ocasional o la negativa, exige suprimir los datos personales cuando ese periodo expire y permite una prórroga caso por caso de hasta cinco años más cuando una autoridad competente la necesite.
Eso es una especificación y no una instrucción general de conservarlo todo. La plataforma tiene que almacenar la evidencia de verificación en una forma que un revisor pueda usar, probar que no se ha alterado, facilitarla de inmediato cuando conservó una referencia en lugar de una copia y suprimirla según un reloj definido sin borrar registros que otra obligación exige. La conservación es también donde el sistema de identidad se encuentra con el paquete de control de registro de seguridad y evidencia de auditoría, porque una regla de conservación que nada aplica es una exposición de protección de datos y no un control.
Vuelva a verificar por cambio, no por calendario
La condición 17.1.1 exige que los titulares adopten medidas razonables para asegurar que la información que conservan sobre la identidad de un cliente siga siendo exacta. El reglamento contra el blanqueo activa nueva diligencia debida cuando existen dudas sobre la veracidad o la suficiencia de los datos de identificación obtenidos previamente, y cuando existen dudas sobre si la persona con la que interactúa la entidad es el cliente o una persona autorizada para actuar por él.
De ahí se derivan tres disparadores prácticos. Un evento de cambio relevante —un cambio de nombre, una dirección nueva, un instrumento de pago a otro nombre— debería abrir una tarea de reverificación en lugar de sobrescribir en silencio el registro establecido. Una sesión que se comporta como una persona distinta debería tratarse como una nueva pregunta de autenticación, con el camino de toma de control de cuenta que define el plan de respuesta a incidentes para compromisos confirmados. Y el fraude de identidad debe presumirse al menos tan bien dotado como la plataforma: la evaluación de 2026 de la Gambling Commission sobre los riesgos de blanqueo de capitales y financiación del terrorismo en la industria británica del juego, publicada el 30 de julio de 2026, señala que el rápido desarrollo de la capacidad de inteligencia artificial pone a prueba la eficacia de los controles de diligencia debida, y califica el sector de casino como alto en relación con otros subsectores del juego aunque la evaluación nacional de riesgos califique los casinos como medios en el conjunto de sectores regulados.
Pruebe los fallos, no solo el camino feliz
La aceptación de un sistema de edad e identidad debería ser una lista de contradicciones, cada una con un estado esperado de la plataforma, un comportamiento visible esperado para el jugador y un registro esperado. Empiece por un solicitante cuyo documento caduca entre la captura y la comprobación, y otro cuya dirección ha cambiado desde que se emitió el documento. Continúe con un nombre que no coincide con los datos de referencia y otro que coincide solo de forma aproximada. Después las rutas de credencial: una cartera que devuelve un predicado de edad sin ningún atributo de identidad, un usuario de cartera que rechaza el atributo y sigue navegando, y un usuario que presenta una segunda cartera después de que se revocara la primera. Y después las contradicciones de la propia plataforma: la misma identidad presentada contra una segunda cuenta, un proveedor de verificación que expira después de aceptar la solicitud, un registro de identidad editado después de completarse la verificación, un retiro intentado en una cuenta cuya verificación se aplazó y un reloj de conservación que expira mientras una revisión sigue abierta.
Cada prueba debería indicar el estado que la plataforma debe alcanzar, la evidencia que debe dejar y la persona responsable de la clase de excepción. Un control de verificación que nunca se ha forzado a un estado contradictorio no se ha probado; solo se ha usado.
Para operadores y proveedores que especifican la acreditación de edad y la verificación de identidad, la certificación y cumplimiento de Wizards convierte este paquete de control en requisitos de plataforma, de proveedor y de aceptación.
Preguntas frecuentes
¿Es lo mismo la verificación de edad que la verificación de identidad en una plataforma de iGaming?
No. En Gran Bretaña, el código de responsabilidad social a distancia 3.2.11 exige verificar la edad antes de que un cliente pueda depositar, acceder a una versión gratuita de un juego de azar o jugar, mientras que la condición de licencia 17.1.1 exige obtener y verificar el nombre, la dirección y la fecha de nacimiento antes de permitirle jugar. Una es un umbral sobre la edad; la otra es un registro de identidad, y la evidencia que satisface una no satisface automáticamente la otra.
¿Cuándo debe un operador a distancia verificar la identidad de un cliente?
Antes de permitirle jugar, según la condición de licencia 17.1.1, y esa misma condición dice que una solicitud de retirada no debe convertirse en la primera vez que se exige información adicional si podría haberse pedido razonablemente antes. El Reglamento (UE) 2024/1624 mantiene la misma posición en los mercados que cubre: la verificación se realiza antes de establecer la relación de negocio o de ejecutar la transacción ocasional, con solo una excepción estrecha y condicionada para completarla durante el establecimiento.
¿Se aplica el reglamento europeo contra el blanqueo a los operadores de juego en línea?
Sí, y añade eventos que no son eventos de alta. El Reglamento (UE) 2024/1624 se aplica directamente desde el 10 de julio de 2027, define por primera vez los servicios de juego a escala de la UE y exige a sus proveedores aplicar la diligencia debida al cobrar ganancias, al apostar un importe o en ambos casos, cuando las transacciones alcancen 2 000 EUR, ya sea en una sola operación o mediante transacciones vinculadas. Los Estados miembros pueden eximir a algunos proveedores por riesgo bajo probado, pero la exención no puede aplicarse a los casinos ni a los proveedores cuya actividad principal sea el juego en línea o las apuestas deportivas.
¿Qué debe conservar una plataforma para probar que hubo una verificación?
Según el artículo 77 del Reglamento (UE) 2024/1624, una copia de los documentos y la información obtenidos al aplicar la diligencia debida —incluida la información obtenida mediante medios de identificación electrónica— conservada sin censura, o una referencia a ella cuando las reglas de conservación permitan su presentación inmediata y la información no pueda alterarse. El periodo de conservación es de cinco años desde el fin de la relación, la transacción ocasional o la negativa, tras lo cual deben suprimirse los datos personales, con una posible prórroga caso por caso de hasta cinco años más.
¿Debería una plataforma de juego aceptar la Cartera Europea de Identidad Digital?
Solo cuando la obligación se aplique realmente, y entonces a petición voluntaria del usuario. El artículo 5f(2) del Reglamento (UE) 2024/1183 obliga a determinadas partes usuarias privadas que deben utilizar autenticación fuerte de usuario para la identificación en línea a aceptar las carteras; el juego no es uno de los sectores citados en su lista ilustrativa, así que la respuesta depende del Derecho nacional o del contrato que vincule al operador. Dos requisitos se mantienen en cualquier caso: el uso de una cartera es voluntario y quien no la use no debe verse perjudicado, y la plataforma debería solicitar un atributo de divulgación selectiva como un predicado de edad en lugar de un documento de identidad completo.
