Latest in AI
Finic Launches Kairos: Open-Source Fraud Workflows With MCP Agents
Kairos lets coding agents help build and test fraud workflows, but its deployment and decision limits deserve as much attention as the demo.
Finic introduced Kairos on November 3, an open-source fraud and risk platform that combines decision models, traditional machine learning and an MCP interface for coding agents. Teams can use agents to build workflows and compare model variants, while retaining a record of the signals behind each decision.
The interesting part is the feedback loop. A fraud team can turn new outcomes into another experiment without rebuilding the surrounding application. Whether that loop produces better decisions still depends on the quality of the labels, the evaluation and the person approving the change.
What Kairos does
In its launch discussion, Finic positions Kairos as an alternative to commercial fraud-decision platforms. It is available as a hosted service or for self-hosting, with an Apache 2.0 repository and TypeScript, Python and HTTP interfaces.
The application records events such as sign-ups and payments, builds context around the relevant entities, and returns an outcome such as approve, review or block. Finic's Grayson decision model can answer a plain-language question about an event. Its answers can also become features for conventional scoring models.
That combination is useful where a team has numerical history but also needs to interpret less structured information. For example, an order's amount is a number; deciding whether a shipping address resembles a reshipping service requires a different kind of signal. A model-generated probability can connect those two inputs, though it does not make either one reliable by itself.
How coding agents fit into fraud experiments
Kairos exposes tools through MCP, the protocol that lets an assistant call an application's functions. Claude Code, Cursor or Codex can inspect decisions, define workflows and propose experiments through that interface.
The model documentation describes comparisons between gradient-boosted trees, logistic models, combinations of models and existing probabilities. Experiments split labeled runs by time, train on older examples and reserve newer examples for validation and testing. They report metrics including ROC-AUC and precision-recall AUC, along with comparison intervals.
Experiments require at least 100 labeled runs and both outcomes in each split. That is an important distinction from the claim that a decision model can start working without a customer's historical labels. Evaluating whether a new workflow is better still needs outcomes to compare against.
The agent can reduce experiment setup work. It cannot supply the missing ground truth. If chargebacks arrive weeks after orders, the newest apparent successes may simply be outcomes that have not matured yet.
Self-hosting still uses an external model
The self-hosting guide describes a Node.js server and Postgres database. It also says the server must reach Finic's API and use a Grayson API key. Hosting Kairos on your infrastructure therefore does not make the complete decision pipeline local.
That distinction affects data review and operating costs. The open-source license covers the application code; teams still need to account for the model service and the infrastructure they run. The deployment guide also says Kairos has not been measured at large volume, so the existence of a Docker setup should not be read as a demonstrated production capacity guarantee.
For a team evaluating it, a small historical dataset is a more informative starting point than immediately placing it in a live approval path.
Decision controls matter more than autonomous deployment
Kairos's MCP safety guidance separates tool groups and warns that published workflows affect subsequent callers. It recommends human oversight for agents with decision or workflow-building access. Event fields and notes can originate with attackers, so they must remain data rather than instructions to the agent.
The overview adds practical limitations: default thresholds need tuning, model probabilities can vary between repeated requests, and a returned step-up decision does not implement the verification flow for the application. The same overview lists no built-in shadow mode.
These are consequential gaps for fraud operations. A slightly different probability near a threshold can change whether a legitimate customer completes an order. An attractive benchmark needs to be weighed against the review workload and the cost of incorrect blocks.
Kairos makes a useful architectural idea concrete: let agents help maintain the machinery around a decision, while keeping evidence and approval visible. The test will be whether teams can improve that machinery faster without allowing the automation to hide the judgment involved.
I'm Paras. I work at the intersection of AI, engineering and distribution.
I help technical founders explain product launches and engineering decisions in stories that developers and founders want to read and share.