En febrero de 2024, la Agencia Española de Protección de Datos (AEPD) publicó una resolución sancionadora —expediente EXP202300426— contra una entidad financiera por haber conservado registros de comunicaciones de clientes más allá del plazo necesario para la finalidad declarada. La base de legitimación invocada era la lucha contra el fraude. La sanción: 1,2 millones de euros. El argumento de la entidad era técnicamente razonable; su documentación, insuficiente.
El conflicto entre tratamiento anti-fraude y cumplimiento del Reglamento General de Protección de Datos no es teórico. Es operativo, cotidiano y, sobre todo, resoluble si se diseña correctamente desde el inicio. La clave está en tres decisiones documentables: elegir la base de legitimación adecuada, garantizar la minimización efectiva del dato y firmar una relación de encargado de tratamiento que soporte una auditoría real. Las entidades que resuelven estas tres decisiones antes del incidente reducen de forma sustancial tanto el riesgo sancionador como el reputacional.
¿Por qué chocan el RGPD y los sistemas anti-fraude en la práctica?
Los sistemas de detección de fraude necesitan datos para funcionar: número de teléfono de origen, contenido del mensaje, metadatos de envío, historial de comportamiento del remitente, patrones de frecuencia. El RGPD, por su parte, exige que cada dato tratado tenga una finalidad explícita, una base de legitimación válida y un plazo de retención justificado. Cuando ambas lógicas se encuentran sin un diseño previo, surge la fricción.
El punto de mayor tensión no es la detección en tiempo real —que se puede sustentar en el interés legítimo del artículo 6.1.f del RGPD o en obligaciones legales derivadas de la Directiva PSD2 (artículo 94) y de DORA (Reglamento UE 2022/2554, artículos 5 y 17)—. El punto crítico es la retención posterior: qué se guarda, durante cuánto tiempo, con qué granularidad y para qué finalidad declarada. Un sistema que almacena el contenido íntegro de mensajes analizados durante doce meses «por si acaso» no cumple el principio de minimización del artículo 5.1.c del RGPD, independientemente de la legitimidad de la finalidad original.
A esto se suma una segunda fuente de conflicto: la cadena de encargados de tratamiento. Cuando una entidad financiera o una operadora delega el análisis de mensajes en un proveedor externo, ese proveedor debe actuar como encargado en los términos del artículo 28 del RGPD. Si la relación contractual no está correctamente documentada —o si el proveedor sublicencia a un tercero sin comunicarlo—, el responsable del tratamiento asume una exposición que difícilmente puede defender ante su DPO ni ante la AEPD.
¿Qué base de legitimación es válida para el tratamiento anti-fraude?
Existe una jerarquía práctica que los comités de cumplimiento deben conocer. Para entidades financieras sujetas a PSD2, la base más sólida es la obligación legal (artículo 6.1.c), dado que la propia Directiva impone medidas de seguridad y autenticación reforzada que implican, de forma inherente, la detección de comunicaciones fraudulentas. Esta base tiene la ventaja de no requerir balance de intereses, pero exige que el tratamiento se circunscriba estrictamente a lo que la norma impone.
«El tratamiento de datos personales en la medida estrictamente necesaria para garantizar la seguridad de la red y de la información (…) constituye un interés legítimo del responsable del tratamiento interesado.» — Considerando 49, Reglamento (UE) 2016/679 (RGPD).
Para operadores de telecomunicaciones o aseguradoras sin obligación legal directa equivalente, el interés legítimo del artículo 6.1.f es la base habitual. Pero su validez no es automática: requiere un test de ponderación documentado que demuestre que el interés del responsable o del tercero prevalece sobre los derechos e intereses del interesado. El INCIBE, en sus guías de ciberseguridad para el sector financiero, recomienda que este test se documente formalmente y se revise con periodicidad anual o ante cambios significativos en el tratamiento.
Lo que no es válido —aunque se utiliza con frecuencia— es invocar el consentimiento del artículo 6.1.a para tratamientos anti-fraude. El consentimiento debe ser libre, y difícilmente puede considerarse libre si la alternativa es no recibir el servicio. La EBA, en sus directrices sobre gestión de riesgos de TIC (EBA/GL/2019/04), es explícita en que las medidas de seguridad no pueden subordinarse al consentimiento del usuario cuando existe una obligación regulatoria de implementarlas.
¿Cómo se estructura una DPIA firmable para análisis de mensajes sospechosos?
Una Evaluación de Impacto relativa a la Protección de Datos (DPIA, según el artículo 35 del RGPD) es obligatoria cuando el tratamiento implica evaluación sistemática de aspectos personales basada en tratamiento automatizado, o cuando se procesan datos a gran escala. El análisis automatizado de mensajes de texto para detección de fraude cae, en la mayoría de los casos, dentro de ambos supuestos.
Una DPIA firmable —es decir, que soporte revisión por parte del DPO, de auditores externos y, en su caso, de la AEPD— debe documentar al menos los siguientes elementos: descripción precisa del tratamiento y sus flujos de datos; finalidad específica y base de legitimación con su fundamentación; categorías de datos tratados y su nivel de sensibilidad; medidas técnicas y organizativas que garantizan minimización y seudonimización; plazos de retención diferenciados por tipo de dato; análisis de riesgos para los derechos de los interesados; y medidas de mitigación adoptadas.
El elemento que con mayor frecuencia invalida una DPIA en revisión es la imprecisión en los plazos de retención. Declarar que «los datos se conservan el tiempo necesario» no constituye una respuesta válida. La AEPD, en su guía sobre evaluaciones de impacto de 2021, exige que los plazos sean concretos, justificados y diferenciados: los datos que fundamentaron una alerta confirmada de fraude tienen un plazo distinto a los metadatos de un mensaje analizado y descartado como legítimo.
¿Cómo cubre VeriMsg el gap entre análisis anti-fraude y requisitos RGPD?
La arquitectura de tratamiento de VeriMsg está diseñada desde el origen para que el análisis de mensajes sospechosos no genere un segundo problema de cumplimiento. Esto se traduce en tres elementos operativos concretos.
En primer lugar, el modelo de encargado de tratamiento está normalizado bajo el artículo 28 del RGPD con cláusulas contractuales tipo compatibles con las recomendaciones de la AEPD y del Comité Europeo de Protección de Datos (EDPB). El contrato de encargado incluye una cláusula de subencargo que detalla los terceros intervinientes, eliminando el riesgo de cadenas opacas de tratamiento que la AEPD ha sancionado en otros contextos.
En segundo lugar, el pipeline de análisis aplica seudonimización a nivel de metadatos antes de cualquier almacenamiento, de forma que los registros auditables no contienen datos directamente identificativos del destinatario. El contenido del mensaje se procesa en memoria y no persiste en almacenamiento en estado claro una vez emitido el veredicto. Este diseño es compatible con el principio de minimización del artículo 5.1.c y facilita la redacción de la sección de medidas técnicas de cualquier DPIA.
En tercer lugar, VeriMsg entrega, como parte del Pilot Readiness Pack, una plantilla de DPIA pre-cumplimentada en los apartados que corresponden a la capa de análisis de mensajes, con referencia a los artículos aplicables de RGPD, DORA y PSD2. El DPO de la entidad puede revisarla, adaptarla a su contexto específico y firmarla sin partir de cero. Esto reduce materialmente el tiempo de integración legal y elimina la dependencia de interpretaciones ad hoc en cada implantación.
Preguntas frecuentes
¿Qué base de legitimación es más sólida para el tratamiento anti-fraude en banca?
Para entidades sujetas a PSD2, la obligación legal del artículo 6.1.c del RGPD es la base más robusta, porque está anclada en una norma sectorial vigente. Para el resto de sectores, el interés legítimo del artículo 6.1.f es válido si va acompañado de un test de ponderación documentado y actualizado.
¿Es obligatoria una DPIA para el análisis de SMS sospechosos?
En la mayoría de los casos, sí. El análisis automatizado y a escala de comunicaciones personales activa los supuestos del artículo 35.3 del RGPD. La AEPD ha confirmado este criterio en varias resoluciones. No realizarla cuando procede constituye por sí mismo una infracción del reglamento.
¿Puede el proveedor anti-fraude subcontratar sin informar al responsable?
No. El artículo 28.2 del RGPD exige autorización previa, específica o general, del responsable del tratamiento. Si la autorización es general, el encargado debe informar de cualquier cambio en los subencargados y dar al responsable la oportunidad de oponerse. La omisión es causa directa de responsabilidad para el responsable.
¿Cuánto tiempo pueden conservarse los registros de análisis de fraude?
Depende del resultado del análisis y de la base de legitimación aplicada. Los metadatos de mensajes descartados como legítimos deben eliminarse o anonimizarse en plazos breves. Los registros de alertas confirmadas pueden conservarse el tiempo necesario para responder a reclamaciones o requerimientos regulatorios, siempre con justificación documentada.
Checklist ejecutivo: cinco decisiones antes de poner en producción cualquier sistema anti-fraude sobre mensajería
- Documente la base de legitimación antes del despliegue. Defina si aplica obligación legal (artículo 6.1.c), interés legítimo (artículo 6.1.f) u otra base. Si es interés legítimo, redacte y archive el test de ponderación. Ningún sistema anti-fraude debería arrancar sin este documento firmado por el DPO.
- Firme el contrato de encargado de tratamiento conforme al artículo 28 del RGPD. Exija a su proveedor que identifique explícitamente a todos sus subencargados y que le notifique cualquier cambio antes de que sea efectivo. Verifique que el contrato incluye las obligaciones de confidencialidad, seguridad y asistencia en ejercicio de derechos.
- Realice y archive la DPIA antes de activar el tratamiento a escala. No después. Una DPIA realizada a posteriori tras una incidencia tiene escaso valor mitigador ante la AEPD. Incluya plazos de retención diferenciados por tipo de dato y resultado del análisis.
- Establezca plazos de retención concretos y técnicamente aplicados. No basta con declararlos en la política. El sistema debe borrar o anonimizar automáticamente los registros al vencer el plazo. Documente el mecanismo técnico en la DPIA y en el Registro de Actividades de Tratamiento.
- Revise el alineamiento con DORA si su entidad es una entidad financiera en ámbito de aplicación. El Reglamento (UE) 2022/2554, aplicable desde enero de 2025, impone requisitos de gestión de riesgos de TIC de terceros (artículos 28 a 44) que se solapan con la relación de encargado del RGPD. Una revisión conjunta de ambas cadenas contractuales evita duplicidades y vacíos.
Si su entidad está en proceso de revisar su arquitectura de tratamiento de mensajería o de preparar la documentación para un piloto, el Pilot Readiness Pack de VeriMsg incluye plantilla de DPIA, borrador de contrato de encargado y matriz de alineamiento regulatorio para RGPD, PSD2 y DORA. Solicítelo a través del formulario de contacto institucional.