Risk Scores Explained
Understand how VertexY computes scores, actions, levels, and reason codes.
The output you receive
Every assessment returns:
riskScore: number from 0 to 100action:allow,review, orblockrecommendedAction: the engine’s direct recommendationriskLevel:low,medium,high, orcriticalreasonCodes: machine-readable explanation listfeatureContributions: low-level diagnostic values
How the score is built
VertexY combines four major signal families:
- Graph Shared devices, IPs, payment fingerprints, and fraud-neighbor structure.
- Velocity Bursts, spikes, and repeated recent activity.
- Similarity Overlap with known bad or suspicious indicators.
- Contextual BIN, geo, timezone, address mismatch, country mismatch, and user profile mismatch.
The current scoring implementation weights them approximately as:
- Graph:
35% - Velocity:
25% - Similarity:
15% - Contextual:
25%
Weights are implementation details and may evolve. Clients should integrate against the response contract, not hard-code internal formulas.
Risk levels
lowUsually 0 to 30.mediumUsually 31 to 60.highUsually 61 to 85.criticalUsually 86 to 100.
Actions
allowProceed normally.reviewHold for analyst review or step-up verification.blockStop the transaction.
action is influenced by both score and policy mode.
policyMode versus recommendedAction
recommendedActionis what the engine itself thinks should happenpolicyModecontrols how that recommendation is applied for your tenantactionis the final value your application should act on
Example:
- in
hybrid,actionusually matchesrecommendedAction - in
advisory, the engine still scores but your policy may reduce enforcement - in
shadow, the engine scores while live business action stays permissive
Common reason codes
You do not need to memorize every code. In practice, they fall into a few simple groups:
Threat and graph signals
GLOBAL_INDICATOR_MATCH: one or more identifiers matched known global threat intelligence.BLACKLIST_OVERLAP_HIGH: the transaction shares a strong overlap with suspicious or blocked indicators.ONE_HOP_GUARD_TRIGGERED: the user is directly connected to a risky fraud neighbor in the graph.
Velocity and behavior signals
VELOCITY_ZSCORE_SPIKE: recent activity jumped well above the normal baseline for that entity.
Degraded or partial-signal responses
GRAPH_UNAVAILABLE: graph data could not contribute to this decision.REDIS_UNAVAILABLE: velocity or cache-backed signals were temporarily unavailable.BLOOM_UNAVAILABLE: a bloom-filter or threat-intelligence lookup could not contribute.GDS_SCORES_UNAVAILABLE: precomputed graph-science scores were not available.ML_INFERENCE_UNAVAILABLE: the ML probability subsystem did not contribute.CONTEXTUAL_UNAVAILABLE: contextual checks could not be computed.
Policy-mode markers
POLICY_MODE_ADVISORY: the response was produced while your tenant was in advisory mode.POLICY_MODE_SHADOW: the response was produced while your tenant was in shadow mode.
Treat reason codes as explanation hints, not as a strict ranking. The safest way to automate decisions is to use action, recommendedAction, riskLevel, and riskScore together.
Reading featureContributions
featureContributions is a diagnostic object. It may contain:
velocity_zscoreBurst intensity compared with the historical baseline.indicator_overlap_ratioThe overlap ratio with suspicious indicators.graph_neighbor_ratio_n2The concentration of risky users in the two-hop neighborhood.graph_global_penaltyPenalty added from global threat evidence.contextual_scoreScore contribution from contextual mismatch checks.ml_fraud_probabilityFraud probability produced by the ML subsystem.knn_fraud_similaritySimilarity to nearby fraud embeddings.
These values are primarily for:
- observability
- analyst tools
- model debugging
They are not guaranteed to be stable across engine versions.
Degraded mode
If some dependencies are down, VertexY still returns a decision whenever possible.
In degraded scenarios:
reasonCodeswill include subsystem degradation signalsactionmay be raised to a safer floor such asreviewrecommendedActionstill reflects the engine result
Improving score quality
You will get better performance when you:
- ingest all supported event types
- keep user and device identifiers stable
- provide contextual data such as BIN, geo, timezone, and address country
- submit feedback consistently