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

JuegadorId.	Identificación única del jugador en la plataforma.
SaldoInicial.	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.
Depositos.	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).
Retiradas.	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.
Participacion.	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.
ParticipacionDevolucion.	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.
Premios.	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».
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.
Trans_IN.	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.
Trans_OUT.	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.
Otros.	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.
SaldoFinal.	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.
Cuentas.	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.
Comision.	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.
Bonos.	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.
PremiosEspecie.	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.
Regalos.	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:

TipoJuego.	Tipo de juego respecto al que se declaran los datos de acuerdo a la tipificación de los juegos incluida en el «Tipo de Juego» de esta resolución.
Participacion.	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.
ParticipacionDevolucion.	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.
Premios.	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.
PremiosEspecie.	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.
Botes.	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).
AjustesRed.	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.
Otros.	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.
Comision.	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.
GGR.	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.
FechaInicioOferta.	Fecha en la que comenzó la oferta del juego reportado.

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:

TipoJuego.	Tipo de juego del que informa el registro.
PartidasVivas.	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.
Botes.	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.

JuegoId.	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.
JuegoDesc.	Descripción del juego.
TipoJuego.	Detalle en el apartado «Listas y enumerados».
FechaInicio.	Fecha y hora en la que se realiza la primera apuesta en el juego.
FechaFin.	Fecha y hora del final del hecho que genera la obligación de informar al SCI.

Campos comunes del bloque de Jugador.

JugadorId.	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.
IP.	Dirección IP del dispositivo del jugador desde el que se conectó al juego.
Dispositivo.	Tipo de dispositivo del jugador desde el que se conectó al juego.
IdDispositivo.	Identificador del dispositivo.

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:

Participacion.	Total agregado de las participaciones en el juego durante la sesión reportada. (-) Se reportará con signo negativo.
ParticipacionDevolucion.	Total agregado de las devoluciones de participaciones en el juego durante la sesión reportada. (+) Se reportará con signo positivo.
Premios.	Total agregado de los premios en el juego durante la sesión reportada. (+) Se reportará con signo positivo.
Botes.	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.
Variante.	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».
VarianteComercial.	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.
JuegoEnVivo.	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.
JuegoEnRed.	Se reportará sólo y obligatoriamente para el juego POC. «S» si el juego se ha producido en una red de póquer.
LiquidezInternacional.	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».
MesaId.	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.
PartidasJugadas.	Número de partidas jugadas durante la sesión para el juego reportado.

Y los siguientes campos específicos para el bloque Jugador:

Sesion.	Información de los parámetros y características de la sesión reportada. Es un campo múltiple compuesto de los siguientes campos:
SesionId.	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.
FechaInicioSesion.	Fecha y hora de inicio de la sesión.
FechaFinSesion.	Fecha y hora de fin de la sesión (sea por la razón que sea el cierre).
FechaInicioPrimerJuego.	Fecha y hora de inicio del primer juego dentro de la sesión.
FechaFinUltimoJuego.	Fecha y hora de finalización del último juego de la sesión.
PlanificacionSesion.	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.
SesionCompleta.	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.
SesionNueva.	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.
MotivoFinSesion.	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:

JuegoEnRed.	«S» si el juego se ha producido en una red de póquer.
LiquidezInternacional.	«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.	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».
VarianteComercial.	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.
NumeroParticipantes.	Número de jugadores en el torneo reportado. Se incluirán todos los jugadores con independencia de la jurisdicción a la que pertenezcan.
ContribucionOperadorOVL.	Contribuciones a los premios realizadas por el operador (Overlay).
ContribucionOperadorADD.	Liberacion de bonos para entradas a torneos realizadas por el operador (ADD).

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:

Participacion.	Total de las participaciones en el torneo. (-) Se reportará con signo negativo.
ParticipacionDevolucion.	Total de las devoluciones de participaciones en el torneo. (+) Se reportará con signo positivo.
Premios.	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:

EnDirecto.	«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».
TipoApuesta.	Tipo de la apuesta en función de los eventos y hechos apostados. Detalle en el apartado «Listas y enumerados».
NumeroEventos.	Número de eventos distintos sobre los que se apuesta.
Eventos.	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:

SaldoCuenta	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.
Participacion	Valor total de la apuesta reportada. (-) Se reportará con signo negativo.
ParticipacionDevolucion	Valor total de las devoluciones de la apuesta. (+) Se reportará con signo positivo.
Premios	Total de premios recibidos por la apuesta. (+) Se reportará con signo positivo.
TicketApuesta	Ticket obtenido por participante una vez cerrada la apuesta.
Cuota	Valor de la cuota de la apuesta (en valor decimal) en el momento en que es aceptada por el jugador.
CashOut	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:

TipoApuesta.	Tipo de la apuesta en función de los eventos y hechos apostados. Detalle en el apartado «Listas y enumerados».
NumeroEventos.	Número de eventos distintos sobre los que se apuesta.
Eventos.	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».
DesgloseCruzadas.	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:

Participacion.	Valor total de la apuesta reportada. (-) Se reportará con signo negativo.
ParticipacionDevolucion.	Valor total de las devoluciones de la apuesta. (+) Se reportará con signo positivo.
Premios.	Total de premios recibidos por la apuesta. (+) Se reportará con signo positivo.
Botes.	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.
TicketApuesta.	Ticket obtenido por participante una vez cerrada la apuesta.
FechaApuesta.	Fecha y hora en la que jugador realiza la apuesta.
Cuota.	Valor de la cuota de la apuesta en el momento en que es aceptada por el jugador. Estará expresada en formato decimal.
CashOut.	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:

NumeroParticipaciones.	Número de participaciones.
NumeroPremiados.	Número de premiados.
NumeroLlamadas.	Número de llamadas.
PrecioMinutoLlamada.	Precio del minuto por llamada.
ImporteMaximoLlamada.	Importe máximo Llamada.
ParticipacionLlamadas.	Importe total de la participación pagada por los jugadores en concepto de llamadas, incluyendo los servicios de tarificación adicional y cualesquiera otros.
STALlamadas.	Importe de la parte correspondiente a servicios de tarificación adicional correspondiente a llamadas.
NumeroSMS.	Número de SMS.
PrecioSMS.	Precio del SMS. Si hay varios precios, se indicará el máximo.
ParticipacionSMS.	Importe total de la participación pagada por los jugadores en concepto de SMS, incluyendo los servicios de tarificación adicional y cualesquiera otros.
STASSMS.	Importe de la parte correspondiente a servicios de tarificación adicional correspondiente a los SMS.

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:

Participacion.	Total agregado de las participaciones en el concurso. (-) Se reportará con signo negativo.
ParticipacionDevolucion.	Total agregado de las devoluciones de participaciones en el concurso. (+) Se reportará con signo positivo.
Premios.	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:

NumeroBoletos.	Número de boletos adquiridos por los jugadores en el sorteo.

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:

Participacion.	Total agregado de las participaciones en el sorteo. (-) Se reportará con signo negativo.
ParticipacionDevolucion.	Total agregado de las devoluciones de participaciones en el sorteo. (+) Se reportará con signo positivo.
Premios.	Total agregado de los premios en el sorteo. (+) Se reportará con signo positivo.
Botes.	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:

NumeroBoletos.	Número total de boletos o billetes jugados durante la sesión de juego.

Y los siguientes campos específicos para el bloque Jugador:

Sesion.	Información de los parámetros y características de la sesión reportada. Es un campo múltiple compuesto de los siguientes campos:
SesionId.	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.
FechaInicioSesion.	Fecha y hora de inicio de la sesión.
FechaFinSesion.	Fecha y hora de fin de la sesión (sea por la razón que sea el cierre).
FechaInicioPrimerJuego.	Fecha y hora de inicio del primer juego dentro de la sesión.
FechaFinUltimoJuego.	Fecha y hora de finalización del último juego de la sesión.
PlanificacionSesion.	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.
SesionCompleta.	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.
SesionNueva.	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.
MotivoFinSesion.	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».
Participacion.	Total agregado de las participaciones en la sesión. (-) Se reportará con signo negativo.
ParticipacionDevolucion.	Total agregado de las devoluciones de participaciones en la sesión. (+) Se reportará con signo positivo.
Premios.	Total agregado de los premios en la sesión. (+) Se reportará con signo positivo.
Botes.	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:

EventoId.	Código asignado por el operador al evento. Deberá coincidir con el código de evento indicado en el registro de la apuesta correspondiente.
TicketApuesta.	Ticket obtenido por participante una vez cerrada la apuesta.
JugadorId.	Identificador único del jugador en la plataforma.
FechaAjuste.	Fecha en la que se produce el ajuste.
MotivoAjuste.	Descripción del motivo por el que se ha producido el ajuste de la apuesta.
ImporteAjuste.	Cantidad efectiva que se añade o se minora al premio de la apuesta ya determinado.

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:

EventoId.	Código asignado por el operador al evento. Deberá coincidir con el código de evento indicado en el registro de la apuesta correspondiente.
DescripcionEvento.	Descripción del evento.
EventoEspecial.	«S» para eventos que no son partidos, carreras o competiciones. Por ejemplo: «máximo goleador del Atlético de Madrid».
FechaInicio.	Fecha de inicio del evento.
FechaFin.	Fecha de finalización del evento, o fecha aproximada si se desconoce en el momento de reportar.
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: Codificación Deporte asociado 17 Fútbol. 37 Squash. 999 OtroCodigoEspecificar: Sumo Sumo (no estaba incluido en el catálogo).
Competición.	Dato descriptivo indicando la competición a la que pertenece el evento. Ejemplos: Competición Deporte asociado Campeonato 2014. Fórmula 1. Supercopa de la UEFA. Fútbol.
CompeticionInternacional.	«S» para competiciones que se desarrollan en más de un país, y N para competiciones que se celebran en un único país.
PaisCompeticion.	País donde se realiza la competición. En caso de competición internacional se utilizará el código 00, en el resto de los casos se usará el código del país mediante los códigos de dos dígitos correspondientes a la norma ISO 3166-1 alfa-2.
SexoCompeticion.	Sexo de la competición: Masculino / Femenino / Otros.
CategoriaCompeticion.	Categoría de la competición. Por ejemplo: Profesional, Amateur, Universitaria, Juvenil, Amistoso.
FaseCompeticion.	Campo opcional, se rellena si aplica. Fase, semana, momento de la competición. Por ejemplo: Previa, semana 2, Clasificatoria, Semifinal.
Actualizado.	«S» para eventos que ya han sido reportados previamente y se están modificando con la información actual. «N» para eventos nuevos.
FechaAltaEvento.	Fecha de alta del evento en la plataforma de apuestas. En caso de eventos nuevos será una fecha actual, en caso de actualizados será la misma fecha que se reportó con el evento la primera vez.

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

<Lote xmlns="http://cnjuego.gob.es/sci/v1.0.xsd" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://cnjuego.gob.es/sci/v1.0.xsd CNJ_Monitorizacion_1.0.xsd http://www.w3.org/2000/09/xmldsig# xmldsig-core-schema.xsd">

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.