Legislación › 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.
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:
| Tipo de operador | Tipo de registro | ||||||
|---|---|---|---|---|---|---|---|
| Registro de Usuarios | Cuenta de Juego | Cuenta de Operador | Cuenta de Botes y Partidas Vivas | Registro de Juego | Ajustes de Apuestas | Catálogo de Eventos | |
| Gestor registro de usuario. |
√ (RUD, RUT) |
√ (CJD, CJT) |
√ (OPT) |
√ (BOT) |
√ (JUC) |
√ (JUA) |
√ (CEV) |
| Adscrito a una red. |
√ (RUD, RUT) |
√ (CJD, CJT) |
√ (OPT) |
– | – | – | – |
| Coorganizador de la red. |
√ (RUR, RUT) |
– |
√ (ORT) |
√ (BOT) |
√ (JUC) |
– | – |
| Gestor de botes compartidos. | – | – | – |
√ (BOT) |
– | – | – |
| De juegos sin Registro Previo. |
√ (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:
| Periodicidad | Tipo de Registro | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| RUD | RUT | RUR | RUG | CJD/CJT | OPT/ORT | BOT | JUC | JUA | CEV | |
| Tiempo real. | – | – | – | – | – | – | – | √ | – | – |
| Diaria. | √ | – | – | – | √ | – | – | – | – | √ |
| Mensual. | √ | √ | √ | √ | √ | √ | √ | – | √ | √ |
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:
| JugadorId. | Identificación única del jugador en la plataforma. |
| FechaActivacion. | Fecha en la que la identidad del usuario ha sido verificada por primera vez y por tanto adquiere el estado activo. |
| CambiosEnDatos. |
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. |
| RegionFiscal. |
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. |
| FechaNacimiento. | Fecha de nacimiento del participante en el formato indicado en el modelo de datos. |
| Login. | Login del usuario en la plataforma. |
| Pseudonimo. | Pseudónimo o pseudónimos (alias, nickname) utilizados por el jugador en la plataforma. Opcional. |
| Nombre. | Nombre. |
| Apellido1. | Primer apellido. |
| Apellido2. | Segundo apellido. En el caso de extranjeros el segundo apellido es opcional. |
| Email. | Email empleado por el participante para darse de alta en la plataforma. El formato del mail ha de ser correcto. |
| EmailVerificado. | (S) email ha sido verificado por el operador / (N) no ha sido verificado. |
| Sexo. | (M) Masculino/(F) Femenino. |
| Domicilio. |
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. |
| Teléfono. | Teléfono. |
| TelefonoVerificado. | (S) teléfono verificado por el operador / (N) no verificado. |
| LimitesJugador. |
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. |
| Exclusion. |
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. |
| PerfilEspecial. |
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. |
| Estado. |
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. |
| VSVDI. | Verificación del SVDI. Tomará valor S (Sí), si se ha usado el Sistema de Verificación de Identidad de la DGOJ y se ha obtenido verificación positiva, o N (No) en caso contrario. |
| FVSVDI. |
Fecha de la primera verificación positiva en el SVDI. Campo opcional, solo es obligatorio si VSVDI=«S». |
| VDocumental. | Verificación documental. Tomará valor S (Si), si se ha realizado la verificación de usuario documentalmente y ha resultado positiva, o N (No), en caso contrario. |
| TipoVDocumental. |
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. |
| JugadorTest. | Se reporta «S» si el jugador es un jugador de pruebas en la plataforma de juego en el momento de generar el registro. |
| IP. |
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. |
| Dispositivo. |
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. |
| IdDispositivo. |
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.
| NumeroJugadores. |
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. |
| NumeroAltas. | Número de participantes dados de alta en la plataforma de juego durante el periodo. |
| NumeroBajas. |
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. |
| NumeroActividad. |
Número de usuarios con actividad durante periodo. Número de jugadores que hayan realizado al menos una apuesta en euros durante el periodo. |
| NumeroTest. | Número de jugadores de test reportados en el periodo. |
| NumeroJugadoresPorEstado. | Se indicará el número de jugadores clasificados en cada uno de los estados de la DGOJ. |
| NumeroJugadoresPorPerfil. | Se indicará el número de jugadores clasificados por cada uno de los perfiles especiales. |
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.
| ID. |
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. |
| Login. | Login del usuario en la plataforma. |
| Estado. |
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:
| TipoJuego. | Tipo de juego de Loterías en que el jugador ha sido premiado. |
| Premio. | Valor en euros del premio del jugador ganador de Lotería presencial. |
| Retencion. | Valor en euros de la retención realizada sobre el premio del jugador ganador de Lotería presencial. |
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:
| 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:
|
||||||||
| Competición. |
Dato descriptivo indicando la competición a la que pertenece el evento. Ejemplos:
|
||||||||
| 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


