La arquitectura de geolocalización de una app iGaming debe separar el permiso que se muestra en el dispositivo, la evidencia que recopilan los componentes aprobados y la decisión del servidor que permite o bloquea una apuesta. Tratar los tres elementos como una sola llamada a un SDK móvil dificulta explicar, probar y operar los fallos en distintos mercados.
Para un operador, responsable de producto o líder de ingeniería de apps, el entregable práctico es un contrato de control de geolocalización. Conecta la matriz de jurisdicciones, los recorridos del dispositivo, el esquema de evidencia, la política de límites, la API de decisión, los mensajes para el jugador, las señales de fraude, el registro de auditoría y las pruebas de aceptación antes de que un proveedor o framework cliente se convierta en una dependencia permanente.
Define la autoridad de geolocalización antes de integrar un SDK
La autoridad de geolocalización debe ser un servicio fiable de la plataforma que evalúe la evidencia y devuelva una decisión, no un valor booleano almacenado por la app. El cliente puede solicitar permiso al sistema operativo, iniciar un componente de recopilación aprobado y representar el resultado. No puede convertirse de forma segura en la autoridad porque el código cliente, el almacenamiento local y el tráfico de red están expuestos a un dispositivo que el operador no controla.
Empieza con una matriz de jurisdicciones. Para cada mercado y producto, registra la actividad controlada, la evidencia aceptada, la fuente de límites aprobada, el tratamiento de confianza, los eventos de comprobación, la vigencia de la decisión, las zonas excluidas, la política de reintentos, la regla de conservación y el responsable de escalado. Los requisitos normativos deben aparecer en esta matriz con la autoridad emisora y la versión vigente. No copies una regla temporal de un mercado a otro sin evidencia.
La norma GLI-19 para sistemas de juego interactivo es una referencia técnica, no un sustituto de la aprobación jurisdiccional. Su sección sobre detección de ubicación indica que un sistema de juego interactivo debe supervisar dinámicamente a quien intenta jugar, comprobar la ubicación antes de la primera partida después del inicio de sesión, usar un radio de confianza asociado y registrar las infracciones detectadas. También describe fuentes de ubicación y polígonos de límites auditados. Los controles exactos siguen dependiendo del organismo regulador y del sistema aprobado.
Separa permiso, evidencia y decisión de apuesta en estados distintos
El modelo de estados de geolocalización iGaming debe mantener separados el permiso del cliente, la calidad de la evidencia y la elegibilidad de la plataforma. Un dispositivo puede conceder acceso a la ubicación mientras la evidencia está caducada, es demasiado imprecisa o resulta incoherente. Una posición válida puede seguir estando fuera del polígono permitido. Una solicitud fallida al proveedor no demuestra que el jugador esté fuera del mercado.
Usa estados explícitos al menos para:
- permiso no solicitado, concedido, aproximado, denegado o restringido;
- recopilación pendiente, completa, caducada, no disponible o fallida por motivos técnicos;
- evidencia aceptada, insuficiente, incoherente o sospechosa de manipulación;
- decisión permitida, denegada, reintentable, caducada o en revisión.
La respuesta de decisión debe incluir un código de motivo estable, la versión de la política o del conjunto de reglas, la hora de decisión, el vencimiento o la condición de la próxima comprobación y una referencia de correlación. La app convierte ese código en orientación revisada y localizada. Los registros y las herramientas de soporte conservan el detalle técnico. El jugador no debe ver un error sin procesar del proveedor, y soporte no debe deducir si el problema fue el permiso, la precisión, la política o la disponibilidad del servicio.
Solicita acceso al dispositivo en el momento necesario
El recorrido de permisos de la app debe explicar por qué se necesita la ubicación justo antes de la acción controlada. Apple recomienda solicitar autorización de ubicación cuando una persona usa una función que la necesita y describe el acceso Durante el uso como el nivel preferido en la mayoría de los casos. Android distingue el acceso en primer y segundo plano y permite que una persona conceda una ubicación aproximada aunque una app solicite acceso preciso.
Esos comportamientos de plataforma crean requisitos de producto. Define qué muestra la app antes del aviso del sistema operativo, después de una denegación, cuando cambia la configuración, cuando solo está disponible el acceso aproximado y cuando el dispositivo no puede producir un resultado reciente. Si el acceso preciso o en segundo plano es realmente necesario, conecta ese requisito con el control aprobado y pruébalo en las versiones de sistema operativo compatibles. No solicites un acceso más amplio solo porque un SDK lo admita.
Una PWA añade otro límite. La especificación de geolocalización del W3C trata la geolocalización como una función controlada por permisos expuesta en contextos seguros y aconseja a quienes reciben los datos que los soliciten solo cuando sean necesarios, los protejan y expliquen su uso. La duración y disponibilidad del permiso en el navegador pueden variar según el agente de usuario. La guía anterior sobre app nativa o PWA ayuda a elegir el canal de entrega; este contrato de control define lo que debe demostrar cualquier canal elegido.
Haz que las nuevas comprobaciones y los límites dependan de la política
Las nuevas comprobaciones de geolocalización deben activarse según la política aprobada del mercado y los eventos materiales de la sesión, no mediante un único temporizador global incrustado en el código. Entre las posibles entradas figuran el inicio de sesión, la primera apuesta controlada, el vencimiento de la decisión, el tiempo de sesión, la proximidad a un límite, una transición de red, la reanudación de la app o un cambio material en la integridad del dispositivo. Las entradas obligatorias dependen de la jurisdicción.
Pensilvania ofrece un ejemplo útil de por qué importa la configuración. Su norma técnica de geolocalización publicada exige comprobaciones en eventos e intervalos concretos, incluido un tratamiento más frecuente cerca del límite del estado. También aborda polígonos auditados, zonas de amortiguación, métodos de fraude, manipulación de dispositivos, supervisión e informes. Son requisitos de Pensilvania, no un calendario universal.
Modela la respuesta de la plataforma cuando una decisión vence durante una sesión. El acceso a la cuenta, los depósitos, las retiradas, el soporte y las apuestas no tienen por qué compartir una misma regla de elegibilidad. Una decisión de apuesta denegada debe bloquear la acción de juego controlada sin inventar restricciones para funciones de cuenta no relacionadas. Las reglas del mercado y la política del operador deben definir ese límite.
Trata la evidencia de ubicación como entrada sensible y hostil
La evidencia de ubicación debe minimizarse, protegerse y verificarse porque es información sensible suministrada desde un entorno cliente no fiable. La especificación del W3C pide una explicación clara, protección frente al acceso no autorizado y un uso limitado de la información de posición. La documentación de las plataformas también trata la ubicación como información sensible y mantiene el control continuo del permiso en manos de la persona.
El servidor debe autenticar las solicitudes, vincularlas a la sesión correcta, validar marcas de tiempo e identificadores, rechazar repeticiones fuera de la ventana permitida y conservar evidencia suficiente para explicar el resultado. No incluyas coordenadas sin procesar, identificadores de jugadores ni valores de dispositivo de alta cardinalidad en métricas generales. Usa medidas operativas agregadas y evidencia de casos con acceso controlado para la investigación.
La gestión del fraude también necesita resultados explícitos. Los indicadores de proxy, las señales de ubicación simulada, las máquinas virtuales, el software de control remoto, los dispositivos rooteados o con jailbreak y los desplazamientos imposibles pueden contribuir a una decisión cuando las reglas aprobadas lo permitan. Ninguna señal aislada debe convertirse silenciosamente en una acusación universal. Registra qué política combinó qué evidencia y ofrece a operaciones una ruta revisada para falsos positivos y caídas del proveedor.
Diseña los estados de fallo antes que el recorrido ideal
El diseño de fallos de geolocalización debe distinguir la elección del jugador, la capacidad del dispositivo, la calidad de la evidencia, la denegación por política y el fallo del servicio. Combinarlos en un único mensaje genera datos de soporte deficientes y puede fomentar avisos de permiso repetidos que no resuelven la condición real.
Crea una tabla de decisión para cada estado. Indica el mensaje para el jugador, las acciones de cuenta permitidas, la ruta de reintento, el código de soporte, el evento de telemetría y el responsable de escalado. Incluye el modo avión, los servicios del dispositivo desactivados, el acceso aproximado, las coordenadas caducadas, la falta de evidencia de red, el solapamiento con un límite, el tiempo de espera del proveedor, una respuesta malformada, una versión de política incompatible y el vencimiento de la decisión mientras se prepara una apuesta.
La opción predeterminada más segura cuando falta una decisión obligatoria es bloquear la apuesta controlada, conservar el estado de la sesión y explicar la siguiente acción disponible. Eso no equivale a declarar que el jugador está fuera de la jurisdicción. La diferencia importa para el trato al cliente, el análisis de incidentes y la responsabilidad del proveedor.
Exige un paquete de aceptación capaz de reproducir decisiones
Un paquete de aceptación de geolocalización debe permitir que producto, ingeniería, cumplimiento, soporte y el proveedor reproduzcan por qué se permitió o bloqueó una acción controlada. Debe contener la matriz de jurisdicciones, las referencias del polígono y la zona de amortiguación aprobados, los recorridos de permisos, el esquema de evidencia, el contrato de API, el catálogo de estados y códigos de motivo, las versiones de política, las reglas de conservación y acceso, los paneles operativos y las responsabilidades asignadas.
Las pruebas deben cubrir los dispositivos y versiones de sistema operativo compatibles, los canales nativos y web incluidos, los permisos precisos y aproximados, los cambios de configuración, las transiciones de red, los casos de límite, las zonas excluidas, los intentos de repetición, los errores simulados del proveedor y la restauración del servicio. Usa coordenadas y procedimientos de prueba aprobados por el regulador cuando sea necesario. No presentes una prueba con ubicación sintética como evidencia de certificación.
La contratación también debe exigir evidencia de cambios. Un SDK móvil, un conjunto de límites, un modelo de fraude, el comportamiento de permisos del sistema operativo o una política de plataforma pueden cambiar de forma independiente. La respuesta del proveedor debe indicar cómo se identifican las versiones, se prueba la compatibilidad, se controlan los cambios urgentes, funcionan las reversiones y siguen siendo explicables las decisiones históricas.
Para un operador que contrata o sustituye el control de ubicación de una app de casino o apuestas deportivas, usa la matriz de jurisdicciones y la tabla de fallos para definir el alcance de la primera integración mediante un proyecto de desarrollo de aplicaciones. Habla con Wizards sobre los mercados, canales y acciones controladas que debe cubrir el paquete de aceptación.
Preguntas frecuentes
¿Qué debe controlar un sistema de geolocalización iGaming?
Un sistema de geolocalización iGaming debe recopilar evidencia permitida del dispositivo y la red, evaluarla frente a límites y reglas de riesgo aprobados, devolver una decisión con vigencia limitada a la plataforma de juego, conservar un registro explicable y bloquear las apuestas cuando falte o se deniegue la decisión necesaria.
¿Debe una app iGaming decidir si un jugador puede apostar?
Una app iGaming debe presentar los estados de permiso y decisión, pero la plataforma fiable debe decidir si una apuesta puede continuar. El código del cliente y las señales del dispositivo son entradas para esa decisión, no la autoridad final.
¿Cuándo debe comprobar la ubicación una app iGaming?
Una app iGaming debe comprobar la ubicación en los eventos e intervalos exigidos por las reglas aprobadas del mercado y su diseño de riesgo. El inicio de sesión, la primera apuesta, las comprobaciones de sesión, la proximidad a un límite y un cambio material del dispositivo o la red pueden recibir tratamientos distintos. No existe un intervalo universal seguro.
¿Cómo debe gestionar una app la ubicación denegada o aproximada?
La app debe asociar los estados de ubicación denegada, restringida, aproximada, caducada, no disponible y fallida por motivos técnicos con mensajes para el usuario y resultados del servidor distintos. No debe disfrazar una comprobación fallida como un error genérico de inicio de sesión o pago.
¿Puede una dirección IP demostrar la ubicación de un jugador?
Una dirección IP por sí sola no debe considerarse una prueba universal de la ubicación de un jugador. La combinación de evidencias aceptada depende de la jurisdicción y del diseño aprobado, y algunas normas limitan expresamente los datos de IP a una función de apoyo.
¿Qué debe incluir un paquete de aceptación de un proveedor de geolocalización?
Un paquete de aceptación de un proveedor de geolocalización debe incluir la matriz de jurisdicciones, las fuentes de límites, el modelo de evidencia y confianza, el contrato de API, los estados de decisión, los recorridos de permisos, los controles de fraude, las reglas de conservación, la supervisión, los casos de prueba, los ejercicios de fallo, el historial de versiones y los responsables de las excepciones.
