Risk

One risk plane for accounts, payments and agents

Two faces over one engine, at two different stages. Available now — the compliance face, at api.hanzo.ai/v1/aml: monitoring, alerts, cases, rules, sanctions screening, relationship lookback and a retained-record clock. Coming soon — the decide plane, which will score an account, a transaction, a session or an agent and return a decision you can explain, from a model trained on your organization's own data rather than a pooled model of somebody else's traffic.

Where this is today

Hanzo Risk is two faces over one engine, and they are not at the same stage. The compliance face is live at api.hanzo.ai/v1/aml, behind your Hanzo identity: monitoring, alerts, cases, rules, sanctions screening, relationship lookback, and a retained-record plane that keeps a five-year clock.

Its source is public and every rule cites the instrument it implements, so what this page claims can be read back out of the code. It is not open source: the engine is licensed under the Lux Ecosystem License — free for research and on Lux networks, and licensed separately for commercial use anywhere else.

The decide plane — /v1/risk, everything else on this page — and the shared model plane behind both are being built. Every capability below says which of the two it is.

Available now: the compliance face

Anti-money-laundering monitoring is a different job from stopping fraud, and it is the half that is live. It is one face of the same engine, not a separate product.

Transaction monitoringAvailable now

Transactions are scored against the rule library as they arrive. An alert carries the rule that fired and the citation behind it — the authority, the document and the locator inside it — so a reviewer lands on the primary text instead of taking the alert on trust.

Rules you can readAvailable now

Twenty typology rules ship as a starting library, each citing the standard it implements. A candidate rule can be replayed over your own history, and the report is the difference between what it would have caught and what the live library catches — one replay at a time per organization. Activating a rule of your own belongs to the decide plane and is not here yet.

CasesAvailable now

An alert becomes a case with a timeline, and both are durable — they are there after a restart, and one institution’s volume cannot evict another’s. Closing a case requires a rationale, and the record keeps it: a resolution nobody can account for is not a resolution.

Sanctions screeningAvailable now

OFAC, UK OFSI, EU and UN designations, parsed from each authority’s own published export rather than a reseller’s copy of it. The freshness of every list is on the record.

Relationship lookbackAvailable now

Ask whether a business relationship with a named party is open now, or was open inside the last five years, and what its nature was. The answer is a lookup on that party in an index of relationship records, so what it reads does not grow with the ledger. It reads relationships and not transactions, which is a different question from the one the rules answer.

RetentionAvailable now

A retained record — a relationship, a transaction, the assessment behind a case, a refusal — carries its own five-year clock, started by the end of the relationship, by the occasional transaction, or by the refusal itself. Disposal runs daily and proves what it destroyed before it reports it. Alerts and case timelines are durable, and are not on that clock.

The customer lifecycle

Coming soon. Loss does not arrive at one moment, so the plane will not watch one moment. Same call, same record, same model at each stage — the stage is a field.

Signup and onboardingComing soon

Multi-account abuse, free-trial abuse, account sharing and account fraud, judged when the account is created. The device and pairing signals exist for exactly one question: are several nominally unrelated customers acting as one?

PaymentComing soon

Card testing, transaction fraud and bot-driven payment abuse, scored at authorization time. The hot path is meant to read velocity counters held in memory, not the warehouse, so a payment decision does not fail when analytics does.

Ongoing and post-purchaseComing soon

Pay-as-you-go abuse, negative balances and payout fraud, plus the disputes that arrive weeks later. A resolved dispute is a label, and the label goes back into the model that made the call.

What it decides on

Coming soon. Fraud is a use of a scoring plane, not a product that sits beside one. One call will judge an account, a transaction, a session or an agent.

AccountsComing soon

Score any account on the platform, at signup and continuously afterwards. Covers multi-account abuse, free-trial abuse, account sharing, account takeover and account fraud. A merchant on your platform is an account too, so onboarding and ongoing monitoring run off the same score.

TransactionsComing soon

Score a transaction at authorization and return an action, a score and the reasons behind it. Covers card testing, transaction fraud and payment abuse across whatever methods and processors you already use.

AbuseComing soon

Score the usage plane, not only the money: pay-as-you-go abuse, credential stuffing, scraping, quota abuse and spam. This is the plane that defends an AI product, where the loss is inference spend rather than a chargeback.

DisputesComing soon

Assemble what a dispute response needs — the decision, the rules that fired, the values behind it and the identity of the model that produced it — out of a tamper-evident record. Hanzo does not process payments and has no dispute-network integration; the evidence is yours to submit.

Your data, your model

Coming soon. The door your events already arrive through is live; reading that surface as features, and training on it, is what is being built.

Most fraud products score you against a pooled model built from other people’s traffic. Hanzo already holds yours. Analytics, product events and errors arrive through one door — POST /v1/event — and are stored as rows scoped to your organization, beside your model usage, in a warehouse Hanzo runs and every tenant shares. That door is live today. Reading that surface as features and training on it is what is coming: your users, your products, your normal.

The boundary is the hard part, and the commitment is that it will be enforced in the code rather than asserted in a policy. A feature read will not be expressible without a tenant. The organization will come from your verified identity, never from a field a caller can set. Anything shared across organizations will be an aggregate — published quantiles, with no organization, no subject and no identifier in the row — and a bucket too few organizations contributed to will not be published at all. The model is meant to be per organization down to its geometry, so that two organizations do not merely keep separate counters; they have separate models.

Two of the properties that plane needs are already in the engine’s behavioural model, and it is those that will be carried forward. A score there is attributable by construction: move one input back to its neutral value, score again, and the drop is that input’s contribution — no second model is asked to explain the first. And a statistical judgement may summon a person; it may not decline anything on its own, a ceiling the engine refuses to start above. On the live deployment that model runs in shadow: it scores, and it contributes nothing to any transaction’s outcome.

Agents are not bots

Coming soon. This is the argument for building the decide plane here rather than buying one, not a description of something running today.

A user-agent string cannot tell you whether traffic is a scraper or a customer’s agent doing work it was asked to do. The plane will not read one.

Hanzo runs agents. An agent transacting here has a registration in your organization, a credential of a known class, a live session and metered usage — four facts about our own platform rather than four guesses about a client. Traffic carrying them will be treated as an agent and get the agent policy. Traffic that declares nothing and authenticates as nobody will be in the anonymous lane and bounded like one.

Treating a customer’s agent as a bad bot is a lost sale. Treating a bad bot as an agent is a loss. The difference has to be computed, and computing it needs facts only the platform the agent runs on has.

Rules, lists and suppression

Coming soon.

Custom rulesComing soon

Write rules over your own fields in the same vocabulary the shipped library uses, and replay them over your own history before you turn them on.

ListsComing soon

Allow and deny lists over addresses, emails, accounts, card ranges, networks and devices, referenced directly from a rule. Your lists are yours; a designation from a sanctions authority is not editable by a tenant, and the two never merge.

SuppressionComing soon

Suppress an activation you have already judged. A suppressed hit is recorded as suppressed rather than dropped, because silence must never read back as a clean result.

Platforms and marketplaces

Coming soon.

If you run a platform, your risk is your sellers as much as your buyers. Risk will declare a control against a subject — hold a payout, set a reserve, restrict a merchant, block a suspect transaction — and the money plane will read it. Risk will never move money itself.

That separation is deliberate. The thing that decides and the thing that pays should not be the same thing, and a control that is a written record rather than a side effect is one you can still account for a year later.

How it connects

Coming soon. Risk will ingest signals and return a decision. Everything about how you take money stays where it is.

Keep the processor you haveComing soon

Risk takes signals and returns a decision. It never touches a processor, so nothing about your payment stack has to move and there is no migration to schedule.

Pure APIComing soon

One call from your own system: send what you know, get back an action, a score and the reasons. A signup, a payment, a session and an agent are the same call — the stage is a field, not a different endpoint.

Plans

Coming soon. Four tiers, each a subscription with screens included and metered beyond that on the Hanzo bill you already have. A screen is one decision about one transaction, account or customer. Nothing here is priced yet.

LiteComing soon

The smallest useful shape: screening on one stage, the shipped rules, and the record behind every decision.

StandardComing soon

The full lifecycle — signup, payment and post-purchase — with rules and lists of your own.

PlusComing soon

A model trained on your own event surface, with the search over model shape that finds which one to use.

ProComing soon

Platform and marketplace controls, the compliance face alongside the decide plane, and the retention that goes with it.

What this is not

Hanzo does not process payments — your processor does, and Hanzo Commerce owns the money plane. There is no dispute-network integration today: Risk assembles the evidence, you submit it. No figure on this page is a customer result, because the decide plane has not carried customer traffic yet. When it has, the numbers here will be ours and measured.

Three unmet requirements decide whether this is enough on its own, and they are named here rather than left to be found. There is no report workflow — no drafting, no approval step, no filing. There is no filing clock, so no deadline is measured anywhere. And there is no confidentiality marking on a case, so nothing in the engine keeps a case note away from a customer-facing surface. What is here is the detection and the record; the filing is not.

Anti-money-laundering compliance and fraud prevention are related jobs, not one job. /v1/aml is the compliance face, /v1/risk is the decide plane, and one engine serves both. Nearby: identity verification for proving who somebody is, Guard for what a model is allowed to say, and Analytics for the event plane the model reads.