Laura Santeusanio
Regional Director Southern Europe
An international executive with 20+ years of experience driving business growth, market expansion, and transformation across Europe. Proven General Manager skilled in scaling operations, building high-performing teams, and executing strategy to deliver measurable results.
Key takeaways:
A recent, widely reported fintech breach involved no technical intrusion at all: attackers used a compromised government email account to request customer data, and the company handed it over believing the request was legitimate.
The pattern reportedly continued for months before anyone caught it, not because one email slipped past a filter, but because the verification process itself had no way to catch a well-authenticated fake.
Technical email authentication (SPF, DKIM, DMARC) confirms a message came from a genuine domain. It says nothing about whether the specific person sending it was authorized to send it, or whether the request itself is lawful.
Several of the more dramatic details still circulating, the exact data volume, the ransom figure, how long the underlying government account was compromised, come from the attacker's own claims and remain unconfirmed by any official body.
The fix isn't a better spam filter. It's a documented, mandatory verification step for exactly this category of request, one that exists on paper and is actually followed under pressure.
What actually happened
The reconstruction that's emerged from investigative reporting is straightforward, which is precisely what makes it unsettling. An attacker gained control of an email account belonging to a real government office. From that account, they sent the fintech requests for customer information, styled as law enforcement demands. The requests came from a genuine government domain, so they passed the technical checks that usually flag impersonation, and were routed through the company's normal process for handling government and law enforcement inquiries.
The company treated the requests as legitimate and disclosed the data. It later described the incident as an external impersonation scam rather than a breach of its own systems, and that framing holds up under scrutiny: there's no public evidence of a network intrusion, and the company has stated that customer funds and core systems were never compromised. What did happen is a personal data breach, and under GDPR's own definition, that's true regardless of whether a single server was touched. Unauthorized disclosure to the wrong party is the breach, full stop.
A verified sender is not the same as an authorized request
The uncomfortable insight sitting underneath this incident is one most organizations haven't fully priced in: authentication and authorization are different problems, and most disclosure processes only check the first one.
SPF, DKIM, and DMARC exist to answer one question: did this message actually come from the domain it claims to come from? They're good at that job. They say nothing about whether the specific person who sent it was authorized to make this particular request, whether the legal basis they're citing actually applies, or whether the volume and nature of what they're asking for matches a legitimate inquiry. A compromised account inside a real government domain sails through all three checks. The domain is genuine. The person behind it, on this occasion, is not.
Government and law enforcement requests carry a specific kind of institutional trust that makes this gap worse, not better. A request that looks official tends to get processed faster and questioned less, which is exactly the assumption an attacker is counting on.
The part that should worry compliance teams more than the breach itself
A single fraudulent email getting through is a bad day. What reportedly happened here is different: the same pattern of requests continued, undetected, for an extended period. That's not a story about one email slipping past a filter. It's a story about a verification process that had no mechanism to catch a well-authenticated fake even after it had already worked more than once.
Most organizations can point to a policy that says government requests get handled carefully. Far fewer can show that the policy includes a specific, mandatory step, like confirming the request through an independently sourced contact channel, not one provided in the request itself, before anything gets disclosed. Without that step written down and actually enforced, "handled carefully" quietly becomes "processed like every other request," and nobody notices until it's already happened repeatedly.
What's confirmed, and what's still just a claim
Part of writing about a live incident responsibly is being honest about which details are solid and which aren't yet. As of this writing:
Reasonably well established: an attacker used a compromised government email account to submit fraudulent requests for customer data. The company disclosed data in response, believing the requests were legitimate. The company's own systems and customer funds were not breached. Authorities are investigating.
Reported by media, not officially confirmed: the specific number of affected customers, and which exact government office's account was compromised.
Claimed by the attacker only, unverified by any official body: the total volume of data allegedly obtained, the length of time the underlying government account was allegedly compromised, and the ransom demand. Governance practice is clear on this point: a threat actor's own claims about what they have are marketing for the extortion attempt, not evidence, until something independent confirms them.
What this means if your organization ever gets a government request
Almost every regulated organization, financial services, healthcare, telecom, has some process for responding to law enforcement and government data requests, because the law generally requires one. The question this incident raises isn't whether that process exists. It's whether the process has a real check built in for exactly this scenario: a request that looks completely legitimate and might not be.
A reasonable control here is specific, not general. Something close to: before disclosing personal data in response to a government, judicial, or law enforcement request, independently verify the requester's identity and authority, the legal basis for the request, and its scope, using contact details sourced independently rather than ones provided in the request itself. High-volume or unusual requests get a mandatory second look before anything goes out.
Written down, that sounds obvious. The reason it fails in practice is that it rarely lives anywhere an intake team actually sees it in the moment, and it's rarely tested against a request that looks exactly right.
See how a verification step like this fits into your compliance program
Bring your own process for handling government or law enforcement requests, however informal it is today. We'd rather show you how to structure the check than describe it in the abstract.
How Formalize supports this
This is a control problem before it's a technology problem, and Formalize's role is to make sure the control actually exists somewhere other than a policy document nobody opens under pressure. In practice, that means:
A documented control for government and law enforcement disclosures, sitting alongside your other controls rather than in a separate policy binder, with a named owner.
Verification steps built into the workflow, so a request gets checked against defined criteria before disclosure, not after.
A record of who approved a disclosure and why, so if a request is questioned later, the reasoning is already there rather than reconstructed from memory.
The same control reused across frameworks, since this kind of disclosure risk touches GDPR, and often overlaps with obligations under frameworks like DORA or ISO 27001 too.
None of that replaces judgment. It makes sure the judgment gets applied consistently, every time, including the one time it matters most.