Impersonation-Proof Request Handling for Financial Institutions

When a threat actor impersonates a government agency and your team fulfills the request, you've just handed over customer passports, transaction histories, and verification selfies. Revolut learned this the hard way. The attacker used valid domain authentication credentials, and staff reasonably believed they were responding to a legitimate government inquiry.

Domain authentication alone doesn't verify intent. It verifies that an email came from a specific server, not that the person sending it has lawful authority to request customer data. For financial institutions serving millions of customers across dozens of jurisdictions, this gap becomes a critical exposure.

The Problem: Why Authentication Isn't Authorization

Revolut operates in over 160 countries and serves more than 80 million customers worldwide. When staff received a request from what appeared to be a government agency domain, they fulfilled it. The exposed data included full names, dates of birth, passport copies, facial verification images, account statements with IBAN numbers, withdrawal records, and complete transaction histories including Bitcoin transactions.

The company's previous breach in September 2022 affected 50,150 customers. This pattern suggests that verification protocols haven't kept pace with attacker sophistication.

Domain authentication (SPF, DKIM, DMARC) confirms that an email originated from an authorized mail server. It doesn't confirm:

• The sender's identity within that organization
• Their authority to request specific data
• The legal basis for the request
• Whether the request matches known formats for that jurisdiction

You need a verification protocol that treats domain authentication as a necessary first step, not a sufficient one.

What You Need Before Starting

Before building your verification protocol, assemble:

Reference materials:

• Current mutual legal assistance treaty (MLAT) request templates for each jurisdiction where you operate
• Contact directories for data protection liaison officers at relevant supervisory authorities
• Escalation matrices showing which internal roles authorize disclosure for different data categories
• Your Article 6(1)(c) legal obligation processing register (if operating under GDPR)

Technical infrastructure:

• Secure request logging system that captures full email headers, timestamps, and fulfillment decisions
• Encrypted storage for verification artifacts (callback recordings, written confirmations)
• Access controls limiting request fulfillment to designated personnel
• Notification workflows to alert legal and privacy teams when requests arrive

Team alignment:

• Documented authority: which roles can approve disclosure of identity documents vs. transaction histories vs. verification images
• Maximum response timeframes that balance compliance obligations with verification requirements
• Clear escalation triggers (requests for bulk data, unusual jurisdictions, expedited timelines)

Step-by-Step Implementation

Step 1: Create a multi-factor verification checklist

Build a mandatory checklist that staff must complete before fulfilling any government data request:

1. Domain authentication passes (SPF, DKIM, DMARC all align)
2. Sender email matches known contact for that agency (maintain and update this list quarterly)
3. Request references a specific legal authority (statute, regulation, court order number)
4. Request format matches templates you've received previously from that jurisdiction
5. Data requested is proportionate to stated purpose
6. Callback verification completed using independently sourced contact information

Never use contact information provided in the request email itself. Maintain your own verified directory.

Step 2: Implement callback verification

For every request, regardless of how legitimate it appears:

1. Locate the agency's publicly listed contact number (government website, not the email signature)
2. Call and ask to be transferred to the named sender or their supervisor
3. Verify: the person's role, the case or reference number, and the specific data elements requested
4. Document the callback: date, time, person spoken to, verification outcome
5. Store this documentation in your breach register workflow (you'll need it if the request turns out to be fraudulent)

If you can't reach the sender via independent contact methods within your response timeframe, escalate to legal counsel. Don't fulfill the request based solely on email authentication.

Step 3: Segment data disclosure by sensitivity

Not all customer data carries equal risk. Create tiered approval requirements:

Tier 1 (Basic contact information):

• Name, email, phone number, postal address
• Approval: Data protection team lead
• Verification: Domain authentication + callback

Tier 2 (Identity documents and financial records):

• Passport copies, driver's licenses, facial verification images
• Account statements, IBAN numbers, transaction histories
• Approval: Chief Privacy Officer or designated deputy
• Verification: Domain authentication + callback + written confirmation from agency (email from verified address explicitly confirming the request)

Tier 3 (Bulk requests or sensitive populations):

• Requests affecting more than 50 customers
• Requests targeting high net worth individuals or politically exposed persons
• Approval: Legal counsel + Chief Privacy Officer
• Verification: All Tier 2 steps + consultation with your supervisory authority liaison

Step 4: Build request templates for common scenarios

Create standardized response templates:

"We received your request dated [DATE] referencing [LEGAL AUTHORITY]. Before we can fulfill this request, we need written confirmation from [AGENCY NAME] at [VERIFIED EMAIL] that explicitly lists: (1) the legal basis, (2) the specific customer identifiers, (3) the data categories requested, and (4) the name and title of the authorized requestor. Please respond within [TIMEFRAME] to [SECURE EMAIL]."

This template forces the attacker to either abandon the attempt or expose themselves by failing to respond from the verified channel.

Step 5: Log everything in your breach register workflow

Treat every government data request as a potential security incident until verified. Log:

• Request receipt timestamp
• Domain authentication results
• Callback verification details
• Approval chain
• Data disclosed (specific fields, row counts, date ranges)
• Fulfillment timestamp

If a request later proves fraudulent, you'll need this audit trail for your notification to supervisory authority under the 72-Hour Notification requirement and for your breach register.

Validation: How to Verify It Works

Test your protocol quarterly:

Have your security team send a simulated government request to your data operations team. The request should pass domain authentication but fail callback verification. Track:

• How many staff members escalate rather than fulfill immediately
• Average time to complete verification checklist
• Whether callback attempts use independent contact sources

Your target: 100% escalation rate, zero fulfillments without completed verification.

Audit fulfilled requests monthly:

Pull all government data requests fulfilled in the past 30 days. For each:

• Verify callback documentation exists
• Confirm approval came from authorized roles
• Check that disclosed data matches the request scope
• Review response time against your legal obligation deadlines

Flag any request where verification steps were skipped or documentation is incomplete.

Monitor for patterns:

Watch for:

• Multiple requests from the same purported agency in short timeframes
• Requests for data categories that agency doesn't typically need
• Requests that arrive outside normal business hours for that jurisdiction
• Urgent language or threats of penalties for delayed response

These patterns often indicate social engineering attempts.

Maintenance and Ongoing Tasks

Update contact directories quarterly:

Government agency personnel change. Every 90 days:

• Verify phone numbers and email addresses for your primary contacts at each agency
• Document new liaison officers
• Remove outdated contacts
• Test that phone numbers still reach the correct departments

Review verification protocol after every breach disclosure:

When any financial institution publicly discloses a breach involving government impersonation:

• Analyze their disclosure for attack details
• Update your verification checklist to address that specific technique
• Brief your data operations team on the new threat pattern
• Test whether your current protocol would have caught it

Train staff twice yearly:

Social engineering succeeds because attackers exploit human trust and time pressure. Every six months:

• Walk through recent impersonation attempts (yours or industry examples)
• Practice callback verification with role-playing scenarios
• Emphasize that verification delays are acceptable, unauthorized disclosure isn't
• Reinforce that domain authentication is step one, not the only step

Document false positives:

When your verification protocol flags a legitimate request, document why. Over time, you'll identify:

• Agencies that consistently fail to match your templates
• Jurisdictions where callback verification is difficult due to time zones or language barriers
• Data categories that generate frequent legitimate requests

Use these insights to refine your protocol without weakening it.

Domain authentication tells you an email came from a server. Verification tells you whether you should respond to it. The difference between those two facts is where customer data walks out the door.