Risk-based approaches to AML and KYC compliance appear throughout FinCEN regulatory guidance going back more than a decade. The concept is not new, and it is not a loophole. The Financial Action Task Force (FATF) Recommendation 1 explicitly calls for countries to apply a risk-based approach to combating money laundering and terrorist financing, and FinCEN's own BSA examination procedures describe a risk-based framework as the expected standard for covered institutions.
The fact that most KYC vendor implementations do not actually implement risk-based verification is not because the regulators oppose it. It is because building a system that routes sessions differently based on risk signals is harder to sell as a product than a system that runs the same checks every time. One has a simple per-check pricing model. The other requires your customer to think about what their risk segments actually look like.
What Risk-Based Verification Is Not
Risk-based verification is not a license to do less verification. It is a framework for ensuring that verification depth is proportionate to the risk level of the specific customer and transaction. In practice, this means some applicants get more thorough verification than a flat policy would impose, not fewer checks across the board.
A risk-based program requires you to identify your high-risk customer categories and ensure they receive enhanced due diligence, not just basic document verification. High-risk categories typically include politically exposed persons (PEPs) and their close associates, customers from jurisdictions with elevated money-laundering risk ratings, customers whose stated business purpose is inconsistent with their transaction profile, and customers requesting account types with higher value transfer limits.
The risk-based framework makes your verification program more demanding for these categories, not less. The reduction in friction happens for the customers whose risk profile genuinely warrants a lighter touch. Getting this backward and using "risk-based" as a justification for doing less everywhere is a compliance failure, not a compliance strategy.
The Signal Set for Risk Scoring
A practical risk scoring model for onboarding identity verification uses inputs that are available at the point of application, before any checks have run. The goal is to score the session before selecting which checks to run, so that the check selection itself reflects the risk assessment.
The most reliable signals we have found to be meaningful in a pre-verification risk model:
Document region and document type. A domestic government-issued driver's license from a state with strong issuance controls presents a different forgery risk profile than an international passport from a jurisdiction with historically weaker document security controls. This is not a prejudice against applicants from certain countries. It is an acknowledgment that the technical difficulty of forging documents varies, and verification accuracy varies accordingly.
Device and network signals. A session initiated from a device with an established history on a residential network has a different fraud signal profile than a session from a fresh device on a datacenter IP range or a known VPN exit node. Neither is conclusive, but both are meaningful inputs to a risk model. The use of anonymizing network infrastructure by itself is not fraud evidence. Combined with other signals, it changes the probability distribution.
Session behavioral signals. Scripted or automated sessions often have timing signatures different from human-paced interaction. Form fill sequences where all fields are populated in near-zero time intervals, or where the interaction timing follows machine-regular patterns, are weak indicators of non-human sessions. Strong form factors for these signals are when they co-occur with other anomalies.
Prior session history. A previous failed verification attempt on the same identity data, from a different device, is a meaningful escalation signal. A first-time applicant with no prior history is neutral. Repeat attempts after failures should trigger review routing, not automatic re-entry into the same check flow.
How to Structure a Two-Tier Routing Model
The simplest practical implementation of risk-based verification is a two-tier model: standard verification and elevated verification. The complexity and data requirements of sophisticated multi-tier models often exceed what a growing platform can operationalize, at least initially.
Standard verification: document verification required. Liveness optional, triggered by specific signals. Processing within the automated pipeline. Accounts approved or soft-declined automatically.
Elevated verification: document verification required. Active liveness required. Sanctions and PEP screening required. Manual review queue for sessions that do not clear automated checks at a defined confidence threshold. Accounts held pending review before activation.
The routing criteria between tiers should be documented in your written CIP procedures. Every session should have a record of which tier it was assigned to and why, using the signal values that were present at routing time. This documentation is what an examiner reviews to confirm that your written procedures are being followed in practice.
The Calibration Problem
Building a risk scoring model is straightforward in concept and genuinely difficult in practice. The difficulty is not technical. It is calibration: determining where to draw the boundary between standard and elevated tiers such that you are catching the right proportion of elevated-risk sessions without generating excessive false positives.
If your elevated threshold is set too low, a large fraction of legitimate users gets routed into elevated verification, your manual review queue fills up, and the conversion benefit of the risk-based approach disappears. If your threshold is too high, genuine elevated-risk sessions slip through standard verification, and your fraud program has a gap.
The calibration should be driven by your fraud outcome data. Specifically: what signal values, or combinations of signals, were present in sessions that later turned out to be fraud? This requires closing the loop between your verification system and your fraud and loss data, which not every platform has instrumented properly at the time they build their KYC flow.
In the absence of your own outcome data (common for platforms in the early stages of building their fraud data set), there are two reasonable starting points. One is to use conservative published guidance from FinCEN and FATF on what categories of customers typically warrant enhanced due diligence, and use those categories as your elevated tier criteria. The other is to start with a simple rule-based model using the signals described above, and refine the weights as outcome data accumulates.
The Policy Change Problem
One underappreciated challenge in running a risk-based program is how to change the routing policy over time. Fraud patterns evolve. A signal that was predictive six months ago may be less predictive now. New fraud vectors emerge that your original signal set does not capture.
If your routing logic lives in your application code, changing it requires an engineering cycle and a deployment. This creates a lag between when your compliance team identifies a risk pattern change and when your verification system reflects it. In a fraud context, that lag is costly.
The structural solution is to externalize your routing policy from your application code. Your application provides session context to the verification system. The routing logic lives in the verification layer, where your compliance team can modify it without a deployment cycle. This is a compliance operations concern as much as a technical one: the people responsible for your fraud program need to be able to make policy decisions at policy speed, not at engineering release speed.
What Risk-Based Verification Does Not Solve
Risk-based verification is a framework for calibrating check selection to risk. It does not solve the underlying accuracy problem: if your document verification model has a false-positive rate of 3% on legitimate documents from certain regions, routing more sessions through document verification will not fix that. It will just generate more false positives at higher volume.
Risk-based routing improves efficiency and proportionality. Verification accuracy is a separate problem that depends on the quality of the underlying check models. The two are complementary, not substitutes. You want accurate checks and you want to apply them proportionately. Doing one without the other leaves money on the table, whether the cost is poor user experience from unnecessary friction or poor fraud detection from insufficient checks on high-risk sessions.