# Cómo deben los bancos supervisar la entrega de códigos OTP y el fraude

> Los indicadores clave de rendimiento (KPI) que los bancos necesitan en el panel de control, las señales de fraude que merecen una alerta y el plan de acción operativo para los modos de fallo de la contraseña de un solo uso (OTP) que tienen más probabilidades de generar costes.

- URL canónica: https://www.broadnet.me/es/blog/bank-otp-delivery-monitoring-fraud-playbook
- Idioma: es
- Última actualización: 2026-10-20
- Editor: BroadNet (https://www.broadnet.me)

- Publicado: 2026-04-30
- Autor: BroadNet Industry Research

Para un banco, una OTP no es una notificación. Es un control sobre los flujos de clientes más sensibles a la seguridad: inicio de sesión, confirmación de transacción, adición de beneficiarios, activación de tarjeta, vinculación de dispositivos. El costo de una OTP que no llega es un cliente atrapado; el costo de una OTP que llega pero es interceptada, reutilizada o agotada por sondeos automatizados es una pérdida directa por fraude y una conversación con el regulador. Por lo tanto, los bancos necesitan una práctica operativa de OTP más rigurosa que otros emisores A2P: mejor instrumentación, alertas más agresivas sobre patrones de fraude y un manual documentado para los modos de falla predecibles. Así es como se ve esa práctica.

## Los cinco KPI que deben estar en la pared

La mayoría de los bancos miden la entrega de OTP con un solo número —la «tasa de entrega»—, pero este número casi siempre es erróneo, ya que la tasa de entrega que informa el proveedor de mensajería corresponde a la tasa de éxito del envío, no a la tasa en la que un OTP llegó realmente al cliente que lo utilizó. Cinco números, registrados por canal y por operador de destino, ofrecen una imagen más precisa.

1. Tasa de entrega de extremo a extremo: fracción de solicitudes de OTP en las que el operador de destino devolvió un [DLR](https://www.broadnet.me/answers/what-is-dlr) positivo dentro del período de validez de la OTP. Este es el número real de entregas, no la tasa de aceptación de la solicitud.
2. Latencia p50, p95, p99: envío al terminal, por canal, por operador de destino. Se registra como una serie temporal, no como un valor único; la condición de alerta es la degradación con respecto a una línea base móvil, en lugar de un umbral absoluto.
3. Tasa de reintentos: fracción de solicitudes de OTP que resultaron en un reenvío iniciado por el usuario o por el sistema dentro del período de validez. Un aumento en la tasa de reintentos es la señal más temprana de que la entrega principal se está degradando; casi siempre precede a la caída explícita en la tasa de entrega.
4. Tasa de rechazo de identificador de remitente: fracción de envíos rechazados en el límite del operador por motivos relacionados con el identificador de remitente. Un valor distinto de cero indica un problema de registro; se debe alertar sobre este problema con tolerancia cero.
5. Tasa de finalización de OTP: fracción de solicitudes de OTP en las que el usuario introdujo el código correctamente. Este es el único KPI relevante desde el punto de vista comercial; todo lo demás influye en él. Una tasa de entrega del 99 % junto con una tasa de finalización del 70 % indica que el mensaje llegó demasiado tarde o que la experiencia de usuario para introducir el código es deficiente; la entrega sin finalización no es un éxito.

## Las señales de fraude que merecen ser alertadas

La infraestructura de OTP también constituye una superficie de ataque para este sistema. Existen tres categorías comunes de abuso, todas detectables a partir de los datos que el banco ya recopila.

### 1. Solicitudes repetidas de OTP para el mismo MSISDN

Un atacante que sondea el flujo de OTP en una sola cuenta, ya sea manualmente o mediante un script, genera una firma característica: numerosas solicitudes de OTP para un mismo número de teléfono, a menudo agrupadas en un corto intervalo de tiempo, a veces con direcciones IP o cadenas de agente de usuario rotativas en la sesión de origen. El equivalente legítimo (un usuario que realmente no puede encontrar el código) no supera los tres a cinco intentos en pocos minutos; un perfil de ataque implica decenas o cientos de intentos. Los umbrales de alerta deben ser estrictos: más de diez solicitudes de OTP para un MSISDN en quince minutos casi siempre indican un ataque o una integración defectuosa, y ambos requieren atención.

### 2. Anomalías geográficas y de comportamiento

Una solicitud de OTP desde una sesión originada en un país, para un número de teléfono históricamente asociado con otro país, no necesariamente indica fraude (podría tratarse de un cliente de viaje), pero conviene reforzar la autenticación en lugar de aceptarla sin más. Si a esto le sumamos cambios en la huella digital del dispositivo (nuevo navegador, nuevo ID de dispositivo, nueva instalación de aplicación), la señal es más clara. El sistema de gestión de riesgos del banco ya debería realizar esto para la autorización de transacciones; extenderlo a la emisión de OTP supone una mejora inmediata.

### 3. Enumeración limitada y relleno de credenciales

Un atacante más sofisticado enumera los identificadores de cuenta a través del flujo de recuperación de contraseña, manteniéndose deliberadamente por debajo del límite de OTP por cuenta, pero sondeando muchas cuentas en paralelo. La firma es una alta tasa de solicitudes de OTP en muchos MSISDN distintos desde un rango de origen pequeño, a menudo con recuentos individuales bajos por MSISDN que pasan desapercibidos para las alertas por cuenta. La detección requiere la agregación a través de orígenes de origen (IP, clase de dispositivo, patrón de sesión) en lugar de por cuenta. Este es exactamente el patrón de los ataques de [bombeo de SMS](https://www.broadnet.me/answers/what-is-sms-pumping) que algunos atacantes ejecutan contra la infraestructura de OTP para monetizar los reembolsos por mensaje del proveedor; protegerse contra esto protege simultáneamente contra el fraude y la inflación de costos del proveedor.

## El manual operativo para los modos de fallo predecibles

En todos los bancos se repiten tres tipos de incidentes relacionados con la contraseña de un solo uso (OTP). Contar con un plan de acción escrito para cada uno —y no con un manual improvisado bajo presión— permite resolver el problema en 15 minutos, en lugar de en 4 horas.

### Manual de procedimientos 1: degradación de la ruta del operador de destino

Señal: la latencia p95 aumenta en un operador de destino específico mientras que los demás se mantienen estables, y la tasa de entrega a ese operador disminuye. Acción: confirmar que la degradación se produce en el lado de la ruta y no internamente (la aceptación de envíos sigue siendo del 100%), redirigir el tráfico OTP de ese operador a la ruta secundaria en el motor de enrutamiento, notificar al NOC del proveedor para su confirmación y tiempo estimado de recuperación. Recuperación: una vez que las métricas de la ruta principal vuelvan a la línea base durante 30 minutos, restaurar. El manual completo debe constar de diez líneas y practicarse trimestralmente.

### Plan de acción 2: pico de rechazo de identificador de remitente

Señal: la tasa de rechazo de ID de remitente aumenta de cero a un valor distinto de cero, casi siempre para un mercado de destino. Acción: verificar si el registro del ID de remitente ha caducado o ha sido revocado por el regulador de destino (causa más común), confirmar con el agregador local, recurrir a un ID de remitente registrado de respaldo para el mercado afectado si está disponible, escalar el registro. El tiempo de recuperación lo determina el regulador, no el banco; la función del plan de acción es limitar el impacto durante la espera.

### Plan de acción 3: ataque coordinado de bombeo de OTP

Señal: el costo por OTP exitosa aumenta drásticamente; el volumen de envíos a rangos de números específicos (a menudo adyacentes a tarifas premium o prefijos de países específicos) aumenta bruscamente; la tasa de finalización de esos envíos es casi cero. Acción: habilite la lista de prefijos de destino permitidos si aún no está activada (este es el control más efectivo), limite la emisión de OTP desde las rutas de origen afectadas, comuníquese con el equipo de fraude del proveedor de mensajería. Recuperación: desactive la lista de prefijos permitidos una vez que cese el ataque; para la mayoría de los bancos no es seguro mantenerla deshabilitada permanentemente. Consulte [HLR Lookup pre-flight](https://www.broadnet.me/products/hlr-lookup) como una mitigación estructural contra esta clase.

## Opciones arquitectónicas que hacen posibles los manuales de estrategias

Los planes de acción dependen, sobre todo, de decisiones arquitectónicas tomadas antes del incidente, no de improvisaciones durante el mismo. Tres de ellos merecen una atención especial.

- OTP multicanal desde el primer día: como mínimo SMS y voz; idealmente SMS, plantilla de autenticación de WhatsApp y voz con conmutación por error automática documentada. La conmutación por error es un control, no una solución de reserva; debe poder invocarse por ruta y por categoría sin necesidad de modificar el código.
- Telemetría de entrega y latencia por canal y por operador: sin ella, los paneles de control anteriores son meramente aspiracionales. Los datos deben provenir del proveedor de mensajería en formato DLR estructurado, no como informes mensuales en PDF.
- Inventario documentado de identificadores de remitente con fechas de renovación: el equipo de cumplimiento del banco debería ser el responsable de este registro, no el proveedor de mensajería; las fallas causadas por la falta de atención del proveedor en la renovación siguen siendo problema del banco cuando deja de llegar tráfico.

## Hablar con el proveedor: qué datos deberían retroceder

Un contrato de mensajería de nivel bancario especifica los datos operativos que devuelve el proveedor, no solo el esquema de precios unitarios. Espere, como mínimo:

- Webhooks DLR en tiempo real que el banco pueda autenticar (por ejemplo, una [firma HMAC-SHA256](https://www.broadnet.me/answers/hmac-sha256-dlr-signing) con secreto compartido si el proveedor firma las devoluciones de llamada, o una lista de IP permitidas) para que el banco pueda conciliar los envíos con la entrega real en su propio SIEM.
- Informes diarios de entrega y latencia desglosados por operador de destino, ID del remitente y ruta, aptos para su incorporación al sistema de observabilidad del banco.
- Resúmenes mensuales de incidentes con cronograma, causa raíz y medidas de mitigación para cualquier incidente del lado del proveedor que haya afectado el tráfico del banco.
- Contactos directos para la escalada de problemas en el centro de operaciones de red (NOC) y el equipo de fraude del proveedor, con un acuerdo de nivel de servicio (SLA) que establece tiempos de respuesta específicos.

> El servicio OTP de BroadNet (/products/otp) envía análisis de entrega, latencia y finalización por canal y por operador como flujos estructurados, y la misma capa de detección de fraude que protege al operador está disponible para los clientes empresariales de OTP como puntuación previa al envío de las solicitudes antes de que se conviertan en envíos facturables.

## Preparación para la regulación: la dimensión que a menudo se pasa por alto.

Los bancos centrales y los reguladores de servicios financieros formulan cada vez más preguntas explícitas sobre la infraestructura de entrega de OTP durante las inspecciones: ¿cuál es el SLA?, ¿cuál es el sistema de conmutación por error?, ¿cuál es el registro de auditoría?, ¿cómo se detectan y responden los patrones de fraude? Los bancos que pueden responder en cinco minutos a partir de un expediente operativo estándar superan la inspección sin problemas; los que tienen que elaborar la respuesta en medio de la misma no. Los KPI y los manuales de procedimientos mencionados anteriormente son los insumos para dicho expediente; considérelos tanto documentos de cumplimiento como documentos operativos.

## Un antipatrón común para retirarse

Muchos bancos integran la OTP como una función del servicio de autenticación, en lugar de como un sistema propio. El resultado: la integración de mensajería es responsabilidad de quien creó el flujo de autenticación originalmente, a menudo alguien que ya no trabaja en el mismo equipo; nadie presta atención a la telemetría de entrega por operador; el primer indicio de degradación es un pico en la atención al cliente que el equipo de soporte no puede vincular a un problema de mensajería. La solución es estructural: un responsable designado para la infraestructura de OTP con un pequeño equipo permanente (o un equipo de socios claramente definido), una revisión trimestral del panel de KPI y un ejercicio anual integral de los manuales de procedimientos mencionados anteriormente frente a un escenario de incidente realista. Todos los proveedores de mensajería para bancos institucionales realizan revisiones conjuntas trimestrales con sus clientes como parte del acuerdo; si el suyo no lo hace, solicítelo.

## Cómo se ve el éxito, en números.

Una infraestructura de OTP bancaria bien gestionada, que envía a un mercado regulado del CCG a través de rutas directas del operador, con la cadena de reserva y los controles de fraude descritos anteriormente, debería alcanzar: una tasa de finalización de extremo a extremo superior al 99 % (no solo la entrega, sino que el cliente realmente se haya verificado), una latencia p95 inferior a cinco segundos en el canal principal, una tasa de rechazo de ID de remitente del cero, una tasa de reintentos inferior al 3 % (por encima de la cual la experiencia del usuario y el coste se degradan) y un bloqueo de solicitudes de OTP relacionadas con el fraude inferior al 1 % del tráfico legítimo (los falsos positivos importan; un bloqueo demasiado agresivo es su propio problema de experiencia del cliente). Los bancos que se encuentran muy por debajo de estas cifras tienen una o más de las siete causas de fallo en la [guía de solución de problemas de entrega de OTP](https://www.broadnet.me/blog/why-otp-messages-fail-delivery-troubleshooting) en producción; diagnostique antes de ajustar.

## Lecturas relacionadas

- [Por qué fallan los mensajes OTP y cómo solucionar los problemas de entrega](https://www.broadnet.me/blog/why-otp-messages-fail-delivery-troubleshooting)
- [Cómo afecta la verificación de llamadas instantáneas a los ingresos A2P de los operadores](https://www.broadnet.me/blog/flash-call-verification-operator-a2p-revenue-impact)
- [Estrategia de mensajería omnicanal para comercio electrónico y logística](https://www.broadnet.me/blog/omnichannel-messaging-ecommerce-logistics-strategy)
- Glosario — [¿Qué es OTP?](https://www.broadnet.me/answers/what-is-otp), [¿Qué es el envío masivo de SMS?](https://www.broadnet.me/answers/what-is-sms-pumping), [¿Qué es un DLR?](https://www.broadnet.me/answers/what-is-dlr)
- Páginas de productos: [Servicio OTP](https://www.broadnet.me/products/otp) y [OTP de voz MyOTP](https://www.broadnet.me/products/myotp)
- Cobertura — [Enrutamiento compatible con OTP y TDRA en los EAU](https://www.broadnet.me/coverage/uae)