Structuring a customer risk assessment that actually discriminates

Start from the decisions the rating is supposed to drive, and work backwards. In most programmes there are four: how much due diligence is required before and during the relationship, which monitoring rules and thresholds apply, how often the relationship is reviewed, and what has to be escalated for approval. If you cannot draw a line from each rating band to a specific difference in those four, the bands are labels rather than a model, and no amount of factor engineering will fix that.

Choose factor families you can defend

A risk-based approach requires the institution to justify its own factors against its own business, not to adopt a list. That said, most defensible models draw from the same families, and it is worth being explicit about what each is actually measuring:

Customer type and legal form

A natural person, a listed company, a private company, a trust, a partnership and a non-profit present different transparency and control questions. This factor measures how easy it is to know who you are dealing with.

Ownership and control complexity

Layers between the customer and its beneficial owners, cross-border ownership chains, nominee arrangements, and whether control follows ownership or diverges from it. Measure the structure, not just the count of owners.

Occupation, industry and business activity

What the customer does and how cash-intensive, agent-mediated or intermediary-heavy that activity is. This is also the factor that feeds the expected-activity profile monitoring will later compare against, so it is worth capturing in a coded vocabulary rather than free text.

Geography

Several distinct things that are often collapsed into one: country of residence, nationality, place of incorporation, operating footprint, and counterparty jurisdictions seen in actual activity. Collapsing them loses information, and the last one is the only one that updates itself.

Products, services and channels

What the customer holds and how they transact. Products differ in how easily value moves and how visible the other side is; channels differ in the assurance obtained at the point of interaction.

Relationship characteristics

How the relationship was established, whether the customer was met, whether an intermediary introduced them, expected duration, and the stated purpose of the relationship.

Adverse information

Confirmed screening outcomes and substantiated adverse media. The word confirmed is doing the work here — an unadjudicated potential match is a task, not a risk factor.

Observed behaviour

What has actually happened: alerts raised and their outcomes, prior investigations, prior reports. This is the family most often missing from the model, and it is the only one grounded in evidence rather than declaration.

Weighting is a policy decision, not a maths decision

There is no external source that will tell you how much more a complex ownership structure should weigh than a cash-intensive industry. That is a statement about your institution's risk appetite, it is owned by the people accountable for that appetite, and it should be written down as a decision with a rationale, approved, versioned, and given an effective date. Weights that live only in a configuration screen are weights nobody can explain the origin of a year later.

• Version the model, not just the weights. A rating produced in March under one weighting is not comparable to one produced in September under another unless you can tell which produced which.
• Record which model version produced each rating, on the rating. Otherwise the customer book is a mixture of vintages that nobody can separate.
• Keep the number of bands small enough that each band means something operationally. Five bands with three distinct treatments is three bands with extra steps.
• Decide what a missing input does before you need to. Treating absent data as low risk is the single most common way a model quietly stops discriminating.

Some outcomes should bypass the score entirely

A weighted score is a good way to combine ordinary factors and a poor way to handle categorical ones. Where the regime or the institution's own policy requires enhanced measures on a given finding, that requirement should be a mandatory trigger applied independently of the arithmetic — not a large number added to a total that some other combination of factors could offset.

• A confirmed politically exposed person match mandates enhanced due diligence directly, rather than contributing points. Note the word confirmed: the trigger is the adjudicated outcome, not the raw hit.
• Where the finding is that a match is confirmed but its subtype is not established, the conservative treatment is to record what is actually known and apply the enhanced requirement, rather than inventing a classification the evidence does not support.
• Institution-level prohibitions — customer types or jurisdictions the institution has decided not to serve — are policy gates, not risk factors, and belong before the model rather than inside it.

Every rating needs a date and a reason

A rating with no reason attached cannot be reviewed, and a rating with no date cannot be trusted. In practice a small set of events should each produce a new assessment, and each new assessment should record which event caused it:

• Onboarding — the initial assessment, from declared and verified information.
• Profile change — a change to the customer's own particulars, or an approved change to the due-diligence tier or monitoring segment they sit in.
• Screening outcome — an adjudicated match that changes what is known about the customer.
• Behavioural evidence — an alert whose investigation established something about how the relationship is actually being used.
• Periodic review — the scheduled reassessment appropriate to the current band.
• Event-driven review — a material external development, a lookback, or a referral.

Overrides should be rarer than you expect

Manual overrides are legitimate and necessary: no model captures everything, and an experienced officer who knows the relationship sometimes knows better. But an override is always one of two things — a factor the model is missing, or an exception to policy — and the difference matters. Track the override rate, by factor and by officer. A factor that is overridden in a large share of cases is telling you it is wrong, not that the officers are.

• Require a reason from a governed list, plus a free-text justification, for every override.
• Require a second approver for overrides that reduce a rating, and consider requiring one for increases too, so that the control is about the change rather than about the direction.
• Give downward overrides an expiry, so an exception granted once does not become the customer's permanent state.
• Report override statistics to the same body that approved the model. They are the most direct feedback the model produces about itself.

Validating the model

A customer risk model is a model, and it should be tested like one. None of the following needs a data science function; all of them need the data to be in one place and someone to be accountable for looking.

1. 01Distribution

   Plot the book across the bands. If nearly everything lands in one band, the model is not discriminating, whatever its factor list says. Look at the distribution per segment as well as overall — a model can be well-spread across the book and flat within the segment that matters.

2. 02Back-testing

   Compare ratings against outcomes: where did the alerts, the escalations and the filed reports actually come from? A model that rates the customers who generate your reports as low risk is a finding, not a coincidence.

3. 03Stability

   Measure how much ratings move, and why. High churn with no corresponding events suggests the model is reacting to noise; total stasis in a live book suggests it is not reacting at all.

4. 04Data coverage

   For each factor, what proportion of the book has a real value rather than a default? A factor populated for a third of customers is not a factor, it is a rounding difference.

5. 05Downstream effect

   Confirm that the four decisions the model exists to drive actually differ by band in practice — not in the policy document, in the operational data.

Before you sign the model off

1. Each factor family is justified against this institution's business, not adopted from a template.
2. Each factor has a defined source, a coded vocabulary where possible, and a stated treatment for missing values.
3. Weights are an approved, versioned policy decision with a written rationale.
4. Mandatory triggers are applied outside the arithmetic and cannot be offset.
5. Each rating records the model version, the triggering event, the date, and the factors that drove it.
6. Re-assessment events are defined and are actually wired to produce assessments.
7. A later, weaker event cannot silently reverse a stronger evidenced finding.
8. Overrides require a reason code, a second approver, and an expiry where they reduce risk.
9. Distribution, back-testing, stability and coverage are reviewed on a defined cycle by a named owner.
10. Every band maps to a concrete difference in due diligence, monitoring, review frequency and approval.