Worked case · Controlled response · 12 figures

Event-driven profile refresh

Refresh through events and risk

Figure 01 / 12

The population that monitoring actually sees

The population that monitoring actually sees — Event-driven profile refresh. Count; profile-change signals in one day. Exact values are in the figure data below.
Count; profile-change signals in one day

9,254 of 9,300 source items enter this monitoring calculation. The missing 46 items are a coverage gap, not evidence of low risk. Reconcile stable identifiers and amounts where appropriate before interpreting the alert rate.

Figure data and text version
Population stateItems
Included in monitoring9,254
Absent from this run46

A material change in activity or reliable ownership evidence can make an earlier profile stale. A periodic schedule alone may miss the relevant event.

Use defined event triggers and preserve the history of profile changes and supporting facts.

All amounts, rates, capacity limits, and outcomes in this case are synthetic. The three conditions are separate assumptions for comparison. A better result in the response condition is not measured proof that the proposed control causes that improvement. The figures expose the calculation and its limits; a real deployment needs its own evidence.

Read the result

The daily source population is 9,300 items, but 46 are outside the completed monitoring run. The included population creates 311 hits and 295 unique cases. With 42 cases already open and capacity for 350, the queue closes at 0. Coverage, duplicate work, and staffing are separate causes; reducing one number does not prove that the overall control improved.

Model inputs and calculated values

Inputs below are the case-specific values. Each figure states the condition-specific assumptions and units used in its calculation. Calculated values are rounded for display.

InputValue
population9,300
alertRate0.032
capacity250
backlog42
Calculated valueResult
population9,300
covered9,254
missing46
raw311
duplicates16
cases295
opening42
resolved337
closing0
capacity350
Figure 02 / 12

From scenario hits to unique cases

From scenario hits to unique cases — Event-driven profile refresh. Count; hit and case units differ. Exact values are in the figure data below.
Count; hit and case units differ

311 raw hits become 295 cases after removing 16 repeated references to the same case under the stated merge rule. Deduplication should reduce duplicate work while retaining the underlying events and reasons. It must not merge unrelated activity merely because values look similar.

Figure data and text version
StageCount
Raw scenario hits311
Duplicate references16
Unique cases295
Figure 03 / 12

The queue balance is an accounting identity

The queue balance is an accounting identity — Event-driven profile refresh. Cases per day. Exact values are in the figure data below.
Cases per day

Opening backlog 42 + arrivals 295 − completed cases 337 = closing backlog 0. Completion is capped by both available work and the stated capacity. This identity is useful even when average handling times are uncertain.

Figure data and text version
MovementCasesDefinition
Opening backlog42Unresolved at window start
New cases295Unique arrivals in this window
Completed337Reached a defined completion state
Closing backlog0Unresolved at window end
Figure 04 / 12

Backlog accumulates across uneven days

Backlog accumulates across uneven days — Event-driven profile refresh. Cases unresolved at day end. Exact values are in the figure data below.
Cases unresolved at day end

This deterministic six-day example applies a stated daily arrival multiplier and a constant completion capacity. Unused capacity does not carry forward as completed work. The series is a workload illustration; it omits variable case durations and specialist routing. Horizontal positions are the labeled observations or scenarios; equal spacing does not imply equal numerical increments.

Figure data and text version
DayClosing backlog
D10
D20
D34
D496
D570
D60
Figure 05 / 12

Arrivals and completions need separate plots

Arrivals and completions need separate plots — Event-driven profile refresh. Cases per day. Exact values are in the figure data below.
Cases per day

The service line cannot exceed the work available that day. A team can complete more cases than arrive while clearing an opening backlog. Conversely, stable staffing can coexist with a growing queue when arrivals remain higher than capacity. Horizontal positions are the labeled observations or scenarios; equal spacing does not imply equal numerical increments.

Figure data and text version
DayArrivalsCompletions
D1295337
D2251251
D3354350
D4442350
D5324350
D6206276
Figure 06 / 12

An illustrative age profile of open work

An illustrative age profile of open work — Event-driven profile refresh. Cases; constructed snapshot. Exact values are in the figure data below.
Cases; constructed snapshot

The closing backlog is 0 cases. The 50/30/remainder split is an explicit illustrative age allocation, not a distribution inferred from the arrival model. Production age buckets must come from each case’s actual receipt and status history.

Figure data and text version
Age bucketOpen cases
Under one day0
One to three days0
Over three days0
Figure 07 / 12

Completion outcomes are not criminal labels

Completion outcomes are not criminal labels — Event-driven profile refresh. Completed review tasks; synthetic disposition allocation. Exact values are in the figure data below.
Completed review tasks; synthetic disposition allocation

Of 337 completed review tasks, 57 are referred for further assessment, 40 need another evidence action, and 240 close under the stated procedure. These are operational outcomes. None is a probability of money laundering or a substitute for a reporting decision.

Figure data and text version
Review dispositionTasks
Referred for assessment57
Further evidence action40
Closed under procedure240
Figure 08 / 12

Known-event tests assess specific coverage

Known-event tests assess specific coverage — Event-driven profile refresh. Synthetic coverage test. Exact values are in the figure data below.
Synthetic coverage test

The injected test set contains 100 known test events designed to exercise refresh through events and risk. The system surfaces 96. That 96% detection result measures this constructed test set only; it does not establish population-wide detection of illicit activity.

Figure data and text version
MeasureCountInterpretation
Injected known events100Defined test population
Detected by the scenario96Expected evidence reached the control
Not detected4Investigate data, logic, and delivery
Real-world illicit prevalenceUnknownNot inferred from this test
Figure 09 / 12

Data quality has several independent dimensions

Data quality has several independent dimensions — Event-driven profile refresh. Count; overlapping field checks. Exact values are in the figure data below.
Count; overlapping field checks

Each row is a different field requirement over the same source population. Completeness alone does not establish that values are accurate or current. The case uses explicit illustrative missing counts to show how data quality can affect scenario coverage.

Figure data and text version
Field requirementPresentAbsent
Party reference9,28119
Event time9,25446
Counterparty context9,160140
Figure 10 / 12

Type the relationship before drawing an inference

Type the relationship before drawing an inference — Event-driven profile refresh. Typed evidence relationships. Exact values are in the figure data below.
Typed evidence relationships

This evidence map distinguishes a customer relationship, a transfer, and a case reference. The links support refresh through events and risk; they do not imply common ownership or intent. A shared data point is a lead whose meaning depends on source, time, and context.

Figure data and text version
FromToRelationship
Event-driven profile refreshCounterparty AObserved transfer
Event-driven profile refreshProfile recordDeclared business
Counterparty ACase recordEvidence reference
Profile recordCase recordContext for review
Figure 11 / 12

Case clocks start from defined events

Case clocks start from defined events — Event-driven profile refresh. Illustrative internal timing. Exact values are in the figure data below.
Illustrative internal timing

A legal deadline, an internal response target, and an evidence-expiry date can start from different events. The hours here are internal teaching targets only. They are not BSA, sanctions, consumer-protection, or other statutory deadlines.

Figure data and text version
EventRelative timeOperational meaning
Source eventT0Activity occurred
Data arrivalT0 + 2 hoursThe monitoring system learned it
Case createdT0 + 3 hoursWork entered an owned queue
Internal review targetT0 + 27 hoursIllustrative 24-hour target from case creation
DispositionRecorded separatelyUse actual decision and reporting records
Figure 12 / 12

The end-to-end delivery contract

The end-to-end delivery contract — Event-driven profile refresh. Operational control path. Exact values are in the figure data below.
Operational control path

The scenario is incomplete until the intended evidence reaches an owned case. For refresh through events and risk, verify source coverage, hit creation, queue acceptance, reviewer access, and final disposition separately. A green job status proves only that a job reported completion.

Figure data and text version
BoundaryAcceptance evidence
Source to scenario9254 included source items; 46 missing
Scenario to case311 hits linked to 295 unique cases
Case to reviewerRequired evidence visible under the reviewer role
Reviewer to outcomeDisposition, rationale, and any separate reporting decision retained

Connect the result to the system

Use defined event triggers and preserve the history of profile changes and supporting facts.

Check the population, evidence, permitted action, and actual effect together. A balanced calculation can still use the wrong population; a successful response can still leave an unknown financial outcome. The case’s numerical result applies only to its stated assumptions.

Sources and further reading

The chapter sources support the concepts and scope. They do not prescribe the synthetic model rates.

  1. FinCEN: Customer Due Diligence Rule and current resources
  2. FinCEN: FIN-2026-R001 beneficial-owner exceptive relief
  3. FFIEC: Customer Due Diligence (historical examination material; read with current FinCEN rules)