Customer risk rating: how to score a business client, and what to do with the score

A customer risk rating is the single output that decides how much due diligence a client receives, how closely their payments are watched, and who has to approve them. Get it right and every other control points at the right accounts. Get it wrong and the programme spreads its effort evenly, which means it spends most of that effort on the wrong customers.

This article sets out what the rating is for, which factors belong in it, how to score them, what changes when settlement runs in stablecoins, and what a reviewer reads. It is general information for compliance and payments leaders, not legal advice.

What is a customer risk rating, and what is it not?

The rating is your view of the money laundering, terrorist financing and sanctions risk that one client relationship presents. FATF Recommendation 1 requires an institution to identify and assess its risks and then apply measures in proportion to them. The customer rating is where that proportionality becomes operational, one account at a time.

A rating should drive four decisions. It sets the depth of due diligence at onboarding, the monitoring thresholds and scenarios applied to the account, how often the file is refreshed, and the seniority needed to accept the relationship and to keep it. If a rating changes none of those four things, it is a label rather than a control.

Three things it is not. It is not the enterprise wide AML risk assessment, which looks at the whole book and sets the programme. It is not a credit or commercial rating, and it must never be adjusted for the revenue the client brings. It is not a sanctions decision: an ownership and control analysis either permits a payment or it does not, whatever band the customer sits in.

Which factors belong in a customer risk rating?

Four groups of factors cover almost every payment business. Annex III of Directive (EU) 2015/849 lists potentially higher risk factors in a similar structure, and the FFIEC BSA/AML Examination Manual expects a bank to consider the same ground.

• Who the customer is: legal form, industry, ownership structure and how transparent it is, whether a beneficial owner or controller is a politically exposed person, and any adverse media.
• Where they operate: country of incorporation, the jurisdictions they send to and receive from, and whether those sit under sanctions, capital controls or weak supervision.
• What they buy from you: product and channel, because a business sending scheduled supplier payments to two known beneficiaries differs from one making ad hoc payouts to changing counterparties.
• How they behave: expected volume, value, frequency and counterparties, captured in numbers at onboarding so that monitoring has something to compare against.

The fourth group is the one most often missing. A rating built only on static attributes cannot tell you when a customer has stopped being the customer you onboarded. Expected activity recorded as figures gives monitoring a baseline to test.

FinCEN's customer due diligence rule at 31 CFR 1010.230 requires a covered institution to identify each beneficial owner holding 25 percent or more of the equity interests in a legal entity customer, plus one individual with significant responsibility for control, and to maintain and update a customer risk profile. That is an input. The rating is what you do with it.

How should a customer risk rating be scored and weighted?

Two designs are common. A weighted score assigns points to each factor and sums them into bands. A matrix crosses a small number of dimensions, usually customer type against geography, and reads a band from the cell. Both work. What does not work is precision beyond what the inputs can support.

Four rules keep a score honest.

• Set the weights from your own risk assessment and write down the reasoning, so a reviewer sees judgement rather than arithmetic that appeared from nowhere.
• Let a single factor override the total. A sanctioned jurisdiction, or an ownership chain nobody can explain, is high risk no matter how low the rest of the score runs.
• Allow documented overrides in both directions, each with a named approver, a reason and a date, then report how many you issue. Frequent downgrades are a sign the model is miscalibrated.
• Keep the bands few. Three or four bands that genuinely change what you do beat nine bands that change nothing.

Averaging is the quiet failure. A client in a high risk corridor with opaque ownership can average down to medium once enough neutral factors are added. The override rule above is the mitigation, applied by the system rather than remembered by an analyst.

What does a stablecoin settlement leg change in the rating?

It changes the inputs, not the method. Some risks fall. A settlement leg on a public blockchain leaves a permanent, timestamped record of every movement, so the evidence behind a rating is stronger than a chain of correspondent banks can offer.

Other risks rise, and each deserves its own factor rather than one line labelled crypto.

• The asset and its issuer: which stablecoin settles the corridor, who issues it, and whether that issuer can freeze a balance held for your customer.
• The chain: each network the customer pays on, carrying its own availability record and its own history of reorganisations.
• Counterparty wallets: whether the customer pays from and to addresses you have screened and whitelisted, or from wallets that change every month.
• The payout partner: the institution completing the local leg, whose controls become part of your customer's risk the moment you route through it.

Attribution is the real difference. A bank wire names its sender. A blockchain transfer names an address, and only your own records connect that address to a person. FATF Recommendation 16, applied to virtual assets by Recommendation 15, requires originator and beneficiary information to travel with a transfer. How reliably a counterparty institution sends that information is itself a customer risk factor, because an incomplete arrival leaves your customer's payment waiting.

A customer risk rating is a prediction. If you never compare it with what the account actually did, you hold a filing requirement rather than a control.

How do you build and calibrate a customer risk rating, step by step?

• Start from the enterprise AML risk assessment, so customer factors inherit the risks the institution has already identified rather than a generic list.
• Define every factor, its permitted values and its evidence source, and record for each customer where the value came from.
• Fix the weights, the bands and the override rules in a written methodology, approved by the compliance officer and version dated.
• Decide what each band changes in practice: due diligence depth, monitoring thresholds, review frequency and approval level.
• Rate the existing book, not only new applicants, and report the distribution that results.
• Back test against outcomes, asking which bands produced the alerts, the escalations and the reports you actually filed.
• Recalibrate on that evidence, and keep the previous version with its date so a reviewer can follow what changed and why.

Back testing is the step that gets skipped, and it is the one that shows the model works. If the band meant to carry your highest risk produces no alerts and no reports, while the low band produces most of them, the weights are wrong. That comparison is cheap to run and hard to argue with.

What forces a re-rate, and what evidence will a reviewer read?

Periodic review sets the floor, with high risk files revisited more often than low risk ones. Events do the real work, because risk changes between reviews. Re-rate on a change of ownership or control, a new corridor or a new beneficiary type, activity that breaches the profile recorded at onboarding, an alert that becomes an escalation or a report, adverse media, and a list update that touches the customer's structure. FINTRAC expects a reporting entity under the Proceeds of Crime (Money Laundering) and Terrorist Financing Act to assess the risk of each business relationship and apply enhanced measures where that risk is high, which only holds if the assessment stays current.

Automate the trigger wherever the data allows. A corridor added in the payment system should raise the rating question by itself, instead of waiting for an annual review to notice.

A reviewer reads a short file per customer: the factor values and the source of each, the computed band, any override with its author and reason, what that band changed in practice, and the date of the last review with the next one set. Across the book they read two more things, the distribution by band and the back test. The FFIEC BSA/AML Examination Manual points examiners at the customer risk profile and the monitoring it drives, so a rating that changes nothing downstream is the finding, even when every form is complete.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross-border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs. Compliance is built in, with KYB and KYC onboarding that captures the ownership behind a corporate sender, KYT, sanctions and PEP screening, FATF Travel Rule data in IVMS101 form, a compliance workbench and a tamper-evident audit trail, so the factor values behind a rating sit with the payments they govern. Settlement runs in regulated stablecoins on public blockchains and completes in minutes with on-chain auditability, and because the platform is ISO 20022 native, with pacs.008 customer credit transfers, pacs.009 interbank legs, pacs.002 status reports and pacs.004 returns tracked by UETR, the behaviour a rating predicts can be measured against the record of what each customer did.