En el segundo semestre de 2024, el Banco de España registró un incremento sostenido de las reclamaciones por cargos no reconocidos vinculados a comunicaciones fraudulentas suplantando entidades financieras. La mayoría de los afectados habían recibido un SMS aparentemente legítimo, con el nombre de su banco en el campo de remitente, antes de facilitar credenciales o autorizar una transferencia. La infraestructura del banco no había sido vulnerada. El SOC no registró ninguna alerta. El fraude se consumó en el canal de comunicación, no en el perímetro técnico de la entidad.
Ese desplazamiento es la cuestión central de este artículo. No se trata de que los equipos de seguridad trabajen mal: se trata de que operan sobre un perímetro que, por definición, termina donde termina la infraestructura propia. Y el fraude dirigido al cliente final comienza exactamente ahí.
I. El perímetro del SOC y el vacío que deja
Un Centro de Operaciones de Seguridad convencional monitoriza activos propios: redes internas, endpoints corporativos, aplicaciones bajo custodia de la entidad, flujos de autenticación en plataformas controladas. Su valor es indiscutible para detectar intrusiones, gestionar vulnerabilidades y responder a incidentes dentro del dominio técnico de la organización.
El smishing, el vishing y el fraude por suplantación de remitente operan en un espacio distinto. El atacante no necesita entrar en los sistemas del banco: necesita convencer al cliente de que el mensaje que ha recibido es legítimo. Para ello utiliza técnicas de inyección en rutas SS7, alfa-sender spoofing en pasarelas SMS con controles laxos, o dominios registrados con variaciones tipográficas mínimas respecto al dominio oficial de la entidad. Ejemplos del tipo banco-operaciones.net/verificar o banca-segura-alerta.com son suficientes para superar el umbral de confianza de un usuario no especializado.
Ninguna de estas acciones genera tráfico anómalo en la red interna del banco. Ninguna activa las reglas SIEM configuradas para detectar movimiento lateral o exfiltración de datos. El SOC, sencillamente, no tiene visibilidad sobre ese vector porque el vector no pasa por sus sensores.
"Las entidades financieras deben gestionar los riesgos de las TIC de forma integral, incluyendo los riesgos derivados de sus relaciones con terceros y de los canales de comunicación con clientes." — Reglamento (UE) 2022/2554, DORA, considerando 52 y Art. 5.2
La lectura habitual de DORA en los comités de riesgos se concentra en resiliencia operativa, continuidad del servicio y gestión de terceros críticos de TIC. Es una lectura correcta pero parcial. El artículo 5 impone al órgano de dirección la responsabilidad de definir y supervisar la gestión de riesgos de TIC de forma que cubra los canales a través de los cuales la entidad se relaciona con sus clientes. Cuando ese canal es el SMS y el riesgo concreto es la suplantación del remitente, la cobertura exige instrumentos que no forman parte de un SOC estándar.
II. Tipología del fraude que escapa al SOC: tres patrones documentados
II.1 Inyección en hilo SMS legítimo
La técnica más extendida en banca minorista española durante 2023 y 2024 consiste en inyectar mensajes fraudulentos dentro del hilo de conversación que el cliente ya tiene con su banco. Dado que el campo alfa-sender coincide con el nombre real de la entidad, el dispositivo agrupa automáticamente el mensaje malicioso con las notificaciones OTP o alertas de movimiento genuinas. El cliente no percibe discontinuidad visual. La solicitud fraudulenta —habitualmente un enlace para "verificar" una operación bloqueada— aparece con el mismo contexto de confianza que los mensajes anteriores del banco.
La detección de este patrón requiere monitorización activa de las pasarelas de terminación SMS, análisis de remitente en origen y correlación con los dominios enlazados. Ninguno de esos puntos de captura está dentro del perímetro que gestiona el SOC de una entidad financiera media.
II.2 Registro de dominios de suplantación con ventana corta
INCIBE-CERT documenta de forma recurrente campañas en las que los atacantes registran dominios que imitan la denominación de entidades financieras, aseguradoras u operadoras de telecomunicaciones con días o semanas de antelación a la campaña activa. La ventana de actividad del dominio malicioso es deliberadamente corta —a veces inferior a 72 horas— para eludir los tiempos de respuesta de las listas de reputación estándar. La baja longevidad del dominio y el volumen reducido de envíos impiden que las soluciones reactivas generen señal suficiente antes de que el fraude se consume.
La cobertura de este vector exige inteligencia de registros DNS en tiempo próximo al real, correlación con patrones tipográficos respecto a los dominios oficiales de la entidad y capacidad de actuación sobre las pasarelas de envío antes de que el SMS llegue al destinatario. Es una capa de protección orientada al cliente, no a la infraestructura.
II.3 Suplantación en canales de atención al cliente por voz
El vishing combinado con SMS previo —el atacante envía primero un mensaje de alerta falso y después llama haciéndose pasar por el servicio de fraude del banco— está documentado en resoluciones del Banco de España y en las guías de fraude del cliente publicadas por la Autoridad Bancaria Europea (EBA). La eficacia de la combinación reside en que el SMS inicial eleva la credibilidad de la llamada posterior: el cliente ya ha recibido una alerta, el agente que llama la "confirma". El SOC no detecta ninguno de los dos eventos porque ninguno ocurre en sus sistemas.
III. DORA, PSD2 y el riesgo reputacional como triángulo de presión
Tres presiones convergentes obligan a los comités de riesgos a ampliar su modelo de cobertura más allá del SOC tradicional.
La primera es regulatoria. DORA, en vigor desde enero de 2025 para las entidades en ámbito, exige en su Art. 9 que el marco de gestión de riesgos de TIC incluya mecanismos de detección de anomalías en todos los canales de comunicación relevantes. La Directiva PSD2, transpuesta en España mediante el Real Decreto-ley 19/2018, establece en su artículo 74 la responsabilidad del proveedor de servicios de pago ante operaciones no autorizadas, con excepciones acotadas a negligencia grave del usuario. La combinación de ambos marcos sitúa a la entidad en una posición de exposición si no puede demostrar que adoptó medidas razonables para proteger el canal de comunicación con el cliente.
La segunda presión es operativa. Una reclamación por smishing no resulta únicamente en el reembolso del importe defraudado: genera un expediente ante el Banco de España, consume recursos del servicio de atención al cliente, puede derivar en cobertura mediática si el volumen de afectados supera cierto umbral, y deteriora el índice de confianza del producto digital. El coste total por incidente supera con frecuencia el valor nominal del fraude.
La tercera es de responsabilidad compartida con el cliente. El RGPD, en su Art. 5.1.f, impone integridad y confidencialidad en el tratamiento de datos personales. Cuando un atacante utiliza datos del cliente —nombre, número de teléfono, entidad con la que opera— para construir un mensaje de suplantación creíble, la pregunta sobre el origen de esos datos no tarda en plantearse. La entidad que puede demostrar trazabilidad de sus canales de comunicación y ausencia de fuga en el proceso de envío está en posición considerablemente mejor ante reguladores y ante el propio cliente.
IV. Lo que VeriMsg cubre específicamente en este ángulo
VeriMsg opera como capa de verificación y monitorización sobre el canal de comunicación entre la entidad y su cliente, en el espacio que queda fuera del alcance del SOC. Su función no es sustituir ni solapar las capacidades del equipo de seguridad interna: es cerrar el gap entre el último punto de control técnico de la entidad y el dispositivo del cliente.
En términos operativos, esto implica tres capacidades diferenciadas. Primera: verificación de integridad del remitente en el momento del envío, de forma que el cliente dispone de un mecanismo de confirmación independiente del propio canal SMS. Segunda: monitorización de dominios de suplantación mediante análisis de registros DNS y correlación con los activos de marca de la entidad, con alertas accionables antes de que la campaña active su volumen principal. Tercera: trazabilidad auditable del ciclo de vida de cada comunicación, alineada con los requisitos de documentación que establece DORA Art. 11 para la gestión de incidentes relacionados con TIC.
El resultado para el comité de riesgos es doble: reducción de la superficie de fraude dirigido al cliente final, y evidencia documental ante auditores y reguladores de que la entidad adoptó medidas activas sobre el canal de comunicación, no solo sobre la infraestructura interna.
Checklist ejecutivo: cinco preguntas para su próxima revisión de cobertura
- ¿Tiene su entidad visibilidad sobre los mensajes SMS que llegan a sus clientes con su nombre como remitente, incluyendo los que no han sido enviados por usted? Si la respuesta es negativa, el vector de inyección en hilo SMS está abierto.
- ¿Dispone de un proceso de alerta temprana ante el registro de dominios que imitan sus activos de marca? La ventana de actuación útil es inferior a 48 horas en las campañas documentadas por INCIBE-CERT. Un proceso manual no es suficiente.
- ¿Puede demostrar ante una auditoría DORA la trazabilidad completa de sus comunicaciones con clientes, incluyendo los eventos de entrega fallida o anomalía en remitente? El Art. 11 del Reglamento exige registros que soporten la gestión de incidentes TIC.
- ¿Está su equipo de atención al cliente formado para identificar y escalar reclamaciones que corresponden a smishing antes de que se tramiten como incidencias técnicas ordinarias? La demora en la clasificación aumenta el coste total por incidente.
- ¿Ha revisado la distribución de responsabilidad entre su SOC, su equipo de fraude y su proveedor de comunicaciones ante un incidente de suplantación de remitente? La ausencia de un responsable claro en ese gap es, en sí misma, un riesgo regulatorio bajo DORA Art. 5.2.
Si su entidad está en proceso de revisión de su marco de gestión de riesgos TIC o evaluando la cobertura de canales de comunicación con clientes, el Pilot Readiness Pack de VeriMsg proporciona un diagnóstico estructurado del gap entre su SOC actual y el canal de comunicación con el cliente final, con documentación alineada a los requisitos de reporte de DORA.