A customer risk rating decides how much scrutiny an account gets, and most institutions set it once, at onboarding, then leave it alone. FATF and the Wolfsberg Group both reject that model directly: customer risk is not static, and a rating nothing ever prompts a re-check on isn't risk-based. It's a label.
That gap rarely shows up as a single dramatic failure. It shows up as a customer whose transaction pattern changed two years ago, still carrying the risk tier a form assigned them on day one.
What is a customer risk rating, and what is it supposed to do?
A customer risk rating is the classification, typically Low, Medium, or High, that a risk-based CDD program assigns to a customer. It comes out of an AML risk assessment: a scoring exercise weighing factors like customer type, product usage, geography, and channel. That AML risk scoring step sets the level of due diligence a customer gets. A Low-risk retail customer gets simplified checks. A High-risk customer gets enhanced due diligence and closer monitoring. The rating is what makes a risk-based approach actually risk-based, instead of applying the same scrutiny to every account regardless of what it does.
What do FATF and Wolfsberg actually say about reviewing it?
Both standard-setters describe customer risk assessment as a lifecycle, not a one-time exercise. The Wolfsberg Group frames it as a dynamic, lifecycle-based assessment, refreshed based on transaction behavior, trigger events, and changes in ownership, control, or geography. FATF's own position is that customer risk is not static and that a risk profile should be updated through ongoing monitoring as trigger events and behavioral changes occur. Neither treats onboarding as the finish line.
What does "built once" look like inside a real compliance program?
In practice, it looks like a risk-based CDD program with no path back to the rating after day one. The onboarding form asks the right questions, a score comes out, a tier gets assigned, and the file closes. If the institution runs any review at all, it's usually a scheduled periodic refresh, annual for High risk, longer for everyone else, not a rating that responds to anything that happens in between. A customer's transaction behavior can drift substantially. New ownership can move in. A screening hit can land. The rating on file doesn't move until the next scheduled cycle catches up, if it catches up at all. FyscalTech has made a version of this argument before, about AML programs generally: a policy that exists on paper isn't the same thing as a control that's actually running.
Illustrative, not a measured statistic. Trigger categories drawn from FATF and Wolfsberg Group guidance on dynamic, lifecycle-based customer risk assessment.
What should actually trigger a re-rating?
FATF and Wolfsberg's own trigger categories give a concrete list, and each one should be able to move a rating on its own, independent of the calendar. A change in the customer's transaction behavior relative to their known profile is one trigger. A screening match, positive or near-positive, against a sanctions, PEP, or adverse-media list is another. So is a change in ownership or beneficial ownership, a change in geography such as a new jurisdiction of residence, incorporation, or counterparty, or the customer adopting a new product or channel with a different risk profile than the one they were originally rated for.
Where does BSP's AML Risk Rating System fit into this?
BSP Circular 950 establishes an AML/CFT Risk Rating System that BSP-supervised institutions are expected to demonstrate, not just document. BSP's own examination posture has shifted toward testing whether a risk-based approach produces results, a point FyscalTech has covered in detail, instead of checking that a policy exists on paper. One thing we have not independently verified from BSP's own text is a specific mandated cadence for re-rating. Treat any specific review-frequency figure as something to confirm with BSP's circular directly, or with your Compliance Advisory Lead.
What does a rating that actually updates require, technically?
It requires the rating to live somewhere every relevant signal can reach, instead of sitting in a CDD file that only gets opened during a scheduled review. That means the customer's onboarding classification, every subsequent screening result, and behavioral flags from transaction monitoring all need to update the same record, not three records nobody has connected. A continuously updated, real-time view of a customer is the same underlying idea applied to KYC generally. Building that connective layer is a case management problem before it's a risk-scoring problem. The rating is only as current as the weakest link feeding it.
How does Delta Screening fit into this, and what does a persistent risk profile add on top?
FyscalTech's Delta Screening re-screens the existing customer base on a schedule the institution sets, checking only against new watchlist additions since the last run instead of repeating a full screen every time. A customer added to a sanctions list yesterday gets flagged today, not at the next scheduled review. That closes one trigger, a screening hit, automatically. It does not, on its own, connect that hit to a transaction-behavior change or an ownership update happening in a different system.
Every alert, every screening result, and every prior investigation tied to one customer consolidates into a single case file, not three separate tickets. The Case Copilot's risk-assessment function works from that consolidated history, not from a static onboarding form.
A rating with that foundation can actually respond to a trigger event when it happens, instead of waiting for the next scheduled review to notice. That is what customer risk management looks like when the rating is a living part of the record, not a field filled in once and forgotten.