Customer risk scoring

The customer risk score is where the risk-based approach stops being a policy and becomes a decision about one person or company. It decides who gets simplified, standard or enhanced due diligence, how often a file is reviewed, and which monitoring thresholds apply. A score that nobody can explain, or that rates almost everyone as low risk, fails supervisors and the firm alike.

From the enterprise assessment to the customer

The enterprise-wide risk assessment (see the lesson The risk-based approach) identifies the firm's risks by customer type, product, geography, channel and technology. The customer risk rating applies the same factors to each relationship. INR.10 groups risk factors under three headings: customer, country or geographic, and product, service, transaction or delivery channel. A crypto business adds a fourth that it can measure directly: on-chain behavior.

The output is usually a band (low, medium, high, sometimes prohibited) that drives:

• the depth of due diligence (see the lesson Enhanced and simplified due diligence);
• the periodic review cycle;
• monitoring thresholds and limits;
• who must approve the relationship.

Choosing factors and weights

Factors play two different roles. Scored factors each receive a value, typically on a scale of 1 to 5, and a weight, and the weighted values are added. Override factors set a floor or a ceiling regardless of the sum: a confirmed sanctions match makes the relationship prohibited, and a foreign PEP is never below high. Overrides exist because additive models dilute: one severe factor averaged with several benign ones produces a comfortable medium.

Weights should come from the enterprise assessment and expert judgment, be written down with their rationale, and then be tested against outcomes (see the governance section below). FATF does not prescribe a formula. It expects the method to be documented, proportionate and applied consistently.

Worked example

Ms. K, a fictional self-employed software developer resident in Country B, applies through the app, passes remote verification at the firm's standard assurance level, and declares expected deposits of about USD 20,000 a month from her existing self-hosted wallet and her bank account. Before activating crypto deposits, the firm screens the two addresses she says she will deposit from. One shows 8% indirect exposure to online gambling services, four hops away; neither has sanctions exposure.

With bands set at below 2.00 low, 2.00 to 3.20 medium and above 3.20 high, Ms. K is medium: standard CDD, a review cycle of two to three years, and the firm's standard monitoring thresholds.

Now change one fact: her second address received funds directly from a darknet market. The on-chain score rises to 5, and the total becomes 3.15, still medium. This is exactly the dilution problem. The firm's override table says that direct exposure to a darknet market or other illicit service above a set share of inflows forces at least high and triggers enhanced due diligence on source of funds. The override, not the sum, produces the right result.

The firm stores the score as a record that anyone can decompose:

{
  "customer_id": "C-31877",
  "model_version": "crr-2.4",
  "scored_at": "2026-10-02T08:15:00Z",
  "stage": "onboarding",
  "factors": [
    {"group": "customer", "weight": 0.35, "score": 2, "reason": "individual, no PEP, no adverse media"},
    {"group": "geography", "weight": 0.25, "score": 3, "reason": "residence rated medium"},
    {"group": "product_channel", "weight": 0.15, "score": 3, "reason": "fiat ramp, self-hosted withdrawals"},
    {"group": "on_chain", "weight": 0.25, "score": 3, "reason": "8% indirect gambling exposure"}
  ],
  "weighted_total": 2.65,
  "overrides_applied": [],
  "band": "medium",
  "next_review_due": "2028-10-02",
  "manual_adjustment": null
}

Each factor carries its weight, score and a plain-language reason, the model version is pinned, and overrides and manual adjustments have their own fields, so a reviewer can see what moved the band and why.

Blockchain analytics at onboarding

A crypto business can test a customer's story in a way a bank rarely can: by looking at the wallets the customer brings. Practical uses at onboarding:

• screen the addresses the customer declares, and every address that funds the first deposits, for direct and indirect exposure to sanctioned, illicit and high-risk categories;
• compare wallet age and history with the declared source of funds: a wallet "holding since 2017" that was first funded last month needs an explanation;
• feed the result into the on-chain factor and the override table, not straight into an automatic rejection.

A simple decision table keeps analysts consistent:

Small indirect exposure is common, because most active funds pass near something risky within a few hops, and analytics labels can be wrong or stale. The lesson Blockchain analytics for compliance covers exposure measures and their limits; the IDFE-BA course covers clustering and attribution in depth. Proof that the customer controls a declared address is covered in the lesson Unhosted wallets and self-hosted transfers.

Onboarding and ongoing scores

The onboarding score rests largely on what the customer declares. Once the account is active, the firm observes what the customer actually does, so the ongoing score should replace declared values with observed ones: real volumes against expected volumes, actual counterparties and exposure, alert history, and changes in geography or devices. Many firms treat the onboarding score as provisional and rescore automatically after the first 30 to 90 days of activity.

Reviews happen on two clocks:

• Periodic review, with frequency set by band, for example yearly for high risk and every few years for low risk; the firm sets and justifies the cycle.
• Trigger-based review, whenever an event suggests the risk may have changed: a material alert, a sanctions or PEP list hit, adverse media, a change of ownership or residence, use of a new higher-risk product, or reactivation of a dormant account.

A score that only moves on the calendar misses the events that matter most.

Calibration, governance and explainability

A scoring model is a model, and it needs the controls any model needs.

• Calibration: check the distribution across bands (if 97% of customers are low risk, the model probably cannot discriminate) and back-test against outcomes such as suspicious transaction reports filed, accounts exited and confirmed fraud. If most of those customers were rated low, the weights or factors are wrong.
• Sensitivity testing: change each weight within a reasonable range and see how many customers change band. Large swings from small changes mean the bands sit in the wrong place.
• Data quality: a missing occupation, country or expected volume must never default to the lowest score. Treat missing values as higher risk or block onboarding until they are completed, and report the share of scores built on incomplete data.
• Governance: a named model owner, a written methodology, version control, approval of changes by senior management or the compliance committee, and periodic independent validation by a function that did not build the model.
• Overrides: manual changes need a reason code and an approver, and downgrades need a more senior approver than upgrades. Override rates by analyst and by team should be monitored.
• Explainability: every score must break down into factor contributions a reviewer can read. If machine-learning models are used, the firm must still be able to show which features drove each result, because neither an examiner nor a customer complaint will accept "the model said so".

Exam focus: the INR.10 risk-factor groups and the on-chain factor a crypto business can add; scored factors versus override factors and why additive models dilute severe risks; computing a weighted score and band from a worked example; using wallet screening at onboarding as a factor rather than an automatic rejection; provisional onboarding scores and observed ongoing scores; periodic versus trigger-based review; calibration, back-testing and sensitivity testing; governance of overrides and explainability of every score.