Glossary
Terms, and what they mean here.
Every product in this field uses the same words slightly differently. Below is what each one means specifically inside Krino.
Decision engine
How a decision is built.
Scenario
A set of decisions bound to one event type. It determines which data table is read, under what conditions it runs, and which queue the outcome reaches.
Iteration
A scenario's rules and thresholds at a point in time. You work on a draft; publishing makes it live and keeps the previous one on record.
Rule
A condition tree and a score. If the condition holds, the score is added to the total. Scores can be negative — a discount for a trusted customer, for instance.
Trigger condition
The pre-filter deciding which events a scenario runs on at all. If you do not want to evaluate cancellations, they are excluded here rather than in a rule.
Threshold
The boundary turning a total score into an outcome. There are three: review, block-and-review and decline. Everything below is an approval.
Outcome
One of four answers: approve, review, block and review, decline.
Velocity rule
A count over a time window — how many distinct cards one device tried in 24 hours. It catches patterns invisible from a single transaction.
Shadow run
Running a draft version in parallel over real traffic without influencing any decision. It ends with a list of where it diverged from live.
Threshold simulation
Re-reading past decisions at new thresholds. Not a forecast — a replay of decisions already made.
Backtest
Running a draft version against records that really arrived in the past. Each record is judged as of the moment it arrived: velocity rules count the history before that record, not today's. Nothing is written.
Version diff
What changed between two published versions, on one screen: rules added, removed and changed, the thresholds and the trigger condition. Conditions are written as sentences rather than JSON.
Data and signals
What a decision feeds on.
Data model
The schema of the objects you send to Krino — tables, fields, types. Named the way you named them; no fixed schema to conform to.
Trigger object
The event that starts a decision: a payment, an application, a login attempt. Stored verbatim alongside the decision.
Pivot
The field decisions are grouped on — usually the customer number. Decisions sharing a pivot value collect into the same case.
Device fingerprint
A stable identifier derived from what the browser reports. Cookies cleared or a private tab opened, the same device still appears under the same trace.
Datacenter IP
Address ranges belonging to hosting providers. Most VPN and proxy traffic exits here — not proof of anything on its own, but a signal.
Disposable email
Services offering addresses that vanish minutes after signup. Accounts opened with them show markedly higher chargeback and dispute rates.
Enrichment
Deriving new signals from an incoming event: whether the email is disposable, the IP's country, the phone's line type. In Krino, all of it offline.
List weight
A number carried by a list entry. The rule compares that weight rather than mere membership — gambling and groceries can sit in one list at different weights. No need to keep a separate list per risk band.
Prior decisions
A condition that looks not at what the customer sent but at what your organisation already decided about them: "how many times did we send this card to review this month". It appears in no transaction payload.
Investigation and compliance
What happens after a decision.
Case
The file that decisions requiring review collect into. Several decisions about one customer accumulate in a single case.
Inbox
The working queue cases land in. Different teams get different queues; assignment happens within a queue.
Snooze
Removing a case from the queue until a chosen date. It returns on its own when the day comes, so nothing is forgotten.
Four eyes
Work that cannot be completed on one person's decision. One proposes the outcome, the case stays open, and anyone except the person who asked can close it. The same rule can be set on publishing a rule set.
Entity annotation
A note or tag attached to a device, IP or card. It surfaces in the investigation every time that entity appears.
False positive
A transaction flagged, investigated and found clean. Unmeasured, its cost is invisible — every false alarm is an analyst's hour.
Sanctions screening
Comparing person and organisation names against sanctions lists, tolerating spelling, accent and transliteration differences.
PEP
A politically exposed person — someone requiring heightened scrutiny because of public office. Usually a reason to look, not a reason to decline.
Suspicious activity report
Reporting a case to a regulator. In Krino the reporting status, date and reference number live in the case's own record.
Audit trail
The record of who changed what and when — from rule edits to case notes, readable after the fact.
Let's see the concepts on screen.
Showing is easier than explaining — let's arrange a demo.