#10 - Build vs Buy: When DIYing Fraud Tech Makes Sense

Jan 18

“I want us to have a world-class fraud prevention organization”.

Have you heard this statement before?

Better yet, have you ever said so yourself?

It would usually appear when I’m speaking with a prospect about why they’ve reached out to me in the first place. The more senior they are, the more likely it is to appear.

And if there are other team members on the call? Even more likely.

The thing is, it’s very easy to mistake what goes into being world-class. And even more so, remaining there.

There’s definitely a time and a place for a Fintech to invest heavily into their own fraud technology (and we’ll talk about it in the end).

But let’s first analyze what’s wrong with wanting to be number one.

The most common pitfall is developing half-hearted, in-house fraud prevention tech.

How so? Here's how it usually plays outs:

An average fraud prevention software project that costs X, would likely have a maintenance cost of 30-40% that annually.

This means that you’ll need to re-invest the project’s costs every 2-3 years just to keep pace.

Not to mention developing extra features that were left outside the scope.

Given that the initial cost itself is usually in the 7-8 figure range for mature Fintechs, this is not a blip in your budget.

You can invest the same amount in a couple of vendors and spare some change to cushion your loss budget.

What ends up happening is that the initial project’s scope gets severely curtailed, turning it into a perpetual MVP.

Tragically, the performance proves to be sub-par to 3rd-party vendors which puts companies in an awkward situation:

They either need to continue using a crappy tool they invested in, or throw away the entire effort and go back to using a vendor.

But budget constraints are just one side of the problem.

Another issue I come across way too often is Fintechs insisting on developing fraud tech without having internal domain know-how.

Fraud tech is too often simply judged as just… tech.

The reason for which companies miss the abnormal maintenance cost, is the same one that drives them to assign it to their engineering teams, thinking they’ll deliver it just like any other project.

But in reality, fraud tech requires deep expertise to develop successfully.

For once, its features, data streams and real-time nature require an intricate design.

But more importantly, fraud tech always – always – feeds into a manual process that is managed by a human.

It’s not important if this process is case investigation, rule writing, model training, or customer onboarding. At the end of the flow, there’s a human waiting to digest the output, make a decision, and enact next steps.

And yet, I’ve encountered plenty of companies who were happy to commence development before they even had these teams up and running.

If your internal customers are not there, if the processes you want to support are not functioning yet, and if you’re missing an internal expert to tie this into the software specifications - how likely you are to succeed?

Is developing fraud tech always a bad investment? Absolutely not.

Here are the signals that let you know you are ready to take that leap:

Your internal fraud team is >20 FTEs and is already hacking some internal tooling to compensate for your vendor’s gaps.
You have a senior domain expert with a technical/product/data background that can help shape up the product specifications.
Most importantly - fighting fraud is no longer about your losses and all about your competitive advantage.

The first two are capability prerequisites, the last one is to make sure your ROI is big enough.

And to make it big enough, it needs to be about revenue growth.

You've checked all the boxes, where should you invest?

Let’s start with where not to invest:

Niche technologies: device fingerprinting, DocV, entity resolution, behavioral/biometric analytics, etc. These are essentially features within the fraud system, and require deep and narrow expertise. Will always have a negative ROI.
UI: rule engines, investigation tools, etc. These generally seem like an easy lift from an engineering perspective, but encompass deep product/domain expertise in the fraud operations space.

For both these categories, there are plenty of options out there to choose from, and it’s usually easy and cheap to integrate them into an in-house system.

Where will investments yield high ROI?

The answer is in – as always – the data.

Data products manage to capture your business’ uniqueness perfectly:

Your unique product
Your unique user-journeys
Your unique data structure
Your unique customer base
Your unique fraud patterns

Oftentimes, the frustrating bit in working with 3rd-party vendors is trying to push your oval-shaped product through their square-shaped integration.

This is what you want to solve.

Which data products are best to capture your uniqueness? Data features organized in a Feature Store, and Machine Learning models.

How so?

Designing your own features is the only way to capture your unique business experience and insights.

For example, your own velocity features that focus on an identifier that is unique to you.

In turn, feeding these features into your own Machine Learning model, means your score will be customized to your needs.

Side note: Sending “custom data points” to your fraud vendor already? These are not used in their ML models, regardless of what they claim. They are unknown entities to them, and will rarely be part of the training dataset.

“But wait!” you say.

“Vendors have much more data feeding their models from their network, how can I do any better?”

The truth no vendor will ever admit - there’s no data like your data.

Yes, having huge datasets is nice, but relevance is even more important.

I’ve trained more fraud models than I can count and I can assure you - data from sources other than yours often has little to no effect on your performance.

In fact, the main reason why vendors do better at scoring than their clients is not their algorithms and datalakes.

It’s the fact they’ve invested heavily into building their own feature store.

Yes, the same aforementioned feature store that 99% of business rush past on their way to ship their raw data-fed model.

TL;DR Summary

It’s easy to get frustrated with your fraud vendors and decide to develop your own tech.

The two most common pitfalls I encounter are:

Hidden high maintenance fees
Treating it as a software project rather than a domain-led product

Look for these signs to know it is time to go for it:

Your fraud team is mature enough (size, experience, and processes)
Your fraud team's goals are focused on unlocking growth rather than mitigating losses

Ready to go? Focus on developing these first:

Your own custom data features
Your own custom Machine Learning models

As always, I’d love to hear from you.

Have some heroic/botched war stories? Don’t hesitate to write, I read all messages.

That’s all for this week.

See you next Saturday.

P.S. If you feel like you're running out of time and need some expert advice with getting your fraud strategy on track, here's how I can help you:

Fraud Strategy "Power Call" - Book a consultation call with me to get clear, actionable recommendations that fit your budget. Guaranteed.
Book a Call Now >>

Fraud Strategy Workshop - are you an early-stage Fintech that needs to move fast and with confidence? Book this 1.5-hours workshop to get instant insight into your vulnerabilities, optimization opportunities, and get clear actionable recommendations that won't burn through your budget.
Book Your Workshop Now >>

Fraud Strategy Transformation Program - are you a growth-stage Fintech in need for performance optimization or expansion of your products offering? Sign up to this 6-8 weeks program, culminating in a tailored made, high-ROI roadmap that will unlock world-class performance.
Schedule a Call Now >>

Enjoyed this and want to read more? Sign up to my newsletter to get fresh, practical insights weekly!

Chen Zamir