PS-00331-2022

1/77  Expediente N.º: EXP202101565 IMI Reference: A56ID 318964 - A60DD 432357 - Case Register 321773 RESOLUCIÓN DE PROCEDIMIENTO SANCIONADOR Del procedimiento instruido por la Agencia Española de Protección de Datos y en base a los siguientes ANTECEDENTES PRIMERO: A.A.A. (en adelante, la parte reclamante) interpuso reclamación, con fecha 5 de agosto de 2021, ante la autoridad de protección de datos de Baviera (Bavarian Lander Office for Data Protection Supervision). La reclamación se dirige contra OPEN BANK, S.A. con NIF A-28021079 (en adelante, OPENBANK). Los motivos en que basa la reclamación son los siguientes: La entidad bancaria OPENBANK ha pedido a la parte reclamante que pruebe el origen de varias cantidades recibidas en su cuenta bancaria, en cumplimiento de la normativa contra el blanqueo de capitales. Sin embargo, no se le ha ofrecido ningún mecanismo para facilitar esta información cifrada o mediante carga directa en el portal web. La única opción válida ha sido el envío por e-mail. Junto a la notificación se aporta: - Copia de correo remitido desde la dirección ***EMAIL.1 a ***EMAIL.2 (en adelante, email de la parte reclamante) de fecha 7 de julio de 2021. En este correo, se requiere a la parte reclamante para que aporte la documentación necesaria para probar cuál es el origen los fondos de tres depósitos realizados por la parte reclamante, en cumplimiento de la legislación de prevención de blanqueo de capitales y contra la financiación del terrorismo; y se indica que, en el caso de no recibir esta documentación en el plazo de 15 días, OPENBANK deberá bloquear la realización de nuevos pagos en su cuenta de acuerdo con la normativa vigente. - Copia de correo remitido desde el email de la parte reclamante a ***EMAIL.1 de fecha 10 de julio de 2021. En este correo la parte reclamante indica que aporta bajo protesta la documentación correspondiente al año 2019 a través de un correo electrónico no encriptado porque, como indicó en una conversación telefónica, no existe la posibilidad de hacer llegar esa documentación electrónicamente de otra manera. - Contestación automática al anterior correo de 10 de julio de 2021 enviada por ***EMAIL.3 hacia la parte reclamante en la que se indica que se ha recibido su correo electrónico y le responderán pronto. SEGUNDO: A través del “Sistema de Información del Mercado Interior” (en lo sucesivo IMI), regulado por el Reglamento (UE) nº 1024/2012, del Parlamento Europeo y del Consejo, de 25 de octubre de 2012 (Reglamento IMI), cuyo objetivo es favorecer la C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 2/77 cooperación administrativa transfronteriza, la asistencia mutua entre los Estados miembros y el intercambio de información, se transmitió la citada reclamación el día 24 de agosto de 2021 y se le dio fecha de registro de entrada en la Agencia Española de Protección de Datos (AEPD) el día 30 de agosto de 2021. El traslado de esta reclamación a la AEPD se realiza de conformidad con lo establecido en el artículo 56 del Reglamento (UE) 2016/679, del Parlamento Europeo y del Consejo, de 27/04/2016, relativo a la Protección de las Personas Físicas en lo que respecta al Tratamiento de Datos Personales y a la Libre Circulación de estos Datos (en lo sucesivo, RGPD), teniendo en cuenta su carácter transfronterizo y que esta Agencia es competente para actuar como autoridad de control principal, dado que OPENBANK tiene su sede social y establecimiento principal en España. Los tratamientos de datos que se llevan a cabo afectan a interesados en varios Estados miembros. Según las informaciones incorporadas al Sistema IMI, de conformidad con lo establecido en el artículo 60 del RGPD, actúa en calidad de “autoridad de control interesada”, además de la autoridad alemana de protección de datos de Baviera, las autoridades de Países Bajos, Portugal y las autoridades alemanas de Renania del Norte-Westfalia, Hesse, Berlín y Baden-Wurtemberg. Todas ellas en virtud del artículo 4.22.

1. b)del RGPD, dado que los interesados que residen en el territorio de estas autoridades de control se ven sustancialmente afectados o es probable que se vean sustancialmente afectados por el tratamiento objeto del presente procedimiento. TERCERO: Con fecha 9 de septiembre de 2021, de conformidad con el entonces vigente artículo 64.3 de la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales (en adelante, LOPDGDD), se admitió a trámite la reclamación presentada por la parte reclamante. CUARTO: La Subdirección General de Inspección de Datos procedió a la realización de actuaciones previas de investigación para el esclarecimiento de los hechos en cuestión, en virtud de las funciones asignadas a las autoridades de control en el artículo 57.1 y de los poderes otorgados en el artículo 58.1 del Reglamento (UE) 2016/679 (Reglamento General de Protección de Datos, en adelante RGPD), y de conformidad con lo establecido en el Título VII, Capítulo I, Sección segunda, de la LOPDGDD, teniendo conocimiento de los siguientes extremos: En contestación a un requerimiento de información formulado por esta Agencia, OPENBANK aporta el 19 de mayo de 2022, entre otra, la siguiente información: 1. Indicación de que OPENBANK tiene delegado el servicio de solicitud de información a clientes a la entidad Santander Global Operations, S.A. (en adelante, SGO), que pertenece al grupo Santander, y que actúa en este caso como encargada del tratamiento. 2. Indicación de que tienen definido un procedimiento interno denominado “Protocolo de comunicaciones a clientes por alertas de PBC/FT: Apertura y gestión de GAPS” para establecer la forma de actuación de SGO cuando sea necesario solicitar información o documentación justificativa de un ingreso no habitual. Este procedimiento se aplicaría en todos los países en los que OPENBANK presta servicio en régimen de libre prestación de servicios, entre los que se incluyen C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 3/77 España y Alemania. Según lo indicado en el escrito, este procedimiento consiste en que “el centro de atención telefónica de Openbank (en adelante, “call center”), contactará con el cliente para solicitar dicha información al número de teléfono móvil registrado en la base de datos de Openbank. Adicionalmente, se envía un correo electrónico a la dirección registrada en nuestra base de datos desde el buzón de ***EMAIL.4 a clientes españoles o desde ***EMAIL.1 a clientes alemanes. En aquellos casos en los que el cliente solicite información sobre otros canales a través de los cuales puede remitir la documentación requerida, se informa que tiene a su disposición los siguientes: (
2. i)por correo postal y (
3. ii)presencialmente en cualquiera de las dos sucursales que Openbank tiene en Madrid.”. Y manifiesta que se aporta el modelo de comunicación para ambos canales de contacto, que sería el siguiente: Estimado cliente: El motivo de nuestra comunicación es informarle que Openbank está obligado, en cumplimiento de la legislación vigente, a conocer la actividad económica y origen de los fondos de sus clientes. A. Para una operación especifica: En esta comunicación le solicitamos documentación que acredite el origen de los fondos que con fecha […] ha ingresado en Openbank por un importe total de [...] €. Puede enviarnos cualquier documento que justifique el origen de los mencionados fondos. B. Para operaciones regulares: En esta comunicación le solicitamos documentación que acredite el origen de los fondos que de forma regular ha venido ingresando desde [...] y hasta la fecha por un importe total de [...] €. Puede enviarnos cualquier documento que justifique el origen de los mencionados fondos. Esta documentación la puede enviar a la siguiente dirección de correo electrónico: [***EMAIL.5 para clientes españoles o ***EMAIL.1 para clientes alemanes] indicando en el correo su nombre completo. Le informamos que Openbank, actuando en calidad de responsable del tratamiento de sus datos personales, tratará los mismos para el cumplimiento de las obligaciones legales a las que Openbank está sujeta adoptando medidas técnicas y organizativas suficientes para garantizar la seguridad de la información. Más información sobre sus derechos y protección de datos en [***URL.1 para clientes españoles o ***URL.2 para clientes alemanes] Quedando a su disposición para cuantas aclaraciones precise, reciba un cordial saludo 3. Respecto a las medidas que se toman para garantizar la confidencialidad de la documentación que envía el cliente para justificar un ingreso no habitual, se indica, entre otras medidas, la siguiente: Por último, teniendo en cuenta la seguridad que ofrecemos en nuestras páginas web y aplicaciones móviles, y que Openbank es un banco 100% digital les informamos que existen diferentes procesos en la entidad, como la contratación de préstamo hipotecario, préstamo personal o cuenta corriente, que permiten que los clientes nos remitan documentación a través del área privada de cliente donde estarán identificados con su documento de identidad y clave de acceso. En este sentido, nos gustaría indicar que esta C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 4/77 funcionalidad se encuentra implantada y en funcionamiento para dar cumplimiento a la obligación de PBC/FT de aplicar medidas para garantizar el conocimiento que tiene Openbank de sus clientes y garantizar que los documentos, datos e información de que se disponga estén actualizados. Les adjuntamos a modo de ejemplo como Anexo V: Flujo de actualización de KYC y documentación de clientes. Y se aportan impresiones de pantalla del formulario de conocimiento del cliente en el que se observa que, al finalizar la cumplimentación del formulario, se ofrece la opción de actualizar los documentos de “Documento de actividad económica” y de “Verificación de domicilio” cargándolos en ese momento. 4. Como “Anexo IV: Soporte contractual del servicio prestado por SGO”, se aporta copia de un documento denominado “ANEXO 12 SERVICIO PREVENCIÓN DE BLANQUEO DE CAPITALES”, en el que se indica que es anexo al contrato marco de arrendamiento de servicios entre OPENBANK (como cliente) y SGO (como proveedor) suscrito el 1 de enero de 2020 por un año prorrogable por periodos anuales. Este anexo está fechado el 16 de octubre de 2020 y su objeto es “la prestación por el Proveedor al Cliente de un servicio de Back Office para las actividades relacionadas a la prevención del blanqueo de capitales y financiación del terrorismo”, con el siguiente contenido relevante: - En la cláusula primera: (…). - En la cláusula quinta, respecto a la protección de datos de carácter personal, se indica que (…). Además, en esta cláusula quinta se indica que (…). Y, en la cláusula quinta.
4. d)se indica lo siguiente: (…). - En la cláusula sexta, sobre requisitos de ciberseguridad, se incluye el siguiente apartado sobre las transferencias de datos: (…). - En la cláusula undécima, sobre la subcontratación, se indica lo siguiente respecto a las actividades que no se pueden subcontratar: (…). CONCLUSIONES DE LAS ACTUACIONES PREVIAS DE INVESTIGACIÓN 1. Las comunicaciones con los clientes por alertas de prevención de blanqueo de capitales y financiación del terrorismo están subcontratadas a CGO tanto en España C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 5/77 como en Alemania. Informan de que existe un protocolo para realizar estas comunicaciones en el que se indica que, en estos casos, se contacta con el cliente utilizando el teléfono que tiene previamente registrado y, adicionalmente, se le envía un correo electrónico a la dirección de email que tiene previamente registrada. 2. De acuerdo con este protocolo, en la comunicación que se envía por correo electrónico para solicitar información al cliente por alertas de blanqueo de capitales, los canales que se le ofrecerían al cliente para enviar documentación serían los siguientes: correo electrónico, correo postal o presencialmente en las oficinas de OPENBANK en Madrid. 3. OPENBANK dispone de una manera para cargar documentos de forma segura (a través de su sitio web) para algunos procedimientos (por ejemplo, para actualizar los documentos “Documento de actividad económica” y “Verificación de domicilio” en el formulario de conocimiento del cliente). Esta manera de cargar documentos no se le ofrece al cliente dentro del protocolo por alertas de blanqueo de capitales, de acuerdo con lo indicado en la reclamación. QUINTO: Con fecha 26 de agosto de 2022, la Directora de la AEPD adoptó un proyecto de decisión de inicio de procedimiento sancionador. Siguiendo el proceso establecido en el artículo 60 del RGPD, el 30 de agosto de 2022 se transmitió a través del sistema IMI este proyecto de decisión y se les hizo saber a las autoridades interesadas que tenían cuatro semanas desde ese momento para formular objeciones pertinentes y motivadas. Dentro del plazo a tal efecto, las autoridades de control interesadas no presentaron objeciones pertinentes y motivadas al respecto, por lo que se consideró que todas las autoridades estaban de acuerdo con dicho proyecto de decisión y estaban vinculadas por éste, de conformidad con lo dispuesto en el apartado 6 del artículo 60 del RGPD. Este proyecto de decisión se notificó a OPENBANK conforme a las normas establecidas en la Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas (LPACAP) el día 29 de agosto de 2022, como consta en el acuse de recibo que obra en el expediente. SEXTO: Con fecha 3 de octubre de 2022, la Directora de la Agencia Española de Protección de Datos acordó iniciar procedimiento sancionador a OPENBANK, con arreglo a lo dispuesto en los artículos 63 y 64 de la LPACAP, por la presunta infracción del Artículo 25 del RGPD, tipificada en el Artículo 83.4 del RGPD, así como por la presunta infracción del artículo 32 del RGPD, tipificada en el artículo 83.4 del RGPD. En dicho Acuerdo de Inicio se le indicaba a OPENBANK que tenía un plazo de diez días para presentar alegaciones. Este Acuerdo de Inicio, que se notificó a OPENBANK conforme a las normas establecidas en la Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas (LPACAP), fue recogido en fecha 3 de octubre de 2022, como consta en el acuse de recibo que obra en el expediente. SÉPTIMO: Con fecha 6 de octubre de 2022, OPENBANK presentó un escrito a través del cual solicitaba la ampliación del plazo para aducir alegaciones y que se le facilitara copia del expediente. C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 6/77 OCTAVO: Con fecha 14 de octubre de 2022, el órgano instructor del procedimiento acordó la ampliación de plazo instada hasta un máximo de cinco días, de acuerdo con lo dispuesto en el artículo 32.1 de la LPACAP, y que se le remitiera a OPENBANK copia del expediente. El citado acuerdo se notificó a OPENBANK en fecha 14 de octubre de 2022, como consta en el acuse de recibo que obra en el expediente. NOVENO: Con fecha 26 de octubre de 2022, se recibió en esta Agencia, en tiempo y forma, escrito de OPENBANK en el que aducía alegaciones al Acuerdo de Inicio, acompañado de la siguiente documentación: 1.- Documento “Protocolo de comunicaciones a clientes por alertas de PBC/FT: APERTURA Y GESTIÓN DE GAPS (Versión de marzo de 2021)”. 2.- Documento “Protocolo de comunicaciones a clientes por alertas de vigilancia transaccional de prevención de blanqueo de capitales y financiación del terrorismo (PBC/FT) (Versión de octubre de 2022)”. 3.- Documento “Certificado sobre los apartados 3.10 y 3.11 del Manual de carácter interno de OPENBANK en materia de PBC/FT”. 4.- Documento “Evaluación de Impacto - Seguimiento de clientes y operaciones sensibles (versión agosto 2021)”. 5.- Documento “Evaluación de Impacto - Seguimiento de clientes y operaciones sensibles (versión octubre 2022)”. 6.- Documento “Informe de homologación referido a Santander Global Operations, S.A.” 7.- Documento “Certificado interno de seguridad emitido por Santander Global Technology and Operations, S.L.” 8.- Documento “EVALUACIÓN (…)”. 9.- Documento “VENDOR RISK ASSESSMENT - DP REPORT”. 10.- Subida documentación área privada de cliente. 11.- Imágenes de “Sección: Preguntas Frecuentes en la página web de Openbank”. 12.- Documento “Certificado de disponibilidad de carga de documentos, emitido el 21 de octubre de 2022”. 13.- Documento “Certificado de número de análisis de operativa y de clientes impactados”. DÉCIMO: Con fecha 01 de diciembre de 2022, el órgano instructor del procedimiento acordó la apertura de un período de práctica de pruebas, teniéndose por incorporados la reclamación interpuesta por la parte reclamante y su documentación, los documentos obtenidos y generados durante la fase de admisión a trámite de la reclamación, y el informe de actuaciones previas de investigación que forman parte del procedimiento E/09448/2021, dándose por reproducidas a efectos probatorios, las alegaciones al acuerdo de inicio del procedimiento sancionador referenciado, presentadas por OPENBANK, y la documentación que a ellas acompañaba. Ese mismo día esta Agencia requirió a OPENBANK para que en el plazo de diez días hábiles presentara la siguiente información: C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 7/77 Aportar prueba documental respecto a la protección de datos desde el diseño y por defecto, por la que se requiere a OPEN BANK, S.A. la evaluación de impacto de protección de datos vigente el 07/07/2021, fecha en la que OPEN BANK, S.A. solicitó el envío de documentación a la parte reclamante, ya que en la documentación adjunta a las alegaciones de OPEN BANK, S.A. se aportan versiones posteriores, concretamente, las versiones modificadas de agosto de 2021 y octubre de 2022. La apertura del período de prueba se notificó a OPENBANK conforme a las normas establecidas en la Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas (LPACAP) el día 01 de diciembre de 2022, como consta en el acuse de recibo que obra en el expediente. Con fecha 19 y 28 de diciembre de 2022, OPENBANK ha presentado su respuesta al citado requerimiento. DÉCIMO PRIMERO: Con fecha 11 de abril de 2023 se formula diligencia por el instructor del procedimiento por la que se incorpora al expediente el documento “Informe anual 2021” del Grupo Santander, en el que consta estructura societaria del Grupo Santander y su volumen de negocio. En este informe consta que el volumen de negocio total anual global del Banco Santander, S.A. y sociedades dependientes (Grupo Santander) en el ejercicio financiero anterior a la comisión de la infracción, ejercicio 2020, fue de 44.279 millones de euros (ver páginas 555 y 843 del citado “Informe anual 2021”). DÉCIMO SEGUNDO: Con fecha 23 de mayo de 2023, el órgano instructor del procedimiento dictó propuesta de resolución en la que se proponía, con arreglo a lo dispuesto en los artículos 63 y 64 de la LPACAP, imponer una multa de 1.500.000 de euros a OPENBANK por la infracción del artículo 25 del RGPD, y una multa de 1.000.000 de euros por la infracción del artículo 32 del RGPD, tipificadas ambas en el artículo 83.4 del RGPD. Asimismo, se le indicaba que tenía un plazo de diez días para presentar alegaciones. Esta propuesta de resolución, que se notificó a OPENBANK conforme a las normas establecidas en la Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas (LPACAP), fue recogido en fecha 1 de junio de 2023, como consta en el acuse de recibo que obra en el expediente. DÉCIMO TERCERO: Con fecha 1 de junio de 2023, OPENBANK presenta un escrito a través del cual solicita la ampliación del plazo para aducir alegaciones y que se le facilite copia del expediente. DÉCIMO CUARTO: Con fecha 2 de junio de 2023, el órgano instructor del procedimiento acuerda la remisión a OPENBANK de la copia del expediente, que se recibe mediante mensajería el 8 de junio de 2023, como consta en el acuse de recibo que obra en el expediente DÉCIMO QUINTO: Con fecha 5 de junio de 2023, el órgano instructor del procedimiento deniega la ampliación de plazo solicitada para presentar alegaciones. El citado acuerdo se notifica a OPENBANK ese mismo día, como consta en el acuse de recibo que obra en el expediente. C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 8/77 DÉCIMO SEXTO: Con fecha 14 de junio de 2023, se recibe en esta Agencia, en tiempo y forma, escrito de OPENBANK en el que aduce alegaciones a la propuesta de resolución. En estas alegaciones, en síntesis, manifestaba que: - El contenido de la propuesta de resolución es el mismo que el acuerdo de inicio del presente procedimiento sancionador, por lo que reproducirá las alegaciones ya presentadas. No resulta de aplicación la normativa de prevención de blanqueo de capitales. No existen datos financieros. No resultan exigibles las denominadas “medidas de nivel alto”. Se está vulnerando el principio non bis in idem, o subisidiariamente existiría un concurso medial de infracciones. OPENBANK cumple con el principio de protección de datos desde el diseño. OPENBANK no ha vulnerado el artículo 32 del RGPD. Se está vulnerando el principio de proporcionalidad. De las actuaciones practicadas en el presente procedimiento y de la documentación obrante en el expediente, han quedado acreditados los siguientes: HECHOS PROBADOS PRIMERO: En el documento, sin firmar, que acompaña a las alegaciones al acuerdo de inicio del presente procedimiento, denominado “PROTOCOLO DE COMUNICACIONES A CLIENTES POR ALERTAS DE PBC/FT: APERTURA Y GESTIÓN DE GAPS”, se indica que la primera versión aprobada es del 03/04/2018 y que el 10/03/2021 se ha procedido a la “Revisión actualización y modificación de algunos plazos (reducción de los mismos)”. En el punto 4 del citado documento se detalla: “4. SEGUIMIENTO DE LA PETICIÓN GAP Y BLOQUEO DE CUENTAS Se establece el siguiente proceso y plazos para poder realizar el seguimiento de la solicitud de información relativa a alertas de PBC/FT y establecer los avisos en cuenta, cuando proceda: D: SGO abre GAP solicitando al Contact Center que contacte al Cliente solicitando información/documentación. En caso de que la petición sea urgente o que el tamaño de la petición no quepa en GAP, SGO también la enviará por correo electrónico al Contact Center dejando constancia de este punto en GAP. D+1: Contact Center contacta con el cliente y solicita la información/documentación siguiendo el modelo Primera Comunicación del Anexo I. En primera instancia el contacto será por vía telefónica y además se le enviará un correo electrónico al cliente (Ver Primera Comunicación del Anexo I) detallando la documentación requerida. De no existir una dirección de correo válida se procederá a enviar la solicitud por Correo Postal. El Contact Center registrará en el GAP tanto el envío de esta comunicación como cualquier contacto con el cliente, o la imposibilidad de realizar dicho contacto, y reasignará el GAP a SGO. C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 9/77 SGO revisa GAP y registra en el comentario del GAP la fecha de la siguiente revisión (D+15). D+15: De no haberse recibido la documentación requerida en dicha fecha SGO indicará al Contact Center que debe de reiterar la solicitud de información al cliente a través de un comentario y la reasignación del GAP. D+16: Contact Center vuelve a contactar con el cliente, siguiendo el mismo proceso empleado en D+1 pero en este caso empleando la Segunda Comunicación del Anexo I en la cual se le advierte al cliente de la posibilidad de bloqueo.”(…)” En el Anexo I del citado documento, se indica: “(…)” SEGUNDO: El 7 de julio de 2021 se envió un correo electrónico desde la dirección ***EMAIL.1 hacia ***EMAIL.2. El contenido del correo electrónico es el siguiente (traducción no oficial del original en alemán): “Estimado Sr. A.A.A. el motivo de nuestra comunicación es informarle de que Openbank está obligado, de acuerdo con la legislación vigente, a conocer la actividad económica y el origen de los fondos de sus clientes. En esta comunicación, le solicitamos los documentos que acrediten el origen de los fondos. Importes depositados en Openbank (cuenta finalizada en XXXX). - a (…) - el (…) - el (…) Por favor, envíenos documentos que prueben el origen de estos fondos. Puede enviarnos cualquier documento que justifique el origen de dichos fondos (por ejemplo, impuesto sobre la renta, nómina, contrato de trabajo, contrato de compraventa si se trata de una operación inmobiliaria). Garantizamos la absoluta confidencialidad de la documentación que nos envíe. En caso de no recibir la documentación solicitada en el plazo de 15 días desde la fecha del presente aviso, Openbank podrá, en cumplimiento de la normativa aplicable, impedir que se realicen nuevos ingresos en sus cuentas. Si tiene alguna pregunta al respecto, no dude en ponerse en contacto con nosotros todos los días de 08:00 a 22:00 en el ***TELÉFONO.1. Atentamente Su equipo Openbank” TERCERO: El 10 de julio de 2021 se envió un correo desde el email de la parte reclamante hacia ***EMAIL.1. El contenido del correo electrónico es el siguiente (traducción no oficial del original en alemán): “Estimado Sr. o Sra, Tengo una cuenta de dinero a la vista en Openbank S.A./Madrid desde el año pasado. Ahora me han pedido que aporte pruebas de depósitos a la vista de más de XXXXX euros, pero también de más de XXXX euros. Puedo entender esto como parte de la lucha contra el "blanqueo de dinero". Sin embargo, el banco no ofrece la posibilidad de cargar los datos de forma segura, por ejemplo, a través del portal del cliente. En su C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 10/77 lugar, me veo obligado a transmitir mis datos personales a través de un simple correo electrónico no cifrado. A pesar de preguntar, sólo me ofrecieron esta opción, que me vi obligado a utilizar. Les ruego que comprueben el proceso desde el punto de vista de la protección de datos y, en su caso, tomen las medidas oportunas. Si no es usted la autoridad competente, le ruego que me remita el asunto y me envíe una notificación de presentación. Le saluda atentamente A.A.A.” CUARTO: El 13 de julio de 2021 la parte reclamante recibe en su correo una contestación automática enviada por ***EMAIL.3. El contenido del correo electrónico es el siguiente (traducción no oficial del original en alemán): “Gracias por su solicitud. Le confirmamos que ha sido debidamente recibida y le enviaremos nuestra respuesta en breve. Le recordamos que nuestro horario de correo electrónico es de lunes a domingo de 08:00 a 22:00. Se trata de una respuesta automatizada. Si tiene alguna pregunta, póngase en contacto con ***EMAIL.4. Reciba un cordial saludo, OPENBANK” QUINTO: El documento 4 aportado por OPENBANK junto a las alegaciones al acuerdo de inicio del presente procedimiento sancionador lleva por título “Evaluación de impacto- Seguimiento de clientes y operaciones sensibles”, no está firmado e indica que es de agosto 2021. En su página 41 incluye lo siguiente: SEXTO: Con fecha 19 de mayo de 2022, en respuesta al requerimiento de información formulado por esta Agencia, OPENBANK manifestó: C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 11/77 1.- Que tenía delegado el servicio de solicitud de información a clientes a la entidad Santander Global Operations, S.A. (SGO), que pertenece al grupo Santander, y que actúa en este caso como encargada del tratamiento, según contrato de fecha 16 de octubre de 2020. En el documento “Anexo IV: Soporte contractual del servicio prestado por SGO” de la respuesta al requerimiento de información de esta Agencia, en el punto 6.1 de la cláusula sexta del “ANEXO 12 SERVICIO PREVENCIÓN DE BLANQUEO DE CAPITALES AL CONTRATO MARCO DE ARRENDAMIENTO MARCO DE SERVICIOS Y/O EJECUCION Y/O DESARROLLO DE PROYECTOS SUSCRITO ENTRE SANTANDER GLOBAL OPERATIONS S.A. Y OPEN BANK, S.A. SUSCRITO ENTRE OPENBANK, S.A. Y SANTANDER GLOBAL OPERATIONS, S.A. EL 1 DE ENERO DE 2020” se puede observar: 2.- Que tenía definido un procedimiento interno denominado “Protocolo de comunicaciones a clientes por alertas de PBC/FT: Apertura y gestión de GAPS” cuya finalidad era establecer el protocolo de actualización para la gestión de solicitudes de información a clientes por parte de Santander Global Technology and Operations (en adelante, “SGTO”), entidad perteneciente al Grupo Santander en la que Openbank tiene delegado este servicio como encargado de tratamiento. 3.- Que este procedimiento de gestión de solicitudes de información a clientes se aplicaba en todos los países en los que OPENBANK presta servicio en régimen de libre prestación de servicios, entre los que se incluyen España y Alemania. 4.- Que este procedimiento consistía en que “el centro de atención telefónica de Openbank (en adelante, “call center”), contactará con el cliente para solicitar dicha información al número de teléfono móvil registrado en la base de datos de Openbank. Adicionalmente, se envía un correo electrónico a la dirección registrada en nuestra base de datos desde el buzón de ***EMAIL.4 a clientes españoles o desde ***EMAIL.1 a clientes alemanes. En aquellos casos en los que el cliente solicite información sobre otros canales a través de los cuales puede remitir la documentación requerida, se informa que tiene a su disposición los siguientes: (
5. i)por correo postal y (
6. ii)presencialmente en cualquiera de las dos sucursales que Openbank tiene en Madrid.”. 5.- Que el modelo de comunicación para ambos canales de contacto era el siguiente: (…). 1.Los clientes podrán enviar por correo electrónico adjuntando la documentación encriptada y la contraseña mediante llamada telefónica C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 12/77 SÉPTIMO: El documento 5 aportado por OPENBANK junto a las alegaciones al acuerdo de inicio del presente procedimiento sancionador lleva por título “Evaluación de impacto- Seguimiento de clientes y operaciones sensibles”, no está firmado e indica que es de octubre de 2022. En su página 4, en el punto “1. RESUMEN EJECUTIVO”, en el apartado “Nombre y descripción del tratamiento”, describe el tratamiento de datos aplicable a este caso de la siguiente forma: “Seguimiento de clientes y operaciones en cumplimiento de la normativa de PBC/FT específicamente lo establecido en el artículo 17 las entidades financieras a examinar con especial atención cualquier hecho u operación, con independencia de su cuantía, que, por su naturaleza, pueda estar relacionado con el blanqueo de capitales o la financiación del terrorismo, en particular toda operación o pauta de comportamiento compleja, inusual o sin un propósito económico o lícito aparente, o que presente indicios de simulación o fraude.” En la página 15 del citado documento se clasifica el riesgo de la siguiente forma: Y en la página 43 del citado documento se incluye lo siguiente: OCTAVO: En el documento, sin firmar, que acompaña a las alegaciones al acuerdo de inicio del presente procedimiento, denominado “PROTOCOLO DE C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 13/77 COMUNICACIONES A CLIENTES POR ALERTAS DE VIGILANCIA TRANSACCIONAL DE PREVENCIÓN DE BLANQUEO DE CAPITALES Y FINANCIACIÓN DEL TERRORISMO (PBC/FT)”, se indica que la primera versión aprobada es del 03/04/2018 y que el 10/03/2021 se ha procedido a la “Revisión actualización y modificación de algunos plazos (reducción de los mismos)”. La revisión 3 del documento se indica se realizó el 06/05/2022 y consistió en la “Revisión actualización y modificación de las comunicaciones del Anexo I”, mientras que la revisión 4 indica se realizó el 17/10/2022 y consistió en la “Revisión y actualización del protocolo con el objetivo de adecuarlo al nuevo proceso de subida de documentación por web privada, eliminando que el cliente tenga que remitir la misma a una dirección de correo electrónico. Documento revisado junto con el contact center y Operaciones Cumplimiento”. En el punto 4 del citado documento se detalla: “4. ENVÍO Y RECEPCION DE LA DOCUMENTACION POR PARTE DE LOS CLIENTES En todos los casos (clientes de España y países de pasaporte -Alemania, Países Bajos y Portugal) se informará a los clientes de que suban la documentación requerida al espacio habilitado para ello en el área privada de la web de Openbank indicando, dentro del campo de texto, la información que permita justificar la operativa realizada. El gestor del contact center prestará asistencia a los clientes cuando éstos tengan dificultades para subir la documentación. En caso de que el cliente haya olvidado su usuario y/o clave de acceso a la web de Openbank, se le informará de los pasos a seguir para reestablecer la misma. Además, se ha elaborado una guía de ayuda para los gestores e incorporado información para los clientes dentro del apartado de FAQ de la web.” Y en el “Anexo I- Comunicaciones a clientes para solicitar información y/o documentación por una alerta de vigilancia transaccional de PBC/FT” se explica: “(…)” NOVENO: A fecha 13 de octubre de 2022 OPENBANK tenía habilitado dentro del área privada de la página web del banco (que requiere usuario y contraseña de acceso) un espacio para que los clientes pudieran facilitar la documentación requerida en cumplimiento de lo dispuesto en el artículo 6 de la Ley 10/2010, de 28 de abril, de prevención del blanqueo de capitales y de la financiación del terrorismo. DÉCIMO: Durante el período de prueba, OPENBANK aportó un fichero de tipo Excel “DOCUMENTO_NUM._1.XLSX” sin firma ni fecha, en el que en la pestaña “0.Hoja de Control” se puede observar al inicio y en rojo “Data Privacy Impact Assessment (DPIA)”. Y en la pestaña “2. Ciclo de vida” de este fichero, bajo el título “Captura de Datos”, se contempla en el apartado “Actividades u operaciones de tratamiento” la “Extracción de la operativa de transaccionalidad del cliente de los sistemas core del Banco”. (…): C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 14/77 2. Ciclo de vida del tratamiento I nformación General El siguiente formulario debe recoger toda aquella información adicional que permita una adecuada identificación de amenazas y valoración de los riesgos a los que están expuestos los datos de carácter personal afectados. Es necesariindicar, a grandes rasgos, cómo sería el ciclo de vida del tratamiento, desde que los datos son capturados, de qué forma son almacenados o clasificados, con qué finalidad son utilizados, la existencia de cesiones o transferencias (ya sea a otras empresas nacionales o internacionales) y finalmente una descripción de cómo se procede a su destrucción. Captura de datos Almacenamiento / clasificación Flujo y datos tratados Datos de carácter identificativo Datos económicos, financieros y de seguros Datos de carácter identificativo Datos económicos, financieros y de seguros Datos de carácter identificativo Datos económicos, financieros y de seguros Datos de carácter identificativo Datos económicos, financieros y de seguros N/ A I ntervinientes en las actividades u operaciones del tratamiento (incluyen encargados de tratamiento) N/ A N/A GEOBAN (encargado del seguimiento de alertas) BANCO SANTANDER SA (Análisis de operativa de segundo nivel) Sepblac N/ A Tecnología involucrada en las actividades del tratamiento Partenon Herramientas ofimáticas (Excel). Herramienta Norkom Aplicativo FI OC Editran N/ A Ciclo de vida del tratamiento Actividades u operaciones de tratamiento Cesión de los datos o Destrucción/ Uso / tratamiento transferencias a un tercero pseudonimización Seguimiento y monitorización Los datos no se destruyen, del perfil transaccional del se almacenan de forma Extracción de la operativa de cliente, por medio del Cesión de datos del cliente a indefinida. No obstante se transaccionalidad del cliente Almacenamiento de datos en análisis de sus posiciones y través de la herramienta limita la profundidad de los sistemas core del listas internas de fraude. operativa en los distintos Editran histórica de la información Banco productos contratados con que se consulta de un mismo Openbank y ponderación cliente. DÉCIMO PRIMERO: El Banco Santander, S.A. tiene la participación directa del 100% de Open Bank, S.A. (ver página 816 del “Informe anual 2021” del Grupo Santander). El volumen de negocio total anual global del Banco Santander, S.A. y sociedades dependientes (Grupo Santander) en el ejercicio financiero anterior a la comisión de la infracción, ejercicio 2020, fue de 44.279 millones de euros (ver páginas 555 y 843 del “Informe anual 2021”). DÉCIMO SEGUNDO: El número de clientes total de OPENBANK es superior a 1,7 millones de clientes (Fuente: ***URL.3) DÉCIMO TERCERO: El número de peticiones, realizado por OPENBANK, de análisis de operativa en cumplimiento del art. 6 de la Ley 10/2010, de 28 de abril, de prevención del blanqueo de capitales y de la financiación del terrorismo y el número de clientes por ello impactados durante los años 2020, 2021 y 2022 ha sido el siguiente, de acuerdo a lo expuesto en el Documento 13 que acompaña a sus alegaciones al acuerdo de inicio del presente procedimiento sancionador: FUNDAMENTOS DE DERECHO I Competencia y normativa aplicable De acuerdo con los poderes que el artículo 58.2 del Reglamento (UE) 2016/679 (Reglamento General de Protección de Datos, en adelante RGPD), otorga a cada autoridad de control y según lo establecido en los artículos 47, 48.1, 64.2 y 68.1 y 68.2 C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 15/77 de la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales (en adelante, LOPDGDD), es competente para iniciar y resolver este procedimiento la Directora de la Agencia Española de Protección de Datos. Asimismo, el artículo 63.2 de la LOPDGDD determina que: “Los procedimientos tramitados por la Agencia Española de Protección de Datos se regirán por lo dispuesto en el Reglamento (UE) 2016/679, en la presente ley orgánica, por las disposiciones reglamentarias dictadas en su desarrollo y, en cuanto no las contradigan, con carácter subsidiario, por las normas generales sobre los procedimientos administrativos.” II Cuestiones Previas En el presente caso, de acuerdo con lo establecido en el artículo 4.1 y 4.2 del RGPD, consta la realización de un tratamiento de datos personales, toda vez que OPENBANK, a través de la entidad Santander Global Operations, S.A. como encargada del tratamiento, realiza la recogida, conservación y comunicación de, entre otros, los siguientes datos personales de personas físicas: nombre, apellidos, número de identidad fiscal, correo electrónico y el origen de los ingresos de los clientes, entre otros tratamientos. OPENBANK realiza esta actividad en su condición de responsable del tratamiento, dado que es quien determina los fines y medios de tal actividad, en virtud del artículo 4.7 del RGPD. El RGPD dispone, en su artículo 56.1, para los casos de tratamientos transfronterizos, previstos en su artículo 4.23), en relación con la competencia de la autoridad de control principal, que, sin perjuicio de lo dispuesto en el artículo 55, la autoridad de control del establecimiento principal o del único establecimiento del responsable o del encargado del tratamiento será competente para actuar como autoridad de control principal para el tratamiento transfronterizo realizado por parte de dicho responsable o encargado con arreglo al procedimiento establecido en el artículo 60. En el caso examinado, como se ha expuesto, OPENBANK tiene su establecimiento principal en España, por lo que la Agencia Española de Protección de Datos es la competente para actuar como autoridad de control principal. Por su parte, el artículo 25 del RGPD regula la protección de datos desde el diseño y por defecto, que el responsable del tratamiento aplicará, tanto en el momento de determinar los medios de tratamiento como en el momento del propio tratamiento y, por otra, en el artículo 32 del RGPD se regulan las medidas de seguridad que deben adoptarse para garantizar un nivel de seguridad adecuado al riesgo que presente el tratamiento de datos personales. III Alegaciones aducidas C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 16/77 Con relación a las alegaciones aducidas a la propuesta de resolución del presente procedimiento sancionador, se procede a dar respuesta a las mismas según el orden expuesto por OPENBANK. PRIMERA.- CONSIDERACIONES GENERALES ACERCA DEL CONTENIDO DE LA PROPUESTA DE RESOLUCIÓN Alega OPENBANK que la estructura y contenido de la propuesta de resolución no solo resulta extremadamente compleja y difícil de seguir, sino que, como consecuencia de todo ello, la AEPD incurre en numerosas contradicciones. En este sentido, alega que la propuesta de resolución dedica el fundamento de derecho III a la contestación a las alegaciones aducidas por OPENBANK al acuerdo de inicio del presente procedimiento sancionador, a cuyo objeto reproduce casi literalmente las alegaciones efectuadas por OPENBANK tratando de contraargumentar, una por una, lo señalado en cada una de ellas, pero que, posteriormente, la propuesta de resolución reproduce en los fundamentos de derecho IV y siguientes, de forma prácticamente literal y con mínimas alteraciones, el contenido del citado acuerdo de inicio, sin efectuar razonamiento o adición alguna a lo que ya se invocó por la Agencia en el momento de iniciarse el procedimiento. Y alega que lo señalado en el fundamento de derecho III de la propuesta de resolución entra en abierta contradicción con lo mencionado a partir de su fundamento de derecho IV, dado que en el primero de estos fundamentos la AEPD niega sostener la argumentación o razonamiento que, posteriormente, reproduce y utiliza para ratificarse en su postura en los siguientes fundamentos de derecho. Indica que esto conduce en primer lugar a una conclusión, obvia: si el razonamiento de la AEPD es exactamente el mismo que se mantuvo en el acuerdo de inicio, OPENBANK no puede sino ratificarse en todas y cada una de las alegaciones previamente efectuadas al citado acuerdo. Al respecto, esta Agencia reconoce que es posible que la redacción de los fundamentos de derecho posteriores al que da respuesta a las alegaciones presentadas por OPENBANK fuera mejorable, razón por la cual se dará una nueva redacción que simplifique la lectura de la resolución, a la vez que se mejore la motivación en relación con la comisión de la infracción, así como la sanción a imponer y evite posibles confusiones. SEGUNDA.- ACERCA DE LAS PREMISAS SOSTENIDAS POR LA AEPD A LO LARGO DEL PROCEDIMIENTO OPENBANK, en sus alegaciones al Acuerdo de Inicio puso de manifiesto cómo aquél (y la Propuesta) se fundaba en tres argumentos esenciales: (
7. i)que OPENBANK estaba sujeta en lo que respecta al cumplimiento de las obligaciones de diligencia debida, a lo establecido en el artículo 32 de la Ley 10/2010, de 28 de abril, de prevención del blanqueo de capitales y de la financiación del terrorismo (en adelante, la “LPBCFT”) y 60.2 de su Reglamento de desarrollo, aprobado por Real Decreto 304/2014, de 5 de mayo (en adelante, el “RPBCFT”); (
8. ii)que la AEPD consideraba que la información solicitada por OPENBANK a la parte reclamante tenía la consideración C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 17/77 de “dato financiero”, que exigía la adopción de medidas reforzadas y no valoradas por OPENBANK; y (iii) que debían implementarse medidas de seguridad “de nivel alto”. Se alega que la propuesta de resolución no contradice lo argumentado por OPENBANK, sino que niega la aplicación por el Acuerdo de Inicio de las citadas premisas, algo que, a su juicio, directamente se contradice del hecho mismo de la lectura de la propia propuesta, dado que los párrafos transcritos por OPENBANK siguen apareciendo, literalmente, en los fundamentos de derecho IV y siguientes de misma. Al respecto, esta Agencia se reitera en que: (
9. i)el objeto del presente procedimiento no es la vulneración de lo dispuesto en la normativa de prevención de blanqueo de capitales sino la vulneración de lo previsto en los artículos 25 y 32 del RGPD, normativa aplicable a la protección de datos personales de las personas físicas, que es la competencia de esta Agencia; (
10. ii)la información solicitada por OPENBANK a la parte reclamante sí que tiene la consideración de “dato financiero”, lo cual exigía la aplicación de una serie de medidas reforzadas para aplicar de forma efectiva los principios de protección de datos e integrar las garantías necesarias en el tratamiento a fin de cumplir los requisitos del RGPD y proteger los derechos de los interesados (a tenor de lo dispuesto en el artículo 25 del RGPD), así como la aplicación de medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo (a tenor de lo dispuesto en el artículo 32 del RGPD); (iii) que en el presente caso no se trata de que debieran implantarse medidas de seguridad “de nivel alto”, sino que se trata de que debían implantarse medidas que garantizaran un nivel de seguridad adecuado al riesgo para los derechos y libertades de las personas físicas. No obstante, esta Agencia reconoce que es posible que la redacción de los fundamentos de derecho posteriores al que da respuesta a las alegaciones presentadas por OPENBANK fuera mejorable, razón por la cual se dará una nueva redacción que simplifique la lectura de la resolución, a la vez que se mejore la motivación en relación con la comisión de la infracción y la sanción a imponer y evite posibles confusiones. 1. Sobre la aplicabilidad de la normativa de prevención del blanqueo de capitales Alega OPENBANK que, en relación con la supuesta aplicabilidad a las obligaciones de diligencia debida de lo establecido en el artículo 32 de la LPBCFT, la propuesta de resolución establece una premisa: que lo dispuesto en la normativa de prevención del blanqueo de capitales y la financiación del terrorismo resulta irrelevante en el presente caso, dado que (
11. i)“la tipificación de los hechos no está motivada por una infracción de los artículos 32 y 32 bis de la Ley 10/2010, como dice OPENBANK en sus alegaciones, sino por los artículos 25 y 32 del RGPD”; (
12. ii)“no es objeto del presente procedimiento si se ha vulnerado o no lo dispuesto en el artículo 32 o 32 bis de la LPBCFT, toda vez que no es la autoridad competente para ello y el bien jurídico protegido por la citada normativa es distinto al bien jurídico protegido por la normativa C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 18/77 de protección de datos”; y (iii) en relación con la invocación por OPENBANK de los informes de la propia AEPD “lo que no puede hacerse es, tal y como pretende OPENBANK, utilizarlos para interpretar el contenido de un artículo, el 32.bis, en contraposición al artículo 32, cuando el artículo 32.bis no existía a la fecha de la emisión de tales informes, siendo añadido con posterioridad por el art. 3.15 del Real Decreto-ley 7/2021, de 27 de abril, en vigor a partir del 29/04/2021”. Respecto de la primera de las cuestiones mencionadas, OPENBANK considera que basta una mera lectura del fundamento de derecho IV de la Propuesta de Resolución para poner de manifiesto cómo la AEPD sigue fundamentando toda la imputabilidad de OPENBANK en el supuesto incumplimiento por la misma del artículo 32 de la LPBCFT y cómo dicho precepto se refiere única y exclusivamente al cumplimiento por las entidades obligadas en materia de prevención del blanqueo de capitales a las previsiones relativas a las obligaciones de examen especial de operaciones y comunicación por inicio al Servicio Ejecutivo de la Comisión de Prevención del Blanqueo de Capitales e Infracciones Monetarias (en adelante, el “SEPBLAC”). Al respecto, esta Agencia reconoce que es posible que la redacción de los fundamentos de derecho posteriores al que da respuesta a las alegaciones presentadas por OPENBANK fuera mejorable, razón por la cual se dará una nueva redacción que simplifique la lectura de la resolución, a la vez que se mejore la motivación en relación con la comisión de la infracción y la sanción a imponer y evite posibles confusiones. Del mismo modo, alega OPENBANK que la propuesta de resolución yerra al indicar que lo dispuesto en los artículos 32 y 32 bis de la LPBCFT se encuentra al margen de las competencias de la AEPD, toda vez que se trata de dos normas que regulan las obligaciones de los sujetos obligados en materia de protección de datos personales y no los aspectos sustantivos de la propia normativa de prevención del blanqueo de capitales. Y que estos preceptos se conforman como una norma especial referida a protección de datos personales en el entorno de la normativa de prevención del blanqueo de capitales, del mismo modo que numerosas normas sectoriales incluyen previsiones de protección de datos respecto de las cuales esa AEPD jamás ha negado su competencia, por cuanto no son sino la particularización para un supuesto o sector concreto de las propias normas contenidas en el RGPD y la LOPDGDD. Indica OPENBANK que los preceptos mencionados son los que particularizan las obligaciones que habrán de cumplirse por los sujetos obligados para dar cumplimiento a los deberes de responsabilidad proactiva establecidos en la normativa de protección de datos personales en relación con los tratamientos de datos de esta naturaleza que deban llevar a cabo en cumplimiento de las obligaciones establecidas en la Ley, y, en lo que respecta a este caso, en lo que atañe al cumplimiento del deber de conocimiento del origen de los fondos establecido en la propia normativa de prevención del blanqueo de capitales. Es decir, el cumplimiento del principio de responsabilidad proactiva, y en particular del de privacidad desde el diseño, se materializa en la adopción de las medidas que establece la propia LPBCFT, sin que sea admisible disgregar esta ley del propio RGPD, como si se tratase de normas legales independientes y referidas a realidades distintas. La LPBCFT indica cuáles son esas obligaciones, diferenciando de forma C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 19/77 evidente (y vigente al tiempo de producirse los hechos que han dado lugar al presente expediente) entre las obligaciones relacionadas con los tratamientos llevados a cabo en cumplimiento de la diligencia debida y aquéllas relacionadas con los tratamientos efectuados para el cumplimiento del examen especial de operaciones, de modo que en el presente caso es innegable la aplicación de lo previsto en el artículo 32 bis de la LPBCFT. Al respecto, esta Agencia desea señalar que no puede menos que coincidir con todo lo afirmado por OPENBANK en este sentido. Si bien matizando que la gestión del cumplimiento normativo prevista en el artículo 25 del RGPD no se limita a la aplicación de los preceptos de la LPBCFT que particularizan algunas de las obligaciones en materia de protección de datos reforzando, a mayores, algunas de las obligaciones en relación con determinados tratamientos. De este modo, alega OPENBANK, el cumplimiento del principio de privacidad desde el diseño en los tratamientos llevados a cabo en cumplimiento del Capítulo II de la LPBCFT se traduce en el artículo 32 bis.4 de la ley que dispone que “los sujetos obligados deberán realizar una evaluación de impacto en la protección de datos de los tratamientos a los que se refiere este artículo a fin de adoptar medidas técnicas y organizativas reforzadas para garantizar la integridad, confidencialidad y disponibilidad de los datos personales. Dichas medidas deberán en todo caso garantizar la trazabilidad de los accesos y comunicaciones de los datos”. Y es innegable, a su juicio, que OPENBANK llevó a cabo la mencionada evaluación de impacto en la protección de datos en relación con los citados tratamientos, como lo es que no concibió y aplicó esta obligación como un proceso estático, sino como un proceso dinámico, constando en el expediente las diversas evaluaciones efectuadas por OPENBANK, así como las medidas sucesivamente implementadas por aquélla, entre las cuales se encuentra actualmente la de que la información para el cumplimiento de las obligaciones de diligencia debida se facilitará en el área privada del cliente puesta a disposición del mismo por OPENBANK. Al respecto esta Agencia desea señalar que el cumplimiento del principio de privacidad desde el diseño en los tratamientos llevados a cabo en cumplimiento del Capítulo II de la LPBCFT se traduce en mucho más que lo indicado en el artículo 32 bis.4 de la ley . A estos tratamientos les es de aplicación todo lo indicado en el artículo 25 del RGPD, tal y como le es de aplicación a todos los sujetos incluidos en su ámbito de aplicación. No obstante, en el caso concreto de las entidades sujetas al régimen de la LPBCFT, la obligación de realizar una evaluación de impacto a fin de adoptar medidas reforzadas para garantizar la integridad, confidencialidad y disponibilidad de los datos personales (y como mínimo, garantizar la trazabilidad de los accesos y comunicaciones de los datos), es una obligación a mayores, por la naturaleza misma de los tratamientos llevados a cabo en cumplimiento del Capítulo II de la LPBCFT, los cuales requieren de una mayor protección dado el mayor riesgo para los derechos y libertades de las personas físicas. Cabe significar, asimismo, que la privacidad desde el diseño tampoco se limita a realizar las evaluaciones de impacto de protección de datos referidas en la LPBCFT. C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 20/77 En el presente caso, se pone de manifiesto la falta de diseño del tratamiento por parte de OPENBANK, toda vez que no se ha incluido la actividad de recogida de datos de los clientes en el denominado “ciclo de vida del tratamiento” de su fichero Excel de documento de evaluación de impacto de protección de datos (aportado durante el período de prueba del presente procedimiento); por ello, al no preverse siquiera esta actividad, no se han aplicado las medidas técnicas y organizativas apropiadas para aplicar de forma efectiva los principios de protección de datos (entre otros, la confidencialidad) y cumplir los requisitos del RGPD y proteger los derechos de los interesados. En cuanto a los análisis realizados por OPENBANK en los documentos denominados “Evaluación de Impacto - Seguimiento de clientes y operaciones sensibles”, en su versión de agosto de 2021, la cual ni siquiera estaba vigente al momento de los hechos objeto de la reclamación, los cuales tuvieron lugar en el mes de julio de 2021, sólo se había previsto como una posibilidad que los clientes remitieran la información mediante mensaje cifrado remitiendo la contraseña mediante otro canal. E incluso en el citado documento se menciona que se “ha solicitado una demanda interna para que los interesados puedan subir documentos directamente a través del apartado de la web, una vez que se hayan logado en la misma”. No obstante, se ha podido comprobar que a la parte reclamante nunca se le dio esa posibilidad, ni en la comunicación inicial remitida por OPENBANK ni posteriormente cuando solicitó una vía alternativa segura para el envío de esa comunicación. También se comprobó que en el modelo de comunicación que se enviaba a los clientes no se daba ninguna de estas opciones, sólo se hacía mención a la posibilidad de responder el correo electrónico que se enviaba sin dar más indicaciones sobre cómo podía protegerse dicha información. Resulta curioso que, pese a no facilitar ningún medio lo suficientemente seguro a sus clientes para proporcionar la información a que estaban obligados, ambos documentos en sus versiones de 2021 y 2022 reconocen que el riesgo inherente a tal tratamiento era de alto impacto para los derechos y libertades de los interesados. Y, no obstante, recién es en la versión de octubre de 2022 cuando OPENBANK indica que “los clientes se identificarán mediante DNI y clave de acceso al área privada de cliente”. Lo que sí es cierto es que la comunicación dirigida al cliente cumplía lo previsto en el documento aportado por OPENBANK como protocolo para solicitar la documentación a los clientes en virtud de la LPBCFT y la comunicación dirigida a los clientes no indicaba medio alguno para proporcionar esa información, más allá de la posibilidad de responder el citado correo electrónico. En cualquier caso, para cumplir con la protección de datos desde el diseño y por defecto no es suficiente con simplemente contar con un documento de protocolo o de modelo de comunicación, si luego al revisar dichos documentos se comprueba que no se realizó una previsión en condiciones sobre las medidas técnicas y organizativas apropiadas para aplicar de forma efectiva los principios de protección de datos e integrar las garantías necesarias en el tratamiento a fin de cumplir los requisitos del RGPD y proteger los derechos de los interesados, tal y como dispone el artículo 25.1 del RGPD. C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 21/77 Tampoco es suficiente con contar con documentos que establezcan protocolos o modelos a seguir, si luego en la práctica al realizar el tratamiento no se proporcionan tampoco medidas apropiadas para aplicar los principios de protección de datos ni se integran las garantías necesarias para cumplir con los requisitos del RGPD. En el presente caso, ha quedado acreditado que en julio de 2021 se le solicitó a la parte reclamante que enviara determinada información, que podía tener un alto impacto para sus derechos y libertades, mediante correo electrónico, sin darle más indicaciones sobre cómo podía enviar dicha información a través de un canal seguro. También ha quedado acreditado que la parte reclamante había manifestado al banco su preocupación en este sentido y había solicitado se le facilitara un medio seguro para compartir tal información. Pero, ante la negativa del banco, no le quedó otra opción que enviar la información solicitada a través de un simple correo electrónico, para su disgusto y pese a haber expresado sus reticencias. E incluso la parte reclamante pidió expresamente que se tuviera en cuenta su preocupación y se habilitara un medio seguro a futuro para compartir este tipo de información. No obstante, en los documentos de agosto de 2021 que aportó OPENBANK junto con sus alegaciones al acuerdo de inicio, tampoco se prevé otro medio. Del contenido de la documentación que figura en el expediente, ha quedado acreditado: - Que en el “Anexo I - Comunicaciones a clientes para solicitar información y/o documentación por PBC” del documento ““PROTOCOLO DE COMUNICACIONES A CLIENTES POR ALERTAS DE PBC/FT: APERTURA Y GESTIÓN DE GAPS”, de fecha marzo 2021, en la primera comunicación que se dirige al cliente, en la que se le solicite que acredite el origen de los fondos, no se prevé indicar un medio específico por el cual deba facilitar tal información a OPENBANK. Y que en la segunda comunicación que se dirige al cliente no se prevé indicar tampoco un medio por el cual facilitar tal documentación al banco, pero se incluye en el texto la amenaza de que en caso de no recibir la documentación solicitada en los próximos 15 días OPENBANK puede impedir la realización de nuevos ingresos en sus cuentas. - Que el 7 de julio de 2021 OPENBANK solicitó a la parte reclamante que enviara la documentación que acreditaba el origen de determinados fondos, bajo la amenaza de que en 15 días podían impedir nuevos ingresos en su cuenta, sin indicarle medio alguno por el cual debía facilitar tal información. - Que el 10 de julio de 2021 la parte reclamante aportó la documentación solicitada manifestando su disconformidad porque cuando preguntó por la forma de remitir tal información, le indicaron que lo hiciera por correo electrónico, sin más. Y en este correo electrónico que envía, la parte reclamante indica que no lo considera un medio seguro, que lo realiza a través de este medio porque se vio obligado a ello, e incluso él mismo proporciona como ejemplo de medio seguro la posibilidad de remitirlo “a través del portal del cliente”, posibilidad que no se le proporcionó desde OPENBANK. También ruega que comprueben el C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 22/77 proceso desde el punto de vista de la protección de datos y tomen las medidas oportunas. No obstante, este correo electrónico sólo recibió un acuse de recibo automático por parte del banco, el 13 de julio de 2021. - En el documento “Evaluación de impacto- Seguimiento de clientes y operaciones sensibles”, de agosto 2021, se prevé que el interesado puede responder al correo electrónico con un mensaje cifrado remitiendo la contraseña mediante otro canal. Y que se ha solicitado que se pudiera realizar directamente a través del apartado de la web, una vez logados. - En el documento “Evaluación de impacto- Seguimiento de clientes y operaciones sensibles”, octubre de 2022, se prevé que los clientes se autenticarán mediante su DNI y clave de acceso al área privada de cliente. - En el documento “PROTOCOLO DE COMUNICACIONES A CLIENTES POR ALERTAS DE VIGILANCIA TRANSACCIONAL DE PREVENCIÓN DE BLANQUEO DE CAPITALES Y FINANCIACIÓN DEL TERRORISMO (PBC/FT)”, de octubre 2022, se indica que se informará a los clientes de que suban la documentación a través del área privada de la web de OPENBANK. Y en el “Anexo I- Comunicaciones a clientes para solicitar información y/o documentación por una alerta de vigilancia transaccional de PBC/FT” se indica al cliente que envíe la documentación a través del “Área Clientes” de la web de OPENBANK. Es decir, el protocolo vigente al momento de los hechos (de marzo de 2021) no preveía proporcionar información sobre el método de envío de la documentación solicitada, no obstante los riesgos en los derechos y libertades presentes en tal tratamiento de datos. En julio de 2021 la parte reclamante llama la atención sobre esta cuestión en el correo que envía el 10 de julio de 2021 a OPENBANK. Pero el banco hace caso omiso y ni siquiera se le dio una respuesta a su inquietud, que versaba claramente sobre una cuestión de protección de datos personales, lo cual evidencia también la falta de un procedimiento interno de OPENBANK para canalizar estas cuestiones. En agosto de 2021, OPENBANK prevé la posibilidad de que los clientes envíen la referida documentación a través de un correo electrónico cifrado y facilitando la contraseña mediante otro correo (sin especificar cuál). Y se indica que se solicitó la posibilidad de que se pudiera proporcionar esta documentación a través del área del cliente de la web de OPENBANK. Y no es hasta octubre de 2022 que los protocolos de comunicación y los documentos de supuesta evaluación de impacto de esta cuestión incorporan de forma específica que los clientes puedan aportar la documentación solicitada a través de la página web de OPENBANK, logándose en su área de cliente. Es decir, se adoptó la solución de poder proporcionar esta información a través del área de cliente un año y medio más tarde de que se adoptara el protocolo de actuación de marzo 2021 y más de un año más tarde de que la parte reclamante hubiera llamado la atención sobre esta cuestión en concreto y que el documento de supuesta evaluación de impacto de esta cuestión ya lo hubiera previsto como una posibilidad a C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 23/77 la que había que realizar seguimiento. Todo ello evidencia que OPENBANK no aplicó un enfoque de protección de datos desde el diseño ni antes ni durante la realización del tratamiento, por lo que se desestima la presente alegación. Alega OPENBANK que es perfectamente consciente de que el principio de privacidad desde el diseño exige que las medidas reforzadas para garantizar los derechos de los interesados se lleven a cabo con anterioridad a la práctica del tratamiento, pero que la obligación de que recabe del interesado información acerca del origen de los fondos viene prevista en la LPBCFT, cuya vigencia es anterior en más de ocho años a la del RGPD. Y que OPENBANK venía obligada a llevar a cabo el tratamiento de los datos al que se refiere el presente expediente mucho tiempo antes de que se adoptasen o cobrasen plena aplicación las normas contenidas en el RGPD y la LOPDGDD. Por ello, difícilmente puede exigirse a la misma la aplicación estricta del principio (en el sentido de que las medidas debían ser previas al tratamiento), so pena de incumplir sus obligaciones en materia de prevención del blanqueo de capitales y la financiación del terrorismo. Al respecto, esta Agencia desea señalar que la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal fue aprobada más de 10 años antes que la LPBCFT y que la propia LPBCFT contenía en su redacción original una referencia a la normativa de protección de datos personales en su artículo 32. Y que no cabe ninguna duda de que los sujetos a los que resultaba de aplicación la LPBCFT estaban plenamente sujetos a lo previsto en la normativa entonces vigente sobre protección de datos personales. Con independencia de que hubiera un artículo 32 de la LPBCFT específico para los tratamientos del Capítulo III de la citada Ley (que imponía una serie de mayores obligaciones para los responsables de tratamiento), ello no era óbice para que en el resto de tratamientos fuera de aplicación la normativa de protección de datos personales vigente en cada momento: en un principio, la LOPD de 1999, hasta que resultó de aplicación el RGPD y la LOPDGDD que desplazaron a aquella. Si bien es cierto que el enfoque del RGPD y la LOPDGDD resultó completamente novedoso respecto la normativa de protección de datos anterior, no es menos cierto que OPENBANK contó con tiempo más que suficiente a lo largo de los tres años (seis años si se cuenta desde la adopción del texto RGPD) que transcurrieron entre que se aprobó el RGPD (abril de 2016), hasta que resultó de aplicación el RGPD (mayo 2018, lo que concedía dos años largos para la preparación y adaptación al RGPD) y los hechos objeto de la reclamación a que dio lugar el presente procedimiento sancionador (julio de 2021) para adecuar sus tratamientos a lo dispuesto en los artículo 25 y 32 del RGPD (cuatro años si se tiene en cuenta que recién se adoptaron las medidas para que los clientes pudieran compartir la información solicitada a través de su área privada en octubre de 2022). Por supuesto que hubiera sido imposible que se tuviera un enfoque de protección de datos desde el diseño antes de realizar el tratamiento, cuando éste tuvo lugar muchos años antes de que el RGPD existiera, pero resulta innegable que el principio de protección de datos desde el diseño no implica únicamente que las medidas debían ser previas al tratamiento, sino que el propio artículo 25 del RGPD indica “tanto en el C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 24/77 momento de determinar los medios de tratamiento como en el momento del propio tratamiento”, esto es, no solo de forma previa sino a lo largo de que ese tratamiento tenga lugar y siempre que se determinen los medios de tratamiento, lo cual es una decisión que se va tomando también a lo largo del tiempo, conforme van cambiando las circunstancias y las posibilidades de cada momento. A mayor abundamiento, cabe significar que, sin denostar las obligaciones legales impuestas mediante la LPBCFT, las obligaciones legales previstas en el RGPD están como mínimo al mismo nivel, máxime cuando con estas últimas se protege un derecho fundamental. Obligaciones que tienen que ser cumplidas por OPENBANK, independientemente del cumplimiento de las que devengan de la LPBCFT; y ello sin que el cumplimiento de las previstas en esta última norma imposibilite el cumplimiento de las del RGPD. OPENBANK está focalizando en sus riesgos, en los riesgos para la organización si no cumple con la LPBCFT, y no en los riesgos en los derechos y libertades de sus clientes en materia de protección de datos. Por último, alega OPENBANK que el artículo 32 de la LPBCFT únicamente resulta aplicable a las obligaciones contenidas en su Capítulo III. Y ello hasta el punto de instar al legislador a la adopción de una norma que estableciera específicamente el alcance de dichas obligaciones en materia de protección de datos personales en relación con lo establecido en su Capítulo II de aquella Ley, como finalmente se materializó en el artículo 32 bis de la LPBCFT, añadido por el art. 3.15 del Real Decreto-ley 7/2021, de 27 de abril. Y que sólo de este modo puede interpretarse la conclusión alcanzada por el Informe 195/2013 del Gabinete Jurídico de esta AEPD cuando indica que “la interpretación de que el nivel de seguridad alto es al que se refiere el artículo 32.5 de la Ley 10/2010 es únicamente exigible en relación con los ficheros creados para el cumplimiento de las obligaciones establecidas en el Capítulo III de la citada Ley ha de considerarse congruente con el hecho de que la propia Ley establece determinadas limitaciones al afectado en relación únicamente con dichos ficheros, siendo ese nivel exigible una garantía adicional establecida como contrapeso de las citadas limitaciones” y el hecho de que en el Informe 41/2018 la AEPD instase al legislador la necesidad de regular las obligaciones de protección de datos en el marco del cumplimiento de los deberes de diligencia debida y de examen especial de operaciones, recomendando la redacción de normas diferenciadas para uno y otro tipo de tratamientos. En resumen, alega OPENBANK que la argumentación sostenida por la AEPD debe decaer, dado que fundamenta el supuesto incumplimiento por OPENBANK del principio de privacidad desde el diseño y de la implementación de medidas de seguridad en una norma, el artículo 32 de la LPBCFT, que no resulta aplicable al caso, por haberlo incluso indicado así la propia Agencia. Al respecto, esta Agencia coincide en que no es de aplicación a las obligaciones del Capítulo II de la LPBCFT el artículo 32 de la LPBCFT, sino el artículo 32 bis de la misma, razón por la que se dará una nueva redacción a los fundamentos de derecho posteriores al que da respuesta a las alegaciones presentadas por OPENBANK. EN CONCLUSIÓN: C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 25/77 1.- La gestión del cumplimiento normativo del artículo 25 del RGPD, la privacidad desde el diseño, no se agota con el cumplimiento de las obligaciones en materia de protección de datos previstas en la LPBCFT. 2.- La gestión del cumplimiento normativo del artículo 25 del RGPD no se agota con la realización de evaluaciones de impacto de protección de datos. 3.- OPENBANK no había previsto la actividad de tratamiento consistente en la recogida de datos financieros de los clientes para la prevención del blanqueo de capitales. 4.- Las evaluaciones de impacto de protección de datos efectuadas por la parte reclamante en el momento en el que se produjeron los hechos no recogían la actividad de tratamiento consistente en la recogida de datos financieros de los clientes para la prevención del blanqueo de capitales. 5.- Al no preverse esta actividad por OPENBANK, no se habían identificado y evaluado los riesgos en los derechos y libertades de los clientes presentes en tal tratamiento. 5.- Al no identificarse y evaluarse los riesgos no se han establecido y aplicado las medidas técnicas y organizativas apropiadas para aplicar de forma efectiva los principios de protección de datos (entre otros, la confidencialidad) y cumplir los requisitos del RGPD y proteger los derechos de los interesados (de todos sus clientes). 6.- Todo lo anterior pone de manifiesto, de manera indubitada que OPENBANK no cumplió con su obligación de aplicar el artículo 25 del RGPD, la privacidad desde el diseño ni antes ni durante la realización del tratamiento. 2. Sobre la referencia efectuada por la AEPD a los datos financieros Alega OPENBANK que la propuesta de resolución entra en una clara contradicción, dado que introduce en dos párrafos consecutivos del fundamento de derecho III dos consideraciones diametralmente opuestas y que parecen fundar su reproche sancionador. Así, se indica que “no corresponde determinar el nivel de riesgo y la necesidad de adoptar medidas de seguridad apropiadas en función de los datos financieros de forma aislada, sino según lo que prevé la normativa de protección de datos aplicable al caso, esto es, dependiendo del tipo de tratamiento, así como de manera específica, en materia de prevención de blanqueo de capitales”, lo que parece reforzar la idea, ya rebatida anteriormente, de que es la naturaleza del tratamiento, y no la de la tipología de los datos, la que justifica su reproche. Pero inmediatamente añade que “las circunstancias de hecho del presente caso determinan que deben ser adoptadas medidas de seguridad reforzadas dado que el tratamiento de los datos personales financieros de la parte reclamante presenta un C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 26/77 elevado nivel de riesgo”. Es decir, es la naturaleza de los datos, considerados financieros, y no la finalidad del tratamiento, la que justifica la adopción de unas medidas que la AEPD considera no cumplidas. Al respecto, esta Agencia desea señalar que el análisis y adopción de medidas técnicas y organizativas para aplicar de forma efectiva los principios de protección de datos e integrar las garantías necesarias para cumplir los requisitos del RGPD y proteger los derechos de los interesados (artículo 25 del RGPD) y para aplicar medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo para los derechos y libertades de las personas físicas (artículo 32 del RGPD), no debe realizarse únicamente en virtud de la naturaleza o finalidad del tratamiento que se realice ni únicamente en virtud de la tipología de los datos que se trate, como si fueran aspectos excluyentes, sino que debe realizarse teniendo en cuenta todos los aspectos que el tratamiento en cuestión pudiera entrañar. El análisis efectuado por OPENBANK sobre el concepto de “dato financiero” para determinar si el tratamiento ante el que nos encontramos entraña un mayor riesgo y si esta categoría de datos merecen una especial protección no es correcto, toda vez que pretende valorar de forma separada el concepto “dato financiero” de la normativa de LPBCFT, cuando la necesidad de una evaluación de impacto de protección de datos y la consecuente adopción de medidas reforzadas que garanticen la integridad y confidencialidad de los datos personales, así como la garantizar la trazabilidad de los accesos y comunicaciones de los datos, ya se encuentran establecidas por el ordenamiento jurídico. En cumplimiento de la LPBCFT, las entidades obligadas pueden tratar datos financieros, pero no sólo datos de esta categoría también son tratados datos personales de diversa naturaleza: de identificación, de contacto o económicos (empresariales, profesionales, de inversiones…). La protección de datos en cumplimiento de la LPBCFT no puede verse limitada por los criterios aplicables tan sólo a uno de estos datos, como pretende razonar OPENBANK, cuando lo que trata de proteger es el acceso a la información que suponen todos estos datos personales, no sólo de forma individual, sino a su tratamiento de forma conjunta. Indica OPENBANK que lo anteriormente alegado se refuerza por el hecho de que el fundamento de derecho IV de la propuesta de resolución vuelve a considerar la referencia a los datos financieros efectuada por el considerando 28 del RGPD como esencial para determinar la necesidad de que OPENBANK hubiera establecido una medida adicional en la recogida de los datos relacionados con el origen de los fondos. Al respecto, esta Agencia desea señalar que no entiende la referencia que se realiza al considerando 28 del RGPD, toda vez que éste trata de la seudonimización de los datos. En cualquier caso, la referencia a los datos financieros sí que es determinante, dado que son datos que merecen una especial protección al suponer su tratamiento un mayor riesgo para los derechos y libertades de las personas físicas. Alega OPENBANK que, en cuanto a la referencia efectuada por la AEPD a las Directrices del Grupo de Trabajo del artículo 29 (en adelante, el “GT29”), baste señalar que el tratamiento controvertido ni supone ningún tipo de “evaluación o puntuación” de los interesados ni su contraste con “una base de datos de referencia de crédito o una C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 27/77 base de datos contra el blanqueo de capitales y la financiación del terrorismo”, sino sólo la obtención de información sobre el origen de los fondos correspondientes a determinadas operaciones. Al respecto, esta Agencia desea recordar el contenido de las “Directrices sobre la evaluación de impacto relativa a la protección de datos (EIPD) y para determinar si el tratamiento «entraña probablemente un alto riesgo» a efectos del Reglamento (UE) 2016/679”, en lo que aquí interesa: “Con el fin de ofrecer un conjunto más concreto de operaciones de tratamiento que requieran una EIPD debido a su inherente alto riesgo (…) se deben considerar los nueve criterios siguientes: 1. Evaluación o puntuación, incluida la elaboración de perfiles y la predicción, especialmente de «aspectos relacionados con el rendimiento en el trabajo, la situación económica, la salud, las preferencias o intereses personales, la fiabilidad o el comportamiento, la situación o los movimientos del interesado» (considerandos 71 y 91). Algunos ejemplos de esto podrán incluir a una institución financiera que investigue a sus clientes en una base de datos de referencia de crédito o en una base de datos contra el blanqueo de capitales y la financiación del terrorismo o sobre fraudes…” (el subrayado es nuestro). Esta Agencia considera que la actividad realizada por OPENBANK en virtud de lo dispuesto en el Capítulo II de la LPBCFT, por la que se le solicita a los clientes que aporten los “soportes que justifican un determinado ingreso, por cuanto permitirán de clarificar el origen de los fondos que han sido ingresados en la cuenta del cliente en OPENBANK” sí que se enmarca dentro de una institución financiera que investigue a sus clientes en una posible base de datos contra el blanqueo de capitales y la financiación del terrorismo, razón por la que son operaciones que entrañan probablemente un mayor riesgo. Y tanto ello es así, que son operaciones que entrañan probablemente un mayor riesgo, que la misma LPBCFT consideró conveniente incorporar la necesidad de realizar una evaluación de impacto de la protección de datos de los tratamientos a los que se refiere dicho artículo a fin de adoptar medidas técnicas y organizativas reforzadas para garantizar la integridad, confidencialidad y disponibilidad de los datos personales. Asimismo, alega OPENBANK que la propuesta de resolución parece indicar que OPENBANK no ha llevado a cabo evaluación alguna del impacto del tratamiento en la protección de datos, lo que entra en directa contradicción con el expediente administrativo, en que consta la misma, así como las medidas adoptadas para paliar los riesgos sobre la protección de datos derivados del tratamiento. Al respecto, esta Agencia desea recordar que el objeto del presente procedimiento no es si OPENBANK realizó o no una evaluación de impacto tal y como le obliga el artículo 32 de la LPBCFT, sino si la organización había incorporado los principios de protección de datos desde el diseño y por defecto (artículo 25 del RGPD) y si había adoptado las medidas de seguridad apropiadas en relación al riesgo para los derechos y libertades de los interesados (artículo 32 del RGPD). En el presente caso, se pone de manifiesto la falta de diseño del tratamiento por parte de OPENBANK, toda vez que no se ha incluido la actividad de recogida de datos de los clientes en el denominado “ciclo de vida del tratamiento” de su fichero Excel de documento de evaluación de impacto de protección de datos (aportado durante el C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 28/77 período de prueba del presente procedimiento); por ello, al no preverse siquiera esta actividad, no se han aplicado las medidas técnicas y organizativas apropiadas para aplicar de forma efectiva los principios de protección de datos (entre otros, la confidencialidad) y cumplir los requisitos del RGPD y proteger los derechos de los interesados. Por lo demás, esta Agencia se reitera en lo ya contestado en la alegación sobre la aplicabilidad de la normativa de prevención del blanqueo de capitales respecto al análisis del contenido de las comunicaciones enviadas a la parte reclamante así como de la documentación aportada al expediente, todo lo cual evidencia que OPENBANK no aplicó un enfoque de protección de datos desde el diseño ni antes ni durante la realización del tratamiento. Alega OPENBANK que, tanto el Manual de legislación europea sobre protección de datos como la Guía sobre gestión del riesgo de la AEPD se refieren, al mencionar los datos financieros, a los relacionados con los medios de pago, aun cuando la propuesta de resolución parezca negar, de forma terminante y no fundada, dicha afirmación. Al respecto, esta Agencia desea recordar el contenido del Capítulo 9.2 del Manual de legislación europea en materia de protección de datos, elaborado por la Agencia de la Unión Europea para los Derechos Fundamentales, el Consejo de Europa, el Tribunal Europeo de Derechos Humanos y el Supervisor Europeo de Protección de Datos donde se refiere a los “datos financieros”: ”A pesar de que los datos financieros no se consideran datos sensibles en virtud del Convenio 108 o del Reglamento general de protección de datos, su tratamiento requiere garantías especiales que garanticen la exactitud y la seguridad de los datos. En particular, los sistemas de pago electrónico necesitan incorporar medidas de protección de datos, es decir, protección de la privacidad o de los datos desde el diseño y por defecto”. La mención a la protección de la privacidad respecto a los sistemas de pago electrónico viene a resaltar la importancia de éstos, pero no excluye que, de igual manera, otros datos financieros puedan requerir garantías especiales, tal y como ocurre en el presente caso con los datos recogidos en virtud de lo dispuesto en el Capítulo II de la LPBCFT. En cuanto a la Guía sobre la gestión del riesgo y evaluación de impacto en tratamientos de datos personales de la AEPD, se diferencia entre tres tipologías de datos económicos que deben valorarse a la hora de determinar el nivel de riesgo de un determinado tratamiento para la realización de la DPIA, diferenciando entre estas tres categorías de datos: • Datos relacionados con la “[s]ituación económica, (P.ej., sin ser exhaustivos, renta personal, Ingresos mensuales, Patrimonio (bienes muebles/inmuebles), Situación laboral)”. A estos datos se les asigna un “riesgo medio”. • Datos relacionados con el “[e]stado financiero (P. ej,. sin ser exhaustivos, solvencia financiera, capacidad de endeudamiento, nivel de deuda (Préstamos personales, hipotecas), listas de solvencia, impagos, activos (fondos de inversión, rendimientos generados, acciones, cuentas a cobrar, rentas percibidas, etc.), pasivos (gastos en alimentación, vivienda, educación, salud, impuestos, pagos de créditos, tarjetas de crédito o gastos personales, etc.; o deudas u obligaciones)”. A estos datos también se les asigna un “riesgo medio”. C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 29/77 • “Datos de medios de pago (P. ej., sin ser exhaustivos, tarjetas de crédito e información de acceso a servicios de monedas virtuales)”. En el caso de estos datos sí se asigna un “riesgo alto”. OPENBANK añadió en sus alegaciones al acuerdo de inicio del presente procedimiento sancionador que, en los criterios establecidos por la AEPD para la realización de una DPIA se recogen en el número 4 los “[t]ratamientos que impliquen el uso de categorías especiales de datos a las que se refiere el artículo 9.1 del RGPD, datos relativos a condenas o infracciones penales a los que se refiere el artículo 10 del RGPD o datos que permitan determinar la situación financiera o de solvencia patrimonial o deducir información sobre las personas relacionada con categorías especiales de datos”. Y que el elevado riesgo que debería justificar la implementación de lo que dicho Acuerdo denomina “medidas de seguridad de nivel alto” únicamente sería predicable, a juicio de OPENBANK, de la información que: • Se refiriese a medios de pago, es decir, la referida a los datos relacionados con aquellos instrumentos que permiten al interesado la adquisición de bienes y servicios o le habilitan para la cancelación de deudas que pudiera mantener con terceros, al margen de la enumeración no exhaustiva del documento. • La que permitiera determinar la situación financiera o la solvencia de una persona. Al respecto, esta Agencia considera que la documentación solicitada por OPENBANK en virtud de lo dispuesto en el Capítulo II de la LPBCFT, es decir, “el soporte documental relacionado con el origen de un fondo de su cuenta bancaria (P.ej., su nómina, contrato laboral, contrato de compraventa si se trata de una operación inmobiliaria, donación o herencia, la factura por los servicios prestados que le son satisfechos por el beneficiario de aquéllos, la resolución por la que se declare la percepción de una determinada ayuda, etc.)” contiene datos relacionados con la situación económica y el estado financiero de los clientes, de los que permiten determinar la situación financiera o la solvencia patrimonial de una persona, por lo que requieren de una mayor protección. Por último, alega OPENBANK que la conclusión de esta Agencia según la cual “los datos con relación a tres ingresos en cuentas bancarias deben ser considerados como “datos financieros”, y la información relativa al origen de estos ingresos, sin tener estrictamente naturaleza financiera, está íntimamente relacionada con estos movimientos bancarios, por lo que, al suministrarse información sobre el origen de los ingresos, a su vez se pone de manifiesto los movimientos en la cuenta bancaria de la parte reclamante que las actividades origen de esos ingresos producen”, carece de soporte alguno que la acredite. Y que, en cualquier caso, es evidente que no serían lo mismo -y no puede pretenderse que lo sea- los datos catalogados como “financieros” (ingresos en cuenta bancaria) que los restantes datos (la información relativa al origen de estos ingresos), que la propuesta de resolución considera “íntimamente relacionada” con los movimientos bancarios. Al respecto, esta Agencia insiste en que considera que la información relativa al origen de los ingresos en cuentas bancarias de los clientes es información que está íntimamente relacionada con tales movimientos bancarios y que contiene datos relacionados con la situación económica y el estado financiero de los clientes, de los C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 30/77 que permiten determinar la situación financiera o la solvencia patrimonial de una persona, por lo que requieren de una mayor protección en atención a los riesgos en los derechos y libertades de los interesados. En este sentido, no podemos dejar de indicar que los datos personales financieros conjuntamente considerados (los remitidos por el cliente por sí mismos, a los que se puede sumar los que ya tiene la entidad bancaria) pueden revelar múltiples aspectos sobre el cliente, como la situación financiera o la solvencia patrimonial tal y como hemos indicado. Así, el Dictamen 1/15 del Tribunal de Justicia (Gran Sala) de 26 de julio de 2017 establece que, “128 Por otra parte, aun cuando algunos de los datos del PNR, aisladamente considerados, no parezcan poder revelar información importante sobre la vida privada de las personas afectadas, no deja de ser cierto que, conjuntamente considerados, dichos datos pueden revelar, entre otros extremos, un itinerario de viaje completo, hábitos de viaje, relaciones existentes entre dos o varias personas así como información sobre la situación económica de los pasajeros aéreos, sus hábitos alimentarios o su estado de salud, y podrían incluso proporcionar datos sensibles sobre dichos pasajeros, tal como se define en el artículo 2, letra e), del Acuerdo previsto”, riesgo que asimismo recoge la STJUE de 1 de agosto de 2022. En cualquier caso, la propia LPBCFT reconoce que son operaciones que entrañan probablemente un mayor riesgo, por lo que consideró conveniente incorporar la necesidad de realizar una evaluación de impacto de la protección de datos de los tratamientos a los que se refiere dicho artículo a fin de adoptar medidas técnicas y organizativas reforzadas para garantizar la integridad, confidencialidad y disponibilidad de los datos personales. EN CONCLUSIÓN, la documentación solicitada por OPENBANK en virtud de lo dispuesto en el Capítulo II de la LPBCFT, es decir, “el soporte documental relacionado con el origen de un fondo de su cuenta bancaria (P.ej., su nómina, contrato laboral, contrato de compraventa si se trata de una operación inmobiliaria, donación o herencia, la factura por los servicios prestados que le son satisfechos por el beneficiario de aquéllos, la resolución por la que se declare la percepción de una determinada ayuda, etc.)” contiene datos financieros relacionados con la situación económica y el estado financiero de los clientes, de los que permiten determinar la situación financiera o la solvencia patrimonial de una persona, por lo que su tratamiento requieren de una mayor protección en atención a los riesgos en los derechos y libertades de los interesados. Por lo que se desestima la presente alegación. 3. Sobre la exigibilidad de las denominadas “medidas de nivel alto” Alega OPENBANK que en el acuerdo de inicio del presente procedimiento sancionador se había invocado la exigibilidad de un nivel de seguridad “alto”, que no era exigible desde la entrada en vigor del RGPD, y la propuesta de resolución se limita a indicar que reproducía el texto del artículo 32 de la LPBCFT en su redacción vigente al tiempo de producirse los hechos (lo que no hace sino reforzar lo ya indicado en relación con su indebida aplicación). Pero debe añadirse asimismo que, por más que C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 31/77 se indique lo contrario, el Acuerdo de Inicio, y la Propuesta de Resolución sí pretendían aplicar miméticamente a OPENBANK el régimen anterior a la plena aplicación del RGPD, dado que se refieren a una medida, el cifrado de datos, que expresamente se asociaba en dicha regulación a las denominadas “medidas de seguridad de nivel alto”. Y que en este punto, la propuesta vuelve a negar, aunque, a su juicio, exista una evidencia que lo contradiga en el expediente, que OPENBANK efectuase una evaluación del impacto del tratamiento en los derechos de los interesados, para determinar el alcance de las medidas a adoptar, haciendo recaer todo el reproche a OPENBANK en el hecho de que uno solo de todos sus clientes “llamó la atención [a OPENBANK] sobre este extremo”, no siendo satisfactoria, a juicio de la Agencia, la respuesta dada por OPENBANK a aquél. Y ello conduce a OPENBANK a cuestionarse si lo que la AEPD considera vulnerado en este caso es su deber de adopción de medidas técnicas y organizativas encaminadas a paliar los riesgos del tratamiento, previo análisis de dichos riesgos a través de una evaluación de impacto en la protección de datos, algo que (a su juicio) la AEPD no podrá negar que OPENBANK ha llevado a cabo, o el objeto del reproche de la AEPD es que no ha dado a la “inquietud” del interesado la respuesta que esa Autoridad considera adecuada, aun cuando no es posible negar (a su juicio) que OPENBANK sí respondió a lo solicitado. Al respecto, esta Agencia desea señalar que el presente procedimiento sancionador refiere única y exclusivamente a que OPENBANK no aplicó, antes y durante la realización del tratamiento en cuestión, la protección de datos desde el diseño y por defecto, para asegurar el cumplimiento de los principios consagrados por el RGPD (artículo 25 del RGPD), y no adoptó las medidas de seguridad apropiadas en función del riesgo para proteger los derechos y libertades de los interesados (artículo 32 del RGPD), en lo relativo al tratamiento de datos objeto del presente procedimiento. Ya se ha indicado, además y a mayor abundamiento, que la protección de datos desde el diseño no se agota con la realización de una evaluación de impacto. Las referencias que realizó esta Agencia a la LPBCFT han de entenderse únicamente para reforzar las infracciones de la normativa de protección de datos que esta Agencia habría constatado. No obstante, esta Agencia dará una nueva redacción a los fundamentos de derecho posteriores, tal y como se indicó anteriormente. Asimismo, esta Agencia desea señalar que ha revisado las medidas adoptadas por OPENBANK en lo que refiere a la información compartida por los usuarios para dar cumplimiento a las obligaciones previstas por la LPBCFT y la realidad es que no se les proporcionaba un medio seguro a los clientes para facilitar la información solicitada, información que, en relación con los riesgos, podía tener un alto impacto en los derechos y libertades de sus clientes si se materializaba, tal y como se desprende del propio análisis realizado por OPENBANK en sus documentos denominados “Evaluación de Impacto - Seguimiento de clientes y operaciones sensibles”, tanto en su versión de agosto 2021 como la de octubre 2022. El hecho de que aun cuando la parte reclamante llamó la atención sobre este extremo, enviando un correo electrónico C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 32/77 a la dirección que le indicaron para remitir la documentación financiera, sin obtener respuesta alguna por parte de OPENBANK, evidencia aún más la falta de conciencia sobre esta cuestión, dado que tampoco se le proporcionó un medio alternativo para ello ni siquiera cuando lo solicitó. Es decir, que lo que esta Agencia considera vulnerado en este caso es no sólo que OPENBANK, al momento de producirse los hechos, no había llevado a cabo antes de realizar el tratamiento en cuestión ni durante su realización un análisis que permitiera asegurar el cumplimiento de los principios de protección de datos ni tampoco adoptó unas medidas apropiadas al riesgo para las libertades y derechos de los interesados, sino también que OPENBANK no ha dado a la “inquietud” del interesado una respuesta adecuada, todo lo cual no hace más que evidenciar la no adopción de los principios de protección de datos desde el diseño y por defecto. En cuanto a los análisis realizados por OPENBANK en los documentos denominados “Evaluación de Impacto - Seguimiento de clientes y operaciones sensibles”, en su versión de agosto de 2021, la cual ni siquiera estaba vigente al momento de los hechos objeto de la reclamación, los cuales tuvieron lugar en el mes de julio de 2021, sólo se había previsto como una posibilidad que los clientes remitieran la información mediante mensaje cifrado remitiendo la contraseña mediante otro canal. E incluso en el citado documento se menciona que se “ha solicitado una demanda interna para que los interesados puedan subir documentos directamente a través del apartado de la web, una vez que se hayan logado en la misma”. No obstante, se ha podido comprobar que a la parte reclamante nunca se le dio esa posibilidad, ni en la comunicación inicial remitida por OPENBANK ni posteriormente cuando solicitó una vía alternativa segura para el envío de esa comunicación. También se comprobó que en el modelo de comunicación que se enviaba a los clientes no se daba ninguna de estas opciones, sólo se hacía mención a la posibilidad de responder el correo electrónico que se enviaba sin dar más indicaciones sobre cómo podía protegerse dicha información. Resulta curioso que, pese a no facilitar ningún medio lo suficientemente seguro a sus clientes para proporcionar la información a que estaban obligados, ambos documentos en sus versiones de 2021 y 2022 reconocen que el riesgo inherente a tal tratamiento era de alto impacto para los derechos y libertades de los interesados. Y, no obstante, recién es en la versión de octubre de 2022 cuando OPENBANK indica que “los clientes se identificarán mediante DNI y clave de acceso al área privada de cliente”. Por último, OPENBANK alega que en ningún caso ha dejado de responder a las inquietudes de la parte reclamante ni cabe considerar que exista en dicha respuesta amenaza alguna de ningún tipo, como se indica la Propuesta de Resolución. OPENBANK se ha limitado a poner de manifiesto que la ausencia de información a la misma en relación con el origen de los fondos en los ingresos controvertidos exigirá que por parte de OPENBANK se proceda al bloqueo de la cuenta, al poder existir indicios, por incumplimiento de la normativa de prevención del blanqueo de capitales, de la existencia de una conducta ilícita en su cliente. Al respecto, esta Agencia desea señalar que no se le ha proporcionado a la parte reclamante una respuesta satisfactoria a su inquietud, toda vez que no se le C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 33/77 proporcionó un medio adecuado para facilitar la información solicitada por OPENBANK en virtud del Capítulo II de la LPBCFT. En todo caso, cabe aclarar en este momento que, lo que OPENBANK denomina como “inquietud” por parte del cliente, no es más que una persona, su cliente, que pretende se haga efectivo su Derecho Fundamental a la Protección de Datos de Carácter Personal. En cuanto a si existió algún tipo de amenaza a la parte reclamante, se desea recordar el contenido del modelo de comunicación a los clientes, vigente en julio de 2021: “ Segunda comunicación: D+16 (…) En el caso de no recibir la documentación solicitada en los próximos 15 días a contar desde la fecha de la presente comunicación, le informamos que Openbank puede impedir la realización de nuevos ingresos en sus cuentas en cumplimiento de la normativa en vigor. (…)” (el subrayado es nuestro) Y el correo enviado a la parte reclamante el 7 de julio de 2021 por parte de OPENBANK decía lo siguiente: “Estimado Sr. A.A.A. (…) En caso de no recibir la documentación solicitada en el plazo de 15 días desde la fecha del presente aviso, Openbank podrá, en cumplimiento de la normativa aplicable, impedir que se realicen nuevos ingresos en sus cuentas. (…)” (el subrayado es nuestro) El contenido de las comunicaciones enviadas por OPENBANK a los clientes (entre ellos, la parte reclamante), por las que se solicita el envío de la documentación en virtud del Capítulo II de la LPBCFT, contienen un aviso de que si no se remite la citada documentación en el plazo de 15 días, OPENBANK puede impedir que se realicen nuevos ingresos en sus cuentas. El diccionario de la Real Academia Española explica que “amenaza” es un “dicho o hecho con que se amenaza”. Mientras que “amenazar” es aquello “dicho de algo malo o dañino: Presentarse como inminente para alguien o algo” y también “dar indicios de ir a sufrir algo malo o dañino”. Bloquear los nuevos ingresos de las cuentas de los clientes, por supuesto que es algo malo o dañino para quien lo sufre, por más que ello sea, al decir de OPENBANK, “al poder existir indicios, por incumplimiento de la normativa de prevención del blanqueo de capitales, de la existencia de una conducta ilícita en su cliente”. Incluir esa información en las comunicaciones dirigidas a los clientes, hace que estos últimos remitan la documentación solicitada aunque no se le proporcionen medios apropiados para ello (como ha debido hacer la parte reclamante), por miedo a las posibles consecuencias desfavorables para ellos, en este caso, el bloqueo de sus cuentas. C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 34/77 Por todo lo expuesto, se desestima la presente alegación. TERCERA.- ACERCA DE LA VULNERACIÓN DEL PRINCIPIO NON BIS IN IDEM O SUBSIDIARIAMENTE DE LA EXISTENCIA DE CONCURSO MEDIAL EN EL PRESENTE CASO OPENBANK alega que se le pretende sancionar doblemente como consecuencia de un mismo hecho y por la vulneración de un mismo bien jurídico, al considerarse que no había establecido medidas de seguridad adecuadas para la transmisión (y consiguiente recepción por aquélla) de lo que erróneamente se consideraban “datos financieros” y, al propio tiempo, no haber adoptado dichas medidas desde el diseño del tratamiento. Del mismo modo, alega que, en el negado supuesto de que no se considerase que nos encontrábamos ante una doble sanción por un mismo hecho, resultando vulnerado un mismo bien jurídico protegido, de lo que no cabía duda es de que la supuesta ausencia de medidas de seguridad adecuadas en la remisión de la documentación traía su causa, necesariamente, del, a juicio de la AEPD, inadecuado análisis de riesgos efectuado por OPENBANK, de forma que no habría previsto la implementación de tales medidas. De este modo, si se negaba la vulneración del principio non bis in idem, de lo que no cabía duda alguna era de la existencia de un concurso medial entre ambas infracciones. Cita OPENBANK la propuesta de resolución del presente procedimiento sancionador en la que se dice expresamente lo siguiente en relación con la supuesta vulneración del artículo 25 del RGPD: “En este protocolo, OPENBANK no tenía previsto ofrece a sus clientes ningún canal de comunicación con un nivel alto de seguridad, a pesar de que en la cláusula sexta del contrato con su encargado de tratamiento indica que “las transferencias electrónicas de Información del Cliente a través de redes públicas o no seguras se realicen de forma segura utilizando métodos de cifrado apropiados de acuerdo con las Políticas de Grupo Santander”. Al aplicar el citado protocolo, OPENBANK hace recaer en el cliente la responsabilidad de una comunicación segura, siendo este quien debe procurar la confidencialidad e integridad de sus datos personales. En este punto, recordemos que, en virtud del principio de responsabilidad proactiva consagrado en el artículo 5.2 del RGPD, el responsable del tratamiento, en este caso OPENBANK, es quien debe asegurar la efectiva privacidad e integridad de los datos personales objeto de tratamiento.” Indica OPENBANK que el peso de la imputación de la supuesta vulneración del artículo 25 del RGPD se hace recaer en el hecho de que no había establecido, a juicio de la AEPD “ningún canal de comunicación con un nivel alto de seguridad” trasladando al interesado la responsabilidad de velar por “la confidencialidad e integridad de sus datos personales”. Es decir, es la propia Propuesta de Resolución la que indica claramente que la supuesta falta de diseño de medidas técnicas y organizativas adecuadas se refiere, C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 35/77 específicamente, a la supuesta falta de medidas de seguridad en el envío de la documentación, haciendo posteriormente una valoración acerca de la supuesta ineficacia del cifrado de correos electrónicos para garantizar la integridad y confidencialidad de los datos. De este modo, resulta a OPENBANK ciertamente sorprendente que la propia Propuesta de resolución afirme en un lugar distinto que en el presente caso no se está haciendo referencia, al hablarse de las medidas técnicas y organizativas adecuadas al riesgo, a las medidas relacionadas con el envío de la documentación, cuya supuesta ausencia ha sido la que ha dado lugar a la comunicación dirigida por la parte reclamante a OPENBANK. Al respecto, esta Agencia se reitera en que se dará una nueva redacción a los fundamentos de derecho posteriores, tal y como se indicó anteriormente. Alega OPENBANK que para apoyar la supuesta diferenciación y, en su defecto, desconexión entre ambas infracciones, la AEPD señala en el fundamento de derecho III de la Propuesta de resolución, que la supuesta vulneración del artículo 25 del RGPD no se refiere a la falta de adopción de medidas específicas en la remisión de los documentos, sino al hecho de que dichas medidas no han sido comunicadas a la parte reclamante cuando puso de manifiesto su preocupación sobre el modo de remisión de aquéllos. Sin embargo, entiende OPENBANK que tal argumento no puede sostenerse, dado que esa supuesta falta de comunicación traería su causa del hecho de que las medidas de seguridad cuya vulneración se achaca a OPENBANK, y que además fueron posteriormente implementadas, no existían al tiempo de producirse la remisión de tal preocupación a OPENBANK. Es decir, nos encontraríamos simplemente ante la adición de un nuevo elemento que no altera la relación causal entre las infracciones imputadas a OPENBANK, dado que la ahora argumentada por la AEPD como base de la imputación del artículo 25 del RGPD (falta de atención a la inquietud manifestada por interesado, al que, aun cuando pudiera parecer lo contrario de la lectura de la Propuesta, sí se dio respuesta) traería su causa del hecho de que no se habían, a juicio de la AEPD, adoptado medidas de seguridad adecuadas porque, supuestamente, OPENBANK no había llevado a cabo un adecuado análisis de los riesgos del tratamiento para los derechos de los interesados y adoptado tales medidas técnicas y organizativas. Y todo ello nos devolvería a la conclusión inicial ya manifestada por OPENBANK: se está imponiendo una doble sanción por unos mismos hechos y la supuesta vulneración de un mismo bien jurídico o, cuando menos, una de las supuestas infracciones trae causa directa y subsume a la otra, hasta el punto de que si no se hubiera cometido ésta no se habría cometido la segunda. Y a tal efecto indica OPENBANK que resulta paradigmático observar cómo, pese a su ímprobo esfuerzo, la Propuesta de Resolución no hace más que ratificar lo alegado al Acuerdo de Inicio, cuando se indica en la página 64 de la Propuesta lo siguiente: C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 36/77 “Del examen de los hechos probados y de la documentación obrante en el expediente, puede diferenciarse claramente dos infracciones basadas en hechos y fundamentos distintos. La comisión de la infracción del artículo 32 del RGPD deviene del requerimiento de documentación de OPENBANK a los clientes (y en concreto, a la parte reclamante) siguiendo el protocolo de comunicación previsto a tal efecto, en el que no se le indica al cliente ningún medio seguro para facilitar la información solicitada. Ni tan siquiera cuando el cliente solicita al banco un medio alternativo, como ocurrió en el caso concreto de la parte reclamante, que no tuvo más opción que remitir la citada documentación por correo electrónico ya que al dirigirse a OPENBANK para que se le facilitara otra opción, ello no ocurrió. Por lo tanto, no se aplicaron medidas técnicas y organizativas de seguridad apropiadas por parte de OPENBANK para la realización del tratamiento en cuestión en general ni aun ante la petición formulada por la parte reclamante, efectuándose un tratamiento de datos (recordemos que la recogida de datos es una operación de tratamiento según el artículo 4.2) del RGPD), sin las medidas de seguridad adecuadas para garantizar la confidencialidad del tratamiento. Por otra parte, la comisión de la infracción del artículo 25 del RGPD se fundamenta en que el protocolo de OPENBANK vigente al momento de los hechos (de marzo de 2021) no preveía proporcionar información sobre el método de envío de la documentación solicitada. Se sanciona la falta de diseño de un sistema adecuado para cumplir con los principios del tratamiento, los requisitos del RGDP y garantizar los derechos de los interesados.” Es decir, se considera infringido el artículo 32 del RGPD porque “no se le indica al cliente ningún medio seguro para facilitar la información solicitada” y por el artículo 25 del RGPD porque el protocolo de OPENBANK “no preveía proporcionar información sobre el método de envío de la documentación solicitada”, lo que es exactamente lo mismo que se acaba de invocar como motivo de la imputación del artículo 32 del RGPD. En primer lugar, esta Agencia desea señalar que la infracción del artículo 25 del RGPD y la infracción del artículo 32 del RGPD, son infracciones que están tipificadas de manera diferenciada al vulnerar preceptos distintos que protegen bienes jurídicos diferentes, como a continuación se expondrá. Por lo tanto es algo previsto por el legislador, sin que la vulneración de uno de los preceptos impida la del otro, lo que además no supone per se conculcar el principio de non bis in idem. Asimismo, si bien están calificadas ambas infracciones como graves a efectos de la prescripción en la LOPDGDD, se reseñan en distintos apartados del artículo 73 de la LOPDGDD: “(…)
13. d)La falta de adopción de aquellas medidas técnicas y organizativas que resulten apropiadas para aplicar de forma efectiva los principios de protección de datos desde el diseño, así como la no integración de las garantías necesarias en el tratamiento, en los términos exigidos por el artículo 25 del Reglamento (UE) 2016/679. C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 37/77
14. e)La falta de adopción de las medidas técnicas y organizativas apropiadas para garantizar que, por defecto, solo se tratarán los datos personales necesarios para cada uno de los fines específicos del tratamiento, conforme a lo exigido por el artículo 25.2 del Reglamento (UE) 2016/679.
15. f)La falta de adopción de aquellas medidas técnicas y organizativas que resulten apropiadas para garantizar un nivel de seguridad adecuado al riesgo del tratamiento, en los términos exigidos por el artículo 32.1 del Reglamento (UE) 2016/679.
16. g)El quebrantamiento, como consecuencia de la falta de la debida diligencia, de las medidas técnicas y organizativas que se hubiesen implantado conforme a lo exigido por el artículo 32.1 del Reglamento (UE) 2016/679. (…)”. Por tanto, se trata de infracciones perfectamente diferenciadas. En segundo lugar, el artículo 31 de la Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público (en adelante, LRJSP) establece: “No podrán sancionarse los hechos que lo hayan sido penal o administrativamente, en los casos en que se aprecie identidad del sujeto, hecho y fundamento”. En el presente caso, la infracción por vulnerar lo dispuesto en el artículo 25 del RGPD se determina ante la inadecuada protección de datos desde el diseño y por defecto, en virtud del cual “el responsable del tratamiento aplicará tanto en el momento de determinar los medios de tratamiento como en el momento del propio tratamiento, medidas técnicas y organizativas apropiadas”. Estas medidas no tienen por qué tratarse estrictamente de medidas de seguridad, cuestión que se recoge específicamente en el artículo 32 del RGPD en cuando al tratamiento en concreto, por el que “el responsable y el encargado del tratamiento aplicarán medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo”. El artículo 25 del RGPD se vulnera cuando no se han adoptado aquellas medidas técnicas y organizativas que resulten apropiadas para aplicar de forma efectiva los principios de protección de datos desde el diseño, así como la no integración de las garantías necesarias en el tratamiento, en los términos exigidos por el artículo 25 del Reglamento (UE) 2016/679, lo que puede producirse o no por ausencia o deficiencia de las medidas de seguridad. Las medidas técnicas y organizativas a que hace referencia el artículo 25 del RGPD para aplicar los principios de protección de datos desde el diseño no están limitadas a medidas estrictamente de seguridad. Esto sería simplificar la esencia y el espíritu que inspira el RGPD, así como la voluntad del legislador, ya que el cumplimiento del RGPD no se limita a la implantación de medidas técnicas y organizativas de seguridad; lo cual significaría, en el presente caso, reducir la garantía exigida por el artículo 25 del RGPD a su logro únicamente con medidas de seguridad dejando sin efecto y de facto las garantías establecidas por le RGPD. En este sentido, el artículo 25 del RGPD establece: “Teniendo en cuenta el estado de la técnica, el coste de la aplicación y la naturaleza, ámbito, contexto y fines del tratamiento, así como los riesgos de diversa probabilidad y gravedad que entraña el tratamiento para los derechos y C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 38/77 libertades de las personas físicas, el responsable del tratamiento aplicará, tanto en el momento de determinar los medios de tratamiento como en el momento del propio tratamiento, medidas técnicas y organizativas apropiadas, como la seudonimización, concebidas para aplicar de forma efectiva los principios de protección de datos, como la minimización de datos, e integrar las garantías necesarias en el tratamiento, a fin de cumplir los requisitos del presente Reglamento y proteger los derechos de los interesados” (el subrayado es nuestro) Esta Agencia se reitera en que hay múltiples medidas técnicas u organizativas que no son de seguridad y que puede implementar el responsable del tratamiento como cauce para garantizar este principio. Sin embargo, el artículo 32 del RGPD comprende la obligación de implementar medidas técnicas y organizativas de seguridad apropiadas para garantizar un nivel de seguridad adecuado al riesgo. De seguridad. Sólo de seguridad. Además, su objetivo es garantizar un nivel de seguridad adecuado al riesgo mientras que en el caso del artículo 25 del RGPD se debe garantizar la gestión del cumplimiento normativo de todo el RGPD. Por tanto, como se puede observar, los dos artículos persiguen fines distintos y protegen bienes jurídicos diferentes, aunque puedan estar relacionados. En cuanto al examen del non bis in idem, la Sentencia de la Audiencia Nacional de 23 de julio de 2021 (rec. 1/2017) dispone que: “(…) Conforme a la legislación y jurisprudencia expuesta, el principio non bis in ídem impide sancionar dos veces al mismo sujeto por el mismo hecho con apoyo en el mismo fundamento, entendido este último, como mismo interés jurídico protegido por las normas sancionadoras en cuestión. En efecto, cuando exista la triple identidad de sujeto, hecho y fundamento, la suma de sanciones crea una sanción ajena al juicio de proporcionalidad realizado por el legislador y materializa la imposición de una sanción no prevista legalmente que también viola el principio de proporcionalidad. Pero para que pueda hablarse de "bis in ídem" debe concurrir una triple identidad entre los términos comparados: objetiva (mismos hechos), subjetiva (contra los mismos sujetos) y causal (por el mismo fundamento o razón de castigar):
17. a)La identidad subjetiva supone que el sujeto afectado debe ser el mismo, cualquiera que sea la naturaleza o autoridad judicial o administrativa que enjuicie y con independencia de quién sea el acusador u órgano concreto que haya resuelto, o que se enjuicie en solitario o en concurrencia con otros afectados.
18. b)La identidad fáctica supone que los hechos enjuiciados sean los mismos, y descarta los supuestos de concurso real de infracciones en que no se está ante un mismo hecho antijurídico sino ante varios. C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 39/77
19. c)La identidad de fundamento o causal, implica que las medidas sancionadoras no pueden concurrir si responden a una misma naturaleza, es decir, si participan de una misma fundamentación teleológica, lo que ocurre entre las penales y las administrativas sancionadoras, pero no entre las punitivas y las meramente coercitivas.” Tomando como referencia lo anteriormente explicitado en el presente procedimiento sancionador no se ha vulnerado el principio non bis in idem, puesto que la infracción del artículo 25 del RGPD se concreta en no haber realizado una adecuada gestión del cumplimiento normativo, mientras que la infracción del art. 32 del RGPD se reduce a la ausencia y deficiencia de las medidas de seguridad (solo de seguridad) detectadas, presentes con independencia de la petición realizada por la parte reclamante. Aunque la parte reclamante no hubiera realizado petición alguna (otros muchísimos clientes se habrán limitado a remitir la documentación requerida sin plantearse nada) las medidas de seguridad serían, en sí mismas, inadecuadas. Y todo ello frente a las alegaciones formuladas por OPENBANK que considera que en ambos preceptos se exige una única conducta que es implantar la seguridad adecuada. No es cierto, puesto que el artículo 25 del RGPD no se constriñe a la garantía de la seguridad adecuada al riesgo, sino a la adopción de las medidas que garanticen la aplicación de forma efectiva los principios de protección de datos y el cumplimiento de los requisitos del RGPD y proteger los derechos de los interesados. Y ello no sólo mediante medidas de seguridad, sino mediante todo tipo de medidas técnicas u organizativas apropiadas. Por lo demás, esta Agencia se reitera en lo afirmado en la citada propuesta de resolución. Respecto a la infracción de lo dispuesto en el artículo 25 del RGPD, cabe recordar que la Protección de Datos desde el Diseño y por Defecto (PDDD) es una obligación legal, cuya vulneración constituye una infracción según lo dispuesto en el artículo 83 del RGPD. La protección de datos desde el diseño forma parte del sistema de gestión del cumplimiento normativo, que implica concebir y planificar el tratamiento, verificar su cumplimiento y poder demostrarlo, todo ello enmarcado en un proceso de revisión y mejora continua, donde la privacidad desde el diseño juega un papel fundamental. Las organizaciones deben preocuparse por instaurar una verdadera cultura de protección de datos en la organización, donde la protección de datos esté integrada en las políticas de cumplimiento normativo de aquellas, desde el inicio mismo del diseño de los tratamientos de datos de carácter personal. Por su parte, en la “Guía de Privacidad desde el Diseño” de la AEPD lo define de la siguiente forma: “La privacidad desde el diseño (en adelante, PbD) implica utilizar un enfoque orientado a la gestión del riesgo y de responsabilidad proactiva para establecer estrategias que incorporen la protección de la privacidad a lo largo de todo el ciclo de vida del objeto (ya sea este un sistema, un producto hardware o software, un servicio o un proceso). Por ciclo de vida del objeto se entiende todas las etapas por C/ Jorge Juan, 6 28001 – Madrid www.aepd.es sedeagpd.gob.es 40/77 las que atraviesa este, desde su concepción hasta su retirada, pasando por las fases de desarrollo, puesta en producción, operación, mantenimiento y retirada”. Y en la resolución del procedimiento sancionador PS/00001/2021 esta Agencia ha considerado que “La responsabilidad proactiva implica la implantación de un modelo de cumplimiento y de gestión del RGPD que determina el cumplimiento generalizado de las obligaciones en materia de protección de datos. Comprende el establecimiento, mantenimiento, actualización y control de las políticas de protección de datos en una organización, especialmente si es una gran empresa, -entendidas como el conjunto de directrices que rigen la actuación de una organización, prácticas, procedimientos y herramientas-, desde la privacidad desde el diseño y por defecto, que garanticen el cumplimiento del RGPD, que eviten la materialización de los riesgos y que le permita demostrar su cumplimiento." En el presente caso, se pone de manifiesto la falta de diseño del tratamiento por parte de OPENBANK, toda vez que no se ha incluido la actividad de recogida de datos de los clientes en el denominado “ciclo de vida del tratamiento” de su fichero Excel de documento de evaluación de impacto de protección de datos (aportado durante el período de prueba del presente procedimiento); por ello