The real cost of stacking identity and fraud vendors 

Every new threat tends to arrive with its own vendor. What rarely arrives is the full bill for keeping them all working together, or for what slips through the gaps between them.

In short: every identity or fraud vendor adds an SDK, an integration, a dependency and another rules console. The real cost is not in the licences but in keeping the tools working together, and in the fraud that slips through the handoffs between them.

The pattern repeats in almost every regulated organisation. First comes a vendor to verify identity at onboarding. Then another for device intelligence. Then one to detect bots, another to analyse in-session behaviour and, if needed, one more to strengthen authentication. Each decision makes sense on its own. The problem appears when they add up.

What shows up on the invoice and what doesn’t

The licence is the visible cost. It is the one that gets negotiated, approved and reviewed every year. But every new vendor brings a series of costs that appear in no contract and that the technical team ends up paying.

More SDKs

Every control in the digital channel usually needs its own SDK. That means a heavier app, more permissions to justify to the user, more libraries to keep up to date and more chances of conflict between them. And every vendor update forces the whole flow to be tested again, because nobody guarantees it will not break what the one next to it does.

More integrations

Each tool speaks its own language: its data model, its scoring format, its response times and its way of returning a result. Someone has to translate between all of them and decide what to do when they disagree. That middle layer is rarely designed. It grows on its own, one integration at a time, until nobody knows it end to end.

More dependencies

Every vendor brings its own roadmap, release schedule, service level agreements and approach to data. If one goes down, the journey suffers. If one changes its terms, you have to renegotiate. And each one is another third party with access to personal data, with everything that means for risk management and for the conversation with the regulator.

More technical debt

Decision logic ends up scattered: some rules live in one console, others in another, others in your own backend. Duplicate thresholds appear and contradict each other, along with exceptions nobody remembers creating. Changing a criterion stops being a risk decision and becomes a development project.

The cost nobody measures: the gaps between tools

Everything above can be budgeted, even if it takes effort. What cannot be budgeted is what happens between one tool and the next.

Take a common account takeover case. At onboarding, the person was verified correctly. Months later, someone logs in with their credentials, which are the right ones. The authentication tool accepts the login as valid. The tool that analyses the session sees a new device and slightly different behaviour, but it does not know who was verified at onboarding or how that person usually behaves, so it has nothing to compare against. Each system approves its own stretch. None of them sees the whole story.

Fraud does not need to break any control. It only needs to move through the space between them.

The more vendors, the more handoffs and the more space. Each tool holds part of the context and none holds all of it. The result is twofold: more fraud that goes unseen, and more legitimate customers who face friction because no system knows enough about them to let them through.

The market is seeing it too. Gartner expects point solutions from different business functions to be consolidated into unified platforms built around case management and decisioning engines:

“Online fraud prevention will change significantly by the end of the decade.” Gartner, Emerging Tech: The Future of Online Fraud Prevention (Gartner, January 2025)

Gartner’s view on banking is also covered in why higher IT spending doesn’t always lead to better fraud prevention in banking.

Five questions before adding the next vendor

If you are deciding between a platform and specialists, we cover it in suite vs. best of breed: when to choose each approach.

1. Does it share context with what you already have? If it does not know who was verified at onboarding, it will be making decisions about an identity it knows nothing about.
2. How many SDKs will your app have afterwards? And who makes sure they coexist on every release.
3. Where will the decision live? If it adds another rules console, it adds another place to check why something was approved or blocked.
4. What happens to the data? Where it is processed, who controls it and which deployment options exist.
5. Will you be able to reconstruct a decision a year from now? If the evidence is spread across vendors, so is the audit.

One vendor fewer, not one more

The alternative is not to give up controls. It is to stop them working in isolation. An identity verified at source that follows every login and every session (continuous identity verification) lets every new signal be compared with what is already known about that person. A single SDK for the whole journey reduces the technical surface. And a single risk logic, which recommends and leaves the final decision to each organisation’s rules engine, puts control back where it belongs. That is the principle behind white-box identity orchestration.

Fewer pieces to maintain, fewer handoffs to watch and fewer gaps for fraud to get through. That is the approach behind the Facephi Identity Platform. If you want to review how many vendors support your journey today, talk to our team.

Frequently asked questions about the cost of multiple fraud vendors