The Vendor You Can’t See Behind the Curtain
An examiner asks a financial institution why a customer was declined. In turn, an analyst reads the vendor's score back as if it were an answer. Pressed further, the room goes quiet, not from unwillingness but inability: somewhere in the fraud stack sits a decision engine, and if you ask it why, the honest answer is a shrug wrapped in an NDA.
To be clear, that is not a knock on the vendor. It is the deal you signed as a financial institution. You bought speed, scale, and volume no single institution could match, but not the ability to open the hood. And this was not accidental. No mid-size bank alone sees enough fraud to train a model as well as a vendor pooling signal across hundreds of institutions, and few can retain the data science talent fraud modeling requires.
That trade-off held when fraud typologies moved slowly, but that's no longer the case. Mule networks reorganize faster than meetings get scheduled, and the Federal Reserve’s 2026 Risk Officer Report found a rising share of institutions rating mule and synthetic identity risk as persistent or increasing.
Regardless, a control you cannot review or tune isn’t just outsourced workload. It’s outsourced judgment.
There Are Three Places Where the Opacity Hits Financial Institutions
1. Transparency.
Vendors will point to explainability features and expect the argument to stop there, but there are two different pieces of feature explainability. Global explainability is understanding how the model works in general (feature set, weighting logic, etc.). Local explainability is narrower and more urgent, including information on why a specific customer declined on a specific transaction. Most vendors will hand over local explainability without much resistance. However, it's not enough without describing, in plain language, what the model is generally sensitive to and how it was trained.
With recent regulatory guidance updates from the SR 11-7 to the SR 26-2 guidelines, ultimate accountability for third-party models is on the banking organization itself. They have to document it, get its logic independently validated, and monitor it in line with how much risk it poses.
2. Flexibility.
A model tuned on consortium-wide behavior reflects the average institution’s customer base and risk appetite, not yours. A credit union serving a tight geographic footprint and a national digital-first bank do not have the same fraud surface, and a model built to generalize across both will underperform for each. (Somewhere, a statistician is muttering "regression to the mean" and yes, that’s the joke, and yes, it’s also the problem.)
3. Control.
Vendor models update on the vendor’s roadmap, not your threat calendar. If a new synthetic identity pattern shows up in your portfolio on a Tuesday, your ability to respond is bounded by however fast the vendor’s product team prioritizes your ticket against every other customer’s ticket. That is not a criticism of the vendor — it is just math.
It's worse when the retrain happens without your knowledge. Vendors often update models on their own cadence, and unless your contract says otherwise, you are not entitled to advance notice. To solve this, financial institutions can change notification requirements written into the agreement, and holdout rights, which is the ability to run the prior model version in shadow mode before the new one takes over.
Ask These Before You Sign, Not at Renewal
Yet the process of leaving a vendor also poses risks, such as the cost of losing case history, tuning parameters, custom labels. Rather than discovering that loss when you are halfway out the door, ask your vendor these five questions:
- Documentation rights: can you get, in writing, what the model is generally sensitive to, not just why any single decision was made?
- Retrain cadence: how often does the vendor retrain, and is that schedule disclosed to you at all?
- Change notification: are you notified before a model update goes live on your traffic, or only after?
- Typology response SLA: when you flag a new fraud pattern the model is missing, is there a contractual response time, or just a ticket queue?
- Exit data rights: when the contract ends, do your case history, labels, and tuning come with you, or stay with the vendor?
This Is a Risk Tolerance Decision, Not a Best Practice
There is no universally correct ratio of vendor-to-in-house fraud detection, and anyone selling you one is selling you something. The right mix depends on your institution’s size, data maturity, and appetite for the ongoing cost of maintaining independent capability.
For banks to maintain best practices, a named internal owner needs to be accountable for challenging the vendor model on a set schedule, not just when something breaks. It means a contractual SLA on how fast the vendor is obligated to respond when you flag a new typology, so “the vendor’s roadmap” has a ceiling instead of being open-ended. And it means a predefined trigger for reassessment — a specific shift in false negative rate, a specific volume of a new fraud patterns the model is missing. Absent those three things, “we made a considered decision” is indistinguishable from “we never really looked at it.”
The failure mode is not relying on a third party. It is never having asked the question, and discovering during an incident review that “we do not actually know why the model does what it does” was the institution’s real answer all along.
Looking for a reprint of this article?
From high-res PDFs to custom plaques, order your copy today!
