Over the past two months, I experienced three security incidents at the fintech where I work as a tech lead.
I won't go into which company it is, the exact amounts involved, or which partners failed. But I'll share what happened with the honesty of someone who was in the middle of the fire, and what it made me think about what's coming.
There's a silent pattern in mid-sized fintechs: engineering grows fast, the product is good, developers are skilled, and security keeps getting pushed to later. Not out of negligence, but because the cost of ignoring it feels abstract until the day it isn't.
How a Real Attack Actually Happens
The popular image of a hacker involves someone furiously typing in a black terminal, trying passwords until one works. Reality is far less cinematic, and far more unsettling.
Of the three incidents I experienced, none involved brute force.
In one of them, a partner of ours had their credential database leaked. The attacker arrived with a copy of the house keys, no need to break in. They managed to move a significant amount of money across accounts before we could stop them.
In another, it was pure social engineering. The attacker somehow obtained a client's credentials, logged in, realized they didn't have the transactional PIN, and opened a support ticket pretending to be the client, even sending a photo holding an ID document. Our support team processed the request. The phone number used was different from the one on file. Nobody noticed.
The weakest link in any system is always human. The best encryption in the world doesn't matter if someone answers the wrong phone call.
Why Our Current Defenses Aren't Enough
After each incident, we asked the right questions: what failed? what could have prevented this?
We reached some uncomfortable conclusions.
The government reversal mechanism doesn't work for this type of attack. Brazil has a special mechanism designed to trace and reverse fraudulent transactions. In theory, it's the financial system's shield against fraud. In practice, it takes days, weeks, sometimes months to act. A competent attacker pulverizes the stolen balance across dozens of mule accounts, which forward to others, which forward to others. Within hours, the trail is nearly untraceable. We filed the request more out of procedure than genuine hope of recovering the money.
Partners' fraud detection is too generic. Our banking partner blocked roughly half the amount transacted in one of the incidents. That helped, and I'm grateful, but the half that wasn't blocked was enough to cause real damage. The problem isn't partner incompetence: it's that a fraud system built to serve thousands of different clients tends to be conservative and generic. It doesn't know the specific transactional pattern of your business.
Condominiums, for example, have extremely predictable financial behavior. Payments happen in specific windows of the month, to corporate accounts, in amounts that follow a historical pattern. A transfer to an individual, outside business hours, above the historical amount for that account is trivially suspicious to someone who knows the domain. To a generic fraud system, it's just another transaction.
What Changes With AI
Recently, major AI labs announced they're working on models capable of autonomously finding vulnerabilities in software systems. There's obvious market interest in those statements, FOMO sells, but there's also genuine truth to them.
A human attacker has limits. They sleep. They make mistakes. They have a finite set of technical knowledge. They need time to analyze a system, identify attack surfaces, test hypotheses.
An AI-powered attacker has none of those limitations.
The speed of exploitation is going to shift by an order of magnitude. What today takes days of manual analysis could take minutes of automated scanning. And the systems that are exposed, APIs without IP validation, forgotten old endpoints still running on the internet, credentials that have never been rotated, are going to be found much faster than any security team can react.
I'm not speculating about a distant future. I'm describing the present with one new variable added.
What You Can Do Right Now
I'm not writing this to cause panic. I'm writing it because most effective defenses are relatively simple to implement, and most companies still haven't done them.
Eliminate long-lived exposed credentials. Production credentials shouldn't exist in .env files on developer machines or be injected as environment variables in Kubernetes pods. They should be fetched at runtime from a secrets manager (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault). The overhead is small. The gain is enormous.
Add mutual TLS (mTLS) to your B2B APIs. If you have an API that partners integrate with, mTLS is the proper long-term solution: both sides present certificates, so the connection is authenticated at the transport layer regardless of what's in the payload. IP allowlisting is a valid quick win (it's what we did after our incident, and it stopped the immediate bleeding), but it's not a substitute. IPs rotate, VPNs exist, and cloud-native architectures make stable IP ranges increasingly rare. mTLS doesn't have those weaknesses.
Build your own fraud detection, even if simple. You know the transactional behavior of your domain better than any partner does. Basic rules based on historical pattern, time of day, beneficiary type, and amount already capture most obvious anomalies.
Implement credential rotation. Credentials that never expire are credentials that may have been leaked years ago without your knowledge. A periodic rotation process, even semi-manual, drastically reduces the impact of a past breach.
Audit access for former employees. It sounds obvious. Most companies don't do it systematically. Make it a mandatory step in your offboarding process.
Define security protocols for your support team. Social engineering works because support teams prioritize resolving the customer's problem over verifying who the customer actually is. Write down what your team is and isn't allowed to change without additional verification, and what that verification looks like. A checklist isn't glamorous, but it closes the gap that cost us tens of thousands of dollars.
Monitor actively, not passively. Logs exist to be read. If you're discovering incidents because a client complained, you're already late. Invest in alerts, dashboards, and if possible, automation that catches anomalies before they become incidents.
A Question I Can't Stop Asking
I've thought about what would have happened if the attacker we faced had an AI on their side. Not for phishing at scale, but to systematically scan our APIs for unauthenticated endpoints. To test payload variations against our routes. To identify patterns in error responses that reveal internal structure. To do in minutes what took weeks of manual analysis.
The honest answer is: I don't know if we would have held.
And if that's true for us, with all the attention we've dedicated to security over these two months, it's true for the vast majority of fintechs operating today.
The ground is shifting. The question isn't whether you'll be attacked. It's whether you'll be ready when it happens.
If you've been through something similar or have a different perspective, I'd love to hear it in the comments.
Top comments (0)