Sumario

La Ley 13/2011, de 27 de mayo, de regulaci髇 del juego, que fija el marco regulatorio de la actividad de juego de 醡bito estatal, tiene por finalidad garantizar la protecci髇 del orden p鷅lico, luchar contra el fraude, prevenir las conductas adictivas, proteger los derechos de los menores y salvaguardar los derechos de los participantes en los juegos.

El 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 regula en sus art韈ulos 26 y 27 la identificaci髇 de los participantes, as� como el control de las prohibiciones subjetivas de participaci髇 en los juegos y blanqueo de capitales.

En concreto, el art韈ulo 26.5 dispone que la Direcci髇 General de Ordenaci髇 del Juego 玡stablecer� los requisitos y condiciones adicionales que deban reunir los registros de usuario y las cuentas de juego y las medidas de protecci髇 que hayan de ser cumplidas por los operadores.�

En desarrollo de estas disposiciones se dict� la Resoluci髇 de 12 de julio de 2012, de la Direcci髇 General de Ordenaci髇 del Juego, por la que se aprueba la disposici髇 que desarrolla los art韈ulos 26 y 27 del Real Decreto 1613/2011, de 14 de noviembre, en relaci髇 con la identificaci髇 de los participantes en los juegos y el control de las prohibiciones subjetivas a la participaci髇.

Transcurridos seis a駉s desde la aprobaci髇 del marco regulatorio mencionado, la experiencia adquirida en este tiempo hace que resulte conveniente reforzar los procesos de verificaci髇 de identidad llevados a cabo por los operadores de juego sobre los datos aportados por los participantes mediante la modificaci髇 de la Resoluci髇 de 12 de julio de 2012 anteriormente citada.

En este escenario de mejora de los procesos de verificaci髇 de identidad, tambi閚 resulta adecuado adaptar el contenido de la Resoluci髇 de 6 de octubre de 2014, por la que se aprueba el modelo de datos del sistema de monitorizaci髇 de la informaci髇 correspondiente a los registros de operaciones de juego, para un funcionamiento m醩 eficaz de dicho sistema.

En otro orden de ideas, la modificaci髇 de esta Resoluci髇 aprovecha para incorporar, en los registros de datos de juego, nuevos par醡etros en la clasificaci髇 de los estados de jugador que refuerzan la informaci髇 disponible sobre pr醕ticas de juego responsable llevadas a cabo por los operadores regulados. Por otro lado, la modificaci髇 de esta Resoluci髇 tambi閚 afecta al contenido del Registro de Cat醠ogo de Eventos del operador, al introducir en este campo nuevos datos que son objeto de reporte y a馻dir igualmente una periodicidad diaria en su reporte. Finalmente, tambi閚 se incorpora informaci髇 sobre la IP de origen de las transacciones y sobre el valor de la cuota de la apuesta con la finalidad de prevenir determinadas formas de fraude.

Finalmente, esta Resoluci髇 modifica la Resoluci髇 de 6 de octubre de 2014, por la que se aprueba la 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. Las modificaciones de esta Resoluci髇 tienen por objeto actualizar los requisitos de certificaci髇 de los generadores de n鷐eros aleatorios, exigiendo para ello que 閟tos sean criptogr醘icamente fuertes.

Esta disposici髇 ha sido sometida al procedimiento de informaci髇 en materia de normas y reglamentaciones t閏nicas y de reglamentos relativos a los servicios de la sociedad de la informaci髇 previsto en la Directiva (UE) 2015/1535 del Parlamento Europeo y del Consejo, de 9 de septiembre de 2015, por la que se establece un procedimiento de informaci髇 en materia de reglamentaciones t閏nicas y de reglas relativas a los servicios de la sociedad de la informaci髇.

En su virtud, y previo informe favorable de la Abogac韆 del Estado de la Secretar韆 de Estado de Hacienda del Ministerio de Hacienda,

Esta Direcci髇 General resuelve:

Primero. Modificar la Resoluci髇 de 12 de julio de 2012, por la que se aprueba la disposici髇 que desarrolla los art韈ulos 26 y 27 del Real Decreto 1613/2011, de 14 de noviembre, en relaci髇 con la identificaci髇 de los participantes en los juegos y el control de las prohibiciones subjetivas a la participaci髇, en los siguientes t閞minos:

• 1. El apartado quinto del anexo I queda redactado del siguiente modo:

  玅uinto. Comprobaci髇 de los datos de identidad y la verificaci髇 de los datos aportados por los participantes.

  1. 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.

  2. En los casos en los que el solicitante pueda aportar en su proceso de registro el n鷐ero del documento nacional de identidad (DNI) o el n鷐ero de identificaci髇 de extranjeros (NIE), los operadores deber醤:

  • a) Comprobar los datos de identidad que figuren en sus registros de usuario, bien a trav閟 del Sistema de Verificaci髇 de Identidad de los participantes de la Direcci髇 General de Ordenaci髇 del Juego, bien a trav閟 de otros sistemas o medios de verificaci髇 alternativos.
  • b) Verificar documentalmente los datos aportados por el participante.

  3. En los supuestos en los que el solicitante, en su proceso de registro, se identifique como no residente en Espa馻 y no aporte el n鷐ero del documento nacional de identidad (DNI) o el n鷐ero de identificaci髇 de extranjeros (NIE), la verificaci髇 y comprobaci髇 de los datos, que se realizar� mediante el sistema de verificaci髇 documental que se considere procedente, ser� realizada por el operador en el plazo de un mes contado desde que se haya completado el proceso de registro.

  4. El operador adoptar� las medidas oportunas para evitar que usuarios residentes se registren como usuarios no residentes.�

  
• 2. El apartado sexto del anexo I queda redactado del siguiente modo:

  玈exto. Sistemas de verificaci髇 de identidad de los participantes.

  1. La Direcci髇 General de Ordenaci髇 del Juego, a los efectos de facilitar a los operadores la comprobaci髇 de los datos de identidad de los participantes, pondr� a su disposici髇 un Sistema de Verificaci髇 de Identidad de los participantes que permitir�, mediante el acceso electr髇ico por parte de los operadores, la verificaci髇 en tiempo real de los datos de los solicitantes que empleen para su identificaci髇 el documento nacional de identidad (DNI) o el n鷐ero de identificaci髇 de extranjeros (NIE).

  El Sistema de Verificaci髇 de Identidad de los participantes de la Direcci髇 General del Juego es el 鷑ico sistema cuyo resultado se presume cierto y que, en caso de error, exime de responsabilidad al operador.

  En los supuestos de funcionamiento incorrecto del Sistema de Verificaci髇 de Identidad de los participantes de la Direcci髇 General de Ordenaci髇 del Juego, 閟ta garantizar� la verificaci髇 de los datos en el plazo de tres d韆s desde que se formulara la consulta del operador.

  2. El Sistema de Verificaci髇 de Identidad de la Direcci髇 General de los participantes de Ordenaci髇 del Juego no excluye el empleo de sistemas o medios de verificaci髇 alternativos por parte del operador.�

  
• 3. El apartado octavo del anexo I quedar� redactado del siguiente modo:

  玂ctavo. Verificaci髇 documental y otros controles adicionales.

  1. Sin perjuicio de los medios que se empleen, los operadores son los responsables de exigir y validar la documentaci髇 que sea necesaria para verificar que la identidad del participante en un juego coincide con los datos de identidad comprobados mediante alguno de los sistemas de verificaci髇 de identidad previstos en el apartado sexto de este Anexo.

  2. Para la recepci髇 y comprobaci髇 de la documentaci髇 requerida a los efectos de la verificaci髇 documental de los datos, los operadores dispondr醤 de los medios que se consideren oportunos y que garanticen la seguridad y celeridad del proceso. La Direcci髇 General de Ordenaci髇 del Juego podr� determinar de forma espec韋ica qu� medios garantizan la validez de todo el proceso de verificaci髇 documental.

  3. Los operadores deber醤 registrar y conservar la totalidad de las gestiones, consultas y requerimientos que hubieran realizado para la verificaci髇 documental 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 de conformidad con la normativa vigente.

  4. Sin perjuicio del proceso establecido en el apartado duod閏imo de este anexo, los operadores establecer醤 controles adicionales con el fin de prevenir o evitar conductas fraudulentas relativas a la identidad de los participantes. Estos controles formar醤 parte de los procedimientos generales de detecci髇 y tratamiento del fraude establecidos por el operador y deber醤 ser objeto de revisi髇 peri骴ica.

  A estos efectos la Direcci髇 General de Ordenaci髇 del Juego podr� desarrollar de forma espec韋ica los controles a establecer por los operadores de juego.�

  
• 4. El apartado duod閏imo del anexo I queda redactado del siguiente modo:

  獶uod閏imo. Activaci髇 del registro de usuario.

  1. La activaci髇 de los registros de usuario en los que el solicitante sea residente en Espa馻 o hubiera aportado el n鷐ero del documento nacional de identidad (DNI) o el n鷐ero de identificaci髇 de extranjeros (NIE) requiere la previa verificaci髇 de los datos del mismo en los t閞minos previstos en el p醨rafo 2 del apartado quinto de esta Resoluci髇, y la comprobaci髇 de que no figura inscrito en el Registro General de Interdicciones de Acceso al Juego.

  El operador proceder� de la siguiente manera:

  • a) Los usuarios cuya identidad no haya sido validada en el Servicio de Verificaci髇 de Identidad de los participantes de la DGOJ ni en ning鷑 otro servicio de verificaci髇 de identidad, no podr醤 jugar, ni hacer dep髎itos o retiradas.
  • b) Los usuarios correctamente identificados a trav閟 de cualquier sistema de verificaci髇 de identidad y que est閚 pendientes de verificaci髇 documental podr醤 depositar, hasta un l韒ite conjunto de 150 euros, y participar en los juegos, pero no podr醤 retirar los premios cualquiera que sea su importe o naturaleza. El estado de estos usuarios tendr� la consideraci髇 de pendiente de verificaci髇 documental.
  • c) Los usuarios correctamente identificados mediante verificaci髇 documental podr醤 depositar, participar en los juegos y hacer retiradas. El estado de estos usuarios tendr� la consideraci髇 de activo.

  2. La activaci髇 de los registros de usuario en los que el solicitante no sea residente en Espa馻 y no aporte el n鷐ero de documento nacional de identidad (DNI) o el n鷐ero de identificaci髇 de extranjeros (NIE) requiere la verificaci髇 de los datos del mismo en los t閞minos previstos en el p醨rafo 3 del apartado quinto de esta Resoluci髇.

  El operador proceder� de la siguiente manera:

  • a) Los usuarios que hayan completado el proceso de registro, pero tengan pendiente la verificaci髇 documental de los datos no podr醤 jugar, ni hacer dep髎itos o retiradas.
  • b) Los usuarios correctamente identificados mediante el sistema de verificaci髇 documental podr醤 depositar, participar en los juegos y hacer retiradas. El estado de la cuenta de estos usuarios tendr� la consideraci髇 de activo.�
  

Segundo. Modificar la Resoluci髇 de 6 de octubre de 2014, por la que se aprueba el modelo de datos del sistema de monitorizaci髇 de la informaci髇 correspondiente a los registros de operaciones de juego, en los siguientes t閞minos:

• 1. En el apartado 2 (獶efiniciones�) se modifica el apartado 獳ctivaci髇 del registro de usuario�, que queda redactado del siguiente modo:

  獳ctivaci髇 del registro de usuario.

  La activaci髇 del registro de usuario es el proceso a trav閟 del cual el operador habilita al usuario para poder participar en el juego, toda vez, que se han realizado las verificaciones establecidas por la normativa de juego.�

• 2. El apartado 3.3 (玃eriodicidad�) queda redactado del siguiente modo:

  �3.3 Periodicidad.

  La periodicidad del reporte de la informaci髇 para cada tipo de registro se indica en la siguiente tabla:

  

  El env韔 al almac閚 de los registros de periodicidad diaria, debe producirse antes de las 4 a.m. del d韆 siguiente al d韆 sobre el que se est� informando.

  El env韔 al almac閚 de los registros de periodicidad mensual, debe producirse antes de las 23:59 del primer d韆 del mes siguiente.�

• 3. En el apartado 3.4.1 (玆egistro de usuario detallado (RUD)�), en el apartado 獵ontenido del registro�, el ep韌rafe 獶atos de verificaci髇 de identidad�, queda redactado del siguiente modo:
  • �– Validaci髇 del SVDI. Tomar� valor 玈砘, si se ha usado el Sistema de Verificaci髇 de Identidad de la DGOJ y se ha obtenido verificaci髇 positiva, o 玁o� en caso contrario.
  • – Fecha en la que se ha verificado positivamente por primera vez la identidad del usuario a trav閟 del SVDI.
  • – Validaci髇 documental. Tomar� valor 玈砘, si se ha realizado la verificaci髇 de usuario documentalmente y dicha verificaci髇 es positiva, o 玁o� en caso contrario.
  • – Fecha en la que se ha verificado positivamente por primera vez la identidad del usuario a trav閟 de la verificaci髇 documental.�
• 4. En el apartado 3.4.5, (獵uenta de juego detallada (CJD)�), en el ep韌rafe rubricado 獵ontenido del registro�, los apartados donde se describen los 獶ep髎itos del participante� y las 玆etiradas del participante� quedan redactados de la siguiente manera:
  • �– (+/-) Dep髎itos del participante, desglosado por fecha y medio de pago, de acuerdo a la clasificaci髇 de tipos de medio de pago establecida en el ep韌rafe 玊ipos de medios de pago� de esta Resoluci髇.

  Se reflejar醤 con signo positivo los importes depositados por los participantes y con signo negativo las posibles anulaciones o ajustes realizados.

  Para cada una de las operaciones de dep髎ito realizadas por el jugador, se incluir醤 adem醩:

  • – IP: direcci髇 IP del dispositivo del jugador desde el que se conecta con la plataforma de juego, puede ser IPv4 o IPv6.
  • – Tipo de dispositivo: desde el que se produce la conexi髇 (m髒il, PC, tablet, terminal fijo u otro).
  • – Id dispositivo: identificador del dispositivo desde el que se realiza la conexi髇.�
  • �– (+/-) Retiradas del participante, desglosado por fecha y medio de pago, de acuerdo a la clasificaci髇 de tipos de medio de pago establecida en el ep韌rafe 玊ipos de medios de pago� de esta Resoluci髇.

  Se reflejar醤 con signo negativo los importes retirados por los participantes de su cuenta de juego y con signo positivo las posibles anulaciones o ajustes realizados.

  Para cada una de las operaciones de retirada realizadas por el jugador, se incluir醤 adem醩:

  • – IP: direcci髇 IP del dispositivo del jugador desde el que se conecta con la plataforma de juego, puede ser IPv4 o IPv6.
  • – Tipo de dispositivo: desde el que se produce la conexi髇 (m髒il, PC, tablet, terminal fijo u otro).
  • – Id dispositivo: identificador del dispositivo desde el que se realiza la conexi髇.�
• 5. El apartado 3.4.10 [玆egistros de juegos (JUT, JUD)籡, el ep韌rafe 獶atos gen閞icos comunes a todos los juegos� queda redactado del siguiente modo:

  獶atos gen閞icos comunes a todos los juegos.

  La informaci髇 a transmitir es la siguiente (se incluye el signo m醩 probable):

  • – Identificador del juego: apuesta, partida, mano, torneo, concurso, sesi髇.
  • – Descripci髇 del juego.
  • – Tipo de juego.
  • – Fecha/hora de inicio (apuesta, partida, mano, torneo, concurso, sesi髇).
  • – Fecha/hora de fin (apuesta, partida, mano, torneo, concurso, sesi髇).
  • – Juego en red: s�/no.
  • – Juego aplazado: s�/no (en el caso de juegos por sesi髇 no debe ser cumplimentado).
  • – Juego anulado: s�/no (en el caso de juegos por sesi髇 no debe ser cumplimentado).
  • – Juego suspendido: s�/no (en el caso de juegos por sesi髇 no debe ser cumplimentado).
  • – Totales.
  • – Desglose a nivel de jugador:
    • • IP: direcci髇 IP del dispositivo del jugador desde el que se conecta con la plataforma de juego, puede ser IPv4 o IPv6.
    • • Tipo de dispositivo: desde el que se produce la conexi髇 (m髒il, PC, tablet, terminal fijo u otro).
    • • Id dispositivo: identificador del dispositivo desde el que se realiza la conexi髇.

  En el caso de juegos con liquidez internacional, el operador solo reportar� los datos de los jugadores del dominio �.es�.�

• 6. El apartado 3.4.10 [玆egistros de juegos (JUT, JUD)籡, en el ep韌rafe 獶atos espec韋icos a cada tipo de juego�, se a馻de al final del p醨rafo rubricado 獳puestas� un nuevo punto:
  • �– Cuota: Valor de la cuota de la apuesta (en valor decimal) en el momento en que es aceptada por el jugador.�
• 7. El apartado 3.4.12 獵at醠ogo de Eventos (CEV)� queda redactado de la siguiente manera:

  獻nformaci髇 en cat醠ogo de eventos.

  Datos normalizados de los eventos que componen la oferta de apuestas del operador. Recoger� todos los nuevos eventos o actualizaciones sobre eventos reportados previamente sobre los que el operador ha comercializado apuestas en el periodo, independientemente que dichos eventos hayan finalizado o no.

  Operadores obligados.

  Los operadores que comercializan apuestas.

  Periodicidad.

  • – Diaria: Diariamente se incluir� la informaci髇 de los eventos nuevos o que hayan sido modificados en el d韆.
  • – Mensual: Mensualmente se incluir� la informaci髇 de todos los eventos reportados durante el mes, tanto las altas como las modificaciones. En el caso de haber varias modificaciones en el mes para el mismo evento, se reportar� la informaci髇 de la 鷏tima actualizaci髇.

  Datos del cat醠ogo.

  El cat醠ogo contendr� los siguientes datos:

  • – Identificador del evento.
  • – Descripci髇 del evento.
  • – Tipo de evento. Deportivo, h韕ico u otras apuestas.
  • – Deporte: se identificar� el deporte, siguiendo la clasificaci髇 oficial publicada en la web de la DGOJ, que contiene el listado normalizado de deportes utilizados por los operadores en sus programas de apuestas. Ejemplo: �6� para el 玝閕sbol� o �9� para el deporte 玝oxeo �.
  • – Competici髇: Las apuestas identificar醤 la competici髇. Este campo es obligatorio en caso de que el evento pertenezca a una competici髇 deportiva.
  • – Fecha de inicio del evento.
  • – Fecha de fin del evento, o fecha aproximada si se desconoce en el momento de reportar.
  • – Actualizado. Campo booleano que informar� si el evento reportado es nuevo (‘N’) o es una actualizaci髇 de un evento reportado en un CEV de un mes previo (‘S’).

  Controles principales.

  Todos los eventos reportados en las apuestas mediante un identificador de evento deber醤 estar recogidos en el cat醠ogo correspondiente. No debe haber eventos duplicados, en caso de reportar un duplicado se entiende que es una actualizaci髇 de los datos de un evento previo y por tanto debe ser se馻lizado con el campo actualizado = ’S’ o ser� considerado err髇eo.�

• 8. En el apartado 3.5.1.1 玆egistro RUD: Registro de usuario detallado�, las entradas del cuadro relativas a la verificaci髇 del jugador (VSVDI, FVSVDI, VDocumental y FVDocumental) quedan redactadas del siguiente modo:

  玍SVDI: Verificaci髇 del SVDI. Tomar� valor S (S�), si se ha usado el Sistema de Verificaci髇 de Identidad de la DGOJ y se ha obtenido verificaci髇 positiva, o N (No) en caso contrario.

  FVSVDI: Fecha de la primera verificaci髇 positiva en el SVDI.

  VDocumental: Verificaci髇 documental. Tomar� valor S (S�), si se ha realizado la verificaci髇 de usuario documentalmente y ha resultado positiva, o N (No) en caso contrario.

  FVDocumental: Fecha de la primera verificaci髇 documental positiva.�

• 9. En el apartado 3.5.2.1 玆egistro CJD: Cuenta de juego detallada�, los apartados del cuadro relativos a 獶ep髎itos� y 玆etiradas� quedan redactados de la siguiente forma:

  獶ep髎itos: Se consignar� el total del importe en euros depositado durante el per韔do, as� como cada uno de los dep髎itos realizados, indicando la fecha del dep髎ito, el c骴igo del tipo de medio de pago utilizado –basado en la lista de medios de pago incluida en el apartado 玊ipos de medios de pago�–, el proveedor del medio de pago, el importe, la IP desde la cual se ha realizado la operaci髇, el tipo de dispositivo y su identificador.

  

  Retiradas: Se consignar� el total del importe en euros retirado durante el per韔do, as� como cada una de las retiradas realizadas, indicando la fecha de la operaci髇, el c骴igo del tipo de medio de pago utilizado –basado en la lista de medios de pago incluida en el apartado 玊ipos de medios de pago�–, el proveedor del medio de pago, el importe, la IP desde la cual se ha realizado la operaci髇, el tipo de dispositivo y su identificador.�

• 10. En el apartado 3.5.4.1 [獶atos gen閞icos comunes a todos los juegos (JUT y JUD)籡, el ep韌rafe 獶atos de juego desglosados (JUD)� queda sustituido por el siguiente:

  獶atos de juego desglosados (JUD).

  Identificador del juego: Identificador 鷑ico del suceso que genera la obligaci髇 de informar al SCI. El suceso depende del tipo de juego:

  • – Apuestas: cada combinaci髇 de eventos y hechos sobre los que el que el jugador realice la apuesta.
  • – P髊uer cash y Punto y Banca: cada mano.
  • – P髊uer torneo: cada torneo.
  • – Bingo: cada partida de bingo.
  • – Concursos: cada concurso.
  • – Ruleta, Blackjack, Juegos Complementarios y m醧uinas de azar: cada sesi髇.

  Fecha/hora de fin: Fecha y hora del final del suceso que genera la obligaci髇 de informar al SCI. Esta Fecha debe corresponderse a la misma Fecha/hora de fin reportada en el fichero JUT para el mismo Identificador de juego.

  Desglose a nivel de jugador:

  • – (-) Participaci髇.
  • – (+) Premios.
  • – (+) Premios en especie, valoraci髇 monetaria.
  • – Desglose de los premios en especie: descripci髇 y valoraci髇 del premio (+).
  • – IP.
  • – Dispositivo [PC; MO (m髒il); TB (tablet); TF (terminal fijo); OT (otros)].
  • – Id dispositivo.�
• 11. En el apartado 3.5.4.2 (獶atos espec韋icos de apuestas�) el ep韌rafe 獳 nivel de desglose por jugador se contemplan� queda redactado del siguiente modo:

  獳 nivel de desglose por jugador se contemplan.

  TicketId: Ticket obtenido por participante una vez cerrada la apuesta.

  Fecha y hora de apuesta: Fecha y hora en la que jugador realiza la apuesta.

  Relaci髇 de apuestas cruzadas: Se deber� indicar si se trata de un reto o no. Se considera que hay un reto cuando el apostante conoce a la persona contra la que est� apostando.

  Se incluir� adem醩 una lista de tickets asociados a cada cruce:

  

  Cuota: Valor de la cuota de la apuesta en el momento en que es aceptada por el jugador.�

• 12. En el apartado 3.5.6 (玆egistro de Cat醠ogo de eventos�), se incluir� una 鷏tima fila en la tabla con el siguiente texto:

  獳ctualizado: S/N.

  El campo es opcional, si no se reporta implica que el evento es nuevo. En caso de ser una actualizaci髇 de un evento previamente reportado, el campo es obligatorio, y debe ser reportado con valor ‘S’.�

• 13. El apartado 3.5.7.2 (獷stado del jugador�) se sustituye por el siguiente:

  �3.5.7.2 Estado del jugador.

  El 玡stado� del jugador est� compuesto por dos campos:

  EstadoCNJ, en el que se pide al operador diferenciar entre:

  • – A: Activo. Refleja el estado en el que el jugador se encuentra debidamente identificado y verificado documentalmente.
  • – PV: Pendiente de verificaci髇 documental. Refleja el estado de un jugador residente, cuya identificaci髇 no ha sido cotejada fehacientemente mediante un sistema de verificaci髇 documental.
  • – S: Suspendido. Refleja el estado del jugador que, tras dos a駉s de inactividad ininterrumpidos, el operador ha optado por suspender.
  • – C: Cancelado. Refleja el estado del jugador que, transcurridos cuatro a駉s desde su suspensi髇, ha sido cancelado.
  • – SC: Suspendido cautelarmente. Refleja el estado del jugador suspendido cautelarmente por el operador por sospecha de comportamiento colusorio o fraudulento o por haber permitido la utilizaci髇 del registro de usuario por terceros.
  • – AC: Anulaci髇 contrato. Refleja el estado del jugador que, estando suspendido cautelarmente, el operador haya considerado probado que el participante ha incurrido en fraude, colusi髇 o puesta a disposici髇 de terceros de su propia cuenta, y haya procedido a resolver unilateralmente el contrato.
  • – PR: Prohibici髇 subjetiva. Refleja el estado del jugador sujeto a cualquiera de las prohibiciones subjetivas establecidas en el art韈ulo 6 de la Ley 13/2011 (menores, inscritos en el RGIAJ, vinculados,...).
  • – AE: Autoexcluido. Refleja el estado del jugador que voluntariamente ha decidido autoexcluirse del juego ofertado por el operador.
  • – O: Otros. Resto de situaciones en que pueda encontrarse un jugador y no est閚 incluidas en ninguna de las anteriores.

  EstadoOperador, en el que el operador introducir� el nombre del estado tal y como se denomina en su plataforma.�

• 14. En el apartado 4.2 (獷structura de directorios�), ep韌rafe 玁iveles 3, 4, 5 y 6�, se modifica el p醨rafo 獼U: Juego�, quedando redactado del siguiente modo:

  獼U: Juego.

  • – <AAAAMMDD>: D韆 en curso:
    • • JUT: Juego (totales): Subcarpeta para cada tipo de Juego (seg鷑 lista del apartado 玊ipo de juego�).
    • • JUD: Juego (por jugador): Subcarpeta para cada tipo de Juego (seg鷑 lista del apartado 玊ipo de juego�).
  • – Anteriores.
  • – Mensual:
    • • JUA: Ajustes de apuestas.
    • • CEV: Cat醠ogo de eventos (mensuales).
  • – Diario:
    • • CEV: Cat醠ogo de eventos (diarios).�
• 15. En el apartado 4.3 (獷mpaquetado de los datos de juegos�) se modifica el segundo p醨rafo, que queda redactado de la siguiente manera:

  獷l nivel 4 para los juegos tendr� una carpeta para los ficheros de periodicidad mensual, otra para los de periodicidad diaria, una carpeta para el d韆 en curso, y otra carpeta para d韆s anteriores:

  • – Mensual: Para depositar los ficheros con los ajustes de apuestas (JUA) y cat醠ogo de eventos (CEV), de periodicidad mensual.
  • – Diario: Para depositar los ficheros del cat醠ogo de eventos (CEV), de periodicidad diaria.
  • – AAAAMMDD: Para el d韆 en curso. Los registros de juegos (JUT y JUD) se generan en tiempo real. El d韆 en curso contendr� todos los lotes/ficheros generados individualmente.
  • – Anteriores: Para d韆s anteriores.�
• 16. El apartado 4.4.5 (獼UA: Ajustes de Apuestas y CEV: Cat醠ogo de Eventos�) queda redactado del siguiente modo:

  獿a nomenclatura es:

  <OperadorId>_<AlmacenId>_<Tipo>_<Subtipo>_<Periodicidad>_<Fecha>_<LoteId>.zip

  Valores:

  • – <OperadorId> es el identificador del operador.
  • – <AlmacenId> es el identificador del Almac閚.
  • – <Tipo> ser� JU.
  • – <Subtipo> puede ser: JUA o CEV.
  • – <Periodicidad> puede ser: D (diario) o M (mensual).
  • – <Fecha> es la fecha sobre la que se declaran los datos (no la fecha de escritura en el Almac閚). Para informaci髇 diaria tendr� el valor AAAAMMDD y para informaci髇 mensual AAAAMM.
  • – <LoteId> es el identificador del lote.�
• 17. El apartado 4.5.6 (玆egistros peri骴icos�) queda redactado de la siguiente manera:

  �4.5.6 Registros peri骴icos.

  Los registros de informaci髇 peri骴ica se basan en dos tipos derivados del RegistroBase, con campos adicionales que permiten determinar el periodo respecto al cu醠 se reportan los datos. Son de nuevo tipos abstractos, que no pueden presentarse directamente.

  • – Si el registro es susceptible de reporte mensual y diario (RUD, RUT, CJD, CJT y CEV), se utilizar� RegistroPeriodicoBase.

    

    Periodicidad	Diaria o mensual
    D韆/Mes	AAAAMMDD/AAAAMM

  • – Si el registro s髄o se puede reportar mensualmente (OPT, ORT, BOT, RUR, RUG y JUA), se utilizar� RegistroMensualBase.

    

    Mes

    AAAAMM�

• 18. En el apartado 4.5.11 (獶esgloses que se repiten varias veces�), la secci髇 獶esgloseOperaciones� queda redactada de la siguiente manera:

  獶esgloseOperaciones.

  Importe total y desglose de cada una de las operaciones de cobro o pago.

  

Tercero. Modificar la Resoluci髇 de 6 de octubre de 2014, por la que se aprueba la 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, en los siguientes t閞minos:

• 1. El apartado 3.5.1 獸uncionamiento del GNA� queda redactado del siguiente modo:

  �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.�

DISPOSICIONES TRANSITORIAS