Signal taxonomy v1¶

Defines standard signal types used across onboarding, AML, fraud, and risk systems. Signals are reusable, versioned, and explainable inputs into decision engines.

What is a signal?¶

A signal is an observed or derived fact about an entity, suitable for scoring, monitoring, and explanation. Signals are not raw CDC rows — they are produced by verification, screening, fraud, graph, and behavioural modules, and they carry metadata including severity, confidence, and production source.

Signals contribute to decisions but do not themselves change operational state.

Signal type families¶

IDENTITY¶

Signals derived from identity document verification, biometric checks, and identity data consistency checks.

Signal code	Meaning
`IDENTITY_VERIFIED_STRONG`	Identity document verified with high biometric confidence
`IDENTITY_VERIFIED_WEAK`	Identity document verified but below strong-confidence threshold
`DOCUMENT_BIOMETRIC_MISMATCH`	Facial or biometric comparison did not match presented document
`IDENTITY_DATA_INCONSISTENT`	Declared identity fields do not cross-validate (e.g. name, DOB, address conflict)

DEVICE¶

Signals derived from device fingerprinting, IP analysis, and emulation detection.

Signal code	Meaning
`DEVICE_FINGERPRINT_NEW`	Device not previously seen for this entity or linked entity group
`DEVICE_CLUSTER_RISK`	Device fingerprint associated with multiple distinct identities
`EMULATOR_DETECTED`	Session characteristics consistent with an emulated or virtualised device
`IP_HIGH_RISK`	IP address associated with known proxy, VPN, Tor exit node, or high-risk geography

SCREENING¶

Signals produced by sanctions, PEP, and adverse media screening modules.

Signal code	Meaning
`SANCTIONS_MATCH`	Entity name or identifiers returned a match against a sanctions list
`PEP_MATCH`	Entity identified as a Politically Exposed Person or close associate
`ADVERSE_MEDIA_MATCH`	Entity associated with adverse media relating to financial crime, fraud, or regulatory action

BEHAVIOUR¶

Signals derived from transaction velocity, pattern analysis, and session behaviour.

Signal code	Meaning
`VELOCITY_HIGH`	Transaction count or value exceeds expected velocity for entity profile
`PATTERN_ANOMALY`	Transaction pattern deviates materially from established baseline
`SESSION_RISK`	Session characteristics (timing, navigation, interaction cadence) indicate elevated risk

NETWORK¶

Signals derived from entity linkage, graph analysis, and shared attribute detection.

Signal code	Meaning
`LINKED_HIGH_RISK_ENTITY`	Entity is connected through the relationship graph to a known high-risk or sanctioned entity
`SHARED_IDENTITY_ATTRIBUTES`	Key identity attributes (name, DOB, address, phone) shared with another distinct entity in the system
`ACCOUNT_CLUSTER_RISK`	Account is part of a cluster that exhibits coordinated or suspicious behaviour

Signal design principles¶

Signals MUST carry a stable machine-readable code suitable for use in routing rules, analytics, and audit trails.

Signals SHOULD carry a severity level and a confidence score where the producing module can provide them.

Signals MUST NOT change operational state directly. Operational state changes occur only through the decision publication contract (see Data contracts and decision publication).

Signals are versioned. Changes to signal semantics that would affect existing consumers require a version increment.

Governance¶

Aspect	Owner
Signal taxonomy versioning	Head of Architecture
Signal production (identity)	MOD-009, MOD-010
Signal production (screening)	MOD-013
Signal production (risk/fraud)	MOD-039, MOD-040
Signal storage	MOD-043 (EventBridge), Snowflake `signal_raw` schema
Signal consumption	Decision engines in SD06 Risk Platform