The person who spots the pattern should write the rule.
In Krino a rule is a condition tree: you pick the fields, compose the comparison, set the score. No code, no deployment — the rules live above the data.
Scenario, version, rule.
Three concepts, all of them yours to control. The complexity matches your business, not the product.
Scenario
Bound to one event type — a loan application, a card payment, a withdrawal. It determines which table is read and who owns the outcome.
Version
The current state of the rules. You work on a draft while the live version is untouched; publishing swaps them and keeps the old one on record.
Rule
A condition tree and a score. If it fires, the score is added; if not, nothing happens. Thresholds turn the total into an outcome.
What can a rule look at?
Field comparisons
Equality, ranges, contains, empty, in-list — over the fields of your own data model, combined with nested AND/OR. They are the fields you named; you do not have to translate into somebody else's schema.
Velocity rules
Counts over a time window: how many distinct cards one device tried in 24 hours, how many applications came from one IP in ten minutes. Measure, window and threshold are all set on screen.
Lists and their weights
Allow and deny lists, country and BIN lists, and any custom list you maintain. Adding an entry does not mean changing a rule — the list lives on its own.
Risk is not always a yes or no: gambling is worse than electronics, which is worse than groceries. Give a list entry a weight and a rule compares that weight instead of the value — no need to keep one list per band and watch them drift apart.
Your own decision history
Every other condition looks at what the customer sent you. This one looks at what you did: "how many times have we sent this card to review this month".
It is a signal no transaction data contains, and it closes the feedback loop. A customer you have decided on twenty times is usually a frequent customer; one you have sent to review four times is not — and the two can be asked separately.
Derived signals
Whether the email provider is disposable, whether the IP is a datacenter egress, the phone's line type, whether a name resembles a listed one — each usable in a rule like any other field.
A list can now say what it holds.
Declare what a custom list contains — an IBAN, a crypto wallet address, a card BIN, an e-mail, a phone. From the moment it does, spacing, separators and letter case stop breaking matches.
Spacing, separators, case
A list holding TR33 0006 1005 1978 6457 8413 26 matches a record carrying the same IBAN written without spaces. A list holding an Ethereum address matches it whatever case it arrives in.
In base58, case is information
Bitcoin and TRON addresses are the exception the design protects: their case carries meaning, so it is preserved rather than folded. Two addresses differing only in case are two different addresses, and typed matching keeps them apart.
A malformed row no longer lands quietly
On import, a value the declared kind says can never match is refused with its reason — and the good rows still land.
Before, a malformed IBAN was stored silently and simply never fired. For a deny list there is no worse outcome: it looks populated.
The field and the list have to agree
The field a rule tests and the list offered to test it against are matched up. A wallet field is no longer offered a list of card BINs.
A list left untyped behaves exactly as it always has. That is worth saying plainly: nothing about the lists you use today changes.
Four outcomes, at thresholds you set.
The total score becomes an outcome. You set the thresholds and you decide what each outcome means downstream.
Approve
It goes through. Recorded, but nobody's time is spent on it.
Review
It goes through, but a case opens — the team looks afterwards.
Block and review
It stops and a case opens. A person makes the call.
Decline
It is refused. The reasoning is on record, ready for the dispute.
A rule is tried twice before it goes live.
The most expensive version of a new rule is the one that surprises you in production. Krino shows you two ways beforehand.
Against sample data
Download a sample spreadsheet, fill it with your own records, upload it back. For every row you see which rules fired, what they scored and what the outcome was. Nothing published is touched.
Against your own history
Run the rule over last month's real transactions — against confirmed cases, where the right answer is already known. Each record is evaluated as of the moment it arrived: velocity rules count the history that existed before that record, not the history that exists now.
This is the answer to "try the new rule on last month's fraud" without waiting a month. Nothing is written: no decision, no case, no alert.
Shadow run against live traffic
The draft runs in parallel over live traffic without influencing any decision. When the window closes you know how often it agreed with the live version, where it diverged, and in which direction. Then you publish.
Two people before it goes live
Optionally, publishing splits in two: one person asks, another reviews and publishes. Whoever asked cannot approve their own request.
Any edit to the draft after a request retires that request. Without it the control breaks in one move: somebody asks, the second person changes the rules and approves their own change — two different names, but only one person read what went live.
What changed between two versions
Rules added, removed and changed; the before and after of every field; thresholds and the trigger condition. The direct answer to an auditor asking what you changed last month.
Rule conditions are shown as sentences rather than JSON — two blocks of JSON side by side make a comparison nobody actually reads.
Let's build your rules.
Describe the checks you do by hand today; we'll set them up in a demo environment and show you.