Email infrastructure for regulated finance.

Email infrastructure for financial services is not generic email infrastructure with a different sales pitch. The differences are structural and they show up in the contract before they show up in the technology. Three of them set the tone for everything else. First, the regulatory layer is denser than in any other vertical we operate in, and it changes faster than any vendor's roadmap can match. Second, the procurement framework typically excludes specific jurisdictions or vendors or sub-processors before any technical conversation begins, which means the technical fit only matters within the subset of providers that have already cleared the procurement gate. Third, the consequences of getting deliverability wrong are more expensive than in any other vertical: a failed transactional email can mean a missed authorisation, a delayed regulatory filing, a client complaint that escalates to the regulator within 48 hours.

What we have learned across roughly forty engagements with fintech and regulated-financial customers since 2020. The customer rarely buys email infrastructure on technical merit. The customer buys an architectural answer to a compliance question, and the technical performance is the thing they need to verify after the architectural answer has cleared the procurement framework. This page describes what we have observed about how that decision goes, the regulatory layer that drives it, the jurisdictional choices that fit different financial-services profiles, and the patterns we have seen go wrong when vendors who do not understand the vertical try to compete in it.

FCA + UK. The UK's Financial Conduct Authority operates the densest sector-specific framework affecting email infrastructure. SYSC 8 governs the outsourcing of operational functions, including email and messaging where they support regulated activity. SYSC 9 governs record-keeping, with retention periods up to seven years for client communications in certain product categories (longer for pension and insurance products under separate handbook sections). The FCA does not pre-approve email vendors, but it does expect the regulated firm to have evidenced due diligence on its outsourcing arrangements and to have written contracts containing the audit-rights and termination provisions specified in SYSC 8.1.7R through 8.1.13G. Customer-supplied DPAs in our UK engagements typically request explicit reference to SYSC 8 in the audit-rights clause, which we accept.

MiFID II + EU markets. MiFID II Article 16(7) imposes record-keeping obligations on investment firms that include the recording and retention of electronic communications relating to client orders or trade advice or portfolio management activity. The retention period is five years from the date of the recording, extending to seven years where required by national competent authorities. Member states have transposed the directive with variations: the UK retained the Article 16(7) framework through FCA COBS 11.8, Germany's BaFin enforces the equivalent under WpHG section 83, France's ACPR through the AMF Règlement Général. Email infrastructure for MiFID II-scope firms must support retrieval of client communications across the full retention window, with timestamping that survives infrastructure migration and an audit trail that demonstrates non-repudiation.

PSD2 + payment services. The Payment Services Directive 2 imposes specific notification obligations on payment service providers. Article 95 requires reporting of major operational and security incidents to the competent authority without undue delay, with the reporting timeline transposed by national authorities (typically two to four hours for the initial notification, with detailed follow-up within 72 hours). Where email infrastructure is part of the security incident chain — for example, where a phishing attack against the firm's customers traces back to compromised authentication on the firm's sending domain — the firm's incident response runbook must explicitly cover email-side notifications. We have seen procurement teams reject email vendors whose incident response SLA does not match the timeline the firm needs to meet under PSD2 Article 95.

Banking secrecy. Bank secrecy provisions create additional considerations beyond the EU-wide framework. Luxembourg's Loi du 5 avril 1993 imposes professional secrecy on credit institutions and financial-sector professionals, with personal liability for breach extending to employees and contractors who handle the relevant data. Switzerland's Article 47 of the Banking Act (BankG) imposes equivalent obligations with criminal sanctions for unauthorised disclosure. France's Code monétaire et financier Article L511-33 frames a similar obligation. Email infrastructure that handles communications subject to these provisions cannot route those communications through sub-processors who are not bound by equivalent confidentiality obligations and who do not operate within a jurisdiction whose courts will enforce them. This is the single most common reason European banking customers reject US-domiciled email vendors regardless of their technical capabilities.

GDPR overlay. GDPR applies as the baseline data protection regime across all of the above. The financial-services-specific overlay produces specific tensions. GDPR Article 17 (right to erasure) interacts with MiFID II Article 16(7) (retention obligation), with the typical resolution being that the retention obligation prevails for the records covered by the regulatory mandate, but the data subject's right of access under Article 15 still applies. GDPR Article 6(1)(c) (legal obligation) is the typical legal basis for the retention itself. Customer communication outside the scope of MiFID II retention (general marketing, account administration messages not tied to regulated activity) reverts to standard GDPR analysis without the sectoral overlay. Email infrastructure for financial services has to handle both regimes simultaneously, with retention periods and access controls differentiated by the regulatory classification of each message.

Retention with regulatory mapping. Retention is the single most-asked question in our financial-services intake calls. The honest answer requires knowing the customer's regulatory footprint before we can quote a number. A UK fintech under FCA SYSC 9 typically needs five to seven years on client communications. A MiFID II investment firm needs five years extending to seven where the national competent authority requires it. A PSD2 payment service provider needs records sufficient to support incident reconstruction for the full statutory window in their member state. Beyond the sectoral retention, the GDPR baseline applies for everything outside the regulatory scope. Our infrastructure handles the differentiation through metadata classification at message-acceptance time, with retention policies applied per-classification rather than uniformly across all traffic. The customer's compliance team owns the classification rules; we operate the retention against the rules they define.

Audit logs. Audit logs in financial-services email infrastructure are a separate category from operational logs. Operational logs (delivery status, bounce codes, recipient engagement) are retained for 30 to 90 days for deliverability troubleshooting. Audit logs (admin access, configuration changes, security events) are retained for seven to ten years on append-only storage in a separate jurisdiction from production. The seven-year minimum maps to NIS2 Law 217/2024 in Slovenia and to comparable transpositions in other member states. The longer ten-year retention applies where MiFID II Article 25(5) reconstruction obligations may require evidence of who had access to client communications during the retention window. Our audit log architecture is documented at /trust/#technical and has supported audit reviews from UK regulators as well as German and Luxembourg ones in the engagements we have run.

Breach notification SLAs. Breach notification is where vendor SLA terms collide with regulatory timelines. GDPR Article 33 requires notification to the supervisory authority within 72 hours of awareness. PSD2 Article 96 imposes faster timelines (typically two to four hours) for major operational incidents. NIS2 imposes a 24-hour early-warning notification. The vendor that takes 48 hours to confirm a breach to its customer is incompatible with the customer's PSD2 obligations, regardless of how good the technical infrastructure is. Our standard DPA commits to 48-hour breach notification; financial-services customers regularly request 24-hour or 12-hour windows, which we accept after reviewing the customer's specific regulatory exposure. We do not push back on tighter breach notification SLAs in this vertical because the regulatory regime makes them operationally reasonable.

Sub-processor scrutiny. Sub-processor scrutiny is more rigorous in financial services than in any other vertical. The procurement team typically reviews each sub-processor for jurisdiction, regulatory status, ownership chain, and beneficial ownership. The OVH Canada ruling of September 2025 has produced a measurable change in our intake conversations: customers who would previously have accepted any EU-domiciled sub-processor now ask about foreign subsidiary exposure. Our published sub-processor list at /trust/#subprocessors lists eight EU-domiciled entities with no foreign subsidiary exposure that would create equivalent process reach. This is a deliberate architectural choice, not a marketing claim, and it is the architectural choice that allows us to serve regulated-financial customers without the contractual complications that vendors with US-domiciled entities have to manage.

Data residency. Data residency requirements vary by sub-segment. Banking-secrecy customers (Luxembourg, Switzerland, France retail banking) typically require data to remain within the secrecy jurisdiction. Investment firms under MiFID II are typically EU-flexible as long as the residency is within the EEA or an adequacy-decision country. Insurance customers under Solvency II or comparable national regimes typically require data within the regulating member state. Crypto-asset firms under MiCA have specific residency provisions in Article 67 that we have begun to see in 2026 intake conversations. The matching of customer regulatory profile to our jurisdiction options is described in section 4.

The jurisdiction-to-customer mapping in our financial-services book is more concentrated than in any other vertical. About 38 percent of our offshore-dedicated revenue lands in Luxembourg, primarily from regulated-financial customers. The reasoning is operational rather than legal magic. Luxembourg combines a hard banking-secrecy statute with EU member status, the strongest GDPR enforcement track record in the bloc (the Amazon CNPD ruling of July 2021 set the largest GDPR fine in EU history at €746 million), and a regulatory authority (the CSSF) that has experience with non-bank financial firms whose operational model involves outsourced infrastructure.

Luxembourg fit. Luxembourg is the right jurisdiction for European customers running PSD2-scope payment services, MiFID II investment activity, or fund administration where the firm or its parent is established in the EU. The Loi du 5 avril 1993 secrecy provisions apply to email communications related to client business, and our infrastructure complies with the personal-secrecy obligations through the access controls described in our Trust documentation. Customers in this profile typically deploy on dedicated PowerMTA or KumoMTA infrastructure in our Luxembourg PoP, with backup replication to our Swiss facility for disaster recovery.

Switzerland fit. Switzerland is the right jurisdiction for customers whose primary regulatory anchor is wealth management, private banking, or any business whose internal compliance frame specifically references Article 47 of the Swiss Banking Act. The Swiss adequacy decision from the European Commission (in force since the equivalence determination of August 2024 confirming the revFADP regime) means that EU customers can use Swiss infrastructure without the SCC complexities that previously applied. Customers in this profile typically deploy in our Zurich PoP with EU-internal backup to Luxembourg or Ljubljana.

Slovenia fit (cost-effective). Slovenia is the right jurisdiction for cost-sensitive financial-services customers whose regulatory profile does not specifically require Luxembourg or Swiss anchors. UK fintech customers post-Brexit who are already operating outside the EU framework often find Slovenia the more efficient choice because the cost differential is meaningful and the regulatory profile (full EU member, GDPR native, NIS2 compliant, the CCR 1258/2009 retention precedent) is materially equivalent to the alternatives for the workloads they actually run. The UK Fintech case study described elsewhere on this site is one example of this pattern.

When we recommend a different vendor. We do not always win the deal. About 8 percent of our financial-services intake conversations end with us recommending the customer use a different vendor. The most common reason is procurement framework requirements that specifically mandate ISO 27001 or SOC 2 certification, which we have not pursued for the reasons documented at /trust/#regulatory. We route those customers to providers whose certification status meets their procurement gate. The honest framing matters more than winning every deal. A customer whose procurement framework rejects us at the certification stage will churn at the first audit if we obscure the gap during the sales conversation, and the long-term cost of that churn is higher than the short-term cost of a deal we did not chase.

Pattern 1: Vendor accepts FCA SYSC reference without reading it. The first pattern is the email vendor that accepts an FCA SYSC reference in the contract without understanding what it actually requires. SYSC 8.1.7R requires the regulated firm to retain ultimate accountability for any outsourced operational function, with sufficient rights of audit and termination to demonstrate effective oversight. A vendor that signs the SYSC reference but operates a contract template that limits audit rights to two business days per year, or that imposes commercial restrictions on the firm's ability to terminate for regulatory reasons, has effectively contracted around the obligation the firm needs to demonstrate to the FCA. We see this pattern in customer-supplied contracts that have been pre-approved by the firm's procurement team but never actually reviewed by an FCA-fluent compliance lawyer. Our DPA template explicitly preserves the audit-rights latitude SYSC 8 contemplates, and we accept tighter customer-supplied amendments where they reflect the firm's specific FCA correspondence history.

Pattern 2: Sub-processor exposure not actually mapped. The second pattern is the financial-services customer who reads our sub-processor list and then forgets to map it against their own firm-level sub-processor disclosure to their regulator. FCA-regulated firms are typically required to disclose material outsourcing arrangements to the regulator under SYSC 8.1.4R or to maintain an internal outsourcing register reviewable by the regulator on request. Adding our infrastructure as a sub-processor without updating the firm's disclosure produces a documentation gap that surfaces in the next regulatory review. We have seen this gap escalate to a regulatory enquiry twice; in both cases the remediation was to update the firm's outsourcing register and document the email infrastructure as a material outsourcing arrangement, which closed the gap without sanction. The pattern is avoidable with a 30-minute conversation between the firm's compliance team and ours during the migration.

Pattern 3: Retention classification not actually implemented. The third pattern is the firm that has a written policy on email retention classification but has not actually implemented the classification at the message-acceptance layer. Email infrastructure cannot retroactively classify messages by regulatory scope after they have been sent through the system. The classification has to happen at message acceptance, with the metadata that drives differential retention attached to the message before it enters the queue. We have seen firms migrate email infrastructure to our system with the assumption that we would handle the classification automatically, only to discover that the classification rules need to be defined by the firm's compliance team and enforced at the application layer that submits messages to our infrastructure. The fix is straightforward but it is the firm's work, not ours. A vendor that promises to handle regulatory classification automatically without input from the firm's compliance team is making a promise it cannot deliver.

What we run for financial-services customers, in concrete terms. Dedicated PowerMTA or KumoMTA clusters on bare metal in Luxembourg or Switzerland or Slovenia, depending on the customer's regulatory profile. Customer-controlled DKIM keys with rotation procedures the customer can audit. SPF, DMARC, MTA-STS, and BIMI configuration and ongoing maintenance. Full delivery and bounce parsing with metadata classification at message-acceptance time, supporting differential retention by regulatory scope. Audit logs on append-only storage in a separate jurisdiction from production, retained for the period the customer's regulatory profile requires. Incident response on the 7-minute first-response SLA documented in our Trust page, with breach notification windows tightened where the customer's PSD2 or comparable obligations require shorter timelines.

What we do not run. We do not operate ISO 27001 certification audits or SOC 2 Type II reports. We do not pre-classify messages by regulatory scope on the customer's behalf; that classification is the firm's compliance work and our infrastructure enforces the rules the firm defines. We do not provide the legal opinion that the firm needs from its own counsel on whether our infrastructure satisfies the firm's specific regulatory obligations. We do provide the technical and architectural documentation that the firm's counsel needs to write that opinion, and we have supported counsel-led reviews from FCA-equivalent regulators in five EU markets in past engagements.