En enero de 2025, el Banco de España publicó su Memoria de Supervisión 2024 alertando de que el fraude en medios de pago electrónicos continúa siendo uno de los principales vectores de pérdida para los usuarios del sistema financiero español, con especial incidencia en las comunicaciones de suplantación de identidad dirigidas al cliente final. El dato no es menor: las entidades financieras notificaron incidentes relacionados con smishing y phishing bancario que superaron, en volumen agregado, los registrados en el ejercicio anterior. La infraestructura interna seguía intacta. El cliente no.
El SOC no basta contra el fraude dirigido al cliente final porque su perímetro es, por diseño, la infraestructura de la entidad. Un SMS fraudulento que llega al teléfono del titular de una cuenta no atraviesa el cortafuegos del banco, no activa ninguna regla SIEM y no genera ninguna alerta en el cuadro de mando del analista de turno. El canal de comunicación con el cliente queda estructuralmente fuera del alcance operativo del SOC, y ese es exactamente el hueco que explotan las tipologías de fraude más prevalentes en España hoy.
¿Por qué el SOC protege la infraestructura pero no al destinatario del mensaje?
El modelo operativo de un Centro de Operaciones de Seguridad está concebido para monitorizar activos bajo control de la organización: redes internas, endpoints corporativos, APIs, bases de datos, registros de autenticación. Es la respuesta técnicamente correcta a las amenazas que atacan desde afuera hacia adentro del perímetro lógico de la entidad.
El fraude dirigido al cliente final opera en sentido inverso. El atacante no necesita penetrar los sistemas del banco: necesita engañar al usuario para que él mismo entregue sus credenciales, autorice una transferencia o instale un perfil de configuración malicioso. Los vectores más documentados en España durante 2024 —según el informe anual de INCIBE— incluyen SMS que suplantan al banco receptor con remitentes alfanuméricos manipulados, llamadas de voz que combinan datos extraídos de filtraciones previas, y URLs de phishing con estructura de subdominio plausible del tipo banco-operaciones.net/verificar registradas horas antes del envío masivo.
Ninguno de estos eventos genera telemetría en el SIEM de la entidad hasta que el daño está consumado: la transferencia ya se ha ejecutado, el cliente ya ha introducido su OTP en una página falsa. El SOC detecta la consecuencia, no la causa.
¿Qué exige DORA respecto a la gestión de riesgos que afectan al usuario final?
"Las entidades financieras establecerán, mantendrán y actualizarán un marco completo de gestión del riesgo de las TIC [...] que incluya estrategias, políticas, procedimientos, protocolos y herramientas de TIC necesarios para proteger de manera adecuada y proporcionada todos los activos de información y de TIC pertinentes."
— Reglamento DORA (UE) 2022/2554, Artículo 5, apartado 2.
La definición de "activos de información pertinentes" en DORA es más amplia de lo que habitualmente se implementa. El canal de comunicación con el cliente —SMS, correo electrónico transaccional, notificaciones push— es un activo de información de la entidad en la medida en que se usa para autenticar operaciones, comunicar estados de cuenta o activar flujos de seguridad. Cuando ese canal es suplantado, el riesgo operacional recae sobre la entidad aunque el vector esté fuera de su red.
El Artículo 9 de DORA obliga a implementar mecanismos de protección y prevención. El Artículo 17 regula la clasificación de incidentes significativos. Una campaña de smishing que afecte a decenas de clientes de una entidad regulada puede alcanzar los umbrales de notificación obligatoria al supervisor sin que el SOC lo haya detectado como incidente propio. Esa asimetría es la que los comités de riesgos deben resolver antes de la auditoría, no durante.
PSD2, por su parte, establece en su Artículo 73 la responsabilidad del proveedor de servicios de pago ante operaciones no autorizadas. La carga de la prueba sobre la autenticación reforzada recae en la entidad. Si el cliente fue engañado mediante un mensaje que suplantaba la comunicación oficial del banco, el perímetro de responsabilidad —y de riesgo reputacional— se amplía de forma significativa.
¿Cómo explotan los atacantes el canal de mensajería en España?
Las tipologías documentadas en el mercado español presentan tres patrones recurrentes que resultan útiles para que el comité de riesgos pueda calibrar su exposición actual.
Suplantación de remitente alfanumérico: El atacante registra o manipula un remitente que visualmente coincide o se aproxima al identificador legítimo de la entidad. El cliente lo recibe en el mismo hilo de conversación que los SMS auténticos del banco. La tasa de apertura e interacción es sustancialmente superior a la del phishing por correo electrónico, precisamente por esa continuidad visual del hilo.
Campaña coordinada con llamada de voz: Un primer SMS genera urgencia ("su cuenta ha sido bloqueada"). Una llamada posterior, con número aparentemente local, completa el vector. El interlocutor dispone de datos parciales del cliente —extraídos de filtraciones previas o de ingeniería social básica— que otorgan credibilidad suficiente para que el usuario entregue el factor de autenticación. INCIBE documentó variantes de esta tipología con ciclos de ataque de menos de cuatro horas desde el registro del dominio hasta el primer envío masivo.
URL de vida corta sobre infraestructura legítima: Los atacantes alojan páginas de phishing en subdominios de plataformas de nube pública o servicios de acortamiento de URLs con reputación limpia, eludiendo los filtros de reputación de dominio estándar. La URL queda activa el tiempo justo para completar la campaña antes de que las listas negras la incorporen.
En los tres casos, el SOC de la entidad no tiene visibilidad hasta que el cliente ya ha sido comprometido o hasta que inicia el proceso de reclamación.
¿Qué cubre VeriMsg que el SOC no alcanza a cubrir?
VeriMsg opera como capa de verificación de integridad del canal de comunicación entre la entidad y su cliente, en el punto exacto donde el SOC no tiene cobertura: el momento en que el mensaje llega al dispositivo del destinatario y antes de que este interactúe con él.
La arquitectura se inserta entre el operador de mensajería y la bandeja del usuario, analizando atributos del mensaje —remitente, estructura del enlace, contexto de envío, coherencia con patrones de comunicación legítima de la entidad— y devolviendo una señal verificable al cliente antes de que abra el contenido. La señal es trazable: cada veredicto lleva asociado un identificador de análisis auditable, lo que permite a los equipos de cumplimiento y a los auditores externos reconstruir la cadena de decisión para cualquier incidente.
Esto no duplica ni reemplaza el SOC. El SOC continúa siendo la capa competente para la seguridad de la infraestructura interna. VeriMsg cubre el gap operativo que media entre el perímetro del SOC y el dispositivo del cliente, alineándose con los requisitos de gestión de riesgos del canal contemplados en DORA Art. 5 y con las obligaciones de protección al usuario de PSD2 Art. 73. El RGPD Art. 25 —privacidad por diseño— se incorpora desde la arquitectura: el análisis no requiere acceso al contenido del mensaje del usuario.
Para entidades de banca regional, aseguradoras medianas y operadores de telecomunicaciones con responsabilidad sobre protección del cliente, el piloto de integración está disponible con un entorno de prueba aislado que no afecta a los flujos de producción.
Preguntas frecuentes
¿El SOC anti-fraude de mi entidad cubre el smishing dirigido al cliente?
No de forma directa. El SOC monitoriza activos internos de la organización. Un SMS fraudulento enviado al cliente no atraviesa la infraestructura de la entidad y no genera telemetría en el SIEM hasta que el fraude ya se ha consumado. Existe un gap estructural entre el perímetro del SOC y el dispositivo del usuario.
¿Qué artículos de DORA afectan al canal de comunicación con el cliente?
DORA Art. 5 obliga a proteger todos los activos de información pertinentes, categoría que incluye el canal de mensajería cuando se usa para autenticar operaciones. El Art. 9 exige mecanismos de protección y prevención. El Art. 17 regula umbrales de notificación de incidentes que una campaña de smishing masiva puede activar.
¿Puede una campaña de smishing generar obligación de notificación al supervisor?
Sí. Si la campaña afecta a un volumen significativo de clientes o implica pérdidas que superen los umbrales definidos en la guía de clasificación de incidentes de la EBA, la entidad puede estar obligada a notificar al supervisor competente aunque sus sistemas internos no hayan sido comprometidos.
¿Cómo se integra una capa de verificación de mensajería con el SOC existente?
Como capa complementaria, no sustitutiva. La verificación opera sobre el canal externo de comunicación con el cliente. Los veredictos y registros de análisis pueden integrarse en el SIEM del SOC como fuente de telemetría adicional, ampliando la visibilidad del analista hacia el perímetro del cliente sin modificar los flujos internos existentes.
Checklist ejecutivo: tres acciones que su comité puede activar esta semana
- Audite el perímetro real de visibilidad del SOC. Pida a su equipo que delimite explícitamente qué ocurre con un SMS fraudulento que llega al cliente desde un remitente suplantado: en qué punto aparece en el cuadro de mando, cuánto tiempo transcurre hasta la primera alerta interna y qué activos quedan fuera del alcance de monitorización. Ese mapa de puntos ciegos es el documento de partida para cualquier análisis de brecha frente a DORA.
- Verifique su exposición regulatoria bajo DORA Art. 17 y PSD2 Art. 73. Contraste con su asesor legal si una campaña de smishing de escala media —pongamos, varios centenares de clientes afectados en 48 horas— activaría en su entidad los umbrales de notificación obligatoria al Banco de España o al supervisor sectorial correspondiente. Si la respuesta no es inmediata, el proceso de clasificación de incidentes necesita revisión.
- Solicite el Pilot Readiness Pack de VeriMsg. El paquete de evaluación incluye un análisis de integración con su arquitectura de mensajería actual, un ejercicio de simulación de campaña de smishing sobre entorno aislado y un informe de brecha con referencia a los artículos regulatorios aplicables. No modifica flujos de producción y está dimensionado para completarse en un ciclo de dos semanas.