El Reglamento DORA (UE 2022/2554), aplicable desde el 17 de enero de 2025, exige que las entidades financieras documenten y supervisen los acuerdos con proveedores críticos de TIC a lo largo de todo el ciclo de vida del servicio, incluida la fase de incorporación. El artículo 28 obliga a establecer estrategias de salida y planes de prueba antes de que cualquier componente externo opere en entornos de producción. Para un comité de riesgos, esto convierte el onboarding tecnológico en un evento regulatorio, no solo técnico.
La integración white-label de una capa anti-fraude en una entidad regulada puede completarse en ocho semanas si los hitos están definidos, los responsables asignados y los criterios de cierre del piloto acordados desde la primera llamada. Este artículo describe ese roadmap: qué ocurre en cada fase, quién firma cada entregable y cómo se evalúa el resultado antes de escalar a producción.
¿Por qué el onboarding de tecnología anti-fraude es ahora un evento regulatorio?
Hasta 2024, incorporar un proveedor de verificación de mensajes era, para la mayoría de entidades, un proyecto de producto. DORA lo eleva a obligación de gobierno. El artículo 5 del reglamento requiere que el órgano de dirección apruebe y revise los acuerdos con terceros que soporten funciones críticas o importantes. La verificación de comunicaciones al cliente —SMS, correo, notificaciones push— entra en ese perímetro cuando su fallo podría derivar en fraude, pérdida de datos personales o incumplimiento del deber de información regulado en PSD2 (Directiva 2015/2366, artículo 74).
"Las entidades financieras garantizarán que los acuerdos contractuales con proveedores externos de servicios de TIC incluyan las especificaciones completas de los niveles de servicio, así como los derechos de auditoría y supervisión de la entidad." — DORA, Art. 30.2, traducción al español del texto publicado en el DOUE L 333/1 de 27.12.2022.
A esto se suma el riesgo reputacional cuantificable. Según el informe de fraude del Banco de España correspondiente al ejercicio 2023, las reclamaciones por operaciones no autorizadas en medios de pago electrónico superaron las 125.000 en banca minorista. Una fracción relevante tiene origen en comunicaciones fraudulentas que suplantan a la entidad. El coste directo es absorbible; el coste de confianza, no.
¿Qué estructura de fases cubre un piloto de ocho semanas?
Un piloto de integración white-label anti-fraude estructurado en ocho semanas se divide en cuatro fases de dos semanas cada una: alineación y alcance, integración técnica, validación en entorno controlado y evaluación de criterios de cierre. Cada fase tiene un responsable principal, entregables concretos y una condición de avance que debe ser aprobada antes de iniciar la siguiente.
Fase I (semanas 1-2): Alineación estratégica y alcance regulatorio
El primer bloque no es técnico. El objetivo es que el comité de riesgos, el CISO y el responsable de cumplimiento compartan una definición común del problema, el perímetro regulatorio aplicable y los criterios de éxito del piloto. Los entregables de esta fase son tres: el acuerdo de tratamiento de datos alineado con el RGPD (artículo 28, responsable-encargado), el registro de la relación en el inventario de proveedores TIC exigido por DORA y el documento de alcance funcional firmado por ambas partes.
Durante esta fase se identifican los canales en piloto (habitualmente SMS transaccional y correo de alertas), los volúmenes estimados y los umbrales de falsos positivos aceptables para el negocio. Sin este acuerdo previo, la validación técnica posterior carece de criterio de referencia.
Fase II (semanas 3-4): Integración técnica en entorno de preproducción
La integración de TrustLayer se realiza sobre la infraestructura de preproducción de la entidad. El equipo técnico del partner trabaja con el equipo de arquitectura interno para mapear los flujos de mensajería existentes —operador, agregador, plataforma de notificaciones— y situar la capa de verificación en el punto correcto sin alterar la experiencia del cliente final.
El entregable principal de esta fase es el informe de integración técnica, que documenta: los endpoints configurados, la política de reintentos, el comportamiento ante indisponibilidad parcial y los registros de auditoría generados por cada verificación. Este documento es el que los auditores internos y el supervisor consultarán en una inspección DORA. La configuración de la marca blanca —denominación, identidad visual, dominio de consulta— se valida también en esta fase con el equipo de producto de la entidad.
Fase III (semanas 5-6): Validación con tráfico real controlado
Con la integración estable en preproducción, se activa un volumen limitado de tráfico real —habitualmente entre el 5 % y el 15 % del canal pilotado— bajo supervisión conjunta. El objetivo es contrastar el comportamiento del motor de verificación ante tipologías de fraude reales documentadas en el mercado español: dominios de aspecto legítimo del tipo banco-operaciones.net/verificar, remitentes alfa numéricos suplantados, y redirecciones encadenadas que eluden listas negras estáticas.
Durante estas dos semanas, el Head of Fraud de la entidad recibe informes diarios de señales detectadas, clasificadas por fase de análisis: remitente, cuerpo, destino y contexto temporal. Cada señal es trazable: el veredicto tiene un identificador único, una puntuación y las señales que lo componen, lo que permite al equipo de fraude auditar cualquier decisión sin depender del proveedor para explicarla.
Fase IV (semanas 7-8): Evaluación de criterios de cierre y decisión de escala
La última fase es deliberadamente analítica, no operativa. El tráfico vuelve a niveles nominales y el comité de riesgos recibe el informe de piloto consolidado. Este informe incluye: tasa de detección sobre el subconjunto de casos conocidos, tasa de falsos positivos sobre comunicaciones legítimas, tiempos de respuesta del sistema en percentiles representativos, y ausencia de incidentes de disponibilidad no comunicados. La decisión de escalar a producción es del comité, no del proveedor.
¿Qué diferencia a TrustLayer de la capa de seguridad que ya tiene su SOC?
Esta es la pregunta que los CISO plantean con más frecuencia, y merece una respuesta precisa. El SOC de una entidad regulada opera sobre infraestructura propia y tráfico interno: eventos de red, logs de sistemas, alertas de SIEM. Su visibilidad sobre la mensajería saliente al cliente es, en la mayoría de arquitecturas, limitada o inexistente una vez el mensaje abandona la plataforma de envío.
TrustLayer opera en el espacio entre la plataforma de envío de la entidad y el dispositivo del cliente. Analiza el mensaje en el momento de la entrega —o en la consulta activa del cliente— y devuelve un veredicto estructurado que el SOC puede ingerir como evento en su SIEM. No sustituye al SOC; le extiende la visibilidad al canal de comunicación con el cliente, que es precisamente el canal que los grupos de fraude explotan con mayor intensidad en España según los datos del Centro de Coordinación de Ciberseguridad Nacional (CCN-CERT, Informe de Amenazas 2023).
La integración white-label añade una dimensión adicional: la entidad presenta la verificación bajo su propia marca, sin transferir la relación de confianza con el cliente a un tercero visible. Para una entidad regulada con obligaciones de transparencia bajo RGPD, esto no es un detalle estético; es una decisión de arquitectura de datos y de comunicación institucional.
Preguntas frecuentes
¿Cuánto tiempo lleva integrar una solución white-label anti-fraude en una entidad regulada?
Un piloto completo con validación regulatoria puede estructurarse en ocho semanas: dos de alineación y alcance, dos de integración técnica en preproducción, dos de validación con tráfico real controlado y dos de evaluación de criterios de cierre antes de la decisión de escala a producción.
¿Qué documentación exige DORA para incorporar un proveedor de verificación de mensajes?
El artículo 28 de DORA requiere registrar al proveedor en el inventario de terceros TIC, documentar los niveles de servicio acordados, establecer derechos de auditoría y definir una estrategia de salida antes de que el componente opere en producción. El artículo 30 detalla las cláusulas contractuales mínimas.
¿La capa de verificación es visible para el cliente final?
En la modalidad white-label, no. El cliente interactúa únicamente con la marca y el dominio de la entidad. TrustLayer opera de forma transparente para el usuario, lo que preserva la relación de confianza directa entre la entidad y su cliente y simplifica la base legal bajo el RGPD.
¿Cómo se integra el veredicto de verificación con el SIEM del SOC?
Cada veredicto de TrustLayer genera un evento estructurado con identificador único, puntuación y señales trazables por fase de análisis. Este evento puede ingerirse en los SIEM habituales del mercado como evento de seguridad estándar, sin desarrollo adicional por parte del equipo interno.
Checklist ejecutivo: lo que su comité debe validar antes de aprobar el piloto
- Alcance regulatorio documentado. El acuerdo de tratamiento de datos (RGPD Art. 28) y el registro en el inventario de terceros TIC (DORA Art. 28) deben estar firmados antes del inicio de la integración técnica, no después.
- Criterios de cierre del piloto definidos por adelantado. Tasa de detección mínima aceptable, umbral de falsos positivos tolerable y ausencia de incidentes de disponibilidad no comunicados deben ser acordados en la Fase I, no evaluados a posteriori.
- Trazabilidad de veredictos auditables. Exija que cada decisión del motor de verificación tenga un identificador único y señales exportables. Su equipo de auditoría interna —y el supervisor en una inspección DORA— necesitarán reproducir cualquier veredicto sin intermediación del proveedor.
- Diferenciación clara entre capa SOC y capa de mensajería. Documente en la arquitectura de seguridad dónde termina la visibilidad de su SOC y dónde comienza TrustLayer. Esta delimitación es necesaria tanto para el informe de piloto como para el mapa de riesgos TIC exigido por DORA.
- Decisión de escala en manos del comité, no del proveedor. El informe de piloto de la Fase IV debe llegar al comité de riesgos con datos suficientes para una decisión autónoma. Si el proveedor es quien propone escalar sin haber entregado el informe consolidado, el proceso de gobierno no está funcionando correctamente.
Si su entidad está evaluando iniciar este proceso, el Pilot Readiness Pack de VeriMsg incluye las plantillas de documentación regulatoria para las fases I y IV, el modelo de acuerdo de tratamiento de datos y los criterios de cierre de piloto estándar adaptables a banca, seguros y telecomunicaciones reguladas. Puede solicitarlo sin compromiso como primer paso antes de la primera llamada.