MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
QUALITY GUIDE FOR THE CORRECT REPORTING OF ICS DATA
1. Document objective
This document is a guide on the validations made by the General Sub-Directorate General for the Inspection of Gambling (SGIJ) on the files generated and stored by the operators in its Internal Control System (ICS), which can help carry out procedures for quality control of the ICS data on licensed operators.
It is not a complete and disaggregated list, but it does reflect the most important validations to date.
2. Document control
Version Date Description of the changes
1.0 24 May 2018 Creation of document: Quality guide for the correct reporting of ICS data
2.0 29 March 2019 Update with new validations and controls needed to adapt to version 2.13 of the data model. New appendix on test players
3.0 29 October 2019 Update of the new controls and validations put in place since the document’s last update
3.1 22 June 2020 Update of the new controls and validations put in place since the document’s last update
3.2 29 September 2020 Update of the new controls and validations put in place since the document’s last update
3.3 28 October de 2020 Update of the new controls and validations put in place since the document’s last update
3.4 23 March de 2021 New Appendix for the correct use of ‘Actualizado’ field
Page 1 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
3. Contents
1. DOCUMENT OBJECTIVE ...... 1
2. DOCUMENT CONTROL ...... 1
3. CONTENTS ...... 2
4. ABBREVIATIONS USED ...... 7
5. INTRODUCTION...... 10
6. FORMAT VALIDATIONS ...... 10
A. HIGH LEVEL ...... 10 a) General ...... 10 b) RU ...... 11 c) CJ ...... 14 d) OP ...... 14 e) JU ...... 15 f) JUA ...... 15 g) How to correctly report a Registration ...... 16
B. MEDIUM LEVEL ...... 19 a) General ...... 19 b) RU ...... 20 c) CJ ...... 21 d) JU ...... 22
C. LOW LEVEL ...... 23 a) General ...... 23 b) RU ...... 23 c) OPT ...... 23 d) JU ...... 24
7. CONTENT VALIDATIONS...... 24
A. HIGH LEVEL ...... 25 a) General ...... 25
B. MEDIUM LEVEL ...... 25 a) General ...... 25 b) RU ...... 25
Page 2 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
c) CJ ...... 26 d) OP ...... 27
C. LOW LEVEL ...... 30 a) RU ...... 30
8. EXTERNAL VALIDATIONS ...... 30
A. HIGH LEVEL ...... 30 a) CJ ...... 30
B. MEDIUM LEVEL ...... 30 a) RU ...... 30 b) RUD versus JUD ...... 31 c) BOT ...... 31 d) OPT versus BOT ...... 32 e) OPT versus CJT versus JUT ...... 32 f) BOT versus JUT ...... 32 g) JU versus JUA versus CEV ...... 32 h) ORT versus OPT ...... 32 i) JUD versus RUG ...... 33
9. CONTROLS ...... 33
A. ABSENCES ...... 33
B. AC: BETS BADLY REPORTED ON THE CJ ...... 34
C. AE: STATUS UPDATES WITH AE ...... 34
D. AL: EXTENSION OF DEPOSIT LIMITS WITHOUT RESPECTING THE ESTABLISHED TIMELINES ...... 34
E. BC: HEADING OF BONUSES IN CJ FILE ...... 35
F. C2: DUPLICATE PLAYER ACCOUNTS ...... 35
G. CA: ADC QUALITY ...... 35
H. CD: CHANGE IN DATA IN RUD ...... 35
I. CE: COUNTING EVENTS ...... 36
J. CJ: CEV AND JUA ...... 36
K. CM: COMMISSIONS REPORTED ...... 37
L. CN: PLAYERS’ DATA ARE CORRECT ...... 38
M. PC: REVIEW OF THE OTHERS HEADING IN CJ ...... 38
N. CR: CHECK ON THE GENERAL REGISTER OF GAMBLING ACCESS BANS AND ACTIVE PLAYERS ...... 38
O. CT: SPORTS COMPETITIONS ...... 38
Page 3 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
P. CU: BETTING ODDS ...... 38
Q. CV: DAILY CEV AND UPDATES ...... 39
R. D2: DAILY IN VERSION 2 ...... 39
S. DC: PLAYERS WITHOUT VALID DOCUMENTATION ...... 39
T. DD: DUPLICATE DEPOSITS AND/OR WITHDRAWALS ...... 40
U. DE: EVENT DESCRIPTION ...... 40
V. DN: PLAYER IDENTIFICATION ...... 40
W. DP: AZA SESSION, DURATION AND WAGER LIMITS ...... 40
X. EI: INCORRECT PLAYERS’ AGES ...... 41
Y. EM: EVENTS WITH UNDER AGE PLAYERS ...... 41
Z. F2: INVALID ACTIVATION DATE ...... 41
AA. FA: ACTIVATION DATE OF THE PLAYER ...... 41
BB. FB: JACKPOT DATES ...... 41
CC. FC: DATES IN THE CEV ...... 42
DD. FE: JU DATES ...... 42
EE. FF: END DATE IN THE JUD ...... 42
FF. FL: DECEASED GAMBLERS ...... 42
GG. FM: MOVEMENT DATE (DEPOSITS AND WITHDRAWALS) ...... 42
HH. GB: AZA GGR CALCULATION ...... 43
II. GG: GGR IN OPT ...... 43
JJ. GT: BETTING SLIP IDENTIFIER ...... 43
KK. H2: STATUS HISTORY CONTINUITY ...... 43
LL. HD: DUPLICATED STATUS HISTORY ...... 44
MM. HE: HECHO FIELD CONTAINING THE JUT OF THE BETS ...... 44
NN. HS: STATUS HISTORY ...... 44
OO. I2: DUPLICATED IP ...... 44
PP. IP: DEVICE IDENTIFICATION FIELDS ...... 45
QQ. IS: NON-ACCREDITED IDENTITIES ...... 45
RR. JC: CONSISTENCY BETWEEN JU AND CJ ...... 45
SS. JD: DUPLICATE JUEGOLD ...... 45
TT. JJ: INCORRECT FIELDS IN THE JUD FOR CASINO GAMES ...... 45
UU. JO: CONSISTENCY BETWEEN JU AND OPT ...... 45
VV. JU: DUPLICATE JU FILES ...... 45
Page 4 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
WW. LD: DEPOSIT LIMITS...... 46
XX. LI: INTERNATIONAL LIQUIDITY ...... 46
YY. LM: LIST OF PAYMENT METHODS ...... 46
ZZ. LR: REPORTED LICENSES ...... 48
AAA. LS: LIST OF SPORTS ...... 48
BBB. M2: BOT MOVEMENTS DOUBLE ENTRY ...... 51
CCC. MA: REASON FOR ADJUSTMENT IN THE JUA ...... 52
DDD. MB: JACKPOT MOVEMENTS ...... 52
EEE. MD: COMPARISON OF DAILY AND MONTHLY CJ MOVEMENTS ...... 53
FFF. MM: ADULTS AND MINORS PLAYING ...... 53
GGG. MN: MINORS PLAYING ...... 53
HHH. MP: PAYMENT METHOD DATA COMPARISON ...... 53
III. NA: NON-ACTIVE PLAYERS WHO PLAY ...... 53
JJJ. NC: ACTIVITY NUMBER OF THE RUT ...... 54
KKK. ND: LIVE BETTING ...... 54
LLL. NE: NUMBER OF EVENTS IN JUT ...... 55
MMM. NP: NON-RESIDENT PLAYERS WITH ESTADOCNJ=’PV’ ...... 56
NNN. NR: NON-RESIDENT PLAYERS ...... 56
OOO. NU: UNITS REPORTED IN CJ ...... 57
PPP. OO: OTHER FIELDS OF THE OPT ...... 57
QQQ. OV: OVERLAY IN POKER GAMES (POC AND POT) ...... 57
RRR. P2: PV BALANCES AND BONUSES IN BOT ...... 57
SSS. PA: AZA SESSION REPORTED IN OTHER GAMES ...... 57
TTT. PC: COMPETITION COUNTRY ON THE CEV ...... 58
UUU. PD: PLAYERS IN ESTADOCNJ=’PV’ WITH ACCUMULATED DEPOSITS OVER €150 ...... 58
VVV. PE: PRIZES IN KIND ...... 58
WWW. PN: PARTICIPATION OF GAMBLERS WITH NON-ACTIVE STATUS ...... 58
XXX. PP: PRIZES WITHOUT WAGERS IN JUD ...... 58
YYY. PV: UNFINISHED GAMES ...... 58
ZZZ. RE: RECTIFIED ...... 59
AAAA. RG: GAMBLERS ON THE GENERAL REGISTER OF GAMBLING ACCESS BANS WHO ARE ACTIVE BUT NOT PLAYING ...... 60
BBBB. RI: BANNED GAMBLERS (GENERAL REGISTER OF GAMBLING ACCESS BANS) PLAYING ...... 60
CCCC. RP: POSITIVE WITHDRAWALS ...... 60
Page 5 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
DDDD. RS: RESIDENT PLAYERS ...... 60
EEEE. RU: NUMBER OF RU PLAYERS ...... 61
FFFF. SC: CASINO GAMBLING SESSION ...... 61
GGGG. SF: CLOSING BALANCE ON THE CJDS ...... 61
HHHH. SH: BALANCES OF GAMBLING ACCOUNTS...... 61
IIII. SL: EXCEEDING SET DEPOSIT LIMITS ...... 62
JJJJ. SR: PLAYERS WITH A GAMBLING ACCOUNT WITHOUT A RECORD ...... 62
KKKK. SS: EXCEEDING SLOT SESSION LIMITS ...... 62
LLLL. SX: CJ MOVEMENTS WHICH ARE NOT SHOWN ON A JU ...... 62
MMMM. TA: DOUBLE BET TICKET ...... 62
NNNN. TC: CREDIT AND DEBIT CARDS ...... 62
OOOO. TE: TYPE OF EVENT ON THE CEV ...... 63
PPPP. TF: BET TICKET AND DATE ...... 63
QQQQ. TZ: DATES WITH TIME ZONE ...... 64
RRRR. V2: LIVE ROULETTE ...... 64
SSSS. VA: MARKET VERSION OF THE JUT ...... 64
TTTT. VI: IDENTITY VERIFICATION ...... 65
UUUU. VN: ASSOCIATED GAMBLERS PLAYING ...... 65
VVVV. VR: PLAYERS VERIFIED ON THE GENERAL REGISTER OF GAMBLING ACCESS BANS ...... 65
10. APPENDIX I. IMPORTANT NOTES. TIPS & TRICKS ...... 66
11. APPENDIX II. HOW TO REPORT BONUSES ...... 68
12. APPENDIX III HOW TO REPORT TEMPORARY DATA ...... 69
13. APPENDIX IV. NEW FIELDS FROM VERSION XSD 2.13 ONWARDS ...... 71
14. APPENDIX V. TEST PLAYERS, RECOMMENDATIONS FOR USE ...... 73
15. APPENDIX VI: CORRECT USE OF THE "ACTUALIZADO" FIELD OF THE CEV ...... 74
Page 6 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
4. Abbreviations used • A: Active, estadoCNJ. Status of a player that has been correctly identified and verified through documents. • AC: Contract cancellation, estadoCNJ. A player who, being SC, the operator considers that fraud, collusion or the making available to third parties of the account itself has been proven, and has proceeded to unilaterally terminate the contract. • ADC: Sport Fixed-Odds Betting. • ADM: Sports Pool Betting. • ADX: Sports Betting-Exchange. • AE: Self-excluded, estadoCNJ. A player who has voluntarily excluded themselves from the gambling offered by the operator. • AHC: Horse Fixed-Odds Betting • AHM: Horse Pool Betting. • AHX: Horse Betting-Exchanges. • AOC: Other Fixed-Odds Betting. • AOX: Other Betting-Exchange. • AP: Adjustments for Wagers. • AZA: Slot Machines. • BN: Vouchers. • BNG: Bingo. • BO: Jackpots. • BOT: Jackpot and unfinished games' account. • C: Cancelled, estadoCNJ. A player who, after four years of S status, the operator has decided to cancel it. • CEV: Catalogue of events. • CJ: The player's account, type of file. • CJD: Detailed Gambling Account. • CJDD: Daily Detailed Gambling Account. • CJDM: Monthly Detailed Gambling Account. • CJT: Gambling Account Totals. • CJTD: Daily Gambling Account Totals. • CJT: Monthly Gambling Account Totals. • CO: Fees. • COC: Contests. • COM: Additional Games. • DE: Deposits. • DGOJ: Directorate-General for the Regulation of Gambling. • DL: Driver License • EstadoCNJ: Current status of the player as of the moment of recording. • GGR: Gross Gambling Revenue of the Operator. • ID: ID Doc. • JU: Game record, file type. • JUA: Bet Adjustments. • JUD: Detailed gambling record. • JUT: Aggregate gambling record. • LGA: General Licence - Betting
Page 7 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• LGC: General Licence - Contests • LGO: General Licence - Other types of gambling • LI: International or shared liquidity • NR: Non-Resident. • O: Other, estadoCNJ. A player in the other situations that are not included in any of the above and who cannot perform any activity on the gambling platform. • OP: Operator account, file type. • OPT: The full operator account will be reported by operators that manage a gambling activity entirely or are operators assigned to a network (national or international). • ORT: the co-organised operator account will be reported by the operators that manage the gambling platform in a co-organised network, be it national or international. • OT: Others. • PA: Wagers. • PA: Passport. • PD: Wager Return. • PE: Prizes in Kind. • POC: Poker Cash. • POT: Poker Tournament. • PR: Prizes. • PR: Individual prohibition, estadoCNJ. Player subject to any of the individual prohibitions stipulated in article 6 of Gambling Act 13/2011 (minors, registered in the RGIAJ, connected parties, etc.) • PUN: Baccarat. • PV: Unfinished Games. • PV: Pending document verification, estadoCNJ. A gambler whose identity has not been verified reliably through a document verification system. • RE: Withdrawals. • RGIAJ: General Register of Gambling Access Bans • RLT: Roulette. • RU: User Registration, type of file. • RUD: Detailed User Record. • RUG: Record of User-Winners (for games without prior registration) • RUR: User Record of Network Operators. • RUT: Aggregate User Record. • S: Suspended, estadoCNJ. Player who, after two years of uninterrupted inactivity, the operator has decided to suspend. • SC: Precautionary suspension, estadoCNJ. A player who is suspected of collusive or fraudulent behaviour or of having allowed a third party to use their record. • ICS: Internal Control System of the operator where the warehouse in which they periodically deposit the files generated with the information from their gambling platform is stored. • SF: Closing Balance. • SGIJ: Subdirectorate General for Gambling Inspection • SI: Opening Balance. • SR: Suspended by responsible gambling, estadoCNJ. • SS: Social Security Number • SVI: Player Identity Verification System • TI: Trans_IN, transfer from other wallets.
Page 8 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• TO: Trans_Out, transfer to other wallets. • Trans_IN: Transfer from other wallets. • Trans_Out: Transfer to other wallets. • XSD: Data model to follow to generate the XML files • XML: Format of the files generated by the operator in their ICS and stored in the warehouse
Page 9 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
5. Introduction.
The validations and controls carried out by the SGIJ on the information reported by the operators are gradually increasing and constantly improving. Therefore, this guide will be updated with the new validations that are generated.
There are four types of validations depending on the purpose of the verification: • Format validations: affect the structure of the XML file. • Content validations: affect the reporting of data. • External validations: affect data crossing between several files. • Controls: more complex validations, which normally involve several files and/or periods and which look for errors in the understanding of the model and in the homogenisation of the information reported by the different operators.
Likewise, depending on the importance and criticality of the analysed data, the checks are classified into three levels: • High level: very serious errors that may prevent the processing of data. They must be corrected as soon as possible. Therefore, the maximum resolution date is one month from the operator is informed of the error.
• Medium level: serious errors, mainly in interpreting the model, which must be resolved as soon as possible.
• Low level: these are the errors with the lowest priority. In each case the correction deadlines will be evaluated.
6. Format validations
They are automatic validations made on the structure of the XML file a. High level a) General • The XML must be well formed and be in line with the structure defined in the XSD. In addition, all the batches that make up a record must belong to the same XSD version, and this version must exist in the system. The latest version of the data model is available for download at: http://www.ordenacionjuego.es/es/sistema-control-SCI “Appendix II of the Resolution of 6 October 2014.Version x.y of the XSD data model.”
• The "OperadorId" and "AlmacenId" fields of the Header of both the Batch and of the Record are mandatory and cannot have a null value. In addition, for each of them, it must have the same value in the header of the batch and in the header of the record. These fields must match the expected value according to the route from which it was obtained.
• The "OperadorId" field of the Batch and Record Header must be numerical and correspond to the operator that reports the information.
Page 10 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• The fields "RegistroId" and "LoteId" of the Record Header must be unique to each warehouse and operator.
• 'AAAAMMDDhhmmss' type date format will be used in the fields (see Appendix III): . "Desde" Field corresponding to the Player's Status History. . “FechaActivacion” Field . “FVSVDI” Field . “FVDocumental” Field . “FechaNacimiento” Field . “FechaInicio” Field . “FechaFin” Field . "Fecha" Field in the header.
• The subrecords within the same record are divided as follows: . They have to have a value in the "SubregistroTotal" field and in the "SubregistroId" field. . There cannot be duplicate subrecords. . All subrecords must have the same value in the "SubregistroTotal" field. . In each subrecord the value of the field "SubregistroTotal" must be greater than or equal to that of the "SubregistroId" field. . The number of subrecords must match the number indicated in the "SubregistroTotal" field.
• In the case of rectification, the "RegistroId" field belonging to the "Rectificacion" field of the cancellation or rectifying record header is mandatory and cannot have a null value. Said "RegistroId" must exist in the system and cannot refer to itself, otherwise it will refer to the original record that it rectifies or cancels.
b) RU • There must not be players with the same duplicate JugadorId.
Page 11 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• The "Periodicidad" field must contain the 'Mensual' or Diaria data.
• The "Sexo" field must have one of the following values: . ‘M’ Male. . ‘F’ Female.
• The fields "TipoDocumento" and "Documento" of the heading "NoResidente" are mandatory and cannot have a null value.
• All fields that refer to the number of players must have a positive numerical value.
• The field "NumeroActividad" must have a numerical value and a positive integer type.
• The fields of "LimitesDeposito" must have a real numerical value.
Page 12 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• The fields "JugadorId", "Login", "Nombre", "Apellido1", "Direccion", "Ciudad", "CP", "FechaNacimiento" and "FechaActivacion" are mandatory and cannot be null.
• The "Residente" label must contain the "DNI" or "NIE" label and must be filled out.
Page 13 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• One of the two complex fields must be selected: “Residente" or "NoResidente", and within these all mandatory fields. Information should never be sent in both fields.
• The fields "VSVDI" and "VDocumental" must have the values 'S' or 'N'.
• The “FVSVDI” and “FVDocumental” fields are obligatory in the event that the previous ones are ‘S’.
c) CJ • The field "Cuenta" is mandatory and cannot have a null value.
d) OP • The "SaldoInicial", "Movimientos" and "SaldoFinal" of Unfinished Games and Jackpot in the BOT file are mandatory. They cannot be null and must have a numeric value. .
Page 14 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
e) JU • The fields "JuegoId" and "JuegoDesc" are mandatory and cannot have a null value.
f) JUA • The fields "EventoId", "MotivoAjuste" and "TicketApuesta" are obligatory and cannot have a null value.
Page 15 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
g) How to correctly report a Registration
Below, an explanation is given as to how the information should be reported, taking into account that a record is a complete block of information corresponding to a period (day or month). A record is divided into subrecords, which are grouped into batches, a batch being the content of a file.
1.1.1.1 RUT, CJT, BOT, OPT and JUT • The field "Tipo" and "Subtipo" must have the following values depending on the file:
TYPE SUBTYPE
RU RUT
CJ CJT
OP BOT, OPT u ORT
JU JUT
• The maximum number of sub-records in a batch must be 1, and therefore, the value of this field and that of "SubregistroTotal" must be 1.
1.1.1.2 RUD, RUG, RUR, CJD
The maximum number of subrecords per batch is 10, with each subrecord consisting of 1,000 players. Only the last record or, in the case of having only one, may the number of subrecords per batch be less than 10.
The maximum number of players per subrecord is 1,000. There cannot be a subrecord with less than 1,000 players other than the last one or if there is only one subrecord.
TIPO SUBTIPO
RU RUD, RUG, RUR
CJ CJD
TIPO SUBTIPO
RU RUD, RUG, RUR
CJ CJD
Page 16 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
TYPE SUBTYPE
RU RUD, RUG, RUR
CJ CJD
1.1.1.3 JUD
The maximum number of subrecords per batch is 500. Each batch will be generated when 15 minutes pass or that number is reached, each subrecord consisting of 1,000 players.
The maximum number of players per subrecord is 1,000.
TYPE SUBTYPE
JU JUD
1.1.1.4 CEV
The maximum number of subrecords per batch is 10, with each subrecord consisting of 1,000 events. Only the last record or, in the case of having only one, may the number of subrecords per batch be less than 10.
Page 17 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
The maximum number of events per subrecord is 1,000. There cannot be a subrecord with less than 1,000 events other than the last one or if there is only one subrecord.
TYPE SUBTYPE
JU CEV
1.1.1.5 JUA
The maximum number of subrecords per batch is 10, with each subrecord consisting of 1,000 bet adjustments. Only the last record or, in the case of having only one, may the number of subrecords per batch be less than 10.
Page 18 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
The maximum number of bet adjustments per subrecord is 1,000. There cannot be a subrecord with less than 1,000 bet adjustments other than the last one or if there is only one subrecord.
TYPE SUBTYPE
JU JUA b. Medium Level a) General • The number of fields separated by "_" must be equal to 7 in RU, CJ, JU, CEV and JUA, and equal to 8 in BOT, OPT and ORT.
RU:
• The generation date of the file must be after the date of the data that is reported, that is to say, a file cannot be generated before the period of the data it contains.
Page 19 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
b) RU • The "NumeroActividad" must be less than the "NumeroJugadores” in the monthly RUT.
• The field "RegionFiscal" must have one of the values established by order HAP/2373/2014.
Page 20 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• The formats of the fields referring to "Pais" and "Nacionalidad" must correspond to the one established by ISO for countries and territories.
• The “Apellido2” field is obligatory in the event that the player provided a National ID Document as an identifier document. c) CJ • The field "Concepto" corresponding to the "Desglose" of "Otros" cannot have a null value.
Page 21 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• The "MedioPago" of deposits and withdrawals cannot have a null value.
• The "Cantidad" field must have a numeric and real value in all files.
• The field "Unidad" is mandatory and cannot have a null value in any file. To express the unit Euros, the literal "EUR" must always be used; for the rest of the units the operator is free to name them as they wish.
d) JU • When the "Total" of "Botes" is not zero, the "Desglose" field must exist. The fields "BoteId" and "BoteDesc" corresponding to it, must be filled in and cannot have a null value.
Page 22 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• The elements "JuegoEnRed", "JuegoAplazado", "JuegoSuspendido", "JuegoCancelado" must have any of the following values: . ‘S’ . ‘N’
• The "TicketApuesta" field cannot be assigned a null value, even if it has one.
• The fields "LayBack" and "Ticket" corresponding to the "Cruces" of "DesgloseCruzadas" cannot have a null value.
c. Low level a) General • The file must be decompressed with the correct password. The password must be the last one and it will allow the decompression of the file (it can be an old one as long as it allows the file to be opened). b) RU • The email format must correspond to a valid email format. c) OPT • There is only an obligation to give a breakdown by "OperadorId" when it is a network game.
Page 23 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
Example for Wagers d) JU • The field "Descripcion" of "DesgloseEspecie" is mandatory and cannot have a null value. The field "Valoracion" of "DesgloseEspecie" is mandatory and must have a positive value.
• The "Reto" field corresponding to "DesgloseCruzadas" must be assigned some of the valid values for that field, if any.
7. Content validations
They are automatic validations that affect the reported data.
Page 24 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
a. High level a) General • The “Cantidad” field of the variables: SI, SF, DE, RE, PA, PD, PR, OT, PE, AP, CO, T_IN, T_OUT and BO must have a numerical value and not be zero.
Positive Sign Negative Sign Both
SaldoInicial Participacion Retiradas
Depositos Comision Bonos
ParticipacionDevolucion Trans_OUT AjustePremios
Premios
Trans_IN
SaldoFinal
• The type of gambling must have a valid value: AHC, AHM, ADC, ADM, AOC, POT, POC, BLJ, PUN, BNG, RLT, COC, COM, ADX, AOX, AHX and AZA. b. Medium level a) General • Prizes in kind must have the unit 'EUR'. b) RU • The “FechaActivacion” field must contain a valid date that must match the player's first active status date. It is not valid to fill it in with zeros.
• The number of registrations must be less than or equal to the number of players.
Page 25 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
c) CJ • The total of RE, DE, PA, PD, PR, OT, PE, AP, Trans_IN, Trans_OUT, CO and BO must coincide with the sum of their breakdowns and, in addition, such breakdowns must exist when the total is not zero.
BREAKDOWN
2nd 1st Amount 3rd Amount SUM Amount
7 2 361.20 370.20
• The "SaldoFinal" of "Cuentas" must be equal to the "SaldoFinal".
Page 26 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
CJD FILE
d) OP • The "SaldoInicial" of "Botes" plus its "Movimientos" must be equal to its "SaldoFinal".
SI_BO + Movimientos_BO = SF_BO
Page 27 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• Within the heading “DesgloseBotes” under “Botes”, the “SaldoInicial” plus the “Movimientos” must be the same as the “SaldoFinal”.
SI_desBO + Movimientos_desBO = SF_desBO
The sum of the closing balances of all the "DesgloseCompromiso" must match the "SaldoFinal" of "PartidasVivas". This must also be the case with "SaldoInicial" and "Movimientos".
Page 28 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
BOT FILE
• The sum of the closing balances of all the “DesgloseBotes” must match the closing balance of the jackpots.
BOT FILE
Page 29 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
c. Low level a) RU • The fields "CP", "VSVDI" and "VDocumental" must contain a valid value.
o VSVDI: in the case of resident players it will have one of the following values: . ‘S’ Yes . ‘N’ No
o VDocumental: it will have one of the following values: . ‘S’ Yes . ‘N’ No
• The "RegionFiscal" field must be consistent with the "CP" field. The "CP" must be a five-digit number with a correct value.
8. External validations
They are automatic validations that normally affect data crossing between several files. a. High level a) CJ • • The SI on the monthly CJT file for one month must be the same as the SF on the CJT for the previous month. • The SI on the monthly CJT file must be the same as the total SI of all players on the CJD file for the same month. • The SF on the monthly CJT file must be the same as the total SF of all players on the CJD file for the same month. • These validations are high level for EUR unit; for the other units it is medium level. b. Medium level a) RU • The number of registrations of a monthly RUT file must coincide with the sum of the number of registrations of the daily RUT files of each day of that month.
Nº altas RUTM = ∑ Nº altas RUTD
Page 30 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• The number of players in a monthly RUT file must match the number of players reported in the monthly RUD corresponding to the same month.
No. of players RUTM = No. of players RUTD
• The number of registrations in a monthly RUT file must match the number of players reported in the monthly RUD with the data change value equal to 'A’ corresponding to the same month.
Nº altas RUTM = ∑Nº jugadores con SN_CAMBIOS =’A’ RUDM
• The number of players in a monthly RUT file must match the sum of the number of file registrations and the number of players in the previous monthly RUT, minus the number of file de-registrations.
No. of registrations (month of study) + No. of players (month of study - 1) – No. of de- registrations (month of study)
b) RUD versus JUD • All the players that are reported in the JUD files (JugadorId) must be in the RUDM of the month in which they are reported. c) BOT • The "SaldoInicial" of "Botes" of a monthly BOT file must match the "SaldoFinal" of "Botes" of the same file for the previous month.
• The "SaldoInicial" of unfinished games of a monthly BOT file must match the "SaldoFinal" of unfinished games of the same file for the previous month.
Page 31 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
d) OPT versus BOT • The "Movimientos" of "Botes" of the monthly BOT files must coincide with the "Total" of "Botes" of the OPT file of that month.
• In a network, the "Movimientos" of "Botes" of the monthly BOT files must coincide with the "Total" of "Botes" of the ORT file of that month. Both files reported by the B2B. e) OPT versus CJT versus JUT • The total wagers, wager return, prizes and prizes in kind of OPT and/or ORT must match those of CJT and JUT for the same type of gambling. f) BOT versus JUT • Each of the jackpots reported in the monthly BOT must match one of the JUT of the month. g) JU versus JUA versus CEV • The events reported in JU must match the CEV. • All bet adjustments reported in JUA must appear in the JU. h) ORT versus OPT • In a game network, the wagers, wager return, prizes, prizes in kind, jackpots, network adjustment, commission and others of the ORT reported by the B2B must coincide with those of the OPT reported by the B2C.
Page 32 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
i) JUD versus RUG • In a Contest operator the players reported in JUD-COC must match those in RUG.
9. Controls
Are more complex validations, which normally involve several files and/or periods and which look for errors in the understanding of the model and in the homogenisation of the information reported by the different operators.
There are three types of control, depending on the seriousness of the error:
• Monitoring controls: consist of reviewing the data to verify compliance with the requirements provided for in law 13/2011 and its implementing regulation.
The following controls belong to this group: AL, C2, CN, EM, FL, IS, MN, NP, PN, RI, SL, SS and VN. The following controls may also be treated as monitoring controls, where reiteration occurs or they are not solved on time: Ausencias, CR, DN, HS, NA, NP, NR, PD, RG, RS, SH and SR.
In cases where there are sufficient indications of infringement, communications will be sent directly to the operator's representative for the purpose of notices, and, as appropriate, initiation of the relevant penalty procedures will be proposed.
• Query, request or suggestion: review of the data raises doubts about its interpretation, for which reason a query or suggestion for change notice is sent to the operator. The operator is advised to respond to queries within a reasonable period of time. These queries may become quality errors, depending on the response provided.
The following controls belong to this group: AE, BC, DD, DE, EI, LI, MA, MP, OO, PC, PE, PP, RP, SC, TC and VR.
• Quality error: normally these are medium level reporting errors that should be corrected within a maximum of 3 or 6 months, depending on the case. Non-resolution of these controls on time may be considered to be a breach of the technical requirements.
The remaining controls belong to this group. a. Absences
The operator must report all the files corresponding to the licenses granted and active. These files must be complete, encrypted with the code provided by the DJOG, in the correct XML format and will be sent at the time indicated for each of them, the daily files being
Page 33 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
before 4 a.m. the next day, and the monthly ones during the 24 hours after the end of the month.
A file is considered to be absent where, due to its low or non-existent quality, it does not contain valid information for processing, for example, if, instead of sending the information it arrives empty or with clearly incorrect values. b. AC: Bets badly reported on the CJ
The information on the CJ files must be reported when the event occurs, unlike JU files where, for example, the bet is reported once the game is over.
This means that the player’s participation in any game on the platform must be reported on the day and month when this occurred on the daily and monthly CJD and CJT files. It is considered to be an error to wait to report such participation when the game is over, or it is detected in bets which are over in later days or months, or in poker tournaments which last several days. c. AE: Status updates with AE
The status CNJ=AE, or Self-Excluded, has been included since version 2.13 of the data model. In order to carry out more comprehensive monitoring of the self-exclusion requirements within the framework of monitoring responsible gambling, it is important to know the periods of time the players have been in self-exclusion status.
Operators are requested, in as far as possible, to report players’ self-exclusion periods from the start of their activity in the HistoricoEstados field. d. AL: Extension of deposit limits without respecting the established timelines
This control checks that, in all cases of increases to limits exceeding those provided for in the royal decree, more than three months have passed since the previous increase to limits.1
1Article 39 of Royal Decree 1614, of 14 November, which develops Law 13/2011, of 27 May, on gambling regulation in relation to licences, authorisations and gambling registers.
Page 34 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
e. BC: Heading of Bonuses in CJ file
The different headings of bonuses reported by the operator in the CJD and CJT Bonuses field are reviewed. Although in the data model the CONCEPTO field is open to any text string, operators are asked to stick to three single headings:
• GRANTING: To report the granting of a bonus to the player's account • CANCELLATION: For cancellations of bonuses that have occurred when the player does not meet the conditions for their use or conversion to euros • RELEASE: To report the conversions to euros that have occurred when the player meets the bonus conditions
Any other Concepto will be considered an error and, therefore, the operator will be asked to modify the report of the CJ files so that they fulfil these terms.
There is more comprehensive information about how to report bonuses in Appendix II to this document. f. C2: Duplicate player accounts
According to Royal Decree 1613-2011, of 14 November, article 26.2 states: "The operator shall establish the procedures and mechanisms necessary for ensuring that a player does not have various active user registrations."
This control checks that the operator does no effectively permit any of the players registered on their platform to have two or more active user registrations at the same time. g. CA: ADC quality • It is not possible to report "AjustesRed" when the game is not a network game. • The unit for the amounts in euros is 'EUR'. • The "NumeroApostantes" of the JUT must be consistent with the number of players reported in JUD.
• The "JuegoId" field in JUD must be the same as that of the JUT in the same bet. h. CD: change in data in RUD
The "CambiosEnDatos" field must have one of the following values: • ‘A’: Registration. • ‘N’: No changes made. • ‘S’: Changes made
In the daily RU you only have to report the players that have had changes in their user registration during the period and the registrations. Therefore, in the daily files there can only be "CambiosEnDatos = A" and "CambiosEnDatos = S".
Page 35 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
In the monthly RU, however, all players in the period must appear.
Therefore, when there is a change in the player's details, it must be reflected both in the daily and in the monthly ones, "CambiosEnDatos = S", even if the player has not had movements in their CJ.
i. CE: Counting events
The “NumeroEventos” field on the RegistroApuestas files must be the same as the number of the various “Eventold” reported in the Eventos multiple field.
j. CJ: CEV and JUA • The "EventoId" cannot be duplicated. As an exception to this rule, you can repeat the "EventoId" in the event of updating, but you must always have a field modified with respect to the CEV file of the previous period.
Page 36 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• Each combination of the fields that define an event (excluding the event code itself) in a CEV must be unique. These fields are: “DescripcionEvento”, “FechaInicio”, “FechaFin”, “TipoEvento”, “Deporte”, “OtroDeporteEspecificar” and “Competicion”.
• The "Competicion" field, if the label exists, is mandatory and cannot have a null value.
• The fields "EventoId" and "DescripcionEvento" are mandatory and cannot have a null value.
• All bet adjustments reported in JUA must have been previously reported in a JUD.
• All events that appear in the JUT of the month must be reported in the CEV of that month or earlier. k. CM: Commissions reported
Commissions reported are reviewed on the CJ and OP files.
Page 37 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
It is checked that commission on games is reported on the CJ files: POC and POT, BNG, ADM, AHM, ADX and PUN, which are the games where the operator can gain a margin from the commission received from the player.
Commission for the remaining games should not be reported on CJ or OPT.
The commissions reported in the “Comision” field on the monthly CJT must match those reported on each one of the OPT for each game. l. CN: Players’ data are correct
Information about the players who have been verified with documentary evidence from information on the National Police National ID Document database is compared and, in the event of discrepancy, a request is sent to the operator to confirm the data reported. m. PC: Review of the others heading in CJ
The field "Otros" cannot contain 'bonuses'; they must go in the field "Bonos". Neither can have cancellation of deposits or withdrawals; these must appear in their respective fields with the opposite sign to the usual one. n. CR: Check on the General register of gambling access bans and Active players
A search is made for resident players (with National ID Document or NIE) who have NOT been checked on the general register of gambling access bans, who have active status (A or PV) and have Deposits or Stakes on their gambling account. o. CT: sports competitions
The "Competicion" field of the CEV file can only contain information related to the competition and not to the event.
The "Competicion" field is only optional in the case of events that do not belong to a competition. In events that belong to a competition it must always be filled in. p. CU: Betting odds
From version 2.13 onwards, a new “Cuota” field is defined on the RegistroJUD files.
This field is expected to receive the value of the bet’s odds at the time it is accepted by the gambler
The “Cuota” field should be reported for all betting games and should not be reported for non-betting games.
The “Cuota” value should be coherent with the other data reported (tipoApuesta, Participacion, Premios).
Page 38 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
q. CV: Daily CEV and updates
From version 2.12 onwards, apart from monthly, it is obligatory to report the CEV file on a daily basis. The “Actualizado” field is also added. This applies to operators offering LGA games.
A check is made that CEV files are being reported daily and that the information on them is contained in the monthly CEV for the relevant month.
The “Actualizado” Boolean field should be filled in with ‘S’ when the information is for a previously reported event for which the values are being changed. When the event is new, and has not previously been reported, it will be filled in with ‘N’.
On the monthly files, the “Actualizado” field will contain ‘N’ where the event is new during the month, and ‘S’ where it has been changed during the month. If both have occurred, ‘S’ will be reported as it is the most recent position.
r. D2: Daily in version 2
In the daily files, from version 2.0 of the data model, only the information corresponding to that day must be sent, and not the information corresponding to that accumulated monthly until that time. This applies to both the CJ files and the RU files.
In the daily RU you only have to report players who have had changes in their user registration that day.
In daily CJ only players who have had movements that day must be reported, regardless of whether or not the player has a positive Balance in their account.
The RUT data must be the same as the RUD data.
The CJT data must be the same as the CJD data. s. DC: Players without valid documentation
A search is made for players fulfilling the following requirements:
- Non-test players, - who have estadoCNJ=A or PV - who are active, that is to say, with some movement in Stakes, Deposits or Withdrawals (in the Unidad=EUR) and - whose identification document is empty or clearly invalid (for example, ‘-‘, ‘NULL’, ‘N/A’, etc.)
Page 39 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
t. DD: Duplicate Deposits and/or Withdrawals
A check is made that, when reporting movements of deposits and withdrawals on the CJ files, they are not duplicated.
We have detected various possible errors:
• RE same amount in positive and negative at the same time • RE duplicated in positive or DE duplicated in negative (REs are reported with a minus sign and DEs with a plus sign unless they are cancellations) • Duplicates with different amounts at the same time
u. DE: Event description
In the “DescripcionEvento” field on the CEV file the information should follow the following pattern: “Equipo Local ‘separator’ Equipo Visitante” in the case of events where there are two teams, in any other case (tournaments, competitions and races, etc) the event will be specified.
In any case, if the “DescripcionEvento” field includes dates and/or markets this is considered to be any error. v. DN: Player identification
The "NIE" and "DNI" fields must be selected correctly.
All players with an active "EstadoCNJ" must have completed the fields "Nombre" and “Apellido1".
Resident players with a DNI and an active "EstadoCNJ" must have completed the field "Apellido2". w. DP: AZA session, duration and wager limits
The "ParticipacionLimite" and the "DuracionLimite" cannot be left empty. In addition, the value of the "ParticipacionLimite" cannot exceed the balance that the player has.
The "ParticipacionLimite" and the "DuracionLimite" must not be zero. The "DuracionLimite" field is of the "hhmmss" type and the "ParticipacionLimite" field must have a numeric value.
The "PlanificacionAzar" field should only exist in the AZA files and in no other.
Page 40 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
x. EI: Incorrect players’ ages
It is checked whether the players’ dates of birth reported on the RUD files are correct according to the information on the Police databases. y. EM: Events with under age players
A check is made on the catalogue of events marketed by the operator to see if bets are being offered on events involving minors.
The first article of the Resolution of 11 July 2019, banning offering betting on events in which participants are exclusively or mainly minors, from the Directorate General for the Regulation of Gambling, provides that “Gaming operators with a specific licence in any of the regulated betting may not offer events which exclusively or mainly involve minors in their events programme”. z. F2: Invalid activation date
The “FechaActivacion” field on the RUD and RUR files for active gamblers must have a correct value, it may not be a date prior to 2011 or later than the file report date. A check is also made that such date is not more than a few days from the first date that the gambler's status was active. aa. FA: Activation date of the player
The “FechaActivacion” field on the RUD and RUR files for active gamblers (estadoCNJ=’A’ or ‘PV’) must be filled in, it may not be empty or filled up with zeros. bb. FB: Jackpot dates
The date fields are found in the “DesgloseBotes” complex field on the BOT files: FechaInicio and FechaFin checking: • FechaInicio is obligatory and in the event of there being DesgloseBotes must be filled in. • FechaFin will be filled in where the jackpot has been handed over. • FechaInicio must be prior to FechaFin and both must be in current times. Neither of the two dates may be in the future.
Page 41 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
cc. FC: Dates in the CEV
The Start and End dates in the Events Catalogue must be the correct ones and must match those that correspond to the event. If the operator does not know the specific dates, they must report the approximate value. Event completion dates which are earlier or the same as the start date of the event are considered to be errors. Likewise, event end dates that are empty or have inconsistent data are considered errors.
dd. FE: JU dates
The "FechaInicio" of the game must be before the "FechaFin"; in this check the hours of both fields will also be taken into account. The end date must be in a "logical" period after the start (normally the same day). ee. FF: End date in the JUD
From v2.13 of the data model onwards, the “FechaFin” field is included on the JUD file. This field is obligatory and must contain the same information as that on the JUT file for the same Juegold. This enables unequivocal unification of the information about the same game on the JUD and JUT files. ff. FL: Deceased gamblers
A check is made on whether there are registered gamblers who have died, according to the information on the deaths section at the Civil Registry, and who have had movements on their account after the date of decease. gg. FM: Movement date (Deposits and Withdrawals)
The deposit (DE) or withdrawal (RE) movement date should match the month reporting them, or the previous month. There should not be any dates for deposits or withdrawals
Page 42 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
after the reported date, or older, as movements must be reported when they are carried out. hh. GB: AZA GGR calculation
Enquiry made to the operators who have a licence for slot machines (AZA) about how they calculate the GGR, if they take into account Jackpots when making the calculation, or not. ii. GG: GGR in OPT
The "GGR" field must have negative numbers and no null values, and the unit must be 'EUR'. If, exceptionally, the reported game has recorded a higher value between prizes and returns than in wagers the GGR will be positive in that month.
The monthly GGR can be approximated by applying the following formula, except for network games in which the GGR will be the same as the fee.
PA + PD + PR + Otros (APA) + Otros (BON) ≈ GGR jj. GT: Betting slip identifier
The TicketApuesta reported on the JUD files is checked as to whether it matches the identifier that the operator gives the gambler when making the bet. kk. H2: Status history continuity
The status history data reported on the RUD for the month are verified to ensure they are consistent with those reported for the previous month for the same gambler. Status histories cannot be deleted, the status sequence must be retained.
Page 43 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
ll. HD: Duplicated status history
The list of status passed through by the gambler is verified in case there are duplicated status. This may occur due to consecutive reporting of the same pair: EstadoCNJ and EstadoOperador, which implies that there has been no change and, therefore, one of the two would be superfluous, and an error is also detected when the date of the status is exactly the same as that of another status reported in the history. At the same time there cannot be two different statuses; there must be at least a second difference between them. mm. HE: Hecho Field containing the JUT of the bets
The field Hecho containing the JUT of the betting games must be filled in; it cannot be empty, it must be clear, correspond to the type of sport and event that is being bet on and must contain the bet, both the name of the market and the exact result selected by the player.
For example, for a Football Event (Juventus vs. Bayern), if the Mercado is: 'Siguiente gol' and the player bets that Bayern is going to get it, 'Hecho' = 'Siguiente gol: Bayern’ would be reported nn. HS: Status history
The "EstadoCNJ" must take some of the possible values within the value domain:
o ‘A’: Active o ‘AC’: Contract cancellation o ‘AE’: Self-excluded o ‘C’: Cancelled o ‘O’: Other o ‘PR’: Individual prohibition o ‘PV’: Pending verification o ‘S’: Suspended o ‘SC’: Precautionary suspension
The "EstadoOperador" field corresponding to the "Estado" and the status "Historico" is mandatory and cannot be null.
All present and past statuses of the player must be reflected in their status "Historico” ("Historico" field).
The current status of the player must correspond to their last status history.
There must be consistency between the "EstadoCNJ" and the "EstadoOperador". oo. I2: Duplicated IP
A check is made that a high number of duplicate IPs are not being reported. Numerous gamblers (the number is adjusted depending on the number of errors detected) making their deposits or withdrawals or gambling from the same IP is considered to be an error.
Page 44 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
pp. IP: Device identification fields
From version v2.12 of the data model onwards, the IP, Dispositivo and IdDispositvo fields are included to complete the information about the device from which the gambler makes the connection when requesting deposit or withdrawal, or confirming participation in the game.
The following checks are made:
- The fields are filled in - The IP field has the correct format for Ipv4 or IPv6 - The Dispositivo field contains one of the valid values: PC, MO, TB, TF or OT - The IdDispositivo field contains valid information (see Appendix IV) qq. IS: Non-accredited identities
A check is made that there are no active gamblers with stakes whose identity has not previously been verified using the SVDI and/or by Document verification.
Any gambler reported on the RUD as active and having stakes is considered to be an error if the SVDI and VDocumental field are both at ‘N’. rr. JC: consistency between JU and CJ
The data reported in JUT/JUD/CJT must be the same, or very similar. In betting files, there may be differences in PA and PD between the JU and CJT files, but not in PR and never between JUT and JUD. ss. JD: Duplicate Juegold
The JUT and JUD are checked to ensure there are no duplicate game identifiers (Juegold), as they must be unique. tt. JJ: Incorrect fields in the JUD for casino games
A check is made that the optional fields that only apply to the specific betting licences games are not reported on the JUD. FechaApuesta, TicketApuesta, etc. uu. JO: consistency between JU and OPT
In the same way as the JC control checks the data between JU and CJ, this control compares the data between JU and OPT and between OPT and CJ. The stake values (PA), wager return (PD) and prize (PR) values are compared for all the EUR units and remaining units. vv. JU: duplicate JU files
There cannot be duplicate "JuegoId" or "RegistroId", either in JUT or JUD files. If you need to correct data, you must send a corrected file.
Page 45 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
ww. LD: Deposit limits
In general, most players will have the "LimitesDeposito" set in their values by default2: - "Diario" limit: 600 - "Semanal" limit: 1,500 - "Mensual" limit: 3,000
Any change that occurs in the "LimitesDeposito" must appear both in the monthly files and daily files. xx. LI: International liquidity
Since 2018, operators may offer their poker cash games and tournaments on international tables managed by a mutual gambling platform where liquidity is shares amongst authorised operators in Spain, France and Portugal.
This control checks that the information reported by the gambling operators offering games with international liquidity is correct and complete. In particular checks are made that the Commissions and Adjustments from the network are reported and are the same, the the GGR reported on the OPT is correct, that the information reported in the quarterly reports matches that reported in the OPT/ORT on the SCI and that the information between the OPT and ORT is consistent. yy. LM: List of payment methods
The field "TipoMedioPago" must be completed taking into account the standard list of methods of payment published on the DGOJ website:
(http://www.ordenacionjuego.es/es/sistema-control-SCI)
2See note 1
Page 46 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
If the method of payment does not appear in the above list, a request must be made through the electronic office and, during the period of inclusion in that list, it must be reported with the code '99' and the field "OtroTipoEspecificar" must be filled in.
Page 47 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
In the event of cancellation of the deposit (DE) or withdrawal (RE), the “TipoMedioPago” should coincide that the one the cancelled deposit or withdrawal was made with.
zz. LR: Reported licenses
Information on all current and active licenses must be reported. The operator must have a license for the games in the period during which they are commercialised. If you have a game license but it is not offered, you must report a zero value for the OPT or break it down in the CJTM of the game to zero for PA and PR. aaa. LS: List of sports
The field "Deporte" must be completed taking into account the standard list of sports published on the DGOJ website:
(http://www.ordenacionjuego.es/es/sistema-control-SCI)
When the sport is '999' the label "OtroDeporteEspecificar" is mandatory.
Codigo Deporte Observaciones 1 Atletismo Athletics 2 Automovilismo Formula 1, Rally, Deportes de motor, Karting
Page 48 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
3 Bádminton 4 Baloncesto Basketball 5 Balonmano Handball 6 Béisbol Baisball, Baseball 7 Biatlón, triatlón, otros Triathlon 8 Billar 9 Boxeo Boxing 10 Ciclismo Cycling 11 Ciclocross Cyclo-cross o bicicros 12 Criquet Cricket 13 Dardos Darts Patinaje, Esquí, Descenso en trineo, Snowboard, salto de 14 Deportes de invierno esquí, Esquí de fondo o travesía 15 Hípica Utilizar para apuestas de las licencias AHC y AHM 16 Esgrima 17 Fútbol Football, soccer 18 Fútbol americano 19 Futbol australiano 20 Fútbol sala Futsal 21 Gimnasia Rítmica y Artística 22 Golf 23 Halterofilia 24 Hockey sobre hielo Ice Hockey 25 Hockey sobre hierba Field Hockey, indoor hockey 26 Hockey sobre patines 27 Judo 28 Lucha libre 29 Motociclismo Motorcycling, Speedway 30 Natación 31 Pádel 32 Patinaje Cesta punta, Pala, Remonte, pelota mano, frontenis, 33 Pelota vasca sare 34 Remo 35 Rugby 36 Snooker Snooker & pool 37 Squash 38 Taekwondo 39 Tenis Tennis 40 Tenis de mesa Table Tennis 41 Tiro con arco
Page 49 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
42 Tiro deportivo Shooting 43 Vela Yachting 44 Voleibol Volleyball, Volley 45 Vóley playa Beach Volley 46 Waterpolo 47 Ajedrez 48 Apnea Buceo libre, buceo, freediving, diving 49 Balón puño Fistball 50 Balonmano playa 51 Bowls Bowls, Bowls sobre hierba, Bolos cesped, Indoors Bowls 52 Bowling Bolo americano o boliche 53 Curling 54 Deportes de combate 55 Deportes Gaélicos 56 Deportes Vascos Herri Kirolak 57 Floorball Unihockey, Street hockey, Ball Hockey, Floor Hockey Showbol, Futbito, Fútbol 5 o Fútbol rápido, Minifootball, 58 Fútbol indoor Indoor soccer 59 Fútbol playa Beachsoccer 60 Lacrosse 61 Netball 62 Petanca 63 Piragüismo Incluye Kayak y Canoa 64 Schwingen 65 Softball 66 Surf 67 Bandy Hockey hielo con pelota UFC/MMA, UFC Internacionalm Artes Marciales Mixtas, 68 MMA-Mixed Martial Art Boxeo tailandés o MuaiThai, Prodal, Tomoi, Lethwei, Muay Lao, Muay Boran, Kick boxing 69 Indoor Bowling Indoor Bowls, Bolos indoor 70 Pesapallo Béisbol finlandés 71 Wrestling WWE 72 Sumo 73 Sepak takraw 74 Polo Show jumping, stadium jumping, open jumping, 75 Salto Ecuestre Spanish equestriam fixtures 76 Hurling 77 Pesca deportiva Fishing, Angling 78 Kabbadi Kabbadi indoor, Circle Kabbadi, Beach Kabbadi
Page 50 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
Olimpiadas de invierno, olimpiadas de verano, juegos 79 Evento multideportivo Mediterraneos, juegos asiáticos 80 Baloncesto 3x3 Basketball 3x3 81 No Disponible código reservado para futuros deportes 82 No Disponible código reservado para futuros deportes 83 No Disponible código reservado para futuros deportes 84 No Disponible código reservado para futuros deportes 85 No Disponible código reservado para futuros deportes 86 No Disponible código reservado para futuros deportes 87 No Disponible código reservado para futuros deportes 88 No Disponible código reservado para futuros deportes 901 e-Sport Pertenece a la licencia de AOC 902 Galgos Pertenece a la licencia de AOC 903 No Disponible Reservado para futuros códigos AOC 904 No Disponible Reservado para futuros códigos AOC 905 No Disponible Reservado para futuros códigos AOC 998 Otras Apuestas Utilizar para apuestas de las licencias AOC y AOX 999 (OtroDeporteEspecificar)
The field "TipoEvento" must be consistent with the value of the field "Deporte", that is, for the sports that appear in the previous list there must appear in the field "TipoEvento" a 'D' corresponding to sporting events, an 'H' in horse-racing events and an 'O' for other types of events.
The codes of the previous list will be for sporting events with the exception of the code '15' which is for horse betting and 901 to '998' which will be used for other types of betting. bbb. M2: BOT movements double entry
On BOT-type files, both in the PartidasVivas section and that for Botes, the Movimentos field must have a double entry - a positive one for the increases in PartidasVivas and Botes during the month, and a negative one for PartidasVivas closed in the month or the Jackpots handed
Page 51 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
over in the period. If no movement occurred in any of the two directions, it is correct to send a zero to this record.
ccc. MA: Reason for Adjustment in the JUA
The reason for adjusting the JUA must be filled in and be sufficiently clear. Texts of the type: ‘Ajuste’, 'Adjustment', 'Settlement', 'Unsettlement' or similar are considered unclear and, therefore, the operator will be asked to complete them. ddd. MB: Jackpot movements
The information for bingo, slot machines and pool betting jackpots must reported as follows:
The BOT file must have two lines in the "Movimientos" section, one with a positive sign, corresponding to the sum of the contributions during the period and another with a negative sign, corresponding to the sum of the prizes awarded or the sum total redirected to another jackpot:
Page 52 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
In the "Botes" section in the OPT file, there must be a breakdown with two lines, one positive and one negative:
eee. MD: Comparison of daily and monthly CJ movements
The comparison between monthly and daily CJ files (CJDM vs. CJDD and CJTM vs. CJTD) and between daily CJ files (CJDD vs. CJTD) verifies that the amounts on all the files coincide for the various items (DE, RE, PA, PD, PR, PE, OT, AP, Trans_IN, trans_Out, CO and BO), both in Euros and the remaining units. fff. MM: Adults and minors playing
This control checks that in the user records (RUD, RUR and RUG) there are no active players under 18 years old, who are forbidden from playing.
It is also checked whether there are active players over 100 years old. These players have no limitations on playing, but they can be an indicator of errors in the documentary checks and identity theft. ggg. MN: Minors playing
Possible cases of access by minors to the games offered by the operator are checked. hhh. MP: Payment method data comparison
This control consists of comparing the data on payment methods used by gamblers to make deposits and withdrawals reported by the operators on their SCI with data obtained from the national payment methods management platform. iii. NA: Non-active players who play
This control checks that no player with a status other than active (A) or pending verification (PV) carries out movements on their gambling account.
Page 53 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
Nevertheless, there are certain cases where certain transactions are allows on non-active players’ gambling accounts. • The opening balance (SI) and closing balance (SF) may be different from zero. • Gamblers with blocked accounts, whether resident or not, may make withdrawals (RE) of the total account balance, or part of it. • Non-active players may receive income for prizes (PR) from bets made previously, when the player was active. • There may be bonus activity whenever it is a promotion; in this situation the Non- Active player cannot make any movements unless their status passes to Active beforehand. • Non-resident players (NR) with a status other than Active may not make deposits (DE), stakes (PA) or withdrawals (RE) until their identify is verified with documentary proof. jjj. NC: Activity number of the RUT
The “NumeroActividad” in a monthly RUT file must match the number of players with movements greater than or equal to €1 reported in the CJD corresponding to the same month.
kkk. ND: live betting
In the JUT betting file, live betting must be reported in the field "EnDirecto = S".
The operators that offer this type of betting cannot have this field always the same as 'N'.
Page 54 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
lll. NE: Number of events in JUT
The "TipoApuesta" field has to be consistent with the "NumeroEventos" field, the latter being the number of different events. Therefore:
• Bet type ‘S’ Different events = 1 Different events = 1.
• Bet type ‘M’ Different events = 1 Different events > 1.
• Bet type ‘C’ Different events > 1 Different events > 1.
Page 55 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
mmm. NP: Non-Resident Players with estadoCNJ=’PV’
After 1 April 2019, there should not be any Non-Resident players whose identity has not been verified using the SVDI service. Therefore:
- Non-Resident players who have a National ID Document or NIE can be verified using the SVDI which means they can appear on the RUD as Non-Resident players with estadoCNJ=’PV’. - Non-resident players providing a different identity document (passport, driving licence, or others) may only be in active estadoCNJ if they have already been verified by documents or otherwise they will be in a non-active estadoCNJ. nnn. NR: Non-resident players
When the players are not residents they have to fulfil a series of premises: • The field "TipoDocumento" must be 'ID', 'SS', 'PA', 'DL' or 'OT'.
• The operator must validate the documentary information of that player within one month after its review and, if it is positive, "VDocumental = S" must appear.
• In cases where the type of document 'OT' is used, it is necessary to specify what kind of document it is in the field "EspecificarTipoDocumento".
• Those players who have a DNI or NIE and their country of residence is Spain must appear as residents and never as non-residents.
• Players who, being non-residents, have a DNI or NIE, must put in the field "TipoDocumento = ID".
Page 56 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• Any of the following situations will also be considered to be an error:
o Non-Resident Players who have EstadoCNJ=’A’ and VDocumental=’N’.
o Non-Resident Players with Nacionalidad=’ES’ and an address in Spain
ooo. NU: Units reported in CJ
The number of different units used on the CJ includes the Euro unit and the units used for bonuses and other promotions. The number of different units may be one, relating to the Euro unit, solely in the case of operators who do not give bonuses. In any other case, not reporting the other bonus or promotion units will be considered to be an error. ppp. OO: Other fields of the OPT
In the OPT files, in the Otros field, only the following items should be reported:
- APA (Stake adjustments), - APR (Prize adjustments), - BON (Bonuses), - ADD (Added in Poker games), - OVL (Overlay), - OTR (Other).
Any other item used is considered an error and its correction will be requested. qqq. OV: Overlay in Poker games (POC and POT)
Overlay should be reported with the label OVL in the Others field on the OPT and ORT for poker games (POC and POT). rrr. P2: PV balances and Bonuses in BOT
The SaldoInicial and SaldoFinal for PartidasVivas and Bonuses must be zero or positive on the BOT file. sss. PA: AZA session reported in other games
The JUD PlanificaciónAzar field must only be completed in the AZA JUD; it is considered an error to find this field (not mandatory) in the JUD of other games.
Page 57 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
ttt. PC: Competition Country on the CEV
The operator is requested to report the country where the event is held in the ‘Competicion’ field on the CEV file. The country should be reported first, then a separator such as ‘-’, followed by the competition the event falls into. uuu. PD: Players in EstadoCNJ=’PV’ with accumulated deposits over €150
A control that checks whether there are players registered after 1 April 2019 who have not been verified with proof of identity (estadoCNJ=’PV’) and who have accumulated deposits of €150 or more. vvv. PE: Prizes in kind
Prizes in kind are reported on the CJ, OP and JU files. This control checks that if prizes in kind are reported on one of the files, they are reported on the other two types of file. It is also checked that the data is consistent.
A Prize in kind should not be confused with a Gift. For it to be a prize in kind there must have been a prior stake in EUR, or in another unit. www. PN: Participation of gamblers with Non-active status
A control to check if there are players with a status other then A or PV and who participated in the period studied. xxx. PP: Prizes without wagers in JUD
It is considered an error to find values for Prizes other than zero in the JUD files, when the Wager is zero.
NOTE: There are some exceptions to this rule; if the operator gives us a satisfactory explanation this exceptional situation is considered correct. yyy. PV: Unfinished games 1. As long as the "SaldoFinal" of unfinished games is not zero, "DesgloseCompromiso" must be reported. 2. The sum of the breakdowns must be equal to the total of the "SaldoFinal". 3. The opening balance plus the total movements must match the “SaldoFinal”. 4. The resolution dates of the unfinished games that appear in the closing balances of the "DesgloseCompromiso" field must be greater than the date of the month of study.
Page 58 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
The dates highlighted in the box of the example, belonging to "DesgloseCompromiso" must be greater than the month reported (April 2017).
Saldo inicial + movimientos = Saldo final
2934.07 + 991.82 – 2869.29 = 1056.60
Saldo final = ∑Desglose Compromiso
1056.60 = 603.43 + 453.17
zzz. RE: Rectified
Any file that is sent with changes with respect to a previous one must be sent as a corrected file:
Page 59 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• The new record must have a new "RegistroId". • They will never be sent as duplicates. • Within the field "Rectificacion", the fields "RegistroId” and "RegistroFecha” must be those of the record which they rectify. aaaa. RG: Gamblers on the general register of gambling access bans who are active but not playing
This control verifies registrations on the general register of gambling access bans who have an on-line user record, whose status is active (A or PV), and who do not carry out gambling activities. These gamblers must have EstadoCNJ=’PR’ for which reason they are treated as a quality reporting error in the notice to the operator. bbbb. RI: Banned gamblers (General register of gambling access bans) playing
This control verifies registration on the general register of gambling access bans who have an on-line user record and who have carried out gambling activity, deposit or wagers in the period in question. cccc. RP: Positive Withdrawals
On gambling accounts (CJ file) all deposits and withdrawals requested by the gambler, and the time they are requested, must be reported, even if the request is not completed in the end and the gambler cancels the transaction.
Withdrawals, since they result in a decrease in the value of the player's account, are reported with a negative sign. Therefore, the cancellation of a withdrawal will be reported with a positive sign.
Only sending withdrawals relating to completed transactions, with no details about cancelled withdrawals, is an error. Sending cancelled withdrawals in other field (deposits or others) is an error.
To check that the requirement is fulfilled, the percentage of withdrawals with a positive value is reviewed. If this is very small (less than 5% of the total transactions) or null, the operator is consulted. dddd. RS: Resident Players
The following situations are considered to be errors for gamblers reported as ‘Residentes’.
• VSVDI = 'S' and FVSVDI null or incorrect • VDocumental = 'S' and FVDocumental null or incorrect • VSVDI = ‘S’ with no NIE or National ID Document • Invalid FVSVDI or FVDocumental • VSVDI = ‘N’ and VDocumental = ‘N’ and estadoCNJ=’A’ o ‘PV’
Page 60 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
eeee. RU: Number of RU players
The "NumeroJugadores" reported in RUT and RUD files must be the same. In addition, it must be equal to the "NumeroJugadoresPorEstado" and the sum of all players in each status in RUD must be equal to the number reported for that status in RUT. ffff. SC: Casino gambling session
This control contains various requests to the operators for change, to improve the information: • In casino games (RLT, BLJ and PUN) a request is made to report a single Juegold per session for the gambler, grouping all the bets (PA), return of bets (PD) and prizes (PR) made during the gambling session by the same gambler. • The FechaApuesta field on the JUD for casino games must be filled in with the session’s FechaInicio. • The last 4 digits of the card used in the MedioPago field are requested in Deposits and withdrawals on the CJD file.
A possible error in the slot machine (AZA) sessions reported on various files is also included. Several JU can be sent to report a single AZA session in the event that the session was interrupted due to a technical problem or disconnection. Normal AZA gaming sessions should be reported in a single JUD/JUT with a single JuegoID.
gggg. SF: Closing Balance on the CJDs
The closing balance on the gamblers’ accounts should always show the value in the EUR unit, regardless of whether this is zero, or there are values in other units, or not. hhhh. SH: Balances of gambling accounts. 1. In the monthly CJ files: the opening balance plus all its movements, excluding the fees, must coincide with the closing balance.
SI + DE + RE + PA + PD + PR + PE + T_IN + T_OUT + AP + OT + BN = SF
2. The values for SI, DE, RE, PA, PD, PR, OT, BN, TI, TO, AP and SF must be the same in the monthly CJT and CJD.
3. The "SaldoInicial" must be the same as the "SaldoFinal" of the previous month.
4. These rules apply to input in the EUR unit and also to input in the other units defined by the operator.
Page 61 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
iiii. SL: Exceeding set deposit limits
This control checks that the deposits made by gamblers do not exceed the limits set on their user record3. jjjj. SR: Players with a gambling account without a record
All players who have a gambling account must have a user record.
All players that appear in the UK with "EstadoCNJ = A" must have their corresponding player account. kkkk. SS: Exceeding Slot session limits
This control checks that the gamblers do not exceed the limits set in their slot machines session settings. It is understood that the amount has been exceeded in slot machine sessions where the gambler has set a maximum amount of money to spend and this has been exceeded4. llll. SX: CJ movements which are not shown on a JU
This control checks that there are no gaming movements reported on the Gambler accounts which have not been reported on a JUD/JUT. It should be taken into account that the information on the CJ is reported when it occurs and on the JU when the game ends or is terminated. mmmm. TA: Double bet ticket
The TicketApuesta in the JUD of a betting license must be unique. nnnn. TC: Credit and debit cards
A request is made to specify whether the card is credit or debit in the payment methods reported with deposit and withdrawal movements.
3See note 1 4Article 14 of Order HAP/1370/2014 of 25 July, approving the basic regulations for slot machine gambling.
Page 62 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
Reporting generic cards and/or that the percentage of Cards reported does not reach 50% on DE and/or RE is considered to be an error. oooo. TE: Type of event on the CEV
The TipoEvento field on the CEV has three possible values:
• D: Sports • H: Hípica • O: Other
A check is made that the TipoEvento reported matches the licence for the correct betting game (TipoJuego on the JUT reporting it).
TipoEvento TipoJuego
D ADC, ADM, ADX
H AHC, AHM
O AOC, AOX
pppp. TF: Bet ticket and date
All betting games have to report "TicketApuesta" and "FechaApuesta".
Page 63 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
qqqq. TZ: Dates with time zone
From v2.11 of the data model, the majority of date fields on the model must be reported in the format that includes the time zone: yyyymmddhhmmss+hhmm (See Appendix III).
A check is made that all the date are correctly reported in the specified format. rrrr. V2: Live roulette
The operators offering live roulette are monitored, verifying that they are reporting a text or label in the VarianteComercial field which enables it to be differentiated from conventional roulette, for example, the words ‘LIVE’, ‘VIVO’ or ‘DIRECTO’. If the operator offering that type of roulette does not report it in such a way that it is distinguishable, they are requested to amend it.
ssss. VA: Market version of the JUT
The field "VarianteComercial" is mandatory for POQ, BLJ and RLT
The version field is mandatory and has specific fields for the games: • POQ: . ‘DR’: Draw . ‘ST’: Stud . ‘OM’: Omaha . ‘TH’: Texas Holdem • BLJ . ‘CL’: Classic . ‘AM’: American . ‘PO’: Ponton . ‘SU’: Surrender . ‘21’: Super21 • RLT . ‘Francesa’
Page 64 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
. ‘Americana’
tttt. VI: identity verification
The “VSVDI” field must have an ‘S’ value for all Resident players with estadoCNJ=A. It should have an ‘N’ value for Non-Resident players with estadoCNJ=A. uuuu. VN: Associated gamblers playing
This control verifies whether any person registered on the register of the operator’s associates5 has made deposits or stakes during the period.
vvvv. VR: Players verified on the general register of gambling access bans
All players who have been looked up on the general register of gambling access bans’ on- line consultation service with a positive result must be marked with estadoCNJ=’PR’.
This control verifies that operators are correctly reporting these players using the correct estadoCNJ.
5Article 6.2.c) of the gambling regulation Act 13/2011.
Page 65 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
10. APPENDIX I. Important notes. Tips & Tricks
• In the User Registration files (RUD, RUG and RUR), you only have to send the information of the users who have managed to register correctly, and who are, therefore, ready to move to an active status, regardless of whether they are awaiting documentary verification. Do not send unsuccessful registration attempts, records that were never validated, were not activated and therefore never played.
• The Aggregate type files (RUT, CJT and JUT) must ALWAYS tally with the data of the Disaggregated type files with which they are related for the same period. Therefore, a daily RUT file must have the same number of players and registrations as those reported in the corresponding RUD. The daily CJT must coincide in terms of Balances and the rest of the variables with the data reported in the CJD of the same day. And the JUT corresponding to a game must have the same JuegoId and economic values as the JUD corresponding to that game.
• The information contained in the daily files (RU and CJ) must correspond to that reported in their monthly files. Therefore, any Registration or Modification of user registration that is reported in a daily file must appear in the corresponding monthly file and vice versa. Regarding the information that appears in the daily CJs, it must be completely consistent with the information reported in the corresponding monthly CJ. For example, the sum of all the deposits reported in the daily files must be equal to the amount reported in the monthly file.
• The movements in Botes and PartidasVivas in the BOT file must be reported in two notes, one positive with the increase in that Bote or PV and another negative with the Botes delivered and the bets resolved in the period. You always have to report both movements even if one of them is zero.
• There is a DGOJ on-line service giving information on whether a player has died. When the status of these players is reported, this information should be taken into account. Active players who, after their decease, have not carried out any movements on their account will move to estadoCNJ=’O’, but players who are registered after the date of their decease, or who, after decease, maintain activity on their account will automatically be blocked and move to estadoCNJ=’SC’.
• Regardless of the estadoCNJ the player is in, the inactivity statuses will be applied when the set time has passed: suspended status ‘S’ for players who have been continuously inactive for 2 years, and cancelled status ‘C’ for those who have been in suspended status for 4 years.
• Self-excluded players: self-excluded status (estadoCNJ=’AE’) covers cases where the player requests the operator for complete self-exclusion from all the games. In the event that the player requests partial self-exclusion from some games, there is no specific provision on the current data model which means that this information cannot be reported on the SCI. The player’s status will be the one they have for the other
Page 66 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
games where they continue to be active, that is to say, Active (“A”) or pending verification (“PV”), depending on the case.
Page 67 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
11. APPENDIX II. How to report Bonuses
The resolution defining the data model does not specify how the bonuses must be reported; a field is defined in the CJ files, but it is not specified how it must be filled out.
To improve efficiency in reporting bonuses, and enable the DGOJ to carry out the same processing in all operators, a simple bonus reporting model has been designed which can be used on all bonus and promotion systems on the market.
To do so, three single concepts are defined for the Concepto de Bonos field on the CJD and CJT which relate to the main milestones in the lifespan of a bonus.
• CONCESION: occurs when the operator offers a bonus to the player and they accept it. • CANCELACION: occurs when the bonus or promotion has expired and, therefore, the Bonus money and/or the real money in Euros (EUR) obtained through those bonuses is withdrawn from the account. • LIBERACION: occurs when the accumulated money for a bonus becomes real money. This transaction generates two entries on the file: an entry with a negative amount on the bonus unit, and another entry with a positive amount for the amount of Euros released.
Movements for stakes, returns or prizes in bonuses are reported in the units used by the operator for their bonuses and promotions (for example: Bonuses, EurBonuses, etc).
Promotions entailing free bets or wagers (Freebets, Freespins, Freebingo, eTournament, etc.) will be reported in the same way.
The SH control is applied in the same way to the movements with the EUR unit as the movements with the rest of the units. Therefore, it is expected that the sum of all movements plus the opening balance in the player's account is equal to the closing balance of the same in the period reported.
Page 68 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
12. APPENDIX III How to report temporary data
From version 2.11 onwards of the data model, a new type of data has been declared that allows us to know exactly the moment that is recorded, regardless of the time zone the server generating the entry is.
In this way, operators will be able to report the variables that contain date-time in their own time zone as long as they add the time difference with respect to UTC.
The definition of the new field is:
The fields affected by this new format are as follows:
RegistroCEV: • FechaInicio • FechaFin
RegistroRUD, RegistroRUG: • Desde • FVSVDI • FVDocumental
RegistroJUT: • FechaInicio • FechaFin • RegistroApuesta:
o FechaHecho RegistroJUD: • FechaFin • FechaApuesta
RegistroJUA:
Page 69 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
• FechaAjuste
RegistroCJD: • Depositos:
o DesgloseOperaciones Fecha • Retiradas:
o DesgloseOperaciones Fecha
Examples of valid and invalid date values:
Dates values Valid Pattern
20171204134522 aaaammddHHMMSS
20171204134522+0200 aaaammddHHMMSS+HHMM
20171204114522+0000 aaaammddHHMMSS+HHMM
20171204114522-0100 aaaammddHHMMSS-HHMM
201712041345220200 aaaammddHHMMSSHHMM
20171204134522-02 aaaammddHHMMSS-HH
Page 70 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
13. APPENDIX IV. New fields from version xsd 2.13 onwards
The changes introduced are as follows:
• The CEV becomes daily, with the pre-existing monthly control being retained.
On a daily basis, the operators that offer games under the general betting license must report this file with information on new events and modifications of the events already reported.
Monthly operators will send a file that contains all the registrations and modifications of events registered in that month.
In order to report the new file correctly, a new type of ‘RegistroCEVDM’ data model has been defined.
Organisation of the folders in the warehouse is as follows:
The names of the file have the following format:
For example:
1082_10821_JU_CEV_D_20180424_LOTEID.zip (for a daily file)
1082_10821_JU_CEV_M_20180501_LOTEID.zip (for a monthly file)
• A new 'Actualizado field is included in the CEV file; this field is Boolean and it will contain an 'S' when the information that is reported is the modification of some data relating to an event previously reported. In that case, there must be a previous CEV file with the same EventoId. In addition, it will have a value of 'N' when it is a new event.
Under no circumstances should a repeated or duplicate event be sent if there is no change in the data related to that event.
Page 71 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
In the RUD and RUG file, it is clarified that the VSVDI field must be reported with a value of 'S' only the query has been made in the SVGO of the DGOJ and this have been positive. In any other case the value must be 'N'.
• Three new fields are added to the Depositos and Retiradas operations of the CJDs and the results of each game in the JUD. o IP: It will contain the IP address of the device from which the player has performed the operation that is being reported. o TipoDispositivo: It is a field listing the following values: MO (Mobile), PC, TB (Tablet), TF (Fixed terminal) and OT (Others). o IdDispositivo: Identifier of the device from which the connection is made. The highest value that can be obtained for the device from which the connection for the transaction reported was made should be reported. Depending on the type of device and its security settings, the data that can be obtained will be more precise (imei, mac, etc) or more generic (telephone model, operating system version, etc). The data reported should be as precise as possible. IdDispositivo may change over time. The information obtained in the connection is required.
Some examples of IdDispositivo:
• A new 'Cuota' field is included in the JUD files. This field is a decimal value that must contain the odds of the bet at the moment when it is accepted by the player.
• New statuses are added to the listed estadosCNJ:
o PV: Pending document verification o AE: Self-excluded
• The FechaFin field is included in the JUD files. This field, in date format with time zone, should correspond to the same one on the JUT for the same Juegold.
Page 72 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
14. APPENDIX V. Test players, recommendations for use
An analysis has been made of the test players reported by the various operators, and of the problems and errors that they have caused during the past few years. Using this experience, we decided to draw up a series of basic recommendations for operators in order to guide them when they generate test players on their gambling platforms.
A test player is understood to be a fictitious player created by the operator to test their gambling platform, whether or not there is an associated account, and who is reported as such to the DGOJ, to be taken into account in the validations carried out on the information received.
The basic recommendations to be taken into account by the operators when it comes to creating and using test players are as follows:
• The test player identifier (National ID Document, NIE or Document) may not coincide with that of a real account or of another test player.
• The compulsory fields have to be filled in with valid data, particularly the date of birth and activation date, estadoCNJ and estadoOperador, Name and Surname 1 fields,
• A test player who has some kind of characteristic preventing them (or that will prevent them) from playing, in the event they are a real player, should be treated in the same way by the system and must not be able to play. This applies to minors, deceased, restricted, prohibited and associated persons. If the test player falls into any of these categories, they must have a status that is consistent with the situation and must not be able to play in any case whatsoever.
• The creation of test players must be limited to a reasonable number of accounts and should have a clear purpose.
• The amounts gambled by these players must be very low, in such a way that they do not significantly affect the operator's financial variables.
• The financial information reported should be consistent on all the files and be the same on the CJ as on the OP and JU.
• It is NOT compulsory, but it is recommended, that the Jugadorid field for these players has the following features:
o That it has an initial class chain: test, user, etc.
o That the chain is no longer than 15 characters
• The list of test players should be reported to the monitoring supervision inbox ([email protected]) at the DGOJ, and be maintained up-to- date. A player who has not been reported as a test player will be treated as a real player and will generate the corresponding consequences.
Page 73 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
15. Appendix VI: Correct use of the "Actualizado" field of the CEV
We have detected different interpretations over the use of the "Actualizado" field of the CEV (Catalogue of events) file.
This appendix is a usage guide for this field to unify its use across all operators.
The "Actualizado" field is has been mandatory since version 2.12 of the data model. It has two possible values:
• N: For new event registrations • S: To amend the data on existing events • Important note: Given that CEV files differential, an event that already exists and that has not been changed should not be sent.
The possible situations what we might find are:
• New event without changes in the month: o CEVM (CEV monthly): Actualizado = "N" o CEVD (CEV daily) for the day its registration is reported: Actualizado = "N"
Page 74 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
OperadorId EventoId DescripcionEvento FechaInicio FechaFin TipoEvento Deporte Dia/Mes Competicion Actualizado Periodicidad World 29/05/2021 29/05/2021 World 100X 123456 Championship D 24 01/01/2021 N CEVM 1:00 2:30 Championship 2021 World 29/05/2021 29/05/2021 World 100X 123456 Championship D 24 03/01/2021 N CEVD 1:00 2:30 Championship 2021
• New event with changes in the same month: o CEVM: a record with the day of registration Actualizado = "N" o CEVM: a record with the most recent update of data: Actualizado = "S" o CEVD: a record for each day with updates, only the last of the day if there are several. Actualizado = "S" o CEVD: in the particular case that on the day of registration there are also one or more updates, it is considered correct: . to send two records, one with the registration (Actualizado = "N") and the other with the data of the last amendment that day (Actualizado = "S") . or send a single record with the most up-to-date data and Actualizado = "N" . In this particular situation, the decision on the daily report must be replicated on the corresponding monthly report.
OperadorId EventoId DescripcionEvento FechaInicio FechaFin TipoEvento Deporte Dia/Mes Competicion Actualizado Periodicidad World 29/05/2021 29/05/2021 World 100X 123456 Championship D 24 01/01/2021 N CEVM 1:00 2:30 Championship 2021 Championship 29/05/2021 29/06/2021 World 100X 123456 D 24 01/01/2021 S CEVM 2021 1:00 2:30 Championship World 29/05/2021 29/05/2021 World 100X 123456 Championship D 24 03/01/2021 N CEVD 1:00 2:30 Championship 2021 World 29/05/2021 29/06/2021 World 100X 123456 Championship D 24 03/01/2021 S CEVD 1:00 2:30 Championship 2021 Championship 29/05/2021 29/06/2021 World 100X 123456 D 24 05/01/2021 S CEVD 2021 1:00 2:30 Championship
• Event not new in the month and with changes: o CEVM: a record with the most recent update of data: Actualizado = "S" o CEVD: a record for each day with updates, only the last of the day if there are several. Actualizado = "S"
OperadorId EventoId DescripcionEvento FechaInicio FechaFin TipoEvento Deporte Dia/Mes Competicion Actualizado Periodicidad World 29/05/2021 29/06/2021 World 100X 123456 Championship D 24 01/10/2020 N CEVM 1:00 2:30 Championship 2021 Championship 29/05/2021 30/06/2021 World 100X 123456 D 24 01/01/2021 S CEVM 2021 1:00 2:30 Championship World 29/05/2021 29/06/2021 World 100X 123456 Championship D 24 13/10/2020 N CEVD 1:00 2:30 Championship 2021 World 29/05/2021 30/06/2021 World 100X 123456 Championship D 24 03/01/2021 S CEVD 1:00 2:30 Championship 2021 Championship 29/05/2021 30/06/2021 World 100X 123456 D 24 05/01/2021 S CEVD 2021 1:00 2:30 Championship
Page 75 of 76 Quality guide v3.4
MINISTRY OF CONSUMER AFFAIRS DIRECTORATE GENERAL FOR THE REGULATION OF GAMBLING
(*) In the case of a double change during the month, on different days, that leaves the event with the same data that had been previously reported in the month that said event was reported for the last time, both changes must be reported on the two days on which the occur and the monthly one must be reported without changes, but with the field Actualizado = "S": o CEVM: a record with the most recent update of data (which in this case could match the previous month): Actualizado = "S" o CEVD: a record for each day with updates, only the last of the day if there are several. Actualizado = "S"
OperadorId EventoId DescripcionEvento FechaInicio FechaFin TipoEvento Deporte Dia/Mes Competicion Actualizado Periodicidad
World 29/05/2021 29/06/2021 World 100X 123456 Championship D 24 01/01/2021 S CEVM 1:00 2:30 Championship 2021 World 29/05/2021 29/06/2021 World 100X 123456 Championship D 24 13/10/2020 N CEVD 1:00 2:30 Championship 2021 World 29/05/2021 30/06/2021 World 100X 123456 Championship D 24 03/01/2021 S CEVD 1:00 2:30 Championship 2021 World 29/05/2021 29/06/2021 World 100X 123456 Championship D 24 05/01/2021 S CEVD 1:00 2:30 Championship 2021
If the double change occurs on the same day, it should not be reported in either the daily or the monthly report • No new event and without changes: o The event is not sent as no changes have been made and the CEV is a differential file.
Notes to highlight:
• An event can only have the Actualizado = "N" field once per period (monthly/daily) and never again in subsequent files. • The information in the CEVM will be the same as the last information received in the daily reports. Only one record per event is be sent in the monthly report; the one that corresponds to the most recent information sent in the daily reports of the reported month. Unless it has been created and amended in the same period as it will then have two records, the registration and the last update. • If changes have been made more than once in the same day, only the latest update will be sent, thus avoiding duplicated events. • An event update will only be sent if this information is different from the last one reported for that event. The exception discussed in the previous paragraph applies (*)
Page 76 of 76 Quality guide v3.4