Durante años, verificar que un número de teléfono realmente pertenece a la persona que dice tenerlo lo resolvimos con un rodeo: mandar un código y pedir que lo escriba. Funciona. Pero es un rodeo. Las Network APIs de GSMA Open Gateway, estandarizadas en el proyecto CAMARA, empiezan a resolverlo de otra manera: preguntándole a la red, que es quien realmente sabe.
Este artículo es una lectura práctica de qué hacen esas APIs, cuáles importan de verdad para servicios críticos y —lo que casi nunca se dice— cómo diseñar un flujo de autenticación que las aproveche sin depender de ellas.
Qué es Open Gateway y por qué CAMARA importa
Open Gateway es la iniciativa de la GSMA para que los operadores móviles expongan capacidades de red mediante APIs comunes. CAMARA es el proyecto open source donde esas APIs se estandarizan. La diferencia con el modelo anterior es el punto central: antes, cada operador exponía lo suyo a su manera; el objetivo ahora es que una misma integración sirva en múltiples operadores y mercados.
Para quienes construimos plataformas de comunicaciones, el cambio de fondo es más profundo que el catálogo: la red pasa de ser el medio por donde viaja el mensaje a ser también una fuente de señales de confianza sobre quién está del otro lado.
Las dos que más mueven la aguja en autenticación
SIM Swap
Permite consultar si hubo un cambio reciente de SIM asociado a un número. Es la respuesta directa a uno de los vectores de fraude más usados en autenticación: portar o duplicar una línea para interceptar los códigos que llegan por SMS.
El cambio conceptual es importante. Hasta ahora, el número de teléfono se trataba como un dato fijo del expediente del cliente: se validaba una vez, al alta, y quedaba ahí. Consultar el estado de esa línea en el momento en que se la va a usar convierte al número en una señal viva. No es lo mismo enviar un OTP a una línea estable desde hace cuatro años que a una cuya SIM cambió hace seis horas.
Number Verification
Permite verificar el número del dispositivo conectado sin pedirle nada al usuario. Sin código, sin escritura, sin fricción. Cuando el dispositivo está sobre la red móvil, el operador confirma que la sesión corresponde a ese número.
El impacto en conversión es real: cada paso que se le pide a un usuario en un alta o en un login tiene abandono asociado. Eliminar el tipeo del código no es una mejora cosmética.
El catálogo completo es más amplio
- Device Location Verification — confirmar si el dispositivo está dentro de un área determinada, sin exponer coordenadas exactas.
- Device Status / Roaming — tipo de red, estado de roaming y alcanzabilidad del dispositivo.
- Scam Signal — señales de posible estafa en curso, útiles cuando el fraude combina llamada y mensaje.
- KYC Match — validación de datos del cliente contra los registros del operador, sin transferir el dato completo.
- Quality on Demand — priorización de tráfico, más relevante para voz y video que para mensajería.
La parte realista: la cobertura es despareja
Acá está lo que muchas presentaciones omiten. La disponibilidad de cada API depende de cada operador y de cada mercado, y hoy es irregular. Un flujo diseñado asumiendo que la señal siempre va a estar disponible se rompe el día que el operador del usuario no la expone, o que la consulta devuelve un error, o que el tiempo de respuesta se degrada.
Es una capa adicional de confianza, no un reemplazo.
Cómo diseñar el flujo para que sume y no rompa
Mi recomendación, después de integrar varias capas de verificación sobre servicios que no se pueden detener, es tratar la señal de red como un modificador de riesgo, no como una compuerta.
- Consulta no bloqueante con presupuesto de tiempo. Si la respuesta no llega en el plazo que el flujo tolera, se continúa con el mecanismo tradicional. Un timeout nunca debe dejar al usuario sin poder autenticarse.
- Tres resultados posibles, no dos. Señal positiva, señal negativa y señal no disponible. Ese tercer estado es el que más se olvida en el diseño y el que más aparece en producción.
- Acción proporcional al riesgo. Un SIM swap reciente no tiene por qué bloquear la operación: puede escalar a un segundo factor distinto, demorar una operación sensible o exigir intervención humana.
- Registro de la señal en la traza. Si la decisión de riesgo se apoyó en una consulta de red, esa consulta y su resultado deben quedar auditables. En un entorno regulado, una decisión que no se puede reconstruir es una decisión que no existió.
- Degradación explícita, no silenciosa. Si la API está caída para un operador entero, alguien tiene que enterarse. Métrica y alerta, no un catch vacío.
Qué no resuelven las Network APIs
Conviene ser honesto sobre los límites. Las señales de red dicen algo sobre la línea y el dispositivo, no sobre la persona. Un atacante con acceso físico al teléfono desbloqueado pasa Number Verification sin problema. Un fraude de ingeniería social en el que la víctima autoriza la operación también pasa.
Y quedan los escenarios sin red móvil: un usuario sobre wifi, un dispositivo de escritorio, una línea de un operador que no expone la API. Ninguno es marginal.
Por eso la conclusión práctica es la de siempre en arquitectura: una capa más no reemplaza a las anteriores. Suma cuando está y no debe restar cuando falta.
Por dónde empezar si todavía no lo evaluaron
- Identificar los dos o tres flujos donde un fraude de SIM swap tendría mayor impacto económico. Normalmente son alta de beneficiario, cambio de credenciales y transferencia de monto alto.
- Medir hoy, sin ninguna API, qué porcentaje del tráfico de esos flujos viene de líneas con alta reciente. Ese número suele sorprender.
- Consultar la cobertura real de SIM Swap en los operadores que concentran tu base. Si cubre el 70% del tráfico, ya justifica el diseño.
- Definir la política de acción antes de integrar. Qué se hace con un SIM swap de 24 horas, de 7 días y de 30 días no es una decisión técnica: es de riesgo.
¿Ya están evaluando Network APIs en sus flujos de autenticación, o el número de teléfono sigue siendo un dato fijo del expediente?