Continuous monitoring: tracking post-onboarding behavior
Continuous monitoring recognizes that risk measured at onboarding changes over time. TruvaLI evaluates every transaction against the customer's own history and declared profile, generating alerts and updating risk classes when deviations occur.
Continuous monitoring is the tracking of a customer's transaction behavior and risk profile throughout the business relationship. Information gathered at onboarding is merely a starting point: a customer's declared activity and actual transactions can diverge over time, and the obliged party is required to detect this exact divergence.
What is it monitored against?
A transaction has no meaning on its own. Meaning is derived from what it is compared against.
| Comparison | What it detects |
|---|---|
| Customer's own history | Amounts, frequencies, or times deviating from habits |
| Declared activity | Transaction types or counterparties inconsistent with declarations |
| Peer group | Behavior that appears unusual within the same segment |
| Below-threshold patterns | Structured transactions split just below reporting thresholds |
| Network relationships | Clusters connected via shared devices, IPs, addresses, or accounts |
These comparisons are calculated over aggregation windows: a customer's transaction count, sum, and average over a specific period can be used directly when writing rules. Details are on the rule and scenario engine page.
Why is the risk class not static?
The customer risk class is assigned at onboarding but does not freeze there. A new sanctions record, a new adverse media finding, a series of transactions inconsistent with declarations, or a change in ownership structure can elevate the risk class. When the class is elevated, the monitoring frequency, required documentation, and review schedule also change.
As lists change, the existing customer base is re-screened: a record that is clean today might match tomorrow. The screening aspect is explained on the sanctions compliance page.
What happens if there are too many alerts?
The real challenge of continuous monitoring is not missing risks, but drowning in them. A rule with a threshold set too low generates so many alerts that it obscures real threats, and after a while, the team stops looking at them. Therefore, what a rule will generate must be measured before going live: the new threshold is run against historical traffic to see how many alerts it will produce. This is why rule simulation and backtesting exists.
No technical knowledge is required to write a rule: the required control can be written in plain language, and its equivalent is generated as a draft rule. The rule writing with prompts page explains this.
When an alert is triggered
An alert becomes a case. In a case, the transaction, the customer's history, which version of which rule triggered it, and the investigator's justification are kept together. Having the rule version on record is decisive for audits: when asked which rule set was used to make a decision six months ago, the answer is in the records.
As a result of the investigation, the case is closed, snoozed, or escalated to a report. The workflow is on the alert and case management page, and reporting is on the regulatory reporting page.
Monitoring becomes meaningful with onboarding
Information collected at onboarding is the baseline for monitoring. If there is no declared activity, deviations cannot be measured. This is why it is crucial for both processes to reside on the same record: the customer onboarding page explains that side.
Common questions
- What does continuous monitoring compare?
- It evaluates transactions against the customer's own history, declared activity, peer groups, below-threshold structuring patterns, and network relationships established through shared devices, IPs, or accounts.
- Does the customer risk class change?
- Yes. A new sanctions record, adverse media finding, a series of transactions inconsistent with declarations, or a change in ownership structure elevates the risk class: monitoring frequency and the review schedule change accordingly.
- Are existing customers re-screened?
- Yes. As lists change, the existing customer base is re-screened, because a record that is clean today might match later.
- How is the risk of generating too many alerts managed?
- Before a rule goes live, it is run against historical traffic to measure how many alerts it will generate. A threshold that drowns the team is just as problematic as one that misses risks.
- Is technical knowledge required to write rules?
- No. The required control can be written in plain language, and its equivalent is generated as a draft rule: the draft does not go live without approval.
- Can you see later which rule was used to make a decision?
- Yes. Which version of which rule triggered the alert is recorded with the event, allowing a past decision to be explained using the rule set active on that day.
- How does the process proceed after an alert?
- An alert becomes a case. Following the investigation, the case is closed, snoozed, or escalated to a report: the justification and decision are written to the audit trail.
- Is monitoring independent of the onboarding process?
- No. The declaration and profile collected at onboarding serve as the baseline for monitoring: without a declaration, deviations cannot be measured.