Techniques & Models - Risk & Compliance Analytics

The analytical methods available to risk practitioners have expanded faster than most risk functions have been able to adopt them. The result is a significant gap between what is technically achievable in risk analytics and what most organizations actually do. This article covers eight techniques that span the full maturity spectrum - from foundational statistical methods that every risk program should have in place to AI/ML approaches and third-party risk frameworks that represent the competitive frontier of the discipline.

Each technique is presented with sufficient depth to evaluate its applicability and implementation requirements, not as a survey reference but as a decision tool. For the KPIs these techniques produce, see Risk KPIs. For the data sources they require, see Risk Data Sources. For how to present the results, see Risk Dashboards.

1. Fraud Detection and Anomaly Analysis

Fraud detection is analytically distinct from other risk measurement disciplines because it is an adversarial problem. Fraudsters adapt to detection systems. A detection method that is effective today degrades as fraud patterns evolve to avoid it. Effective fraud analytics therefore requires a layered approach combining rule-based controls, statistical anomaly detection, and ML-based behavioral scoring.

Rule-Based Transaction Monitoring

Rules are the foundation of any fraud detection program. They are interpretable, auditable, and fast - essential properties for a control system that must operate in real time on high-volume transaction flows.

Core rule categories:

Velocity rules detect abnormal transaction frequency:

IF transaction_count(account_id, window_1_hour) > threshold_hourly THEN flag
IF transaction_amount_sum(account_id, window_24_hours) > threshold_daily THEN flag

Geographic anomaly rules detect impossible travel and location-inconsistent behavior:

IF location_distance(current_txn_country, prior_txn_country) > 500km
   AND time_delta(current_txn, prior_txn) < 2_hours THEN flag

Amount anomaly rules detect transactions inconsistent with account history:

IF transaction_amount > percentile_99(historical_amounts, account_id) * 1.5 THEN flag

Channel stuffing detection - a common form of revenue manipulation and insurance fraud - requires rules that look at aggregate patterns rather than individual transactions:

IF period_revenue_growth(channel, current_quarter) >
   percentile_95(historical_growth, channel, trailing_8_quarters) * 2.0
   AND channel_return_rate(current_quarter) > prior_quarter_return_rate * 1.3
THEN flag for investigation

Duplicate payment detection in accounts payable requires fuzzy matching logic:

SELECT a.invoice_id, b.invoice_id, a.vendor_id, a.invoice_amount
FROM invoices a
JOIN invoices b ON a.vendor_id = b.vendor_id
   AND ABS(a.invoice_amount - b.invoice_amount) < 0.01
   AND ABS(DATEDIFF(a.invoice_date, b.invoice_date)) <= 30
   AND a.invoice_id != b.invoice_id
   AND SIMILARITY(a.invoice_number_normalized, b.invoice_number_normalized) > 0.85

Statistical Anomaly Detection

Statistical methods identify transactions or patterns that are unusual relative to a reference distribution, without requiring pre-defined rules about what “unusual” looks like.

Z-score anomaly detection for transaction amounts:

Z_score = (X - μ) / σ

Transactions with |Z| > 3 (more than 3 standard deviations from the mean) warrant investigation. For right-skewed transaction distributions, use log-transformed amounts:

Z_score = (ln(X) - μ_ln) / σ_ln

Interquartile range (IQR) method for robust outlier detection that is less sensitive to extreme values:

Lower_fence = Q1 - 1.5 * IQR
Upper_fence = Q3 + 1.5 * IQR
Anomaly if X < Lower_fence OR X > Upper_fence

Benford’s Law is a particularly powerful technique for accounting fraud detection. In naturally occurring financial data, the probability of the leading digit d follows:

P(d) = log_10(1 + 1/d)

Expected proportions: 1→30.1%, 2→17.6%, 3→12.5%, 4→9.7%, 5→7.9%,
                      6→6.7%, 7→5.8%, 8→5.1%, 9→4.6%

Expense reports, journal entries, or vendor payments where first-digit distribution significantly deviates from Benford’s Law (tested with chi-square or Kolmogorov-Smirnov tests) indicate potential manipulation. This is a standard tool in GAAS-compliant fraud audits and is admissible as evidence of accounting irregularity.

Expense Compliance Monitoring

Expense fraud is among the highest-incidence internal fraud types. Key analytical approaches:

Policy violation detection uses structured rules against expense report data:

Amounts exceeding per-diem limits by category and location
Meals submitted without required attendee lists above threshold amounts
Weekend or holiday submissions inconsistent with business travel
Round-number amounts clustering (indicating fabricated receipts)
Merchant category codes inconsistent with stated expense category

Peer comparison analysis identifies employees whose expense patterns deviate significantly from peers with similar roles, geography, and travel frequency - a more sensitive detector than absolute policy limits alone.

2. Monte Carlo Simulation

Monte Carlo simulation quantifies risk by modeling the probability distribution of outcomes across thousands of simulated scenarios. Unlike deterministic analysis, Monte Carlo captures the full range of potential outcomes including tail events.

Core Methodology

The Monte Carlo approach to risk quantification follows these steps:

Define input variables and their distributions. Each uncertain input (default rate, recovery rate, loss severity, frequency of occurrence) is modeled as a probability distribution rather than a point estimate.
Specify correlations. Risk factors are correlated - credit defaults cluster during recessions; operational failures and market stress often co-occur. The correlation structure (typically a correlation matrix or copula) governs how simulated values co-vary.
Generate random samples. Draw N samples from the joint distribution of inputs. N is typically 10,000 to 100,000 for stable results.
Compute outcomes. For each simulation, compute the outcome (total loss, portfolio value, capital requirement) using the model equations.
Analyze the distribution. The empirical distribution of simulated outcomes produces VaR estimates, Expected Shortfall, and probability estimates for specific threshold breaches.

Operational loss Monte Carlo model:

For simulation i in 1..N:
  frequency_i ~ Poisson(λ)        // Number of loss events
  For each event j in frequency_i:
    severity_j ~ LogNormal(μ, σ)  // Loss amount per event
  total_loss_i = SUM(severity_j for j in 1..frequency_i)

VaR(99%) = Percentile_99(total_loss_i for i in 1..N)
Expected_Shortfall(99%) = MEAN(total_loss_i WHERE total_loss_i > VaR(99%))

Correlation implementation using a Cholesky decomposition:

L = Cholesky(Correlation_Matrix)
correlated_normals = L * independent_normals

Calibration and Validation

Monte Carlo results are only as reliable as their input calibration. Best practices:

Frequency calibration: Fit Poisson or negative binomial distributions to historical loss event counts. Test goodness-of-fit with chi-square tests.
Severity calibration: Fit LogNormal or Generalized Pareto distributions to historical loss amounts. Use maximum likelihood estimation.
Correlation estimation: Use historical data where available; supplement with expert judgment for tail correlations which historical data underestimates.
Back-testing: Compare model-predicted loss distributions against realized losses. A 99% VaR that is exceeded more than 1% of the time indicates model underestimation.

3. Scenario Analysis and Stress Testing

Stress testing complements Monte Carlo by analyzing specific, named adverse scenarios rather than a full probability distribution. Regulatory stress testing (DFAST, CCAR for banks; ORSA for insurers) requires scenario-based approaches by design.

Scenario Construction

Scenarios fall into three categories:

Historical scenarios replay known crisis periods with actual observed market movements:

2008-2009 global financial crisis: equity markets -55%, credit spreads +500bps, GDP -4%
2020 COVID shock: equity markets -34% (peak-to-trough), unemployment +10pp in 60 days
2022 rate normalization: 10-year Treasury yield +300bps in 12 months

Hypothetical scenarios construct internally consistent adverse narratives not represented in history:

Simultaneous cyber attack on top 5 counterparties
Pandemic-driven remote work failure affecting 60% of workforce
Supply chain failure of top 3 critical vendors

Reverse stress tests work backward from a defined failure outcome to identify the scenarios that would cause it:

Target: Capital ratio falls below regulatory minimum (10.5%)
Find: Combination of input shocks that produces this outcome

Reverse stress tests reveal the specific vulnerabilities that stress scenario analysis may miss.

Impact Calculation

For a credit portfolio stress test:

Stressed_Default_Rate(s) = Base_Default_Rate * (1 + macro_multiplier(s))
Stressed_LGD(s) = Base_LGD * (1 + collateral_value_decline(s))
Stressed_EL(s) = EAD * Stressed_Default_Rate(s) * Stressed_LGD(s)
Stressed_Loss(s) = Stressed_EL(s) - Expected_Loss_Reserve
Capital_Impact(s) = Stressed_Loss(s) / Tier_1_Capital

Where macro_multiplier(s) maps scenario macro variables (GDP growth, unemployment, credit spread widening) to default rate changes through a satellite model estimated on historical recession data.

4. Credit Risk Modeling

Credit risk modeling quantifies the probability that a counterparty will fail to meet its financial obligations and the expected financial impact if it does.

Probability of Default Models

Logistic regression remains the most widely used PD model for consumer and commercial credit:

logit(PD) = β_0 + β_1*FICO + β_2*DTI + β_3*LTV + β_4*Employment_Status + ...

PD = 1 / (1 + exp(-logit(PD)))

Key model performance metrics:

Gini coefficient: Measures rank-ordering power. A Gini of 0.70 or above is considered strong for consumer credit models.
Kolmogorov-Smirnov statistic: Maximum separation between default and non-default score distributions. KS > 40 is generally adequate.
Area Under the ROC Curve (AUC): AUC > 0.75 indicates good discriminatory power.

Model validation requires out-of-time testing: train the model on one period, test on a subsequent period. Models that perform well in-sample but degrade significantly out-of-time are overfit and will underperform in production.

Loss Given Default Estimation

LGD varies by collateral type, seniority, and recovery process:

LGD = 1 - Recovery_Rate
Recovery_Rate = f(Collateral_Type, LTV, Time_in_Default, Economic_Cycle)

LGD is typically estimated using beta regression (since recovery rates are bounded 0-1) or a two-stage model:

Stage 1: Probability of zero recovery (logistic regression)
Stage 2: Recovery rate given non-zero recovery (fractional logit or beta regression)

Portfolio Credit Risk: Expected and Unexpected Loss

Expected_Loss = PD * LGD * EAD
Unexpected_Loss = EAD * LGD * SQRT(PD * (1-PD))  // Simplified single-asset

// Portfolio UL (requires correlation)
Portfolio_UL = SQRT( SUM_i SUM_j (UL_i * UL_j * ρ_ij) )

Economic_Capital = VaR(99.9%) - Expected_Loss  // Basel III approach

5. AI/ML-Driven Risk Analytics

Machine learning is transforming risk analytics in ways that rule-based and classical statistical approaches cannot match. ML models can detect complex, non-linear patterns in high-dimensional data; they adapt as new labeled data is added; and they scale to transaction volumes that would overwhelm manual review. This is the area of greatest competitive gap in publicly available risk analytics content.

Anomaly Detection with Isolation Forests

Isolation Forest is particularly effective for fraud detection because it does not assume a parametric data distribution and scales efficiently to high-dimensional transaction data.

The algorithm works by randomly partitioning the feature space using random splits. Anomalies - transactions that differ significantly from normal behavior - require fewer splits to isolate than normal observations.

Anomaly_Score = 2^(-E[h(x)] / c(n))

Where E[h(x)] is the expected path length for observation x and c(n) is the expected path length for a random dataset of size n.

Observations with Anomaly_Score > 0.6 are candidates for fraud investigation; scores > 0.7 warrant automated holds pending review.

Feature engineering for transaction anomaly detection:

Effective ML fraud models require engineered features beyond raw transaction attributes:

Rolling transaction statistics (mean, variance, max) over 1h, 24h, 7d, 30d windows
Time-since-last-transaction by channel and merchant category
Deviation from personal spending profile (transaction amount / user’s typical amount)
Network features: shared device IDs, addresses, or phone numbers across accounts
Velocity features: number of new payees added in past 7 days

Gradient Boosting for Credit Risk

Gradient Boosted Trees (XGBoost, LightGBM) consistently outperform logistic regression on complex, non-linear credit risk data while maintaining reasonable interpretability through SHAP (SHapley Additive exPlanations) values.

# Model training
model = xgb.XGBClassifier(
    n_estimators=500,
    max_depth=6,
    learning_rate=0.01,
    subsample=0.8,
    colsample_bytree=0.8,
    objective='binary:logistic',
    eval_metric='auc'
)
model.fit(X_train, y_train, eval_set=[(X_val, y_val)], early_stopping_rounds=50)

# SHAP interpretation
explainer = shap.TreeExplainer(model)
shap_values = explainer.shap_values(X_test)

SHAP values provide per-observation feature attribution that satisfies model explainability requirements under ECOA (Equal Credit Opportunity Act) and similar regulatory guidance - a critical property for consumer credit ML models deployed in regulated environments.

Real-Time ML Scoring Architecture

Deploying ML models in real-time risk contexts (payment fraud, loan decisioning) requires a serving architecture distinct from batch analytics:

Feature store: Pre-computed aggregated features (customer spending statistics, network features) stored in low-latency key-value store (Redis, Feast). Real-time features are computed at inference time; historical features are read from the feature store.
Model serving: ML models deployed as REST or gRPC microservices (BentoML, Seldon, TensorFlow Serving) returning probability scores in under 50ms p99 latency.
Decision engine: Combines ML score with rule-based flags to produce a final risk decision. The decision engine is separate from the scoring model to enable rule updates without model redeployment.
Monitoring: Shadow scoring (running new models alongside production models without acting on their output) and champion-challenger testing (routing a percentage of traffic to new models) enable safe model updates.

ML Model Risk Management

Regulatory guidance (OCC 2011-12, SR 11-7 for banks; SOC 2 and SOX implications for public companies) establishes expectations for model risk management:

Model inventory: Every production ML model must be documented with purpose, inputs, outputs, limitations, and performance benchmarks.
Validation: Independent validation team must evaluate conceptual soundness, data quality, and performance on out-of-sample and out-of-time data before production deployment.
Monitoring: Production model performance must be monitored for accuracy drift, data drift (change in input distributions), and concept drift (change in the relationship between inputs and outcomes).
Documentation: SHAP or similar explainability outputs must be available for adverse action notices in consumer credit applications.

6. Third-Party and Vendor Risk Analytics

Third-party risk has become one of the fastest-growing risk domains as organizations have deepened their operational dependence on external vendors, SaaS providers, and outsourced services. Despite this, third-party risk analytics is among the least analytically mature areas in risk management, and published analytical frameworks are sparse. This represents a significant opportunity for organizations willing to invest in structured measurement.

Vendor Risk Scoring

A quantitative vendor risk score aggregates multiple risk dimensions for each supplier relationship:

Vendor_Risk_Score = w_financial * Financial_Health_Score
                  + w_operational * Operational_Risk_Score
                  + w_security * Security_Posture_Score
                  + w_concentration * Concentration_Risk_Score
                  + w_compliance * Compliance_Score

Where each component score is derived from measurable indicators:

Financial Health Score sources:

Commercial credit score (D&B Paydex, Experian Business Credit)
Days Sales Outstanding trend
Publicly available financial ratios (current ratio, interest coverage) for public vendors
Payment performance against your AP records

Operational Risk Score sources:

SLA breach rate: SLA_Breach_Rate = Breached_SLAs / Total_SLA_Obligations
Incident frequency: count of vendor-attributable operational incidents per quarter
Business continuity plan (BCP) and disaster recovery (DR) documentation quality
Audit right-to-examine exercise results

Security Posture Score sources:

External security rating services (BitSight, SecurityScorecard, RiskRecon)
Penetration test findings
SOC 2 Type II report findings and qualified opinions
Response time to security questionnaires (a behavioral proxy for security culture)

Concentration Risk Score:

Vendor_Concentration = Spend_with_Vendor / Total_Category_Spend
Critical_Dependency = 1 if Vendor_is_Single_Source else 0
Concentration_Score = (Vendor_Concentration * 0.6) + (Critical_Dependency * 0.4)

Portfolio-Level Third-Party Risk

Individual vendor scores need to be aggregated to portfolio-level metrics:

Portfolio_Concentration_HHI = SUM( (Spend_i / Total_Spend)^2 ) * 10,000

An HHI above 1,800 in a critical spend category (IT infrastructure, financial services, logistics) indicates dangerous concentration. Segment vendor portfolios by criticality tier:

Tier 1 (Critical): Vendors whose failure would cause immediate operational disruption
Tier 2 (Important): Vendors whose failure would cause significant process degradation
Tier 3 (Standard): Vendors whose failure can be managed through standard procurement

Tier 1 vendors warrant quarterly financial health monitoring, annual onsite assessments, and contractual BCP/DR requirements. Tier 3 vendors may be managed through automated financial scoring alone.

Vendor Risk Monitoring Automation

Continuous vendor risk monitoring is achievable at scale through API integrations:

Security rating services provide daily score feeds via API for continuous security posture monitoring
Commercial credit bureaus support monthly refresh pulls for financial health monitoring
News and event monitoring APIs (Factiva, LexisNexis Risk Solutions) can flag vendor adverse events (litigation, regulatory actions, leadership changes) in near-real-time
ESG data providers (Sustainalytics, MSCI ESG) provide environmental, social, and governance risk scores for supply chain ESG risk programs

7. Regulatory Compliance Automation

Manual compliance tracking - spreadsheets, periodic self-assessments, email-based attestation chains - is inadequate at the scale and frequency that modern regulatory environments require. Analytical automation of compliance monitoring transforms compliance from a periodic activity into a continuous monitoring function.

Continuous Control Monitoring

Automated control testing replaces periodic (quarterly or annual) manual testing with continuous validation against defined control criteria:

Segregation of duties (SoD) monitoring:

-- Detect users with conflicting access (create AND approve invoices)
SELECT user_id, COUNT(DISTINCT role_id) as role_count
FROM user_role_assignments
WHERE role_id IN (SELECT role_id FROM roles WHERE permission = 'CREATE_INVOICE')
   OR role_id IN (SELECT role_id FROM roles WHERE permission = 'APPROVE_INVOICE')
GROUP BY user_id
HAVING COUNT(DISTINCT role_id) >= 2
   AND EXISTS (SELECT 1 FROM user_role_assignments
               WHERE user_id = outer.user_id
               AND role_id IN (SELECT role_id FROM roles WHERE permission = 'CREATE_INVOICE'))
   AND EXISTS (SELECT 1 FROM user_role_assignments
               WHERE user_id = outer.user_id
               AND role_id IN (SELECT role_id FROM roles WHERE permission = 'APPROVE_INVOICE'))

Authorization threshold compliance:

-- Identify payments that bypassed required approval levels
SELECT payment_id, amount, approver_user_id, approval_level
FROM payment_approvals pa
JOIN payment_approval_matrix pam ON pa.amount_range = pam.amount_range
WHERE pa.approval_level < pam.required_approval_level

Regulatory Deadline Tracking

Regulatory filing deadlines must be tracked against actual submission dates:

Filing_Timeliness_Rate = COUNT(filings WHERE submission_date <= due_date) /
                         COUNT(filings) * 100

Days_Early_or_Late = submission_date - due_date  // Negative = late

Alerting on filing deadlines 30, 15, and 5 days in advance - with automatic escalation if preparation is not confirmed in the GRC system - reduces late filing penalties, which in regulated industries can be material ($10K-$1M per day for banking regulators; up to 4% of annual global turnover under GDPR).

Policy Attestation Automation

Policy attestation completion tracking is a foundational compliance metric:

Attestation_Completion_Rate = Completed_Attestations /
                              Required_Attestations_in_Period * 100

Overdue_Attestations = Required_Attestations WHERE
                       deadline_date < today AND completion_date IS NULL

Automated reminder workflows and escalation chains - triggered by days-until-deadline thresholds - significantly improve completion rates without manual follow-up overhead.

8. Enterprise Risk Quantification

Enterprise risk quantification translates the outputs of individual risk domain analyses into a unified financial representation of total organizational risk exposure - the analytical foundation for risk appetite articulation, capital allocation, and board-level risk reporting.

Aggregating Across Risk Domains

The central challenge in enterprise risk quantification is aggregation across domains that use different units, time horizons, and measurement approaches. The solution is to express all risk domains in common financial terms - expected loss and unexpected loss (economic capital) - and then aggregate with explicit modeling of cross-domain correlations.

Step 1: Translate each domain to an expected loss distribution.

Credit risk EL is calculated from PD, LGD, and EAD. Operational risk EL is estimated from historical loss event data using Monte Carlo simulation (see Technique 2). Market risk EL is derived from VaR calculations. Compliance risk EL estimates the expected cost of regulatory actions, fines, and remediation.

Step 2: Determine cross-domain correlations.

Credit and market risk are positively correlated (credit spreads widen in market downturns). Operational and compliance risk are positively correlated (process failures often generate regulatory findings). Use a correlation matrix derived from historical observations and expert judgment:

ρ = [ 1.0   0.4   0.2   0.3  ]   // Credit, Market, Operational, Compliance
    [ 0.4   1.0   0.1   0.2  ]
    [ 0.2   0.1   1.0   0.5  ]
    [ 0.3   0.2   0.5   1.0  ]

Step 3: Aggregate using copulas or correlation-adjusted VaR.

Simple correlation-adjusted portfolio unexpected loss:

Portfolio_UL = SQRT( SUM_i SUM_j (UL_i * UL_j * ρ_ij) )
Diversification_Benefit = SUM_i(UL_i) - Portfolio_UL

The diversification benefit quantifies the value of not being perfectly correlated across risk domains - a number that strengthens the case for managing enterprise risk holistically rather than domain by domain.

Step 4: Compare to risk appetite and available capital.

Risk_Appetite_Utilization = Portfolio_UL / Risk_Appetite_Capital_Allocation * 100
Excess_Capital = Available_Capital - Portfolio_UL - Expected_Loss

This comparison - enterprise risk quantification against available capital and defined appetite - is the deliverable that enables a CRO to have a precise conversation with the Board about whether the organization is taking too much risk, too little risk, or is within appetite.

Risk-Adjusted Return on Capital (RAROC)

RAROC enables risk-adjusted performance comparison across business units with different risk profiles:

RAROC = Net_Income / Economic_Capital

// Where Economic_Capital = Unexpected_Loss at 99.9% confidence

RAROC > Cost_of_Capital => Value-creating activity
RAROC < Cost_of_Capital => Value-destroying activity

Business units that generate high returns but consume disproportionate capital - and therefore show lower RAROC - are revealed as less attractive than their raw profitability suggests. RAROC is the metric that enables capital allocation decisions grounded in risk-adjusted economics rather than accounting profit.