Revolut Handed Passports and Selfies to One Fake Government Email — the 4 Backend Controls I Now Screen Every Singapore Fintech Hire For

I have spent a decade interviewing backend engineers for payments companies, and until this week my system design question was always some version of “design the ledger.” On Monday I replaced it. The Revolut disclosure that landed over the weekend and was reported in detail on 14 September is the clearest case I have seen of a data breach with no exploit, no malware and no compromised server — just a request that looked legitimate arriving at a workflow with no engineering controls in front of it. For any fintech operating under MAS in Singapore, that is not a security-team story. It is a hiring story, and the four controls below are what I now screen for.

What Happened, in the Words of the People Who Reported It

BleepingComputer’s Sergiu Gatlan broke the detail on Monday 14 September 2026 under the headline “Revolut discloses data breach exposing financial info, passports”. Help Net Security’s Mirko Zorz published a same-day summary, “What we know about the Revolut data breach so far”, noting that Revolut had confirmed the incident on Saturday 12 September.

The mechanism, in Revolut’s own account as quoted by BleepingComputer: a threat actor impersonating a government agency sent emails requesting personally identifiable information, and because the communication “carried valid domain authentication credentials, it was fulfilled under the reasonable belief that it was an authentic government agency request.” Help Net Security adds that the sender used an email address on the agency’s own domain.

What went out, per both reports: identity details (full name, date of birth, occupation), contact details (postal address, email, phone), copies of passports and driving licences, facial verification selfies taken for KYC, account statements including IBANs, withdrawal records, and full transaction histories including Bitcoin transactions. Revolut told BleepingComputer that a “limited number of customers” were affected and declined to give a figure; crypto investigator ZachXBT said the breach “seems to have been targeted at high net worth users.”

Revolut’s statement: “Upon detection, we immediately blocked the address and alerted the relevant government agency as well as enforcement agencies, data protection, and financial regulators.” The company characterised the event as “an external impersonation scam” and said “Revolut systems and customer funds are unaffected.” By Monday, Help Net Security reported, threat actors had allegedly begun leaking VIP client data and demanding payment. BleepingComputer notes Revolut serves more than 80 million customers across 160-plus countries and that this is the company’s second major breach in four years, after the September 2022 incident affecting 50,150 customers.

Why This Is a Singapore Engineering Story, Not a London Compliance One

Revolut operates in Singapore under MAS licensing, but the point is broader: every licensed payments, digital banking, crypto or wealth platform here runs a workflow that looks exactly like the one that failed. Law enforcement requests, regulator requests, court orders, data-subject access requests, partner-bank due diligence — they all arrive as documents, from domains that look right, asking for the most sensitive data you hold. The Singapore Police Force and MAS do send such requests. So, apparently, does anyone who can get a mailbox on the right domain.

Two clocks then start. MAS technology risk management rules require licensed institutions to notify MAS of relevant incidents within one hour of discovery. The PDPA’s mandatory breach notification regime gives three calendar days from the point a breach is assessed as notifiable to inform the PDPC, and affected individuals must be notified as well where the breach is likely to result in significant harm. Meeting either deadline is not a legal exercise. It is a query against systems that either can or cannot tell you which records, for which customers, were exported by which account, at what time, in response to what. If your backend cannot answer that in under an hour, your compliance team is guessing, and the regulator will notice.

Which is why I changed my interview question. The engineers who can build the four controls below exist, but they are rarely asked about them, so they are rarely identified. If you are assembling a team, our earlier guides on building a fintech engineering team in Singapore and hiring DevSecOps engineers for Singapore fintech cover the surrounding roles; this piece is about what to ask the backend engineer.

The 4 Backend Controls I Now Screen For

Control 1: Out-of-band verification, so an email can never trigger a disclosure

The interview question is: “Design the intake for law-enforcement and regulator data requests.” The answer I want has no email fulfilment path at all. Requests land in a portal where agencies hold pre-registered accounts, or an inbound email creates a ticket that is only actioned after a callback to a number on file for that agency — not a number in the email. The engineer should mention that the verification step is recorded, that the ticket cannot move to fulfilment without it, and that an emergency path exists but requires a second, senior approval rather than skipping verification. Candidates who reach for “check the DMARC result” as the control have just described the Revolut incident.

Control 2: Tiered data access with a two-person rule on identity documents

Question: “Which tables can a support engineer read right now, and how do you know?” Passport scans and KYC selfies should not live beside transaction data with the same access policy. They belong in a separately gated store, with just-in-time access granted for a named case, approved by a second person, and expiring automatically. The engineer should be able to describe the difference between role-based access that is set once and case-based access that is granted per request, and should know that the second is the only one that survives an insider or a convincing impersonator. A good answer also volunteers that the bulk of day-to-day support work never needs the raw document, only a yes/no verification status.

Control 3: Export controls that make bulk PII movement a ticketed, signed, rate-limited event

Question: “Someone with legitimate access needs to send a regulator the records for twelve customers. Walk me through what your system does.” I am listening for: the export is created by the system, not assembled by hand; it is tied to the verified ticket from Control 1; it produces a signed manifest of exactly which fields for which customers; documents are watermarked with the ticket reference; and export volume per account per day is rate-limited with alerts on anomalies. The point of the manifest is that when the notification clock starts, the answer to “what left” already exists.

Control 4: An immutable, queryable audit log that reconstructs a disclosure in under an hour

Question: “It is 09:00 on a Saturday and legal has just learned that a request fulfilled on Tuesday was fraudulent. What can you tell them by 10:00?” The answer has to be specific: which customers, which fields, which account exported them, which approvals were recorded, which IP and session. The engineer should talk about append-only storage for the audit trail, separation of the log from the systems it observes, and a query interface that legal and compliance can use without an engineer on call. If the honest answer is “we’d grep the application logs,” you do not have Control 4, and you are going to miss the MAS window.

What the Singapore Market Looks Like When You Screen This Way

Here is the uncomfortable finding from the first week of asking these questions. Of the backend candidates I put them to — all with fintech on the CV, most with a payments ledger or a reconciliation system they were rightly proud of — the majority had never been asked to design a disclosure workflow, and it showed. They could design Control 4 in the abstract because it resembles observability work they had done. Controls 1 and 3 were new to most of them. Control 2 split the room between those who had worked at a licensed institution and those who had not.

That scarcity has a price. In our recent Singapore placements, senior backend engineers with production fintech experience have been landing roughly in the S$10,000 to S$16,000 per month range, and the candidates who have actually built data-governance or trust-and-safety tooling at a licensed institution sit at the top of that band with room to negotiate. Expect four to eight weeks to fill a role if you hold out for all four controls in the portfolio, and consider whether one senior engineer who has built them can lead three who have not. Our fintech developer and security engineer benches are where we start those searches; the backend development services in Singapore page covers the outsourced route.

What to Do This Week If You Run Engineering at a Singapore Fintech

Three things, none of which need a budget. First, find your inbox. Somewhere in your organisation there is an email address that receives requests from agencies, and someone who acts on them. Ask that person what they check before they act. If the answer involves the sender’s domain and nothing else, you have found your Revolut. Second, run the Saturday-morning drill from Control 4 against a real fulfilled request from last month and time it. Third, change your interview loop. Replace one system-design question with one of the four above, and see how your current pipeline performs. Our colleagues in Dubai reached a similar conclusion after last week’s identity-document breach there — see their analysis of the IDScan breach and Dubai security engineer hiring, and the wider HireDeveloper.ae employer library.

Follow the story as it develops on Google News; the primary sources for this piece are the BleepingComputer and Help Net Security reports linked above and the Tech Startups daily digest for 14 September 2026.

FAQ — The Revolut Breach and Singapore Fintech Hiring