Lectura de 17 minActualizado: 23 de octubre de 2026
Un OTP por SMS es un código de un solo uso que el banco genera en su servidor, envía por mensaje de texto al número que el cliente registró y valida cuando el cliente lo escribe o la app lo lee automáticamente. En México, desde el 2 de septiembre de 2026, la CNBV permite expresamente que ese código se entregue por SMS en las operaciones que los bancos ofrecen a través de comisionistas de base tecnológica, además del correo electrónico y la mensajería instantánea cifrada. Bien diseñado, con vigencia corta, formato compatible con el autocompletado de Android e iOS, límites claros y monitoreo de entrega, el SMS sigue siendo el factor de posesión con mayor alcance que tiene un banco: llega a cualquier celular con línea, sin instalar nada.
Última actualización: octubre de 2026. Esta guía se revisa cuando cambia la regulación o la documentación de las plataformas móviles.
En esta guía
- Qué es un OTP por SMS y cómo funciona el flujo
- Marco regulatorio del OTP por SMS en México
- Buenas prácticas de diseño del OTP por SMS
- Señales de red: un complemento, nunca un reemplazo
- Métricas para medir tu OTP por SMS
- Comparativa de factores de autenticación
- Preguntas frecuentes
Qué es un OTP por SMS y cómo funciona el flujo
OTP significa one-time password: una contraseña dinámica que sirve una sola vez y por un tiempo limitado. En la regulación bancaria mexicana, la definición de Factor de Autenticación en las Disposiciones de carácter general aplicables a las instituciones de crédito incluye, entre sus tipos, la información contenida en dispositivos que posee el usuario, como los mecanismos generadores de contraseñas dinámicas de un solo uso. El SMS es la forma más extendida de hacer llegar esa contraseña: el teléfono del cliente funciona como el “algo que tienes”.
El flujo completo, visto desde la arquitectura, tiene seis pasos:
- Disparo. El cliente inicia una operación que requiere un segundo factor: alta de un dispositivo, una transferencia, un cambio de datos o un inicio de sesión de mayor riesgo.
- Generación. El servidor genera un código aleatorio con un generador criptográficamente seguro, lo asocia a la sesión y a la operación concreta, guarda solo un hash y le pone fecha de vencimiento.
- Envío. El servicio de autenticación arma el mensaje con un formato estable y lo entrega a la plataforma de mensajería, que lo despacha hacia la red móvil y devuelve un identificador para seguir su entrega.
- Entrega y lectura. El mensaje llega al teléfono. Si el formato es el correcto, Android o iOS ofrecen el código para autocompletarlo; si no, el cliente lo copia a mano.
- Validación. El servidor compara el código recibido contra el hash, verifica que no haya vencido, que no se haya usado y que corresponda a esa sesión y a esa operación.
- Cierre. El código queda invalidado, se registra el resultado (éxito, error, vencimiento) y la operación continúa.
Dos detalles hacen la diferencia en producción. El primero: la validación siempre ocurre en el servidor; la documentación de Android lo pide de forma explícita incluso cuando la app lee el mensaje automáticamente. El segundo: el código debe estar ligado a la operación que lo pidió. Un OTP emitido para consultar saldo no debería servir para autorizar una transferencia.
El SMS conserva una ventaja estructural en México: según la ENDUTIH 2025 del INEGI, el 84.6 % de las personas de 6 años y más usó teléfono celular, y el 79.3 % de los usuarios lo hizo solo con contrato de prepago. Un factor que no depende de un plan de datos, de una app instalada ni de un modelo de teléfono específico es, en la práctica, el que permite llegar a toda la base de clientes.
Marco regulatorio del OTP por SMS en México
El cambio más reciente es la “Resolución que modifica las Disposiciones de carácter general aplicables a las instituciones de crédito”, firmada por la CNBV el 24 de agosto de 2026, publicada en el Diario Oficial de la Federación el 1 de septiembre y vigente desde el día siguiente, el 2 de septiembre de 2026. Lo expliqué en detalle cuando salió, en el análisis de la habilitación del SMS para autenticación bancaria; aquí va lo que conviene tener a la mano para diseñar.
Qué modificó la resolución
- Artículo 319 Bis 2. Al definir sus factores de autenticación, el cliente es redirigido a la Infraestructura Tecnológica de la institución, y para recibir el Factor de Autenticación Categoría 3 puede registrar, además del correo electrónico o un servicio de mensajería instantánea con comunicación cifrada, “un número de teléfono móvil habilitado para la recepción de Mensajes de Texto SMS”.
- Artículo 319 Bis 3. Antes de cada operación se informa al cliente que se le solicitará el Factor de Autenticación Categoría 2 (lo que sabe, como su contraseña). Para la consulta de saldos y movimientos, las instituciones pueden requerir únicamente ese Factor Categoría 2.
- Artículo 319 Bis 5. El cliente debe poder modificar su Factor Categoría 2 y el medio de contacto registrado, y la página o la aplicación del comisionista debe tener una opción o enlace explícito para hacerlo.
A qué operaciones aplica
Las reglas modificadas corresponden a los servicios que los bancos ofrecen a través de comisionistas de base tecnológica, el esquema que en el mercado se conoce como banca embebida. Según la cobertura de Expansión y Uno TV, se trata de la apertura de ciertas cuentas de nivel 2 y sus transferencias, créditos de hasta 3,000 UDIS, el pago de bienes y servicios y la consulta de saldos y movimientos. Los considerandos de la resolución la enmarcan en la Política Nacional de Inclusión Financiera 2025-2030 y en ampliar el acceso por canales digitales seguros.
Cómo leerlo en clave de arquitectura
La resolución no sustituye otros mecanismos ni elimina requisitos de seguridad: agrega el SMS como medio de entrega del factor de posesión dentro de un esquema que sigue pidiendo dos factores para operar. Eso tiene tres implicaciones prácticas para tu diseño:
- El número móvil pasa a ser un dato de autenticación, no solo de contacto. Su alta y su cambio merecen el mismo cuidado que un cambio de contraseña, con su propia bitácora.
- El cliente debe poder elegir y cambiar el medio. Tu servicio de OTP tiene que ser multicanal desde el diseño: SMS, correo o mensajería cifrada detrás de la misma interfaz interna.
- La consulta de saldos puede resolverse con un solo factor, lo que libera el OTP para las operaciones donde realmente agrega valor.
Una nota de alcance: esta guía no es asesoría legal. Las disposiciones tienen muchas más reglas sobre medios electrónicos; cada institución debe validar con su área jurídica y de cumplimiento cómo aplican a su modelo.
Buenas prácticas de diseño del OTP por SMS
Después de años operando plataformas de mensajería crítica, mi conclusión es que la experiencia del OTP se decide en detalles pequeños: cuántos dígitos, qué dice el mensaje, cuándo se permite reenviar y qué tan rápido te enteras si algo se retrasa. Estas son las decisiones que recomiendo documentar.
Vigencia, longitud y un solo uso
La referencia técnica más citada es la guía NIST SP 800-63B-4, publicada en agosto de 2025. Para autenticadores fuera de banda pide códigos aleatorios de al menos seis dígitos decimales, considerar inválida la autenticación si no se completa en 10 minutos y aceptar cada código una sola vez. Es un techo razonable; en la práctica, una ventana más corta, alineada con lo que tarda en llegar el mensaje y con los cinco minutos que la API SMS Retriever de Android espera un mensaje, suele dar buen equilibrio entre seguridad y comodidad.
- Seis dígitos numéricos: es el formato que la gente reconoce y el que mejor se lleva con el autocompletado.
- Generación con fuente aleatoria criptográficamente segura, nunca secuencial ni derivada de datos del cliente.
- Almacenamiento como hash, con vencimiento y contador de intentos asociados a la sesión y la operación.
- Invalidación inmediata al usarse, al vencer o cuando se emite un código nuevo para la misma operación.
Formato del mensaje compatible con autocompletado
Que el código se complete solo es la mejora de experiencia con más impacto, y depende casi por completo del texto del mensaje. Hay tres mecanismos que conviene atender al mismo tiempo:
- Android, SMS Retriever. La app lee el mensaje sin pedir permisos de SMS. Google pide que el mensaje no supere 140 bytes, contenga el código e incluya una cadena de 11 caracteres que identifica a la app.
- Web, WebOTP. En el navegador, el mensaje termina con una última línea con el dominio precedido de @ y el código precedido de #, por ejemplo “@banco.ejemplo.mx #482913”. El código va de 4 a 10 caracteres alfanuméricos con al menos un número.
- iOS y macOS. Desde iOS 14 y macOS Big Sur, Apple usa el mismo formato de última línea con dominio para ofrecer el código solo cuando el sitio o un dominio asociado de la app coincide. En la app, el campo usa el tipo de contenido
oneTimeCode; en web,autocomplete="one-time-code".
Un mensaje que cumple con los tres, sin acentos para mantener la codificación de 7 bits y dentro del límite de bytes, puede verse así:
Banco Ejemplo: tu codigo es 482913. Vence en 5 min. FA+9qCX9VSu
@banco.ejemplo.mx #482913
Si tu inicio de sesión vive en un iframe con otro dominio, revisa la documentación de cada plataforma: la especificación de WebOTP y la de Apple usan prefijos distintos para el dominio embebido. Prueba siempre en dispositivos reales, Android y iPhone, antes de cambiar una plantilla. Los cambios recientes del sistema operativo los revisé en qué cambia con Android 17 para el OTP por SMS.
Reintentos y límites
NIST pide limitar los intentos fallidos consecutivos cuando el secreto es corto, con un máximo de 100 antes de bloquear. Para un banco, ese número es un tope, no una meta: lo habitual es definir límites mucho más estrechos en tres niveles.
- Por código: pocos intentos de captura antes de invalidarlo y pedir uno nuevo.
- Por reenvío: un temporizador visible antes de permitir “reenviar”, con espera creciente (por ejemplo, 30, 60 y 120 segundos) y un número máximo de reenvíos por operación.
- Por número y por cliente: un límite de envíos por ventana de tiempo, independiente de la sesión, para proteger la experiencia y el presupuesto de mensajería.
Tras el segundo reenvío, ofrece un canal alterno: OTP por llamada de voz o el medio que el cliente tenga registrado. Así el límite nunca deja al cliente sin salida.
Remitente consistente
El cliente aprende a reconocer de dónde vienen sus códigos. Usa siempre el mismo remitente para OTP, idealmente un código corto dedicado o un identificador estable, y sepáralo del tráfico promocional. Si el remitente va a ser alfanumérico, en la guía del ID de remitente en SMS explico qué reglas aplican en cada país. Escribe el nombre del banco al inicio del mensaje y mantén la plantilla fija: la consistencia ayuda al cliente y al autocompletado. El panorama de los registros de remitentes SMS en la región apunta en esa misma dirección, y la idea de fondo la desarrollé en identidad de las comunicaciones.
Latencia y monitoreo de entrega
El OTP es un mensaje que alguien está esperando con la pantalla abierta, así que la latencia de punta a punta es parte de la experiencia. Recomiendo instrumentar:
- Marcas de tiempo en cada salto: solicitud del OTP, aceptación por la plataforma, envío a la red, confirmación de entrega (DLR) y validación.
- Percentiles, no promedios: el p95 y el p99 de tiempo a entrega son los que reflejan la experiencia de quienes más esperan.
- Desglose por operador móvil, tipo de remitente y franja horaria, con alertas cuando un segmento se aleja de su línea base.
- Correlación entre el identificador del mensaje y la sesión, para saber si un reenvío se pidió antes o después de que llegara el primero.
Separa el tráfico de OTP del masivo, con colas y prioridades propias, y diseña la plataforma con redundancia regional. Escribí sobre esa base en la región de AWS en México y la alta disponibilidad de comunicaciones críticas.
Señales de red: un complemento, nunca un reemplazo
El OTP por SMS confirma que el cliente tiene acceso al número registrado. Las APIs de red agregan contexto sobre la línea antes o durante ese momento. En mayo de 2025, Altán Redes, América Móvil, AT&T México y Telefónica México anunciaron su incorporación a GSMA Open Gateway con tres APIs iniciales: SIM Swap, Device Location y Number Verification, construidas sobre el proyecto abierto CAMARA de la GSMA y la Linux Foundation.
- SIM Swap. Indica si la SIM asociada a un número cambió dentro de un periodo definido, por ejemplo las últimas 24 horas, o devuelve la fecha del último cambio. También admite suscripción a notificaciones.
- Number Verification. Verifica en tiempo real si el número que el cliente declara coincide con el de la línea del dispositivo, a través de su conexión móvil, sin que tenga que leer un código.
El encaje correcto es como señal adicional dentro de una política de riesgo, no como sustituto del factor. NIST sugiere considerar indicadores como cambio de dispositivo, cambio de SIM o portabilidad antes de entregar un secreto fuera de banda. Un diseño razonable consulta SIM Swap antes de enviar el OTP en operaciones sensibles y, si hay un cambio reciente, sube el nivel: pide un factor adicional o un paso de verificación distinto, sin cancelar el SMS. Number Verification puede agilizar el registro del número cuando el teléfono navega con datos móviles, y el OTP por SMS sigue cubriendo los casos con wifi o sin datos.
Estas señales tampoco reemplazan el conocimiento del cliente: una línea registrada a nombre de alguien no dice quién la usa hoy. Lo expliqué en por qué una SIM registrada no es lo mismo que una SIM confiable. Antes de integrarlas, confirma con cada operador su disponibilidad comercial y las condiciones de consentimiento y privacidad.
Métricas para medir tu OTP por SMS
Sin métricas, cada discusión sobre el OTP se vuelve una discusión de opiniones. Este es el tablero mínimo que recomiendo, segmentado por operador móvil, sistema operativo, canal (app o web) y tipo de operación:
- Tasa de verificación: sesiones que completan el OTP sobre sesiones que lo solicitan. Es la métrica principal.
- Tiempo a verificación: desde la solicitud hasta la validación correcta, en p50 y p95.
- Tiempo a entrega: desde el envío hasta la confirmación de entrega, en p50, p95 y p99.
- Tasa de entrega confirmada: mensajes con confirmación de entrega sobre mensajes enviados.
- Tasa de reenvío: sesiones que piden un segundo código. Si sube, algo se está retrasando o la plantilla confunde.
- Tasa de autocompletado: validaciones hechas por SMS Retriever, WebOTP o el autocompletado de iOS frente a captura manual.
- Errores de captura y vencimientos: códigos mal escritos y códigos que vencieron antes de usarse.
- Uso del canal alterno: cuántas sesiones terminan en voz u otro medio, y con qué tasa de éxito.
- Costo por verificación exitosa: gasto total de mensajería dividido entre verificaciones completadas, no entre mensajes.
Una práctica útil: revisar el tablero cada vez que cambias la plantilla, el remitente o la versión de la app. Muchas variaciones en la tasa de verificación se explican por un cambio de texto o de formato.
Comparativa de factores de autenticación
No existe un factor único que sirva para todo. La pregunta útil es qué combinación cubre a toda tu base de clientes con la fricción adecuada para cada operación. Esta tabla resume cómo se complementan:
| Factor | Qué necesita el cliente | Alcance | Experiencia | Dónde encaja mejor |
|---|---|---|---|---|
| OTP por SMS | Un celular con línea activa | Muy amplio: cualquier teléfono, prepago o pospago, sin app ni datos | Familiar; con autocompletado se resuelve en segundos | Factor de posesión general, registro de número, canal alterno universal |
| OTP por voz | Una línea que reciba llamadas | Amplio, incluye teléfonos fijos y personas que prefieren escuchar | Sin autocompletado; útil para accesibilidad | Respaldo cuando el SMS no se recibe a tiempo |
| App o token (OTP generado) | App del banco o token físico activado | Clientes con la app instalada o con token entregado | Funciona sin cobertura una vez activado | Clientes digitales frecuentes, operaciones recurrentes |
| Notificación push | App instalada, sesión activa y datos o wifi | Clientes con la app y notificaciones habilitadas | Un toque para aprobar | Aprobaciones dentro del ecosistema de la app |
| Biometría | Dispositivo con sensor o captura y registro previo | Depende del dispositivo y del enrolamiento | Muy rápida una vez configurada | Desbloqueo local y operaciones desde un dispositivo ya vinculado |
En la práctica, el diseño más robusto combina varios: biometría o push para el día a día en un dispositivo vinculado, y el OTP por SMS como el factor que llega a todos, sirve para vincular dispositivos nuevos y funciona como respaldo cuando el resto no está disponible. Con la resolución de septiembre de 2026, además, el SMS queda reconocido como medio de entrega del Factor Categoría 3 en los servicios a través de comisionistas de base tecnológica.
Preguntas frecuentes
¿La CNBV permite usar OTP por SMS en la banca?
Sí. Desde el 2 de septiembre de 2026, la resolución publicada en el DOF el 1 de septiembre permite que, en los servicios ofrecidos a través de comisionistas de base tecnológica, el Factor de Autenticación Categoría 3 se entregue a un número móvil habilitado para SMS, además del correo y la mensajería cifrada. Cada institución debe validar con su área de cumplimiento cómo aplica a sus demás canales.
¿Cuánto tiempo debe durar un código OTP por SMS?
NIST SP 800-63B-4 fija un máximo de 10 minutos para completar la autenticación fuera de banda. Muchos equipos usan ventanas más cortas, alineadas con el tiempo real de entrega y con los cinco minutos que espera SMS Retriever en Android. Lo importante es que el código sirva una sola vez y se invalide al usarse o al emitir uno nuevo.
¿Cuántos dígitos debe tener un OTP?
Al menos seis dígitos decimales, según NIST SP 800-63B-4, generados con una fuente aleatoria criptográficamente segura. Seis dígitos numéricos es también el formato más reconocible para los clientes y el que mejor funciona con el autocompletado de Android, iOS y los navegadores. Combínalo con un límite estricto de intentos por código.
¿Cómo hago que el OTP se autocomplete en Android y iPhone?
En Android, usa SMS Retriever e incluye en el mensaje la cadena de 11 caracteres de tu app, sin pasar de 140 bytes. Para web e iOS, termina el mensaje con una línea como “@tudominio.mx #123456” y marca el campo con autocomplete=”one-time-code” o el tipo oneTimeCode en apps nativas.
¿Qué hago si el cliente dice que no le llegó el SMS?
Muestra un temporizador antes de permitir el reenvío, ofrece un canal alterno como el OTP por voz tras uno o dos intentos y revisa tus métricas de tiempo a entrega por operador. Correlacionar el identificador de cada mensaje con la sesión te permite saber si llegó tarde, si se reenvió antes de tiempo o si el número registrado debe actualizarse.
¿La consulta de SIM swap sustituye al OTP por SMS?
No. SIM Swap y Number Verification aportan contexto sobre la línea, como un cambio reciente de SIM o la coincidencia del número con el dispositivo. Funcionan mejor como señales dentro de una política de riesgo que decide cuándo pedir un paso adicional, mientras el OTP por SMS sigue siendo el factor de posesión que llega a todos los clientes.
El remitente con el que llega el código también tiene reglas propias en cada mercado: el mapa de registro de remitentes SMS por país resume qué exige cada uno.
Fuentes
- Diario Oficial de la Federación (SIDOF): Resolución que modifica las Disposiciones de carácter general aplicables a las instituciones de crédito (1 de septiembre de 2026).
- Expansión: Los bancos estrenan una nueva forma de confirmar tu identidad por SMS y debes saber cómo funciona (2 de septiembre de 2026).
- Uno TV: Te llegará un código del banco: desde mañana cambian estas reglas de autenticación (1 de septiembre de 2026).
- CNBV: Disposiciones de carácter general aplicables a las instituciones de crédito (texto compilado, consultado en octubre de 2026).
- NIST: SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (26 de agosto de 2025).
- Android Developers: Request SMS Verification in an Android App (actualizado el 28 de septiembre de 2026).
- Google for Developers: Perform SMS Verification on a Server (actualizado el 31 de octubre de 2024).
- Chrome for Developers: Verify phone numbers on the web with the WebOTP API (2019, consultado en octubre de 2026).
- Apple Developer: Enabling AutoFill for domain-bound SMS codes (consultado en octubre de 2026).
- W3C WICG: Origin-bound One-Time Codes Delivered via SMS (24 de marzo de 2021).
- GSMA: Mexico’s mobile industry joins forces to simplify the development of applications and digital services through GSMA Open Gateway (28 de mayo de 2025).
- CAMARA Project: SIM Swap y Number Verification (consultados en octubre de 2026).
- INEGI: Encuesta Nacional sobre Disponibilidad y Uso de Tecnologías de la Información en los Hogares (ENDUTIH) 2025, comunicado de prensa 32/26 (16 de junio de 2026).
¿Estás revisando tu flujo de OTP ahora? Si tu equipo está ajustando plantillas, límites de reenvío o métricas de entrega para aprovechar el cambio de la CNBV, escríbeme: es una conversación que estoy teniendo bastante seguido.
Seguir leyendo
- CNBV habilita SMS para autenticación bancaria — el análisis de la resolución el día que entró en vigor.
- Anexo 71 de la CNBV: biometría con estándares y con plazo — qué exige la CNBV a la verificación biométrica en la banca.
- Banxico homologa el flujo de las transferencias móviles — qué cambia con la Circular 9/2026 para los mensajes al cliente.
- Android 17 y el OTP por SMS — qué revisar en SMS Retriever y WebOTP con la nueva versión.
- SIM registrada no es SIM confiable — por qué las señales de la línea complementan, no sustituyen.
- Identidad de las comunicaciones — el remitente como parte del diseño de seguridad.
- Región AWS México — la base de infraestructura para mensajes que no pueden esperar.
- Padrón de telefonía móvil: qué pasa con el OTP cuando la línea está suspendida — un escenario de no entrega que el flujo de OTP tiene que contemplar.


