Comparable customer segments
Segment for meaningful comparison
The population that monitoring actually sees
12,936 of 13,200 source items enter this monitoring calculation. The missing 264 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 state | Items |
|---|---|
| Included in monitoring | 12,936 |
| Absent from this run | 264 |
A cash-intensive retailer and a payroll provider can have different ordinary transaction patterns. A single peer comparison can obscure both legitimate variation and relevant changes.
The reference case starts with the stated population and a functioning evidence path. The owner is risk operations.
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 13,200 items, but 264 are outside the completed monitoring run. The included population creates 479 hits and 393 unique cases. With 35 cases already open and capacity for 390, the queue closes at 38. 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.
| Input | Value |
|---|---|
| population | 13,200 |
| alertRate | 0.037 |
| capacity | 390 |
| Calculated value | Result |
|---|---|
| population | 13,200 |
| covered | 12,936 |
| missing | 264 |
| raw | 479 |
| duplicates | 86 |
| cases | 393 |
| opening | 35 |
| resolved | 390 |
| closing | 38 |
| capacity | 390 |
From scenario hits to unique cases
479 raw hits become 393 cases after removing 86 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
| Stage | Count |
|---|---|
| Raw scenario hits | 479 |
| Duplicate references | 86 |
| Unique cases | 393 |
The queue balance is an accounting identity
Opening backlog 35 + arrivals 393 − completed cases 390 = closing backlog 38. 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
| Movement | Cases | Definition |
|---|---|---|
| Opening backlog | 35 | Unresolved at window start |
| New cases | 393 | Unique arrivals in this window |
| Completed | 390 | Reached a defined completion state |
| Closing backlog | 38 | Unresolved at window end |
Backlog accumulates across uneven days
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
| Day | Closing backlog |
|---|---|
| D1 | 38 |
| D2 | 0 |
| D3 | 82 |
| D4 | 282 |
| D5 | 324 |
| D6 | 209 |
Arrivals and completions need separate plots
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
| Day | Arrivals | Completions |
|---|---|---|
| D1 | 393 | 390 |
| D2 | 334 | 372 |
| D3 | 472 | 390 |
| D4 | 590 | 390 |
| D5 | 432 | 390 |
| D6 | 275 | 390 |
An illustrative age profile of open work
The closing backlog is 38 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 bucket | Open cases |
|---|---|
| Under one day | 19 |
| One to three days | 11 |
| Over three days | 8 |
Completion outcomes are not criminal labels
Of 390 completed review tasks, 66 are referred for further assessment, 47 need another evidence action, and 277 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 disposition | Tasks |
|---|---|
| Referred for assessment | 66 |
| Further evidence action | 47 |
| Closed under procedure | 277 |
Known-event tests assess specific coverage
The injected test set contains 100 known test events designed to exercise segment for meaningful comparison. The system surfaces 92. That 92% detection result measures this constructed test set only; it does not establish population-wide detection of illicit activity.
Figure data and text version
| Measure | Count | Interpretation |
|---|---|---|
| Injected known events | 100 | Defined test population |
| Detected by the scenario | 92 | Expected evidence reached the control |
| Not detected | 8 | Investigate data, logic, and delivery |
| Real-world illicit prevalence | Unknown | Not inferred from this test |
Data quality has several independent dimensions
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 requirement | Present | Absent |
|---|---|---|
| Party reference | 13,134 | 66 |
| Event time | 13,068 | 132 |
| Counterparty context | 12,804 | 396 |
Type the relationship before drawing an inference
This evidence map distinguishes a customer relationship, a transfer, and a case reference. The links support segment for meaningful comparison; 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
| From | To | Relationship |
|---|---|---|
| Comparable customer segments | Counterparty A | Observed transfer |
| Comparable customer segments | Profile record | Declared business |
| Counterparty A | Case record | Evidence reference |
| Profile record | Case record | Context for review |
Case clocks start from defined events
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
| Event | Relative time | Operational meaning |
|---|---|---|
| Source event | T0 | Activity occurred |
| Data arrival | T0 + 2 hours | The monitoring system learned it |
| Case created | T0 + 3 hours | Work entered an owned queue |
| Internal review target | T0 + 27 hours | Illustrative 24-hour target from case creation |
| Disposition | Recorded separately | Use actual decision and reporting records |
The end-to-end delivery contract
The scenario is incomplete until the intended evidence reaches an owned case. For segment for meaningful comparison, 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
| Boundary | Acceptance evidence |
|---|---|
| Source to scenario | 12936 included source items; 264 missing |
| Scenario to case | 479 hits linked to 393 unique cases |
| Case to reviewer | Required evidence visible under the reviewer role |
| Reviewer to outcome | Disposition, rationale, and any separate reporting decision retained |
Connect the result to the system
Use justified segments, monitor coverage within them, and preserve changes to segment membership.
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.