RDS-HIVE
Decision-Integrity Framework
Why AML transaction screening generates excessive false positives — and a governance-first framework that separates WHAT to screen, HOW to interpret, and WHEN to validate.
The Core Problem
Transaction Screening Is
a Governance Problem - Not a Detection Problem
Despite decades of investment in rules-based systems, AI, and canonical data models, transaction screening continues to generate high false-positive rates and heavy reliance on manual review.
Why False Positives Persist
The dominant operational challenge in transaction screening is not missed detection — it is excessive screening scope driven by uncertainty in raw transaction data.
Faced with ambiguous free-text fields, partial identifiers, and unresolved abbreviations, institutions rationally adopt a defensive posture: screen everything that could plausibly matter. The result is excessive alert volume and unsustainable manual review burden.
"False positives are not primarily the result of inadequate matching logic or poor tuning. They are the consequence of uncertainty being pushed forward rather than resolved early."
RDS-HIVE addresses this at the root — by governing the three distinct decisions that traditional architectures collapse into one.
Unresolved Ambiguity at Ingestion
Free-text narratives, abbreviations, and partial identifiers in raw transaction messages create uncertainty that propagates downstream into alert storms.
Conflated Decision Points
WHAT to screen, HOW to interpret results, and WHEN to validate are three fundamentally different decisions — yet most architectures treat them as one pipeline.
Probabilistic Systems Without Governance
AI and LLM-based tools can inform screening decisions but must not authorize them. Without deterministic policy control, model risk is assumed away rather than managed.
Real-Time Payment Pressure
Accelerating payment rails reduce tolerance for manual intervention while regulatory expectations remain unchanged — exposing every weakness in decision governance.
The RDS-HIVE Framework
Three Governed Decisions.
One Defensible Outcome.
RDS-HIVE explicitly separates transaction screening into three distinct decisions, each with its own uncertainty, makers, and policy-aligned controls.
WHAT to Screen
The largest source of false positives arises before matching begins — at the decision of what elements of a transaction should be screened at all.
- →Preserves three parallel representations: RAW, Canonical, and Augmented
- →Multiple independent makers propose screening scope
- →Deterministic checker authorizes the final screening plan
- →Disagreement between makers surfaces as a signal of uncertainty
HOW to Interpret
Screening execution produces signals, not outcomes. Interpretation is a separate decision with its own uncertainty and controls.
- →Deterministic interpretation enforces non-negotiable policy constraints
- →Probabilistic models (including LLMs) add semantic clarity
- →No single maker's proposal is authoritative by default
- →Checker authorizes or blocks proposed dispositions (PAY / HOLD / ESCALATE)
WHEN / HOW to Validate
Validation is not universal. Governance requires validation effort to be proportionate to risk, confidence, and regulatory obligation.
- →No validation where confidence is high and no policy trigger exists
- →AI-based validation for consistency and rationale checking
- →Mandatory human review for defined high-risk scenarios
- →Decision finality is explicit, auditable, and policy-driven
What HIVE Means
Heterogeneous Independent
Verification Engine
A decision architecture in which independent contributors inform outcomes that only policy-aligned, deterministic controls can authorize.
HIVE Defined
Multiple representation types — RAW, Canonical, Augmented
No single maker is privileged or authoritative by default
Deterministic checker evaluates and reconciles all proposals
A governing architecture — not a model, not a detection technique
Probabilistic models inform. They do not authorize.
AI and LLM-based makers contribute contextual inference. Only deterministic, policy-aligned checkers can authorize outcomes.
Disagreement is a control signal, not an error.
When makers disagree, that disagreement is treated as a signal of uncertainty and resolved through explicit policy logic.
Auditability is preserved by design.
Every decision — screening scope, interpretation, validation — is explicit, traceable, and reproducible under regulatory scrutiny.
Real-time viability without relaxing controls.
Controls are placed where they are effective — resolving scope early and applying validation selectively without blocking payment flow.
What's Inside
18 Pages. Everything You Need
to Rethink Transaction Screening.
From executive summary to a fully worked MT103 free-text alert storm example, the whitepaper covers the complete governance architecture.
Representation-Diverse Screening (RDS)
Why no single representation of a transaction is sufficient to determine screening scope with confidence — and how preserving RAW, Canonical, and Augmented representations resolves this.
Maker-Checker Decision Architecture
How independent deterministic and probabilistic makers propose outcomes, and how a deterministic checker aligned to AML policy evaluates and reconciles those proposals.
Gateway vs. Name Screening Separation
Why non-negotiable indicators (jurisdictions, vessels, accounts) must be screened independently of entity name matching — and how KYC2020 implements this with configurable orchestration.
Regulatory Alignment: SR 11-7 & OCC
How RDS-HIVE aligns with Federal Reserve SR 11-7 model risk guidance — constraining model risk by design rather than assuming it away through narrative explanations.
Real-Time Payments Stress Test
Real-time payment systems don't create new financial crime risks — they expose weaknesses in decision governance. See how RDS-HIVE supports real-time operation.
Worked MT103 Example: Alert Storm Resolution
A complete walkthrough of an Iraq Power Plant transaction through RDS-HIVE — from FIRCO alert storm to governed PAY decision with full audit trail.
About the Author
Written by a Practitioner,
Not a Theorist
Rajeev Bahri
CAMS · CFA · CEO & Head of Product, KYC2020
Rajeev has spent over a decade building AML screening infrastructure for regulated institutions across 193 countries. As CEO and Head of Product at KYC2020, he leads product strategy for the DecisionIQ platform — trusted by 250+ compliance teams worldwide. RDS-HIVE reflects years of direct engagement with CAMLOs, compliance officers, regulators, and payment system operators confronting the real costs of over-screening.
Ready to Rethink
Transaction Screening?
Download the full RDS-HIVE whitepaper or speak directly with our compliance team about how KYC2020's DecisionIQ platform implements this framework.