Seguridad y Privacidad en Flujos Financieros: Un Llamado a la Vigilancia Operativa


Los bancos destinan grandes recursos a convencer a los clientes de que son los custodios más cuidadosos de los datos personales y financieros. Sin embargo, una revisión de 14 sitios de servicios financieros en Europa y EE. UU. revela prácticas preocupantes: scripts de rastreo y personalización incrustados en procesos de apertura de cuentas, hipotecarios y de préstamos que envían datos de contacto, intención financiera y huellas de dispositivos a terceros, con 9 de 14 sitios operando sin una opción de consentimiento válida.

Las fallas se agrupan en tres patrones, y la distinción entre ellos tiene implicaciones legales. En primer lugar, las etiquetas se disparaban antes de que se respondiera el banner de cookies en sitios de gestión de patrimonio, banca de inversión y proveedores de pago; según la Directiva de ePrivacy de la UE, ese comportamiento no tenía base legal, ya que el consentimiento es obligatorio antes de almacenar o leer datos en un dispositivo.

En segundo lugar, el rastreo continuó tras que el usuario rechazara las cookies: en un sitio, Google Ads y DoubleClick recibían la dirección de correo electrónico hasheada en la URL de la solicitud junto con la señal de consentimiento denegada, lo que implica que el rechazo se registró y se ignoró.

En tercer lugar, se filtraron datos financieros independientemente del consentimiento: un importe de préstamo de 2.500 € en un plazo de 12 meses y una selección de seguro llegaron a Google Analytics durante una solicitud de crédito personal; en un banco portugués, el nombre, la edad y el NIF de un cliente se enviaron a Evergage como texto codificado en Base64 en la URL durante la apertura de la cuenta.

En un sitio bancario holandés, un script de primera parte combinaba fingerprinting del navegador con peticiones de imágenes a 127.0.0.1 en los puertos 7070 y 5938, asociados a AnyDesk y TeamViewer, verificando efectivamente si software de acceso remoto estaba funcionando en el dispositivo del visitante.

Dónde recae la responsabilidad

Meta y TikTok señalan al operador del sitio como la parte que controla lo que se recoge, en respuesta a investigaciones anteriores. Meta citó sus controles de privacidad y su política contra compartir datos sensibles; TikTok afirmó que los anunciantes deciden qué eventos y parámetros envían y que solo recibe lo que sus socios configuran intencionalmente.

Este marco coloca toda la responsabilidad en el operador, y solo se sostiene si la recopilación fue algo que el operador activó deliberadamente. A menudo no lo fue. La función de Coincidencia Avanzada Automática (Automatic Advanced Matching) de Meta Pixel está activada por defecto y, en ese estado, captura y aplica hash a datos de contacto sin necesidad de configuración adicional por parte del propietario del sitio. Un ingeniero bancario que añade un snippet de rastreo no está eligiendo enviar el correo electrónico y el teléfono hasheados de un solicitante de hipoteca a Meta; el píxel lo hace por defecto. Una política que prohíbe recolectar datos sensibles es difícil de reconciliar con una función que los recoge por defecto.

Eso no elimina la responsabilidad del banco. Las entidades deciden qué proveedores despliegan, colocan banners de consentimiento frente a los clientes y publican políticas de cookies que deben enumerar cada entidad receptora de datos. Ambos lados tienen responsabilidad: las plataformas envían defaults que maximizan la captación de datos y los bancos desplegan esos defaults en flujos sensibles sin validar su comportamiento en tiempo real.

Cerrando la brecha

Esto es una cuestión de cumplimiento tanto como de ética.

En la UE, scripts de terceros no gestionados en flujos orientados al cliente abarcan GDPR y requisitos de consentimiento de ePrivacy; para entidades financieras reguladas, también rigen las reglas de riesgo y resiliencia operativa de DORA; PSD2 añade obligaciones de seguridad para flujos de pago. En EE. UU., las instituciones tienen deberes bajo la regla de Salvaguardas de GLBA y, cada vez más, bajo leyes estatales como CCPA/CPRA. Aparte de la exposición reguladora, se trata de higiene operativa básica.

La corrección comienza verificando el comportamiento en tiempo real en lugar de asumir que coincide con la configuración. Esto significa validar lo que hacen los scripts en páginas reales de apertura de cuentas, hipotecas, préstamos y simulaciones, ya que son las que manejan los datos más valiosos, en lugar de detener las comprobaciones solo en la página de inicio. También implica vigilar por un script que empiece a recoger más de lo previsto, a veces llamado alcance incremental (scope creep).

La visibilidad debe conducir al control. Los equipos de seguridad deben poder impedir que scripts de terceros lean campos sensibles y bloquear transferencias de datos no autorizadas, incluyendo la práctica de ocultar identificadores y detalles financieros dentro de una URL de solicitud en lugar de en el cuerpo de la petición, tal como ocurrió en varias filtraciones de nuestra investigación.

El consentimiento debe traducirse en acción real, no solo en papel. Una denegación debe impedir que los datos salgan del navegador en lugar de registrarse como señal denegada mientras la llamada de rastreo se ejecuta. Ese consentimiento debe acompañar al cliente incluso al interactuar con iframes o subdominios que adopte el flujo, y no reiniciarse en cada frontera que cruce.

Caracteres como Automatic Advanced Matching, que hashea y envía datos de contacto por defecto, deben desactivarse a menos que dicha recopilación esté documentada, informada y sea legal. El código propio merece la misma escrutinio que las etiquetas de terceros: la huella digital y el sondeo de puertos para fraude pueden ser controles legítimos, pero implementarlo internamente no exime de divulgación y consentimiento.

Nada de esto exige abandonar la analítica o la personalización. Requiere tratar los scripts en páginas sensibles como parte del riesgo de la institución, revisados en el mismo ciclo que cualquier otro proveedor, y no configurados una vez y dejados sin revisión. Nueve de las catorce entidades analizadas enviaban datos a través de un canal cuyo propio banner de consentimiento indicaba que estaba cerrado.

Esa brecha entre lo que un script puede hacer y lo que realmente hace merece cerrarse antes de que un regulador o un cliente lo descubra primero.

Este artículo forma parte de TechRadar Pro Perspectives, nuestro canal para presentar las mentes más brillantes de la industria tecnológica. Las opiniones aquí expresadas corresponden al autor y no necesariamente a TechRadar Pro ni a Future plc. Si está interesado en contribuir, descubra más aquí: https://www.techradar.com/pro/perspectives-how-to-submit.

from Latest from TechRadar https://ift.tt/MGVT5gk
via IFTTT IA