El artículo 11 del Reglamento DORA (Reglamento UE 2022/2554) obliga a las entidades financieras a garantizar la continuidad operativa de sus funciones críticas frente a perturbaciones de terceros proveedores de TIC, con planes de respuesta y recuperación documentados y probados. En la práctica, esto significa que cualquier capa de protección antifraude incorporada como servicio externo —incluida la verificación de mensajes comerciales y transaccionales— debe poder acreditarse ante el supervisor con evidencia de onboarding estructurado, controles de acceso auditables y criterios de salida definidos. Sin ese expediente, el piloto más prometedor queda fuera del perímetro aprobable por el comité de riesgos.
I. Por qué el onboarding estructurado es ya una exigencia regulatoria, no una preferencia de proyecto
La entrada en vigor plena de DORA el 17 de enero de 2025 ha elevado el listón para cualquier integración de servicios TIC en entidades bajo supervisión del BCE o del Banco de España. El artículo 28 del mismo reglamento detalla los requisitos contractuales mínimos con proveedores de servicios críticos: descripción del alcance, niveles de servicio medibles, derechos de auditoría y procedimientos de salida. Un acuerdo de white-label que no contemple estos extremos desde la fase de negociación acumula deuda regulatoria antes de procesar el primer mensaje.
En paralelo, la revisión de PSD2 en curso —conocida como PSD3 en fase de trílogo— refuerza el enfoque de responsabilidad compartida en fraude de pagos iniciados por el ordenante bajo manipulación (la tipología TOAD, telephone-oriented attack delivery, y sus derivados por SMS). El Banco de España cifra el fraude no presencial en tarjeta y transferencias como una de las líneas de mayor crecimiento en sus memorias anuales de supervisión. Dicho de otro modo: el regulador ya sabe que el vector de entrada es el canal de mensajería; espera que su entidad también lo sepa y lo tenga cubierto operativamente.
"Las entidades deben disponer de un marco sólido de gestión del riesgo de las TIC que incluya estrategias, políticas, procedimientos, protocolos y herramientas necesarios para proteger todos los activos de información e infraestructuras TIC pertinentes." — Reglamento (UE) 2022/2554, artículo 6, apartado 1.
El onboarding de TrustLayer —la capa de integración white-label de VeriMsg— está diseñado para producir ese expediente desde la semana cero, no como subproducto de la implementación técnica, sino como entregable explícito de cada hito.
II. El roadmap en ocho semanas: hitos, responsables y entregables
El calendario que se describe a continuación refleja el ciclo real de incorporación de una entidad regulada de tamaño mediano (banca regional, aseguradora de ámbito nacional u operador de telecomunicaciones con base de clientes superior a 500.000 líneas). Las semanas son semanas naturales de trabajo; la fecha de inicio se fija en la firma del acuerdo de confidencialidad mutuo y del Data Processing Agreement alineado con el artículo 28 del RGPD.
Semana 1-2: Fase de descubrimiento y alineación de requisitos
El objetivo de esta fase no es técnico: es regulatorio y organizativo. Se convoca una sesión de trabajo conjunta con el Head of Fraud o CISO, el responsable de cumplimiento y, cuando procede, el delegado de protección de datos. Los entregables de salida son tres documentos: el inventario de canales de mensajería en producción (SMS transaccional, notificaciones push, correo electrónico operativo), el mapa de datos personales involucrados en cada flujo, y la descripción de los criterios de éxito del piloto acordados con el comité de riesgos.
Este último punto es crítico. Un piloto sin criterios de cierre predefinidos es una prueba de concepto que nunca termina. VeriMsg propone formalizarlos en la semana 2 mediante un documento de Pilot Success Criteria que el comité puede firmar y archivar como evidencia de gobernanza ante una inspección.
Semana 3-4: Integración técnica en entorno de preproducción
La integración de TrustLayer sigue un modelo de API REST sobre HTTPS con autenticación por certificado de cliente. No requiere modificación del núcleo bancario ni del sistema de mensajería existente: se posiciona como capa de análisis entre el orquestador de mensajes del partner y el canal de entrega. El equipo técnico del partner —habitualmente dos o tres ingenieros de integración— trabaja con la documentación de referencia y un entorno sandbox con datos sintéticos.
Los entregables de esta fase son: pruebas de conectividad firmadas, configuración de los perfiles de alerta adaptados a la tipología de mensajes del partner (transaccional, comercial regulado, OTP), y el primer informe de latencia en entorno controlado. La seguridad del canal se documenta con referencia a los controles técnicos alineados con el artículo 9 de DORA (protección de datos e integridad de sistemas).
Semana 5-6: Parametrización de políticas y calibración de umbrales
Esta es la fase más intensiva en criterio experto. Cada entidad tiene una distribución de mensajes legítimos distinta: una aseguradora envía comunicaciones de siniestro con patrones de urgencia que, fuera de contexto, se asemejan a señales de fraude; un operador challenger puede tener remitentes con nombres cortos que comparte con dominios de spoofing conocidos.
El equipo de análisis de VeriMsg trabaja con una muestra representativa de mensajes reales (anonimizada conforme al DPA firmado) para calibrar los umbrales de puntuación de riesgo. Se definen tres niveles operativos: entrega sin fricción, entrega con señal de verificación visible para el receptor, y bloqueo con alerta al equipo de fraude. Los falsos positivos en cada nivel se miden y documentan. Esta documentación sirve directamente para el informe de gestión de riesgos TIC que exige el artículo 13 de DORA.
Semana 7-8: Piloto en producción y cierre de expediente
El piloto en producción opera sobre un segmento acotado del tráfico real —habitualmente entre el 5 % y el 15 % de los mensajes transaccionales— con supervisión compartida entre el equipo de fraude del partner y el servicio de monitorización de VeriMsg. Se registran los eventos de alerta con trazabilidad completa: identificador de mensaje, fase de análisis en que se generó la señal, puntuación de riesgo y acción tomada.
Al cierre de la semana 8 se entrega el Pilot Closure Report, que incluye: estadísticas de cobertura, distribución de puntuaciones, detecciones confirmadas por el equipo de fraude del partner, y recomendación de transición a producción plena. Este informe está estructurado para ser presentado directamente al comité de riesgos sin reelaboración.
III. Qué cubre TrustLayer que el SOC del partner no cubre por defecto
Los centros de operaciones de seguridad de las entidades financieras y telecomunicaciones están diseñados para monitorizar infraestructura propia: tráfico de red, accesos a sistemas, alertas de SIEM. Su perímetro natural termina donde empieza el canal externo de mensajería. El vector de fraude más activo en España en los últimos dos años —el smishing con suplantación de entidad financiera, documentado por INCIBE en sus informes de avisos de seguridad— opera precisamente en ese espacio ciego: el mensaje llega al dispositivo del cliente desde fuera del perímetro del SOC.
TrustLayer actúa en la capa de verificación de contenido y remitente antes de la entrega, y en la capa de análisis de comportamiento del receptor tras la misma. Ninguna de estas dos capas forma parte del modelo operativo estándar de un SOC orientado a infraestructura. No se trata de sustituir al SOC: se trata de cubrir el tramo que, por diseño, el SOC no monitoriza.
Un ejemplo anonimizado ilustra la diferencia. Una entidad de banca regional detectó, durante el piloto, una campaña activa de suplantación de su marca mediante remitentes con variaciones tipográficas del identificador alfanumérico oficial (del tipo "BancoCliente" sustituido por "BancoC1iente" con el número uno en lugar de la letra ele). El SOC de la entidad no tenía visibilidad sobre ese tráfico porque los mensajes fraudulentos no pasaban por sus sistemas. TrustLayer los identificó por comparación de remitente contra el registro de identificadores autorizados y por análisis de la URL embebida, que apuntaba a un dominio registrado 72 horas antes del envío masivo (patrón de dominio efímero documentado también en los avisos de INCIBE).
IV. Dimensión regulatoria del expediente de integración
El expediente que genera el proceso de ocho semanas no es documentación interna de VeriMsg: es documentación del partner, producida conjuntamente y archivada bajo su custodia. Esto es relevante porque el artículo 30 de DORA exige que las entidades mantengan un registro actualizado de todos los acuerdos contractuales con proveedores TIC, con especificación de las funciones críticas cubiertas. El Pilot Closure Report, el DPA y el documento de Pilot Success Criteria forman el núcleo de ese registro para el servicio de verificación de mensajería.
En materia de protección de datos, el tratamiento se circunscribe a los metadatos de mensajería necesarios para el análisis de riesgo. No se procesan contenidos de comunicaciones privadas entre personas físicas; el ámbito es la mensajería comercial y transaccional de la entidad hacia sus clientes. La base jurídica es el interés legítimo del responsable del tratamiento en la prevención del fraude, conforme al considerando 47 del RGPD, sin perjuicio de la evaluación de impacto que cada entidad debe realizar bajo su propio criterio.
Checklist ejecutivo para el comité de riesgos
- Inventario de canales antes de la semana 1. Identifique todos los flujos de mensajería transaccional y comercial activos, los identificadores de remitente registrados y los proveedores de entrega involucrados. Sin ese inventario, el piloto no puede parametrizarse con precisión ni el expediente DORA puede completarse.
- Criterios de éxito formalizados antes de arrancar el entorno de producción. Defina con su comité de riesgos qué tasa de detección, qué umbral de falsos positivos y qué cobertura de tráfico considera suficientes para aprobar la transición. Esto protege tanto al equipo técnico como al decisor.
- DPA y acuerdo de confidencialidad firmados en paralelo, no después. El tratamiento de datos comienza en la fase de calibración (semana 5). Si el DPA no está firmado antes de esa semana, la entidad incurre en riesgo de incumplimiento del artículo 28 del RGPD desde el primer día de trabajo con datos reales.
- Asigne un interlocutor técnico con capacidad de decisión. Los retrasos más frecuentes en integraciones de este tipo provienen de equipos técnicos sin autorización para aprobar configuraciones en preproducción. Un responsable con mandato claro acorta el ciclo en dos a tres semanas.
- Solicite el Pilot Readiness Pack antes de la primera sesión. El Pack incluye la plantilla de Pilot Success Criteria, el modelo de DPA, la guía de integración técnica y el esquema de entregables por semana. Permite que su equipo jurídico y su CISO revisen los términos antes de que comience el reloj de las ocho semanas.
Para acceder al Pilot Readiness Pack o programar la sesión de descubrimiento, contacte con el equipo de VeriMsg a través del formulario de solicitud de piloto disponible en este sitio. El proceso no requiere compromiso comercial previo: el primer entregable es el inventario de canales, y ese trabajo es suyo desde el primer día.