A customer risk rating system is the combination of a rating method, the software that applies it and the data feeds it reads, used to keep a current AML risk tier for every customer. Almost everything such a system needs already exists in systems a bank runs: activity in the core, alerts in transaction monitoring, expected activity and owners in the account-opening file, screening results and open cases. The usual failure is not missing data but data that reaches the rating late, on a calendar, through manual extracts. Botminds' Customer Risk Rating reads those systems where they are, re-scores a customer when a fact changes, and writes the rating back to the core and the monitoring system only after a maker and a different checker have signed.
The examples follow a fictional sample institution, Norrell Federal Credit Union, with 520,000 members, as it runs through the solution. Estimates are labelled as ours.
The customer risk rating system as a stack: read in place, write back once signed
Where the facts already live
- Core banking: accounts, services, cash and wire activity
- Transaction monitoring: alerts and their status
- Account opening: customer type, owners, expected activity
- Sanctions screening: results for customers and counterparties
- Case management: cases, enhanced due diligence, 314(a) results
- Document imaging: customer documents and responses
What the agents do each night
- Fact Watcher links every changed fact to a customer
- Rating agent scores under the approved method and writes the sentence
- Type-Bias Checker and Hold Checker test each proposal
- Batch & Sample agent groups like changes and picks a sample
- EDD Hand-off agent drafts the case on a move into High
Where the signed rating lands
- Core banking: the rating, written back after two signatures
- Transaction monitoring: the new tier sets its thresholds
- Case management: the enhanced due diligence case, opened
- The audit trail: who, what, when, why and which evidence
What is a customer risk rating system?
It is how a bank keeps the customer risk profile the CDD rule requires current for every customer, at the scale of its book. The FFIEC manual treats the profile and the customer risk rating as one thing, and expects a bank's program to tell significantly different customer risks apart (FFIEC, CDD overview). A system makes that possible for hundreds of thousands of customers.
Three parts are easy to confuse. The method is the bank's rules: factors, weights, tier cut-offs. The engine applies the method to each customer. The workflow decides who reviews and signs a change and what happens after. Buying an engine without the workflow automates arithmetic and leaves the slow part, reading and signing, as it was. The rules side is covered in the customer risk rating methodology; this page is about the engine's inputs and outputs.
What data feeds a customer risk rating? Five systems you already run
A rating needs who the customer is, what it said it would do, what it actually does, what it uses and where it deals, and whether anything is already open on it. Each of those sits in a system the bank already maintains, and the FFIEC manual encourages using them: a bank "may find it useful to cross-check for customer information in data systems maintained within the financial institution for other purposes, such as credit underwriting, marketing, or fraud detection" (FFIEC, CDD overview).
Which system holds each input to a customer risk rating
| Input | System that holds it | How the sample credit union uses it |
|---|---|---|
| Customer type, owners, line of business | Account opening platform | The customer profile family; type alone may carry at most 10 of 100 points |
| Expected activity: monthly cash, wires, trade area | Account opening platform | The baseline every activity rule compares against |
| Actual cash, wire, ACH and P2P activity | Core banking system | Activity rules, such as cash at 2.5 times expected |
| Products and services, with start dates | Core banking system | Products family: a new international wire service counts |
| Counterparty geography | Core banking wire log | Compared with the versioned high-risk jurisdiction list |
| Screening results | Sanctions screening service | Customers and counterparties; a late answer is shown, not assumed clear |
| Alerts, cases, 314(a) matches, pending enhanced due diligence | Transaction monitoring and case management | Holds on downgrades; never shown outside the BSA unit |
| Customer documents and responses | Document imaging | Evidence for overrides coded as explained by the customer |
Read in place, write back: why not a new system of record
Because a second copy of the customer is a second thing to keep correct. A rating platform that ingests nightly extracts into its own database inherits every gap in the extracts and adds its own, and a rating computed from a copy that missed an update is wrong with full confidence. FinCEN's order against TD Bank describes exactly that: customer updates made during a computer memory problem never reached the customers' risk scores (the TD Bank risk-score gap follows the consequences).
FinCEN's own guidance on the CDD rule points the same way. Asked whether banks must build new processes for ongoing monitoring and updating, FinCEN answered that an institution with adequate monitoring "may use its existing monitoring processes to comply with customer due diligence monitoring and updating obligations" (FinCEN CDD FAQs, Question 15). The design that follows is to read each system where it is, keep the links back to the source passage, and write one thing back: the signed rating.
Writing back matters as much as reading. A rating that lives only in a separate tool does not change monitoring until someone re-keys it; in Customer Risk Rating the signed rating is written to the core banking system and to transaction monitoring, where the new tier sets the customer's thresholds, and a move into High opens a drafted enhanced due diligence case in case management.
What is dynamic customer risk rating?
Dynamic customer risk rating means re-scoring a customer when a relevant fact changes, rather than only at account opening and on a review calendar. The CDD rule asks for customer information to be kept current on a risk basis, and the FFIEC manual is clear that no fixed continuous or periodic cycle is required. Dynamic rating is the natural reading of that: the rating moves when the evidence does, and a risk rating override is the controlled exception when a person knows something the facts do not show.
The same change in cash, rated on a calendar and rated on change
- Cash runs at three times expected; rating unchanged5 months
- Review
- Three-month trend builds3 months
- Signed
Dynamic does not mean twitchy. A rating that moves on every monthly blip produces churn that analysts learn to ignore. The sample method smooths with a three-month average for cash and a three-month persistence test for P2P payments, and keeps a quarterly re-score of the whole book on top of nightly re-scoring on change, so a customer whose facts never change is still looked at. How refresh cycles for the know-your-customer file sit alongside this is a question for the KYC program; the rating's job is to follow the facts.
One night of re-scoring at a sample credit union
Between 2:00 and 2:41 AM on October 22, 2026, the Fact Watcher found 4,118 members of the sample credit union with a changed fact. The Rating agent proposed 152 rating changes, 88 up and 64 down. 133 went into six like-change batches and 19 came to an analyst one by one, three of them held by the checkers. A banner noted that the sanctions screening service answered late at 6:10 AM; 212 members were re-screened at 6:24 AM and no rating used a stale result.
A quarter of re-scoring on change at a sample credit union
10,186
rating changes in the third quarter, about 3,400 a month
1,231
read one by one by an analyst; the rest decided in batches after a sample
94.8%
enhanced due diligence cases finished within 30 days: 381 of 402
7,140
High-rated members at quarter end, up from 6,610
The batch is what keeps dynamic rating affordable. Like changes, same direction, same rule, same evidence, are grouped, and the analyst reads a risk-weighted sample of those closest to the tier boundary before approving the batch once. Moves into or out of High, held changes and low-confidence changes are never batched.
Like changes in one batch, after reading the cases closest to the boundary
Can risk ratings be automated? What stays with people
The gathering, scoring, explaining and checking can be automated; the decision should not be. Treasury's 2024 report on AI and cybersecurity in financial services describes an institution that built an AI tool to classify suspicious emails, and "highlighted the essential role of human verification" even where the tool cut time spent on false positives (Treasury, March 2024). A rating is a more consequential decision than an email triage.
Where an analyst's minutes go on one rating change, by hand
The estimate shows where the time goes. Most of the manual work is retrieval and writing; the signature itself shrinks least, because a checker still reads the same evidence the maker read. That is the right shape: the system should take the parts that are searching and typing and leave the parts that are judgment.
How do you re-rate the existing customer base?
Run the current method on every customer before anything goes live, compare the result with the ratings on file, and treat every difference as a finding. Some differences are the method working; others are ratings that were never updated, customers who were never scored, or data that never reached the old process. All three are worth knowing before an examiner finds them.
In Customer Risk Rating, the same machinery that back-tests a new method version does this: the Methodology Steward scores the whole book under a given version and shows the tier migration, who would move and why. At the sample credit union, a revision to three rules was tested on all 520,000 members, and 6,412 would have changed tier, before it scored anyone. A first re-rating of an existing book is the same exercise with the old ratings as the starting point.
Implementation in five steps, without replacing anything
Implementing a customer risk rating system is mostly writing down what the bank already does and connecting what it already has. The steps below are how the solution is set up; the order matters more than the tool.
Setting up a customer risk rating system on the systems a bank already runs
- Write the current method as rules
Factors, points, caps, tier cut-offs and the hold rules, each with a one-line reason. Gaps found here are the first findings.
- Map each factor to the system that holds it
And to the field and the update frequency. A factor no system holds is a question for account opening, not for the rating.
- Agree read access and the two write-back points
Read from core, monitoring, account opening, screening and case systems; write only the signed rating and the drafted case.
- Re-rate the whole book and read the migration
Every customer whose tier changes is either a method question or a data question. Resolve both before go-live.
- Set roles, clocks and holds, then go live on change
Who may sign which change, how long each may wait, which changes are held; keep a periodic whole-book re-score as well.
Every action by people and agents, kept and exportable for an examiner
Where Customer Risk Rating fits, and where it does not
It fits a bank or credit union whose method is sound but whose ratings are slow, stale or hard to explain, and whose systems hold the data but do not talk to the rating. It does not replace transaction monitoring, sanctions screening or case management; it reads them and writes to them. It will not fix an account-opening process that never collected expected activity, because there is nothing to compare actual activity against, and it applies the bank's method rather than inventing one.
The retention side is settled by rule rather than preference: BSA records generally must be kept for five years (31 CFR 1010.430), and the solution keeps who did what, when, why and on which evidence for five years from each decision. To see a night of re-scoring on a sample of your own members, start from Customer Risk Rating, or read what to ask any customer risk assessment software in a demonstration.
Questions people ask
How do you implement customer risk rating?
Write the method as explicit rules, map each factor to the system that holds its data, re-rate the existing book and resolve the differences, then set who signs which change and go live with re-scoring on change plus a periodic whole-book re-score. Most of the effort is in the first two steps, which surface gaps in the method and in account-opening data.
Can risk ratings be automated?
Retrieval, scoring, explanation and checks can be; the decision should stay with a named person and a second signer. Automating the whole decision removes the reviewer the FFIEC manual's approval language assumes and the human verification Treasury's AI reporting stresses.
What is customer risk rating software?
The software part of a rating system: the engine that applies the method and, in better products, the workflow for review and sign-off. It needs read access to the systems holding customer data and a way to write the signed rating back to the core and to transaction monitoring.
How often should customer risk ratings be updated?
No rule sets a fixed cycle; the FFIEC manual says there is no categorical requirement to update continuously or periodically. A common design re-scores on change and also re-scores the whole book on a schedule; the sample credit union does both, nightly on change and quarterly for everyone.
Does a customer risk rating system need its own database?
It needs to keep its own decisions, the sentences, signatures, method versions and evidence links, but not a second copy of every customer's data. Reading the core and monitoring systems in place avoids scores built on extracts that missed an update.