Lectura de 9 minActualizado: 24 de octubre de 2026
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 —entre ellas SIM Swap y Number Verification—, 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 el SIM swap
El SIM swap (también llamado SIM swapping o duplicado de SIM) es el cambio de la tarjeta SIM asociada a un número móvil. En la mayoría de los casos es un trámite legítimo: un teléfono nuevo, una SIM dañada o el paso a una eSIM. El problema aparece cuando un tercero logra que el número quede en una SIM que controla él, porque desde ese momento recibe las llamadas y los mensajes de esa línea.
Por eso el dato útil para una plataforma de autenticación no es “hubo un cambio de SIM” a secas, sino cuándo ocurrió. Un cambio de hace dos años no dice nada; uno de hace pocas horas, justo antes de una operación sensible, merece un paso extra de verificación. Esa es exactamente la pregunta que responde la API SIM Swap de CAMARA: devuelve la fecha del último cambio o un sí/no para un periodo definido, por ejemplo las últimas 24 horas.
Del lado de la persona, las recomendaciones de prevención son conocidas: activar el PIN de la SIM, revisar los movimientos desde la app del banco y, si el teléfono se queda sin servicio de forma inesperada, comunicarse de inmediato con la compañía telefónica. Del lado de la plataforma, la consulta a la red permite actuar antes de que la persona note algo raro.
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
- Location Verification — confirmar si el dispositivo está dentro de un área determinada, sin exponer coordenadas exactas.
- Device Roaming Status y Device Reachability Status — estado de roaming y alcanzabilidad del dispositivo.
- Scam Signal — señales de posible estafa en curso, útiles cuando el fraude combina llamada y mensaje. Está en el catálogo de GSMA Open Gateway, pero no se publica en CAMARA.
- Know Your Customer Match (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
Aquí 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?
Preguntas frecuentes sobre SIM swap y Network APIs
¿Qué es el SIM swap?
Es el cambio de la tarjeta SIM vinculada a un número de teléfono. Puede ser un trámite normal (equipo nuevo, eSIM, SIM dañada) o un intento de un tercero de quedarse con la línea para recibir sus mensajes y llamadas.
¿Cómo sabe un banco si hubo un cambio de SIM?
Consultando al operador. Con la API SIM Swap de GSMA Open Gateway y CAMARA, la plataforma pregunta por un número y recibe la fecha del último cambio de SIM o una respuesta sí/no para un periodo, sin pedirle nada a la persona.
¿La API SIM Swap reemplaza al OTP?
No. Lo complementa: la consulta se hace antes de enviar el código y ayuda a decidir si alcanza con el OTP o si conviene sumar otro factor. Number Verification, en cambio, sí puede reemplazar el código en algunos flujos cuando el dispositivo está sobre la red móvil.
¿Está disponible en México?
La disponibilidad depende de cada país y de cada operador. GSMA publica el estado de lanzamiento por mercado; antes de diseñar un flujo que dependa de la API conviene confirmar la cobertura con el proveedor y prever qué hacer cuando la red no responde.
Actualización de septiembre de 2026: cómo se está acomodando el mercado
El cuello de botella de estas APIs nunca fue técnico, sino comercial: cada operador expone lo suyo y nadie quiere integrar cuatro contratos por país. Durante 2026 quedó claro por dónde se resuelve.
- Los agregadores se consolidaron como la puerta de entrada práctica. La foto del mercado que publicó GSMA Intelligence en 2026 muestra el movimiento hacia ese modelo, en lugar de integraciones operador por operador.
- En agosto, IBM Consulting se sumó a la iniciativa, una señal de que la integración empieza a venderse como proyecto y no solo como API.
- En México, los cuatro operadores adhirieron a Open Gateway en 2025 con SIM Swap, Device Location y Number Verification como APIs iniciales. Entre agosto y septiembre de 2026 no encontré anuncios de nuevas APIs locales.
Para el diseño, esto refuerza lo que planteo más arriba: la señal se consulta a través de una capa propia que abstrae al proveedor, con respuesta por defecto cuando la señal no está disponible y con el costo de cada consulta medido por operación. Si mañana cambia el agregador, cambia una integración, no el flujo de autenticación.
Fuentes
- GSMA: What is GSMA Open Gateway?.
- GSMA: GSMA Open Gateway API descriptions.
- CAMARA, Linux Foundation: CAMARA Project.
- INAI, publicada en el micrositio de ciberseguridad del IFT: Guía para prevenir el robo de identidad (SIM swapping).
- CAMARA: SIM Swap API.
- CAMARA: Number Verification API.
Seguir leyendo
- Guía: OTP por SMS en la banca de México — la referencia completa: regulación, diseño del mensaje, límites, señales de red y métricas.
- Una SIM registrada no es una SIM confiable — por qué el padrón de titulares no alcanza como control.
- Identidad de las comunicaciones: la superficie de seguridad que dejamos sin resolver — cómo se resuelve la identidad de quien envía.
- Registro de remitentes SMS en España, Costa Rica y Colombia — qué exige cada esquema y qué protege de verdad.
