Why is banking and fintech email a regulated concern?
For an EU bank, e-money institution, or licensed fintech, the email infrastructure that delivers transaction confirmations, fraud alerts, KYC notifications, and statement-ready emails is in scope for DORA (Digital Operational Resilience Act), in scope for NIS2 Article 21 as an "important entity" supplier, and routinely audited under EBA SREP and ECB on-site inspections. The infrastructure choices that work for a B2C SaaS do not work here, because the operational resilience, third-party risk management, and contractual provisions required by financial supervisors are specific and prescriptive.
What does DORA require from your email infrastructure provider?
DORA Article 30 mandates that contracts with ICT third-party service providers include specific provisions: complete description of services, locations of data and operations, service-level agreements, monitoring and reporting requirements, business continuity provisions, sub-contracting controls, audit rights, exit-and-portability rights. Article 28 requires that financial entities maintain a register of ICT third-party arrangements with specific information fields. Article 31 covers Critical ICT Third-Party Provider designation. We are not currently a CTPP (designation threshold is significantly above our customer footprint), but our standard Enterprise DPA addendum includes every Article 30(2) requirement and we provide the Article 28 register fields in a customer-portal export.
EU banking customers we currently serve.
We serve regulated EU financial-sector senders — credit institutions, e-money institutions, investment-services firms, and payment-services providers. They use us for combinations of transactional banking emails (statements, transaction confirmations), security alerts (fraud detection, login anomalies), regulatory communications (PSD2 SCA prompts, MiFID II disclosures), and operational notifications (compliance officer alerts, internal escalation). All under custom Enterprise contracts with the specific DORA Article 30 provisions and audit rights spelled out.
How does DORA incident reporting affect your email provider?
DORA requires you to classify a major ICT incident within 24 hours of becoming aware of it, then file an initial notification with your competent authority within four hours of that classification, an intermediate report within 72 hours, and a final report with root-cause analysis within one month. The clock starts at classification, not detection, so the classification decision itself has to be fast and documented. RTS 2024/1772 sets six criteria — clients affected, data losses, reputational impact, duration and downtime, geographic spread, and economic cost with a €100,000 threshold — and an incident is major when it crosses two of them, or one severely. Here is why that matters for an email provider. If transaction confirmations or SCA prompts stop arriving and you cannot tell whether the cause is your side or ours, you cannot classify, and the four-hour window is already running. Our incident handling for financial-sector customers is built to feed that window rather than compete with it: a named CSM contact within 30 minutes of detection, a written initial assessment within two hours, and a written incident report within 24 hours — the document you attach to your initial and intermediate filings. You file through your national authority signed with your own qualified eIDAS certificate; we supply the technical facts in the order the RTS 2025/301 template asks for them.
Transactional email is an ICT service supporting an important function.
A recurring mistake in fintech procurement is filing email under marketing tooling. Under DORA the test is functional: does the service support a critical or important function? Email that carries strong customer authentication prompts, fraud and login-anomaly alerts, payment confirmations, and statement delivery supports functions a supervisor will read as important, because a sustained delivery failure has direct customer and prudential impact. That places your email provider inside the third-party ICT arrangements Articles 28 and 30 govern — the same register and contract regime you apply to your core banking platform vendor, scoped to its actual risk. The practical consequence is that the agreement cannot be a click-through SaaS contract. It needs the Article 30(2) provisions: service description, data and processing locations, service levels, monitoring and reporting, business continuity, subcontracting controls, audit rights, and exit and portability terms. Our Enterprise DPA addendum carries each of these as standard clauses rather than as a per-customer negotiation, which is what keeps legal review to one or two rounds instead of a quarter of back-and-forth. We are equally clear about what we are not: we are not a Critical ICT Third-Party Provider, since that designation is made by the European Supervisory Authorities on systemic-importance grounds and our footprint is far below it. Your Article 30 obligations apply regardless of our CTPP status, so the terms are what matter, not the label.
What do you need for the DORA Register of Information?
DORA Article 28 requires every financial entity to keep a Register of Information describing its ICT third-party arrangements, and to submit it to the competent authority each year, with the deadline falling on 30 April. The register is not a free-text inventory. The European Supervisory Authorities publish a structured template with defined fields: provider legal identifiers including LEI, the function supported and whether it is critical or important, data and processing locations, the start and end dates of the arrangement, the subcontracting chain, and a substitutability assessment. Filling those fields for an email provider that hides its infrastructure behind a generic "global cloud" description is painful, because half the fields are unanswerable. We give financial-sector customers a portal export pre-mapped to the register fields: our legal entity and LEI, the precise EU datacenter locations in use for that account, the subprocessor list with roles, and the contractual start date. When your GRC team assembles the annual submission, the email row is filled from our export rather than reconstructed from old support tickets. It reads like a small thing until the 30 April deadline is two weeks out and the register has a blank where the email vendor should be.
Subcontracting controls, and the chain you are actually signing.
The 2024 RTS on subcontracting ICT services that support critical or important functions tightened what financial entities must know and control about their providers' own suppliers. You are entitled to see the subcontracting chain, to be notified of material changes before they take effect, and to object. For an email provider the chain is short but not empty: upstream connectivity, the CDN in front of the customer portal, the payments processor for billing, and any third-party seed or reputation data feeds. Our standard chain for financial-sector accounts is written into the DPA addendum rather than buried in a sub-processor page that changes without notice. Where a national supervisor restricts US-headquartered subprocessors for sensitive workloads, we can route around the usual US defaults with an alternate CDN and EU-only payments handling, for an additional €499 per month and roughly two weeks of setup. We would rather quote that honestly than pretend the default configuration already satisfies a residency restriction it does not.
How do DORA, NIS2 and PCI DSS overlap on email?
Most regulated senders are not subject to DORA alone. NIS2 Article 21 adds supply-chain security and incident-handling obligations for important and essential entities, and a bank email supplier is part of that supply chain. PCI DSS v4.0 made DMARC handling a requirement for organizations that process payment-card data, which pulls email authentication into the cardholder-data conversation. The useful part is how much these regimes share. One set of controls — enforced DMARC at p=reject, EU-pinned processing, documented incident timelines, an audited subprocessor chain, and annual resilience evidence — answers the email-relevant parts of all three at once. We structure the financial-sector account so the same artifacts serve each filing: the resilience attestation we produce every January maps to DORA testing and reporting expectations, supports the NIS2 risk-management narrative, and gives your PCI assessor the email-authentication evidence in one place. The point is to stop the same questions being answered three times, in three formats, for three different auditors.
What breaks when a regulated bank uses a US hyperscaler for email?
The honest comparison is worth making, because procurement teams ask for it. SendGrid, Amazon SES, Mailgun, and Postmark are competent senders, and for an unregulated consumer product they are reasonable defaults. The problem inside a regulated EU financial entity is structural rather than technical. Each runs under a US corporate parent, which makes Schrems II a live transfer question your DPO has to document rather than wave away, and which keeps the CLOUD Act and FISA 702 in scope for your transfer impact assessment. Their standard contracts are click-through and do not carry DORA Article 30(2) provisions; getting those terms added, where it is possible at all, becomes a custom negotiation their legal team is not built to move quickly. Support is tiered and ticket-based, which is fine for a configuration question and a poor fit when a four-hour DORA clock is running and you need an engineer who knows what a DKIM selector is and what happens when an IP lands on a Spamhaus list. None of this makes those providers bad. It means the regulatory and operational profile of a supervised financial entity is a different problem from the one they were built to solve, and the migration we see most often is a bank moving its regulated, customer-facing streams to EU infrastructure while leaving low-risk internal mail where it already is.
Exit and portability, written down before you need it.
DORA Article 30 and the EBA outsourcing guidelines both require that a contract for an important function spells out an exit strategy: how you get your data and operations back, and how you move to another provider or in-house, without an unacceptable continuity gap. For email that means three concrete things. Your sending domains and DKIM selectors stay yours and move with you. Your suppression lists, templates, and historical event data export in open formats. And the reputation you built on dedicated IPs does not evaporate on the way out. Our standard financial-sector contract documents a 90-to-180-day exit window with defined handover steps: a full export of configuration and data, a parallel-run period where the incoming provider warms its own IPs while we keep delivering, and a documented cutover. We put this in writing at signing rather than at termination, because an exit clause negotiated while you are already leaving is worth very little. A supervisor reviewing your third-party arrangements will ask to see the exit plan, and you should be able to hand it over without drafting it on the spot.