Email infrastructure for banks and fintech operating under DORA, PSD3, and the brand-impersonation problem

Not currently. The first batch of CTPP designations was issued by the ESAs in November 2025 and consisted of the very largest cloud and IT services providers (the typical names in that list are public). Our size and customer concentration don't meet the CTPP threshold. What this means practically: under DORA Art. 28, your bank is responsible for the third-party register and the ICT risk management around using us; under Art. 30, the contract has to include the specific clauses DORA requires; under Art. 19, your bank is the reporter to the competent authority if an ICT-related incident on our infrastructure affects you. We supply the technical incident data within an hour; you supply the supervisory-side report.

Banks that need a CTPP-designated provider on grounds of internal procurement policy can use one of the designated names; we work as a complement rather than a replacement when that's the case. We've found that this is rare — most banks decide that for email infrastructure specifically, an EU-jurisdiction operator with no US ownership matters more than CTPP designation.

Authorize Hosting is a Swedish-incorporated entity (Stockholm, established 2003) with no US ownership in the corporate chain. Primary infrastructure is in Stockholm, secondary in Frankfurt. Both are EU-jurisdictions and the data stays in the EU by default. There is no transfer to the US in any normal mail flow, and the EU-US Data Privacy Framework's instability — which the Schrems II case made clear — doesn't apply to our chain.

For banks whose customers explicitly do not want their data touching US-owned infrastructure (typically public sector clients, healthcare-banking-adjacent products, or institutions with EU sovereignty mandates), this is the structural answer. The DPA explicitly precludes US sub-processors. For comparison: any of the dominant US-owned email infrastructure providers (the major US-headquartered ESPs and cloud sending services) requires a transfer-impact assessment for an EU customer, and most banks find that assessment progressively harder to defend through 2025 and 2026.

Banks typically have more sending streams than they realize: the core banking platform's transactional mail, the CRM's service notifications, the marketing automation for the retail offer letters, the wealth management division's reporting, the corporate banking division's separate stream, the HR system's internal mail, the various office Microsoft 365 / Google Workspace tenants, the contracted call center's email-out, the document signing platform, the customer surveys, the security team's automated alerts, and so on. A 50-stream inventory is common for a tier-2 bank.

The progression: first 30 days at p=none with DMARC reporting going to our dashboard, where we parse the aggregate reports and produce a stream-by-stream readiness assessment. Most banks discover 5-10 streams that aren't authenticating cleanly (typically older or less-maintained systems, or third-party vendors whose authentication setup was never completed). We work with the bank's internal teams to fix each, then move to p=quarantine for another 30 days to confirm no legitimate stream is being filtered. Final move to p=reject. Total elapsed time for a bank-sized environment: typically 90-120 days. For very large estates: 6 months.

The DORA Art. 19 clock for major ICT-related incidents is: initial notification within 24 hours of becoming aware, intermediate report within 72 hours, final report within 30 days (extendable to 90). Banks at our pricing tier get a Stockholm on-call rotation with named engineers and a documented escalation tree. Critical incidents (multi-customer affecting, regulator-visible) trigger response within an hour during EU business hours; off-hours response is 2-3 hours. The technical incident data we provide — affected sending streams, time windows, root cause analysis, remediation steps — is structured for direct inclusion in the bank's notification to the competent authority.

What we don't do is file the notification with the competent authority on your behalf. That's the bank's regulatory responsibility, and trying to delegate it to us would create more compliance risk than it would solve. Our job is to make sure the data you submit is accurate, complete, and on time.

Two effects, working over different time horizons. Immediate effect: BIMI requires DMARC at p=reject as a prerequisite. Getting to p=reject stops direct domain spoofing (mail sent from your bank's domain). The phishing that gets through after BIMI deployment is lookalike-domain phishing (sent from your-bank-securely.com or similar), which is harder to set up and easier for customers to spot.

Long-horizon effect: customers do learn to look for the logo, but it takes 6-18 months of consistent visual presence in their inbox. The documented EU financial institution case study from 2025 showed customer behavior change at the six-month mark — customers started reporting messages without the logo as suspicious. This is the actual goal: not "the customer sees the logo and trusts the email," but "the customer notices when the logo is missing and gets suspicious." That second behavior is what reduces phishing victim conversion rates.

Two patterns. SMTP relay pattern: your ESP (SFMC, Adobe, Selligent, Acoustic, or anything else) keeps its UI, its campaign builder, its segmentation, its analytics. What changes is where the mail leaves on. Instead of the ESP's shared infrastructure, the ESP authenticates to our SMTP relay and the mail leaves on our dedicated IPs under your domain. Most banks set this up for the high-deliverability streams (transactional mail, password resets, statement notifications) and keep promotional mail on the ESP's native infrastructure where the engagement signals don't carry regulatory weight.

Direct API pattern: for transactional mail specifically — statement delivery, payment confirmations, 2FA codes — banks often build directly against our HTTP API or SMTP relay from the core banking platform, bypassing the marketing-focused ESP entirely. This is faster (no campaign-builder overhead), more reliable (fewer intermediate systems), and easier to audit (one less vendor in the chain).

DORA Art. 26 requires TLPT for significant financial entities at least every three years. The TLPT scope can include ICT third parties whose disruption would meaningfully affect the bank — which can include the email infrastructure when the bank's transactional mail volume is significant or when the email infrastructure is in the bank's critical-or-important-functions register.

For banks at the Tier-1 pricing tier, we participate in TLPT engagements as a third-party in scope. We provide controlled test environments, documentation of our perimeter, and the technical liaison for the red team during the test window. We don't participate as a third-party in TLPT for banks below that tier because the operational disruption isn't worth it for both sides — but the underlying infrastructure is the same, and the bank can test it indirectly through the red team's customer-side perspective.