Three choices, three consequences.
What separates Krino is not a technical detail but three decisions made at the outset: who owns the rules, where the data sits, and whether a decision can be explained.
The rules belong to the risk team.
Nobody understands fraud better than the analyst looking at cases all day — not the engineer. In Krino that analyst writes the rule: composes the condition on screen, sets the score, tries it on a draft, publishes it.
From noticing to stopping
A new pattern spotted in the morning is live in the afternoon. No release plan, no backlog, no deployment window.
Who changed what, and when
Every published version is kept. Why a rule changed, who changed it, which version was running that day — all readable after the fact.
Tried before it ships
A draft version runs alongside live traffic and every transaction it would have decided differently is listed. Then you publish.
The data stays inside your organisation.
Krino runs on your own servers. Transaction, customer and device data never travels to another company — enrichment included.
Enrichment is local too
Disposable email providers, datacenter IP ranges, country and carrier data, sanctions lists — all read from lists held inside your infrastructure. No per-transaction call goes out, which settles both the privacy question and the latency one.
The lists stay current
A scheduled job refreshes them regularly. The refresh only pulls the list down; which customer matched what never leaves.
Every decision can be defended.
A decision has to hold up in three places: with the customer, with internal audit, and with the regulator. With nothing but a score, you struggle in all three.
Rule by rule
Which rules fired, what each contributed, where the total landed against the threshold — in the decision response.
With the data of the moment
The decision is stored with the field values as they were. Months later the picture is unchanged.
The investigation trail
Who picked up the case, what they wrote, how they concluded — in the file's own record.
Who Krino is right for — and who it isn't.
A good fit if…
- You have your own transaction and customer model that no fixed schema fits
- Data residency is a requirement, not a preference
- Your risk team wants to write the rules themselves
- You want fraud and AML in one system
- You have to show a regulator the reasoning behind a decision
Probably too much if…
- You process a few hundred transactions a month — reviewing by hand is cheaper
- Nobody can run a server and you don't want it hosted either
- What you actually want is the card network's own score
Let's see it on your data.
An anonymised sample is enough. We'll build your rules and put the results side by side.