The biggest fraud problem I’m seeing right now is how quickly AI is making attacks easier to build, test, and adapt.
AI tools can help surface vulnerabilities, understand how fraud controls work, and develop tampering techniques faster than before.
We’re seeing this across our customers, especially around app integrity, spoofing, and tampering.
I’ve been talking about this for a while.
A few months ago, I shared that we had starting seeing a surge in app integrity-related issues not too long after AI coding tools went mainstream.
At the time, I said we couldn’t attribute it of it directly to AI for sure. But the timing was hard to ignore.
Since then, I’ve become even more convinced that this is one of the defining fraud challenges in the industry right now.
We’re having to update our own defenses more frequently.
And we’re starting to see public examples that show exactly how AI can be used to reverse engineer fraud technology.
A recent Reddit post is one of the clearest examples I’ve seen of this happening in practice:
The author used AI to reverse engineer the SDK behind a leading fraud prevention solution and understand the signals it was collecting inside the browser and how they’re used to identify users and assess risk.
This is exactly the kind of activity I’ve been talking about.
AI is getting very good at analyzing software, reverse engineering how it works, and identifying vulnerabilities much faster than would have been possible manually.
That’s why I think code obfuscation, and security by obscurity more broadly, are going to become much less effective as defensive strategies.
Obfuscation can still make reverse engineering harder. But if AI keeps getting better at peeling that complexity back, you have to assume attackers will eventually understand how the control works.
And once they do, they have a much better starting point for identifying where it can be tampered with and developing ways around it.
And the barrier to doing this is getting lower.
You no longer need the same amount of time or specialized expertise to reverse engineer complex software entirely by hand.
The part that really stands out came at the end of this post:
AI coding tools are also making internal engineering teams more productive.
Earlier this year, we started hearing from companies that wanted to build more fraud prevention capabilities in-house because AI had made software faster and cheaper to develop.
I understand the logic.
If your engineers can build something materially faster, building internally starts to look a lot more attractive.
But fraudsters have the same tools.
And the fight is asymmetric.
A financial institution can’t push a new fraud control into production the moment an engineer finishes building it. It has to be tested and reviewed. You have to understand how it will affect legitimate customers, and there are security and regulatory requirements to work through.
Fraudsters don’t have those same constraints.
They can experiment until something works. If an approach fails, they move on to the next one.
That’s why I think AI is creating a bigger advantage for the attacker than it is for the defender.
Historically, a lot of the build-vs.-buy decision has focused on the initial build.
Can our team build this capability? How quickly can we ship it? What will it cost to get version one into production?
AI makes those questions easier to answer in favor of building.
But the bigger cost is what happens after launch.
If fraudsters are finding new ways to tamper with controls more quickly, those controls also need to be researched, hardened, tested, and updated more often.
That maintenance burden can become much more expensive over time.
And I think that’s where some internally built fraud prevention capabilities can start to become economically unfeasible, even if AI made them cheaper to build in the first place.
Investing in fraud technology does not make the arms race disappear.
It changes who is responsible for staying in it.
For us, researching new tampering and spoofing techniques and updating the technology in response is part of the job.
I don’t think our customers should have to become experts in every new attack technique just to keep a fraud control useful.
That’s part of the ongoing engineering burden that we, as vendors, should absorb. As attack methods change, our technology has to change with them.
That’s how I think about build vs. buy in this environment.
The question is becoming less about whether your team can build something, and more about whether you want to own that adversarial engineering problem indefinitely.
AI is making fraud technology easier to build.
But it’s also making fraud controls easier to study, test, and attack.
That changes what matters in a build-vs.-buy decision.
Fraud prevention is adversarial. Whatever you build will eventually be studied and adapted against, and AI is making that cycle much faster.
So the real question is whether you want to own the ongoing cost of keeping up with it.
Some capabilities are worth owning internally.
For the rest, I would want the company I buy from to treat the next attack as its problem too.
If your team is seeing more app integrity issues, reply and let me know what’s changed. I’m interested in comparing notes on how quickly these attacks are evolving.