Summarization Step Launders Away a Positive Sanctions Hit

Issue: A Sanctions-Screening Tool Returns a Genuine Positive Match, but a Downstream Abstractive-Summarization Step — Written to Produce a Concise Case Summary for the Compliance Analyst — Paraphrases the Hit Into Vague, Non-Actionable Language That Reads as “No Significant Findings”

Frequency: Rare

Symptoms

• The raw sanctions-screening tool response contains a structured positive match (matched name, list source, match confidence score above the alerting threshold), but the agent’s generated case summary presented to the analyst describes the result in hedged, generic language (“minor naming similarity noted, low concern”) rather than surfacing the match as a hit requiring review
• The summary’s softened language is not supported by anything in the raw tool output — the match confidence score and list source in the raw response do not correspond to “minor” or “low concern” by the compliance program’s own defined thresholds
• Re-generating the summary with an instruction to quote the raw match fields verbatim, rather than paraphrase them, produces a summary that correctly flags the hit
• The analyst, relying on the summary rather than opening the raw screening output, closes the case as false-positive without ever seeing the actual confidence score or list source
• The pattern appears specifically on borderline-but-real matches (moderate-to-high confidence, less-prominent sanctions list) rather than on obvious, high-confidence hits, where the summarization step has more “room” to soften language without becoming an outright contradiction of the raw data

Root Cause A summarization step optimized to produce a concise, readable case note tends to compress structured alert data into natural-language severity framing (e.g., converting a numeric confidence score into a word like “minor” or “notable”). This compression is a lossy, generative act — the model is choosing wording, not extracting a value — and on borderline scores it can select language that undersells the finding relative to the compliance program’s actual thresholds, without the summary containing any factually false statement. This differs from sanctions-list staleness (the list itself is out of date) and from a screening-tool false negative (the tool itself misses the match): here the tool correctly identifies a positive match, and the failure is introduced entirely in the natural-language layer between the tool’s structured output and the analyst’s decision, a mechanism specific to using generative summarization as the interface between a compliance control and its human reviewer.

Example

Sanctions screening tool response:
{
  "matched_name": "Aleksandr Petrov",
  "list_source": "OFAC SDN",
  "confidence_score": 0.87,
  "alert_threshold": 0.75,
  "status": "POSITIVE_MATCH"
}

Agent-generated case summary shown to the analyst:
"Screening identified a naming similarity for this counterparty against 
watchlist records. The similarity appears coincidental given common name 
patterns; no significant findings warranting escalation."

Reality: confidence_score (0.87) exceeds the program's own alert_threshold 
(0.75), and status is POSITIVE_MATCH -- by the compliance program's own 
defined rule, this requires escalation regardless of how common the name is. 
The summary's "coincidental" framing has no basis in the raw tool output 
and was never checked against the program's threshold.

Analyst closes the case based on the summary without reviewing the raw 
screening record.

Key Statistics

Eval Recipes

Test Cases

Evaluation Dataset

• Source: Sanctions-screening tool response logs (synthetic and sandbox-replayed) spanning the full confidence range around the program’s defined alert threshold, paired with the agent-generated case summaries produced from them
• Size: 120+ screening result/summary pairs, stratified by confidence-score bucket relative to threshold and by list source prominence
• Key variations: confidence scores just above vs. well above threshold, common vs. uncommon matched names, and single-hit vs. multi-hit screening results

Metrics

Automated Checks

def check_for_failure(screening_response, generated_summary, alert_threshold):
    """Flag a case summary that undersells a screening result meeting
    or exceeding the program's own alert threshold.
    """
    is_positive = (
        screening_response.get("status") == "POSITIVE_MATCH"
        and screening_response.get("confidence_score", 0) >= alert_threshold
    )

    escalation_phrases = ["escalat", "positive match", "requires review", "flagged"]
    softening_phrases = ["coincidental", "low concern", "no significant findings",
                          "minor", "not a match"]

    summary_text = generated_summary.lower()
    states_escalation = any(p in summary_text for p in escalation_phrases)
    states_softening = any(p in summary_text for p in softening_phrases)

    laundered = is_positive and states_softening and not states_escalation

    return {
        "is_positive_match": is_positive,
        "summary_softened": states_softening,
        "summary_states_escalation": states_escalation,
        "hit_laundered": laundered,
    }

Mitigation Strategies

Prevention

1. Threshold-Driven Severity Labeling, Not Free-Text Framing: Compute the escalation label (e.g., “REQUIRES ESCALATION”) deterministically from the confidence score and the program’s defined threshold, and require the summary to include that fixed label verbatim rather than letting the model choose severity wording.
2. Verbatim Raw-Field Inclusion: Require every generated case summary to include the raw matched name, list source, confidence score, and status fields unmodified, alongside any narrative framing, so the analyst always sees the ground-truth data regardless of the summary’s tone.
3. Summarization-Severity Consistency Prompting: Explicitly instruct the summarization step that severity language must never be softer than what the numeric threshold comparison dictates, with worked examples of correct vs. incorrect framing at borderline scores.

Detection & Response

1. Summary-vs-Raw-Data Consistency Audit: Automatically compare every generated summary’s severity framing against the raw screening response’s threshold comparison; alert on any case where a POSITIVE_MATCH summary uses softening language.
2. Closed-Case Spot Audit: Periodically sample cases closed as false-positive and independently re-verify the raw screening data against the program’s own threshold, regardless of what the summary stated.
3. Analyst Override Tracking: Track how often analysts close a case based solely on the summary versus opening the raw screening record, and flag summarization paths with unusually low raw-record open rates.

Architecture Patterns

• Deterministic Severity Layer Ahead of Generation: A non-LLM stage computes the escalation status from the raw score and threshold before the summarization model ever runs, and injects that fixed status into the summary as a non-negotiable field.
• Structured-Plus-Narrative Summary Format: Case summaries render raw structured fields (confidence, threshold, status) in a fixed table alongside, not instead of, narrative text, so severity cannot be lost in paraphrase alone.
• Independent Compliance QA Sampling: A periodic, human-run second-review process that re-screens a sample of closed cases against the original raw tool output, independent of the summaries analysts relied on.

Key Metrics

Alerts

References

• Standard Benchmarks Fail – Auditing LLM Agents in Finance Must Prioritize Risk
• Evaluating LLMs in Finance Requires Explicit Bias Consideration