Capability · Precision

Catch fraud without treating every customer like a suspect.

Use customer history, event-specific thresholds and noisy-rule analytics to understand unnecessary friction. Test changes before publishing, inspect the outcome and keep learning from validated reviews.

Context and policy before blunt thresholds
Overrides require a written reason
Backtesting and Monitor before live changes

Explore rule and policy controls → Workflows & human feedback

A false positive costs more than the lost transaction.

A score that looks “safe” on a dashboard still burns activation, support and analyst time when every borderline case lands in the same queue. Teams respond by loosening rules globally—then miss the next organised probe.

Rule analytics can highlight noisy rules. Event-scoped configuration and backtests help your operator decide which changes are worth evaluating.

Use known context without creating blind spots.

Read the diagram

Scoped risk and trust lists contain example IP, device, account, email and payment-method references. List influence is configurable. A risk-list match is not universally a block, and a trust-list match is not a universal exemption. Evaluate the relevant event policy and the other findings.

Give genuine customers the benefit of context.

Use history, targeted policies and reviewed outcomes to challenge unnecessary friction.

Good-customer decision trace

Customer & history context Prior outcomes, account age and linked entities inform the score—when you map them.
Policy thresholds Review and block cutoffs differ by event type so low-risk journeys are not treated like high-risk ones.
Human override with reason Reviewers can approve or block with a written reason that stays on the decision record.
Outcome feedback Validated outcomes and tags return to the record so lists, rules and review appetite can be adjusted deliberately.

What this looks like in practice

Returning payer trips a velocity rule

A known account hits a payment velocity rule after a travel week. Contribution shows the rule and the list match; the resulting rule and anomaly scores fall into the configured review band rather than block.

Known account
Travel week activity
Velocity rule fires
Review band

Response: Approve with a written reason
Evidence: Rule contribution, list match and anomaly score stay attached for later rule tuning

The customer is not permanently treated as a stranger—and the rule remains auditable.

Data and configuration matter

Use policies, reasoned overrides and outcome tagging to identify unnecessary friction. The improvement you achieve depends on data quality, traffic mix and risk appetite; no reduction percentage is guaranteed.

Risk appetite

Three different controls. Three different questions.

Making every rule stricter is not the same as changing when you block. A trusted identifier should not automatically excuse every future action either.

SENTR separates rule sensitivity, decision thresholds and list influence. That gives your operator a more precise way to adapt policy to the event, market and fraud problem.

SENTR policy-group editor with separate model-score review and block threshold fields. — **Set the point where attention becomes action**
Review and block cutoffs are configured separately. Displayed values are demo settings, not recommended thresholds.

Rule sensitivity, decision cutoffs and list influence answer different questions.

Go deeper: Risk appetite

Scoring profiles: what matches?: Adjust numeric thresholds inside rules for an event type—for example, the domain-age threshold in a registration rule. Binary conditions have no numeric threshold to shift.
Decision policies: when do we act?: Set review and block cutoffs, with rule scores and model scores on separate axes. A login and a withdrawal do not need the same appetite. Action policies separately define cases, notifications and webhooks.
Scoped lists: how much should this matter?: Set the influence score for an attribute or entity match. Add entries from profiles or in bulk, export them, and disable lists without deleting them. Keep a known customer from becoming a blanket exemption for a suspicious new session.

Change the control that is causing the problem—not the risk appetite of the whole business.

Make every review—and every rule—earn its place.

Inspect the controls, then design a comparison that tests customer friction alongside fraud outcomes.

Plan a false-positive evaluation → Inspect workflows

Or Book a Session