What it does

Three kinds of operation are scored for fraud risk, every time they happen, in every Kademi account.

When someone places an order, redeems a voucher or registers on a site, Kademi runs a set of rules against that operation before it completes. Each rule that fires adds points to a risk score out of 100. Two thresholds turn that score into a decision: record it for review, or refuse it outright.

The three scored operations are purchases (including points redemptions through the store), voucher redemptions, and signups. Nothing else is scored.

Where to find it

Two pages in the admin console, under the Website Manager menu.

Fraud Prevention

The rules, their weights and settings, and the account's thresholds. Path /fraud/rules/.

Fraud Events

Every operation that scored at or above the recording threshold, newest first, with the rules that fired and what each one saw. Path /fraud/events/.

Intrusion Detection

Not a fraud page, but where an account configures what should happen beyond Kademi's own response — blocking an address, blocking a profile. Path /manage-idp/. See Escalating through IDP.

How scoring works

Points are added, not averaged. That is the design decision everything else follows from.

Each rule has a weight, which is the number of risk points it contributes when it fires as hard as it can. Some rules fire partially — the recently-created-profile rule decays over its window, so a profile made ten minutes ago scores nearly its full weight and one made twenty hours ago scores a fraction of it. The score is the sum of every rule's contribution, capped at 100.

Adding points rather than averaging them means a threshold you set today still means the same thing after the next release. If the score were an average, adding a twelfth rule would dilute every existing signal and silently move the goalposts. It also means a single rule rarely reaches the block threshold on its own — which is the point. Several weak signals agreeing is stronger evidence than any one of them, and it is what stops one unusual-looking order being turned away while a new account buying gift cards from a fresh IP address is not.

The three bands

A blocked operation is still recorded, which is why the block threshold can never be set below the recording threshold — the page will refuse the change rather than let blocked operations go unlogged.

When a rule breaks

If a rule throws an error or runs too long, it contributes nothing and is recorded as failed on the event. It is excluded rather than scored as zero, so a broken rule cannot quietly depress scores and become a silent bypass. A broken rule never blocks a transaction by itself.

The eleven rules

All shipped enabled. The weights below are the defaults an account starts with.

Other apps can contribute rules of their own. A rule that belongs to an app the account no longer has is shown as not runnable and scores nothing — worth knowing before reporting an account as quiet.

Tuning a rule

SET BY THE ACCOUNT

An account can retune and disable the rules it was given. It cannot rewrite what they look at.

Edit on any row opens the rule. Four things can be changed: whether it runs, its weight, its settings, and its wording. The edit panel shows the current block threshold next to the weight field, because a weight is only meaningful relative to the threshold it is trying to reach.

What cannot be changed

A rule's logic and the operations it applies to are code, and are not editable from the admin. This is deliberate: it means an account that has retuned one weight still picks up later improvements to that rule's query and description, because an account's change is stored as a difference from the shipped rule rather than a copy of it.

The three kinds of rule

The Customised tile on the rules page counts overrides and custom rules together — it answers "how far has this account drifted from what we ship?" at a glance.

Test rules now

Runs every rule against your own profile in the purchase context and shows what each one returned, without recording anything or affecting any customer. It is a check that the rules are wired up and running, not a simulation of a real transaction — with no cart behind it, the product and order rules have nothing to look at and correctly return zero.

Thresholds and blocking

SET BY THE ACCOUNT

Two numbers and a checkbox, on the rules page. The checkbox is the one that matters.

Record from	At or above this score the operation is written to the fraud events list. Default 30. Below it nothing is kept, so this number decides how much evidence the account accumulates.
Refuse from	At or above this score the operation is refused. Default 85, deliberately high — a score that only very likely fraud reaches. Cannot be set below the recording threshold.
Actually refuse transactions	Whether refusing really happens. Off by default. With it off, high-scoring operations are recorded and allowed through.

Turning blocking on starts refusing real customers immediately, they get no explanation, and nobody reports it — the people affected simply do not come back. The sequence under Turning blocking on exists so that decision is made against evidence.

Reading fraud events

The only honest evidence about whether the tuning is right.

Every operation that reached the recording threshold is listed newest first, with four tiles above it: how many were recorded, how many refused, how many allowed through, and the highest score seen. Each row shows when, the score, the operation, the profile, the address, and — in the Why column — every rule that fired with the points it added and what it actually saw.

What the patterns mean

• High-scoring events that were not refused. Either blocking is off, or the block threshold is above what real abuse actually scores. Both look like a working system from the rules page.
• One rule in almost every event. Either it has found the account's real problem, or it fires on ordinary behaviour and is inflating every score. Read what it saw in a few events before deciding. Do not raise the threshold to compensate for one noisy rule — that raises it for every other rule too.
• Repeated events for one profile or address. A pattern for one actor is a very different finding from the same total spread across many people, and it is the one to act on directly rather than by retuning.
• Nothing at all. Either the account has no abuse, or the recording threshold is above what anything reaches, or the operations that would be scored are not happening. Check how many rules are enabled and runnable before calling an account clean.

Turning blocking on

This is a real sequence, and the order is the whole point: the block threshold is calibrated against the account's own traffic before it is allowed to refuse anyone.

1. Leave it recording

   A new account is already scoring every operation with all eleven rules. Leave blocking off and let events accumulate — a few weeks of real traffic, including at least one busy period.

2. Read what scored highest

   Sort through the fraud events at and above the score you are considering as a block threshold. For each one, ask the only question that matters: would I have wanted this customer refused?

3. Retune what is obviously wrong

   If one rule is in nearly every event and its evidence looks like ordinary behaviour, change that rule rather than the threshold. For a velocity rule producing false positives, lengthen the window before raising the count — a family sharing a connection and an office behind one address both look like velocity.

4. Set the block threshold where the evidence puts it

   Not at the default because it is the default. At the score above which the recent events were all things you would refuse.

5. Turn blocking on, and watch the Refused tile

   From here the Refused count on the fraud events page is the number to watch. It should be small and it should be right.

6. Decide separately whether to escalate

   Refusing the transaction is as far as Kademi goes. Blocking the address or disabling the profile is a separate decision, configured in intrusion detection — see below.

Escalating through IDP

SET BY THE ACCOUNT, IN INTRUSION DETECTION

How an account goes beyond refusing the transaction — to blocking the address and blocking the profile.

Kademi's own response to a high fraud score is to refuse the operation and notify administrators, and nothing more. It does not disable the profile and does not block the address. That is a deliberate limit: those are heavier actions with real consequences for a legitimate customer, and the decision belongs to the account.

Fraud and intrusion detection are joined by a single one-way seam. Fraud announces a score and knows nothing about who is listening; intrusion detection remembers that score against the profile and the address, and exposes it as a metric its own rules can act on — using the blocking actions it already has. Fraud grows no blocking powers of its own, and IDP needs no knowledge that fraud exists.

Two thresholds, on purpose

The escalation threshold is usually the lower of the two, because the actions are reversible in a way a refused order is not — an address blocked for a day can be unblocked, while a customer turned away at checkout is simply gone. This is also why the score is normalised to 0–100: an escalation threshold is meaningless if adding a rule silently changes what a given number means.

Step one · define the metric

On Intrusion Detection → Metrics, add a metric and choose Fraud score. It takes a window, what to key on — the logged-in user, the client address, or the whole account — and whether to report the highest score in the window or how many scored events there were.

Step two · write the rule that acts on it

On the Rules tab, add a rule whose condition compares that metric against a number, and give it the actions to take. Add IP to known list adds the address to the blacklist, Temporarily block writes a timed access block, and Notify administrators raises it with a person.

Investigating with Copilot

The tuning problem — reading events and deciding what they mean — is exactly the sort of reading nobody gets around to. It is given to an agent.

Kademi's Account Security specialist can read and tune fraud prevention from the Copilot sidebar, anywhere in the admin. Ask it about fraud in your own words and it investigates: reads the events, reads the rules, breaks the pattern down by profile and address, and reports what it found and what it could not check.

What it can do

The specialist also carries a reference document on fraud tuning that it reads when the subject comes up — the judgement that is not in any tool description. Two things it is told, which show up in how it answers: read the events before touching anything, and turning blocking on is the administrator's decision, not yours. It will propose enabling blocking and say what it would have refused; it will not decide.

What an investigation looks like

Asked to investigate the account shown throughout this document, the specialist read the events and the rules, then drilled into the individual profiles it found:

Note what it does at the end: it lists the tools it used and states that nothing was changed. Asked to investigate, it investigated.

Why fraud and account security are the same specialist

Fraud scoring is about the operation; the specialist's other tools — login history, the audit trail, web traffic, orders, memberships — are about the person. The overlap is where the strong findings are. Fraud events for rapid orders, plus a login from a new country, plus an email change the day before, is an account takeover being cashed out, and no one of those three is worth acting on alone. Fraud events also carry the address, which is a lead the login history can follow: the same address across unrelated profiles is one of the strongest signals available in a Kademi account.

Roles and permissions

Two roles, granted at the organisation level.

FraudViewer	Can open both pages and read everything — the rules, the thresholds, the events and who was refused. Cannot change anything.
FraudManager	Everything FraudViewer can do, plus retuning rules, resetting them, and moving the thresholds. Can be granted on its own; it does not require FraudViewer as well.
Administrator	Reaches everything regardless, so an account that has granted neither role to anyone is not locked out of its own fraud settings.

The split is deliberate: being able to see which rules are in force is not the same as being allowed to move the threshold that refuses customers. Both roles apply at organisation level only — there is no website-scoped grant, because the rules and thresholds are account-wide.

What it does not do

Known limits of this version. Worth writing down so support answers do not have to guess.

• No challenge and no review queue. An operation is allowed or refused. There is no step-up verification, and no queue of held transactions for a human to approve.
• Rules cannot be written in the admin. An account can retune, disable and reset the rules it was given. A genuinely new rule needs an app to provide it.
• Refused customers get no explanation, and no self-service path. A refused order simply fails. Whoever handles support needs the fraud events page to find out why.
• Admin notification on a block is not wired up yet. The decision, the recorded event and the IDP signal are all in place; the notification to administrators on the block band is outstanding. Until it lands, an account learns about refusals from the events page, not from an alert. Escalation rules configured in IDP can notify.
• Fraud events cannot be filtered by date. The list is newest-first with a row limit. An agent asked about a 30-day window will say it cannot prove the returned events cover exactly that period — which it should, rather than implying it checked.
• Voucher redemption velocity counts vouchers, not redemptions. Right for a voucher redeemed once; an undercount for one redeemed repeatedly.
• Nothing is scored retrospectively. An operation is scored as it happens. Turning a rule on does not re-score history, and the events list only ever grows forward from when scoring started.

Words to use

The admin pages use customer-facing language rather than the internal names. Matching them keeps the documentation and the product saying the same thing.

Three sentences worth reusing

• "Every purchase, voucher redemption and signup is scored against these rules."
• "Each rule that fires adds its weight to the score, up to 100."
• "Kademi refuses the transaction and notifies administrators. Blocking the address or the profile is configured separately, in intrusion detection."