#24 - Selecting a fraud vendor? The critical detail most miss

When choosing a new fraud vendor, buyers typically survey the same old questions:

What’s the pricing model? What’s the AI score performance? What does the integration look like?

This makes sense, as the answers will help you build the business case and calculate the ROI to make an informed decision.

And yet, the same buyers end up disappointed with their selected vendor nonetheless.

How come? There’s one thing I’ve noticed buyers address way too late in the process:

What the initial setup of the system configuration would look like, and who’ll be responsible for it.

Or if we go back to the ROI question, do we know how fast we’re going to reach optimal performance?

In today’s issue, I’d like to cover the three common models for initial system setup, explore their pros and cons, and help you decide which one is best for you.

Why is the initial setup such a big deal?

One might think, especially considering AI-powered products, that fraud SaaS is a “plug & play” integration:

You follow the API integration instructions to the letter, you test and validate it, and Voilà: you eliminate fraud.

Unfortunately, nothing can be further from the truth.

There are a couple of moving parts that make the setup not only a delicate matter, but also one that is unique for each new buyer. Let’s consider:

Optimizing different segments: Fintechs rarely have one cohesive flow. Instead, they’ll often have different flows that would look entirely different. Think of new payments vs. subscriptions, consumer vs. merchant, open-loop vs. closed-loop, different regions, different products, etc.

Replacing legacy systems: whether you’re replacing an existing vendor, or some internal tool your team hacked together, it’s likely that some migration is needed. These might be existing fraud rules, block lists, workflows, etc., and it’s rarely a case where you can just copy these 1:1 to your new vendor.

You also might ask: “if the POC was successful, why can’t we just copy the same setup?”

That’s a great question, but it can be very misleading.

By their nature, POCs never manage to simulate reality fully. Especially with how the new vendor will perform as part of your entire stack, and not on its own.

You also need to consider that POCs usually run over historical data, which is, well… historical.

Your product and customer base might have changed since then. Fraud patterns might have changed, and even the available data might have changed.

So while POCs can give an indication of ROI, they will rarely inform you on how to set up the system when you go live.

The 3 ways to setup your system

Over the years, and considering I built a fraud SaaS vendor myself, I’ve seen three common models for how initial set up is done.

The main difference between them? Who’s responsible for it.

SaaS model

Many vendors, especially mid-size ones, would opt for a model where they provide the tool, and the buyer is fully responsible to manage it on their own.

In many cases, the vendor will provide training on the tool and documentation for its features, but these will usually be generic and will not focus on the specific pains and needs of the buyer.

While many such vendors will offer robust features that will allow you to simulate and test the configuration, it’s not always the case.

If you don’t feel comfortable with the testing environment a vendor is offering, know that the implication is this: not only are you expected to set up the system, but you are also expected to do it on your own testing environment.

Such a model, although quite common, is only recommended to professional teams that are used to manage their fraud configuration on their own.

If you don’t have this expertise in-house, you should bake in another six months of tuning before the benefits match your expectations.

“Out-of-the-box” templates model

Another common model I see is offering buyers “starter kits” with templates of rules and AI thresholds. In some cases, the vendor might offer industry-specific templates that might seem like a very close match to your needs.

Frankly, I see these as a fig leaf that covers what it really is: the SaaS model, just with some garnish on top.

And I say that as someone who’s built and offered templates myself. The truth is we never saw any client successfully manage to use them.

Why is that?

The misconception I see with both buyers and vendors is that templates are ready-made rules, and implementing them as-is will perform quite well.

But in reality, templates are… templates.

They are ideas for rules that you can experiment with and fine-tune to your business needs.

Some of them might prove to be irrelevant to you. Some of them might be alright after some tuning.

But it’s quite likely that the best performing configs would not even be included.

Either way, it’s up to you – the buyer – to do the research, fine-tuning, and pruning of the different templates.

And so you see, there’s quite a small difference between what is expected of you in this model and the previous one.

The only slight advantage ready-made templates provide is that some domain expertise is already baked into them.

This means that pure data teams with no fraud experience, can still use them as solid starting points, rather than doing everything from scratch.

But if you don’t have a data team, or if you do have a fraud team, there’s very little difference in practice between having templates and not having them.

Professional services model

The least common model I see in the market is the one where vendors offer to do the initial set up themselves.

Ironically, these tend to be either small-sized players that take a consultative sales approach or the mega-sized vendors that offer paid professional services on demand.

We used to offer such services ourselves, usually free of charge and for a period of three months. We knew that while more expensive for us, it has the best chance for fast optimal performance, and that always helped to create stickiness with clients.

Regardless of whether this is a paid or a free service, it comes with a lot of benefits for the buyer.

Firstly, it puts the responsibility for achieving the promised ROI on the vendor’s shoulders.

This solves a common misalignment I see where buyers choose vendors based on forecasted ROI, but in fact are “charged” with generating that ROI themselves, while the vendor is responsible for their services uptime.

Secondly, it means that the team that will set up the system has a very extensive and intimate familiarity with it. This goes a long way in optimizing performance, by knowing all the tricks and short-cuts one can take.

Thirdly, even if the vendor is only tasked with the initial setup, the resulting configuration can be treated as a “real”, high-performing template.

It’s much easier for the client to take charge once it’s deployed, and fine-tune it based on how fraud evolves.

What’s the best model for you?

I hope it’s clear by now that while we talked about three models, there are actually mainly two:

Either the buyer needs to set the system up, or the vendor does.

In my experience, the difference in performance between the two can be quite significant, especially if the buyer is lacking in-house talent.

This effect is often “hidden” in standard POCs, and usually comes to light too late in the process.

Here are some guidelines to make sure you’re properly covered:

  1. Find out who’s responsible for initial setup early on your calls with a vendor, and definitely before you make a decision.

  2. If you’re lacking in-house talent, consider vendors that offer professional services as ones that have a distinct advantage. Even if they don’t come first in a POC.

  3. Unless it’s really unreasonably priced, always opt for any paid initial setup. Don’t only compare it to your fraud losses, but also to how easy it’ll be to keep high approval rates.

  4. Initial setup services shouldn’t be time-bound. Instead, they should conclude when the expected performance is met.

  5. Lastly, if you do have some in-house capabilities, or if you’re planning on acquiring them soon, treat professional services as a “nice to have”. In such a case, I will judge POCs based on pure performance.

Have additional tips? Hit the reply button and let me know!

In the meantime, 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:

Free Discovery Call - Unsure where to start or have a specific need? Schedule a 15-min call with me to assess if and how I can be of value.
​Schedule a Discovery Call Now »

Consultation Call - Need expert advice on fraud? Meet with me for a 1-hour consultation call to gain the clarity you need. Guaranteed.
​Book a Consultation Call Now »

Fraud Strategy Action Plan - Is your Fintech struggling with balancing fraud prevention and growth? Are you thinking about adding new fraud vendors or even offering your own fraud product? Sign up for this 2-week program to get your tailored, high-ROI fraud strategy action plan so that you know exactly what to do next.
Sign-up Now »

 

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

Next
Next

#23 - Confessions of a fraud CTO: My million-dollar algorithm mistake