Expected business activity
Build a usable customer profile
The population that monitoring actually sees
3,744 of 5,200 source items enter this monitoring calculation. The missing 1,456 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 | 3,744 |
| Absent from this run | 1,456 |
The profile describes how a merchant expects to receive and send money. Later activity must be interpreted against that story with room for legitimate growth and change.
A monthly volume estimate is treated as the full customer profile.
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 5,200 items, but 1,456 are outside the completed monitoring run. The included population creates 438 hits and 263 unique cases. With 35 cases already open and capacity for 228, the queue closes at 70. 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 | 5,200 |
| alertRate | 0.065 |
| capacity | 285 |
| Calculated value | Result |
|---|---|
| population | 5,200 |
| covered | 3,744 |
| missing | 1,456 |
| raw | 438 |
| duplicates | 175 |
| cases | 263 |
| opening | 35 |
| resolved | 228 |
| closing | 70 |
| capacity | 228 |
From scenario hits to unique cases
438 raw hits become 263 cases after removing 175 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 | 438 |
| Duplicate references | 175 |
| Unique cases | 263 |
The queue balance is an accounting identity
Opening backlog 35 + arrivals 263 − completed cases 228 = closing backlog 70. 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 | 263 | Unique arrivals in this window |
| Completed | 228 | Reached a defined completion state |
| Closing backlog | 70 | 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 | 70 |
| D2 | 66 |
| D3 | 154 |
| D4 | 320 |
| D5 | 381 |
| D6 | 337 |
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 | 263 | 228 |
| D2 | 224 | 228 |
| D3 | 316 | 228 |
| D4 | 394 | 228 |
| D5 | 289 | 228 |
| D6 | 184 | 228 |
An illustrative age profile of open work
The closing backlog is 70 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 | 35 |
| One to three days | 21 |
| Over three days | 14 |
Completion outcomes are not criminal labels
Of 228 completed review tasks, 39 are referred for further assessment, 27 need another evidence action, and 162 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 | 39 |
| Further evidence action | 27 |
| Closed under procedure | 162 |
Known-event tests assess specific coverage
The injected test set contains 100 known test events designed to exercise build a usable customer profile. The system surfaces 63. That 63% 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 | 63 | Expected evidence reached the control |
| Not detected | 37 | 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 | 4,940 | 260 |
| Event time | 4,472 | 728 |
| Counterparty context | 3,640 | 1,560 |
Type the relationship before drawing an inference
This evidence map distinguishes a customer relationship, a transfer, and a case reference. The links support build a usable customer profile; 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 |
|---|---|---|
| Expected business activity | Counterparty A | Observed transfer |
| Expected business activity | 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 build a usable customer profile, 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 | 3744 included source items; 1456 missing |
| Scenario to case | 438 hits linked to 263 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 product, counterparties, timing, geography, and the source of each profile fact.
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.