When Revolut discovered a scammer impersonating a government agency using a legitimate email domain, it highlighted a key debate in financial services security: Is email authentication primarily a technical control for your IT security team, or is it a fraud detection issue for your risk team?
The answer affects everything from budget allocation to incident response protocols. Yet, many organizations haven't explicitly decided.
The Case for IT Ownership
Email authentication naturally fits within IT security. The technical controls are well-established: SPF records verify sending servers, DKIM signatures authenticate message content, and DMARC policies instruct receiving servers on handling failures. These protections require DNS configuration, mail server management, and ongoing monitoring of authentication reports.
When email security is treated as an IT issue, you get systematic coverage. Your team deploys sender authentication across all domains, monitors DMARC reports for configuration drift, and maintains logs when authentication fails. These controls apply uniformly, whether the email contains a password reset link or a request for customer data.
IT teams also manage perimeter defenses that catch most phishing attempts before they reach employees. Secure Email Gateways analyze sender reputation, URL rewriting services detach suspicious links, and sandbox environments isolate attachments. These tools process thousands of messages daily with minimal human intervention.
The technical argument strengthens when considering integration points. Your IT security stack already correlates email threats with endpoint detection signals, firewall logs, and identity access patterns. An email from an unusual location that triggers an MFA challenge creates a richer signal when systems share data. IT teams have the tools and expertise to build these connections.
The Case for Fraud Team Ownership
Email-based social engineering isn't just a technical failure. It's a fraud tactic exploiting trust, business processes, and human decision-making under pressure. When a scammer uses a legitimate government email domain to request customer data, as with Revolut, technical controls may pass. The domain is authentic, the SPF record validates, and DMARC shows a pass result.
What fails is the fraud detection layer: recognizing that an unusual request pattern from an authenticated source still needs verification through a secondary channel.
Fraud teams focus on behavioral anomalies and social engineering tactics. They ask: Does this request match typical patterns for this sender? Is the timing suspicious? Does the requested data align with the stated purpose? These questions require context about normal business operations, regulatory cycles, and common scam pretexts.
The Revolut incident illustrates this gap. The scammer accessed identity documents, verification selfies, account statements, and transaction histories. That's not data a government agency would request in bulk via email. A fraud-focused review would flag the request type regardless of domain authentication.
Fraud teams also assess customer impact when breaches occur. They understand which data combinations enable account takeover, how exposed identity documents feed synthetic identity fraud, and what notification obligations trigger under your jurisdiction's data protection rules. Treating email compromise as a fraud event naturally includes customer communication, credit monitoring offers, and enhanced transaction monitoring for affected accounts.
Consider the underutilized fraud detection capabilities in most organizations. Research shows 69% of firms use secure bank connections for account and routing numbers, but only 49% use them for real-time fraud signals. That's a 20-point gap between having the capability and using it. Fraud teams can close that gap because they understand the risk indicators that matter: sudden changes in transaction velocity, geographic inconsistencies, or beneficiary patterns that don't match historical behavior.
Where Practitioners Actually Land
In practice, most organizations split the difference without explicitly planning to. IT security owns the technical controls and perimeter defenses. Fraud teams handle incident response when a scam succeeds. The handoff occurs at the moment of compromise.
This division creates blind spots. IT security may not escalate authentication anomalies that don't trigger automated blocks. A government domain suddenly requesting customer data looks technically legitimate but operationally suspicious. Without a defined escalation path, that signal gets lost.
Similarly, fraud teams may not see email authentication failures until after a breach. They can't analyze near-miss patterns or identify which sender domains need extra scrutiny. The forensic data exists in DMARC reports and email gateway logs, but it sits in systems the fraud team doesn't regularly access.
The most effective organizations create a shared responsibility model with clear trigger points. IT security maintains technical controls and monitors authentication failures across all domains. When authentication passes but request patterns are unusual, especially for sensitive data access, the case escalates to fraud operations for secondary verification. This might mean calling the sender through a known phone number, checking the request against recent regulatory guidance, or comparing it to historical patterns for that agency.
Our Take
Email authentication belongs in both domains, but fraud teams should own the final verification decision for any request involving customer data access.
Here's why: Technical controls will always have gaps. Legitimate domains get compromised. Authentication protocols pass while the request itself is fraudulent. DMARC alignment doesn't validate intent.
Your fraud team already makes risk-based decisions about unusual patterns. They verify wire transfer requests from authenticated executive email accounts. They challenge login attempts that pass MFA but originate from new devices. Extending that verification mindset to external data requests is a natural fit.
The practical implementation requires three elements. First, establish clear escalation criteria: Any email requesting bulk customer data, identity documents, or transaction histories triggers secondary verification regardless of sender authentication. Second, create verification protocols that don't rely on email: Use known phone numbers, secure portals, or in-person confirmation for sensitive requests. Third, close the feedback loop between IT security and fraud operations so authentication anomalies inform fraud detection rules.
The tradeoff is response time. Adding a fraud verification step delays legitimate requests. But when the request involves data like that exposed in the Revolut incident, that delay is acceptable. The cost of verification is measured in hours. The cost of a breach is measured in regulatory penalties, customer notification expenses, and long-term reputation damage.
You can't eliminate social engineering through technical controls alone. But you can ensure that every request for sensitive data faces a human review that asks the fraud-focused questions: Why now? Why this data? Why this method? Those questions catch what authentication protocols miss.
