Cybersecurity for Fintech: The Risks Lie at the Extremes
- Samuel Sabogal
- 5 days ago
- 5 min read
On a previous occasion, I told the story of João Roque, the developer who walked out of a bar in São Paulo to find an offer waiting for him on the sidewalk, and of the 541 million reais his password ended up costing. Back then, to bleed half a dozen financial institutions dry, they had to buy a human being. This time, there’s no one to buy.
The three stories that follow have something in common with the first: in none of them was the Riel’s cryptography compromised. With instant payments, it almost never is. The blood flows from the edges.
Primer acto: el teléfono del cliente
Since late 2022, an Android malware called PixPirate has been circulating in Brazil. It arrives the way things usually do in Latin America: via a WhatsApp link or an SMS, disguised as a legitimate app. Once installed, it uses persistent pop-up windows to request a permission that sounds innocent: accessibility services—the same ones used by apps that help people with visual impairments operate their phones. With that permission, the malware can read the screen and tap buttons. In other words, it can use the phone just as its owner would.
And then it waits. When the victim opens their real banking app, PixPirate captures their login credentials and two-factor authentication codes. Later, at the chosen moment, it overlays a screen on top of the current one.

And in the background, unseen, it opens the banking app, navigates to Pix by tapping the buttons itself, and initiates the transfer. Recent versions don’t even have an icon: it is the first documented financial malware that runs without leaving a visible trace on the home screen. The campaign, which accounts for the majority of its infections in Brazil, has also been detected in Mexico, Italy, and India.
The important thing is to understand what the bank sees: a perfectly authenticated transaction. Correct credentials, correct device, correct app, correct two-factor authentication. The fraudster didn’t spoof the customer’s identity—they hijacked it. That’s the lesson: when the threat lives inside the phone, authenticating the person isn’t enough, because the authenticated session is precisely what the malware hijacks. What needs to be cryptographically secured is something else: ensuring that what the customer saw is what the server received.
It’s called a transaction signature (WYSIWYS, what you see is what you sign), and here’s how it works: the critical order data (amount, destination, reference) is signed with a key stored in the phone’s own secure hardware—the Secure Enclave on an iPhone or the Keystore backed by the TEE on Android—which is present even in the low-end models that dominate our market; and the confirmation goes through the operating system’s biometric authentication process, not through an app screen that malware could overlay.
If something altered the order behind the scenes, the signed data won’t match what was received, and the server will reject it. An attacker can no longer succeed by compromising the app—they’d have to compromise the chip. That’s a whole different ballgame.
Act Two: The Boardroom
In January 2024, an employee in the finance department at Arup—the British engineering firm that designed the Sydney Opera House—received an email in Hong Kong from the chief financial officer of the parent company in London requesting a confidential transaction. The employee grew suspicious, just as he had been taught: it smelled like a phishing scam. He asked to verify the request. The verification took the form of a video call. On the call were the CFO and several colleagues he knew: their faces, their voices, their mannerisms.
Convinced, he executed fifteen transfers to five accounts: 200 million Hong Kong dollars, about 25.6 million U.S. dollars. A week later, when he discussed it with headquarters, he discovered that none of the people on that call were real. They were all deepfakes, generated using publicly available material. The Hong Kong police revealed the case in February; it took the company until May to admit that it was the victim. The money has not been recovered.
It’s worth pausing to consider the most uncomfortable detail: the employee did exactly the right thing. He was suspicious of the email and verified it through another channel. The problem is that the other channel could also be faked. Throughout the history of business, seeing someone’s face and hearing their voice has been the gold standard of verification; today, a face and a voice can be replicated with a few seconds of public video and a monthly subscription.
Seeing is no longer verifying. The answer isn’t to train the human eye better—it’s to remove it from the equation. A high-value order shouldn’t be valid simply because the boss requested it on a screen. It must be valid because it is signed: the order data, using the approver’s private key, stored on a physical hardware key for treasury operators (dozens of people, not millions—this is where the token is justified), and with dual control: a second approver, with their own key, via their own channel. A deepfake can mimic the CFO’s face with astonishing precision. It cannot mimic their private key, because there is nowhere to copy it from.
Act III: The Calendar
The third story involves no attacker. On December 6, 2018, a digital certificate expired within the software that Ericsson was selling to mobile operators around the world. The devices did what security best practices dictate when a certificate expires: they shut down. The result: some 32 million users of O2 and its affiliated brands were left without mobile data in the United Kingdom for most of the day, SoftBank’s network went down nationwide in Japan for hours, and disruptions occurred in eleven countries.
Ericsson took full responsibility; the British press estimated that the compensation bill could reach 100 million pounds. All because of a date embedded in a file—the only type of incident in all of technology whose exact date is known years in advance.
On the web, an expired certificate triggers a warning in the browser. In an instant-payment network, where each participant’s connection depends on X.509 certificates with expiration dates, your organization is disconnected from the country’s payment system at 2 a.m. on a Saturday, with all your customers still online. This week’s question is just one line long: Who in your organization is currently responsible for that date? And the technical answer is well known: a central certificate inventory with statuses and designated personnel, alerts scheduled for 90, 60, 30, and 7 days in advance, and rotation with overlap—the new key goes into service before the old one is removed, so that renewal doesn’t mean going offline. It’s not sophisticated cryptography. It’s discipline with a schedule. That’s why it’s unforgivable not to have it.
The “cybersecurity” toll
Three stories, zero broken cryptography, and cybersecurity: malware that executes commands the customer doesn’t see, a face that doesn’t exist, a date no one noticed. The pattern is always the same: modern infrastructure is excellent; what’s usually missing is end-to-end cryptography—the kind that ties what the customer sees to what they sign, that ensures an order is valid because of the key that signed it and not because of the face that requested it, and that treats an expiration date for what it is: the only scheduled event.
At Cyte, we build exactly that layer: on-device transaction signing (WYSIWYS) on the phone’s secure hardware, with verification that the app and device have not been tampered with; high-value orders that are valid based on the signatures of their approvers, with M-of-N dual control and evidence of each approval, rather than a screenshot during a video call; and lifecycle management of certificates throughout the entire operation: inventory, expiration alerts, and rotation without downtime. In the first installment, bleeding a fintech dry cost fifteen thousand reais and a conversation outside a bar. In this one, it cost even less: a WhatsApp link, a few seconds of public video, a date that no one checked. And yes: there will be a third installment. The ways to bleed a fintech dry, unfortunately, are enough for a series. The ways to prevent it, fortunately, fit onto a single platform.





Comments