Ontario no admite un juego en su mercado regulado de igaming porque el juego funcione. Admite un juego que se ha puesto por escrito, se ha descrito al jugador y se ha certificado. Deben existir tres artefactos antes de que un título pueda ofrecerse por dinero real en un sitio de juego de Ontario, y responden a tres preguntas distintas: una especificación interna que dice qué es el juego, una información para el jugador que dice a qué se compromete el jugador y una certificación independiente que dice que ambas afirmaciones se han probado conforme a los estándares del Registrar.
Esa estructura importa sobre todo a la parte que no es el operador: el estudio que construyó el juego, la plataforma que lo suministra o el agregador que lo distribuye a un cliente de Ontario. Las normas de Ontario están redactadas como resultados y no como una lista de comprobación de desarrollo, y el Registrar es explícito en que la responsabilidad puede recaer tanto en un proveedor como en un operador. Este artículo repasa lo que los Registrar’s Standards for Internet Gaming exigen realmente de un juego y del proveedor que está detrás, y lo que la política de certificación que los acompaña hace con un calendario de lanzamiento.
Ontario regula resultados, no una lista de comprobación de desarrollo
Los Registrar’s Standards for Internet Gaming entraron en vigor el 4 de abril de 2022, cuando se abrió el mercado regulado de igaming de Ontario, y se asientan en un modelo deliberadamente indirecto. En virtud de la Gaming Control Act, 1992, el Registrar fija estándares basados en el riesgo, y el documento de estándares declara su intención sin rodeos: el enfoque se diseñó para pasar la regulación «from requiring registrants to comply with a specific set of rules or processes, which tend to be prescriptive in nature, towards the broader regulatory outcomes or objectives they are expected to achieve.»
Para un proveedor, eso tiene dos consecuencias que es fácil pasar por alto.
La primera es que no hay ninguna línea en el documento que diga «your build must contain X». El documento dice qué resultado debe cumplirse y deja el mecanismo al registrante. Un estudio no puede cumplirlo por enviar una función allí donde un competidor envió la misma función; tiene que poder demostrar que el resultado se cumple para su compilación.
La segunda es quién responde. Los estándares se aplican a OLG por su sitio de juego por internet, a iGaming Ontario por sus actividades y a los operadores de juego por internet registrados, y algunos estándares concretos también se aplican a los proveedores registrados de servicios relacionados con el juego. El documento añade después la frase que decide la mayoría de las discusiones comerciales: «Operators are expected to ensure that the Standards related to the operation of their gaming site are met, regardless of the entity that is carrying out the related activities. Depending on the circumstances, the Registrar may hold an Operator, a gaming-related supplier, or both, accountable for meeting a particular Standard.»
Si se lee como proveedor, la cuestión del cumplimiento deja de ser un problema solo del operador. La misma sección señala que el Registrar puede ordenar a cualquier proveedor registrado que cumpla estándares y requisitos adicionales, y puede añadir condiciones específicas para un registrante.
La especificación que el proveedor tiene que poder producir
El primer artefacto es un documento, y no es la página de marketing. El estándar 4.05 exige que «Game specifications must be documented that clearly indicate» cinco cosas:
- los objetivos del juego;
- las apuestas que pueden realizarse;
- cómo se opera y se juega el juego;
- las probabilidades de ganar de cada premio disponible para los jugadores;
- la ventaja del operador en relación con cada apuesta.
Cuatro de esas cinco son hechos de ingeniería corrientes. La quinta —la ventaja del operador en relación con cada apuesta— es el margen de la casa expresado como propiedad por apuesta y no como porcentaje de titular, y es el punto en que la especificación deja de ser un documento de diseño y pasa a ser un documento regulatorio. Un juego con varios modos de apuesta, varios niveles de apuesta o varios tramos de premios tiene una cifra de este tipo por apuesta, no una por juego. La guía del modelo matemático y la hoja PAR cubre la parte probatoria de ese trabajo; la aportación de Ontario es que la propia especificación debe existir.
La especificación se apoya en una obligación de registro más amplia. El estándar 4.01 exige que «All gaming activities and financial transactions shall be conducted fairly and honestly, and must be independently verifiable», y sus requisitos piden un seguimiento y un registro independientes continuos suficientes para verificar el cumplimiento de las reglas del juego, confirmar los resultados, pagar el premio a la persona correcta y confirmar la exactitud de las transacciones financieras, con registros continuos para los sistemas de juego críticos que rastrean la contabilidad financiera y el historial de estados del juego.
El estándar 4.02 enumera después qué deben permitir los registros de transacciones y de estados del juego, incluidos «Capturing information needed to continue a partially complete game within a reasonably defined time» y «Tracking of game enabling, disabling and configuration changes». Dos estándares posteriores convierten esos registros en una propiedad comprobable: el 4.14 exige mecanismos «to allow a game to be recreated up to and including the last communicated state to the player», y el 4.12 exige que los resultados del juego puedan recuperarse, «where technically possible, so that player bets can be settled appropriately».
Esa es la forma práctica del primer artefacto. Un juego que no puede reconstruirse a partir de sus propios registros no puede defenderse, y la reconstrucción tiene que llegar al último estado que el jugador vio realmente.
La información que el jugador debe tener antes de la primera apuesta
El segundo artefacto es el que suele olvidar una conversación de encargo, porque no forma parte del desarrollo: es lo que lee el jugador. El estándar 4.06 no deja lugar a dudas sobre el momento. «Prior to placing a bet or wager, the player shall be provided with sufficient information to make informed decisions about betting or wagering based on chances of winning, the way the game is played, and how prizes and payouts are made.»
Su primer requisito describe cómo debe presentarse el material: «Comprehensive and accurate information that explains the applicable terms governing play must be easily available to the player prior to the placing of a bet or wager through such supports as “game rules”, “help” or “how to play” pages placed prominently to allow players to easily locate them. All reasonable steps must be taken to ensure the content is understandable.»
El segundo requisito enumera qué debe contener realmente el contenido, y es una lista más larga que la de la mayoría de los paneles de reglas:
- cómo pueden participar los jugadores, con instrucciones y las condiciones de cada método;
- instrucciones claras sobre cómo interactuar con el juego;
- descripciones claras de qué constituye un resultado ganador;
- cualquier restricción al juego o a las apuestas, como límites de duración de la partida o ganancias máximas;
- información completa, exacta y comprensible sobre las probabilidades de ganar, las cuotas de pago o los retornos a los jugadores;
- las unidades del valor de los premios, como la moneda o los créditos;
- otros elementos que afectan al juego o a los resultados —el número de barajas o la frecuencia de los barajados en un juego de cartas virtual, cómo funciona un bote progresivo, cuántas fichas de qué tipo entran en una ronda de bonificación y cómo se comporta esa ronda.
Hay dos puntos más en el mismo estándar que es fácil pasar por alto y caro de añadir a posteriori. Cuando la velocidad de interacción afecta a las posibilidades de ganar del jugador, hay que advertir a los jugadores de que la velocidad de conexión o del procesador puede afectar al juego; y cuando la habilidad o la estrategia afectan a las posibilidades de ganar, hay que decírselo también a los jugadores. Ninguna de las dos cosas es cierta en todos los juegos, y la obligación es decirlo cuando lo es.
El estándar fija también las unidades: la denominación de cada crédito debe mostrarse con claridad, los premios y pagos mostrados deben dejar claras sus unidades, y hay que indicar a los jugadores las circunstancias en que un juego puede declararse nulo. Un panel de ayuda que enumera los pagos en créditos mientras el saldo se muestra en moneda ha respondido a una pregunta distinta de la que se le hizo.
Lo que la información al jugador no puede decir
El estándar 4.07 es donde el enfoque de Ontario más se aparta de una instrucción genérica de «be honest». Declara que «Information provided to players prior to and during game play shall not mislead players or misrepresent games», y a continuación enumera los incumplimientos:
- describir resultados, premios o funciones que no son alcanzables;
- animar a jugar como medio de recuperar pérdidas de juego anteriores u otras pérdidas financieras;
- hacer promesas falsas, o presentar la ganancia como el resultado probable;
- dar a entender que las posibilidades de ganar aumentan cuanto más se juega, cuanto más se gasta o mediante la habilidad cuando la habilidad no es un factor;
- usar un lenguaje que sugiera que un resultado concreto es más probable que su probabilidad real —el estándar cita los ejemplos: «due», «overdue», «ready» y «ready to hit»;
- caracterizar mal la naturaleza del juego dándole «a commonly accepted name, such as “European Roulette”, if the game does not operate as a player would reasonably expect.»
Los puntos cuarto y sexto son los que una temática puede hacer fallar. Un juego cuyo rasgo comercial más destacado es una racha que «se acumula» se lee como una probabilidad creciente a menos que el panel de reglas diga qué es de verdad esa mecánica, y un juego de ruleta con la marca de una variante conocida compromete al proveedor con las reglas que un jugador asocia a ese nombre, aunque la temática la haya elegido una marca cliente. Es una restricción de diseño y de textos, no legal, y pertenece a la especificación de reglas y no a una revisión tardía de una pantalla de ayuda.
La certificación que debe existir antes del despliegue
El tercer artefacto es externo. El estándar 4.08 exige que «All igaming games, random number generators and components of igaming systems that accept, process, determine outcome of, display, and log details about player bets, including any subsequent modifications, must either be approved by the Registrar or certified by an independent testing laboratory registered by the Registrar, as per the AGCO’s ITL Certification Policy, prior to being provided for any gaming site.»
La política que se añade detalla los límites que deciden un plan de lanzamiento.
Quién puede certificar. Solo los laboratorios de ensayo independientes que la AGCO registra. La política describe una certificación de ITL como «a form of written assurance that is issued by registered independent test laboratories (“ITLs”) to indicate that they have tested and confirmed that the types of technology captured by this policy meet the relevant AGCO Registrar’s Standards for Internet Gaming».
Qué debe certificarse. Todos los juegos, los generadores de números aleatorios y los componentes de sistema que aceptan, procesan, determinan el resultado, muestran y registran los detalles de las apuestas de los jugadores, incluidos explícitamente las máquinas tragaperras, los juegos de mesa, las apuestas deportivas y a eventos, el póker y otros juegos de cartas. El crupier en vivo se trata por separado: el requisito se extiende a los generadores de números aleatorios físicos con elementos electrónicos y equipos similares, incluidas «physical wheels (roulette), physical dice tables, and card shufflers that have electronic components», y para los juegos con crupier en vivo se aplican también los Casino Electronic Gaming Devices and Gaming Systems Minimum Technical Standards.
Qué debe contener el instrumento de certificación. La política enumera ocho elementos: el nombre registrado ante la AGCO del laboratorio certificador; el nombre registrado ante la AGCO del registrante que la solicitó; la fecha de emisión; un identificador único que permita a la AGCO rastrear la certificación; el nombre del producto, el número de versión y el fabricante; la lista de estándares con arreglo a los cuales se certificó la tecnología; si alguna parte de la certificación se basó en ensayos previos para los requisitos de otra jurisdicción; y, en el caso de una recertificación, una descripción de alto nivel de los cambios clave que la hicieron necesaria. A petición, el laboratorio debe poder aportar también los resultados de ensayos previos del mismo producto para el mismo registrante, incluidas las deficiencias detectadas anteriormente, e información sobre el entorno de ensayo, las configuraciones del producto y la metodología de ensayo.
Dos de esos ocho elementos tienen peso comercial. Una certificación vinculada a una lista de estándares es un instrumento acotado, y la política confirma que el alcance es deliberadamente estrecho: «The scope of the certification is not “all” Standards, but rather those standards that are relevant to games, random number generators, remote gaming servers, and sport and event betting systems being tested.» Y el campo de dependencia de jurisdicción es la razón por la que un título que ya está activo en otro lugar sigue necesitando su propio instrumento para Ontario.
Qué no puede hacer una certificación. «For regulatory purposes, an ITL may not issue a certification that is contingent on any future changes or modifications to the technology being carried out.» Un laboratorio puede, sin embargo, certificar una tecnología señalando funciones que habría que desactivar o deshabilitar para cumplir —lo cual es un resultado útil, pero solo si el proveedor las desactiva de verdad después y puede demostrarlo. Y una certificación que intente limitar o renunciar al uso que el Registrar haga de ella «will not be a recognized certification».
Qué cuenta como cambio: las tres categorías de recertificación
La respuesta de la política a «¿cuándo tenemos que volver a hacer pruebas?» es una clasificación, y el proveedor es quien la asume. La recertificación es necesaria «when any modification or subsequent discovery of an undetected issue impacts critical gaming system integrity, fairness, or security, or compliance with the Gaming Control Act, 1992, its regulation, and/or the Standards», y el efecto de ese cambio es invalidar la certificación anterior. El proveedor clasifica la diferencia entre el software certificado anteriormente y la nueva versión en una de tres categorías y conserva los registros de la clasificación para la AGCO:
- Modificaciones no regulatorias —cambios no relacionados con el cumplimiento, como errores menores de experiencia de usuario, cambios cosméticos o «new language added that is not used in Ontario». No exigen recertificación; el proveedor se apoya en la certificación anterior y confirma que la diferencia no es regulatoria.
- Modificaciones regulatorias —cambios relacionados con el cumplimiento de los estándares, incluido un cambio de diseño que pueda afectar a uno de ellos, o cambios que abordan una preocupación regulatoria sin exigir una actuación inmediata. Deben certificarse antes del despliegue.
- Correcciones regulatorias de emergencia —cambios que abordan un problema regulatorio activo que exige una corrección inmediata. Pueden desplegarse primero y «must be submitted to an ITL for Ontario certification within 5 business days of release».
Esa última categoría es la única vía por la que código no certificado llega a los jugadores de Ontario, y está limitada por un reloj, no por una intención. La clasificación es también el punto en que se pone a prueba un cambio «cosmético»: añadir un idioma que el sitio de Ontario no atiende no es regulatorio, mientras que añadir uno que sí atiende sí lo es, porque las obligaciones de información al jugador se vinculan a los idiomas en que se ofrece el juego.
Dónde falla un título localizado o agregado
Dos requisitos encajan mal con un proceso de localización o de re-skin barato.
El primero es la regla de coherencia entre idiomas dentro del estándar 4.06. El contenido explicativo debe «contain the same information and be consistent across all languages it is provided in». No equivalente, ni adaptado: la misma información, de forma coherente. Una página de reglas cuya edición en español omite la restricción de ganancia máxima, o cuya edición en italiano describe una ronda de bonificación con un número distinto de fichas, es un defecto del artefacto. La guía de certificación localizada defiende la certificación de tratar cada edición como su propia compilación; Ontario añade que la información al jugador es información compartida con representaciones por idioma, no contenido por idioma.
El segundo es el límite del re-skin. Los estándares de Ontario no tienen una exención de ilustración por mercado. Cuando una plataforma distribuye un título encargado a varias marcas cliente, las superficies que un cliente puede cambiar son aquellas de las que no depende la información al jugador publicada. La guía de encargo de plataforma plantea las cuestiones del lado de la licencia; los estándares plantean la consecuencia, que es que un cambio en una superficie vinculada a las reglas es un cambio del artefacto descrito y puede entrar en la categoría de modificación regulatoria anterior. Para un brief de operador y no una licencia de plataforma, el mismo límite se traza en el brief de encargo de marca.
Conservar el registro, porque el Registrar puede pedirlo
La última obligación es la que decide si algo de lo anterior puede probarse un año después. El estándar 4.04 exige que «The gaming system shall be capable of providing custom and on-demand reports to the Registrar», y las orientaciones dan la forma de la solicitud: una lista de todos los juegos alojados por el sitio web, o una lista de todas las cuentas de jugador activas.
El estándar 4.09 añade la disciplina operativa que lo rodea: solo pueden usarse en el sitio de juego los juegos y servidores de juego remotos aprobados por el Registrar o certificados por un laboratorio registrado; cualquier problema con la integridad o la seguridad del sistema de juego debe comunicarse de inmediato al Registrar; el seguimiento y las pruebas deben mantenerse durante toda la vida del sistema; y cuando un proveedor detecta un problema debe «take immediate action, conduct timely investigations, and make any necessary corrections». Los operadores, por su parte, deben «monitor the payback of their live games to detect any behaviour that may indicate faulty performance», y el estándar 4.10 exige que un juego deje de estar disponible para los jugadores mientras no se resuelva un fallo sospechado que pueda afectar a la integridad o la equidad, con decisiones del operador «fair, reasonable, and made in good faith».
Para un estudio, la lectura práctica es que la especificación, la información al jugador y la certificación son un solo paquete, versionado en conjunto, conservado para la versión que está activa. Esa es la forma que adopta el envío de certificación en la mayoría de los mercados, y la variación de Ontario está solo en lo que el paquete debe nombrar. Un operador o una plataforma que trabaje con un socio de certificación y cumplimiento puede pedir ese paquete como entregable por versión en lugar de reunirlo cuando llega una consulta y, si el título se distribuye en lugar de operarse, puede preguntar al socio de agregación qué versión de él recibió cada cliente.
Preguntas que hacen los proveedores
¿Se aprueba un juego una vez para Ontario o se certifica juego por juego?
Existen ambas vías y ambas son por artefacto. El estándar 4.08 exige que cada juego de igaming, generador de números aleatorios y componente de sistema pertinente sea aprobado por el Registrar o certificado por un laboratorio de ensayo independiente registrado por la AGCO antes de ofrecerse para cualquier sitio de juego, y lo extiende a «any subsequent modifications». La certificación se emite contra un producto, un número de versión y un fabricante, con una lista definida de estándares, de modo que se vincula a la compilación que describe y no al catálogo del estudio.
¿El contenido de reglas para el jugador tiene que coincidir entre idiomas?
Sí. El estándar 4.06 exige que el contenido explicativo «contain the same information and be consistent across all languages it is provided in». La obligación se refiere a la información que divulga el juego, no a la calidad de la traducción en abstracto: una edición localizada que omite una restricción de juego, describe una ronda de bonificación de forma distinta o indica unidades de pago diferentes ha publicado información incoherente. Trátese la información al jugador como un solo documento con representaciones por idioma.
¿Qué cambios en un juego certificado obligan a recertificar en Ontario?
El proveedor clasifica la diferencia entre el último software certificado y la nueva versión como no regulatoria, regulatoria o corrección regulatoria de emergencia. Las modificaciones no regulatorias, incluidas las cosméticas y un idioma que no se usa en Ontario, pueden apoyarse en la certificación anterior. Las modificaciones regulatorias deben certificarse antes del despliegue. Las correcciones regulatorias de emergencia pueden desplegarse de inmediato, pero deben remitirse a un ITL para su certificación en Ontario dentro de los cinco días hábiles siguientes al lanzamiento. Los registros de la clasificación deben conservarse y presentarse a la AGCO cuando los solicite.
¿Puede un laboratorio certificar un juego con condiciones?
No como certificación condicional. La política establece que un ITL no puede emitir una certificación que dependa de cambios futuros en la tecnología, y que una certificación que pretenda limitar o renunciar al uso que el Registrar haga de ella no se reconocerá. Lo que un laboratorio sí puede hacer es certificar la tecnología especificando una o varias funciones que habría que desactivar o deshabilitar para que cumpla —lo que devuelve el trabajo al proceso de publicación del proveedor, donde la función debe desactivarse de verdad.
¿Qué ocurre si se descubre un fallo en un juego después del lanzamiento?
El estándar 4.10 exige que el operador deje el juego no disponible para los jugadores mientras no se resuelva un fallo sospechado del juego o del sistema que pueda afectar a la integridad o la equidad, y el estándar 4.09 exige que se notifique de inmediato al Registrar cualquier problema con la integridad o la seguridad del sistema de juego, conservando los registros y las pruebas de apoyo. Un fallo que resulta ser una cuestión regulatoria pone también en marcha el reloj de la modificación: la corrección se certifica después del lanzamiento, dentro de los cinco días hábiles.
¿Algo de esto se aplica a un proveedor que no es el operador?
Puede aplicarse. Los estándares establecen que los operadores deben asegurarse de que se cumplen los estándares de su sitio de juego, independientemente de qué entidad realice la actividad, y que el Registrar puede considerar responsable a un operador, a un proveedor de servicios relacionados con el juego o a ambos por un estándar concreto. Varios estándares de integridad del juego —entre ellos el 4.01, el 4.02, el 4.05, el 4.08 y el 4.09— también están marcados como aplicables a los proveedores de servicios relacionados con el juego. La lectura más clara es que un proveedor debe conservar sus propias pruebas en lugar de confiar en las del operador.
