Frequently asked questions.

On your own infrastructure. It ships as containers and comes up alongside PostgreSQL and NATS on your servers or in your cloud account. Onboarding support is included in the licence.

It doesn't. Enrichment signals — disposable email providers, datacenter IP ranges, country and carrier data, sanctions lists — are read from lists held inside your infrastructure. No per-transaction call goes out. The only outbound traffic is the periodic list refresh, which pulls the list and carries nothing about which customer matched what.

The one exception, if you turn it on, is the AI assistant: the question you ask and the rows the model reads to answer it go to the provider you chose. It is off by default, you supply the provider and the key, and if nothing may leave at all you can point it at a model you run yourself.

One: PostgreSQL. Decisions, cases, rules and configuration sit in a shared schema; the event data each organisation loads sits in a schema of its own. The same database carries both.

We do not stand a separate analytical database beside it, because the question a velocity rule asks is not an analytical one: "how many times has this card in the last 24 hours" is not a scan of millions of rows but a narrow slice of one customer. It is served by partial indexes over the live rows — and those indexes are derived from the published rules on their own: publish a new velocity rule and the index it needs arrives with it.

No. You define your own data model in Krino and send your events as they are. Field names stay as you named them; there is no translation into somebody else's schema.

No. A rule is a condition tree built on screen: pick the field, set the comparison, give it a score. Engineers are only needed for the initial integration.

The analytics screen shows how often each rule fired and how often it actually changed an outcome. A rule that fires constantly but is never decisive is adding noise to every score. The same screen lets you move a threshold and see how past decisions would have landed.

Three ways. Fill a sample spreadsheet with your own records and upload it to see the outcome per row. Run the draft version as a shadow over live traffic — it influences nothing, but lists every transaction where it disagreed with the live version. Or run the rule straight against last month's real transactions: against closed cases whose answer you already know, each record judged as of the moment it arrived. It answers without waiting a month, and writes nothing — no decision, no case, no notification.

Yes. Every decision is stored with the field values of the moment and the scores of the rules that fired. Open it months later and the picture is the picture from that day, even if the rule has since changed.

You put two versions side by side: rules added, removed and changed, the before and after of every field, the thresholds and the trigger condition. Rule conditions are shown as sentences rather than JSON — two JSON blocks side by side are a comparison nobody actually reads. For "who approved this", publishing can be split into two steps: one person requests, another reviews and publishes, and the requester cannot approve their own request.

Two things: it answers questions about decisions, rules and cases in plain language, and it turns the same question into a table and a chart. The model is the one you choose — OpenAI, Anthropic, Google Gemini, or any OpenAI-compatible endpoint, including a model you run on your own servers. The key is yours and so is the bill; there is no account bundled into the product. Details: AI assistant.

No. It has no write capabilities: it cannot close a case, publish a rule set or change a setting. What it reads is our own records — decisions, rule evaluations and cases; the event tables you send are not on the list. Every turn is also written down: the question, the answer, the sources read, the model and the tokens spent.

Yes. A screen streams decisions as they are recorded: outcome, score, scenario, customer and the case opened, if one was. Watching the first minute after a publish tells you now what the dashboard will say in half an hour.

It is a sample, not a system of record: if a busy minute brings more decisions than the screen can carry, it says so plainly, and you go to the decision search for the complete list.

Cases land in queues and are assigned automatically to whoever has the fewest open items in that queue. You can snooze a case to a future date; it returns to the queue on its own when the day comes. Assignment, an approaching due time and a breach are all notified to the analyst. And forty cases heading for the same outcome need not be opened one at a time: select them in the list and close, assign or tag them in one step — the second-approval rule still applies per case, and whatever could not be applied is reported with its reason.