Why Krino — Krino

First choice

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.

Rule list showing each rule with its score and description — **Rule engine** · built and scored on screen, no code

Second choice

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.

Third choice

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.

Fit

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.

muhammet.sahin@dakicksoft.com Pricing