Finance & insurance
No industry is impersonated in email more than financial services. Every statement notification, payment confirmation and password reset you send trains customers to trust a format that somebody else is actively copying - and the same message has to arrive reliably, on time, and provably. Omnivery is transactional email infrastructure for banks, insurers and fintech: link allowlisting that rejects a message carrying an unapproved destination, TLS you can require rather than hope for, message content that is never stored, and independently audited continuity certification.
Updated: July 2026
Five constraints that apply to a bank, an insurer or a lender and do not apply to most senders.
A statement notification, a policy renewal, a tariff or terms change, an arrears notice: these are communications the customer is entitled to and in many cases the regulator requires. On most platforms an unsubscribe from marketing suppresses everything, and the failure is silent.
Omnivery treats transactional messages as bypassing unsubscribe and complaint suppressions, so a required communication still reaches someone who opted out of marketing. Bounce and block suppressions still apply, because those addresses genuinely cannot receive mail. Transactional mode is enabled per domain by the Omnivery team rather than self-serve, precisely because it changes suppression behavior - which is the right way round for a regulated sender.
Financial brands are the most impersonated in email. Your own legitimate mail is the reference material: the more consistent and trusted your notifications, the better the forgeries get.
Two controls address this directly. A URI allowlist means a message is rejected outright if any link in the body points somewhere not on your approved list, which turns a compromised template or an injected link into a send failure rather than a customer incident. Enforced TLS on delivery means a message is not handed to a receiver that will not encrypt the connection.
Balance figures, transaction detail, claim references, arrears status. Most providers store message bodies, so a copy of that sits in a third-party system indefinitely, inside your regulatory perimeter and inside your breach exposure.
Omnivery does not store message body content at all. Delivery metadata is retained for a maximum of 30 days and then reduced to summary volume counts. Strict privacy mode can be set per sending domain, in which case no personal information is stored and all of it is fully anonymized once metadata has been relayed to you. That is a materially different risk position from a provider retaining full bodies and event data.
Operational resilience expectations on financial entities now extend explicitly to their ICT third parties, which is why "what happens when your provider has an outage" has moved from a nice question to a documented one you must answer about your vendors.
Omnivery holds ISO 22301 for business continuity management and ISO/IEC 20000-1 for service management alongside ISO/IEC 27001 and ISO/IEC 27701, all independently audited and published as downloadable certificates. It also runs no third-party cloud in the delivery path, so there is no hyperscaler subcontracting chain to assess beneath the provider - the provider is the whole answer.
A dispute, an ombudsman complaint or an audit eventually becomes a question about exactly what the customer was told and when. Application logs rarely satisfy it.
Email journaling sends exact copies of outgoing messages to an archive address you nominate, enabled with a single domain setting rather than BCC rules spread across systems. Omnivery does not retain content itself, so journaling is the mechanism: if you need the message body kept, it goes to an archive you choose.
Most anti-phishing effort in financial services is defensive: filtering what arrives. The outbound side gets less attention, even though outbound is where your brand is being copied. Two controls on the sending side do real work.
Omnivery can hold an allowlist of permitted link destinations for a sending domain. With it enabled, a message is rejected if a single link in the body points to a destination not on that list.
What it catches is the useful part. A template edited by someone who should not have edited it. A tracking or personalization field that resolves to an attacker-supplied URL. A compromised content system quietly rewriting a destination. In every one of those cases the failure mode without allowlisting is that you successfully deliver a phishing link to your own customer list, under your own authenticated domain, with your own reputation behind it. With allowlisting the send fails and somebody investigates.
It is a blunt control. For a sender whose legitimate mail contains a small, stable set of destinations - your app, your help center, your document portal - bluntness costs nothing and closes a real path.
Opportunistic TLS means a message is encrypted in transit if the receiving server offers it, and sent in the clear if it does not. For most mail that is an acceptable trade. For a statement notification it may not be.
The X-OV-Require-TLS header instructs Omnivery to refuse delivery unless the receiving server offers TLS, per message. That converts encryption in transit from best-effort into an enforced condition you can point an auditor at - and because it works over SMTP as a mail header, a legacy core system can set it without code changes.
Requiring TLS and reaching the right server are two different guarantees, and a security reviewer will usually want the second one. Where a receiving domain publishes DANE records, Omnivery validates them on delivery: the receiving server has to present a certificate matching the TLSA record the domain published, and if it does not, the message is not delivered rather than being handed to an unauthenticated connection. That closes the downgrade path that enforced TLS on its own leaves open.
SPF, DKIM and DMARC are the foundation of not being impersonated, and their requirements keep moving. Omnivery publishes the sending records once and rotates DKIM keys through CNAMEs rather than requiring a key swap each time, and one-click unsubscribe under RFC8058 and feedback-loop reporting under RFC9477 are handled rather than left as implementation work.
Those controls authenticate the domain. S/MIME signing authenticates the message: Omnivery can apply an S/MIME signature to outbound mail, so a recipient's client can verify that the message came from you and that its contents were not altered afterwards. For a sector where a convincing forgery of a statement notification is the attack, that is a different and stronger assurance than an SPF or DKIM pass, because it survives the forwarding and re-signing that weaken domain-level checks - and it is visible to the recipient rather than only to their mail server.
Bot Detection matters in this sector specifically because security gateways at corporate recipients follow every link before a human sees it, so a financial sender's click data is heavily contaminated. If a fraud or engagement model is trained on that, it is being trained partly on scanners. The research puts bot clicks around 30% at Outlook against 2 to 4% at Yahoo and GMX.
Financial procurement does not ask whether a provider is good. It asks who is in the processing chain, where the data sits, what happens when it fails, and whether any of that is independently verified. Most of the effort in onboarding an email vendor goes into answering those four questions about parties the vendor itself subcontracts to.
Omnivery's answer is short because the chain is short.
Omnivery runs exclusively on its own physical infrastructure. There is no AWS, Azure or Google Cloud in the delivery path, which removes an entire tier from the assessment: no shared-tenancy question, no cloud provider agreement layered beneath your contract, and no second sub-processor chain to review. Data centers are required to be ISO 27001 and Tier 3 certified.
All operations are performed by the Czech entity, including the US data centers offered for US residency - the Austin office is a sales function that operates no infrastructure and holds no customer data. Residency is therefore a customer choice between the EU and the US on owned infrastructure either way, and choosing US changes where the machines are without changing who processes the data or which legal system governs it.
There are no US sub-processors in the core email service; US-incorporated vendors apply only to optional, customer-selectable features. The current list is published rather than supplied on request, and the CLOUD Act, Schrems II and SCC analysis is on the GDPR compliant email API page.
Seven ISO certifications plus HIPAA, all published as downloadable certificates rather than described in a questionnaire response:
Handing over the certificates is faster than completing the questionnaire. For continuity specifically, ISO 22301 plus owned infrastructure is a materially different answer from a certification held by a provider whose actual capacity is rented from a third party.
Continuity planning is moot if the mail does not arrive in the first place. Financial senders are frequently sending to a customer base concentrated in one or two countries, which means national mailbox providers rather than the global four. Omnivery's position on that is on the deliverability page: a destination is not less important because it is smaller, and senior deliverability analysts review placement per receiver rather than in aggregate.
ČSOB, Patria Finance, Avtal and TrueML all send with Omnivery.
Statement notifications, transaction and fraud alerts, card and payment confirmations, and the authentication mail that has to arrive in seconds. ČSOB sends with Omnivery.
Policy documents, renewal notices, claim status updates and premium reminders, where the communication is contractual rather than promotional. ČSOB Pojišťovna, ČSOB's insurance arm, sends with Omnivery.
Onboarding and KYC flows, repayment reminders, arrears communications and settlement confirmations, usually at higher volume and on a shorter product cycle. TrueML and Avtal send with Omnivery.
Where the sending system predates the compliance regime it now sits inside and cannot be modified on that timetable. The SMTP relay covers it with one configuration change - see on-premise MTA replacement.
Contract notes, valuation statements and regulatory correspondence, where retention and proof of what was sent matter as much as delivery. Patria Finance sends with Omnivery.
Where the blocking question is who else is in the processing chain, and "nobody, it is our own hardware" is a shorter answer than a hyperscaler subcontracting diagram.
Yes, provided it is sent on a domain configured as transactional. Omnivery treats transactional messages as bypassing unsubscribe and complaint suppressions, on the basis that a statement, renewal notice or arrears communication is a contractual or regulatory obligation rather than a marketing message. Bounce and block suppressions still apply, because those addresses genuinely cannot or must not receive mail.
Transactional mode is enabled per domain by the Omnivery team rather than being self-serve, specifically because it changes suppression behavior. Separating regulatory and marketing streams onto different sending domains is the usual pattern for a regulated sender.
It closes the outbound path rather than the inbound one. Omnivery can hold an allowlist of permitted link destinations for a sending domain, and with it enabled a message is rejected if any link in the body points somewhere not on that list.
The cases it catches are the ones that hurt most: an edited template, a personalization field resolving to an attacker-supplied URL, or a compromised content system rewriting a destination. Without it, the failure mode is that you deliver a phishing link to your own customers under your own authenticated domain with your own reputation behind it. With it, the send fails and somebody looks at why.
It is deliberately blunt. For a sender whose legitimate mail contains a small, stable set of destinations, that costs nothing.
Yes. Omnivery can apply an S/MIME signature to outbound mail, so the recipient's mail client can verify that the message came from your organization and that its content was not altered in transit.
Signing authenticates the message; SPF, DKIM and DMARC authenticate the sending domain. Signing is the stronger assurance of the two for an impersonation concern, because it is verifiable by the recipient rather than only by their mail server, and it survives forwarding that breaks domain-level alignment. It is not body encryption: an S/MIME signed message is still readable in transit, which is what enforced TLS and DANE validation address separately.
Yes. The X-OV-Require-TLS header instructs Omnivery to refuse delivery unless the receiving server offers TLS, applied per message. That turns encryption in transit from best-effort into an enforced condition, which is usually what a control owner is actually asking for.
Because it is a mail header it works over SMTP too, so a core banking or policy administration system can set it without any code change.
Omnivery also validates DANE on outbound delivery. Where the receiving domain publishes TLSA records, the receiving server has to present a certificate that matches them or the message is not delivered - so the connection is not merely encrypted, it is encrypted to a server that has been authenticated. If a reviewer is asking about transport security specifically, that is usually the answer they want alongside enforced TLS.
It is not. Omnivery does not store message body content at all. This is an architectural default rather than a configurable retention setting, so there is no setting to get wrong and no retention window to negotiate default. Delivery metadata is kept for a maximum of 30 days and then reduced to summary volume counts, and strict privacy mode replaces the recipient address with a hash in analytics.
For a financial sender that changes the shape of the risk assessment: there is no repository of balances, transaction detail or claim references sitting in a third-party system inside your regulatory perimeter. If you do need copies retained, email journaling sends exact copies to an archive address you control, which keeps the retention decision and its location yours.
Omnivery holds ISO 22301 for business continuity management and ISO/IEC 20000-1 for service management alongside ISO/IEC 27001 and ISO/IEC 27701, and publishes all seven ISO certificates plus HIPAA for download rather than supplying them under NDA on request.
The architecture usually answers more of the questionnaire than the certificates do. Omnivery runs exclusively on its own physical infrastructure with no AWS, Azure or Google Cloud in the delivery path, so there is no hyperscaler subcontracting chain beneath the provider to assess - and the data centers it uses are required to be ISO 27001 and Tier 3 certified. If an assessment needs something that is not published, ask for it.
That is the common case and it does not require changing the platform. Point it at Omnivery's SMTP relay on smtp.omnivery.net port 587 and it inherits the same certifications, the same 30-day metadata cap and the same policy of never storing content, with one configuration change and no code.
The relay is not a reduced-capability path: templates, tracking control, callbacks, enforced TLS and journaling are all available through X-OV-* mail headers. If the goal is specifically retiring a self-hosted mail server, that case is on on-premise MTA replacement.
Omnivery publishes its data processing conditions and its sub-processor list rather than gating them, and both are linked from /legal.
On the US question specifically: all operations are performed by the Czech entity, including the US data centers offered for US residency, and the Austin office is a sales function that operates no infrastructure and holds no customer data. There are no US sub-processors in the core email service; US-incorporated vendors apply only to optional, customer-selectable features. So selecting US residency changes where the machines are without changing who the processor is or which legal system governs it.
Less than you would like, and financial senders are among the worst affected because corporate security gateways follow every link before a human sees it. Omnivery's own research puts bot clicks at around 30% at Outlook and over 20% at Gmail, against 2 to 4% at Yahoo and GMX.
A model trained on that is partly trained on scanners. Bot Detection returns an is_bot decision per interaction from more than 20 proprietary datasets so the events feeding a model can be filtered first. The findings are in The State of Email Bots 2026, also available as a PDF.
If a vendor assessment is what usually holds this up, start there rather than with the technical evaluation: the ISO and HIPAA certificates and the sub-processor list are published, so a reviewer can begin before anyone signs anything. Domain vetting then takes one to three working days.