- HSBC determinó si los clientes recibían sus correos mediante un píxel de rastreo y, como resultado, envió avisos erróneos de “correo rebotado” a clientes que en realidad sí los recibían con normalidad
- El banco exigió a los clientes que actualizaran su dirección de correo, pero en la cuenta del cliente ya estaba registrada la dirección correcta
- El análisis mostró que los correos de HSBC incluían un píxel de rastreo basado en HTTP, lo que implica riesgo de exponer datos personales como el momento de recepción, la frecuencia y la dirección IP
- Como los píxeles de rastreo no funcionan cuando están bloqueados, se señala como un mal uso técnico que el banco haya concluido “correo no recibido” basándose en eso
- HSBC debería cambiar a un enfoque de fin del rastreo sin cifrar, respeto por la privacidad y comunicación clara con los clientes
Aviso erróneo de rebote de correo por parte de HSBC
- HSBC envió a los clientes una notificación por correo postal indicando que “el correo electrónico rebotó” y solicitando actualizar la dirección
- En realidad, el cliente sí recibía y abría normalmente los correos de HSBC
- Al revisar la cuenta en línea, la dirección de correo registrada era correcta
- En el chat de atención al cliente solo repitieron una respuesta formal: “si el banco envió la carta, debe cambiar la dirección”
- Solo después, en una llamada telefónica, le respondieron que “si la dirección es correcta, puede ignorar la carta”
- El autor propuso a HSBC cambiar la frase “se requiere acción” por “se requiere verificar la dirección”
Estructura y problemas del píxel de rastreo en correos electrónicos
- En la parte inferior de los correos de HSBC había dos imágenes de 1×1 píxel
- Ese píxel se usa como un mecanismo de rastreo que se conecta al servidor cuando el destinatario abre el correo y registra si fue leído
- HSBC estaba enviando ese píxel mediante el protocolo HTTP, lo que genera una vulnerabilidad de seguridad al permitir que terceros en la red sepan que el correo fue abierto
- En entornos de Wi‑Fi público, existe la posibilidad de que otros usuarios de la misma red detecten esa información
- También se menciona el riesgo de que un atacante inserte una imagen al final del correo para falsificarlo como un mensaje de phishing
Falta de fiabilidad y mal uso del píxel de rastreo
- El autor usa una configuración de bloqueo de píxeles de rastreo, por lo que no envía información de apertura del correo
- Ese es el funcionamiento original previsto del correo electrónico, donde el destinatario puede decidir si revela o no que lo abrió
- Al no recibir señal del píxel, HSBC aparentemente lo interpretó erróneamente como “correo no recibido” y lo trató como rebotado
- Este es un caso de mal uso del píxel de rastreo como medio para identificar a clientes individuales, en lugar de usarlo para análisis estadístico
- Como resultado, HSBC terminó enviando un aviso falso de “correo rebotado”
Propuestas de mejora presentadas a HSBC
- Detener el rastreo sin cifrar (HTTP): es necesario usar HTTPS para evitar la exposición en la red cuando se abre el correo
- No considerar el bloqueo del rastreo como rechazo de recepción: que el píxel no funcione puede deberse a múltiples razones técnicas
- Dejar de vigilar los hábitos de correo de los clientes: un banco que ya posee suficiente información personal no necesita hacer vigilancia adicional
- Validar la dirección de correo mediante verificación directa: se recomienda un procedimiento basado en consentimiento explícito, como hacer clic en un enlace de confirmación
- Cumplir principios de ética de datos: conforme a los ‘Principios para el uso ético de los datos y la IA’ publicados por HSBC, es necesario garantizar idoneidad del propósito y transparencia
Conclusión
- HSBC malinterpretó los límites de fiabilidad de los píxeles de rastreo y evaluó incorrectamente los correos de sus clientes
- Este caso muestra que las prácticas de recolección de datos propias del capitalismo de vigilancia han penetrado incluso en la operación de instituciones financieras
- El autor subraya que HSBC debe reconocer el error técnico y reforzar el uso transparente de los datos y la protección de la privacidad del cliente
1 comentarios
Opiniones de Hacker News
Llamó la atención que en 2026 todavía estuvieran sirviendo contenido por HTTP
Con una revisión de seguridad medio decente lo habrían detectado, así que parece que se saltaron por completo esa etapa
Yo trabajo con datos bancarios, y los sistemas internos también son igual de desastrosos
Incluso dentro del mismo banco, el formato de fechas en CSV varía por todos lados, y las descripciones de transacciones están truncadas y sin estandarizar
Que sigan así pese a tanta presión regulatoria se debe a que la mayoría de los bancos siguen tratando la infraestructura digital como si fuera plomería vieja
Pero cada banco corta la longitud de los memos de forma distinta o, como AMEX, intercambia los campos NAME y MEMO, así que sigue siendo un desastre
Aun así, al menos existe un estándar mínimo
Documentación relacionada: Open Financial Exchange, Financial Data Exchange
Hasta las pantallas de los cajeros se sienten igual de anticuadas
Por ejemplo, el desafío ACME HTTP-01, la emisión de certificados y las respuestas CRL/OCSP todavía usan HTTP
Ver RFC8555 y la documentación de Let's Encrypt
Así que generalizar con que “HTTP ya no sirve para nada” es incorrecto
HTTPS también intercambia el SNI, así que igual se puede saber quién se está comunicando con HSBC
El resto de la URL es solo un identificador de seguimiento anonimizado, así que la amenaza real no parece muy grande
Usar HTTPS implica más complejidad de configuración y manejo de certificados
Me preguntaba por qué pasó algo así
En el IT bancario, implementar aunque sea una sola función de rastreo de correos involucra a decenas de personas y puede tardar un año
Seguro hubo algún desarrollador que dijo “usar HTTP en 2026 es riesgoso”, pero probablemente los mandos medios terminaron ignorándolo
La gerencia seguía preguntando por qué algunas personas habían abierto el correo pero no aparecía registrado, o por qué figuraba como abierto cuando no lo habían abierto
Como a los autores les sale una tasa de apertura más alta que la de clics, la usan como métrica de desempeño
Al final, todos usan métricas imprecisas para sentir que les va bien
La gerencia toma todas las decisiones y los desarrolladores solo hacen lo que les dicen
Yo trabajé antes en un banco grande, y salvo los que se van a los pocos años, el resto se queda como “gente que aprieta botones y cobra”
Es mucho mejor que esos mails de “tienes un mensaje importante, inicia sesión”
Como pasa con las apps de departamentos, las funciones de conveniencia poco a poco se vuelven obligatorias y al final todos los usuarios tienen que adaptarse
En ese proceso, el control individual se reduce
Ni el sueldo ni el entorno son especialmente buenos, y casi no hay margen para innovar
NAB Australia hace exactamente lo mismo
Si no cargas las imágenes remotas del correo, te mandan una carta diciendo que “el email no está siendo entregado” y te cambian a estados de cuenta en papel
En realidad, los correos sí estaban llegando bien
Decidieron desactivar automáticamente las alertas de saldo porque asumieron que yo no leía sus correos
Lo único que hice fue desactivar las confirmaciones de lectura y bloquear recursos remotos
Al final me cambié de banco
Los buzones de departamentos suelen recibir entregas equivocadas, sufrir robos o hasta incendiarse
Hace tiempo recibía spam de marketing de Bank of America y no había opción para darme de baja
Así que desactivé esa dirección de correo, y entonces me mandaron una carta pidiendo que la corrigiera porque “el email rebota”
Al final la dejé desactivada por años, hasta que después agregaron una función de preferencias de correo
Mi esposa todavía recibe correo basura por correo postal de Citi, y ahí tampoco hay forma de cancelarlo
Viendo eso, es realmente absurdo que el equipo de IT de HSBC haya concluido, basándose en un tracking pixel, que “el correo no fue leído”
Hoy en día la mayoría de los clientes de correo ya bloquean las imágenes por defecto
La capacidad técnica de HSBC es realmente pésima
La app de banca en línea parece de principios de los 2000, y un familiar todavía la usa pero le falla todo el tiempo
No es error del usuario, es problema del sistema
Si quieres que un banco escuche al cliente, lo más efectivo es cerrar la cuenta
Claro, eso implica estar dispuesto a cambiarte de verdad
Si el problema queda registrado oficialmente, se puede actuar cuando vuelva a repetirse
Ver este artículo de The Guardian
A mí me afectó en ese momento, y después me cambié a Wise
Capital One hace algo parecido
Al menos sí te dicen claramente que “no abriste correos recientes”, así que se entiende a qué se refieren
En realidad sí abrí los correos, solo bloqueé el tracking pixel
No tengo por qué resolverles sus problemas
Gmail precarga imágenes, así que en la práctica el tracking pixel se activa incluso si el usuario no abrió el correo
No lo he probado yo mismo, pero supongo que otros servicios de correo harán algo parecido
Como la mayoría de los servicios de correo precargan imágenes del lado del servidor para escanear malware, en la práctica el pixel tracking casi siempre lo maneja el proveedor externo de correo electrónico
A mí me pasó exactamente lo mismo con HSBC
El proceso fue excelente: pude abrir la cuenta en 10 minutos con identificación digital y recibí la tarjeta de Apple Pay en un día
Pero como rechacé recibir correos de marketing, me enviaron un correo de “bienvenida con upsell” y, cuando ese mensaje rebotó, bloquearon la cuenta
Al final terminé en la misma situación que el OP
Charles Schwab también hace algo parecido
Aunque los correos llegan bien, te cambian a estados de cuenta en papel diciendo que “no se están entregando”
El problema real es el bloqueo del tracking pixel
Los correos en mi dominio personalizado fallan, pero la dirección de ProtonMail funciona bien
Supongo que es porque ProtonMail no bloquea el tracking pixel
Ya decidí simplemente dejar de preocuparme
Como el correo físico les cuesta dinero, espero que algún día se den cuenta