Resolución de 6 de junio de 2024, de la Dirección General de Ordenación del Juego, por la que se aprueba el Modelo de datos del sistema de monitorización de la información y se modifican los anexos I de las Resoluciones de 6 de octubre de 2014, y de 12 de julio de 2012, relativas a las especificaciones técnicas y a la identificación y prohibiciones subjetivas a la participación en las actividades de juego previstas en la Ley 13/2011, de 27 de mayo, de Regulación del Juego.

[preambulo] La Ley 13/2011, de 27 de mayo, de regulación del juego, establece el marco regulatorio de la actividad de juego en el ámbito de aplicación estatal en sus distintas modalidades, con el fin de garantizar la protección del orden público, 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 establecimiento de los requisitos técnicos de las actividades de juego de la referida Ley 13/2011, de 27 de mayo, ha sido desarrollado en el Real Decreto 1613/2011, de 14 de noviembre, que, interpretado de acuerdo con la disposición adicional décima de la Ley 3/2013, de 4 de junio, de creación de la Comisión Nacional de los Mercados y Competencia, atribuye en la disposición final primera a la Dirección General de Ordenación del Juego, la competencia para dictar aquellas disposiciones que sean precisas para el desarrollo y ejecución de dicha norma. Así, dando cumplimiento al mandato reglamentario se adoptaron las siguientes resoluciones: Resolución de 6 de octubre de 2014, de la Dirección General de Ordenación del juego, por la que se aprueba el modelo de datos del sistema de monitorización de la información; Resolución de 6 de octubre de 2014, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición por la que se desarrollan las especificaciones técnicas de juego, trazabilidad y seguridad que deben cumplir los sistemas técnicos de juego de carácter no reservado objeto de licencias otorgadas al amparo de la Ley 13/2011, de 27 de mayo, de regulación del juego; y Resolución de 12 de julio de 2012, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición que desarrolla los artículos 26 y 27 del Real Decreto 1613/2011, de 14 de noviembre, en relación con la identificación de los participantes en los juegos y el control de las prohibiciones subjetivas a la participación. Desde su adopción se han sucedido diversas novedades normativas que obligan ahora a, por una parte, adoptar un nuevo modelo de datos del sistema de monitorización de la información y, por otra, a modificar los anexos de las resoluciones relativas a los requisitos técnicos y a la identificación y prohibiciones subjetivas a la participación en las actividades de juego. Esas novedades normativas se concretan en la aprobación del Real Decreto 958/2020, de 3 de noviembre, de comunicaciones comerciales de las actividades de juego, y del Real Decreto 176/2023, de 14 de marzo, por el que se desarrollan entornos más seguros de juego, las cuales han supuesto la imposición de una serie de obligaciones a los operadores, susceptibles de ser monitorizadas por la Dirección General de Ordenación del Juego, mediante la introducción de los cambios necesarios en el modelo de datos del sistema de monitorización. Todo ello unido a la experiencia adquirida a lo largo de los últimos doce años, han motivado esta adopción de un nuevo modelo de datos, con el objeto de dotarlo de una mayor funcionalidad y claridad, así como evitar la comisión de errores, redundancias o un tamaño excesivo del sistema. Esta nueva versión del modelo de datos introduce cambios significativos derivados de la situación anterior descrita y que se ven reflejados a lo largo de su contenido. Ejemplo de ello es la incorporación de una descripción de la información contenida en el Registro de Usuario detallado (RUD) donde se introduce un campo denominado «perfil especial», siguiendo las definiciones de perfiles de jugadores especiales, en el que se reportarán las fechas de inicio y fin del jugador en el perfil correspondiente (si esta última se conoce), así como la propia clasificación del Perfil del jugador especial, donde se contemplan los siguientes valores: cliente privilegiado; jugador intensivo; participante joven; comportamiento de riesgo u otros, todo ello de conformidad con el Real Decreto 176/2023, de 14 de marzo. De igual modo, se sustituye la periodicidad diaria de los Registros de Usuario totalizado (RUT) por una periodicidad mensual, y se adapta el modelo a la metodología establecida en el estándar de datos de supervisión aprobado por el Comité Europeo de Normalización. Idéntica situación se produce en relación con las otras dos resoluciones cuyos anexos precisan ser modificados, pues deben adaptarse a lo dispuesto en determinados preceptos de los reales decretos citados, actualizar la normativa mencionada y homogeneizar los plazos de conservación de la información. La resolución ha sido sometida al trámite de información pública, se ha recabado informe previo favorable de la Abogacía del Estado del Ministerio de Consumo y ha sido sometida al procedimiento de información en materia de normas y reglamentaciones técnicas y de reglamentos relativos a los servicios de la sociedad de la información 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ón en materia de reglamentaciones técnicas y de reglas relativas a los servicios de la sociedad de la información. En su virtud y en el ejercicio de las competencias atribuidas a la Dirección General de Ordenación del Juego, resuelve: Primero Primero. Aprobar el Modelo de datos del sistema de monitorización de la información correspondiente a los registros de operaciones de juego que se acompaña como anexo I. Segundo Segundo. Aprobar la estructura de ficheros del sistema de monitorización de datos en formato XSD (Definición XML), que se publicará en la sede electrónica de la Dirección General de la Ordenación del Juego. Tercero Tercero. Modificar el anexo I de la Resolución de 6 de octubre de 2014, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición por la que se desarrollan las especificaciones técnicas de juego, trazabilidad y seguridad que deben cumplir los sistemas técnicos de juego de carácter no reservado objeto de licencias otorgadas al amparo de la Ley 13/2011, de 27 de mayo, de regulación del juego. El anexo I de la Resolución de 6 de octubre de 2014, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición por la que se desarrollan las especificaciones técnicas de juego, trazabilidad y seguridad que deben cumplir los sistemas técnicos de juego de carácter no reservado objeto de licencias otorgadas al amparo de la Ley 13/2011, de 27 de mayo, de regulación del juego, queda modificado como sigue: Uno. El apartado 2.1.2 Conservación de copia de los documentos aportados queda redactado como sigue: «2.1.2 Conservación de copia de los documentos aportados. El operador establecerá los procedimientos técnicos necesarios para la conservación de la copia digital de los documentos aportados por los participantes estableciendo una tipificación del proceso de verificación realizado de acuerdo con la lista normalizada publicada en la página web de la DGOJ. Los documentos aportados deberán conservarse durante el periodo de actividad de la cuenta de juego y por un periodo de 4 años desde la cancelación de la cuenta.» Dos. El apartado 2.1.4 Servicios de verificación ofrecidos por la Dirección General de Ordenación del Juego queda redactado como sigue: «2.1.4 Servicios de verificación ofrecidos por la Dirección General de Ordenación del Juego. La Dirección General de Ordenación del Juego proporciona a los operadores un servicio online de verificación de los datos de identidad y fecha de nacimiento para participantes residentes en España: el servicio de verificación se basa en el NIF/NIE del participante. El operador registrará y conservará cuantas consultas realice al sistema de verificación de identidad, dejando constancia de la fecha, hora y minuto de la consulta. Los datos deberán ser conservados, junto con los correspondientes al registro de usuario, durante el período de vigencia del registro de usuario y durante los cuatro años siguientes a su cancelación o anulación. La Dirección General de Ordenación del Juego proporciona a los operadores dos servicios online de verificación para la inscripción de los participantes en el Registro General de Interdicciones de Acceso al Juego: – Un servicio de verificación de la inscripción de un participante en el Registro General de Interdicciones de Acceso al Juego para participantes residentes en España a partir de NIF/NIE. Los operadores deberán utilizar este servicio para comprobar la inscripción en el proceso de registro de usuario. – Un servicio de consulta de las variaciones (altas/bajas) en la inscripción en el Registro General de Interdicciones de Acceso al Juego, correspondientes a los participantes que previamente hubiera verificado el operador. Los operadores deberán utilizar este servicio cada hora para verificar las variaciones en la inscripción 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án ser conservados, junto con los correspondientes al registro de usuario, durante el período de vigencia del registro de usuario y durante los cuatro años siguientes a su cancelación o anulación.» Tres. El apartado 2.1.5 Activación del registro de usuario y limitación en la participación queda redactado como sigue: «2.1.5 Activación del registro de usuario y limitación en la participación. El operador dispondrá de un procedimiento documentado de registro y activación de usuario que recogerá los requisitos de identificación y limitación de la participación establecidos en los artículos 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ón del juego, en lo relativo a los requisitos técnicos 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ón de los participantes en los juegos que organicen o desarrollen. Asimismo, el operador deberá contar con un servicio de verificación 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ón de identidad. Los operadores deberán registrar y conservar la totalidad de las gestiones, consultas y requerimientos que hubieran realizado para la verificación de los datos aportados por los solicitantes, así como cuantos documentos hubieran recibido o empleado con este fin. Los datos deberán ser conservados, junto con los correspondientes al registro de usuario, durante el período de vigencia del registro de usuario y durante los cuatro años siguientes a su cancelación o anulación.» Cuatro. El apartado 2.1.14 Registro de la configuración de la sesión destinada al juego de máquinas de azar queda redactado como sigue: «2.1.14 Registro de la configuración de la sesión de juego bajo la licencia general de ''Otros juegos''. En el caso de la Licencia General de Otros Juegos, los operadores deberán registrar y conservar los datos relativos a la configuración por parte del usuario de cada una de sus sesiones de juego bajo la licencia general de «Otros juegos», según lo establecido en el artículo 13 del Real Decreto 176/2023, de 14 de marzo, por el que se desarrollan entornos más seguros de juego.» Cinco. Se añade un nuevo apartado 2.1.15 Registro de las comunicaciones del servicio de atención al jugador, con la siguiente redacción: «2.1.15 Registro de las comunicaciones del servicio de atención al jugador. El operador deberá registrar y conservar durante dos años las comunicaciones con los participantes a través de los diferentes canales del servicio de atención al jugador.» Seis. El apartado 2.3.1 Registro de las operaciones de pago y cobro queda redactado como sigue: «2.3.1 Registro de las operaciones de pago y cobro. El operador deberá conservar o estar en disposición de obtener el apunte detallado de cada operación de depósito o retirada junto con toda la información asociada a cada operación, independientemente de que utilice medios propios o de terceros. El operador establecerá los procedimientos técnicos necesarios para la conservación de la copia digital de los documentos aportados por los participantes estableciendo una tipificación del proceso de verificación realizado de acuerdo con la lista normalizada publicada en la página web de la DGOJ. Cuando se utilicen servicios de tarificación adicional, el operador deberá conservar la información relativa al importe de participación y al identificador de juego o concurso en que el que tuvo lugar la participación, y estar en disposición de obtener el número de teléfono y la cuenta utilizados para facturar la participación al jugador.» Siete. El apartado 2.4.1 Protección de datos queda redactado como sigue: «2.4.1 Protección de datos. Los operadores establecerán los procedimientos técnicos adecuados para mantener la privacidad de los datos de los participantes de conformidad con la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales, y su normativa complementaria. Los operadores deberán asimismo implantar sobre los ficheros y tratamientos las medidas de seguridad establecidas en la normativa vigente en materia de protección de datos y dar cumplimiento al deber de secreto impuesto por dicha normativa.» Ocho. La letra d) del apartado 4.13 Gestión de cambios queda redactada como sigue: «d) Se conservarán copias del código fuente, o de los binarios o de otros formatos que permitan su posterior despliegue y auditoría, de los elementos de software de todas las versiones software que se hayan utilizado en el sistema técnico efectivamente empleado en los últimos cuatro años. La Dirección General de Ordenación del Juego podrá establecer la obligación de que el procedimiento de conservación de las copias de los elementos de software incluya una huella digital de los mismos.» Nueve. El apartado 5.1.13 Conservación de la información del SCI queda redactado como sigue: «5.1.13 Conservación de la información del SCI. El almacén debe conservar sus datos por un periodo mínimo de cuatro años. Los operadores de juego tendrán la obligación de facilitar y permitir a la Dirección General de Ordenación del Juego el acceso online a la información correspondiente a los doce últimos meses de actividad registrada en el almacén. Los operadores deberán tener previsto un procedimiento de recuperación de la información correspondiente a un periodo mínimo de cuatro años.» Diez. El apartado 5.1.14 Ubicación del almacén en España queda redactado como sigue: «5.1.14 Ubicación del almacén en la Unión Europea. El almacén o almacenes del SCI, así como sus copias de seguridad o sitios de réplica secundarios, deberán estar ubicados en la Unión Europea, con la finalidad de realizar las operaciones de verificación y control de la información. La ubicación y cualquier modificación de esta deberán ser comunicadas a la Dirección General de Ordenación del Juego.» Once. El apartado 6.1 Registro y trazabilidad queda redactado como sigue: «6.1 Registros 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ón en el desarrollo del juego, en el registro de usuario, en las cuentas de juego o en los medios de pago. En relación con los datos de desarrollo del juego, los datos deberán poder reconstruir todos los lances del juego que pudieran tener repercusión sobre su desarrollo. El Sistema Técnico de Juego también debe conservar registros y logs en materia de seguridad de los sistemas de información. Todos los referidos registros y logs deberán ser accesibles online para la Dirección General de Ordenación 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ón a la Dirección General de Ordenación del Juego. Sin perjuicio de lo anterior, los registros y logs deben ser conservados en almacenamiento durante al menos cuatro años. Los operadores deberán tener previsto un procedimiento de recuperación de esta información. Los registros y logs estarán diseñados de forma que se evite la posibilidad de borrado o modificación. Cualquier actuación de borrado que el operador deba realizar, por ejemplo, para corregir errores técnicos, deberá ser debidamente aprobada por el operador y se conservará la documentación justificativa de los ajustes realizados.» Cuarto Cuarto. Modificar el anexo I de Resolución de 12 de julio de 2012, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición que desarrolla los artículos 26 y 27 del Real Decreto 1613/2011, de 14 de noviembre, en relación con la identificación de los participantes en los juegos y el control de las prohibiciones subjetivas a la participación. El anexo I de la Resolución de 12 de julio de 2012, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición que desarrolla los artículos 26 y 27 del Real Decreto 1613/2011, de 14 de noviembre, en relación con la identificación de los participantes en los juegos y el control de las prohibiciones subjetivas a la participación, queda modificado como sigue: Único. El punto 5 del apartado séptimo. Verificación a través del Sistema de Verificación de Identidad, queda redactado como sigue: «5. El operador registrará y conservará cuantas consultas realice al sistema de verificación de identidad, dejando constancia de la fecha, hora y minuto de la consulta. Los datos deberán ser conservados, junto con los correspondientes al registro de usuario, durante el período de vigencia del registro de usuario y durante los cuatro años siguientes a su cancelación o anulación.» Quinto Quinto. A la entrada en vigor de la presente resolución queda derogada la Resolución de 6 de octubre de 2014, de la Dirección general de Ordenación del Juego, por la que se aprueba el modelo de datos del sistema de monitorización de la información correspondiente a los registros de operaciones de juego. Sexto Sexto. La presente resolución entrará en vigor a los nueve meses de su publicación en el «Boletín Oficial del Estado», sin perjuicio de que aquellos operadores que hubieran podido adaptar sus sistemas al modelo de datos aprobado en la misma puedan, de forma facultativa, empezar a utilizarlo en sus relaciones con la DGOJ a partir de los seis meses desde la publicación de esta resolución. [firma] Madrid, 6 de junio de 2024.–El Director General de Ordenación del Juego, Mikel Arana Echezarreta. ANEXO I ANEXO I Modelo de datos del sistema de monitorización de la información correspondiente a los registros de operaciones de juego Índice 1. Contenido. 2. Definiciones. 3. Modelo de datos funcional. 3.1 Tipos de información. 3.2 Obligación de reporte. 3.2.1 Obligaciones del gestor de liquidez compartida. 3.3 Periodicidad. 3.4 Descripción de la información. 3.4.1 Registro de usuario. 3.4.2 Registro de Cuenta de juego. 3.4.3 Registro de Cuenta del operador. 3.4.4 Registros de Datos de Juego. 3.4.4.1 Registro JUC: juegos. 3.4.5 Registro de Ajustes de Apuestas. 3.4.6 Registro de Catálogo de eventos. 3.4.7 Rectificaciones. 3.4.8 Clasificaciones y normalizaciones. 4. Modelo técnico. 4.1 Estructura de la información. 4.1.1 Registros. 4.1.2 Subregistros. 4.1.3 Lote. 4.1.4 Firma del lote. 4.1.5 Compresión y cifrado del lote. 4.2 Estructura de directorios. 4.3 Empaquetado de los datos de juegos. 4.4 Nomenclatura de archivos. 4.4.1 RU: Registro de Usuario. 4.4.2 CJ: Cuenta de juego. 4.4.3 OP: Cuenta de Operador. 4.4.4 JU: Registro de Juego. 4.4.5 JUA: Ajustes de Apuestas y CEV: Catálogo de Eventos. 4.5 Conceptos generales. 4.5.1 OperadorId. 4.5.2 AlmacenId. 4.5.3 Registro. 4.5.4 Rectificaciones. 4.5.5 Registros periódicos. 4.5.6 Registros de Juego (JUC). 4.5.7 Lote. 4.5.8 Periodicidad y fragmentación. 4.5.9 Tipos de movimiento libres. 4.5.10 Desgloses que se repiten varias veces. 4.5.11 Sobre campos económicos vacíos en ficheros. 1. Anexos. 1.1 Listas y enumerados. CambioEnDatos: Cambio en datos (RUD). ConceptoBonos: Concepto bonos (CJD, CJT, CJR). ConceptoOPT: Ajustes de cuenta del operador (OPT, ORT). EstadoCNJ: Estado CNJ (RUD, RUR, RUT). ListaCodigo: Lista de códigos de eventos admitidos (CEV). MotivoEstado: Motivo por el cual la cuenta del jugador ha sido Suspendida o Cancelada (RUD). MotivoFinSesion: Motivo por el cual se ha cerrado la sesión (RegistroOtrosJuegos, RegistroLoteriaPresorteada). PaisISO: Países y territorios según el código ISO de 2 caracteres (RUD, RUG, CEV). (Códigos ISO 3166). PerfilJugador: Perfil del jugador especial según RD de juego seguro (RUD). PeriodoLimite: Periodo al que aplica el límite del jugador (RUD). Sexo: Sexo del jugador (RUD, RUR). SexoCompeticion: Género a la que pertenece la competición deportiva (CEV). TipoApuesta: Tipo de apuesta realizada (RegistroApuestaContrapartida, RegistroApuestaMutua). TipoDispositivo: Tipo de dispositivo del jugador (CJD, RUD, RegistroPoquerTorneo, RegistroApuestaContrapartida, RegistroApuestaMutua, RegistroLoteriaPresorteada). TipoDocumento: Tipo de documento aportado por el jugador no residente (RUD, RUG). TipoJuego: Tipo de juego (todos los registros). TipoLimite: Tipo de limite (RUD). TipoMedioPago: Lista de códigos de medios de pago admitidos (CJD). TipoRegistro: Tipos de registro JUC. TipoResultado: Resultado de la operación de depósito o retirada (CJD). TipoVerificacionDocumental: Tipo de verificación documental del jugador realizada (RUD). UnidadLimite: Valores posibles de las unidades de los límites del jugador (RUD). VariantePoker: Variante de juego de póquer (RegistroPoquerTorneo). VarianteSesion: Variantes de los juegos de Póquer Cash, Black Jack y Ruleta (RegistroOtrosJuegos). 1.2 Tipos de campos. Campos de cadena de caracteres. Campos numéricos. Campos de tipo fecha. 1. Contenido 1. Contenido El presente anexo contiene el modelo de datos funcional y el modelo técnico del sistema de monitorización de la información correspondiente a los registros de operaciones de juego. 2. Definiciones 2. Definiciones Registro de usuario. Se entiende por registro de usuario el registro único 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ón del participante, los límites del jugador o su estado dentro de la plataforma del operador. Cuenta de juego. Se entiende por cuenta de juego a la cuenta o cuentas abiertas por el participante, de forma vinculada a su registro de usuario, en la que se cargan los ingresos de las cantidades económicas destinadas por éste al pago de la participación en las actividades de juego y se abonan los importes de los premios obtenidos por la participación. Incluye tanto la cuenta en euros como el resto de las cuentas de bonos y participaciones gratuitas. Juego sin registro de usuario previo. Juegos autorizados por la DGOJ para la participación sin la previa identificación de los participantes. Operador gestor de registro de usuario. Operador donde el jugador realiza el registro de usuario. Operador coorganizador. Operador que gestiona plataformas de juego en las que sean miembros o se adhieran otros operadores de juego que pongan en común cantidades jugadas por sus respectivos usuarios. Juego coorganizado en red. Juego que es gestionado por operadores coorganizadores. Operador adscrito a una red. Operador que se adhiere a una red coorganizada a la que aporta las cantidades jugadas por sus usuarios. Gestor de botes compartidos. Operador que gestiona las contribuciones y los premios de botes compartidos en red. Jugadores con actividad. Número de jugadores que hayan realizado al menos una apuesta en euros durante el periodo. GGR (Gross Gaming Revenue). Importe total de las cantidades que se dediquen a la participación en el juego, así como cualquier otro ingreso que el operador pueda obtener, directamente derivado de la organización o celebración de los juegos, deducidos los premios satisfechos por el operador a los participantes. Cuando se trate de apuestas cruzadas o de juegos en los que el operador no obtenga como ingresos propios los importes jugados, sino que, simplemente, efectúen su traslado a los jugadores que los hubieran ganado, estará formado por las comisiones, así como por cualesquiera cantidades obtenidas por servicios relacionados con las actividades de juego, cualquiera que sea su denominación, pagadas por los jugadores al operador. Botes. Cantidades jugadas por los jugadores e incorporadas a botes de máquinas de azar, premios adicionales del bingo, fondos de juego no repartido por ausencia de ganadores de una categoría en las apuestas mutuas, y en general todos los fondos de juego que se hubieran dotado o constituido en una partida o juego y que vayan a ser repartidos o aplicados en una partida o juego distinto. Bonos. Actividades de promoción o promociones: bonos, bonificaciones, descuentos, regalos de apuestas o partidas, multiplicadores de cuotas o premios, ofertas o cualquier otro mecanismo similar, gratuito o sujeto a condiciones, destinado a promover de forma efectiva la participación en el juego, o la fidelización de clientes. Quedan excluidos de las actividades de promoción los mecanismos de distribución del fondo para premios acumulados en un determinado juego. Partidas vivas. Las partidas o juegos cuya comercialización se ha iniciado pero que, en el momento de generar la información contable, no han concluido y que por tanto no se conoce el participante o participantes ganadores. Tipos Medio de pago. Clasificación de los diferentes medios de pago usados por el operador en las transacciones económicas con los participantes. Medio de pago. Nombre del proveedor de servicios de pago o del medio de pago concreto. Sesión de usuario. Período de tiempo que un usuario permanece conectado al sitio web del operador, y que comprende desde la autenticación valida del usuario en el sistema hasta la desconexión del mismo. Sesión de juego. Sesión de juego bajo la licencia general de «Otros juegos»: Conjunto de partidas, manos o tiradas jugadas por un participante en cualquiera de los juegos ofertados por un operador bajo la licencia general de «Otros juegos», durante un periodo de tiempo delimitado. El establecimiento de la sesión de juegos aplica a los siguientes juegos: póquer cash, bingo, máquinas de azar, blackjack, ruleta, juegos complementarios y punto y banca. Sesión de juego de lotería instantánea o presorteada: Conjunto de billetes, boletos o cualquier otra forma de participación adquirida por un jugador en esta modalidad de juego durante un periodo de tiempo delimitado. Activación del Registro de Usuario. La activación del Registro de Usuario es el proceso a través 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. Juego ofertado en un entorno de liquidez internacional. Aquel en el que las cantidades económicas que se dedican a la participación en el juego provienen de jugadores con registro de usuario español y de jugadores sin registro de usuario español. Gestor de liquidez internacional. El operador que gestiona un juego ofertado en un entorno de liquidez internacional. Jugador con registro de usuario español. 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ón del juego. 3. Modelo de datos funcional 3. Modelo de datos funcional 3.1 Tipos de información. Atendiendo a su naturaleza, la información que debe ser recogida en el Almacén del Sistema de Control Interno del operador (SCI) se clasificará en las siguientes categorías: 1. Registro de usuario. El Registro de Usuario recoge los datos de identificación de los participantes, los relativos a los límites de depósitos y otros datos de configuración tales como el estado del participante en la plataforma de juego. Se definen los siguientes tipos de archivo para el registro de usuario: 1. El Registro de Usuario detallado (RUD) que deberán reportar los operadores que tienen relación directa con los participantes y gestionan los contratos de juego. 2. El Registro de Usuario de los operadores de red (RUR) que deberán reportar los operadores coorganizadores que gestionen una red de juego. 3. El registro de usuario ganadores en juegos con participación sin registro de usuario previo (RUG), recoge los datos relativos a los participantes premiados en los juegos autorizados para la participación sin registro de usuario previo. 4. El Registro de Usuario totalizado (RUT), como registro de control de la integridad de los datos. 2. Cuenta de juego de los participantes. El registro Cuenta de Juego incluye, para cada periodo y participante, el saldo inicial, las transacciones realizadas por depósitos o retiradas, los bonos que se le hayan reconocido, las participaciones en los juegos, los premios obtenidos y cualquier otro movimiento realizado en la cuenta, así como el saldo final. La cuenta de juego es un reflejo de la información que el propio participante puede obtener cuando accede a su cuenta de juego en la plataforma de juego. Se definen los siguientes tipos de archivo para la cuenta de juego: 1. La cuenta de juego detallada (CJD) con los detalles de las cuentas de juego de cada jugador. 2. Los totales de la cuenta de juego (CJT) como registro de control de integridad de los datos. 3. Cuenta de operador. La Cuenta de Operador es un reflejo de la cuenta de ingresos por juego del operador. Deberá permitir el cálculo de los ingresos brutos (GGR, gross gaming revenue) del operador y, en los casos de redes de operadores, la distribución entre los participantes de la red de los ingresos por juego generados para cada uno de los juegos ofertados por el operador. Se definen dos tipos de archivo para la cuenta de operador: 1. La cuenta de operador completa (OPT), para aquellos operadores que gestionen el registro de usuario o sean operadores adscritos a una red. 2. La cuenta de operador coorganizador (ORT) para aquellos operadores que gestionen la plataforma de juego en una red coorganizada. 4. Cuenta de botes y partidas vivas. La Cuenta de Botes recoge la información correspondiente a cantidades, jugadas por los participantes, incorporadas a botes de máquinas de azar, premios adicionales del bingo, fondos de juego no repartidos por ausencia de ganadores de una categoría en las apuestas mutuas, y en general todos los fondos de juego que se hubieran dotado o constituido en una partida o juego y que vayan a ser repartidos o aplicados en una partida o juego distinto. La Cuenta de Partidas Vivas es un reflejo del saldo del fondo de juego correspondiente a las partidas que al final del periodo considerado no han concluido por lo que no se conoce el participante o participantes ganadores. La información de la cuenta de botes y de la cuenta de partidas vivas es remitida a través del archivo BOT. 5. Registro de juego. El Registro de Juego recoge los datos de detalle de los juegos, con información específica de cada tipo de juego. El registro de juego deberá ser reportado por los operadores que gestionen el registro de usuario. El tipo de archivo registro de juego (JUC) contiene los datos del juego y de los jugadores implicados, así como sus participaciones, premios y botes. 6. Ajustes de Apuestas. Los Ajustes de Apuestas (JUA) recogen los datos normalizados de aquellas modificaciones realizadas sobre premios de apuestas –por anulación de la apuesta, modificación de cuota, o por cualquier otra circunstancia– que son efectuadas con posterioridad al momento en que se ha reportado la existencia del premio. 7. Catálogo de Eventos. El Catálogo de Eventos (CEV) incluye los datos normalizados de los eventos deportivos que componen la oferta de apuestas del operador. Recogerá todos los eventos sobre los que el operador ha comercializado apuestas en el periodo. 3.2 Obligación de reporte. La obligación de los operadores de reportar los tipos de información descritos en el apartado anterior se recoge en el siguiente cuadro: √ (RUD, RUT) √ (CJD, CJT) √ (OPT) √ (BOT) √ (JUC) √ (JUA) √ (CEV) √ (RUD, RUT) √ (CJD, CJT) √ (OPT) √ (RUR, RUT) √ (ORT) √ (BOT) √ (JUC) √ (BOT) √ (RUG) √ (OPT) √ (BOT) √ (JUC) Cuando un operador gestiona el registro de usuario tiene obligación de reportar el registro de usuario total y detallado, la cuenta de juego de los participantes total y detallada, la cuenta de operador, la cuenta de botes y partidas vidas, los registros de juego para dichos juegos y, en su caso, ajustes de apuestas y catálogo de eventos. Cuando se trata de un juego coorganizado en red el operador adscrito a la red de juego no tiene obligación de reportar la cuenta de botes y partidas vidas, ni los registros de juego para dicho juego, salvo en los juegos que formen parte de la sesión de otros juegos (ej. póquer cash). Sí tiene obligación de reportar el registro de usuario total y detallado, la cuenta de juego y la cuenta de operador. El operador coorganizador tiene obligación de reportar el registro de usuario de red, la cuenta de operador coorganizador de red, la cuenta de botes y partidas vidas y los registros de juego. El operador gestor de botes compartidos solo tiene que reportar la cuenta de botes. En el caso de juegos sin registro de usuario previo, el operador deberá reportar el registro de ganadores, la cuenta del operador, los registros de juego y en su caso, la cuenta de botes y partidas vivas. 3.2.1 Obligaciones del gestor de liquidez compartida. El gestor de liquidez internacional solo deberá informar de los juegos en los que participe, al menos, un jugador con registro de usuario español. En los ficheros RUR/RUT, BOT, JUC solo se incluirán datos de jugadores con registro de usuario español. En el fichero ORT, se remitirá la información económica correspondiente a los juegos con liquidez internacional desglosada por operador (B2C) del dominio «.es» y por jurisdicción para los jugadores no pertenecientes al dominio «.es» que participen en el juego. 3.3 Periodicidad. La periodicidad del reporte de la información para cada tipo de registro se indica en la siguiente tabla: El envío al almacén de los registros de periodicidad diaria debe producirse antes de las 4 a.m. del día siguiente al día sobre el que se está informando. El envío al almacén de los registros de periodicidad mensual debe producirse antes de las 23:59 del primer día del mes siguiente. 3.4 Descripción de la información. En los siguientes apartados se detalla la información contenida en los registros. 3.4.1 Registro de usuario. 3.4.1.1 Registro RUD: Registro de usuario detallado. Información en el registro de usuario detallado. El registro de usuario detallado recoge los datos de identificación de los participantes, los relativos a los límites de depósitos y otros datos de configuración tales como el estado del participante en la plataforma de juego. Operadores obligados. El registro de usuario detallado debe ser reportado por los operadores que tienen relación directa con los participantes y gestionan los contratos de juego. Los operadores que comercialicen juegos con participación sin registro de usuario previo no deberán incluir en el tipo de información «registro de usuario detallado» la relativa a los ganadores ni a ningún otro participante. Periodicidad de la información. Diaria: El registro de usuario diario sólo contendrá los datos de los participantes nuevos o con alguna modificación en sus datos de registro de usuario (incluyendo límites, estado, perfil y exclusiones) durante el periodo. Mensual: El registro de usuario mensual contendrá los datos de todos los participantes existentes en la plataforma de juego, independientemente de si han experimentado o no modificaciones en sus datos durante el periodo, o de si su estado es activo o no. Descripción de la información contenida en el registro de usuario detallado: Se indica si durante el periodo se han producido el alta del participante, un cambio en los datos de registro o va a ser dado de baja: (A) Alta, jugador que superado la verificación de identidad. (N) No ha variado. (S) Sí ha variado. (B) Baja del jugador, se reportará «B» el mes anterior a que se vaya a eliminar al jugador del sistema. Según lista de códigos de acuerdo con el modelo 763 de autoliquidación del Impuesto sobre actividades de juego aprobado en Orden HAC/1363/2018, de 28 de noviembre. El código de región fiscal debe tener correspondencia con el código postal del domicilio fiscal. La lista se reproduce en el anexo 7.1 del documento de especificaciones técnicas. Residente. No residente. Datos identificativos del jugador. Para los participantes en España se indica obligatoriamente nacionalidad y documento identificador (NIF o NIE). Si el participante es Residente en España ha de tener obligatoriamente el campo Documento relleno con un NIF o NIE un identificador válido. El identificador válido puede consultarse en el epígrafe «Formato válido NIF y NIE». Para los participantes no residentes en España se indica la nacionalidad, país de residencia, y tipo y número del documento oficial utilizado como identificación. Los valores posibles para el tipo de documento se recogen en el epígrafe Tipo de Documento. En el caso de que se utilice el TipoDocumento=OT (Otros), deberá especificar el tipo de documento en EspecificarTipoDocumento. El valor a trasmitir en el campo Documento es el que existe en el registro de usuario de la plataforma de juego. Datos del domicilio declarado: Dirección, Ciudad, Código postal y País. El país indicado en el domicilio tendrá que ser coherente con los datos de identificación, concretamente con la información de residencia. El país se indicará mediante los códigos de país de dos dígitos correspondientes a la norma ISO 3166-1 alfa-2. Se reportará el límite válido al final del periodo reportado de todos los límites establecidos por el jugador y cualquier cambio que se haya producido en dicho periodo. TipoLimite: Depósito / Participacion /Gasto /Tiempo. Los límites de tipo depósito deben ser reportados para todos los jugadores en los tres periodos (diario, semanal y mensual). En el caso en que el jugador elimine un límite, el campo se rellenará con el valor Cantidad = «-1». UnidadLimite, unidad de medida del campo cantidad puede ser temporal (día, semana, mes, hora o minuto) o económica (EUR). FechaActivacionLimite es la fecha/hora a partir de la cual el nuevo límite es efectivo. FechaSolicitudCambioLimite es la fecha/hora en la que el jugador ha solicitado el cambio de límite. Campo opcional. En caso de que el jugador se autoexcluya en el periodo en que esté autoexcluido debe ser reportado. Se deben reportar todos los cambios que se hayan producido en el periodo. Cantidad y Unidad, tiempo por el que se excluye (3 días o 20 horas). FechaActivacion, momento en que se comienza la exclusión. FechaSolicitudCambioExclusión, fecha en la que el usuario solicita la autoexclusión. Autocontinuacion, «S» en caso de que el jugador haya solicitado la reactivación tras el periodo de exclusión. Siguiendo las definiciones de perfiles de jugadores especiales del Real Decreto 176/2023, de 14 de marzo, por el que se desarrollan entornos más seguros de juego, se reportarán las fechas de inicio y fin del jugador en el perfil correspondiente; si la fecha de fin no se conoce no se reportará. Campo opcional, será obligatorio en el periodo en el que el jugador esté dentro de uno de los perfiles. EstadoCNJ: es el estado actual en el que se encuentra el jugador en el momento de reporte, utilizando la codificación de la DGOJ, como se indica en el apartado «Estado del jugador». EstadoOperador: Es el estado del jugador con los códigos empleados por el operador. Motivo: Razón por la cual la cuenta del jugador ha sido Suspendida o Cancelada. Debe rellenarse obligatoriamente cuando EstadoCNJ sea «S» o «C» y omitirse para el resto de los casos: – MotivoSC: Razón por la cual la cuenta del jugador ha sido Suspendida o Cancelada. Se reportará un valor de la lista de enumerados disponible. – DescripcionSC: Detalle del motivo por el cual la cuenta del jugador ha sido Suspendida o Cancelada. Histórico: Es el histórico de estados por los que ha pasado el jugador en el periodo de tiempo reportado (día o mes). El histórico debe incluir también el estado actual. Desde: es la fecha desde que el jugador se encuentra en dicho estado. Cada EstadoCNJ puede corresponder con uno o varios EstadoOperador. Cada EstadoOperador solo puede corresponder con un EstadoCNJ. MotivoEstado solo debe rellenarse en caso de que EstadoCNJ sea S o C, y en ese caso es obligatorio. El histórico de estados debe ser completo y correcto en el periodo, con todas las fechas configuradas de forma adecuada. Fecha de la primera verificación positiva en el SVDI. Campo opcional, solo es obligatorio si VSVDI=«S». Tipo y fecha de la primera verificación documental positiva. Campo opcional, solo es obligatorio si VDocumental =«S». Tipo, es el modo en que se ha realizado la verificación documental. Detalle en el apartado «Listas y enumerados». Si el Tipo seleccionado no está en la lista y se selecciona OTR hay que rellenar el campo OtroEspecificar con los datos del Tipo de Verificación Documental utilizado. Campo opcional, obligatorio en caso de que el jugador se haya dado de alta en el periodo reportado. Contiene la dirección IP v4 ó v6 del dispositivo desde el que el jugador realizó el registro del alta. Campo opcional, obligatorio en caso de que el jugador se haya dado de alta en el periodo reportado. Contiene el tipo de dispositivo desde el que el jugador realizó el registro del alta. Campo opcional, obligatorio en caso de que el jugador se haya dado de alta en el periodo reportado. Contiene el identificador del dispositivo desde el que el jugador realizó el registro del alta. Controles Principales. – El número de identificación fiscal (NIF) o el número de identificación de extranjeros (NIE) debe tener un formato válido. Ver epígrafe «Formato válido del NIF y del NIE». – No se considerarán válidos aquellos registros de usuario que se declaren no residentes y simultáneamente indiquen España como su país de residencia. – Los límites del jugador se contrastarán con los reportados en el resto de los registros. – Los jugadores autoexcluidos no podrán tener participación, ni depósitos en los juegos correspondientes en el periodo definido. 3.4.1.2 Registro RUT: Registro de usuario totalizado. Información en el registro de usuario totalizado. El registro de usuario totalizado contiene el número de jugadores, altas, bajas, jugadores activos por periodo, así como los estados de los mismos. Operadores obligados. El registro de usuario totalizado debe ser reportado por los operadores que tienen relación directa con los participantes y gestionan los contratos de juego. También debe ser reportado por los operadores coorganizadores que gestionen una red de juego. Los operadores que comercialicen juegos con participación sin registro previo de usuario no deberán contar a los participantes de dichos juegos en el tipo de información «registro de usuario totalizado». En el caso de que el operador comercialice únicamente juegos con participación sin registro previo de usuario, no deberá transmitir el tipo de información «registro de usuario totalizado». Periodicidad de la información. Mensual: El registro contendrá el total de los participantes existentes en la plataforma de juego, independientemente de si han experimentado o no modificaciones en sus datos durante el periodo, o de si su estado es activo o no. Contenido del registro. Número total de jugadores al finalizar el periodo reportado cualquiera que sea su estado. El NumeroJugadores debe coincidir con el NumeroJugadores del periodo anterior más las altas menos las bajas del periodo actual. El NumeroJugadores debe coincidir con la suma de NumeroJugadoresPorEstado. Número de participantes dados de baja en la plataforma de juego durante el periodo. Un participante se considera que es baja en la plataforma de juego cuando su registro es borrado de dicha plataforma, sin menoscabo de que exista en otras bases de datos y backups en cumplimiento de la normativa. En el caso de que el participante pasa de un estado a otro diferente, pero su registro sigue existiendo en la plataforma de juego, entonces no se contabiliza como baja. Ese participante se contabiliza en el estado correspondiente. Número de usuarios con actividad durante periodo. Número de jugadores que hayan realizado al menos una apuesta en euros durante el periodo. Controles principales. – La suma de todos los jugadores agrupados por estados debe ser igual al número total de jugadores. – La suma de los jugadores del Registro de Usuario Detallado (RUD) mensual debe coincidir con el número de jugadores reportados en el Registro de Usuario Totalizada (RUT). – La suma de los jugadores del Registro de Usuario de los operadores de Red (RUR) debe coincidir con el número de jugadores reportados en el Registro de Usuario Totalizada (RUT). 3.4.1.3 Registro RUR: Registro de usuario en la red. Información en el registro de usuario en la red. El registro de usuario en la red recoge los datos de identificación de los participantes en la red coorganizada, estos datos se corresponderán con el identificador del operador en el cual está registrado el jugador y su identificador en dicho operador, además debe incluir el estado del participante en la plataforma de juego (activo, suspendido, bloqueado, …). El registro de usuario en la red contendrá todos los datos de los participantes dados de alta en la plataforma de juego, independientemente de si han experimentado o no modificaciones en sus datos durante el periodo, o de si su estado es activo o no. Operadores obligados. El registro de usuario en la red debe ser reportado por los operadores coorganizadores que gestionen una red de juego. Periodicidad de la información. Mensual: contendrá los datos de todos los participantes dados de alta en la plataforma de juego coorganizada independientemente del estado del jugador. Contenido del registro. Identificación del jugador. El operador de red debe indicar siempre el JugadorId del coorganizador de red. Y además indicará OperadorId del operador adscrito a la red que aporta al participante, y en caso de conocer el JugadorId en dicho operador, también deberá indicarlo. Estado actual del participante en la plataforma en el momento de remisión del registro, en base a la clasificación proporcionada en el epígrafe «Estado del jugador». Se indicará tanto el estadoCNJ como el estado del operador. Controles Principales. – Correspondencia con los usuarios de los operadores clientes de la red: Los identificadores de jugadores que participan en juegos en red deberán coincidir con los identificadores adicionales indicados por el operador cliente en su registro de usuario detallado (RUD). 3.4.1.4 RegistroRUG: Registro de Usuarios Ganadores. Información del registro de ganadores en juegos sin registro de usuario previo. El registro de usuarios ganadores recoge los datos de identificación de los participantes que han obtenido uno o varios premios en juegos sin registro de usuario previo. Operadores obligados. Deberán presentar este registro de usuarios los operadores autorizados a comercializar juegos con participación sin registro previo de usuario. Periodicidad. Mensual. Contendrá todos los usuarios que han obtenido premios durante el periodo. Contenido del registro. En cada periodo, se incluirá la información correspondiente a los usuarios ganadores por premios reconocidos en el periodo. Descripción de la información contenida en el registro. Los campos empleados tienen el mismo significado que en el RUD. Además, tienen los siguientes campos particulares que se usarán para los ganadores de premios de loterías sujetos a verificación de identidad por la normativa de prevención de blanqueo de capitales: 3.4.2 Registro de Cuenta de juego. 3.4.2.1 Registro CJD: Cuenta de juego detallada. Información en la cuenta de juego detallada. La cuenta de juego es un reflejo de la información que el propio participante puede obtener cuando accede a su cuenta de juego en la plataforma de juego. Incluye, para cada periodo y participante, los totales correspondientes al saldo inicial, las transacciones realizadas por depósitos o retiradas, los bonos que se le hayan reconocido, las participaciones en los juegos, los premios obtenidos y cualquier otro movimiento realizado en la cuenta, así como el saldo final en cada periodo. En la cuenta de juego se incluirán todos los movimientos realizados, tanto si se contabilizan en unidades monetarias como los contabilizados en cualquier otra unidad como puntos, u otros, indicándose en cada caso la unidad de medida utilizada. Los valores monetarios deberán ser expresados en euros. Puesto que la cuenta de juego es un reflejo de la información que el propio participante puede obtener cuando accede a su registro de usuario y cuenta de juego, los movimientos que supongan un incremento del saldo del jugador como depósitos realizados, bonos reconocidos o premios, se registrarán con signo positivo. Todos los movimientos que supongan una disminución del saldo del jugador como participaciones en los juegos o retiradas de fondos se registrarán con signo negativo. Operadores obligados. La cuenta de juego deberá ser reportada por todos los operadores que gestionan registros de usuario. Los jugadores se identificarán mediante el identificador único de jugador asociado a éste en el proceso de registro en la plataforma. Se reportarán todos los conceptos económicos de la cuenta de juego, con independencia de que el operador esté adscrito o no a una red. Los operadores que comercialicen juegos con participación sin registro previo de usuario no deberán incluir en el tipo de información «cuenta de juego» la relativa a los ganadores ni a ningún otro participante en dichos juegos. En el caso de que el operador comercialice únicamente juegos con participación sin registro previo de usuario, no deberá transmitir el tipo de información «cuenta de juego». Periodicidad. – Diaria. Diariamente se incluirá la información de las cuentas de juego que hayan presentado algún tipo de movimiento durante el día. – Mensual. Mensualmente se incluirá la información de todas las cuentas de juego registradas en la plataforma del operador. Contenido del registro. Para cada uno de los participantes con cuenta de juego en la plataforma se incluirá la siguiente información: Identificación única del jugador en la plataforma. Saldo al principio del período. Se reflejará el saldo inicial total de cada una de las unidades en las que el jugador tenga algún valor, por ejemplo, bonos, puntos o freebets. (+/-) Se reflejarán con signo positivo los saldos deudores para el participante y con signo negativo los saldos que, con carácter excepcional, sean acreedores para el participante. El saldo de la unidad euros es obligatorio. Se reportará cada operación de depósito que haya tenido su reflejo en la cuenta de juego, con independencia de que la operación se complete o sea anulada con posterioridad. (+/-) Se reflejarán con signo positivo los importes depositados por los participantes y con signo negativo las posibles anulaciones o ajustes realizados. Se consignará el total del importe en euros depositado durante el período, de acuerdo con los criterios previamente establecidos, así como el desglose de cada uno de ellos: Fecha: la fecha en la que el importe se refleja en la cuenta del jugador. Importe: en euros. MedioPago: proveedor del medio de pago. TipoMedioPago: código del tipo de medio de pago utilizado - basado en la lista de medios de pago incluida en el apartado «Listas y enumerados». En caso de no saber el código, se utilizará el «99» y se rellenará la información del campo «OtroTipoEspecificar» indicando el medio de pago utilizado con la terminología más sencilla y clara posible. Con posterioridad será objeto de tipificación. TitularidadVerificada: «S» si la titularidad del medio de pago ha sido verificada por el operador. Entidad: a la que pertenece el medio de pago. IdEntidad: Identificador alfanumérico de la entidad del medio de pago, cuando proceda. UltimosDigitosMedioPago: 4 últimos dígitos del medio de pago, cuando proceda. ResultadoOperacion: informe sobre la transacción. Detalle en el apartado «Listas y enumerados». IP: Dirección IP del dispositivo desde el que se ha realizado el login a la sesión del jugador en la que se realiza el depósito, puede ser IPv4 o IPv6. Dispositivo: desde el que se realiza el login a la sesión (Móvil, PC, Tablet, Terminal fijo u Otro). Id Dispositivo: Identificador del dispositivo desde el que se realiza el login a la sesión. InformacionAuxiliar: Cualquier información que conozca el operador sobre le medio de pago utilizado (Id vendedor de Paypal; N.º tarjeta Skrill, etc). Se reportará cada operación de retirada que haya tenido su reflejo en la cuenta de juego, con independencia de que la operación se complete o sea anulada con posterioridad. (+/-) Se reflejarán con signo negativo los importes retirados por los participantes de su cuenta de juego y con signo positivo las posibles anulaciones o ajustes realizados. Se consignará el total del importe en euros retirado durante el período, de acuerdo con los criterios previamente establecidos, así como el desglose de cada uno de ellos. Se determinará el importe completo de la participación desglosado por cada una de las unidades y por el tipo de juego. Se incluirán las cantidades destinadas por el participante a la participación en el juego, las comisiones o cualesquiera otras cantidades por servicios relacionados con las actividades de juego pagadas por los participantes al operador. Las devoluciones, ajustes o anulaciones en participaciones se reflejarán en su apartado correspondiente de «ParticipacionDevolucion». (-) Las participaciones en los juegos se reflejarán con signo negativo. Se determinará el importe completo de la devolución de la participación desglosado por cada una de las unidades y por tipo de juego. Se incluirán los importes correspondientes a las devoluciones, ajustes o anulaciones en participaciones realizadas con posterioridad a su formalización. (+) Las devoluciones de participaciones se reflejarán con signo positivo. Se determinará el importe completo de los Premios desglosado por cada una de las unidades y tipo de juego. Se incluirán los importes reconocidos al participante por premios monetarios en el juego. (+) Los premios reconocidos en los juegos se reflejarán con signo positivo. Los ajustes o anulaciones en premios se reflejarán en su apartado correspondiente de «AjustePremios». Se incluirán las cantidades cargadas o abonadas por el operador en la cuenta de juego del participante por ajustes en premios reconocidos con anterioridad, derivados de modificaciones o anulaciones. (+/-) Se reflejarán con signo positivo cuando el ajuste suponga un mayor premio reconocido al participante y con signo negativo en caso contrario. Se determinará el importe completo de los Ajustes de Premios desglosado por cada una de las unidades y tipo de juego. Se registrarán los importes que se transfieran desde las cuentas de juego de un mismo participante gestionadas por otro operador. Los apuntes se desglosarán por cada una de las unidades y por operador del que provengan los fondos. Los importes deberán reportarse en el momento en que se tenga conocimiento de ellos y se reflejen en la cuenta del jugador. El signo con el que se consignarán estas cantidades será: – (+) Positivo en la cuenta de juego que recibe la transferencia del importe. Se registrarán los importes que se transfieran hacia las cuentas de juego de un mismo participante gestionadas por otro operador. Los apuntes se desglosarán por cada una de las unidades y por operador destinatario de los fondos. Los importes deberán reportarse en el momento en que se tenga conocimiento de ellos y se reflejen en la cuenta del jugador. El signo con el que se consignarán estas cantidades será: – (-) Negativo en la cuenta de juego que genera la transferencia del importe. Incluirá cualquier movimiento en la cuenta de juego por un concepto diferente a los ya referidos. En los apuntes se indicará el concepto con un nivel de detalle equivalente al usado por el operador en su contabilidad de la cuenta de juego. Se proporcionará el desglose por concepto que originó dicha variación. (+/-) Se reflejarán con signo positivo cuando el movimiento suponga un incremento en la cuenta de jugador y con signo negativo en caso contrario. Se registrarán los saldos de los participantes en su cuenta de juego al final del periodo. (+/-) Se reflejarán con signo positivo los saldos deudores para el participante o con signo negativo los saldos que, con carácter excepcional, sean acreedores para el participante. Se reflejará el saldo final total y desglosado por cada una de las unidades en las que el jugador puede mantener un saldo. El saldo de la unidad euros es obligatorio. Desglose del saldo final, para cada una de las cuentas de juego que puede tener el mismo jugador: Cuenta es el identificador de la cuenta de juego en la plataforma. Se registrará el importe de las comisiones o cualesquiera otras cantidades satisfechas por servicios relacionados con las actividades de juego pagadas por los participantes, o bien con las cantidades detraídas de los premios obtenidos del operador. (-) Se reflejarán con signo negativo las comisiones satisfechas deducidas las posibles anulaciones o ajustes realizados. Importe de la participación del jugador que se considera comisión del operador, totalizada y desglosada por tipo de juego. La comisión no se tendrá en cuanta para el cálculo de los saldos de cuenta del jugador. Se incluirán todas las transacciones promocionales (bonos por registro, por depósito, o de cualquier otra naturaleza) reconocidas al participante y se contabilizarán en su unidad correspondiente (EUR, Eurobonos, Puntos, Freebets, Freespins,…). Las transacciones serán categorizadas atendiendo a los siguientes conceptos: CONCESION, CANCELACION y LIBERACION. Se reportará el total de cada una de las unidades y el desglose de cada uno de los movimientos con los siguientes campos: (+) Se reflejarán con signo positivo las transacciones que incrementen el saldo contable en su unidad correspondiente: – cuando se conceda un bono y sea reconocido por el participante. – cuando se incremente el saldo del jugador en EUR motivado por una liberación del bono. (-) Se reflejarán con signo negativo las transacciones que decrementen el saldo contable: – cuando se produzca una cancelación de bonos en la cuenta del participante. – cuando se liberen los bonos en EUROS. Fecha: en la que se produce la concesión, cancelación o liberación. FechaActivación: fecha en la que el jugador acepta la promoción y se incorpora a su saldo de cuenta. Solo para concesión. Importe del movimiento. En caso de LIBERACION habrá dos importes, uno positivo en EUR y otro negativo en la unidad que se esté liberando. Se incluirán los importes reconocidos al participante por premios no monetarios en el juego. Se registrará su valor en euros, según los criterios de valoración usados por el operador en su contabilidad. (+) Se reflejarán con signo positivo los premios reconocidos deducidas las posibles anulaciones o ajustes realizados. Además, se solicitan los siguientes campos: TipoJuego: Juego en el que se ha concedido el premio en especie. Descripción del premio. Total: Valor en euros del premio concedido. Fecha en la que se ha concedido. Los premios en especie no afectan al saldo de la cuenta del jugador. Se incluirán todos los regalos o premios que no provengan de participaciones en un juego. Se reportará el valor en euros de los regalos concedidos. (+) Se reflejarán con signo positivo los premios reconocidos deducidas las posibles anulaciones o ajustes realizados. Se reportará su valor en euros, además de una descripción del regalo y la fecha en que se concede. Los regalos no afectan al saldo de la cuenta del jugador. Controles Principales. – En todo momento, el saldo en la cuenta de juego para cada uno de los participantes reportado ha de ser igual al saldo que el propio participante puede obtener cuando accede a su registro de usuario y cuenta de juego. – El saldo inicial en cada periodo considerado para cada uno de los participantes debe coincidir con el saldo final del periodo inmediatamente anterior para cada una de las unidades. – Dentro de cada periodo el saldo final debe coincidir con el saldo inicial más los movimientos ocurridos durante el periodo para cada una de las unidades reportadas, sin considerar los importes incluidos en el registro Comisiones, Premios en Especie y Regalos que tienen carácter informativo. – Para cada participante deberán incluirse todos los movimientos realizados en el periodo de forma que quede explicado el saldo final a partir del saldo inicial y los movimientos del periodo en cada una de las unidades. Cualquier movimiento que modifique el saldo de la cuenta de juego y no se corresponda con depósitos, retiradas, participación, devolución de la participación, premios, premios en especie, ajustes o anulaciones en los premios, bonos o transferencias entre monederos, se incluirán en el apartado «Otros», donde se deberá utilizar el campo «concepto» para desglosar la tipología de «Otros» movimientos, siempre con un nivel de detalle equivalente al de la contabilidad del operador. – En el campo «Otros» no deben reportarse movimientos que pertenezcan a una categoría definida en el modelo, especialmente las cancelaciones o anulaciones de depósitos y retiradas deben ser reportadas en su categoría correspondiente. – El Total y el Desglose deben coincidir en todos los casos. 3.4.2.2 Registro CJT: Cuenta de juego totalizada. Información en totales de la cuenta de juego. El registro CJT contiene la información agregada de las cuentas de juego de los jugadores. El registro de totales de la cuenta de juego es un registro de control que permite comprobar que los datos de la cuenta de juego se han registrado de forma completa y correcta. Operadores obligados. El registro de totales de la cuenta de juego deberá ser reportado junto al registro de cuenta de juego detallada. Periodicidad. – Diaria. Diariamente se incluirá la información de las cuentas de juego que hayan presentado algún tipo de movimiento durante el día. Debe ser congruente con la cuenta de juego detallada correspondiente al mismo día. – Mensual. Mensualmente se incluirá la información de todas las cuentas de juego registradas en la plataforma del operador. Contenido del registro. La definición de los campos se corresponde exactamente con la proporcionada en el punto anterior, correspondiente al registro CJD, con las siguientes excepciones: – No hay identificador del jugador ni de la cuenta dado que son datos agregados. – El desglose de los Depósitos y Retiradas solo tiene los campos: MedioPago, TipoMedioPago e Importe. – Los campos Trans_IN y Trans_OUT no tienen desglose. – Bonos solo se desglosa por Concepto (CONCESION, LIBERACION y CANCELACION). – Premios en especie desglosa solo por tipo de juego. – No se reporta el campo Regalos. Controles Principales. – En los registros mensuales, el saldo inicial debe coincidir con el saldo final del mes inmediatamente anterior. – Dentro de cada periodo el saldo final debe coincidir con el saldo inicial más los movimientos ocurridos durante el periodo para cada una de las unidades reportadas, sin considerar los importes incluidos en los campos Comisiones, Premios en especie y Regalos. – Para cada uno de los conceptos, el importe incluido en el registro Cuenta de Juego Totalizada deberá ser igual a la suma de los importes detallados por participante en la Cuenta de Juego Detallada. 3.4.3 Registro de Cuenta del operador. 3.4.3.1 Registro OPT: Cuenta de operador completa. Información en la cuenta de operador completa. La cuenta del operador es un reflejo de la cuenta de ingresos por juego del operador. Deberá permitir el cálculo de los ingresos brutos (GGR, gross gaming revenue) del operador. Con carácter general el desglose de operador atenderá a la siguiente diferenciación: – En el caso del operador adscrito a la red no se precisa desglose ya que sólo tendrán que incluir el detalle de los ingresos procedentes de la red y el cálculo de los ingresos brutos (GGR). – En el caso del operador que gestiona completamente el juego se indicará el propio código de operador que gestiona el juego. Operadores obligados. La cuenta de operador deberá ser reportada por los operadores que gestionen los juegos o por los operadores adscritos a una red, en cuyo caso sólo tendrán que incluir el detalle de los ingresos procedentes de la red y el cálculo de los ingresos brutos (GGR). La cuenta de operador se organiza por tipo de juego. Los juegos sin registro previo también deberán ser incluidos en la cuenta de operador. Periodicidad. Mensual. Se incluirá la información registrada en la plataforma del operador durante el periodo. Contenido del registro. Descripción de la información contenida en el registro: Se registrará la suma de los importes destinados por los jugadores a la participación en el juego en el periodo, incluyendo las comisiones o cualesquiera otras cantidades por servicios relacionados con las actividades de juego pagadas por los participantes al operador. En el caso de los juegos comercializados utilizando servicios de tarificación adicional, se incluirá en este apartado la cantidad dedicada a la participación en el juego según lo establecido en el artículo 48, apartado 6.b) de la Ley 13/2011. (-) Se reflejará con signo negativo el saldo total de las participaciones al final del periodo. Se determinará el importe completo de la participación desglosado por cada una de las unidades y operador. Cuando el operador está adscrito a una red no precisará desglose ya que para el tipo de juego en cuestión solo reflejará el GGR y los Ajustes de red. Se registrará la suma de los importes correspondientes a las devoluciones, ajustes o anulaciones en participaciones realizadas con posterioridad a su formalización. Se determinará el importe completo de la devolución de la participación desglosado por cada una de las unidades y operador. (+) Se reflejará con signo positivo el saldo total de las devoluciones al final del periodo. Se registrará la suma de los importes reconocidos a los participantes por premios monetarios en el juego durante el periodo. Cuando las cantidades destinadas a botes se reconozcan, engrosarán el importe de los premios durante el periodo. Se determinará el importe completo de los Premios desglosado por cada una de las unidades y operador. (+) Se reflejará con signo positivo el saldo total de los premios al final del periodo. Se registrará la suma de los importes reconocidos a los participantes por premios no monetarios en el juego durante el periodo. Se registrará su valor en euros, según los criterios de valoración usados por el operador en su contabilidad. Se determinará el importe completo de la valoración de los premios en especie desglosado por cada una de las unidades y operador. (+) Se reflejará con signo positivo el saldo total de los premios en especie al final del periodo. Se registrará la suma de los importes completos de la contribución a los botes progresivos o premios adicionales desglosado por cada una de las unidades y operadores. Se reportará la información en dos campos: (+) Incremento de Botes para las aportaciones a los botes en el mes reportado. (-) Decremento de Botes con los premios adicionales que provienen de botes en el mes. En todo caso, las cantidades reportadas en Botes tendrán correspondencia con las cantidades reportadas en el Registro de Botes y Partidas vivas (BOT). Los operadores adscritos a una red coorganizada registrarán los ingresos procedentes de la red en el periodo considerado. (+/-) Un ajuste procedente de la red se reflejará con signo negativo, en caso contrario con signo positivo. Se determinará el importe completo los ingresos procedentes de la red desglosado por cada una de las unidades y operador. En todo caso, las cantidades reportadas en los ajustes de red de los operadores adscritos a la red tendrán correspondencia con las cantidades reportadas en los Ajustes de Red del operador coorganizador de la red. En este apartado se incluirán los ajustes contables efectivamente realizados por el operador para la obtención del GGR del periodo, con el siguiente detalle: 1. Los ajustes contables en la valoración de participaciones (APA). Por ejemplo, se incluirán los ajustes netos realizados en el GGR por apuestas contabilizadas como ingresos pendientes de resolver al final del periodo. 2. Ajustes contables en la imputación temporal de premios (APR). Por ejemplo, se incluirán los ajustes netos realizados en el GGR derivados de la imputación temporal de los premios. 3. Bonos (BON). Se incluirán los ajustes relativos a la concesión y liberación de los bonos. 4. Overlay (OVL). En los juegos de póquer se reportarán las contribuciones a premios garantizados. 5. Added (ADD). En los juegos de póquer se reportarán las contribuciones a premios realizadas por el operador motivadas por la liberación de bonos o entradas gratuitas a torneos. 6. Otros ajustes contables en el cálculo del GGR del periodo (OTR). Cualquier otro ajuste que no esté incluido en los anteriores. (+/-) Los apuntes se reflejarán con signo negativo cuando supongan un aumento de los ingresos del periodo y con signo positivo en caso contrario. Se determinará el importe completo de los ajustes contables y otros realizados por el operador, desglosado por cada una de las unidades, operador y concepto. En los juegos en los que el operador no obtenga como ingresos propios los importes jugados, tales como apuestas cruzadas o póquer, se registrará el importe de las comisiones o cualesquiera otras cantidades por servicios relacionados con las actividades de juego pagadas por los participantes al operador. En el resto de juegos se registrará el importe de cualesquiera otras cantidades por servicios relacionados con las actividades de juego pagadas por los participantes al operador. Se determinará el importe completo de las comisiones y otros ingresos en el periodo, desglosado por cada una de las unidades y operador. (-) Se reflejará con signo negativo el total de comisiones al final del periodo. Se registrará el importe de ganancia bruta del operador en el periodo, indicando las cantidades en euros. (+/-) Las ganancias se reflejarán con signo negativo, en caso contrario con signo positivo. Cuando se trata de un operador adscrito a una red el GGR proviene del reparto de las ganancias de la red. Controles Principales. – Cálculo de la Ganancia Bruta del Operador (GGR). – Correspondencia entre los ingresos procedentes de la red reportados por el operador adscrito a la red y los reportados por el operador de red. – Cuando el operador gestiona el juego de forma completa en el desglose de operador indicará su propio código de operador. – El Total y el Desglose de todos los movimientos reportados deben coincidir en todos los casos. 3.4.3.2 Registro ORT: Cuenta del operador de red. Información en la cuenta de operador coorganizador. La cuenta del operador es un reflejo de la cuenta de ingresos por juego generados en un juego gestionado en red. Deberá permitir el cálculo de los ingresos brutos (GGR, gross gaming revenue) del juego coorganizado y su distribución entre los operadores adscritos a la red de operadores. En el desglose de operador se repartirán las cantidades por los operadores que proporcionan los clientes a la red de juego. Operadores obligados. La cuenta de operador deberá ser reportada por los operadores coorganizadores por cada uno de los tipos de juego que gestionan. Juegos ofertados en un entorno de liquidez internacional. En los juegos ofertados en un entorno de liquidez internacional en los que participe al menos un jugador con registro de usuario español, deberán reportarse: – Por las operaciones de operadores de la jurisdicción española, los datos agregados por operador. – Por las operaciones de operadores de otras jurisdicciones, los datos agregados por jurisdicción. Por ejemplo, en el caso de Francia se reportará OperadorId=FR, IT para Italia y PT para Portugal. Periodicidad. Mensual. Se incluirá la información registrada en la plataforma del operador durante el periodo. Contenido del registro. La estructura y contenido es igual que la del registro OPT, teniendo en cuenta que los apuntes vendrán desglosados por operador que ha aportado los participantes a la red. En la Ganancia Bruta del Operador (GGR) se reflejará el GGR total de la red y en los Ajustes de Red el desglose por cada uno de los operadores que aportan jugadores. En el caso de juegos ofertados en un entorno de liquidez internacional, el gestor de liquidez internacional deberá informar de las magnitudes económicas desglosándolas por operador en el caso de los operadores que dispongan de licencia en España, y por un agregado por jurisdicción para el resto de los operadores. 3.4.3.3 Registro BOT: Botes y partidas vivas. Información en la cuenta de botes y partidas vivas. La cuenta de botes y partidas vivas es un reflejo de los importes de las participaciones en los juegos que, al final del periodo considerado, todavía no se han repartido en premios, bien porque se han incorporado a botes, bien porque las partidas no han finalizado. Operadores obligados. La cuenta de botes y partidas vivas debe comunicarla todo operador que gestione el desarrollo del juego, ya sea de manera completa o gestionando la red. Los operadores adscritos a una red que no gestionen el juego no deben informarla. La cuenta de botes deberá ser reportada por los operadores que gestionen los fondos para botes directamente. En los casos de juegos en red será el operador coorganizador quien presentará la información correspondiente a botes. En la cuenta de Botes se incluirán todos los botes activos en el periodo. Un bote está activo desde el momento en que los participantes pueden contribuir al mismo, hasta que se cierra, normalmente por el reparto de todos los premios asociados o, en su caso, por el redireccionamiento a otro bote. Por tanto, en la cuenta de botes se incluirán todos los botes que se hayan comercializado durante el periodo, independientemente de que su comercialización se hubiera iniciado en un periodo anterior, o de que hayan finalizado durante el periodo considerado. Los botes se identificarán de forma individualizada. La cuenta de partidas vivas será reportada por los operadores que gestionen juegos de Apuestas, Torneos de póquer y Concursos. En los casos de juegos en red será el operador coorganizador quien presentará la información correspondiente a partidas vivas. El operador podrá solicitar a la DGOJ la no inclusión en el registro de otros juegos en los que las partidas tengan una duración inferior a un día, contada desde el momento en que se inicia la comercialización hasta el momento en que se reconocen los premios. Dada la dinámica de los juegos de Póquer cash, Ruleta, Blackjack, Punto y banca, Bingo, Máquinas de azar y Juegos complementarios, la información de partidas vivas no ha de ser reportada. La Dirección General de Ordenación del Juego podrá requerir al operador para que se incluya la información de partidas vivas en los casos en que su volumen sea significativo. Periodicidad. La periodicidad de generación del registro será mensual. Contenido del registro. La información que se recoge en el registro de botes y partidas vivas es la siguiente: Información relativa a las partidas que aún no han concluido: – (+) SaldoInicial, importe total de las participaciones realizadas por los jugadores en apuestas, partidas, concursos o torneos que al inicio del periodo considerado no habían concluido y que por tanto no se conoce el participante o participantes ganadores. – (+) IncrementoPartidasVivas, suma total de las participaciones que hayan sido realizadas durante el periodo por los jugadores en apuestas, partidas, concursos o torneos y que al final de este periodo no hayan concluido o no se hayan determinados los ganadores. – (-) DecrementoPartidasVivas, importe de partidas vivas cuyos participantes ganadores sean determinados a lo largo del periodo. – (+) SaldoFinal, importe total de las participaciones realizadas por los participantes en apuestas, partidas, concursos o torneos que al final del periodo considerado no han concluido y que por tanto no se conoce el participante o participantes ganadores. – DesgloseCompromiso, con el saldo final desglosado y agrupado por mes. Si el saldo final es cero, puede omitirse este desglose. Información relativa a las cantidades totales incorporadas a botes: – (+) SaldoInicial, suma total del saldo inicial en botes en el periodo considerado. – (+) IncrementoBotes, importes añadidos a los botes durante el mes reportado. – (-) DecrementoBotes, suma total de las aplicaciones a los botes por reparto de los premios asociados o por el redireccionamiento a otro bote. – (+) SaldoFinal, suma total del saldo final en botes en el periodo considerado. – DesgloseBotes, información detallada de cada bote con movimientos o saldo en el periodo: • BoteId, identificador del bote. • BoteDesc, descripción del bote. • FechaInicio, Fecha/hora de creación del bote. • FechaFin, Fecha/hora de cierre del bote. No se reportará si el bote o premio está activo al final del periodo). • (+) SaldoInicial. • (+) IncrementoBotes, las contribuciones del periodo al bote. • (-) DecrementoBotes, las aplicaciones al bote por reparto de los premios asociados o, en su caso, por el redireccionamiento a otro bote. • (+) SaldoFinal. Controles Principales. – El saldo inicial más el importe total de los movimientos deben coincidir con el saldo final tanto para Botes como Partidas Vivas. – Las cantidades indicadas como aplicaciones de botes por reparto de premios tendrán su reflejo en los importes de premios reportados por el operador en la cuenta del operador. – El saldo inicial de los Botes y las Partidas Vivas debe ser el mismo que el saldo final de dichas variables en el fichero BOT del mes anterior. 3.4.4 Registros de Datos de Juego. 3.4.4.1 Registro JUC: juegos. Información en registros de juegos. Los registros de juegos contendrán información a nivel de sesión, torneo, apuesta, concurso o sorteo: – Póquer cash, bingo, máquinas de azar, ruleta, blackjack, punto y banca, juegos complementarios y loterías presorteadas: cada sesión de juego. – Póquer torneo: cada torneo. – Apuestas: cada combinación de deportes, competiciones, eventos y hechos sobre lo que se apuesta. – Concursos: cada concurso. – Loterías: cada sorteo. Dado que cada juego tiene sus características particulares, se han definido distintos tipos de registros de juego, estos son: – RegistroOtrosJuegos: para juegos de casinos, se incluyen los tipos de juego: POC, BNG, AZA, PUN, RLT, BLJ y COM. – RegistroPoquerTorneo: para el tipo de juego POT. – RegistroApuestaContrapartida: se incluirán todos los juegos de apuestas de contrapartida: ADC, AHC y AOC. – RegistroApuestaMutua: incluye los juegos de apuestas mutuos y los de cruzadas: ADM, AHM, ADX y AOX. – RegistroConcurso: para los juegos COC. – RegistroLoteria: para todos los juegos de loterías. – RegistroLoteriaPresorteada: para las sesiones de juego de lotería instantánea o presorteada. Operadores obligados. Los registros de juegos deben ser transmitirlos por los operadores que gestionen el desarrollo del juego, ya sea de manera completa o gestionando una red coorganizada. No debe ser trasmitida por los operadores que únicamente gestionen jugadores. Periodicidad. Los datos de los registros de juegos se deben generar en tiempo real en el sistema del operador de forma que recoja la información del evento tal y como se produce en el sistema. Los eventos serán: – Póquer cash, bingo, máquinas de azar, ruleta, blackjack, punto y banca, juegos complementarios, loterías presorteadas: cuando finalice la sesión. – Póquer torneo: cuando finalice el torneo. – Apuestas: el momento en que se conoce el resultado de los hechos sobre los que se apuesta. – Concursos: cuando finalice cada concurso. – Loterías: cuando se conozca el conjunto de ganadores. La periodicidad del envío de los registros de juegos al almacén está definida en el apartado «Periodicidad y fragmentación». Las correcciones o ajustes en los juegos realizados con posterioridad a su envío al almacén se reportarán como rectificaciones, sin que, en ningún caso, se pueda borrar la transacción original corregida o ajustada. Esto se hará para todos los juegos donde se produzca estas circunstancias a excepción de las apuestas, cuyas correcciones y ajustes deberán ser informadas de forma individual en el registro denominado Ajuste de Apuestas. Este registro deberá recoger cualquier corrección o ajuste de las apuestas ya realizadas indicando las cuantías y los motivos. Cuando la variación de los registros de los juegos se debe a causas diferentes al funcionamiento normal de los juegos, como a errores en la generación del reporte u otros errores de carácter técnico la trasmisión de los datos correctos se realizará mediante la rectificación de los datos (ver epígrafe «Rectificaciones»). La información de todos los tipos de juego está compuesta por una información del juego y por una información del jugador o jugadores. Los registros RegistroOtrosJuegos, RegistroApuestaContrapartida y RegistroLoteriaPresorteada tienen información de un único jugador, el resto de los registros están preparados para reportar entre 1 y muchos jugadores. Datos del juego. Se definen 7 tipos distintos de registros JUC, dependiendo del tipo de juego y de si son juegos mutuos o de contrapartida. Todos tienen una mayoría de campos comunes y unos pocos específicos de cada juego. Están compuestos por dos bloques, uno con la información del juego y otra con la del jugador. Campos comunes del bloque de Juego. Identificador único del hecho que genera la obligación de informar al SCI. El hecho depende del tipo de juego: – Apuestas: cada apuesta (pronóstico) que realice el jugador tendrá un identificador único, con independencia de que esta sea simple, múltiple o combinada. – Póquer cash, Bingo, Ruleta, Blackjack, Punto y banca, Juegos complementarios, máquinas de azar y loterías presorteadas: un identificador único por sesión en el que el jugador haya tenido movimientos. – Póquer torneo: cada torneo tendrá un identificador único. – Concursos: cada concurso tendrá un identificador único. – Loterías: cada sorteo tendrá un identificador único por sorteo. Campos comunes del bloque de Jugador. Identificador único del jugador en la plataforma, el mismo que el utilizado en los registros RUD y CJD. En el caso de Póquer torneo y Concursos, el identificador contendrá el OperadorId dado que son juegos que pueden estar en red. Campos específicos del registro Otros Juegos (RegistroOtrosJuegos). Este registro JUC será el utilizado para reportar la información para cada uno de los juegos de casino (POC, BNG, AZA, BLJ, RLT, PUN y COM) de la sesión, se generará uno por cada sesión de juego. A diferencia del resto de registros el desglose de los movimientos monetarios (participación, devolución, premios y botes) se reportará en el bloque juego y no en el de jugador ya que se requiere conocer el total de estos movimientos por cada uno de los tipos de juego en los que ha participado el jugador durante la sesión de juego. Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego: Total agregado de las participaciones en el juego durante la sesión reportada. (-) Se reportará con signo negativo. Total agregado de las devoluciones de participaciones en el juego durante la sesión reportada. (+) Se reportará con signo positivo. Total agregado de los premios en el juego durante la sesión reportada. (+) Se reportará con signo positivo. Total de las cantidades aportadas a los botes y recibidas como premios de dichos botes por juego. Si el Total es distinto de cero se desglosará la información por cada uno de los botes modificados reportando la información en dos campos: (+) Incremento de Botes para las aportaciones a los botes. (-) Decremento de Botes con los premios adicionales que provienen de botes. Se reportará sólo y obligatoriamente para los juegos POC, BLJ y RLT. Variante del juego, en caso de jugar a varias de ellas reportar solo la primera. Detalle en el apartado «Listas y enumerados». Se reportará sólo y obligatoriamente para los juegos POC, AZA, BLJ y RLT. Coincidirá con el nombre con el que el operador está comercializando esta variante de juego. Si durante la sesión se producen partidas de distintas variantes comerciales se indicarán todas ellas en una cadena de texto separada por comas. Hasta un máximo de 200 caracteres. Ejemplo: VarianteComercial1,varianteComercial2. Se reportará obligatoriamente para el juego RLT y cualquier juego que tenga aprobada la modalidad de juego en vivo en un casino. Será «S» cuando se trate de ruleta en vivo. Se reportará sólo y obligatoriamente para el juego POC. «S» si el juego se ha producido en una red de póquer. Se reportará sólo y obligatoriamente para el juego POC. «S» si alguno de los juegos se ha realizado en una red internacional y alguno de los participantes es de una jurisdicción distinta a la española. En el caso de juegos con liquidez internacional, el operador solo reportará los datos de los jugadores del dominio «.es». Se reportará sólo y obligatoriamente para el juego POC. Es el identificador de la mesa en la que se ha realizado la mano de póquer. Si durante la sesión se producen partidas de distintas mesas se indicarán los identificadores de todas ellas en una cadena de texto separada por comas. Hasta un máximo de 1000 caracteres. Y los siguientes campos específicos para el bloque Jugador: Información de los parámetros y características de la sesión reportada. Es un campo múltiple compuesto de los siguientes campos: Identificador único de la sesión en el operador. En el caso de sesiones interrumpidas, ambas partes de la sesión serán reportadas con el mismo identificador. Límites establecidos por el jugador para la sesión: – DuracionLimite: Tiempo máximo de la sesión. – GastoLimite: Máximas perdidas en euros para la sesión. – PeriodoExclusion: «S» si el jugador ha marcado un tiempo de exclusión del juego tras finalizar la sesión. – TiempoExclusion: Campo obligatorio en caso de PeriodoExclusion=«S». Indica el tiempo en días, horas y minutos que el jugador ha planificado autoexcluirse tras la finalización de la sesión. Se reportará «S» cuando se esté reportando toda la información de la sesión. Se reportará «N» cuando la sesión haya sido interrumpida y solo se esté reportando una parte de esta. Se reportará «S» cuando se esté reportando una sesión por primera vez. Se reportará «N» cuando la información que se envía es parte de una sesión ya enviada previamente, en concreto el cierre de una sesión interrumpida o incompleta. La sesión se puede cerrar porque la cierre el usuario, por que se cumpla uno de los requisitos de cierre planificados o por un problema externo. En este campo se especifica el motivo de cierre. Detalle en el apartado «Listas y enumerados». Campos específicos del registro Póquer Torneo (RegistroPokerTorneo). Este registro JUC será el utilizado para reportar la información para cada uno de los torneos de póquer (POT). Se generará un registro por cada torneo. Este registro reporta todos los jugadores que participan en el torneo. Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego: «S» si el juego se ha realizado en una red internacional y alguno de los participantes es de una jurisdicción distinta a la española. En el caso de juegos con liquidez internacional, el operador solo reportará los datos de los jugadores del dominio «.es». Variante del juego, deberá coincidir con alguna de las variantes admitidas dentro de la regulación básica correspondiente. Detalle en el apartado «Listas y enumerados». Coincidirá con el nombre con el que el operador está comercializando esta variante de juego. Si durante la sesión se producen partidas de distintas variantes comerciales se indicarán todas ellas en una cadena de texto separada por comas. Hasta un máximo de 200 caracteres. Ejemplo: VarianteComercial1, varianteComercial2. Número de jugadores en el torneo reportado. Se incluirán todos los jugadores con independencia de la jurisdicción a la que pertenezcan. Y los siguientes campos específicos para el bloque Jugador. Es un campo múltiple. Se reportarán todos los jugadores de la jurisdicción española que hayan participado en el torneo de póquer reportado: Total de las participaciones en el torneo. (-) Se reportará con signo negativo. Total de las devoluciones de participaciones en el torneo. (+) Se reportará con signo positivo. Total de los premios recibidos en el torneo reportado. (+) Se reportará con signo positivo. Campos específicos del registro Apuestas de Contrapartida (RegistroApuestaContrapartida). Este registro JUC será el utilizado para reportar la información para cada una de las apuestas realizadas por un jugador de los tipos de apuesta de contrapartida (ADC, AHC, AOC). Se generará un registro por cada apuesta cerrada. Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego: «S» cuando la apuesta se realice dentro del tiempo en que se está disputando el evento sobre el que se apuesta. Si se realiza una apuesta múltiple o combinada, en la que uno de los eventos sobre los que apuesta, se está disputando, se rellenará el campo con «S». Tipo de la apuesta en función de los eventos y hechos apostados. Detalle en el apartado «Listas y enumerados». Para cada apuesta se incluirán la combinación de eventos y hechos que la conforman. Es un campo complejo compuesto de: – EventoId: Identificador de evento será una referencia al Catálogo de eventos. – Hecho: Se incluirá una descripción del hecho sobre el que se realiza la apuesta. Tendrá el formato: «Mercado: Resultado». – FechaHecho: Fecha en la que se determina el resultado del hecho apostado. Y los siguientes campos específicos para el bloque Jugador: Campo a rellenar obligatoriamente en caso de apuesta a evento en directo. Contendrá el saldo del jugador en su cuenta de juego al inicio del primer evento de la apuesta. Valor total de la apuesta reportada. (-) Se reportará con signo negativo. Valor total de las devoluciones de la apuesta. (+) Se reportará con signo positivo. Total de premios recibidos por la apuesta. (+) Se reportará con signo positivo. Campo obligatorio en caso de que la apuesta se haya resuelto por cash out. Es un campo múltiple, habrá tantas entradas como cash outs se hayan realizado sobre la apuesta reportada. Es un campo complejo: – ImporteCashOut: Cantidad retirada. – FechaCashOut: Fecha y hora en la que se solicitó el cash out de la apuesta. Campos específicos del registro Apuestas Mutuas (RegistroApuestaMutua). Este registro JUC será el utilizado para reportar la información para cada una de las apuestas realizadas por varios jugadores de los tipos de apuesta mutuas o cruzadas (ADM, AHM, ADX y AOX), se generará uno por cada apuesta de este tipo cerrada. Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego: Tipo de la apuesta en función de los eventos y hechos apostados. Detalle en el apartado «Listas y enumerados». Para cada apuesta se incluirán la combinación de eventos y hechos que la conforman. Es un campo complejo compuesto de: – EventoId: Identificador de evento será una referencia al Catálogo de eventos. – Hecho: Se incluirá una descripción del hecho sobre el que se realiza la apuesta. Tendrá el formato: «Mercado: Resultado». Campo obligatorio en los juegos de tipo ADX y AOX. 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 reportará cada cruce que se ha realizado sobre un Hecho, y de cada uno de dichos cruces: – Reto: «S» si es cruce de tipo «Reto», en el que los apostantes conocen los identificadores del resto de jugadores. – Ticket: lista de tickets asociados a cada cruce separados por comas. – LayBack: tipo de apuesta de cada uno de los tickets (Lay/Back). Y los siguientes campos específicos para el bloque Jugador. Es un campo múltiple, se reportarán todos los jugadores que hayan participado en la apuesta reportada: Valor total de la apuesta reportada. (-) Se reportará con signo negativo. Valor total de las devoluciones de la apuesta. (+) Se reportará con signo positivo. Total de premios recibidos por la apuesta. (+) Se reportará con signo positivo. Total de las cantidades aportadas a los botes y recibidas como premios de dichos botes. Si el Total es distinto de cero se desglosará la información por cada uno de los botes modificados reportando la información en dos campos: (+) Incremento de Botes para las aportaciones a los botes. (-) Decremento de Botes con los premios adicionales que provienen de botes. Valor de la cuota de la apuesta en el momento en que es aceptada por el jugador. Estará expresada en formato decimal. Es un campo múltiple, habrá tantas entradas como «cash out» se hayan realizado sobre la apuesta reportada. Es un campo complejo: – ImporteCashOut: Cantidad retirada. – FechaCashOut: Fecha y hora en la que se solicitó el «cash out» de la apuesta. Campos específicos del registro Concurso (RegistroConcurso). Este registro JUC será el utilizado para reportar la información para cada uno de los concursos (COC), se generará uno por concurso. Este registro reporta todos los jugadores que participan en el concurso. Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego: Y los siguientes campos específicos para el bloque Jugador. Es un campo múltiple, se reportarán todos los jugadores que hayan participado en el concurso reportado: Total agregado de las participaciones en el concurso. (-) Se reportará con signo negativo. Total agregado de las devoluciones de participaciones en el concurso. (+) Se reportará con signo positivo. Total agregado de los premios en el concurso. (+) Se reportará con signo positivo. Campos específicos del registro Loterías (RegistroLoteria). Este registro JUC será el utilizado para reportar la información para cada uno de los sorteos de loterías (PDM, PHM, PLN, PLP, PEU, PBL, PGP, PLT, PED, PCP, PSO, PTX, PMD, PEJ, PRK, OLN, OLP, OEU, OBL, OGP, OLT, OED, OCP, OSO, OTX, OMD, OEJ, ORK). Se generará uno por sorteo. Se excluyen de este registro las sesiones de usuario de lotería presorteada o instantánea. Este registro reporta todos los jugadores que participan en el sorteo para los juegos online . Para los juegos presenciales se reportarán los totales agrupados de todos los jugadores presenciales. Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego: Y los siguientes campos específicos para el bloque Jugador. Es un campo múltiple, se reportarán todos los jugadores que hayan participado en el sorteo reportado para los juegos online y para los juegos presenciales solo se reportará un único bloque Jugador con los valores totales de participación, devolución, premios y botes: Total agregado de las participaciones en el sorteo. (-) Se reportará con signo negativo. Total agregado de las devoluciones de participaciones en el sorteo. (+) Se reportará con signo positivo. Total agregado de los premios en el sorteo. (+) Se reportará con signo positivo. Total de las cantidades aportadas a los botes y recibidas como premios de dichos botes por sorteo y desglosada por cada bote. Si el Total es distinto de cero se desglosará la información por cada uno de los botes modificados reportando la información en dos campos: (+) Incremento de Botes para las aportaciones a los botes. (-) Decremento de Botes con los premios adicionales que provienen de botes. Campos específicos del registro LoteríasPresorteadas (RegistroLoteriaPresorteada). Este registro JUC será el utilizado para reportar la información para cada una de las sesiones de usuario de juegos de loterías presorteadas o instantáneas. Se generará un registro por sesión. Además de los campos comunes estos registros tendrán los siguientes campos en el bloque Juego: Y los siguientes campos específicos para el bloque Jugador: Información de los parámetros y características de la sesión reportada. Es un campo múltiple compuesto de los siguientes campos: Identificador único de la sesión en el operador. En el caso de sesiones interrumpidas, ambas partes de la sesión serán reportadas con el mismo identificador. Límites establecidos por el jugador para la sesión: – DuracionLimite: Tiempo máximo de la sesión. – GastoLimite: Máximas perdidas en euros para la sesión. – PeriodoExclusion: «S» si el jugador ha marcado un tiempo de exclusión del juego tras finalizar la sesión. – TiempoExclusion: Campo obligatorio en caso de PeriodoExclusion=«S». Indica el tiempo en días, horas y minutos que el jugador ha planificado autoexcluirse tras la finalización de la sesión. Se reportará «S» cuando se esté reportando toda la información de la sesión. Se reportará «N» cuando la sesión haya sido interrumpida y solo se esté reportando una parte de esta. Se reportará «S» cuando se esté reportando una sesión por primera vez. Se reportará «N» cuando la información que se envía es parte de una sesión ya enviada previamente, en concreto el cierre de una sesión interrumpida o incompleta. La sesión se puede cerrar porque la cierre el usuario, por que se cumpla uno de los requisitos de cierre planificados o por un problema externo. En este campo se especifica el motivo de cierre. Detalle en el apartado «Listas y enumerados». Total agregado de las participaciones en la sesión. (-) Se reportará con signo negativo. Total agregado de las devoluciones de participaciones en la sesión. (+) Se reportará con signo positivo. Total agregado de los premios en la sesión. (+) Se reportará con signo positivo. Total de las cantidades aportadas a los botes y recibidas como premios de dichos botes por sesión y desglosada por cada bote. Si el Total es distinto de cero se desglosará la información por cada uno de los botes modificados reportando la información en dos campos: (+) Incremento de Botes para las aportaciones a los botes. (-) Decremento de Botes con los premios adicionales que provienen de botes. 3.4.5 Registro de Ajustes de Apuestas. Información en registros de ajustes de apuestas. Datos normalizados de los ajustes realizados en apuestas con posterioridad al momento en que se determina la existencia de premios. El registro de los ajustes de apuestas se denomina RegistroJUA. Operadores obligados. El registro de ajuste de apuestas debe transmitirlo todo operador que, en posesión de la licencia singular correspondiente para ofertar apuestas deportivas, hípicas u otras, gestione el desarrollo de alguna de estas apuestas, ya sea de manera completa o gestionando una red coorganizada de apuestas. Periodicidad. Mensual. En el caso de que no haya ningún ajuste durante el periodo el registro se generará igualmente con contenido vacío. Datos del registro. La información se desglosa para cada ajuste: Controles principales. – El EventoID declarado debe encontrarse definido en el registro del catálogo de eventos. – El TicketApuesta debe haber sido reportado en algún registro de juego de apuestas (RegistroApuestaContrapartida o RegistroApuestaMutua). 3.4.6 Registro de Catálogo de eventos. Información en catálogo 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 de que dichos eventos hayan finalizado o no. El registro de catálogo de Eventos se denomina RegistroCEV. Operadores obligados. Los operadores que comercializan apuestas. Periodicidad. – Diaria. Diariamente se incluirá la información de los eventos nuevos o que hayan sido modificados en el día. – Mensual. Mensualmente se incluirá la información 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ón de la última actualización. Datos del catálogo. La descripción del registro que notifica los eventos sobre los que se realizan apuestas se detalla a continuación: Codigo. OtroCodigoEspecificar. Código del evento, en base a la lista de códigos publicada y actualizada en la web de la DGOJ. En caso de no encontrarse en dicha lista se utilizará el código correspondiente a «Otros»=999, junto con el campo OtroCodigoEspecificar. Ejemplo: 999 OtroCodigoEspecificar: Sumo Dato descriptivo indicando la competición a la que pertenece el evento. Ejemplos: Categoría de la competición. Por ejemplo: Profesional, Amateur, Universitaria, Juvenil, Amistoso. Campo opcional, se rellena si aplica. Fase, semana, momento de la competición. Por ejemplo: Previa, semana 2, Clasificatoria, Semifinal. «S» para eventos que ya han sido reportados previamente y se están modificando con la información actual. «N» para eventos nuevos. Controles principales. Todos los eventos reportados en las apuestas mediante un identificador de evento deberán estar recogidos en el catálogo correspondiente. No debe haber eventos duplicados, en caso de reportar un duplicado se entiende que es una actualización de los datos de un evento previo y por tanto debe ser señalizado con el campo Actualizado=«S» o será considerado erróneo. 3.4.7 Rectificaciones. Cuando un operador transmita datos erróneos, deberá corregir los datos transmitidos erróneamente. En lo sucesivo, en la presente Disposición se denominará «rectificación» a la corrección de errores. La rectificación en ningún caso debe permitir o implicar el borrado de la información que ya conste en el Almacén, excepto en aquellos casos en que se haya obtenido la aprobación previa y explícita de la Dirección General de Ordenación del Juego. Para la rectificación de la información se utilizará la declaración de la nueva información, junto con una indicación de la información anterior errónea que debe ser sustituida. 3.4.8 Clasificaciones y normalizaciones. 3.4.8.1 Tipo de Juego. Los tipos de juego para el modelo de monitorización (sin considerar los juegos de loterías) son los siguientes: – ADC: Apuestas Deportivas de Contrapartida. – ADM: Apuestas Deportivas Mutuas. – ADX: Apuestas Deportivas Cruzadas. – AHC: Apuestas Hípicas de Contrapartida. – AHM: Apuestas Hípicas Mutuas. – AOC: Otras Apuestas de Contrapartida. – AOX: Otras Apuestas Cruzadas. – AZA: Máquinas de Azar. – BLJ: Blackjack. – BNG: Bingo. – COC: Concursos. – COM: Juegos Complementarios. – POT: Póquer Torneo. – POC: Póquer Cash. – PUN: Punto y Banca. – RLT: Ruleta. 3.4.8.2 Estado del jugador. El «estado» del jugador está compuesto por los 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ón documental. Refleja el estado de un jugador residente, cuya identificación no ha sido cotejada fehacientemente mediante un sistema de verificación documental. • S: Suspendido. Refleja el estado del jugador que el operador ha optado por suspender. En este caso, el operador debe reportar el motivo de la suspensión en el campo MotivoEstado entre uno de los valores de la lista. • C: Cancelado. Refleja el estado del jugador que ha sido cancelado. En este caso, el operador debe reportar el motivo de la cancelación en el campo MotivoEstado entre uno de los valores de la lista. • CD: Cancelado por defunción. Jugador que ha fallecido. • PR: Prohibición subjetiva. Refleja el estado del jugador sujeto a cualquiera de las prohibiciones subjetivas establecidas en el artículo 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én 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. – MotivoEstado, en caso de que el EstadoCNJ sea Suspendido o Cancelado se debe rellenar este campo seleccionando el motivo por el cual la cuenta ha sido suspendida o cancelada. El campo es un enumerado, la lista de valores disponibles se encuentra en el listado correspondiente del anexo 1. 3.4.8.3 Formato válido NIF y NIE. Para que un formato de NIF y NIE sea válido ha de cumplir las siguientes reglas: – Se deben rellenar con ceros a la izquierda hasta contemplar el número exacto de dígitos del DNI (8) y NIE (7). Por ejemplo, en el caso del NIF: Número de 8 dígitos seguido de una letra (digito de control). En caso de no ser un número con 8 dígitos, se completará el número con ceros a la izquierda hasta llegar a 8 dígitos. – En el caso del NIE, debe tenerse en cuenta la siguiente excepción. Cuando se detecte un NIE de 10 dígitos que empiece por X y a continuación haya un 0, debe suprimirse el primer cero tras la X, quedando un NIE formado por 9 caracteres. Para el cálculo del dígito de control del NIF/NIE podrá consultarse la siguiente página web: http://www.ordenacionjuego.es/es/calculo-digito-control 4. Modelo técnico 4. Modelo técnico 4.1 Estructura de la información. 4.1.1 Registros. Se denomina registro a cada información transmitida, y que técnicamente está constituido por un elemento de información definido en el XSD del modelo de datos de monitorización (en adelante XSD). 4.1.2 Subregistros. Se denomina subregistro (subdivisión del registro) a cada una de las partes, formadas por varios elementos XML, en las que, por razones técnicas originadas por la posible existencia de registros muy voluminosos, pueden dividirse éstos. 4.1.3 Lote. Se denomina lote a un elemento XML definido en el XSD, que tiene una información de cabecera. – Información periódica (RU, CJ, OP, JUA, CEV): cada registro se reportará en un lote (o en varios, si hay fragmentación del registro en más de 10 subregistros). Se genera diaria y/o mensualmente, según el tipo de fichero. Se ha de cumplir la siguiente regla: A partir de 10 subregistros, se debe generar un nuevo lote (y sólo se puede generar uno cuando se haya cubierto el cupo de 10 subregistros en el anterior). Por tanto, sólo el último lote correspondiente a un registro (es decir, el que contiene los últimos subregistros) puede contener un número de subregistros menor que 10. Un lote no debe incluir información relativa a registros distintos. En particular, no deben existir rectificaciones de dos registros distintos en un mismo lote. – Información en tiempo real (JUC): en este caso, un lote contiene información de uno o varios registros, cada uno de los cuales se corresponde con una apuesta, torneo, concurso, sorteo o sesión, dependiendo del tipo de juego de que se trate. Se generará un lote cuando transcurran 15 minutos desde que se generó el lote anterior o cuando se alcance la cifra de 500 subregistros en dicho lote (lo que suceda antes). Un lote representa un fichero que se guardará en el Almacén. 4.1.4 Firma del lote. El lote es un elemento XML que debe ir firmado con el certificado del operador, o, en su caso, con el certificado de una empresa debidamente capacitada y autorizada por el operador. La especificación para la firma digital de los lotes es XAdES-BES versión 1.3.2. Dentro de esta especificación, se aceptarán dos métodos de firma, pudiendo el operador optar por cualquiera de los mismos: – Utilizar la firma XAdES-BES 1.3.2 «enveloped». • En este caso la firma estará incluida dentro del propio XML del lote, ya que el formato «enveloped» incrusta un elemento «Signature» dentro del XML del lote. • El fichero firmado se denominará enveloped.xml». – Utilizar la firma XAdES-BES 1.3.2 «enveloping de un manifiesto» del lote. • La firma de un manifiesto está específicamente diseñada para optimizar el proceso de firma. • En este caso se obtendrán dos documentos: el lote original, que se denominará «lote.xml», y firma del manifiesto del lote, que se denominará «enveloping.xml». • Se realizará la firma «enveloping» del manifiesto, tal y como se describe en http://www.w3.org/TR/xmldsig-core/#sec-o-Manifest y http://www.w3.org/TR/xmldsig-core/#def-SignatureEnveloping. • El manifiesto referencia al fichero «lote.xml» mediante la URI y contiene el hash SHA-256 del lote. En el caso de tener algún problema con la firma enveloped, dependiendo de la implementación del operador, pueden intentar solucionarlo añadiendo en la cabecera del lote el espacio de nombres de xmldsig y el elemento schemaLocation con la localización de la definición del esquema tal y como se muestra en el ejemplo a continuación: 4.1.5 Compresión y cifrado del lote. El lote ya firmado, se debe comprimir y cifrar mediante la generación de un fichero ZIP. En el caso de firma «enveloped», el fichero ZIP contendrá un único fichero denominado «enveloped.xml». En el caso de firma «enveloping de un manifiesto», el fichero ZIP contendrá dos ficheros, «lote.xml» y «enveloping.xml». Para garantizar la compatibilidad del formato ZIP, el formato debe respetar las extensiones de WinZip sobre la especificación de PKWare para introducir cifrado AES-256. La información puede obtenerse de http://www.winzip.com/aes_info.htm y ftp://ftp.info-zip.org/pub/infozip/doc/appnote-iz-latest.zip El algoritmo de compresión será «Deflate». El algoritmo de cifrado será «AES-256». La contraseña tendrá una longitud de 50 caracteres y contendrá obligatoriamente dígitos, caracteres y caracteres especiales (tipo: #, $, & ó !) y junto con el resto de claves será responsabilidad del operador su custodia. El resultado es un fichero firmado, comprimido y cifrado que se deposita en el sistema de ficheros del Almacén. 4.2 Estructura de directorios. El Almacén constará de la siguiente estructura de directorios, también organizada por áreas: Nivel 1: CNJ. Nivel 2: . (Para el caso de que haya varios operadores en un mismo Almacén). Niveles 3, 4, 5 y 6: – RU: Registro de Usuario. • Diario / Mensual. ○ RUD: Registro de usuario (por jugador). • Mensual. ○ RUT: Registro de usuario (totales). ○ RUR: Registro de usuario en red (por jugador). ○ RUG: Registro de usuarios ganadores en juegos sin registro previo (por jugador). – CJ: Cuenta de Juego. • Diario / Mensual. ○ CJT: Cuenta de juego (totales). ○ CJD: Cuenta de juego (por jugador). – OP: Operador. • Subcarpetas para cada Tipo de Juego (según lista del apartado «Tipo de Juego»). ○ OPT: Cuenta de Operador (totales). ○ ORT: Cuenta de Operador de Red (totales). ○ BOT: Cuenta de botes y partidas vivas (totales). – JU: Juego. • : Día en curso. ○ SES: RegistroOtrosJuegos. ○ POT: RegistroPokerTorneo. ○ RAC: RegistroApuestaContrapartida. ○ RAM: RegistroApuestaMutua. ○ COC: RegistroConcurso. ○ LOT: RegistroLoteria. ○ LOP: RegistroLoteriaPresorteada. • Anteriores. • Mensual. ○ JUA: Ajustes de Apuestas. ○ CEV: Catálogo de Eventos (mensuales). • Diario. ○ CEV: Catálogo de Eventos (diarios). Los nombres de las carpetas en el SCI del operador (indicados aquí mediante un subrayado) han de coincidir exactamente con lo que se especifica, utilizando mayúsculas y minúsculas como corresponda. 4.3 Empaquetado de los datos de juegos. Respecto a los datos de JU: Juegos, se mantienen los lotes del día en curso, pero los días anteriores se deben agrupar en un único fichero. El 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ía en curso, y otra carpeta para días anteriores: – Mensual: Para depositar los ficheros con los ajustes de apuestas (JUA) y catálogo de eventos (CEV) de periodicidad mensual. – Diario: Para depositar los ficheros del catálogo de eventos (CEV) de periodicidad diaria. – AAAAMMDD: Para el día en curso. Los registros de Juegos (JUC) se generan en tiempo real. El día en curso contendrá todos los lotes/ficheros generados individualmente. – Anteriores: Para días anteriores. Cuando finalice el día (24:00), el operador procederá a empaquetar toda la carpeta Juegos del día que ha finalizado en un fichero ZIP sin compresión ni cifrado. Por tanto, esto solo afecta a ficheros de tipo JUC. Este fichero empaquetado conservará la ruta relativa (la estructura de subcarpetas a partir de AAAAMMDD) y todos los lotes/ficheros del día, estos sí, comprimidos y cifrados con la clave correspondiente. Hay un tamaño máximo de fichero de 1 GB para este archivo total de Juegos del día, de forma que, si supera el umbral de 1 GB, se generarán varios fragmentos. Finalmente, este fichero ZIP (o varios ficheros de fragmentos del ZIP) se moverá a la carpeta «Anteriores» y el operador deberá eliminar la carpeta de Juegos del día finalizado. 4.4 Nomenclatura de archivos. 4.4.1 RU: Registro de Usuario. La nomenclatura es: _ _ _ _ _ _ .zip Valores: – es el identificador del operador. – es el identificador del Almacén. – será RU. – puede ser: RUT, RUD, RUR, RUG. – puede ser: D (diario) o M (mensual). – es la fecha sobre la que se declaran los datos (no la fecha de escritura en el Almacén). Para información diaria tendrá el valor AAAAMMDD y para información mensual AAAAMM. – es el identificador del lote. 4.4.2 CJ: Cuenta de juego. La nomenclatura es: _ _ _ _ _ _ .zip Valores: – es el identificador del operador. – es el identificador del Almacén. – será CJ. – puede ser: CJT, CJD. – puede ser: D (diario) o M (mensual). – es la fecha sobre la que se declaran los datos (no la fecha de escritura en el Almacén). Para información diaria tendrá el valor AAAAMMDD y para información mensual AAAAMM. – es el identificador del lote. 4.4.3 OP: Cuenta de Operador. La nomenclatura es: _ _ _ _ _ _ _ .zip Valores: – es el identificador del operador. – es el identificador del Almacén. – será OP. – puede ser: OPT, ORT o BOT. – según la lista de tipos de juego Juego (ver apartado «Tipo de Juego»). – solo puede ser: M (mensual). – es la fecha sobre la que se declaran los datos (no la fecha de escritura en el Almacén). Tendrá formato AAAAMM. – es el identificador del lote. 4.4.4 JU: Registro de Juego. Los ficheros del día en curso tendrán la siguiente nomenclatura: _ _ _ _ _ _ .zip Valores: – es el identificador del operador. – será: JU. – será: JUC. – según la lista de tipos de registro (SES, POT, RAC, RAM, COC, LOT o LOP). – es la fecha del lote, formato AAAAMMDDHHMMSS. – es el identificador del lote. Los ficheros empaquetados para los Juegos de días anteriores tendrán la siguiente nomenclatura: _ _ _DIARIO_ . Valores: – es el identificador del operador. – será: JU. – es la fecha del día agrupado, formato AAAAMMDD. – : La extensión será «zip», pero si ha de fragmentarse por superar el tamaño de 1 GB aparecerán otras extensiones correlativas. Estas adoptarán la forma «zip.00x», donde x será 1 para el primer fragmento, 2 para el segundo, y así sucesivamente. 4.4.5 JUA: Ajustes de Apuestas y CEV: Catálogo de Eventos. La nomenclatura es: _ _ _ _ _ _ .zip Valores: – es el identificador del operador. – es el identificador del Almacén. – será JU. – puede ser: JUA o CEV. – solo puede ser: D (diario) o M (mensual). – es la fecha sobre la que se declaran los datos (no la fecha de escritura en el Almacén). Para información diaria tendrá el valor AAAAMMDD y para información mensual AAAAMM. – es el identificador del lote. 4.5 Conceptos generales. 4.5.1 OperadorId. Este código es proporcionado por la Dirección General de Ordenación del Juego en el proceso de obtención de licencia y es único y nominativo para cada operador. Siempre que se haga referencia a un operador, debe indicarse el OperadorId único proporcionado por la Dirección General de Ordenación del Juego. 4.5.2 AlmacenId. Este código es proporcionado por la Dirección General de Ordenación del Juego en el proceso de obtención de licencia y es único para cada Almacén. Los Almacenes que actúan como réplica no deben utilizar un AlmacenId distinto del Almacén principal. 4.5.3 Registro. Un registro representa una unidad de información completa en un periodo determinado que se reporta al Almacén. Un registro queda definido por tres parámetros: – El tipo de información: RU, CJ, OP o JU. – La periodicidad: Mensual, diaria o tiempo real. – El nivel de detalle: Totalizada y Desglosada. Por ejemplo, registro de usuario detallado de un día, la cuenta de juego totalizada de un mes o cada uno de los registros de juego en el momento que se conoce su resultado. Los registros constan de una cabecera común e información específica para cada tipo de información. El RegistroBase es el tipo del que se derivan todos los registros. Se trata de un tipo abstracto, lo cual quiere decir que no puede reportarse directamente. Los registros que han de reportarse se derivan del RegistroBase o de otros tipos abstractos intermedios. Descomposición de un registro en subregistros: Todos los registros con desglose a nivel de jugador (RUD, RUR, RUG, CJD y JUC) con un número de jugadores superior a 1.000 se deberán descomponer en subregistros, con un máximo de 1.000 jugadores cada uno. Antes de empezar un subregistro nuevo, hay que agotar los 1.000 jugadores que le caben al subregistro en curso. Esta misma descomposición en subregistros es aplicable también al catálogo de eventos (CEV) y al registro de ajustes de apuestas (JUA), contabilizándose 1000 eventos por subregistro para CEV y 1.000 ajustes por subregistro para JUA. SubregistroId /. SubregistroTotal. Cuando el registro no se descompone en subregistros, se indicará 1/1. Cuando se realice la descomposición, por ejemplo, un registro con información desglosada de 2.325 jugadores, se generarán 3 subregistros: – 1/3: 1.000 jugadores. – 2/3: 1.000 jugadores. – 3/3: 325 jugadores. Rectificacion. Rectificacion.RegistroId Rectificacion.RegistroFecha. El modelo permite rectificar los datos de un registro anterior. La rectificación anula por completo el registro referenciado y debe presentar un nuevo registro con la información correcta. El registro referenciado no debe ser borrado de la base de datos del operador. La rectificación únicamente puede referenciar a un registro del mismo almacén. Se indicará el RegistroId referenciado para rectificar, así como la fecha del registro referenciado. Si la rectificación no referencia ningún registro se considerará un registro duplicado y se considerará error de reporte. 4.5.4 Rectificaciones. Si el operador detecta que los datos que ha grabado en algún registro son erróneos, debe proceder a su rectificación. Sustitución completa de un registro anterior presentando el nuevo registro. En la grabación del nuevo registro se hará uso de los campos «Rectificacion» para indicar cuál es el registro sustituido. En la sustitución, debe indicarse contenido para todos los campos (no únicamente las modificaciones). La sustitución debe generarse siempre dentro del mismo Almacén. El registro sustituido no debe eliminarse físicamente. Se entenderá anulado lógicamente. El registro para realizar la sustitución completa es un registro nuevo que tenga informados los campos de «Rectificación». 4.5.5 Registros periódicos. Los registros de información periódica se basan en tipos derivados del RegistroBase, con campos adicionales que permiten determinar el periodo respecto al cuál 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, CJD, CJT y CEV), se utilizará RegistroPeriodicoBase. – Si el registro sólo se puede reportar mensualmente (RUT, RUR, RUG, OPT, ORT, BOT y JUA), se utilizará RegistroMensualBase. 4.5.6 Registros de Juego (JUC). Los juegos de casino: póquer cash, bingo, slots, ruleta, black Jack, punto y banca, juegos complementarios y loterías presorteadas deben desarrollarse en el marco de una sesión de juego. Para su reporte se tendrá que generar un fichero de tipo RegistroOtrosJuegos para cada sesión de juego realizada por cada jugador. Este RegistroOtrosJuegos tendrá la información del jugador, los parámetros de configuración de la sesión y la información agregada por cada uno de los tipos de juego. Por ejemplo, un jugador a lo largo de un día abre dos sesiones de juego, en la primera juega solo al bingo, en tres partidas de bingo; más tarde abre una segunda sesión en la que juega a dos manos de póquer cash, 5 tiradas de la ruleta y 10 tiradas de slots. A la finalización de cada sesión deberá reportar un registro de tipo RegistroOtrosJuegos, en el primero habrá un único bloque de juego con el total del resultado de las tres partidas de bingo. El segundo tendrá tres bloques de juego, uno para el resultado agregado de las dos manos de póquer cash, otro para el resultado del juego de ruleta y uno con el resultado agregado de las 10 tiradas de slots. Esto aplica igualmente para el reporte de las sesiones de juego de loterías presorteadas utilizando en este caso el registro tipo RegistroLoteriaPresorteada. Los registros que no están englobados en una sesión de juego y se envían individualmente con cada participación del jugador son: – RegistroPoquerTorneo. – RegistroApuestaContrapartida. – RegistroApuestaMutua. – RegistroConcurso. – RegistroLoteria. 4.5.6.1 Juegos y Registros. A continuación, se muestran los registros utilizados para cada uno de los tipos de Juego. 4.5.7 Lote. Un lote se utiliza para agrupar registros (sería inmanejable tener un fichero para cada registro generado, en el caso de los JUs), pero también para fragmentarlos (en los casos en los que los registros son muy voluminosos, p.ej. RU o CJs). 4.5.8 Periodicidad y fragmentación. Los lotes se deben generar de acuerdo con las siguientes reglas: – Información periódica (RU, CJ, OP, JUA, CEV): cada registro irá en un lote (o varios si hay fragmentación del registro en subregistros). Se genera diaria y/o mensualmente, según el tipo de fichero. Se ha de cumplir la siguiente regla: A partir de 10 subregistros, se debe generar un nuevo lote (y sólo se puede generar uno cuando se haya cubierto el cupo de 10 subregistros en el anterior). Por tanto, sólo el último lote correspondiente a un registro (es decir, el que contiene los últimos subregistros) puede contener un número de subregistros menor que 10. Un lote no debe incluir información relativa a registros distintos. En particular, no deben existir rectificaciones de dos registros distintos en un mismo lote. – Información en tiempo real (JUC): en este caso, un lote contiene información de uno o varios registros, cada uno de los cuales se corresponde con un conjunto de juegos de un mismo tipo durante una sesión, una apuesta, un torneo, un concurso o un sorteo, dependiendo del tipo de juego de que se trate. Se generará un lote cuando transcurran 15 minutos desde que se generó el lote anterior o cuando se alcance la cifra de 500 subregistros en dicho lote (lo que suceda antes). 4.5.9 Tipos de movimiento libres. El operador debe explicar todos los movimientos que causen variaciones de saldo del jugador. Los tipos de movimiento predefinidos, como «depósitos», «retiradas», «participación» y «premios», no permiten adaptarse a todos los posibles tipos de movimientos que pueden tener impacto en el saldo del jugador. El elemento «Concepto» del campo «Otros» es libre y permite al operador extender el modelo definiendo sus propios tipos de movimiento cuando no existe una correspondencia con uno de los tipos de movimiento predefinidos. En cualquier caso, el operador debe utilizar preferentemente el elemento predefinido si está disponible. La Dirección General de Ordenación del Juego se reserva la posibilidad de definir algún otro concepto de uso obligatorio. 4.5.10 Desgloses que se repiten varias veces. Se crean varios tipos de datos que representan desgloses para facilitar el mantenimiento del modelo. DesgloseOperador. Importe total y desglose por operador. DesgloseTipoJuego. Importe total y desglose por tipo de juego. DesgloseConcepto. Importe total y desglose por concepto. DesgloseConceptoOP. Importe total y desglose por operador y concepto. DesgloseConceptoBonosT. Importe total y desglose por concepto de bonos (CONCESION, LIBERACION Y CANCELACION) totalizado. DesgloseConceptoBonosD. Importe total y desglose por concepto de bonos (CONCESION, LIBERACION Y CANCELACION) con detalle. DesgloseBotes. Importe total y desglose por operador. DesgloseBotesId. Importe total y desglose por bote. DesgloseMedioPagoT. Importe total y desglose por medio y tipo de pago, totalizada. DesgloseMedioPagoD. Importe total y desglose de cada una de las operaciones de depósito o retirada de efectivo desglosada. 4.5.11 Sobre campos económicos vacíos en ficheros. 4.5.11.1 Campos Obligatorios. Ningún campo obligatorio puede permanecer vacío o sin definición porque se producirá un error de incumplimiento de la gramática. Esto ocurre por ejemplo con los elementos, «Total» en «Depositos» y «Retiradas». Para estos elementos se esperan valores incluso si no hay ingresos (Depósitos) o retiros (Retiradas) porque el XSD los marca como obligatorios. En estos casos se rellenan a 0. Ejemplo: Forma correcta de Jugador sin depósito. Ejemplo: Formas Incorrectas de Jugador sin depósito. 4.5.11.2 Campos Opcionales. Para otros elementos, donde la definición del xsd permite 0 ocurrencias, los campos pueden quedar sin definición (vacías) o rellenas a 0. «Línea» en Participación sería un ejemplo de este tipo de campo. Para un jugador sin participación (0 euros de participación) cualquiera de las siguientes opciones es correcta: 1. Anexos 1. Anexos 1.1 Listas y enumerados. CambioEnDatos: Cambio en datos (RUD). ConceptoBonos: Concepto bonos (CJD, CJT, CJR). ConceptoOPT: Ajustes de cuenta del operador (OPT, ORT). EstadoCNJ: Estado CNJ (RUD, RUR, RUT). ListaCodigo: Lista de códigos de eventos admitidos (CEV). MotivoEstado: Motivo por el cual la cuenta del jugador ha sido Suspendida o Cancelada (RUD). Cuenta cancelada a petición del jugador. La suspensión de cuenta a petición del jugador no se reportará como Suspensión sino como AutoExclusión. Cuenta suspendida o cancelada por violación o incumplimiento de los Términos y Condiciones del contrato suscrito entre el jugador y el operador. A modo de ejemplo: – Cuenta suspendida o cancelada por utilización de tecnologías no autorizadas o con fines indebidos, como, por ejemplo, el uso de bots, herramientas de inteligencia artificial, VPNs o cualquier otra tecnología utilizada con fines indebidos. – Cuenta suspendida o cancelada por sospechas o confirmación de colusión, «chip dumping» o malas prácticas del jugador en connivencia con otros jugadores. – Cuenta suspendida o cancelada por sospecha de amaño deportivo, uso de información privilegiada o alertas de amaño recibidas. – Cuenta suspendida o cancelada por violación de las condiciones particulares de bonos. – Cuentas suspendida o cancelada por prácticas fraudulentas durante el desarrollo del juego que supongan una alteración del normal desarrollo de los juegos. – Cualquier otro motivo recogido en los Términos y Condiciones. MotivoFinSesion: Motivo por el cual se ha cerrado la sesión (RegistroOtrosJuegos, RegistroLoteriaPresorteada). PaisISO: Países y territorios según el código ISO de 2 caracteres (RUD, RUG, CEV). (Códigos ISO 3166). PerfilJugador: Perfil del jugador especial según RD de juego seguro (RUD). PeriodoLimite: Periodo al que aplica el límite del jugador (RUD). Sexo: Sexo del jugador (RUD, RUR). SexoCompeticion: Género a la que pertenece la competición deportiva (CEV). TipoApuesta: Tipo de apuesta realizada (RegistroApuestaContrapartida, RegistroApuestaMutua). TipoDispositivo: Tipo de dispositivo del jugador (CJD, RUD, RegistroPoquerTorneo, RegistroApuestaContrapartida, RegistroApuestaMutua, RegistroLoteriaPresorteada). TipoDocumento: Tipo de documento aportado por el jugador no residente (RUD, RUG). TipoJuego: Tipo de juego (todos los registros). TipoLimite: Tipo de limite (RUD). TipoMedioPago: Lista de códigos de medios de pago admitidos (CJD). TipoRegistro: Tipos de registro JUC. TipoResultado: Resultado de la operación de depósito o retirada (CJD). TipoVerificacionDocumental: Tipo de verificación documental del jugador realizada (RUD). UnidadLimite: Valores posibles de las unidades de los límites del jugador (RUD). VariantePoker: Variante de juego de póquer (RegistroPoquerTorneo). VarianteSesion: Variantes de los juegos de Póquer Cash, Black Jack y Ruleta (RegistroOtrosJuegos). 1.2 Tipos de campos. La experiencia de los años de funcionamiento del modelo de datos de la SCI, en sus versiones 1.x y 2.x nos ha hecho ver la importancia de detallar lo máximo posible el formato, tipo y longitud de los campos del modelo. Por eso en la nueva versión 3.x se han definido una serie de campos de cadena de longitudes fijas para evitar los errores del pasado. Campos de cadena de caracteres. Cualquiera de estos campos marca la longitud máxima de la información que contienen, pero no la mínima. Estos nuevos campos son: – cadena10. Cadena de caracteres de longitud máxima 10. – cadena20. Longitud máxima de 20 caracteres. – cadena50. Longitud máxima de 50 caracteres. – cadena100. Longitud máxima de 100 caracteres. – cadena200. Longitud máxima de 200 caracteres. – cadena1000. Longitud máxima de 1000 caracteres. Campos numéricos. Se define un tipo de campo numérico: – cantidad. Decimal con un máximo de 2 decimales y un total de 12 dígitos de longitud máxima. – entero3. Número entero de 3 dígitos de longitud máxima. – entero6. Número entero de 6 dígitos de longitud máxima. – entero8. Número entero de 8 dígitos de longitud máxima. Campos de tipo fecha. Hay varios campos de tipo Fecha definidos en el modelo, estos son: – date-aaaamm: Año y mes. Por ejemplo: 202301. – date-hhmmss: Hora, minutos y segundos. Por ejemplo: 081125. – Date-ddhhmm: Días, horas y minutos. Por ejemplo: 270811. – date-aaaammdd: Año, mes y día. Por ejemplo: 20230127. – date-aaaammddhhmmss: Año, mes, día, hora, minuto y segundo. Por ejemplo: 20230127081125. – date-aaaammddhhmmssTZ: la misma anterior añadiendo la zona horaria. Por ejemplo: 20230127081125+0100.

Cuarto. Modificar el anexo I de Resolución de 12 de julio de 2012, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición que desarrolla los artículos 26 y 27 del Real Decreto 1613/2011, de 14 de noviembre, en relación con la identificación de los participantes en los juegos y el control de las prohibiciones subjetivas a la participación. El anexo I de la Resolución de 12 de julio de 2012, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición que desarrolla los artículos 26 y 27 del Real Decreto 1613/2011, de 14 de noviembre, en relación con la identificación de los participantes en los juegos y el control de las prohibiciones subjetivas a la participación, queda modificado como sigue: Único. El punto 5 del apartado séptimo. Verificación a través del Sistema de Verificación de Identidad, queda redactado como sigue: «5. El operador registrará y conservará cuantas consultas realice al sistema de verificación de identidad, dejando constancia de la fecha, hora y minuto de la consulta. Los datos deberán ser conservados, junto con los correspondientes al registro de usuario, durante el período de vigencia del registro de usuario y durante los cuatro años siguientes a su cancelación o anulación.»

Primero. Aprobar el Modelo de datos del sistema de monitorización de la información correspondiente a los registros de operaciones de juego que se acompaña como anexo I.

Quinto. A la entrada en vigor de la presente resolución queda derogada la Resolución de 6 de octubre de 2014, de la Dirección general de Ordenación del Juego, por la que se aprueba el modelo de datos del sistema de monitorización de la información correspondiente a los registros de operaciones de juego.

Segundo. Aprobar la estructura de ficheros del sistema de monitorización de datos en formato XSD (Definición XML), que se publicará en la sede electrónica de la Dirección General de la Ordenación del Juego.

Sexto. La presente resolución entrará en vigor a los nueve meses de su publicación en el «Boletín Oficial del Estado», sin perjuicio de que aquellos operadores que hubieran podido adaptar sus sistemas al modelo de datos aprobado en la misma puedan, de forma facultativa, empezar a utilizarlo en sus relaciones con la DGOJ a partir de los seis meses desde la publicación de esta resolución.

Tercero. Modificar el anexo I de la Resolución de 6 de octubre de 2014, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición por la que se desarrollan las especificaciones técnicas de juego, trazabilidad y seguridad que deben cumplir los sistemas técnicos de juego de carácter no reservado objeto de licencias otorgadas al amparo de la Ley 13/2011, de 27 de mayo, de regulación del juego. El anexo I de la Resolución de 6 de octubre de 2014, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición por la que se desarrollan las especificaciones técnicas de juego, trazabilidad y seguridad que deben cumplir los sistemas técnicos de juego de carácter no reservado objeto de licencias otorgadas al amparo de la Ley 13/2011, de 27 de mayo, de regulación del juego, queda modificado como sigue: Uno. El apartado 2.1.2 Conservación de copia de los documentos aportados queda redactado como sigue: «2.1.2 Conservación de copia de los documentos aportados. El operador establecerá los procedimientos técnicos necesarios para la conservación de la copia digital de los documentos aportados por los participantes estableciendo una tipificación del proceso de verificación realizado de acuerdo con la lista normalizada publicada en la página web de la DGOJ. Los documentos aportados deberán conservarse durante el periodo de actividad de la cuenta de juego y por un periodo de 4 años desde la cancelación de la cuenta.» Dos. El apartado 2.1.4 Servicios de verificación ofrecidos por la Dirección General de Ordenación del Juego queda redactado como sigue: «2.1.4 Servicios de verificación ofrecidos por la Dirección General de Ordenación del Juego. La Dirección General de Ordenación del Juego proporciona a los operadores un servicio online de verificación de los datos de identidad y fecha de nacimiento para participantes residentes en España: el servicio de verificación se basa en el NIF/NIE del participante. El operador registrará y conservará cuantas consultas realice al sistema de verificación de identidad, dejando constancia de la fecha, hora y minuto de la consulta. Los datos deberán ser conservados, junto con los correspondientes al registro de usuario, durante el período de vigencia del registro de usuario y durante los cuatro años siguientes a su cancelación o anulación. La Dirección General de Ordenación del Juego proporciona a los operadores dos servicios online de verificación para la inscripción de los participantes en el Registro General de Interdicciones de Acceso al Juego: – Un servicio de verificación de la inscripción de un participante en el Registro General de Interdicciones de Acceso al Juego para participantes residentes en España a partir de NIF/NIE. Los operadores deberán utilizar este servicio para comprobar la inscripción en el proceso de registro de usuario. – Un servicio de consulta de las variaciones (altas/bajas) en la inscripción en el Registro General de Interdicciones de Acceso al Juego, correspondientes a los participantes que previamente hubiera verificado el operador. Los operadores deberán utilizar este servicio cada hora para verificar las variaciones en la inscripción 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án ser conservados, junto con los correspondientes al registro de usuario, durante el período de vigencia del registro de usuario y durante los cuatro años siguientes a su cancelación o anulación.» Tres. El apartado 2.1.5 Activación del registro de usuario y limitación en la participación queda redactado como sigue: «2.1.5 Activación del registro de usuario y limitación en la participación. El operador dispondrá de un procedimiento documentado de registro y activación de usuario que recogerá los requisitos de identificación y limitación de la participación establecidos en los artículos 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ón del juego, en lo relativo a los requisitos técnicos 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ón de los participantes en los juegos que organicen o desarrollen. Asimismo, el operador deberá contar con un servicio de verificación 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ón de identidad. Los operadores deberán registrar y conservar la totalidad de las gestiones, consultas y requerimientos que hubieran realizado para la verificación de los datos aportados por los solicitantes, así como cuantos documentos hubieran recibido o empleado con este fin. Los datos deberán ser conservados, junto con los correspondientes al registro de usuario, durante el período de vigencia del registro de usuario y durante los cuatro años siguientes a su cancelación o anulación.» Cuatro. El apartado 2.1.14 Registro de la configuración de la sesión destinada al juego de máquinas de azar queda redactado como sigue: «2.1.14 Registro de la configuración de la sesión de juego bajo la licencia general de ''Otros juegos''. En el caso de la Licencia General de Otros Juegos, los operadores deberán registrar y conservar los datos relativos a la configuración por parte del usuario de cada una de sus sesiones de juego bajo la licencia general de «Otros juegos», según lo establecido en el artículo 13 del Real Decreto 176/2023, de 14 de marzo, por el que se desarrollan entornos más seguros de juego.» Cinco. Se añade un nuevo apartado 2.1.15 Registro de las comunicaciones del servicio de atención al jugador, con la siguiente redacción: «2.1.15 Registro de las comunicaciones del servicio de atención al jugador. El operador deberá registrar y conservar durante dos años las comunicaciones con los participantes a través de los diferentes canales del servicio de atención al jugador.» Seis. El apartado 2.3.1 Registro de las operaciones de pago y cobro queda redactado como sigue: «2.3.1 Registro de las operaciones de pago y cobro. El operador deberá conservar o estar en disposición de obtener el apunte detallado de cada operación de depósito o retirada junto con toda la información asociada a cada operación, independientemente de que utilice medios propios o de terceros. El operador establecerá los procedimientos técnicos necesarios para la conservación de la copia digital de los documentos aportados por los participantes estableciendo una tipificación del proceso de verificación realizado de acuerdo con la lista normalizada publicada en la página web de la DGOJ. Cuando se utilicen servicios de tarificación adicional, el operador deberá conservar la información relativa al importe de participación y al identificador de juego o concurso en que el que tuvo lugar la participación, y estar en disposición de obtener el número de teléfono y la cuenta utilizados para facturar la participación al jugador.» Siete. El apartado 2.4.1 Protección de datos queda redactado como sigue: «2.4.1 Protección de datos. Los operadores establecerán los procedimientos técnicos adecuados para mantener la privacidad de los datos de los participantes de conformidad con la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales, y su normativa complementaria. Los operadores deberán asimismo implantar sobre los ficheros y tratamientos las medidas de seguridad establecidas en la normativa vigente en materia de protección de datos y dar cumplimiento al deber de secreto impuesto por dicha normativa.» Ocho. La letra d) del apartado 4.13 Gestión de cambios queda redactada como sigue: «d) Se conservarán copias del código fuente, o de los binarios o de otros formatos que permitan su posterior despliegue y auditoría, de los elementos de software de todas las versiones software que se hayan utilizado en el sistema técnico efectivamente empleado en los últimos cuatro años. La Dirección General de Ordenación del Juego podrá establecer la obligación de que el procedimiento de conservación de las copias de los elementos de software incluya una huella digital de los mismos.» Nueve. El apartado 5.1.13 Conservación de la información del SCI queda redactado como sigue: «5.1.13 Conservación de la información del SCI. El almacén debe conservar sus datos por un periodo mínimo de cuatro años. Los operadores de juego tendrán la obligación de facilitar y permitir a la Dirección General de Ordenación del Juego el acceso online a la información correspondiente a los doce últimos meses de actividad registrada en el almacén. Los operadores deberán tener previsto un procedimiento de recuperación de la información correspondiente a un periodo mínimo de cuatro años.» Diez. El apartado 5.1.14 Ubicación del almacén en España queda redactado como sigue: «5.1.14 Ubicación del almacén en la Unión Europea. El almacén o almacenes del SCI, así como sus copias de seguridad o sitios de réplica secundarios, deberán estar ubicados en la Unión Europea, con la finalidad de realizar las operaciones de verificación y control de la información. La ubicación y cualquier modificación de esta deberán ser comunicadas a la Dirección General de Ordenación del Juego.» Once. El apartado 6.1 Registro y trazabilidad queda redactado como sigue: «6.1 Registros 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ón en el desarrollo del juego, en el registro de usuario, en las cuentas de juego o en los medios de pago. En relación con los datos de desarrollo del juego, los datos deberán poder reconstruir todos los lances del juego que pudieran tener repercusión sobre su desarrollo. El Sistema Técnico de Juego también debe conservar registros y logs en materia de seguridad de los sistemas de información. Todos los referidos registros y logs deberán ser accesibles online para la Dirección General de Ordenación 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ón a la Dirección General de Ordenación del Juego. Sin perjuicio de lo anterior, los registros y logs deben ser conservados en almacenamiento durante al menos cuatro años. Los operadores deberán tener previsto un procedimiento de recuperación de esta información. Los registros y logs estarán diseñados de forma que se evite la posibilidad de borrado o modificación. Cualquier actuación de borrado que el operador deba realizar, por ejemplo, para corregir errores técnicos, deberá ser debidamente aprobada por el operador y se conservará la documentación justificativa de los ajustes realizados.»