Redes móveis expõem sinais que podem reforçar a segurança de contas, mas a resposta da operadora não é uma decisão completa de identidade. Trate APIs de rede como entradas sensíveis, autorizadas pelo usuário e sujeitas a falhas, dentro de uma política de risco mais ampla.
GSMA Open Gateway aproxima capacidades de rede de APIs padronizadas desenvolvidas no projeto open source CAMARA. A proposta é permitir que desenvolvedores acessem recursos das operadoras por interfaces mais consistentes, muitas vezes por meio de um agregador. Há implantações ativas na Europa, mas cobertura, oferta comercial, versões e jornadas do usuário variam por mercado. Consulte sempre o catálogo e o perfil atuais do provedor.
Number Verification da CAMARA pode confirmar se o número informado pela aplicação corresponde ao associado à sessão móvel autenticada. O fluxo usa autenticação pela rede/SIM, sem enviar senha de uso único por SMS. Isso reduz exposição à interceptação de OTP, mas não prova que a pessoa é dona legítima da conta nem substitui autenticação resistente a phishing em operações críticas.
As APIs CAMARA de SIM Swap podem informar uma troca recente de SIM, mas operações e precisão dependem da versão e do provedor. Alguns perfis oferecem consulta por janela temporal ou banda padronizada de recência, em vez do horário exato. Use a opção menos reveladora que ainda permita decidir o risco.
Não chame uma API de rede usando apenas um número de telefone e token de serviço duradouro como se a participação do usuário fosse irrelevante. As definições atuais de Number Verification exigem contexto autorizado pelo usuário para as operações documentadas; o perfil de aquisição de token varia entre versões e operadoras. Siga o perfil de segurança/interoperabilidade CAMARA e as orientações de identidade e consentimento. Confirme se a pessoa está em dados móveis ou se existe fluxo alternativo suportado; autenticação silenciosa não funciona necessariamente em todo aparelho, Wi-Fi ou cenário de roaming.
Separe credenciais de cliente que identificam seu aplicativo da autorização delegada que representa o consentimento do usuário. Vincule tokens a audiência e escopos, limite sua duração, nunca registre bearer tokens e não aceite número enviado pelo cliente como prova de identidade pela rede. Valide state, nonce e vínculo com a transação no callback.
| Sinal | Interpretação útil | Não conclua |
|---|---|---|
| Correspondência de número | A sessão autenticada pela rede está associada ao número informado, segundo a semântica da API. | Que a pessoa pode realizar qualquer ação ou não tem malware. |
| Troca recente de SIM | Fator que pode elevar risco de tomada de conta em transação sensível. | Fraude: trocas legítimas existem e cobertura/tempo variam. |
| Indisponível / timeout | Operadora ou agregador não respondeu no prazo. | Resultado negativo; diferencie “desconhecido” de “não corresponde”. |
| Localização ou alcance | Contexto para caso restrito, quando API e permissão permitem. | Permissão para rastreamento contínuo ou prova de presença sem avaliar precisão. |
Envie sinais a um motor de risco com resultados calibrados: permitir, exigir fator mais forte, reter para revisão ou negar por política documentada. Uma troca recente pode solicitar reautenticação por passkey ou atrasar um saque de alto risco; não deve bloquear automaticamente todos. Acompanhe falsos positivos, fricção de recuperação e perdas por fraude sem criar proxies discriminatórios ou reter dados em excesso.
Padronização reduz diferenças de integração, mas não as elimina. Participação de operadoras, versão, modos de autenticação, formatos de número, cobertura, cotas, latência, erros e termos comerciais variam. Coloque adaptadores atrás de contrato interno estável, fixe versões e valide OpenAPI em CI. Trate extensões do fornecedor como capacidades explícitas, não garantias universais.
| Falha | Comportamento backend | Observabilidade |
|---|---|---|
| Timeout da operadora | Limite retries, use circuit breaker e siga com fator alternativo seguro. | Latência por provedor, timeout e resultado de fallback. |
| Consentimento/token inválido | Pare e reinicie fluxo autorizado, sem repetir com credencial de serviço. | Classe do erro, escopo e etapa; nunca valor do token. |
| Formato de número divergente | Normalize por país/plano explícito; rejeite ambiguidade. | Falhas por localidade e rota. |
| Sinal indisponível ou antigo | Retorne “desconhecido” e aplique step-up específico à transação. | Frequência de desconhecidos, atualidade e abandono. |
| Agregador muda perfil | Falhe nos testes de contrato antes do rollout; migre versão deliberadamente. | Diff de schema, release e testes de integração. |
Colocaria um gateway de capacidades telecom atrás da plataforma de autenticação e fraude. Ele exporia endpoint interno estreito, mapearia para a versão CAMARA do provedor, obteria somente token autorizado pelo usuário, imporia timeout rígido e retornaria sinal mínimo normalizado com procedência: provedor, versão, ID de correlação, horário e atualidade. Não retornaria nem persistiria número de telefone sem necessidade explícita.
O motor de risco combinaria o resultado com passkey, reputação do dispositivo, idade da conta, valor da transação e mudanças recentes. A política distinguiria “corresponde”, “não corresponde”, “alteração recente”, “não suportado” e “provedor indisponível”. O painel compararia fraude evitada, step-ups falsos positivos, custo, latência e frequência de fallback. Execute testes sintéticos por rota de operadora e exercícios de caos para falha do agregador.
Open Gateway e CAMARA facilitam o acesso a capacidades de rede com padrões comuns, mas não transformam sinais de telecom em verdade de identidade. Use autorização explícita, escopos mínimos, poucos dados, contratos por versão e fallback resiliente. Combine evidências da rede com autenticadores fortes e contexto da transação; preserve “desconhecido” como resultado real, sem converter falha em aprovação ou fraude.
Nota editorial: Maturidade e cobertura de operadoras mudam. Este artigo reflete materiais públicos GSMA/CAMARA consultados em 28 de setembro de 2026; confirme versão, disponibilidade comercial, consentimento e base legal com o provedor e assessoria qualificada.