---
title: Is your fraud platform a black box?
source_page: https://www.sardine.ai/blog/fraud-platform-black-box-ai-agents
canonical: https://www.sardine.ai/blog/fraud-platform-black-box-ai-agents
format: text/markdown
date: 2026-10-23T13:00:00.000Z
author: Chen Zamir
description: When vendors gate their data and platform knowledge they create a fraud platform black box. AI agents give teams direct access without waiting on vendor staff…
---

**Quick links:** [Human page](https://www.sardine.ai/blog/fraud-platform-black-box-ai-agents) · [Home](https://www.sardine.ai) · [Customers](https://www.sardine.ai/customers) · [Blog](https://www.sardine.ai/blog) · [Demo](https://www.sardine.ai/demo)

---

# Is your fraud platform a black box?

**Author:** Chen Zamir · **Published:** 2026-10-23T13:00:00.000Z · **Categories:** Fraud

When vendors gate their data and platform knowledge they create a fraud platform black box. AI agents give teams direct access without waiting on vendor staff…

Every few years, fraud prevention gets a new technology that promises to make the job easier. Rules, then batch analytics, then machine learning each make fraud platforms more powerful. But each one also asks more of the people running them.
Inevitably, the result is a growing gap between the people who build fraud platforms and the fraud teams who use them. Now that AI has forced another technology wave over the industry, it bears the question: will it widen the gap even further?
Key takeaways: Why the platform is winning and your team is not
Every major fraud platform technology wave, from rules to machine learning, widened the gap between the teams that build fraud platforms and the teams that use them, because vendors gate their data and platform knowledge.
The fraud platform builder and practitioner gap has two root causes. First lack of direct fraud platform access, including SQL and data warehouse access. Second lack of fraud vendor platform knowledge covering data schemas, feature definitions, and model mechanics.
AI agents acting as fraud AI middleware reverse this trend by translating plain analyst requests into the platform’s exact definitions, running fraud score sensitivity checks, and writing rules directly from observed patterns, without vendor involvement.
The practical test for any fraud platform buyer evaluation is to ask the vendor how much of the platform your team could run without the vendor’s staff. The answer tells you whether you are looking at a tool or a dependency.
The fraud platform builder and practitioner gap
Every fraud platform involves two groups of people. Builders design the data, the features, the rule engine, and the models. Practitioners are the analysts and fraud managers who use it every day to monitor, investigate, and enact decisions.
When builders and practitioners work at the same company, an analyst who doesn't understand how the platform calculates a data point can ask the engineer who built it and usually hear back the same day.
But when the platform comes from a vendor, the analyst is a paying customer. They can't sit next to the vendor's engineering team, and the vendor has good reasons to keep some of the details of its data and models to itself. It’s their secret sauce.
So what happens in a lot of cases is that companies pay for the whole platform, but end up using only the parts their team actually understands. And if you look at how the fraud prevention industry developed, you could see how this has only gotten worse over time.
The first fraud tools were review screens. They showed an investigator who was behind a transaction or onboarding application and what that person was trying to do, and they recorded the decision to approve or decline. The software displayed information, and the investigator relied on their own judgment to match the data and reason through it before deciding what to do with the event.
Fraud teams later turned that judgment into rules, which a rules engine runs on every event in real time. To stop a pattern with a rule, an analyst now had to know how that pattern shows up in the platform's data. That means knowing which features exist (a feature is a single data point the platform calculates, such as the number of accounts linked to one device), what each one means, and how to combine them.
With advanced analytics, analysts could schedule jobs that run in batches at the end of the day or week. These include anomaly detection, clustering accounts into networks, and reports on patterns too heavy to calculate while a transaction waits for a decision. Anyone who wanted to run these jobs in-house faced a higher bar again. They had to understand the data schema (the way the platform organizes and stores its data). They also had to write the jobs in SQL, the standard language for querying databases, or in code that runs on a schedule.
Vendors then added machine learning models that attribute a risk score to every event. Understanding why a single event scored high is the easy part, but deciding what to do with the score is harder. Someone has to choose a threshold, meaning the score above which the platform declines or reviews an event. Because one threshold rarely fits every product, region, and type of user, most teams need several.
Setting thresholds per segment requires access to the data and the skills to query it. It also takes knowing which features the model relies on and running sensitivity checks, which test how many good users you decline and how much fraud you catch as the threshold moves. This requires domain expertise, technical ability, and data access.
But a sober view of the industry would have to conclude that most fraud teams don’t have these capabilities, unless they’ve built their own platform.
Critical platform knowledge is gated behind the vendor
When we think about what fraud teams are missing, we mostly focus on technical skills like SQL and coding. But a company can train for those or hire for them. Two other requirements are much harder for a fraud team to meet: free access to the vendor's data, and knowledge of the platform’s internal workings.
The biggest irony in fraud is that much of what a company pays a fraud vendor for is data its own team can't query. That includes features the vendor calculates itself, signals it brings in from specialist providers like email or device intelligence, and consortium data pooled from its other clients.
At the same time, fraud teams often lack critical knowledge on how to operate the platform itself. Platform knowledge means knowing how the vendor organizes its data and builds its features, how its models calculate risk scores, and how its rules execute. Even a team with full data access gets stuck without it.
Velocity features are a good example. They count how often something happens within a time window, such as card attempts from one device in the last hour. Whether that window is rolling (always the last 60 minutes) or fixed (resetting at the top of every hour) changes how you should write a rule. A burst of 10 attempts that straddles the top of the hour looks like two smaller bursts to a fixed window, so a rule designed with a rolling window in mind can miss it.
Or take a pattern an analyst spots in new signups: email addresses built from a first name, the first letter of a last name, and two digits, like johnd42 and sarahk17. The analyst now has to work out whether a feature captures this pattern, whether it takes one feature or a combination of several, and whether those features need a particular definition to work in the rule engine. Each answer depends on how the vendor built the platform.
You could argue that good vendors equip their users with comprehensive documentation, training sessions, and live support to answer ad-hoc questions. And you’d be right saying that. But documentation and training are simply not enough in systems so intricate.
Indeed, vendors have tried to get this knowledge into their users’ hands for years with dashboards, reports, documentation, training, and customer success teams. But each of these efforts runs into the same tension, between too little and too much.
Tools that give access to data can't keep up with demand. Fraud varies from company to company and changes from week to week, so fraud teams keep needing a new view, segment, or filter that the existing dashboards don't show. Every company has a long tail of questions it wants to ask, and no vendor can build a report for each question, let alone for each client.
Documentation has the opposite problem. A vendor can document all 2,000 of its data points, but an analyst writing a rule needs one of them, and finding it and understanding it is hard even with good search and filters.
As a result, fraud teams get plenty of instructions and training but very little direct access to data or help reading it, which is what they need most in order to make clear decisions.
Agentic AI middleware reverses the trend
Given the ever-growing gap between builders and users, the reasonable expectation is that AI adds another layer of complexity on top, making it even worse. But in reality, agentic AI pushes this trend in the other direction.
Vendors built the first AI features in fraud platforms on top of their own documentation, as assistants that users could ask how the platform works. Users got better answers faster, and vendors saw that AI could act as a “middleware” layer between the platform and the people using it.
But AI agents can also give users a way into areas that so far were completely blocked to them. By taking an extended “middleware” role in a platform, they enable the users to communicate with and operate the platform more effectively. The agents translate a plain question or need into the exact definitions the platform requires, then return a decision, a report, or the data needed. They can also handle the one-off, company-specific requests that no product team could build a dashboard for.
Example A: AI fraud rule writing from a signup pattern
Take the analyst who spotted signups with email addresses like johnd42 and sarahk17. She has found a handful of these accounts and wants to stop more of them.
A data analyst agent takes the accounts she flagged and does two things with them. It searches for more accounts that match the same pattern, which gives her more data to work with and a wider set of accounts to act on. It also goes into the data schema to find the exact features and values that describe the pattern, so her informal description (first name, last initial, two digits) becomes a precise definition in the platform's own "vocabulary".
A rule-writing agent then turns those findings into a rule for the platform's real-time rule engine. That's a different task from writing a database query, because in real-time these features would have different naming conventions, and some might be missing entirely. The agent can also help tune the rule to catch the most fraud while declining the fewest good users, which keeps false positives low.
AI provides the two things the analyst can't get on their own: access to the vendor's data and knowledge of how the platform expresses it.
At Sardine, the Rule Assistant Agent and the Data Analyst Agent do this work inside the platform. See how our AI agents work for fraud teams.
Example B: Fraud score threshold setting by segment
The same approach works for utilizing machine learning more effectively. Say a fraud manager wants to know how to set decline thresholds for their model. They can ask a data analyst agent to split the user base into its main segments, such as product flow (signup, checkout, withdrawal), region, payment method, and account type.
For each segment, the agent runs a sensitivity check and finds the threshold that best meets a goal the manager picks. That goal could be a certain decline rate, a precision level, or a recall level. They can also ask for the same analysis at three levels of risk appetite, from conservative to aggressive, and get back a table of recommended thresholds to compare side by side.
This analysis used to require knowledge of the data schema, experience running sensitivity checks, and, most importantly, fraud vendor data warehouse access that most teams simply do not have. It was simply either out of reach or a request sent to the vendor, usually at a cost. But with an agent, the fraud team runs it, makes the call, and can repeat it every month as fraud patterns shift without waiting on the vendor.
What AI capabilities to look for
Every earlier technology wave put more distance between fraud platforms and the teams using them. Agents are now starting to shrink it, and their biggest effect so far is helping companies get far more out of platforms they already pay for.
That also changes what builders can ship, because they can add more sophisticated detection without asking more of the people running it.
The stakes are real. Trustpair’s 2026 fraud trends survey found that 58% of senior financial decision-makers believe fraudsters now evolve faster than humans can respond.
For anyone choosing a fraud platform, ticking the AI box is the obvious place to start, but it’s also too generic. The next question is whether those capabilities help your team get more out of the platform, or whether the platform remains a black box: when your team can't reach its data, can't see how it works, and can't turn either into clear decisions.
By that definition, plenty of fraud platforms with well-explained models are still black boxes.
AI that opens up the platform's data and inner workings to your team is one of the main things to look for. A simple way to test it in a vendor meeting is to ask how much of the platform your team could run without help from the vendor's staff.
The answer will tell you whether you're buying the whole platform or just the 10% your team can reach.
Dive deeper into How to Deploy Trustworthy AI Agents for Financial Crime that give your fraud team platform independence.
Frequently asked questions
### What is the fraud platform black box problem?
A fraud platform is a black box when the team paying for it cannot reach its data, cannot understand how its models score events, and cannot translate that understanding into working rules or decisions without the vendor’s help. The problem compounds over time because each new technology layer, from rules to batch analytics to machine learning, requires more technical skill and more platform-specific knowledge to operate effectively.
### What is fraud AI middleware and how does it help?
Fraud AI middleware is an AI agent layer that sits between a fraud team and the vendor platform, translating plain requests into the platform’s internal definitions, querying the vendor’s data directly, and returning working rules, reports, or threshold recommendations. It gives fraud teams access to the parts of the platform that were previously only reachable through the vendor’s own staff.
### How does AI fraud rule writing from pattern work in practice?
A fraud analyst identifies a suspicious pattern, such as email addresses built from a predictable formula, and describes it in plain language to a data analyst agent. The agent searches the platform’s data for additional accounts matching the pattern, identifies the exact features and values that define it in the platform’s schema, and passes those findings to a rule-writing agent that produces a working rule for the real-time rules engine, including fraud rule false positive tuning to minimize impact on good users.
### What is fraud score threshold setting and why does it require data access?
Setting a fraud score threshold means choosing the score above which the platform declines or reviews an event. Because one threshold rarely fits every product, region, and user type, most teams need several, each requiring a fraud score sensitivity check that shows how many good users are declined and how much fraud is caught as the threshold moves. This analysis requires access to the vendor’s data warehouse and knowledge of the platform’s data schema, which is exactly what most fraud teams do not have without vendor involvement.
### How do I evaluate whether a fraud platform will give my team genuine independence?
Ask the vendor directly how much of the platform your team could run without the vendor’s staff. A platform that requires the vendor for data queries, rule tuning, threshold setting, and feature interpretation is a vendor lock-in risk, not a tool. A platform where AI agents give your team direct fraud platform access, SQL access, and schema-level knowledge is one your team can actually operate at the speed fraud requires.
Reach out to the Sardine Team to see how much of your current setup could run without the vendor in the room.