Decisions you can explain

We return a recommended_action, not a binary block. Exchanges and wallets map our risk levels to the actions that fit their jurisdiction and product: ALLOW (proceed normally), WARN (display risk warning), STEP_UP (extra friction such as 2FA, cooldown, whitelist delay), MANUAL_REVIEW (route to compliance queue), or BLOCK (prevent execution). Step-up options include address whitelist delays, mandatory re-authentication, cooling-off timers for new addresses, and reduced limits for high-risk users—so you can reduce risk without always saying no. Every decision is transparent and auditable: per request we return stable reason codes describing why risk was flagged, evidence pointers (transaction hashes, exposure paths), and confidence and severity levels. At the system level we provide public documentation of detection categories, versioned rulesets and model change logs, and known limitations. We support label provenance (internal, partner feeds, public lists, sanctions) with confidence scoring and timestamped history, and append-only decision logs with deterministic replay via decision_id and version metadata. That way compliance can trust the pipeline and you can explain every decision to users and regulators.

How we do it

• Recommended action is an enum: ALLOW, WARN, STEP_UP, MANUAL_REVIEW, BLOCK. We derive it from risk_score and internal policy (which we can tune per tenant). You map each action to your own UX: e.g. STEP_UP might mean “require 2FA” or “24h whitelist delay” or “reduce limit”; MANUAL_REVIEW means “queue for compliance”; BLOCK means “do not proceed”.
• Reason codes are a closed set of string identifiers (e.g. ADDRESS_POISONING, SCAM_CLUSTER, MIXER_EXPOSURE, HONEYPOT_TOKEN). Each detection path emits one or more codes; the response includes the set that contributed to the decision. Codes are documented and versioned so you can translate them into user-facing copy or compliance narratives.
• Evidence is a list of pointers: transaction hashes, address ids, cluster ids, exposure path summaries, contract addresses, model or rule version. We do not return raw PII or full graph dumps; we return enough for your team to look up the relevant chain data or replay the logic. Evidence is optional in the response (configurable) for performance.
• Decision logging: we emit a decision_id and model_version per response. You can log (request hash, decision_id, recommended_action, reason_codes) in your own append-only store. We optionally support server-side append-only decision logs (request/response or digest) for audit and deterministic replay; logs are retention-limited and tenant-isolated.

Outcomes

• •Five actions: ALLOW, WARN, STEP_UP, MANUAL_REVIEW, BLOCK—you map them to your policy
• •Stable reason codes and evidence per request; no opaque scores
• •Versioned rulesets, change logs, and known limitations documented
• •Append-only decision logs and replay for audit and compliance

Challenge

Compliance and support need to understand why a withdrawal was blocked or a deposit sent to review—without that, trust in the system erodes.

Approach

Every API response includes reason_codes and evidence. We document detection categories and version our models so you can point to a specific ruleset and explain the outcome.