On your own infrastructure. It ships as containers and comes up alongside PostgreSQL, ClickHouse 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.
PostgreSQL holds the transactional side: decisions, cases, rules, configuration. ClickHouse carries the event data you load and the analytical queries — milliseconds instead of seconds over millions of rows. Keeping them apart stops a heavy dashboard from slowing the decision path.
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.
Integration
How does it connect to my system?
The technical connection is two endpoints: POST /api/ingestion/{type} where you send events, and POST /api/decisions where you ask for a decision. Authentication is an X-API-KEY header. An afternoon is enough; the real time goes into getting your rules right.
Tens of milliseconds in a typical scenario. Because enrichment is offline there is no external wait; what drives the number is rule count and the width of your velocity windows. Every response reports how many milliseconds that decision took.
Send events separately and receive the outcome over a signed webhook. Webhooks follow the Standard Webhooks format with HMAC-SHA256 — verification is a few lines.
Yes. There are single-record, multi-record and CSV endpoints. Loading your historical data and trying your rules against it is the fastest way to validate before going live.
Day to day
Living with it.
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.
Two ways. Fill a sample spreadsheet with your own records and upload it to see the outcome per row. Or run the draft version as a shadow over live traffic — it influences nothing, but lists every transaction where it disagreed with the live version.
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.
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.
Commercial
Price and contract.
The self-hosted licence is $1,499 per month. One plan, all modules included, no per-transaction fee. Details on the pricing page.
No. The licence is flat and independent of transaction, decision and user counts. The only thing that grows is your own server cost.
Yes. Send an anonymised sample; we'll set up an evaluation environment, run your rules, and put the results next to your current process.
We accommodate code review requests in enterprise evaluations. Let's discuss the scope.
Didn't find your answer?
Write directly — the same address handles technical and commercial questions.