Infraestructura email para bancos y fintech operando bajo DORA, PSD3 y el problema de suplantación de marca

Actualmente no. La primera batch de designaciones CTPP fue emitida por las ESA en noviembre 2025 y consistió en los proveedores cloud e IT services más grandes. Nuestro tamaño y concentración de clientes no cumple el umbral CTPP. Lo que significa prácticamente: bajo DORA Art. 28, tu banco es responsable del registro de terceros y la gestión de riesgo ICT alrededor de usarnos; bajo Art. 30, el contrato debe incluir las cláusulas específicas que DORA requiere; bajo Art. 19, tu banco es el reportero a la autoridad competente si un incidente ICT-related en nuestra infraestructura te afecta. Suministramos los datos técnicos del incidente en una hora; tú suministras el reporte del lado supervisor.

Authorize Hosting es una entidad sueca incorporada (Stockholm, establecida 2003) sin propiedad estadounidense en la cadena corporativa. Infraestructura primaria en Stockholm, secundaria en Frankfurt. Ambas son jurisdicciones UE y los datos permanecen en la UE por defecto. No hay transferencia a EE.UU. en ningún flujo de mail normal, y la inestabilidad del EU-US Data Privacy Framework — que el caso Schrems II dejó clara — no aplica a nuestra cadena.

Para bancos cuyos clientes explícitamente no quieren que sus datos toquen infraestructura propiedad de EE.UU. (típicamente clientes del sector público, productos banking-healthcare-adjacent, o instituciones con mandatos de soberanía UE), esta es la respuesta estructural. El DPA excluye explícitamente subprocesadores estadounidenses. Para comparación: cualquiera de los proveedores dominantes de infraestructura email propiedad de EE.UU. requiere una transfer-impact assessment para un cliente UE, y la mayoría de bancos encuentran esa evaluación progresivamente más difícil de defender a través de 2025 y 2026.

Los bancos típicamente tienen más streams de envío de los que se dan cuenta: el correo transaccional de la plataforma core banking, las notificaciones de servicio del CRM, la automatización de marketing para las cartas de oferta retail, el reporte de la división de gestión patrimonial, el stream separado de banca corporativa, el mail interno del sistema HR, los varios tenants Microsoft 365 / Google Workspace de oficina, el email-out del call center contratado, la plataforma de firma de documentos, las encuestas a clientes, las alertas automatizadas del equipo de seguridad, etc. Un inventario de 50 streams es común para un banco tier-2.

La progresión: primeros 30 días en p=none con reporte DMARC yendo a nuestro dashboard, donde parseamos los reportes agregados y producimos una evaluación de readiness stream-por-stream. La mayoría de bancos descubren 5-10 streams que no están autenticando limpiamente. Trabajamos con los equipos internos del banco para arreglar cada uno, luego pasamos a p=quarantine por otros 30 días para confirmar que ningún stream legítimo está siendo filtrado. Movimiento final a p=reject. Tiempo total transcurrido para un entorno de tamaño bancario: típicamente 90-120 días. Para estates muy grandes: 6 meses.

El reloj DORA Art. 19 para incidentes ICT-related mayores es: notificación inicial dentro de 24 horas de tomar conciencia, reporte intermedio dentro de 72 horas, reporte final dentro de 30 días (extendible a 90). Bancos en nuestro tier de pricing obtienen una rotación on-call de Stockholm con ingenieros nombrados y un árbol de escalado documentado. Incidentes críticos (multi-cliente afectados, regulator-visible) disparan respuesta dentro de una hora durante horas laborables UE; respuesta fuera de horario es 2-3 horas. Los datos técnicos del incidente que proveemos — streams de envío afectados, ventanas de tiempo, análisis de causa raíz, pasos de remediación — están estructurados para inclusión directa en la notificación del banco a la autoridad competente.

Dos efectos, trabajando en horizontes de tiempo diferentes. Efecto inmediato: BIMI requiere DMARC en p=reject como prerequisito. Llegar a p=reject detiene la suplantación directa de dominio (mail enviado desde el dominio del banco). El phishing que pasa después del despliegue BIMI es phishing por dominio lookalike, que es más difícil de montar y más fácil de detectar para los clientes.

Efecto a largo horizonte: los clientes sí aprenden a buscar el logo, pero toma 6-18 meses de presencia visual consistente en su inbox. El caso documentado de la institución financiera UE de 2025 mostró cambio de comportamiento de cliente al sexto mes — los clientes empezaron a reportar mensajes sin el logo como sospechosos. Este es el objetivo real: no "el cliente ve el logo y confía en el email", sino "el cliente nota cuando falta el logo y se vuelve sospechoso". Ese segundo comportamiento es lo que reduce las tasas de conversión de víctima phishing.

Dos patrones. Patrón SMTP relay: tu ESP (SFMC, Adobe, Selligent, Acoustic, o cualquier otro) mantiene su UI, su campaign builder, su segmentación, sus analytics. Lo que cambia es dónde sale el mail. En lugar de la infraestructura compartida del ESP, el ESP autentica a nuestro SMTP relay y el mail sale en nuestras IPs dedicadas bajo tu dominio. La mayoría de bancos montan esto para los streams de alta-deliverability (correo transaccional, restablecimientos de contraseña, notificaciones de extracto) y mantienen el correo promocional en la infraestructura nativa del ESP donde las señales de engagement no llevan peso regulatorio.

Patrón API directo: para correo transaccional específicamente — entrega de extractos, confirmaciones de pago, códigos 2FA — los bancos frecuentemente construyen directamente contra nuestra HTTP API o SMTP relay desde la plataforma core banking, bypassing el ESP focused en marketing entirely. Esto es más rápido, más confiable, y más fácil de auditar.

DORA Art. 26 requiere TLPT (threat-led penetration testing) para entidades financieras significativas al menos cada tres años. El alcance TLPT puede incluir terceros ICT cuya disrupción afectaría meaningfully al banco — que puede incluir la infraestructura email cuando el volumen de correo transaccional del banco es significativo o cuando la infraestructura email está en el registro de funciones críticas-o-importantes del banco.

Para bancos en el tier de pricing Tier-1, participamos en engagements TLPT como tercero en alcance. Proveemos entornos de prueba controlados, documentación de nuestro perímetro, y la liaison técnica para el red team durante la ventana de prueba. No participamos como tercero en TLPT para bancos por debajo de ese tier porque la disrupción operacional no vale la pena para ambos lados — pero la infraestructura subyacente es la misma, y el banco puede probarla indirectamente a través de la perspectiva customer-side del red team.