Risk Scoring
For each subject screened against sanctions, PEP, and adverse media lists, Zyphe consolidates the matched signals into a single, normalized risk score and a categorical risk level. The scoring engine is fully configurable per organization, so each tenant can align the assessment to its own risk appetite, regulatory perimeter, and internal policies.
Output
Every AML check produces, for each matched entity, a structured result that includes:
| Risk Score | Normalized integer percentage from 0 to 100 |
| Risk Level | Categorical band derived from the score: Low, Medium, High, or Critical |
| Sources Count | Number of independent data sources that contributed to the match |
Risk levels
The percentage score is mapped to a risk level using fixed thresholds. The level is what most reviewers act on; the percentage is what flow builder conditions and audit trails reference.
| Score range | Risk level | Typical handling |
|---|---|---|
0 – 25 | Low | Auto‑approve, log for audit |
26 – 50 | Medium | Auto‑approve with monitoring, or light review |
51 – 75 | High | Manual review by a compliance analyst |
76 – 100 | Critical | Block or escalate; requires senior review |
In the dashboard, risk levels are rendered as color‑coded badges so reviewers can triage cases at a glance.
How the score is computed
The score combines two families of signals: tag weights (the inherent severity of each matched topic) and contextual factors (multipliers that adjust the score based on jurisdiction, position, and relationship signals associated with the match).
In short:
- Each topic the entity matches (e.g.,
sanction,role.pep,crime.fraud) contributes a weighted severity to a base score. - The base score is adjusted by the contextual signals attached to the match — for example, a high‑risk jurisdiction or a senior government position increases the score multiplicatively.
- The result is normalized against the worst‑case configuration to produce a stable percentage in
[0, 100].
The full mathematical specification is part of Zyphe's internal algorithm documentation and is available on request for compliance review.
Configurable tag weights
A tag weight assigns a severity (a positive number) to a specific risk topic. The higher the weight, the more strongly a match on that topic pushes the score upward.
Zyphe ships with a curated set of global default weights covering the standard AML taxonomy — sanctions, terrorism, war crimes, fraud, PEP categories, regulatory warnings, and more. The defaults are designed to produce sensible scores out of the box for most organizations.
Each organization can:
- Override any default weight to make a topic count more or less heavily.
- Add custom tags that are unique to the organization (for internal classifications that aren't part of the global AML taxonomy).
- Activate or deactivate any tag without deleting it, which is useful when temporarily excluding a signal from scoring.
Tag weights are managed from the Risk Tags page in the dashboard, under your organization's settings. The page lists every effective tag for the organization and indicates, for each row, whether it is a global default, a local override, or a custom entry.


Configurable contextual factors
A contextual factor is a multiplier applied on top of the base score when a specific contextual signal is present in the match. There are three types:
| Jurisdiction | Country‑level multipliers based on ISO‑3166 codes — applied when the entity's country, nationality, or country of birth matches a configured factor |
| Position | Multipliers tied to roles or occupancies, such as senior government officials, security agency leadership, or judicial figures |
| Relationship | Multipliers tied to relationship topics, such as a person being linked to a sanctioned entity or sitting on the board of a shell corporation |
As with tag weights, Zyphe provides global defaults covering the most common jurisdictions, positions, and relationship classes. Organizations can override any default factor or disable factors that don't apply to their use case. Contextual factors are managed from the Risk Contextual Factors page.


Both tag weights and contextual factors follow the same precedence model: organization‑level configuration takes priority over global defaults. When you create an override, the global default is preserved and shown alongside the override so you always have a reference point.
Assigning custom risk tags from a flow
Beyond the screening provider's output, your verification flows can attach custom risk tags to a specific result — for example to mark a subject who failed a manual document check as carrying additional internal risk. Custom tags assigned this way are folded into the next risk score computation for that flow result, using the weights configured for the organization.
This is configured with the Assign Risk Tags action node inside the flow builder. The action takes one or more custom tags previously defined on the Risk Tags page and persists them on the flow result.
Using risk scores in flow builder conditions
The flow builder exposes the AML risk score as a condition input. You can branch a flow based on the percentage value with operators such as greater‑than, less‑than, or equals — which lets you encode policies like "send to manual review if score ≥ 60" or "auto‑reject if score ≥ 85" directly in the flow definition, without writing custom code.
Where risk scores appear in the dashboard
Risk scores are surfaced wherever AML results are reviewed:
- Flow result detail — the AML section lists every matched entity with its risk level, match score, and topic tags, plus a moderation status (Under Review, Approved, Rejected, Escalated).
- Entity detail view — clicking through an entity shows the risk score percentage, risk level badge, the originating sources, the field‑level controls, and the audit trail of moderation actions.
- Case management — risk levels drive sorting and filtering of flow results so reviewers can prioritize the highest‑risk cases first.
Programmatic access
Risk scores, levels, and the underlying matched signals are available through the Zyphe REST API as part of the AML result payload. They are intended for integration with internal compliance systems, BI tooling, and case management workflows.
For privacy reasons, AML results — including risk scores — are not included in webhook payloads. Integrators that need risk data programmatically should call the AML result API directly using the flow result identifier delivered via webhook.
All inputs to the score (matched topics, jurisdictions, positions, relationships, and any custom tags assigned via the flow builder) are persisted alongside the result so the score can be re‑explained and audited at any time.