Self-Hosting Fraud Decisioning: Kairos vs Sift, Sardine, and SEON

If you run a marketplace, fintech app, or payment product and need approve/step-up/review/block decisions on signups, orders, and payouts, the build-versus-buy question between Sift, Sardine, SEON and self-hosted platforms like Kairos has a sharper answer than most comparisons suggest: the expensive part of fraud operations was never the software license or the per-call fee, it is the continuous tuning loop of labels, review queues, retraining, and deployment judgment. Self-hosting an open-source decisioning platform like Kairos moves that loop into your codebase and, in Kairos’s design, onto your coding agent. It does not remove the labor. Whether that trade is rational depends on five axes that actually separate fraud platforms, plus one audit most “self-hosted” READMEs skip: what hosted dependencies survive the migration.

A standing caveat before any number below: every Kairos and Ojuri capability cited here is project-reported from its README, with no independent deployment or benchmark in the documentation reviewed here. Every Sift, Sardine, and SEON figure is vendor-reported marketing. This article contrasts two sets of self-descriptions and labels them as such; the one independent evidence base is academic work on label scarcity and agent architecture, flagged as study-reported where used.

The real question: who owns the tuning loop

Kairos positions itself, per its README, as “an open-source alternative to Sardine, Sift, Riskified and SEON, with two things they don’t have: your coding agent tunes it, and decision models catch fraud before you have the labels to train on.” That is a strong claim, and one part of it is already dated. SEON’s September 2026 release notes, per SEON’s docs, added “an explanation report before every training run and a sign-off before every deployment,” plus an SEON MCP connector “now listed in Anthropic’s directory.” A SaaS vendor now ships agent access and agent-governance features of its own, so “your agent tunes it” is no longer a clean differentiator. What remains genuinely different is where the tuning labor lives and who is accountable for it.

Sift sells that labor as a service. Its platform page describes, vendor-reported, a structured implementation process: kickoff, technical integration, data review, workflow design, and implementation tracking, backed by expert services. You pay for a contract and a team that has done this before. Kairos and Ojuri hand you the machinery and expect you (or your agent) to operate it. The rest of this article maps the five axes where that choice actually bites.

Decision API semantics: outcomes, reasons, and what happens on timeout

The first axis is the vocabulary of the decision call and its failure behavior. Kairos, project-reported, returns four outcomes: “one call returns approve, step up, review or block, with a risk score and the reasons, from the subject’s history, the devices, cards and addresses it shares with others, and the session.” Ojuri, project-reported, returns accept/review/decline and makes an explicit choice about infrastructure failure: “If the model times out, the transaction goes to a human for review — a customer never gets declined because of an infrastructure problem.” If Redis is unreachable, Ojuri’s predictions continue using default values. Those are degradation semantics worth demanding from any platform, because a decision API that auto-declines on timeout converts your outage into your customers’ problem.

On the vendor side, Sift advertises, vendor-reported, “[r]eal-time scoring in less than 150 milliseconds” with continuous scoring across account and transaction events, per Sift’s platform page. That is a latency SLA-style commitment a fresh self-host has to earn on its own infrastructure. As of these sources, neither Kairos’s README nor the vendor pages document timeout behavior for the SaaS APIs or for Kairos’s decision path; ask for it in evaluation, because the READMEs are silent where Ojuri is explicit.

Label cold start: chargebacks arrive late and labels are scarce

Every supervised fraud model faces the same physics: the ground truth arrives weeks after the decision, when a chargeback lands or an analyst closes a case. How scarce those labels are in practice is quantified by independent work: in Tencent’s production WeChat fraud graph, study-reported in arXiv:2308.02793, “Only 53,660 user nodes are manually labeled by human experts: 10,749 of them are fraud users and 42,911 are normal users,” out of roughly 6.8 million user nodes. That is a labeling rate under one percent in a production system.

Each platform answers this differently. Kairos’s differentiator, project-reported, is that its hosted Grayson decision models “catch fraud before you have the labels to train on,” a few-label operation claim with no independent verification in these sources. Ojuri’s answer, project-reported, is a mechanical closed loop: “you send chargebacks and confirmed fraud back in through POST /v1/admin/labels, Ojuri retrains once enough have arrived, tests the new model against a later time period than it trained on, and only ships it if it genuinely wins.” SEON’s answer, vendor-reported on its homepage, is daily cadence: “Label transactions as fraud or legitimate and AI retrains daily on your data to fine-tune risk scoring over time.”

The practical implication is that whichever side you choose, you must wire your chargeback feed into the label path from day one. A self-hosted stack without that feed is a rules engine with a model it cannot improve. One caution: Ojuri’s headline 98.8% detection figure comes from its own 128,000-transaction simulation, project-reported in its README, and requires two non-default settings (demo rules off, review band 0.08). A fresh install sets the review band to zero, meaning nothing is ever sent for review. Self-reported metrics with configuration dependencies are exactly the kind of number to re-derive before trusting.

Entity and device linking: your graph versus a cross-tenant network

Fraud decisioning leans heavily on linkage: the card, device, or address this signup shares with three previously blocked accounts. Kairos, project-reported, scores “the devices, cards and addresses it shares with others” as part of every decision. Sardine’s Connections Graph, vendor-reported on sardine.ai, maps “relationships between users, devices, and transactions to spot coordinated activity,” alongside device intelligence and behavior biometrics. SEON, vendor-reported, connects “1,100+ first-party data signals” (seon.io) including digital footprint, phone, address, device and session behavior, expanded from 900+ in September 2026 per its docs.

The structural difference is tenancy. Sift’s pitch, vendor-reported on its platform page, is a cross-customer network: “a global data network processing more than 1 trillion events annually. New to you users are often not new to Sift, which means your team starts with more context before making a decision.” A single-tenant self-host cannot accumulate that. Your graph knows only your own history, which is precisely the point if data residency is why you are self-hosting, and precisely the gap if your fraud problem is attackers who recycle infrastructure across many merchants. This is the axis where the SaaS premium buys something no amount of tuning labor can reproduce internally.

Review queues: turning analyst resolutions into training labels

The review queue is where delayed ground truth gets minted into labels, and it is the piece teams most often underbuild. Kairos, project-reported, has review queues and cases whose human resolutions become labels. Ojuri, project-reported, feeds reviewer overturns back into training, and its Sentinel dashboard includes a review queue, rule editor, model registry, and audit log. On the vendor side, Sift offers analyst-context tooling and SEON ships AI case management, vendor-reported, with SEON claiming its AI tools cut manual review time by up to 50%, per seon.io, an unaudited marketing figure.

The mechanism matters more than the feature checkbox. A queue that records only “approved” or “blocked” throws away the analyst’s reasoning; a queue whose resolutions flow into the retraining set with the case context intact is the cold-start engine. When you evaluate any of these platforms, trace one analyst resolution end to end and confirm it lands in the next training run as a labeled example. If it does not, your retraining cadence is theater.

Retraining cadence and who signs off when an agent ships a model

Kairos’s experiment methodology is the most specific of the platforms compared here, project-reported: “The server trains each variant on your oldest labeled data, chooses on the next, and tests on the newest, then reports ROC-AUC, PR-AUC, the gain over a baseline with its 95% interval, and precision and recall at your thresholds.” (Kairos README) The agent then ships the winning variant as the workflow’s next version. Time-ordered train/select/test splits are the right shape for fraud data, since random splits leak future information into evaluation. Ojuri, project-reported, applies a similar discipline and adds the option to run a new model silently alongside the live one before cutover.

The governance question is what happens between “the experiment won” and “the model is declining customers.” SEON has standardized an answer, vendor-reported: an explanation report before every training run and human sign-off before every deployment. Kairos’s README documents the agent’s experiment loop but, as of these sources, no equivalent human gate before a shipped variant touches production decisions. That is a gap you would have to close yourself, and it is closable: Kairos’s MCP server records every agent action under its key, so the audit substrate exists.

There is also a risk the READMEs omit. MCP architecture research in arXiv:2606.30317 names the core problem when servers expose backend data to LLM agents: protection “against prompt injection via untrusted data.” Fraud data is adversarial by nature. An attacker who can place text into a field your agent later reads (a signup name, an order memo) has a channel to the agent tuning your decision models. The same study reports production telemetry showing tool-selection accuracy degrades as the tool surface grows. Neither concern disqualifies agent tuning; both argue for constraining what the agent can read and requiring sign-off on what it ships.

The hidden-dependency audit

“Self-hosted” deserves a dependency audit before it shapes your data-residency argument. The sharpest counter-evidence here: Kairos self-hosting requires “Node.js 22, pnpm 10 and a Grayson API key from portal.finic.ai,” per the README. The decision model behind its few-label advantage is a hosted dependency, so decisioning is not fully in-house and a Finic portal outage or policy change reaches into your stack. Ojuri, by contrast, is project-reported to run entirely on your own servers with one docker compose up, no SaaS account, and no per-call fees, stable as of v1.7.2 under an MIT license. If residency is the binding constraint, that difference is decisive; if it is not, Kairos’s agent-tuning workflow may be worth the dependency.

A verification checklist for agent-tuned decision models

If you let an agent near production decisioning, these checks follow directly from the evidence above:

1. Import labeled history before judging anything. The WeChat graph’s sub-one-percent labeling rate is what cold start looks like; seed the model with every historical chargeback and analyst resolution you have.
2. Wire the chargeback feed as labels on day one, the way Ojuri’s /v1/admin/labels loop expects.
3. Require time-ordered evaluation. Kairos’s oldest/newest split and Ojuri’s “later time period than it trained on” test are the minimum; reject any experiment report built on random splits.
4. Gate agent-shipped variants behind human sign-off, matching what SEON now standardizes. Kairos records agent actions per key; build the approval step on top of that log.
5. Constrain the agent’s read surface. Prompt injection via untrusted data is a cataloged MCP failure mode, and fraud traffic is the most adversarial untrusted data you handle.
6. Re-derive headline numbers. Ojuri’s 98.8% needs non-default settings (Ojuri README); Sift’s platform page advertises figures such as 72% less manual review (Sift), unaudited vendor claims. Run your own evaluation on your own traffic.

When to keep paying Sift, Sardine, or SEON

Three requirements argue for the contract. First, cross-tenant network intelligence: if your attackers reuse devices and cards across merchants, Sift’s “new to you users are often not new to Sift” context is something a single-tenant deployment structurally cannot match. Second, compliance breadth: Sardine unifies fraud prevention, AML compliance, and real-time transaction monitoring, vendor-reported, and neither Kairos nor Ojuri documents KYC/AML capability in the sources reviewed here. Third, a vendor latency SLA: if sub-150 ms scoring at peak is a hard requirement, an advertised commitment like Sift’s plus an implementation team beats a README.

Verdict

If data residency is the binding constraint, the documentation reviewed here supports Ojuri alone: it runs entirely on your own servers with no SaaS account, while Kairos’s decisions depend on a Grayson API key from portal.finic.ai. Kairos is the candidate only if you accept that hosted dependency in exchange for its agent-tuning workflow, and either way you must staff the tuning loop: labeled-history import, chargebacks wired as labels, and a human sign-off gate before any agent-shipped model touches production decisions. Keep the SaaS contract when cross-tenant intelligence, integrated KYC/AML, or a latency SLA is the actual binding constraint. I would trial the self-hosted path on one decision surface with tolerable review volume first, because the strongest limitation here is evidentiary, not architectural: every Kairos capability rests on its README alone, with no independent deployment, benchmark, or third-party review, and every vendor number is marketing. The decision framework survives that limitation; any specific performance expectation does not.

Frequently Asked Questions

What are the required dependencies for self-hosting Kairos?

Kairos self-hosting requires “Node.js 22, pnpm 10 and a Grayson API key from portal.finic.ai,” per the README.

How does Ojuri handle model timeouts during a transaction?

If the model times out, the transaction goes to a human for review — a customer never gets declined because of an infrastructure problem.

What is the labeling rate in the WeChat fraud graph study?

Only 53,660 user nodes are manually labeled by human experts: 10,749 of them are fraud users and 42,911 are normal users,” out of roughly 6.8 million user nodes. That is a labeling rate under one percent in a production system.