What Happens to Your Fraud Defence If Your Vendor Disappears Tomorrow?

Ask a fintech's head of fraud what happens if their fraud vendor disappears tomorrow, and the honest answer is usually a pause, then "we'd fall back to rules." Ask which rules, tested on what data, catching what share of today's losses, and the pause gets longer.

That is not negligence. A good outside fraud model is often the reason the company could launch so fast in the first place. But the dependency grows quietly. Within a couple of years, the vendor's score is wired into onboarding, payments and payouts, the in-house rules have not been tuned since launch, and nobody has ever run the business without the vendor for a single day.

Why exit planning is a real requirement, not a hypothetical

For US banks, and for fintechs that sit inside a bank partnership, the expectation is written down. The 2023 Interagency Guidance on Third-Party Relationships from the Federal Reserve, FDIC and OCC treats termination as a stage of the relationship life cycle, alongside planning, due diligence, contracting and monitoring. Among the termination considerations it lists are options for transitioning the activity to another provider or in-house, the time and capabilities needed to do so, and the handling of data and system access afterwards. The planning stage calls for contingency plans in case of a risk event (see the OCC's 2024 guide for community banks for a practical walk-through).

A sponsor bank reviewing a fintech's fraud program will eventually ask the question in that language. "What is your plan if this vendor terminates, raises prices sharply, has a long outage or is acquired?" A document that says "we would move to another vendor" does not answer it. The real answer is a number: how much fraud you would catch, and how many good customers you would decline, on the day the vendor's score stops arriving.

How the dependency fails in practice

• The fallback was never tested. Rules written at launch are still in the code, but they have drifted out of date as fraud patterns changed and the vendor's model quietly absorbed the work.
• The data is not yours in usable form. You have the vendor's score and decision, but not the features or labels needed to train anything else. Confirmed fraud outcomes may live in a case tool, a spreadsheet and the vendor's portal, with no join key.
• The integration is load-bearing in ways nobody mapped. A timeout on the vendor call might fail open, approving everything, in one flow and fail closed in another.
• The contract does not help. Notice periods, data return terms and transition assistance were negotiated by procurement, not by the fraud team, and are read for the first time during the crisis.

A self-check: seven questions to answer this month

1. What does a vendor timeout do today? For each flow that calls the vendor, find out in code, not from memory, whether a timeout approves, declines or queues.
2. Could you score yesterday's traffic without the vendor? If yes, with what? Run it and compare catch rate and decline rate against what the vendor did.
3. Do you hold your own labels? Can you produce, in one table, every transaction from the last twelve months with its eventual fraud outcome, independent of the vendor?
4. Do you hold your own features? Are the raw signals the vendor scores on (device, behaviour, history) logged on your side, or do they only exist inside the vendor?
5. What does the contract say about exit? Notice period, data return format, transition support, and whether you can keep the vendor's historical scores.
6. Who decides, and how fast? If the vendor went dark at 2 a.m., who has authority to switch flows to the fallback, and is that written down?
7. When did you last rehearse? A short, scheduled run of one low-risk flow on the fallback tells you more than any document.

If questions 2 to 4 come back "no," your exit plan is a vendor selection project, and those take months. That is the gap worth closing first.

How Riskernel runs this as a fixed-scope assessment

The Fraud Vendor Exit Plan starts with a one-week exit-readiness scan: how your flows behave without the vendor, what data you hold, where the contract and runbook leave gaps. If you choose to continue, a four-week build follows: a backup fraud model built inside your own cloud with Riskernel scoring, tested on held-out data, and a signed exit-test report showing how it performs against your real traffic. You do not have to leave your vendor to do this. The goal is to know your options with numbers, before anyone asks. Scope and fees are agreed on a short call.

If you are already weighing alternatives, two earlier pieces may help: Shadow Testing a Fraud Vendor Before You Touch Production and our look at NICE Actimize alternatives.