ANEXO

Disposici髇 por la que se desarrollan las especificaciones t閏nicas de juego, trazabilidad y seguridad que deben cumplir los sistemas t閏nicos de juego de car醕ter no reservado objeto de licencias otorgadas al amparo de la Ley 13/2011, de 27 de mayo, de regulaci髇 del juego

1. Disposiciones generales

1.1 Objeto.–

Esta disposici髇 tiene por objeto el desarrollo de las especificaciones t閏nicas que deben cumplir los sistemas t閏nicos de juego de car醕ter no reservado de los operadores con licencia otorgada al amparo de la Ley 13/2011, de 27 de mayo, de regulaci髇 del juego y los mecanismos de control de los mismos.

La infraestructura t閏nica de los operadores garantizar� la supervisi髇 por parte de la Direcci髇 General de Ordenaci髇 del Juego de las operaciones de juego realizadas, la obtenci髇 de los registros generados durante su desarrollo y la generaci髇 y puesta a disposici髇 de la Direcci髇 General de Ordenaci髇 del Juego de cualquier otra informaci髇 que sea considerada relevante.

A estos efectos se establecen las especificaciones para el almacenamiento de los registros de operaciones de juego y su trazabilidad, en el formato y de conformidad con el procedimiento establecido por la Direcci髇 General de Ordenaci髇 del Juego y se detallan los requerimientos de seguridad de los sistemas de informaci髇 utilizados para el juego, tanto f韘ica como l骻ica, as� como los de organizaci髇 y gesti髇 de los mismos.

1.2 Definiciones.–

A los efectos de esta disposici髇, los t閞minos que en ella se emplean tendr醤 el sentido que se establece en el presente apartado.

1. Sistema t閏nico de juego: Se entiende por sistema t閏nico de juego al conjunto de equipos, sistemas, terminales, instrumentos y material software, as� como los procedimientos necesarios para el control de su correcto funcionamiento, empleado por el operador para la organizaci髇, explotaci髇 y desarrollo de la actividad de juego. El sistema t閏nico de juego soporta todas las operaciones necesarias para la organizaci髇, explotaci髇 y desarrollo de la actividad de juego, as� como la detecci髇 y el registro de las transacciones correspondientes entre los participantes y el operador.

Los elementos b醩icos del sistema t閏nico de juego son la unidad central de juegos y el sistema de control interno. El sistema t閏nico de juego facilitar� la informaci髇 necesaria para su control en castellano. En caso de no estar disponible en castellano, la Direcci髇 General de Ordenaci髇 del Juego podr� requerir su traducci髇, con car醕ter permanente o puntual.

2. Unidad central de juegos: La unidad central de juegos es el conjunto de elementos t閏nicos necesarios para procesar y gestionar las operaciones realizadas por los participantes en los juegos. Forman parte de la unidad central de juegos, la plataforma de juegos y el software de juegos.

3. Plataforma de juego: La plataforma de juego es la infraestructura de software y hardware que constituye la interfaz principal entre el participante y el operador de juego y que ofrece al participante las herramientas necesarias para abrir y cerrar su cuenta, grabar y editar la informaci髇 de su perfil, depositar o retirar fondos de su cuenta de juego, visualizar el detalle de los movimientos en su cuenta o un resumen de los mismos.

La plataforma de juego incluye cualquier sitio web que muestre informaci髇 relevante al participante sobre los juegos ofrecidos por el operador, as� como cualquier software cliente que el participante tenga que descargarse para poder interactuar con la plataforma.

La plataforma de juego permite al operador gestionar las cuentas de juego de los participantes, as� como las transacciones financieras de juego, informar sobre los resultados de los juegos, habilitar o deshabilitar registros y cuentas y establecer todos los par醡etros configurables.

Forman parte de la plataforma de juego los siguientes componentes:

• • Las bases de datos que recogen los datos de car醕ter personal de los participantes en los juegos, los relativos a la totalidad de las transacciones realizadas por los participantes y la informaci髇 relativa a resultados de eventos o acontecimientos deportivos, coeficientes, etc.
• • Las pasarelas de pagos que permiten realizar las transacciones econ髆icas entre el participante y el operador de juego y que contienen la l骻ica necesaria para transferir fondos desde el medio de pago empleado por el participante al operador y desde 閟te al participante.

La plataforma de juego deber� cumplir con los requisitos t閏nicos que se establecen en esta disposici髇.

4. Software de juego: Se entiende por software de juego cada uno de los m骴ulos o componentes software que permiten gestionar cada uno de los juegos, autorizar e implementar las reglas de cada uno de ellos y a los que se accede desde la plataforma de juego.

5. Generador de n鷐eros aleatorios: El generador de n鷐eros aleatorios, tambi閚 conocido por sus siglas GNA, es el componente software o hardware que, mediante procedimientos que garantizan su aleatoriedad, generan los resultados num閞icos que son empleados por el operador para la determinaci髇 de los resultados de cada uno de los juegos en los que se utiliza.

Mediante un proceso denominado escalamiento, se convertir� el resultado bruto obtenido por el generador de n鷐eros aleatorios en un valor dentro del rango de valores que admita cada juego (52 valores de cartas, n n鷐eros de bingo). Estos n鷐eros, mediante el proceso de traslaci髇 o mapeado, se convierten a los s韒bolos que utiliza el juego (naipes, bolas, etc.).

6. Sistema de control interno: El sistema de control interno o SCI, es el conjunto de componentes destinados a registrar las transacciones realizadas en el desarrollo de los juegos al objeto de garantizar a la Direcci髇 General de Ordenaci髇 del Juego la posibilidad de mantener un control permanente sobre las actividades de juego del operador.

El sistema de control interno estar� formado por el capturador y la base de datos segura o almac閚 de operaciones de juego.

7. Capturador: El capturador es el componente del sistema de control interno del operador destinado a la captura y registro de los datos de monitorizaci髇 y control establecidos por la Direcci髇 General de Ordenaci髇 del Juego, su traducci髇 y su almacenamiento en el dispositivo denominado almac閚 de operaciones de juego.

8. La base de datos segura o almac閚 de operaciones de juego: La base de datos segura o almac閚 de operaciones de juego (en adelante, almac閚) es el dispositivo ubicado en Espa馻 que contiene los datos de monitorizaci髇 y control introducidos por el capturador y al que en todo momento puede acceder la Direcci髇 General de Ordenaci髇 del Juego. La informaci髇 extra韉a del sistema de juego por el capturador deber� almacenarse, con el formato y estructura establecido por la Direcci髇 General de Ordenaci髇 del Juego.

9. Registro de usuario: Se entiende por registro de usuario al registro 鷑ico que permite al participante acceder a las actividades de juego de un determinado operador y en la que se recogen, entre otros, los datos que permiten la identificaci髇 del participante y los que posibilitan la realizaci髇 de transacciones econ髆icas entre 閟te y el operador de juego.

10. Cuenta de juego: Se entiende por cuenta de juego a la cuenta abierta por el participante, de forma vinculada a su registro de usuario, en la que se cargan los ingresos de las cantidades econ髆icas destinadas por 閟te al pago de la participaci髇 en las actividades de juego y se abonan los importes de los premios obtenidos por la participaci髇.

11. Juego ofertado en un entorno de liquidez internacional: aquel en el que las cantidades econ髆icas que se dedican a la participaci髇 en el juego provienen de jugadores con registro de usuario espa駉l y de jugadores sin registro de usuario espa駉l.

12. Gestor de liquidez internacional: el operador que gestiona un juego ofertado en un entorno de liquidez internacional.

13. Jugador con registro de usuario espa駉l: aquel que participa en el juego mediante una cuenta abierta en un operador de juego, de acuerdo con la Ley 13/2011, de 27 de mayo, de regulaci髇 del juego.

2. Registro de usuario, cuenta de juego y medios de pago

2.1 Registro de usuario y limitaci髇 en la participaci髇.–

Los requisitos en relaci髇 con la identificaci髇 de los participantes en los juegos y el control de las prohibiciones subjetivas a la participaci髇 se establecen en los art韈ulos 26 y 27 del Real Decreto 1613/2011 y se desarrollan en la correspondiente Resoluci髇 de 12 de julio, de la Direcci髇 General de Ordenaci髇 del Juego.

En esta resoluci髇 se desarrolla el contenido m韓imo del registro de usuario, as� como los controles internos que el operador ha de establecer.

2.1.1 Contenido m韓imo del registro de usuario. La identificaci髇 de los participantes se realizar� a trav閟 de un registro de usuario que deber� contener, al menos, los siguientes datos:

• – Datos de identificaci髇:
  • • Para residentes, n鷐ero de identificaci髇 fiscal (NIF) o n鷐ero de identificaci髇 de extranjeros (NIE). En ambos casos, el n鷐ero deber� almacenarse en un formato normalizado.
  • • Para no residentes, un documento equivalente: documento de identidad, tarjeta de la seguridad social, pasaporte, permiso de conducir.
  • • Nombre y apellidos.
• – Datos personales:
  • • Fecha de nacimiento.
  • • Sexo.
  • • Domicilio.
  • • Para los no residentes, pa韘 de residencia.
  • • Nacionalidad.
  • • Email.
  • • Tel閒ono.
• – Datos de residencia fiscal:
  • • C骴igo de residencia fiscal del participante, de acuerdo con lo dispuesto en el modelo 763 de autoliquidaci髇 del Impuesto sobre actividades de juego, aprobado en Orden EHA/1881/2011, de 5 de julio.
  • • Para no residentes ser� necesario que el participante aporte una copia del documento utilizado para su identificaci髇.

2.1.2 Conservaci髇 de copia de los documentos aportados. El operador establecer� los procedimientos t閏nicos necesarios para la conservaci髇 de la copia digital de los documentos aportados por los participantes.

2.1.3 Contrato de juego. El operador conservar� el registro de la aceptaci髇 del contrato de juego y de sus eventuales modificaciones.

2.1.4 Servicios de verificaci髇 ofrecidos por la Direcci髇 General de Ordenaci髇 del Juego. La Direcci髇 General de Ordenaci髇 del Juego proporciona a los operadores un servicio online de verificaci髇 de los datos de identidad y fecha de nacimiento para participantes residentes en Espa馻: el servicio de verificaci髇 se basa en el NIF/NIE del participante.

El operador registrar� y conservar� cuantas consultas realice al sistema de verificaci髇 de identidad, dejando constancia de la fecha, hora y minuto de la consulta. Los datos deber醤 ser conservados, junto con los correspondientes al registro de usuario, durante el per韔do de vigencia del registro de usuario y durante los seis a駉s siguientes a su cancelaci髇 o anulaci髇.

La Direcci髇 General de Ordenaci髇 del Juego proporciona a los operadores dos servicios online de verificaci髇 para la inscripci髇 de los participantes en el Registro General de Interdicciones de Acceso al Juego:

• • Un servicio de verificaci髇 de la inscripci髇 de un participante en el Registro General de Interdicciones de Acceso al Juego para participantes residentes en Espa馻 a partir de NIF/NIE. Los operadores deber醤 utilizar este servicio para comprobar la inscripci髇 en el proceso de registro de usuario.
• • Un servicio de consulta de las variaciones (altas/bajas) en la inscripci髇 en el Registro General de Interdicciones de Acceso al Juego, correspondientes a los participantes que previamente hubiera verificado el operador. Los operadores deber醤 utilizar este servicio cada hora para verificar las variaciones en la inscripci髇 en el Registro General de Interdicciones de Acceso al Juego de sus participantes.

El operador registrar� y conservar� cuantas consultas realice al Registro General de Interdicciones de Acceso al Juego, dejando constancia de la fecha, hora y minuto de la consulta. Los datos deber醤 ser conservados, junto con los correspondientes al registro de usuario, durante el per韔do de vigencia del registro de usuario y durante los seis a駉s siguientes a su cancelaci髇 o anulaci髇.

2.1.5 Activaci髇 del registro de usuario y limitaci髇 en la participaci髇. El operador dispondr� de un procedimiento documentado de registro y activaci髇 de usuario que recoger� los requisitos de identificaci髇 y limitaci髇 de la participaci髇 establecidos en los art韈ulos 26 y 27 del Real Decreto 1613/2011, de 14 de noviembre, por el que se desarrolla la Ley 13/2011, de 27 de mayo, de regulaci髇 del juego, en lo relativo a los requisitos t閏nicos de las actividades de juego.

El operador es el responsable de la veracidad de los datos que figuren en sus registros de usuario y de la correcta identificaci髇 de los participantes en los juegos que organicen o desarrollen. Asimismo, el operador deber� contar con un servicio de verificaci髇 de los datos de identidad y fecha de nacimiento suficiente para determinar la veracidad del registro. Este servicio podr� ser prestado por terceros que presten servicios profesionales de verificaci髇 de identidad.

Los operadores deber醤 registrar y conservar la totalidad de las gestiones, consultas y requerimientos que hubieran realizado para la verificaci髇 de los datos aportados por los solicitantes, as� como cuantos documentos hubieran recibido o empleado con este fin. Los datos deber醤 ser conservados, junto con los correspondientes al registro de usuario, durante el per韔do de vigencia del registro de usuario y durante los seis a駉s siguientes a su cancelaci髇 o anulaci髇.

2.1.6 Revisi髇 peri骴ica de los registros de usuario. El operador establecer� un procedimiento t閏nico, que permita la revisi髇 peri骴ica de los registros de usuario en los t閞minos establecidos en el art韈ulo 26.3 del Real Decreto 1613/2011, de 14 de noviembre, por el que se desarrolla la Ley 13/2011, de 27 de mayo, de regulaci髇 del juego, en lo relativo a los requisitos t閏nicos de las actividades de juego.

2.1.7 Cancelaci髇 del registro de usuario. El operador conservar� los datos de los registros de usuario cancelados. En el registro se detallar� el momento de cancelaci髇 y el motivo.

2.1.8 Suspensi髇 por inactividad. El operador mantendr� un registro de los registros de usuario suspendidos por inactividad en el que se incluir� la fecha de suspensi髇.

2.1.9 Suspensi髇 cautelar del registro de usuario. El operador podr� suspender cautelarmente al participante que haya tenido, a su juicio, un comportamiento colusorio o fraudulento o que haya permitido la utilizaci髇 de su registro de usuario por terceros, hasta que se demuestren los hechos.

2.1.9.1 Medidas de prevenci髇 del fraude y del blanqueo de capitales. El operador dispondr� de procedimientos para la detecci髇 de fraude y el blanqueo de capitales. Los procedimientos incluir醤 la pronta notificaci髇 de las acciones sospechosas a los organismos p鷅licos competentes para su investigaci髇.

En los juegos de apuestas en directo, el operador dispondr� de medidas para mitigar el riesgo de que algunos jugadores pudieran obtener ventajas sobre otros jugadores al apostar con informaci髇 sobre un resultado cierto o tras un suceso que altere de manera fundamental las probabilidades de la apuesta.

2.1.9.2 Registro y comunicaci髇 en relaci髇 a la suspensi髇 cautelar del registro de usuario. El operador mantendr� un registro de usuarios suspendidos. El registro incluir� la fecha y el motivo de la suspensi髇.

La DGOJ establecer� un procedimiento telem醫ico a trav閟 de la sede electr髇ica a efectos de que los operadores informen mensualmente sobre las cuentas bloqueadas o suspendidas.

2.1.10 Registro de usuario activo 鷑ico. El operador establecer� los procedimientos y mecanismos necesarios para garantizar el requisito de registro de usuario activo 鷑ico por participante del art韈ulo 26.2 del Real Decreto 1613/2011, de 14 de noviembre, por el que se desarrolla la Ley 13/2011, de 27 de mayo, de regulaci髇 del juego, en lo relativo a los requisitos t閏nicos de las actividades de juego.

2.1.11 Identificaci髇 para el acceso. Una vez se haya completado el proceso de registro se asignar� al participante un identificador 鷑ico de usuario. Los accesos al registro de usuario y a la cuenta de juego deben estar reservados en exclusiva al participante titular del registro.

2.1.12 Autenticaci髇 del usuario y pol韙ica de contrase馻s. El acceso al registro de usuario deber� contar con mecanismos de seguridad para autenticar al usuario en la plataforma.

La autenticaci髇 del usuario podr� realizarse mediante la utilizaci髇 de contrase馻s. La pol韙ica de contrase馻s deber� contemplar, al menos, los siguientes requisitos m韓imos:

• • Deber� establecerse, por defecto o por el participante, una contrase馻 inicial de usuario.
• • Durante el proceso de definici髇 de la contrase馻 de usuario, el participante deber� ser informado sobre buenas pr醕ticas en la elecci髇 de contrase馻s seguras.
• • La longitud m韓ima de la contrase馻 ser� de ocho caracteres o d韌itos, e incluir� al menos elementos de tres de los siguientes grupos: n鷐eros, letras min鷖culas, letras may鷖culas y otros s韒bolos.
• • La contrase馻 no podr� contener ninguno de los siguientes datos: el nombre de usuario, el seud髇imo, el nombre o apellidos o la fecha de nacimiento del participante.
• • Deber� ofrecerse al usuario un recordatorio de cambio de contrase馻 con una frecuencia m韓ima anual, aunque no es obligatorio que el usuario realice el cambio.
• • El mecanismo de identificaci髇 mediante usuario y contrase馻 deber� bloquearse si se producen en un mismo d韆 m醩 de cinco intentos de acceso err髇eos. El operador podr� establecer un l韒ite inferior a este requisito.

El sistema del operador estar� dise馻do para requerir la autenticaci髇 del participante ante cada inicio de sesi髇 de usuario, y en el caso de uso de contrase馻s, la introducci髇 de la contrase馻. El sistema no utilizar� cookies u otros mecanismos para evitar la autenticaci髇 del usuario o la introducci髇 de la contrase馻.

El operador podr� proporcionar otros m閠odos de autenticaci髇 del usuario siempre que ofrezcan un nivel de seguridad mayor que el de la contrase馻.

El sistema conservar� registro de todos los intentos de acceso, ya sean con o sin 閤ito, para su posterior auditor韆.

El operador dispondr� de un procedimiento documentado de seguridad de acceso del usuario en el que se describir�:

• • El modo en que se protege el registro de usuario de accesos no autorizados.
• • La existencia o no de un medio indirecto, o asistido por personal del operador, de acceder al registro de usuario, previa superaci髇 de preguntas antes de conceder el acceso o renovarlo.
• • El tratamiento de identificadores de usuario o contrase馻s perdidos.
• • El operador dispondr� de un procedimiento para detectar las cuentas inactivas durante un tiempo razonablemente prolongado y requerir� un nivel de autenticaci髇 superior al normal o verificaciones adicionales a trav閟 del servicio de atenci髇 al cliente, antes de permitir reanudar la actividad de juego, especialmente las retiradas de fondos. El umbral de tiempo de inactividad para solicitar un nivel de autenticaci髇 o verificaci髇 adicional definido por el operador no podr� ser superior a seis meses.
• • Asimismo, el operador dispondr� de un procedimiento para detectar dentro de lo razonable accesos no autorizados a la cuenta de los participantes, intentos de suplantaci髇 de identidad o acceso a sus datos personales.
• • Adicionalmente, el operador dispondr� de un procedimiento para detectar cambios bruscos en el comportamiento de un participante, y en particular del importe de los dep髎itos o retiradas, e iniciar� alguna acci髇 para prevenir que la cuenta de juego pueda estar siendo accedida por un tercero.

2.1.13 Informaci髇 al participante sobre su 鷏tima conexi髇. Una vez autenticado el usuario, el sistema le mostrar� la fecha y hora de su 鷏timo acceso.

2.1.14 Registro de la configuraci髇 de la sesi髇 destinada al juego de m醧uinas de azar. En el caso de las m醧uinas de azar, los operadores deber醤 registrar y conservar los datos relativos a la configuraci髇 por parte del usuario de cada una de sus sesiones destinadas al juego de m醧uinas de azar, seg鷑 lo establecido en el art韈ulo 14 de la Orden HAP/1370/2014, de 25 de julio, por la que se aprueba la reglamentaci髇 b醩ica del juego de m醧uinas de azar.

2.2 Cuenta de juego y dep髎itos de los participantes.

2.2.1 Funcionalidad de la cuenta de juego. Cuando el operador gestione fondos depositados por los participantes deber� utilizar una cuenta de juego para mantener el registro contable de las operaciones.

Cada registro de usuario tendr� vinculada una o varias cuentas de juego. De las cuentas vinculadas al mismo registro de usuario, al menos una permitir� el dep髎ito y la retirada de fondos. La transferencia de fondos entre las diferentes cuentas de juego vinculadas al mismo registro de usuario ser� inmediata y gratuita para el participante. Cada cuenta de juego permitir� abonar la participaci髇 en uno, varios o todos los juegos ofrecidos en la plataforma.

En la cuenta de juego se reflejar醤 todas las transacciones que supongan una alteraci髇 del saldo del participante, tales como los dep髎itos realizados por el participante, los cargos por el importe de la participaci髇 en los juegos y por los servicios adicionales que pudiera prestar el operador, los abonos por los bonos ofrecidos por el operador y los premios obtenidos por el participante.

La cuenta de juego estar� denominada en euros.

Las correcciones, anulaciones o ajustes se reflejar醤 en apuntes independientes, sin que, en ning鷑 caso, se pueda borrar la transacci髇 original corregida, anulada o ajustada.

Deber醤 registrarse las apuestas que una vez formalizadas hayan sido anuladas por parte del operador, indic醤dose de forma clara el motivo de su anulaci髇.

Los apuntes contables en la cuenta de juego permitir醤 conocer de forma clara la naturaleza de la transacci髇 y el momento en que se realiza.

2.2.2 Procedimiento de control de los dep髎itos de los participantes. Las obligaciones del operador en relaci髇 con los fondos de los participantes son las establecidas en el art韈ulo 39 del Real Decreto 1614/2011, de 14 de noviembre, por el que se desarrolla la Ley 13/2011, de 27 de mayo, de regulaci髇 del juego, en lo relativo a licencias, autorizaciones y registros del juego, y se deben complementar con la existencia de un procedimiento que permita garantizar su correcto funcionamiento que al menos incluya lo siguientes controles:

• • Existir� un libro registro que se cumplimentar� con periodicidad m韓ima semanal en el que se comprobar� y anotar� el saldo de los fondos depositados por los participantes en las cuentas de juego usuario, el saldo de cada una de las cuentas corrientes bancarias en Espa馻 a que hace referencia el art韈ulo 39 del Real Decreto 1614/2011, la fecha y hora en que se ha realizado la comprobaci髇. y la firma de una persona designada por el operador.
• • En el caso de que el saldo de los fondos depositados por los participantes sea inferior al de las cuentas corrientes bancarias, se tomar醤 inmediatamente las medidas para incrementar el saldo de las cuentas corrientes bancarias y se repetir� la comprobaci髇 y anotaci髇 en el libro registro el d韆 siguiente h醔il.

2.2.3 Historial. El participante dispondr� en tiempo real del saldo de la cuenta de juego y del registro de todas las participaciones o jugadas efectuadas, al menos, en los 鷏timos treinta d韆s.

El participante, podr� consultar en tiempo real un resumen, al menos por a駉 natural, de los movimientos en su cuenta de juego que incluya: el saldo inicial, la suma de los dep髎itos realizados, la suma de las retiradas realizadas, la suma de los cargos por el importe de la participaci髇 en los juegos y por los servicios adicionales que pudiera prestar el operador, la suma de los abonos por los eventuales bonos aceptados por el participante y por los premios obtenidos, y el saldo final.

El sistema estar� dise馻do para poder emitir en tiempo real y previa solicitud del participante un documento que incluya la informaci髇 descrita en el p醨rafo anterior y en el que consten los datos de identificaci髇 del operador y del participante. El operador dispondr� de un procedimiento que permita a aquellos usuarios que no dispongan de cuenta de juego activa en el operador en el momento de la consulta, obtener dicha informaci髇 a trav閟 de los canales de atenci髇 a los usuarios del operador. Ante esta solicitud del participante, una vez realizadas las comprobaciones de identidad necesarias, el operador deber� poner a disposici髇 del usuario el documento solicitado en el plazo m醲imo de diez d韆s.

2.2.4 Unidades de la cuenta de juego. De conformidad con lo dispuesto en el art韈ulo 35.2 del Real Decreto 1614/2011, de 14 de noviembre, por el que se desarrolla la Ley 13/2011, de 27 de mayo, de regulaci髇 del juego, en lo relativo a licencias, autorizaciones y registros del juego, la unidad monetaria de la cuenta de juego es el euro.

El operador puede emplear otras unidades como puntos de bonificaci髇 (玝onus�), puntos para pagar entrada en torneos u otros. La plataforma registrar� el saldo y los movimientos expresados en cada una de las unidades.

2.2.5 Prohibici髇 de transferencias entre participantes. El operador establecer� los procedimientos t閏nicos necesarios que impidan las transferencias entre cuentas de juego asociadas a diferentes registros de usuario.

2.2.6 Ofertas promocionales. Si las condiciones de las ofertas promocionales establecieran una cantidad a acumular, por ejemplo de puntos, el participante deber� poder consultar los puntos que ha acumulado o los que le restan para cumplir las condiciones.

2.2.7 Cuentas asociadas a registros de usuario en estado diferente a activo. Los registros de usuario en estado diferente a activo tienen restringida en todo o en parte su operativa en la plataforma. El operador deber� disponer de un procedimiento documentado de controles t閏nicos y revisiones para garantizar que las cuentas de juego asociadas a registros de usuario en estado diferente a activo no realizan movimientos indebidos.

2.2.8 L韒ites de dep髎ito. El operador mantendr� un registro con las modificaciones en los l韒ites de dep髎ito detallada por registro de usuario. El registro incluir� la fecha y el motivo de la modificaci髇. Deber� quedar registrado si la modificaci髇 fue solicitada por el jugador o establecida por el operador.

Asimismo, el operador deber� conservar las pruebas de prevenci髇 de conductas adictivas del juego y de juego responsable superados por el jugador, necesarios para solicitar el incremento de los importes de dep髎ito o la desaparici髇 de cualquier l韒ite que tenga establecido para su cuenta de dep髎ito, as� como el an醠isis hist髍ico de la trayectoria del participante, en los supuestos de segunda petici髇 o ulteriores peticiones de aumento de l韒ites que realice un mismo participante.

2.2.9 Saldo acreedor. Sin perjuicio de otras limitaciones a la participaci髇, si no existe suficiente saldo disponible en la cuenta de juego en el momento en que el jugador desee realizar una participaci髇 en el juego o una apuesta, la participaci髇 en el juego deber� ser rechazada.

En consecuencia, ninguna cuenta de juego puede presentar saldo acreedor como consecuencia de haberse permitido la participaci髇 en el juego sin existir saldo suficiente.

2.3 Medios de pago y cobro.

2.3.1 Registro de las operaciones de pago y cobro. El operador deber� conservar o estar en disposici髇 de obtener el apunte detallado de cada operaci髇 de dep髎ito o retirada junto con toda la informaci髇 asociada a cada operaci髇, independientemente de que utilice medios propios o de terceros.

Cuando se utilicen servicios de tarificaci髇 adicional, el operador deber� conservar la informaci髇 relativa al importe de participaci髇 y al identificador de juego o concurso en que el que tuvo lugar la participaci髇, y estar en disposici髇 de obtener el n鷐ero de tel閒ono y la cuenta utilizados para facturar la participaci髇 al jugador.

2.3.2 Retirada de fondos. El operador establecer� un procedimiento para ordenar al medio de pago que corresponda la transferencia de fondos en un plazo m醲imo de 24 horas. Este procedimiento deber� prever que en caso excepcional de no de no cumplirse el plazo referido deber� ser previamente notificado a la Direcci髇 General de Ordenaci髇 del Juego.

2.3.3 Procedimiento de control de las operaciones de pago y cobro. El operador implantar� un procedimiento de contraste de las operaciones de pago y cobro respecto a los apuntes en la cuenta de juego o en el software de juego, que incluir� al menos:

• • Las cuentas de juego asociadas a registros de usuario en estado diferente a activo no realizan movimientos indebidos.
• • La verificaci髇 de que los importes de dep髎itos y retiradas se corresponden con los importes de operaciones realizadas a trav閟 de los medios de pago.
• • La verificaci髇 de que no existen dep髎itos realizados por los participantes por encima de los l韒ites de dep髎ito que tuviera fijados cada uno de ellos.
• • La verificaci髇 de que las retiradas se ordenan en un plazo m醲imo de 24 horas, a excepci髇 de las causas previstas excepcionalmente y que hubieran sido previamente notificadas a la Direcci髇 General de Ordenaci髇 del Juego.

El procedimiento se ejecutar� con periodicidad m韓ima mensual.

2.4 Protecci髇 de datos personales.

2.4.1 Protecci髇 de datos. Los operadores establecer醤 los procedimientos t閏nicos adecuados para mantener la privacidad de los datos de los participantes de conformidad con la Ley Org醤ica 15/1999, de 13 de diciembre, de Protecci髇 de Datos de Car醕ter Personal y su normativa complementaria.

Los operadores deber醤 asimismo implantar sobre los ficheros y tratamientos las medidas de seguridad establecidas en la normativa vigente en materia de protecci髇 de datos y dar cumplimiento al deber de secreto impuesto por dicha normativa.

2.4.2 Pol韙ica de privacidad. El operador publicar� en la plataforma de juego su pol韙ica de privacidad.

Para completar el proceso de registro de usuario, el participante deber� dar su consentimiento a la pol韙ica del operador. La plataforma registrar� la aceptaci髇 del participante y el contenido de la pol韙ica de privacidad o un enlace al texto de la misma. Cualquier modificaci髇 posterior de la pol韙ica de privacidad requerir� su comunicaci髇 al usuario y su aceptaci髇.

El operador dispondr� de un plan t閏nico y operativo para asegurar la privacidad de los datos de los usuarios.

3. Juego

3.1 Reglamentaci髇 b醩ica del juego.–

El operador ofrecer� juegos y modalidades de conformidad con sus t韙ulos habilitantes y la regulaci髇 b醩ica de cada juego.

Los operadores deber醤 implantar en su sistema de juego los procedimientos necesarios para cumplir los requisitos establecidos en la reglamentaci髇 b醩ica de cada juego y que se establece en la correspondiente Orden ministerial y, en particular, los requisitos establecidos respecto de:

• • Reglas particulares del juego.
• • Reclamaciones de los participantes.
• • Obligaciones de informaci髇 a los participantes.
• • Promoci髇 de los juegos.
• • Canales y medios de participaci髇.
• • Objetivo del juego.
• • Participaci髇 en el juego y l韒ites a la participaci髇.
• • Desarrollo del juego, determinaci髇 y asignaci髇 de los premios.
• • Formalizaci髇 de apuestas o jugadas y supuestos de anulaci髇 y aplazamiento.
• • Pago de premios.

El operador implantar� un procedimiento, que ejecutar� con periodicidad m韓ima mensual, mediante el que verificar� que su oferta de juego se adecua a los t韙ulos habilitantes que ostenta, que las modalidades y variantes dentro de cada tipo de juego son conformes a la normativa vigente en cada momento, as� como que se utilizan las versiones de software homologadas.

El operador conservar� un registro de los juegos activos en cada momento, en el que se indicar� el juego, la modalidad o variante, en su caso, el nombre comercial y la versi髇 homologada.

3.2 Redirecci髇 al dominio �.es�.–

El operador establecer� procedimientos y mecanismos para garantizar que todas las conexiones realizadas desde Espa馻 o con un registro de usuario espa駉l hacia un dominio que sea propiedad o est� controlado por el operador de juego, su matriz o sus filiales se dirijan a un sitio web con nombre de dominio bajo �.es�.

Para ello, el operador deber� implantar medidas que le permitan, en la medida de lo posible, detectar y evitar conexiones a trav閟 de tecnolog韆s de red cuyo fin sea ocultar la direcci髇 IP del jugador.

El operador deber� disponer de un procedimiento que permita contrastar la geolocalizaci髇 de la IP del jugador, con su pa韘 de residencia y, en su caso, los medios de pago utilizados, con el fin de detectar posibles fraudes por parte del jugador.

3.3 Porcentaje de retorno al participante.–

El operador determinar� para cada juego, modalidad o variante, el valor o rango de valores esperados para el porcentaje de retorno.

El operador implantar� un procedimiento que permita garantizar el correcto funcionamiento del retorno esperado al participante, mediante el que se verifique con periodicidad m韓ima mensual que el porcentaje de retorno al participante obtenido en cada uno de los juegos, modalidades o variantes, se corresponde con el valor o rangos esperados.

En los casos en que detecten desviaciones graves, el operador deber� desactivar los juegos afectados, modalidades o variantes, hasta que determine y subsane la incidencia. De confirmarse la existencia de un funcionamiento anormal, el operador notificar� a la Direcci髇 General de Ordenaci髇 del Juego, indicando la causa, el periodo temporal, los jugadores e importes afectados, as� como las medidas adoptadas.

En aquellos juegos donde el porcentaje de retorno pueda depender de par醡etros configurables en el sistema t閏nico, como por ejemplo las tablas de premios, el operador conservar� registro de cualquier cambio en dichos par醡etros.

3.4 Tablas de premios.–

Las tablas de premios, en aquellos juegos en que existan, ser醤 p鷅licas y accesibles para los participantes e incluir醤 todas las combinaciones ganadoras posibles y una descripci髇 del premio correspondiente a cada combinaci髇.

La informaci髇 del programa de premios deber� indicar claramente si los premios est醤 cuantificados en unidades de cuenta, unidad monetaria o en alguna otra unidad establecida.

La informaci髇 del programa de premios reflejar� cualquier cambio en el valor del premio que pueda producirse en el transcurso del juego. A estos efectos, ser� suficiente que el operador disponga y muestre un recuadro en un lugar destacado en la interfaz gr醘ica del juego en el que aparezcan los referidos cambios en el valor de los premios.

Cuando existan botes o multiplicadores de los premios que se muestren en las pantallas, deber� quedar especificado si el bote o el multiplicador afecta al programa de premios o no.

El operador conservar� registro de las tablas de premios de cada juego, de manera que estos cambios podr醤 ser auditados.

Las tablas de premios no podr醤 ser cambiadas durante el juego, excepto en aquellos casos en que este hecho est� previsto en las reglas particulares y el participante sea adecuadamente informado.

3.5 Generador de n鷐eros aleatorios (GNA).

3.5.1 Funcionamiento del GNA. El generador de n鷐eros aleatorios deber� cumplir, como m韓imo, los siguientes requisitos:

• – Los datos aleatorios generados deben ser estad韘ticamente independientes.
• – Los datos aleatorios deben estar uniformemente distribuidos dentro del rango establecido.
• – Los datos aleatorios deben permanecer dentro del rango establecido.
• – Los datos aleatorios generados deben ser impredecibles (su predicci髇 debe ser irrealizable por computaci髇 sin conocer el algoritmo y la semilla).
• – Las series de datos generados no deben ser reproducibles.
• – El generador de n鷐eros aleatorios ser� criptogr醘icamente fuerte.
• – Instancias diferentes de un GNA no deben sincronizarse entre s� de manera que los resultados de unos permitieran predecir los de otro.
• – Las t閏nicas de semillado/resemillado no deben permitir la realizaci髇 de predicciones sobre los resultados.
• – Los mecanismos de generaci髇 deben haber superado con 閤ito distintas pruebas estad韘ticas que demuestren su car醕ter aleatorio. El sistema t閏nico puede compartir un GNA o una instancia del mismo para uno o varios juegos si esto no afecta al comportamiento aleatorio del sistema.

3.5.2 M閠odos de escalado. Los m閠odos de escalado deben cumplir los requerimientos exigidos a los GNAs.

Los m閠odos de escalado deben ser lineales y no deben introducir ning鷑 sesgo, patr髇 o predictibilidad y deben poder someterse a pruebas estad韘ticas reconocidas.

3.5.3 GNA hardware. En el caso de utilizarse un GNA hardware deber� cumplir los mismos requisitos, adaptados a las caracter韘ticas t閏nicas del hardware y, de existir, acreditar que el personal que lo opera no puede influir en los resultados. En los supuestos de utilizaci髇 de un GNA hardware operado por personal, el operador deber� disponer de un procedimiento para minimizar los hipot閠icos riesgos que pudieran llegar a afectar a la generaci髇 de resultados.

3.5.4 Fallos en el GNA. El operador deber� implementar un sistema de monitorizaci髇 del GNA que le permita detectar sus fallos, as� como los mecanismos que deshabiliten el juego cuando se produzca un fallo en el GNA.

3.5.5 Resemillado del GNA. El operador deber� disponer de un procedimiento de resemillado del GNA.

3.6 L骻ica del juego.

3.6.1 L骻ica independiente del terminal de usuario. Todas las funciones y la l骻ica que resulten cr韙icas para la implementaci髇 de las reglas del juego y la determinaci髇 del resultado deben ser generadas por la unidad central de juegos, de manera independiente al terminal de usuario.

3.6.2 Aplicaci髇 del GNA en los juegos. El rango de valores del GNA debe ser preciso y no distorsionar el porcentaje de retorno al participante.

El m閠odo de traslaci髇 de los s韒bolos o resultados del juego no debe estar sometido a la influencia o controlado por otro factor que no sean los valores num閞icos derivados del GNA.

Los eventos de azar deben estar regidos exclusivamente por el generador de n鷐eros aleatorios y no debe existir ninguna correlaci髇 entre unas jugadas y otras. El juego no debe descartar ning鷑 evento de azar, excepto en aquellos casos en que esa circunstancia est� contemplada en las reglas del juego.

El juego no debe manipular los eventos de azar, ni manual, ni autom醫icamente, ni para mantener un porcentaje de retorno m韓imo al participante.

Cuando las reglas del juego requieran que se sortee una secuencia de eventos de azar (por ejemplo, las cartas de un mazo), los eventos de azar no ser醤 resecuenciados durante el transcurso del juego, excepto en aquellos casos en que esta circunstancia est� contemplada en las reglas del juego.

3.6.3 Controles de la l骻ica del juego. El juego debe estar dise馻do para minimizar el riesgo de manipulaci髇. Se adoptar醤 las medidas t閏nicas, organizativas y procedimentales que impidan comportamientos que supongan desviaciones de las reglas del juego.

El operador dispondr� de un procedimiento documentado que describa las medidas que aplica en su sistema para garantizar que:

• • El juego se desarrolla de acuerdo con las reglas del juego.
• • Los datos de juego se graban en el sistema.
• • Los resguardos o documentos identificativos de una apuesta o participaci髇 se protegen frente a su posible manipulaci髇.
• • El sistema controla el tiempo de comercializaci髇 de apuestas o la participaci髇. El momento en que se cierre la comercializaci髇 debe ser aquel que est� establecido en las normas que regulan el juego y en todo caso ser� anterior al final del evento que desencadena el resultado del juego.
• • El sistema controla el fondo de premios constituido.
• • El procedimiento de determinaci髇 de ganadores funciona correctamente, y no permite introducir ganadores que no cumplan las condiciones para ser premiados o dar por no ganadores a aquellos que s� las cumplen.
• • El sistema conceder� los premios a los participantes que figuren en la lista de ganadores de forma efectiva.
• • Todos los tipos de transacciones que puedan ser creadas durante la operaci髇 del juego, incluyendo las dedicadas a la gesti髇 de excepciones, cambios de par醡etros del sistema, anulaciones, acciones en modo manual, deber醤 registrarse en el sistema, junto con la correspondiente pista de auditor韆.

Cualquier modificaci髇, alteraci髇 o borrado de los datos debe dejar traza de auditor韆, especialmente cuando exista intervenci髇 manual.

3.7 Terminales de usuario y terminales f韘icos de car醕ter accesorio.

3.7.1 Terminales. Se consideran terminales al conjunto de elementos software y hardware que interact鷄n directamente con el participante.

Son terminales de usuario aquellos elementos que son proporcionados por el participante y que pueden ser elementos hardware, como el ordenador personal, el tel閒ono m髒il o smartphone, o elementos software como el sistema operativo o el navegador web.

Son terminales f韘icos de car醕ter accesorio los terminales bajo el control del operador destinados a la interacci髇 directa con el participante. Se incluyen tanto los terminales para el autoservicio del participante (quioscos u otros), como los terminales destinados a ser atendidos por personal del operador, as� como las soluciones mixtas.

3.7.1.1 Identificaci髇 de terminales. La plataforma deber� ser capaz de identificar los diferentes tipos y versiones de terminales, y se conservar� registro de los mismos. Salvo razones t閏nicas debidamente justificadas, la plataforma deber� registrar si el participante est� utilizando una soluci髇 espec韋ica proporcionada para dispositivos m髒iles.

Si el terminal est� instalado en salas de juego f韘icas, casino u otros establecimientos donde est閚 autorizados, la plataforma deber� identificar el establecimiento.

3.7.1.2 Funcionalidad del terminal. El terminal 鷑icamente se encargar� de la interacci髇 con el participante y la presentaci髇.

La l骻ica del juego o cualquier elemento de aleatoriedad deben ser realizados por la unidad central de juego de forma independiente al terminal.

Las operaciones que realice el terminal deben tener una confirmaci髇 s韓crona de la unidad central de juegos para tener la consideraci髇 de formalizadas y para extender resguardos acreditativos de apuestas o dep髎itos realizados.

Todas las transacciones realizadas a trav閟 del terminal ser醤 registradas en la unidad central de juegos y asociadas a una persona que se deber� haber autenticado previamente, bien sea un participante, o bien sea el operador, sus t閏nicos o el personal autorizado por este operador. Los registros permitir醤 identificar las transacciones realizadas desde cada terminal.

3.7.2 Terminales de usuario. A continuaci髇, se establecen los requisitos t閏nicos de aplicaci髇 a los terminales de usuario.

3.7.2.1 Instalaci髇 de componentes en el terminal de usuario. Si el uso del sistema de juego exige la instalaci髇 de cualquier componente en el equipo del participante, se deber� requerir el consentimiento expreso del participante previo a la instalaci髇.

3.7.2.2 Desventaja por la calidad de la conexi髇. El operador est� obligado a introducir en sus sistemas t閏nicos todos los medios posibles para tratar de reducir el riesgo de que ciertos clientes est閚 en desventaja frente a otros por factores t閏nicos que pueden afectar a la velocidad de la conexi髇.

El participante debe ser informado en aquellos casos en que el tiempo de respuesta pueda tener un impacto significativo sobre la probabilidad de ganar.

3.7.2.3 Informaci髇 sobre la calidad de la conexi髇. El sistema informar� al participante acerca de la no disponibilidad de comunicaci髇 con el sistema de juego tan pronto como lo detecte.

El software de juego no debe verse afectado por el mal funcionamiento de los dispositivos de los participantes finales, a excepci髇 de la puesta en funcionamiento de los procedimientos previstos para finalizar las partidas o juegos incompletos.

3.7.2.4 Funcionalidad reducida para ciertos terminales de usuario. Los terminales de usuario que disponen de una interfaz gr醘ica m醩 reducida que otros, (como por ejemplo los dispositivos m髒iles frente a los ordenadores personales) podr醤 ofrecer algunos contenidos que no puedan visualizarse completamente como en los otros terminales. La plataforma podr� ofrecer, por razones estrictamente t閏nicas derivadas de la caracter韘ticas del terminal, distinta funcionalidad en los diferentes tipos de terminales.

El participante debe ser informado de las limitaciones de informaci髇 o funcionalidad del terminal y aplicaci髇 cliente que est� utilizando, y aceptarlo de modo expreso.

El operador mitigar� los riesgos derivados de la falta de informaci髇 o de funcionalidad en un determinado terminal ofreciendo la misma informaci髇 por otros medios.

Salvo impedimentos t閏nicos debidamente justificados, todas las informaciones que deben aparecer en la interfaz deben aparecer tambi閚 en la de un terminal. Cuando no sea posible incluir todas las informaciones o enlaces en la interfaz del juego, se ofrecer醤 desde un enlace, desde un men� o desde otra aplicaci髇 del mismo terminal.

3.7.2.5 Recursos m韓imos del terminal. La plataforma no procesar� los juegos del terminal si no dispone de todos los recursos m韓imos para permitir jugar sin problemas t閏nicos y sin desventajas.

3.7.3 Terminales f韘icos de car醕ter accesorio. A continuaci髇, se establecen los requisitos t閏nicos de aplicaci髇 a los terminales f韘icos de car醕ter accesorio.

3.7.3.1 Tratamiento de los datos del participante. Para garantizar la seguridad y confidencialidad de la informaci髇 de un participante, deben adoptarse las medidas necesarias para que los datos de un participante no sean accesibles a otros participantes que pudieran utilizar el mismo terminal posteriormente. El terminal no debe almacenar de manera definitiva datos de un participante. En las situaciones en que se almacene de manera provisional alg鷑 dato de un participante, los datos ser醤 borrados al finalizar la sesi髇 de usuario.

3.7.3.2 Dise駉 f韘ico. El terminal estar� dise馻do para minimizar la posibilidad de ser manipulado por un tercero poniendo en riesgo al participante que lo utilice. A estos efectos se considerar醤 ataques l骻icos, como pudiera ser mediante la manipulaci髇 del software, ataques f韘icos, como pudiera ser mediante el pinchado de chips o puertos, ataques a trav閟 de las comunicaciones, as� como ataques combinados.

3.7.3.3 Integridad del terminal. El terminal tambi閚 debe generar un registro o log local, donde registrar� pista de auditor韆 de cualquier modificaci髇 en un componente software instalado, su eliminaci髇 o nueva instalaci髇, as� como de los accesos o intentos de acceso, ya sean locales o remotos. Estos registros se conservar醤 al menos noventa d韆s, no siendo aplicable el requisito general de conservaci髇 de seis a駉s. El sistema t閏nico comprobar� al menos diariamente que los componentes software del terminal son los aprobados.

El terminal utilizar� un sistema para verificar que cualquier componente software a instalar es aut閚tico y no ha sido alterado, como paso previo antes de cualquier instalaci髇 de componentes software.

El terminal estar� razonablemente dise馻do para detectar un funcionamiento err髇eo o inseguro, y en su caso deber� alertar al participante y restringir la operativa.

Cuando el terminal est� siendo utilizado por un participante, el operador 鷑icamente podr� utilizar el acceso remoto al terminal en las comunicaciones normales para el desarrollo del juego con la unidad central de juegos, para la monitorizaci髇 de la calidad, seguridad y rendimiento, para tareas peri骴icas planificadas como la descarga de contenidos. Tambi閚 podr� acceder el operador para solucionar problemas o incidencias t閏nicas, siempre que el participante sea advertido. Antes de permitir cualquier acceso de este tipo, el terminal debe autenticar al sistema del operador y establecer una l韓ea de comunicaci髇 segura.

3.7.3.4 Terminales m髒iles. En el caso de terminales f韘icos de car醕ter accesorio m髒iles, el terminal incluir� mecanismos que permitan al operador controlar la localizaci髇 del mismo.

3.8 Sesi髇 de usuario. Se denomina sesi髇 de usuario al per韔do de tiempo que un usuario permanece conectado al sitio web del operador, y que comprende desde la autenticaci髇 v醠ida del usuario en el sistema hasta la desconexi髇 del mismo.

3.8.1 Desconexi髇 por inactividad. El tiempo de desconexi髇 por inactividad del usuario ser� como m醲imo de veinte minutos; transcurrido este tiempo, la plataforma debe desconectar al usuario.

Cuando el operador realice comunicaciones de car醕ter b醩icamente unidireccional donde el comportamiento esperado del usuario sea pasivo, como por ejemplo en la retransmisi髇 de un evento deportivo en directo, podr� entenderse que el usuario sigue activo aunque no realice ninguna acci髇.

Si t閏nicamente es posible, se informar� al participante de que la sesi髇 ha terminado.

3.8.2 Registro de las sesiones de usuario. La plataforma conservar� registro de las sesiones de usuario, con detalle de los tiempos de inicio y fin de sesi髇 de usuario, del mecanismo de autenticaci髇 utilizado por el usuario, y la causa de desconexi髇 o inactividad.

En el caso de que el terminal pertenezca al usuario, la plataforma permitir� identificar, si t閏nicamente es posible, el tipo de dispositivo (ordenador, smartphone u otros), la aplicaci髇/versi髇 utilizada (navegador o aplicaci髇 concreta), y en su caso la direcci髇 IP.

En el caso de que el terminal pertenezca a un operador, permitir� identificar el tipo y versi髇 del terminal, as� como, si t閏nicamente es posible, el terminal concreto.

3.9 Interfaz gr醘ica.

3.9.1 Datos del juego. El nombre del juego que el participante est� jugando debe ser claramente visible en todas las pantallas asociadas.

Las instrucciones del juego deben ser f醕ilmente accesibles. La interfaz gr醘ica debe incluir toda la informaci髇 necesaria para el desarrollo del juego. La funci髇 de todos los botones de acci髇 representados en la pantalla debe ser clara.

El resultado de cada jugada deber� mostrarse, si t閏nicamente es posible, de forma instant醤ea al participante y mantenerse durante un lapso de tiempo razonable.

3.9.2 Datos del participante. La pantalla debe mostrar el saldo actual del participante al menos en euros y las apuestas realizadas, unitarias y totales.

3.9.3 Premios. La interfaz deber� indicar claramente si los premios se muestran en euros o en cr閐itos. No deber醤 alternarse diferentes representaciones que puedan confundir al participante.

Si se ofrecen premios aleatorios asociados a una jugada o apuesta, el participante debe conocer el importe m醲imo que puede obtener a partir de la apuesta o jugada que va a realizar.

El participante debe ser informado cuando el importe del premio aleatorio se determine en funci髇 del importe de la jugada o apuesta. Cuando el texto o los elementos gr醘icos anuncien un premio m醲imo, este premio debe poder ser conseguido mediante un 鷑ico juego.

3.9.4 Juegos de cartas. Los juegos de cartas deben cumplir que:

• • Las caras de las cartas deben mostrar claramente el valor de las mismas.
• • Las caras de las cartas deben mostrar claramente el palo/color de las mismas.
• • Los jokers o comodines deben distinguirse del resto de cartas.
• • La utilizaci髇 de m醩 de una baraja en el juego debe mostrarse claramente.
• • Si las cartas son barajadas durante el juego, debe informarse claramente sobre la frecuencia con que se realiza y mostrarse el momento en que se realiza.

3.9.5 Simulaci髇 de elementos de la vida real. Los juegos que simulan elementos de la vida real (ruletas, bombos u otros), deben comportarse de la forma m醩 parecida posible al comportamiento de dichos elementos f韘icos. La probabilidad de que ocurra alg鷑 acontecimiento en la simulaci髇 que afecte el resultado del juego debe ser equivalente a la del dispositivo f韘ico en la vida real.

3.9.6 Interfaz gr醘ica de terceros. Se considerar� que una interfaz gr醘ica es de terceros cuando el operador no la ofrezca como parte de su plataforma o cuando el operador incluya un enlace a su descarga y junto al enlace est� claramente especificado que el operador no es responsable del mismo.

El operador deber� informar a los participantes que decidan utilizar una interfaz de usuario de terceros en relaci髇 con que la funcionalidad y la informaci髇 que reciban pueden no ser completas.

3.10 Integraci髇 con proveedores y en redes de juego con otros operadores.–

El operador ser� responsable de las operaciones de juego realizadas a trav閟 de terceros o proveedores. Los sistemas t閏nicos de terceros o proveedores se considerar醤 a estos efectos parte del sistema t閏nico del operador y deber醤 cumplir las especificaciones establecidas en esta disposici髇.

El operador deber� garantizar que cualquier integraci髇 con los sistemas de otro operador se realiza de tal forma que cumpla las especificaciones establecidas en esta disposici髇.

3.11 Deshabilitaci髇 de un juego o de una sesi髇 de usuario.–

La plataforma debe permitir que, en circunstancias excepcionales, sea posible inhabilitar un juego completo, o sesiones de usuarios concretas, dejando registro de las actuaciones y el motivo que las origin� para una posterior revisi髇.

3.12 Juego incompleto.–

Un juego incompleto es aquel cuyo resultado todav韆 no se ha producido o, si se ha producido, el participante no ha podido ser informado de este hecho.

Ante un juego incompleto, las reglas particulares del juego determinar醤 la actuaci髇 de la plataforma, que podr� esperar al participante, anular el juego o seguir en el mismo hasta que sea completado.

• • Si el juego incompleto se debe a una p閞dida de conexi髇 del terminal del usuario, la plataforma mostrar� el juego incompleto cuando el participante vuelva a conectarse.
• • El operador deber� disponer de un procedimiento documentado de gesti髇 de las incidencias de indisponibilidad de uno, varios o todos los componentes, que incluya las medidas t閏nicas asociadas. Los componentes deben realizar un autodiagn髎tico, un chequeo de los archivos cr韙icos y un chequeo de las comunicaciones entre los distintos componentes.
• • Tras la recuperaci髇, el sistema t閏nico de juego debe proceder a tratar los juegos en curso afectados por la interrupci髇.

El sistema t閏nico guardar� registro de las interrupciones de servicio, con su inicio, duraci髇, y servicios afectados para posterior revisi髇.

3.13 Juego autom醫ico.–

Si el sistema ofrece consejos sobre estrategia de juego o funcionalidades de juego autom醫ico, tales recomendaciones o funcionalidades deben ser veraces y asegurar que se alcance el porcentaje de retorno obligatorio.

Se garantizar� que el participante mantiene el control del juego cuando se proporciona la funcionalidad de juego autom醫ico. El participante podr� controlar el importe m醲imo del juego autom醫ico o de la apuesta m醲ima y el n鷐ero de apuestas autom醫icas. El participante podr� desactivar en cualquier momento la funcionalidad de juego autom醫ico.

Cuando se use la funcionalidad de juego autom醫ico, las informaciones mostradas en pantalla (duraci髇, elementos gr醘icos u otras) ser醤 las mismas y presentar醤 las mismas caracter韘ticas que cuando el juego no es autom醫ico. La interfaz mostrar� adicionalmente el n鷐ero de jugadas autom醫icas transcurridas o restantes.

La funcionalidad de reproducci髇 autom醫ica no podr� poner en desventaja a un participante, y ni la secuencia de las partidas autom醫icas, ni cualquier estrategia que sea aconsejada al participante deber� resultar enga駉sa.

En el caso de los juegos en que intervenga simult醤eamente m醩 de un participante, todos los participantes deben ser informados y aceptar un participante que ha establecido la funcionalidad de juego autom醫ico.

3.14 Repetici髇 de la jugada.–

La plataforma debe proporcionar al participante la opci髇 de repetici髇 de la jugada, mostr醤dolo como una reconstrucci髇 gr醘ica o una descripci髇 inteligible que deber� reproducir todos los lances del juego que puedan tener repercusi髇 sobre su desarrollo. La opci髇 de repetici髇 deber� suministrar toda la informaci髇 necesaria para reconstruir las 鷏timas diez partidas de la sesi髇 de usuario en curso.

3.15 Jugadores virtuales.

3.15.1 Jugadores virtuales proporcionados por el operador. El operador puede utilizar inteligencia artificial mediante jugadores virtuales, tambi閚 denominados robots, si as� lo permitiera expresamente la regulaci髇 del juego correspondiente.

En el caso de los juegos en que intervenga simult醤eamente m醩 de un participante, todos los participantes deben ser informados y aceptar la presencia de un jugador virtual.

Los jugadores virtuales o autom醫icos deber醤 estar identificados claramente en la interfaz.

El jugador virtual no debe tener ninguna ventaja t閏nica sobre los participantes, y no tendr� acceso a informaci髇 que no est� al alcance de 閟tos.

3.15.2 Jugadores virtuales utilizados por participantes. El operador puede facilitar a los participantes inteligencia artificial mediante la utilizaci髇 de jugadores virtuales o robots, si as� lo permite la regulaci髇 del juego correspondiente.

El operador informar� sobre si permite o no el uso de jugadores virtuales o robots por parte de los participantes. En los supuestos en los que los permita e intervengan simult醤eamente m醩 de un participante, el operador debe asegurarse de que el resto de participantes conozcan qui閚 es un jugador virtual o robot. En los casos en los que no los permita e intervengan simult醤eamente m醩 de un participante, deber� tratar de evitar que los participantes hagan uso de jugadores virtuales y tan pronto detecte su uso deber� comunicar esta circunstancia a los participantes. Los participantes deber醤 disponer de un mecanismo para denunciar la existencia de un posible jugador virtual.

El operador dispondr� de procedimientos para detectar si un participante est� utilizando t閏nicas de inteligencia artificial.

3.16 Juegos metam髍ficos.–

Los juegos metam髍ficos o de evoluci髇, deben:

• • Informar de las reglas aplicables en cada momento o fase de juego.
• • Mostrar al participante la suficiente informaci髇 para indicar la cercan韆 de la siguiente metamorfosis. Por ejemplo, si el participante va recogiendo elementos, la interfaz debe mostrar el n鷐ero de elementos que el participante ha recogido, los que son necesarios para la metamorfosis o los que le faltan para conseguirlo.
• • La probabilidad de una metamorfosis no debe ser variada en funci髇 de los premios obtenidos por el participante en previas partidas. Cualquier excepci髇 debe ser previamente autorizada por la Direcci髇 General de Ordenaci髇 del Juego.
• • Las informaciones y el juego no deben ser enga駉sos o ambiguos.

3.17 Participante en estado 玜usente�.–

Durante un juego en que intervenga simult醤eamente m醩 de un participante, la plataforma debe permitir al usuario establecer un estado de 玜usente� o 玴ausa� que puede ser utilizado si el participante necesita dejar de jugar durante un periodo breve que nunca ser� superior a veinte minutos. En estado 玜usente� el participante no realiza nuevas jugadas. Si realizara alguna jugada su estado dejar de ser 玜usente� autom醫icamente. Si las acciones no afectan al juego (p. ej., consulta de la ayuda) se mantendr� el estado de 玜usente�.

3.18 Juegos multiparticipante con anfitri髇.–

En los juegos donde un participante es el anfitri髇, 閟te podr� decidir si acepta a cualquier participante o si s髄o lo acepta a trav閟 de una invitaci髇. El anfitri髇 no podr� excluir participantes de la mesa una vez han sido previamente aceptados a la misma.

3.19 Juego 玡n vivo�.–

A estos efectos se denominan 玡n vivo� a aquellos juegos que utilizan un croupier real o una mesa de juego real como dispositivo de juego, cuando dicho juego se integra con un sistema de retransmisi髇 y de apuestas online.

Los participantes podr醤 visualizar una retransmisi髇 online que permita seguir el juego y conocer el resultado.

Deber醤 existir procedimientos de actuaci髇 para la resoluci髇 de las incidencias que puedan suceder durante las operaciones de juego en vivo.

Los dispositivos autom醫icos de reconocimiento y registro utilizados deben estar equipados con una modalidad de funcionamiento manual que permita la correcci髇 de un resultado err髇eo. El participante debe ser informado de que la modalidad manual se encuentra activa. Cada vez que se active la modalidad de funcionamiento manual se debe dejar la traza que permita su posterior revisi髇.

Deber醤 existir procedimientos para tratar interrupciones en el juego provocadas por la discontinuidad en el flujo de datos, video y voz.

3.20 Botes, botes progresivos, y premios adicionales.–

Siempre que la reglamentaci髇 b醩ica de los juegos correspondientes lo permita, el operador podr� crear botes, botes acumulados, botes progresivos o premios adicionales.

La plataforma informar� al participante de forma clara cuando est� aportando fondos a botes y la manera en que un participante puede optar a los mismos. Todos los participantes que contribuyen al bote deben poder optar a ganarlo a lo largo del desarrollo del juego. La descripci髇 de las condiciones del bote y los requisitos para ganarlo deben ser comunicados al participante.

Las condiciones del bote deben contemplar cualquier conclusi髇 o interrupci髇, prevista o imprevista, del juego, as� como interrupciones t閏nicas del sistema.

El sistema del operador llevar� una contabilidad asociada a la gesti髇 de los botes que permita el control de los mismos, identificando como m韓imo:

• – La creaci髇 de cada bote.
• – Los periodos de tiempo en que ha estado activo cada bote.
• – Las caracter韘ticas configurables del bote activas en cada momento.
• – Los juegos o m醧uinas que participan o contribuyen al bote en cada momento.
• – El saldo del bote en todo momento, diferenciando la contribuci髇 al mismo de cada tipo de juego o m醧uina.
• – Los premios concedidos en base al bote, con detalle del ganador, importe y momento en que se produjo.
• – El registro de las acciones manuales que afecten al saldo del bote.
• – Las operaciones de transferencia o redirecci髇 a otro bote.
• – El cierre de un bote o el momento en que se produzca su baja.

El operador deber� disponer de un procedimiento que permita el control de los botes, garantizando que el bote se crea, gestiona, y concede de manera acorde con las reglas del juego.

En particular, con periodicidad m韓ima mensual, el operador deber� comprobar:

• • El correcto funcionamiento y los saldos y movimientos de los botes.
• • Que una vez constituido y abierto el bote, las condiciones no cambian hasta que 閟te haya sido ganado por uno o varios participantes y su importe hecho efectivo.
• • Que el procedimiento de determinaci髇 de ganadores funciona correctamente. El procedimiento no debe permitir introducir ganadores que no cumplan las condiciones para ser premiados, ni tampoco no dar por ganadores a aquellos que s� las cumplan.
• • Que el sistema concede los premios a los participantes que figuran en la lista de ganadores.
• • Si existen, se prestar� especial atenci髇 a los sistemas de redirecci髇 del bote en los que parte del bote acumulado es redirigido a otro fondo, donde puede ser ganado posteriormente. El sistema de redirecci髇 de bote no puede utilizarse con la finalidad de posponer la concesi髇 de un premio indefinidamente.

La inoperatividad del bote deber� ser comunicada a los participantes mediante la visualizaci髇 en su terminal de mensajes como 玝ote cerrado� o similares. No ser� posible ganar un bote acumulado que se encuentre previamente cerrado.

3.21 Juegos a trav閟 de canales de comunicaci髇 玡n diferido�.–

A estos efectos se tendr醤 la consideraci髇 de juegos 玡n diferido� aquellos juegos cuya aleatoriedad o alguno de los elementos para llegar al resultado se hayan obtenido con anterioridad al inicio de la interacci髇 de los participantes con el juego durante la partida.

El operador adoptar� las medidas t閏nicas, de seguridad y organizativas necesarias para evitar que ni el propio operador, su personal, u otros participantes puedan obtener ventajas derivadas del conocimiento previo, incluso parcial, de los elementos que pueden determinar el resultado.

4. Seguridad de los sistemas de informaci髇

Los requisitos de seguridad del sistema t閏nico de juego que se establecen tienen como objetivo proteger los registros de usuario de los usuarios y sus cuentas de juego asociadas, as� como garantizar que el juego se desarrolla de manera correcta.

4.1 Componentes cr韙icos.–

Los componentes cr韙icos son los elementos cuya seguridad debe ser reforzada, ya que su impacto en el desarrollo del juego es importante.

Son componentes cr韙icos:

• • En el registro de usuario, cuenta de juego y procesamiento de los medios de pago: los componentes del sistema t閏nico de juego que almacenan, manipulan o transmiten informaci髇 sensible de los clientes como datos personales, de autenticaci髇, o econ髆icos y los que almacenan el estado puntual de los juegos, apuestas y su resultado.
• • En el generador de n鷐eros aleatorios: los componentes del sistema t閏nico de juego que transmiten o procesan n鷐eros aleatorios que ser醤 objeto del resultado de los juegos y la integraci髇 de los resultados del generador de n鷐eros aleatorios en la l骻ica del juego.
• • Las conexiones con la Direcci髇 General de Ordenaci髇 del Juego.
• • El sistema de control interno: el capturador y el almac閚.
• • Los puntos de acceso y las comunicaciones de y hacia los componentes cr韙icos anteriores.
• • Las redes de comunicaci髇 que transmiten informaci髇 sensible de participantes.

4.2 Gesti髇 de la seguridad del sistema t閏nico de juego.–

El operador deber� implementar un sistema de gesti髇 de la seguridad, que proteger� especialmente los componentes cr韙icos referidos en el n鷐ero anterior.

Los procedimientos de seguridad deber醤 estar dirigidos a implementar medidas concretas de seguridad, partiendo de una evaluaci髇 de los riesgos. El operador deber� planificar las revisiones peri骴icas y realizar las revisiones derivadas de los cambios significativos.

4.3 Gesti髇 de riesgos.–

La gesti髇 de riesgos identificar� los elementos a proteger, para despu閟 llevar a cabo una identificaci髇, cuantificaci髇 y priorizaci髇 peri骴ica de los riesgos a los que est� sometido el sistema t閏nico de juego. La gesti髇 de riesgos deber� plasmarse en un plan de medidas.

4.4 Pol韙ica de seguridad.–

Los operadores deber醤 contar con unos procedimientos de seguridad que ser醤 comunicados a la totalidad de sus empleados y, en su caso, a las entidades colaboradoras externas.

4.5 Organizaci髇 de la seguridad de la informaci髇.–

Los operadores deber醤 establecer un marco de gesti髇 para la seguridad de la informaci髇 indicando las funciones y responsabilidades de su personal.

4.6 Seguridad en la comunicaci髇 con los participantes.–

Deben adoptarse mecanismos de autenticaci髇 que permitan al sistema de juego identificar al participante, y que, a su vez, permitan al participante identificar al sistema de juego.

El operador deber� establecer los sistemas y mecanismos que garanticen la confidencialidad de las comunicaciones de los participantes con sus sistemas t閏nicos de juego y, en particular, con la unidad central de juegos y su r閜lica. Las comunicaciones ser醤 cifradas en los casos de transmisi髇 de datos personales (registro de usuario) o econ髆icos (cuenta de juego).

En relaci髇 con las comunicaciones, el operador adoptar� las medidas que resulten necesarias para garantizar la integridad y el no repudio en los casos de transmisi髇 de datos personales o econ髆icos, y en las transacciones de participaci髇 en el juego.

4.7 Seguridad de recursos humanos y terceros.–

El plan de seguridad del personal del operador incluir� acciones formativas, gesti髇 de la contrataci髇, cambios y finalizaci髇 de la contrataci髇, prestando especial atenci髇 a los permisos de acceso a informaci髇 y componentes cr韙icos.

Cuando el operador necesite de los servicios de terceros que supongan acceso, procesamiento, comunicaci髇 o tratamiento de la informaci髇, o bien el acceso a instalaciones, productos o servicios relacionados con el juego, 閟tos terceros deber醤 cumplir la totalidad de los requisitos de seguridad exigibles al resto del personal.

4.8 Seguridad f韘ica y medioambiental.–

Los planes de seguridad de los operadores deber醤 incluir, en relaci髇 con la seguridad f韘ica de los componentes del sistema t閏nico de juego y de su r閜lica, lo siguiente:

• • Seguridad perimetral para las 醨eas que contienen componentes cr韙icos e informaci髇 sensible: paredes, tarjetas de acceso, etc.
• • Control de acceso f韘ico a las instalaciones en las cuales se encuentren los equipos, tanto para empleados como para personal externo, que incluya elementos f韘icos, procedimientos de autorizaci髇, registros de acceso y servicios de vigilancia.
• • Protecci髇 de los equipos cr韙icos frente a riesgos ambientales: agua, fuego, provocados por personas, etc.
• • Protecci髇 de los equipos cr韙icos frente a cortes del suministro el閏trico y otras interrupciones causadas por fallos en instalaciones de soporte. El cableado de suministro el閏trico debe ser protegido de da駉s.
• • Control de acceso al cableado de comunicaciones si transporta informaci髇 cr韙ica sin cifrar.
• • Mantenimiento de las instalaciones y equipos.
• • Los dispositivos que contienen informaci髇 deben ser borrados de manera segura o destruidos antes de ser reutilizados o retirados.
• • Los equipos que contienen informaci髇 no pueden ser trasladados fuera de las instalaciones seguras sin la correspondiente autorizaci髇.

4.9 Gesti髇 de comunicaciones y operaciones.–

Se debe garantizar la segura y correcta operaci髇 del sistema t閏nico de juego, as� como las comunicaciones:

• • Los componentes cr韙icos deber醤 ser monitorizados para evitar que puedan utilizarse versiones diferentes de la homologada.
• • La comunicaci髇 entre los componentes de los sistemas t閏nicos de juego garantizar醤 la integridad y la confidencialidad.
• • Las tareas se segregar醤 entre las diferentes 醨eas de responsabilidad, para minimizar la posibilidad de acceso no autorizado y potenciales da駉s.
• • Se separar醤 las tareas de desarrollo, pruebas y producci髇.
• • Los servicios proporcionados por terceras partes deben incluir controles y m閠ricas de seguridad en los contratos, y deben ser peri骴icamente auditados y monitorizados.
• • Se adoptar醤 medidas de protecci髇 contra c骴igo malicioso.
• • Deben hacerse regularmente copias de seguridad con la frecuencia adecuada y conservarse custodiadas seg鷑 quede recogido en el plan de copias de seguridad.
• • Se adoptar醤 medidas de seguridad en la red de comunicaciones.
• • Se adoptar醤 medidas de seguridad en la manipulaci髇 de soportes port醫iles as� como de borrado seguro o de destrucci髇 de los mismos, que se plasmar醤 en un procedimiento documentado.
• • Los relojes de todos los componentes, especialmente los cr韙icos, deber醤 estar sincronizados con una fuente de tiempo fiable. La fuente de tiempo fiable puede no ser la misma para cada componente. El operador establecer� medidas y controles para evitar la manipulaci髇 de las marcas de tiempo o su alteraci髇 posterior, especialmente en los registros de auditor韆.
• • Deber醤 generarse y guardarse registro de auditor韆 de actividades de todos los usuarios, excepciones y eventos de seguridad de la informaci髇 durante un periodo m韓imo de dos a駉s.
• • Los registros de auditor韆 estar醤 protegidos frente a la alteraci髇 y el acceso indebido.
• • Las actividades del administrador del sistema y del operador del Sistema deber醤 quedar registradas.
• • Se realizar� un an醠isis peri骴ico de los registros de auditor韆. Se tomar醤 acciones en funci髇 de las incidencias detectadas.

4.10 Control de acceso.–

Los accesos del personal del operador y de los participantes deben cumplir los siguientes requisitos:

• • Debe existir una pol韙ica de acceso a informaci髇 documentada, que ser� revisada peri骴icamente.
• • Se debe asegurar el acceso autorizado e impedir el no autorizado mediante controles en el alta de usuarios, gesti髇 de privilegios de acceso, revisi髇 peri骴ica de los privilegios de acceso y pol韙ica de gesti髇 de las contrase馻s.
• • Los usuarios deben seguir buenas pr醕ticas en el uso de contrase馻s y proteger adecuadamente la documentaci髇 y soportes en su puesto de trabajo.
• • Los usuarios 鷑icamente tendr醤 acceso a los servicios que han sido autorizados a usar.
• • No existir醤 usuarios gen閞icos y todos los usuarios acceder醤 con su usuario propio 鷑ico.
• • El sistema debe autenticar todos los accesos, ya sea personal propio, de mantenimiento u otros, ya sea de otros sistemas y componentes (por ejemplo la pasarela de pagos). Tambi閚 debe ser autenticado el personal de inspecci髇 de la Direcci髇 General de Ordenaci髇 del Juego u otro personal que act鷈 en su nombre.
• • Las redes se segregar醤 en funci髇 del 醨ea y responsabilidad de la tarea o funci髇.
• • El acceso a los sistemas operativos requerir� un mecanismo de autenticaci髇 seguro.
• • Se restringir� y se controlar� el uso de programas que permitan evitar los controles de acceso y de seguridad.
• • Las sesiones de usuario tendr醤 un tiempo m醲imo de duraci髇 de la conexi髇 y un tiempo de desconexi髇 por inactividad.
• • El personal de soporte inform醫ico tendr� restringido el acceso a los datos reales de las aplicaciones. Los datos reales sensibles estar醤 ubicados en entornos aislados.
• • Se gestionar醤 los riesgos asociados a dispositivos m髒iles.
• • Si existe el teletrabajo, se comprobar� que el riesgo asociado est� gestionado en el marco del plan de seguridad.

4.11 Compra, desarrollo y mantenimiento de los sistemas.–

Se deber� analizar el impacto en la seguridad en la toma de decisiones de compra, desarrollo y mantenimiento de los sistemas de informaci髇.

4.12 Gesti髇 de incidentes de seguridad.–

El operador deber� disponer de un procedimiento documentado de gesti髇 de incidentes de seguridad.

Todos los incidentes de seguridad deber醤 ser registrados y se documentar醤 de forma clara y concisa los hechos, los impactos y las medidas adoptadas.

4.13 Gesti髇 de cambios.–

De conformidad con lo dispuesto en el art韈ulo 8.5 del Real Decreto 1613/2011, de 14 de noviembre, por el que se desarrolla la Ley 13/2011, de 27 de mayo, de regulaci髇 del juego en lo relativo a los requisitos t閏nicos de las actividades de juego los informes de homologaci髇 y certificaci髇 incluir醤 una relaci髇 de los componentes cr韙icos. La Direcci髇 General de Ordenaci髇 del Juego podr� calificar como cr韙icos otros componentes adicionales.

Desde el inicio de su actividad, el operador deber� disponer de un procedimiento de gesti髇 de cambios documentado, que controle los cambios de los equipos y componentes del sistema t閏nico de juego efectivamente empleado.

• a) Existir� un proceso formal de aprobaci髇 interna de todos los cambios, que debe implicar la petici髇 de cambio y su aprobaci髇 por los responsables correspondientes.
• b) En el caso de cambios en componentes cr韙icos, deber� evaluarse si se trata de un cambio sustancial.
• c) Las peticiones de cambio y las decisiones tomadas se registrar醤 y podr醤 ser objeto de posterior auditor韆.
• d) Se conservar醤 copias de los binarios de los elementos de software de todas las versiones software que se hayan utilizado en el sistema t閏nico efectivamente empleado en los 鷏timos cuatro a駉s. La Direcci髇 General de Ordenaci髇 del Juego podr� establecer la obligaci髇 de que el procedimiento de conservaci髇 de las copias de los binarios incluya una huella digital de los mismos.

4.14 Gesti髇 de la disponibilidad del servicio.–

El operador deber� disponer de un plan de gesti髇 de la disponibilidad del servicio. El operador deber� considerar dentro del plan cada uno de los siguientes servicios:

• • Registro de participante, cuentas de juego, incluyendo la posibilidad de realizar dep髎itos y retirar fondos.
• • Servicios de juego.

El plan indicar� el tiempo m醲imo de indisponibilidad acumulada mensual, as� como el tiempo m醲imo de recuperaci髇 para cada servicio. El operador adaptar� su infraestructura y procesos, e implantar� las medidas necesarias para cumplir los objetivos fijados en su plan de gesti髇 de la disponibilidad.

4.15 Plan de prevenci髇 de p閞dida de informaci髇.–

El operador debe disponer de un plan que garantice que no se pierdan datos o transacciones que afecten o puedan llegar a afectar al desarrollo de los juegos, a los derechos de los participantes o al inter閟 p鷅lico e indique el riesgo asumido por el operador.

El operador adaptar� su infraestructura y procesos, e implantar� las medidas necesarias para cumplir los objetivos fijados en su plan, estableci閚dose los siguientes m韓imos:

• • Se conservar醤 copias de la informaci髇 en un lugar alejado convenientemente de los datos que pretende salvaguardar.
• • La copia de la informaci髇 se proteger� de accesos no autorizados mediante medidas de seguridad equivalentes a las de la informaci髇 a salvaguardar.

El operador deber� disponer de un procedimiento documentado de actuaci髇 en caso de p閞dida de informaci髇 que incluir� los mecanismos para atender las reclamaciones de usuarios, la continuaci髇 de los juegos o apuestas interrumpidas, y cualesquiera otras situaciones que pudieran derivarse.

En caso de producirse una p閞dida de datos, el operador deber� informar a la Direcci髇 General de Ordenaci髇 del Juego, con car醕ter inmediato, indicando las acciones tomadas y una estimaci髇 de la repercusi髇 de la p閞dida.

4.16 Gesti髇 de la continuidad de negocio.–

El operador debe disponer de un plan de continuidad de negocio para el mantenimiento de la operativa de juego ante desastres, que incluya las medidas t閏nicas, humanas y organizativas necesarias para garantizar la continuidad del servicio y de una r閜lica de la unidad central de juegos que permita el normal desarrollo de la actividad.

El plan de continuidad de negocio determinar� uno o varios escenarios de recuperaci髇 indicando para cada uno de ellos los servicios recuperados y el tiempo m醲imo en el que estar韆n operativos. El operador deber� considerar dentro del plan los siguientes escenarios:

• • Acceso de los participantes a sus registros de usuario y cuentas de juego, con posibilidad de consultar el saldo y los movimientos de sus cuentas de juego asociadas. El tiempo m醲imo para prestar de nuevo estos servicios ser� de una semana.
• • Posibilidad de los participantes de retirar sus fondos. El tiempo m醲imo para prestar de nuevo estos servicios ser� de una semana.
• • Continuaci髇 de los juegos incompletos o las apuestas pendientes, y pago de los premios v醠idamente conseguidos. El tiempo m醲imo para prestar de nuevo estos servicios ser� de un mes.
• • Restablecimiento completo de todos los servicios.

El operador adaptar� su infraestructura y procesos, e implantar� las medidas necesarias, para hacer realizables los objetivos fijados en su plan de continuidad de negocio.

En caso de desastre, el operador deber� informar a la Direcci髇 General de Ordenaci髇 del Juego con car醕ter inmediato, realizando una estimaci髇 del impacto y del tiempo estimado de recuperaci髇.

4.17 Test de penetraci髇 y an醠isis de vulnerabilidades.–

El sistema de juego deber� pasar un test de penetraci髇 y un an醠isis de vulnerabilidades, al menos con periodicidad anual. Los sistemas t閏nicos o parte de los mismos con car醕ter meramente informativo, donde no se realicen apuestas y no exista acceso al registro de usuario o cuenta de juego, estar醤 exentos de la obligaci髇 de realizar los test de penetraci髇 y los an醠isis de vulnerabilidades.

Los sistemas t閏nicos en los que la interacci髇 con el jugador sea telef髇ica o mediante SMS estar醤 tambi閚 exentos de esta obligaci髇.

El test de penetraci髇 y el an醠isis de vulnerabilidades podr醤 ser realizados por entidades distintas de las entidades designadas para la evaluaci髇 de la seguridad, o incluso ser realizado con recursos propios del operador en el caso de contar con los medios apropiados.

El test de penetraci髇 consistir� en un m閠odo de evaluaci髇 de la seguridad de una red o un sistema, mediante la simulaci髇 de un ataque realizado por un tercero. El proceso incluye un an醠isis activo del sistema buscando debilidades, fallos t閏nicos, o vulnerabilidades. El test incluir� todas las interfaces p鷅licas que custodien, procesen o transmitan datos personales, econ髆icos o de juego.

El an醠isis de vulnerabilidades consistir� en la identificaci髇 y cuantificaci髇 pasiva de los riesgos potenciales del sistema. El an醠isis incluir� todos los componentes que custodien, procesen o transmitan datos personales, econ髆icos o de juego.

Los resultados de los test y de los an醠isis deber醤 conservarse junto con las medidas correctivas aplicadas o planeadas, para su posterior revisi髇 o inspecci髇.

Antes del inicio de la comercializaci髇 de juego, el sistema t閏nico deber� haber pasado con 閤ito tanto un test de penetraci髇 como un an醠isis de vulnerabilidades. El alcance y los resultados deber醤 ser valorados por una de las entidades designadas para la certificaci髇 de la seguridad durante el proceso de certificaci髇.

En el caso de que como resultado del test o an醠isis se detectase un fallo de seguridad muy grave, que pudiera poner en riesgo la identidad o situaci髇 patrimonial de los jugadores o permitir su suplantaci髇, el operador lo comunicar� inmediatamente a la DGOJ junto con el plan de acci髇 que hubiera definido. La DGOJ podr� requerir la suspensi髇 de la oferta de juego afectada hasta la subsanaci髇 del fallo.

Ante incidencias de seguridad de menor gravedad, el operador adoptar� un plan de mejora y en el siguiente test o an醠isis incluir� en el alcance la verificaci髇 de la adecuada subsanaci髇 de las incidencias previamente detectadas.

El operador deber� conservar el informe completo de cada test o an醠isis realizado durante al menos cuatro a駉s.

5. Sistema de control interno e inspecci髇

5.1 Sistema de control interno.

5.1.1 Descripci髇. La monitorizaci髇 y la supervisi髇 de las actividades de juego realizadas por el operador se efectuar� a trav閟 del sistema de control interno (en adelante, SCI), que los operadores deben implantar.

El SCI debe capturar y registrar la totalidad de las operaciones de juego y transacciones econ髆icas de los participantes ubicados en Espa馻 o con registro de usuario espa駉l, cualquiera que sea el medio de participaci髇.

El sistema de control interno deber� adecuarse a los diferentes canales de comercializaci髇 de los juegos y de interacci髇 con los participantes, de tal modo que se asegure la captura y registro de la totalidad de las operaciones de juego realizadas.

Cuando en un 鷑ico juego se empleen simult醤eamente diferentes canales de comercializaci髇 o de interacci髇 con los participantes, el operador deber� establecer las pasarelas, interfaces o canales de comunicaci髇 entre la totalidad de los medios de participaci髇 o de interacci髇 en el juego con el fin de posibilitar a la Direcci髇 General de Ordenaci髇 del Juego acceder a la totalidad de las operaciones y transacciones que se hubieran realizado cualquiera que fuera el medio empleado para ello.

El operador ha de establecer y mantener una l韓ea de comunicaci髇 segura para el acceso de la Direcci髇 General de Ordenaci髇 del Juego, as� como un servicio de consulta y descarga de datos disponible permanentemente para la Direcci髇 General de Ordenaci髇 del Juego.

El SCI se compone de capturador y del almac閚 de operaciones de juego (almac閚).

5.1.2 Acceso de la Direcci髇 General de Ordenaci髇 del Juego al almac閚. El almac閚 mantendr� los siguientes accesos permanentemente abiertos para el acceso de la Direcci髇 General de Ordenaci髇 del Juego:

• • Un acceso mediante el protocolo SFTP para la descarga de la informaci髇.
• • Un acceso mediante SSH con atributos de solo-lectura y permisos suficientes para listar y visualizar el contenido de todo el almac閚.

  El operador proporcionar� los siguientes m閠odos de autenticaci髇 a la Direcci髇 General de Ordenaci髇 del Juego.

• • Para el acceso manual, usuario y contrase馻.
• • Para la descarga automatizada, el operador configurar� el intercambio de pares de claves (SSH keyswap) para el mismo usuario descrito en el acceso manual.

El operador puede utilizar varios almacenes. Los datos deben comunicarse una sola vez, evitando que los diferentes almacenes contengan informaci髇 redundante.

5.1.3 Modelo de datos del SCI. La Direcci髇 General de Ordenaci髇 del Juego, mediante resoluci髇, establecer� el modelo de datos del SCI.

El modelo de datos del SCI contiene el alcance de los datos que deban ser registrados, el per韔do de actualizaci髇 de los mismos y los requerimientos t閏nicos de disponibilidad y de acceso, en los t閞minos establecidos en el art韈ulo 24 del Real Decreto 1613/2011, de 14 de noviembre, por el que se desarrolla la Ley 13/2011, de 27 de mayo, de regulaci髇 del juego, en lo relativo a los requisitos t閏nicos de las actividades de juego.

Los datos se almacenar醤 en una estructura de ficheros, en un formato estructurado en XML, seg鷑 la definici髇 del esquema de datos de monitorizaci髇 (XSD-XML Schema Definition).

5.1.4 Fuente de tiempo del SCI. El sistema de control interno, incluyendo el capturador y el almac閚, estar� sincronizado con un servidor NTP de estrato 1. Toda la informaci髇 de car醕ter temporal reportada en el SCI deber� incluir la zona horaria tomada como referencia mediante la inclusi髇 de las desviaciones positivas o negativas respecto de la hora UTC.

5.1.5 Firma, compresi髇 y cifrado de los datos del SCI. Los datos que vayan a ser registrados en el almac閚 se agrupar醤 en lotes. Cada lote debe ser firmado, comprimido y cifrado por el operador, utilizando el formato y procedimiento descritos en el Modelo de datos de monitorizaci髇.

El operador deber� proporcionar a la Direcci髇 General de Ordenaci髇 del Juego, la parte p鷅lica del certificado electr髇ico que utilizar� para realizar la firma de los lotes. El operador deber� informar a la Direcci髇 General de Ordenaci髇 del Juego si se produce una revocaci髇 del certificado utilizado. El operador podr� utilizar un certificado de su propiedad o encargar a un tercero que en su nombre firme los lotes.

5.1.6 Rendimiento del capturador y del almac閚. El capturador debe tener capacidad para procesar y registrar la informaci髇 de las transacciones.

Salvo situaciones excepcionales debidamente justificadas, el capturador debe estar dise馻do para que la informaci髇 quede procesada, formateada y registrada en el almac閚 en un tiempo m醲imo de dos veces el tiempo definido para tiempo real en el Modelo de datos de monitorizaci髇.

El almac閚 tendr� una capacidad o caudal de comunicaciones m韓imo en Internet, suficiente para que la Direcci髇 General de Ordenaci髇 del Juego pueda acceder al mismo:

• • Para la descarga de datos, deber� disponer de un caudal m韓imo asegurado que permita la descarga de la informaci髇 m醲ima a generar en un d韆, en cuatro horas, mediante el protocolo definido SFTP.
• • Para la subida de datos, se requiere un m韓imo de 64 kbps.

El almac閚 como sistema deber� tener un rendimiento igual o superior al necesario para garantizar los caudales de comunicaciones descritos, independientemente de otras operaciones que deba realizar.

5.1.7 Seguridad del SCI. El SCI en su conjunto, tanto el capturador como el almac閚 de operaciones de juego, son considerados componentes cr韙icos. Los requisitos de seguridad establecidos en el apartado 4 resultan de aplicaci髇 al SCI.

Si bien el modelo de datos requiere que la informaci髇 en el almac閚 se registre finalmente cifrada no se exige que est� cifrada en todo momento. La cadena de custodia de la clave de cifrado se debe incluir en el dise駉 de la seguridad del SCI.

El capturador debe poder registrar las transacciones en todo momento y de manera permanente. El operador debe dise馻r la disponibilidad, el plan de prevenci髇 de p閞dida de informaci髇, el tiempo de recuperaci髇 ante desastres y la continuidad de negocio cumplimentando este requisito.

5.1.8 Indisponibilidad del SCI y suspensi髇 de la oferta de juego. El operador debe suspender la oferta de juego en los supuestos de indisponibilidad del sistema de control interno.

Ante una indisponibilidad del almac閚 inferior a 24 horas, el operador podr� continuar su oferta de juego si el capturador sigue disponible, siempre que sea capaz de continuar registrando las transacciones a la espera de que vuelva a estar disponible el almac閚. El operador suspender� la oferta de juego ante una indisponibilidad del almac閚 superior a 24 horas.

5.1.9 Disponibilidad del SCI. El capturador debe poder registrar las transacciones en todo momento y de manera permanente. El almac閚 no podr� tener un tiempo de ca韉a acumulado mensual superior a 48 horas.

5.1.10 Plan de prevenci髇 de la p閞dida de informaci髇 en el SCI. El SCI es un componente cr韙ico. Los operadores de juegos deben implementar un procedimiento que minimice el riesgo de p閞dida de informaci髇 a un m醲imo de 24 horas.

En caso de p閞dida de informaci髇 en el SCI, el operador deber� disponer de un procedimiento de nueva extracci髇 de la informaci髇 perdida que permita subsanar la p閞dida en el plazo m醲imo de una semana.

Cualquier p閞dida de informaci髇 que afecte al SCI debe comunicarse a la Direcci髇 General de Ordenaci髇 del Juego con car醕ter inmediato, indicando una evaluaci髇 de la p閞dida as� como el plan de medidas a aplicar.

5.1.11 Calidad de la informaci髇 del SCI. El operador deber� disponer de un procedimiento documentado de control de la calidad de los datos del SCI. Este procedimiento, deber� ejecutar con periodicidad m韓ima mensual, incluir� al menos las siguientes comprobaciones:

• – Que los datos incluyen a todos los participantes registrados en el operador.
• – Que los datos econ髆icos incluyen a todas las transacciones de juego del periodo, incluyendo dep髎itos y retiradas, as� como que las cifras obtenidas se corresponden con las cifras oficiales del operador.
• – Que los saldos de las cuentas de los participantes est醤 adecuadamente reflejados en la informaci髇 del sistema de control interno.
• – Que se han generado los ficheros mensuales del periodo, as� como los ficheros diarios de cada uno de los d韆s del periodo.

El operador conservar� la documentaci髇 del resultado de las comprobaciones anteriores, incluyendo en esta documentaci髇 la fecha de realizaci髇, la firma de la persona responsable por parte del operador, las principales magnitudes, econ髆icas y de n鷐ero de usuarios registrados, transmitidas en los ficheros del sistema de control interno, as� como su contraste con las cifras oficiales del operador.

El operador deber� estar preparado para, mediante nuevas extracciones, rectificar los datos incorrectos en el plazo m醲imo de un mes.

5.1.12 Continuidad de negocio en el SCI. Dado que la indisponibilidad del SCI conlleva la suspensi髇 de la oferta de juego, el operador deber� disponer de un procedimiento de continuidad de negocio que ante un eventual desastre permita tener el SCI operativo en un tiempo inferior a un mes.

Cualquier desastre que afecte al SCI debe comunicarse a la Direcci髇 General de Ordenaci髇 del Juego con car醕ter inmediato, indicando una evaluaci髇 de la p閞dida as� como el plan de medidas a aplicar.

5.1.13 Conservaci髇 de la informaci髇 del SCI. El almac閚 debe conservar sus datos por un periodo m韓imo de seis a駉s.

Los operadores de juego tendr醤 la obligaci髇 de facilitar y permitir a la Direcci髇 General de Ordenaci髇 del Juego el acceso online a la informaci髇 correspondiente a los doce 鷏timos meses de actividad registrada en el almac閚.

Los operadores deber醤 tener previsto un procedimiento de recuperaci髇 de la informaci髇 correspondiente a un periodo m韓imo de seis a駉s.

5.1.14 Ubicaci髇 del almac閚 en Espa馻. El almac閚 o almacenes del SCI deber醤 estar ubicados en Espa馻, con la finalidad de realizar las operaciones de verificaci髇 y control de la informaci髇. La ubicaci髇 y cualquier modificaci髇 de la misma deber醤 ser comunicadas a la Direcci髇 General de Ordenaci髇 del Juego.

Las copias de seguridad del almac閚 o los sitios de r閜lica secundarios de un almac閚 principal podr醤 estar ubicados fuera de Espa馻.

5.2 Inspecci髇 presencial y telem醫ica.–

La Direcci髇 General de Ordenaci髇 del Juego deber� tener la posibilidad de monitorizar y supervisar cualquiera de los elementos de las plataformas t閏nicas de juego de los operadores.

Para ello, el operador deber� articular los mecanismos necesarios de comunicaci髇 segura a sus sistemas t閏nicos, as� como permitir y facilitar en todo momento el acceso a los mismos por parte de la Direcci髇 General de Ordenaci髇 del Juego, independientemente de su ubicaci髇.

La Direcci髇 General de Ordenaci髇 del Juego comunicar� al operador su intenci髇 de realizar una conexi髇 al sistema t閏nico de juego proporcionando una descripci髇 de las funcionalidades a las que se pretende acceder y el tiempo y duraci髇 previstos para el acceso.

El operador proporcionar� a la Direcci髇 General de Ordenaci髇 del Juego los medios para realizar un acceso seguro al sistema. El personal designado por el operador colaborar� con la Direcci髇 General de Ordenaci髇 del Juego para el adecuado acceso y consulta de otros sistemas y aplicaciones. La Direcci髇 General de Ordenaci髇 del Juego podr� realizar grabaciones de la sesi髇 de usuario y cuantas constataciones de hecho sean necesarios para el ejercicio de sus funciones.

Si no se requiere lo contrario, deber� entenderse que el acceso proporcionado a la Direcci髇 General de Ordenaci髇 del Juego es de s髄o lectura y que cuenta con el nivel de autorizaci髇 para acceder a todos los sistemas y aplicaciones del sistema t閏nico de juego sin ning鷑 filtro en los datos a que puede acceder.

Finalizado el acceso el operador deber� cerrar el acceso seguro.

6. Registros y logs del sistema t閏nico de juego

6.1 Registro y trazabilidad.–

El operador conservar� registros y logs de todas las decisiones del participante, del propio operador, de su personal o de sus sistemas, que tengan repercusi髇 en el desarrollo del juego, en el registro de usuario, en las cuentas de juego o en los medios de pago.

En relaci髇 con los datos de desarrollo del juego, los datos deber� poder reconstruir todos los lances del juego que pudieran tener repercusi髇 sobre su desarrollo El Sistema T閏nico de Juego tambi閚 debe conservar registros y logs en materia de seguridad de los sistemas de informaci髇. Todos los referidos registros y logs deber醤 ser accesibles online para la Direcci髇 General de Ordenaci髇 del Juego durante un tiempo no inferior a doce meses. De manera excepcional y justificadamente el operador podr� eximirse de este requisito previa solicitud de autorizaci髇 a la Direcci髇 General de Ordenaci髇 del Juego. Sin perjuicio de lo anterior, los registros y logs deben ser conservados en almacenamiento durante al menos 6 a駉s.

Los operadores deber醤 tener previsto un procedimiento de recuperaci髇 de esta informaci髇.

Los registros y logs estar� dise馻dos de forma que se evite la posibilidad de borrado o modificaci髇.

Cualquier actuaci髇 de borrado que el operador deba realizar, por ejemplo, para corregir errores t閏nicos, deber� ser debidamente aprobada por el operador y se conservar� la documentaci髇 justificativa de los ajustes realizados.

6.2 Registro en funci髇 del canal de comercializaci髇.–

Determinados terminales y procedimientos de participaci髇 tienen requisitos espec韋icos de registro para las operaciones de juego. Estos requisitos no afectar醤 a otras comunicaciones entre el operador y el participante diferentes a las propias del desarrollo del juego.

Estos terminales y procedimientos espec韋icos se aplicar醤 al registro de los mensajes enviados y recibidos para las actividades de juego realizadas a trav閟 de mensajer韆 de texto, a trav閟 de servicios telef髇icos fijos o m髒iles o de medios de comunicaci髇 audiovisual.

6.3 Fuente de tiempo: El sistema t閏nico de juego estar� sincronizado con un servidor NTP de estrato 1. Toda la informaci髇 de car醕ter temporal remitida a la Direcci髇 General de Ordenaci髇 del Juego deber� incluir la zona horaria tomada como referencia mediante la inclusi髇 de las desviaciones positivas o negativas respecto de la hora UTC.

7. Juego ofertado en un entorno de liquidez internacional.

7.1 En un juego ofertado en un entorno de liquidez internacional, las referencias hechas en los apartados 1 a 6 de este anexo a los t閞minos 玴articipantes�, 玧ugadores� o 玼suarios� deben entenderse realizadas a los jugadores con registro de usuario espa駉l.

7.2 El desarrollo de un juego en un entorno de liquidez internacional es, en todo caso, de car醕ter voluntario tanto para el operador que solicite una licencia singular habilitante para desarrollar y explotar ese juego como para el operador que ya cuente con una licencia de este tipo.

7.3 El sistema t閏nico de juego que organice, explote y desarrolle la actividad de un juego ofertado en un entorno de liquidez internacional, adem醩 de ajustarse a lo dispuesto en esta resoluci髇, garantizar� que la informaci髇 facilitada a los jugadores con registro de usuario espa駉l se proporcione, al menos, en castellano.

7.4 Toda la informaci髇 remitida a la Direcci髇 General de Ordenaci髇 del Juego deber� incluir la zona horaria tomada como referencia mediante la inclusi髇 de las desviaciones positivas o negativas respecto de la hora UTC.

7.5 En los juegos ofertados en un entorno de liquidez internacional, el sistema t閏nico de juego del gestor de liquidez internacional deber� mantener registros y logs de todas las transacciones que se hayan producido entre los jugadores que hayan empleado un registro de usuario espa駉l y los otros jugadores.

A estos efectos, el sistema t閏nico de juego regulado en esta Resoluci髇 deber� conservar el detalle completo de las partidas en las que haya participado un jugador con registro de usuario espa駉l, el identificador 鷑ico de usuario, los datos de identificaci髇 y la jurisdicci髇 de aquellos jugadores distintos a los jugadores con registro de usuario espa駉l, las participaciones realizadas por cada uno de ellos, los premios recibidos y los datos de desarrollo del juego que permitan reconstruir todos los lances del juego.

En todo caso, el acceso a dichos datos y su tratamiento habr醤 de ser realizados de conformidad con lo dispuesto en la Ley Org醤ica 15/1999, de 13 de diciembre, de Protecci髇 de Datos de Car醕ter Personal y en su normativa de desarrollo.

7.6 El gestor de liquidez internacional deber� disponer de procedimientos para la detecci髇 de fraude y el blanqueo de capitales en los que intervenga alg鷑 jugador con registro de usuario espa駉l, as� como proceder a la pronta notificaci髇 de las acciones sospechosas a los organismos p鷅licos competentes para su investigaci髇.

7.7 El gestor de liquidez internacional adoptar� las medidas necesarias para garantizar que cada uno los jugadores participantes en un determinado juego intervenga con una sola identidad.