Las redes móviles exponen señales que pueden reforzar la seguridad de las cuentas, pero la respuesta del operador no es una decisión completa de identidad. Trata las API de red como datos sensibles, autorizados por el usuario y sujetos a fallos, dentro de una política de riesgo más amplia.
GSMA Open Gateway alinea capacidades de red de operadores con API estandarizadas desarrolladas en el proyecto open source CAMARA. El objetivo es ofrecer interfaces más coherentes, a menudo mediante un agregador. Hay despliegues activos en Europa, pero la cobertura, disponibilidad comercial, versiones y experiencia del usuario dependen del mercado. Comprueba siempre el catálogo y perfil actuales del proveedor.
Number Verification de CAMARA puede confirmar si el número indicado por la aplicación coincide con el asociado a la sesión móvil autenticada. El flujo usa autenticación por red/SIM en vez de enviar una contraseña de un solo uso por SMS. Puede reducir la exposición a la interceptación de OTP, pero no demuestra que la persona sea titular legítima de la cuenta ni sustituye autenticación resistente al phishing en operaciones críticas.
Las API CAMARA SIM Swap pueden proporcionar información sobre un cambio reciente de SIM, aunque las operaciones y su precisión dependen de la versión y el proveedor. Algunos perfiles permiten consultar una ventana temporal o una banda normalizada de antigüedad en vez de revelar la hora exacta. Utiliza la opción menos reveladora que permita evaluar el riesgo.
No llames a una API de red con solo un número telefónico y un token de servicio duradero como si la intervención del usuario no importara. Las definiciones actuales de Number Verification exigen un contexto autorizado por el usuario para las operaciones documentadas; el perfil para obtener el token puede variar según versión y operador. Sigue el perfil de seguridad e interoperabilidad CAMARA y sus directrices de identidad y consentimiento. Comprueba si la persona usa datos móviles o si existe una alternativa admitida; la autenticación silenciosa no funciona en cualquier dispositivo, Wi-Fi o situación de roaming.
Separa las credenciales de cliente que identifican tu aplicación de la autorización delegada que representa el consentimiento del usuario. Vincula tokens a audiencia y scopes, limita su vida, no registres bearer tokens y no aceptes un número enviado por el cliente como prueba de identidad de red. Valida state, nonce y vinculación de transacción en el callback.
| Señal | Interpretación útil | No infieras |
|---|---|---|
| Coincidencia de número | La sesión autenticada por red se asocia al número indicado según la semántica de la API. | Que el usuario puede realizar cualquier acción o que su dispositivo esté libre de malware. |
| Cambio reciente de SIM | Factor que puede elevar el riesgo de apropiación de cuenta en una transacción sensible. | Fraude: los cambios legítimos existen y cobertura/tiempos pueden variar. |
| No disponible / timeout | Operador o agregador no respondió a tiempo. | Un resultado negativo; distingue “desconocido” de “no coincide”. |
| Ubicación o alcance | Contexto para un uso limitado cuando API y permiso lo permiten. | Permiso de seguimiento continuo o prueba de presencia sin evaluar precisión. |
Envía las señales a un motor de riesgo con resultados calibrados: permitir, exigir un factor más fuerte, retener para revisión manual o denegar según una política documentada. Un cambio reciente de SIM podría activar una reautenticación con passkey o retrasar un pago de alto riesgo; no debería bloquear automáticamente a todos. Mide falsos positivos, fricción de recuperación y pérdidas por fraude evitando proxies discriminatorios y retención excesiva.
La estandarización Open Gateway reduce diferencias de integración, pero no las elimina. Participación de operadores, versión, modos de autenticación, formatos de número, cobertura, cuotas, latencia, errores y condiciones comerciales pueden variar. Encapsula adaptadores tras un contrato interno estable, fija versiones y valida OpenAPI en CI. Trata extensiones del proveedor como capacidades explícitas, no como comportamiento universal.
| Fallo | Comportamiento backend | Observabilidad |
|---|---|---|
| Timeout del operador | Limita reintentos, activa circuit breaker y continúa con un factor alternativo seguro. | Latencia por proveedor, timeouts y resultado del fallback. |
| Consentimiento o token inválido | Detén la consulta y reinicia un flujo autorizado, sin repetir con credencial de servicio. | Clase de error, scope y etapa; nunca el token. |
| Formato de número incompatible | Normaliza según país y plan explícitos; rechaza ambigüedad. | Errores de validación por región y ruta. |
| Señal ausente u obsoleta | Devuelve “desconocido” y aplica step-up según la transacción. | Proporción de desconocidos, frescura y abandono tras step-up. |
| El agregador cambia el perfil | Falla en pruebas de contrato antes del despliegue; migra versión deliberadamente. | Diff de esquema, release y estado de pruebas. |
Pondría un gateway de capacidades telecom detrás de la plataforma de autenticación y fraude. Expondría un endpoint interno acotado, lo mapearía a la versión CAMARA del proveedor, obtendría solo el token autorizado por el usuario, impondría un timeout estricto y devolvería una señal normalizada mínima con procedencia: proveedor, versión, ID de correlación, momento y frescura. No devolvería ni guardaría el número de teléfono salvo necesidad explícita.
El motor de riesgo combinaría el resultado con passkey, reputación del dispositivo, antigüedad de la cuenta, importe y cambios recientes. La política distinguiría “coincide”, “no coincide”, “cambio reciente”, “no soportado” y “proveedor no disponible”. Un panel compararía fraude evitado, step-ups falsos positivos, coste, latencia y frecuencia del fallback. Ejecutaría pruebas sintéticas por ruta de operador y ejercicios de caos para caídas del agregador.
Open Gateway y CAMARA facilitan capacidades de red mediante patrones comunes, pero no convierten señales telecom en verdad de identidad. Usa autorización explícita, scopes mínimos, pocos datos, contratos por versión y fallback resiliente. Combina evidencia de red con autenticadores sólidos y contexto transaccional; conserva “desconocido” como resultado real, sin transformar una caída en aprobación o fraude.
Nota editorial: La madurez de las API y la cobertura de operadores cambian. Este artículo refleja materiales públicos de GSMA/CAMARA consultados el 28 de septiembre de 2026; confirma versión, disponibilidad comercial, consentimiento y base jurídica con el proveedor y asesoría cualificada.