Investigation quality feedback
Use quality review and feedback
The population that monitoring actually sees
3,626 of 3,700 source items enter this monitoring calculation. The missing 74 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,626 |
| Absent from this run | 74 |
A quality review can identify weak evidence, missed timing, inconsistent reasoning, and data defects. The feedback should improve the upstream process as well as the individual case.
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 3,700 items, but 74 are outside the completed monitoring run. The included population creates 399 hits and 327 unique cases. With 60 cases already open and capacity for 330, the queue closes at 57. 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 | 3,700 |
| alertRate | 0.11 |
| capacity | 330 |
| backlog | 60 |
| Calculated value | Result |
|---|---|
| population | 3,700 |
| covered | 3,626 |
| missing | 74 |
| raw | 399 |
| duplicates | 72 |
| cases | 327 |
| opening | 60 |
| resolved | 330 |
| closing | 57 |
| capacity | 330 |
From scenario hits to unique cases
399 raw hits become 327 cases after removing 72 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 | 399 |
| Duplicate references | 72 |
| Unique cases | 327 |
The queue balance is an accounting identity
Opening backlog 60 + arrivals 327 − completed cases 330 = closing backlog 57. 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 | 60 | Unresolved at window start |
| New cases | 327 | Unique arrivals in this window |
| Completed | 330 | Reached a defined completion state |
| Closing backlog | 57 | 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 | 57 |
| D2 | 5 |
| D3 | 67 |
| D4 | 227 |
| D5 | 257 |
| D6 | 156 |
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 | 327 | 330 |
| D2 | 278 | 330 |
| D3 | 392 | 330 |
| D4 | 490 | 330 |
| D5 | 360 | 330 |
| D6 | 229 | 330 |
An illustrative age profile of open work
The closing backlog is 57 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 | 28 |
| One to three days | 17 |
| Over three days | 12 |
Completion outcomes are not criminal labels
Of 330 completed review tasks, 56 are referred for further assessment, 40 need another evidence action, and 234 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 | 56 |
| Further evidence action | 40 |
| Closed under procedure | 234 |
Known-event tests assess specific coverage
The injected test set contains 100 known test events designed to exercise use quality review and feedback. 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 | 3,682 | 18 |
| Event time | 3,663 | 37 |
| Counterparty context | 3,589 | 111 |
Type the relationship before drawing an inference
This evidence map distinguishes a customer relationship, a transfer, and a case reference. The links support use quality review and feedback; 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 |
|---|---|---|
| Investigation quality feedback | Counterparty A | Observed transfer |
| Investigation quality feedback | 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 use quality review and feedback, 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 | 3626 included source items; 74 missing |
| Scenario to case | 399 hits linked to 327 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
Track defect types and corrective actions while preserving a representative review population.
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.