False Positive Handling

Audience: Fraud Operations Last updated: March 2026 Version: 4.2

A false positive (FP) occurs when a legitimate transaction receives a HIGH or CRITICAL risk score, resulting in an unnecessary block, step-up challenge, or alert. Managing false positives is a core fraud operations task: too many FPs increase customer friction, generate unnecessary case workload, and can damage customer trust.

FraudShield AI provides four mechanisms for managing false positives: alert disposition feedback, suppression rules, customer and entity whitelisting, and challenge-based step-up authentication.

Alert disposition workflow

Every alert generated by FraudShield AI enters the Case Manager queue. Analysts review the alert and mark a disposition. Dispositions feed back into the model's training dataset and influence future RI scoring for the same account.

Disposition	Meaning	Model feedback effect
Confirmed Fraud	Transaction is verified as fraudulent. Fraud loss recorded.	Positive label added to the training dataset. Supports the model's fraud signal on this account and typology.
Suspicious — No Action	Transaction is suspicious but not confirmed fraud. No action taken (insufficient evidence).	Soft label. Included in model monitoring but excluded from retraining unless promoted by the data science team.
False Positive	Transaction is confirmed legitimate. Customer friction caused unnecessarily.	Negative label. Suppression rule candidate generated for analyst review. Contributes to FPR metric in tuning reports.
Duplicate Alert	A second alert was raised for the same transaction or related case already under review.	Excluded from training. Deduplication rule generated.

Suppression rules

Suppression rules prevent alerts from being created for transaction patterns that analysts have repeatedly confirmed as legitimate. They don't change the risk score — the score is still calculated — but they suppress the alert at the Decisioning Engine stage before it reaches Case Manager.

Suppression rules don't affect the risk score A suppressed transaction still scores as HIGH or CRITICAL internally. Suppression rules only prevent alert creation. If a suppressed pattern later starts generating confirmed fraud, make sure to remove or restrict the suppression rule promptly.

Suppression rule parameters

Parameter	Description	Example
`bta_id`	Restricts the rule to a specific BTA. Use `*` for all.	`ACH_CREDIT_BATCH`
`score_max`	Maximum risk score to suppress. Alerts above this score are never suppressed.	`650`
`ri_driver`	Suppresses only alerts where a specific RI is the top contributor.	`RI_VELOCITY_TRANSFER_1H`
`account_segment`	Restricts the rule to a customer segment.	`HNW`, `BUSINESS`, `ALL`
`expires`	ISO 8601 date when the rule expires automatically. Always set an expiry.	`2026-06-30`
`review_owner`	Analyst or team responsible for reviewing this rule at expiry.	`fraud-ops-team@bank.com`

Set expiry dates on all suppression rules Suppression rules without an expiry date accumulate over time and silently reduce fraud detection coverage. All suppression rules must include an expires date no more than 180 days in the future. Rules are reviewed and renewed by the owner before expiry.

Customer and entity whitelisting

Whitelisting reduces the risk score for a specific account, customer, or trusted payee. Unlike suppression rules, whitelisting affects the score itself by applying a score reduction factor before the decision is made. Use whitelisting for established high-value business customers or internally verified payees.

Whitelist types

Type	Applied to	Score reduction	Use case
Account whitelist	Originator account ID	Configurable (default: −150 points)	Long-standing high-value business customer with zero fraud history.
Payee whitelist	Beneficiary account number	Configurable (default: −100 points)	Internally verified payee (e.g., company's own payroll account, tax authority).
Trusted device whitelist	Device fingerprint ID	Configurable (default: −80 points)	Company-issued device enrolled through the trust registry after IT verification.

Whitelisting creates a fraud risk A compromised whitelisted account or payee bypasses full risk scrutiny. Review all whitelist entries quarterly. Remove entries for inactive accounts or payees that are no longer trusted. Account compromise on a whitelisted account can result in significant undetected fraud.

Challenge / step-up authentication

For transactions scoring in the HIGH range (default 550–749), FraudShield AI returns a STEP-UP decision instead of an outright BLOCK. The originating channel uses this signal to present an additional authentication challenge before allowing the transaction to proceed.

Step-up decision flow

Step-up authentication flow

Transaction scored → Decision: STEP-UP
        │
        ▼
Channel presents challenge to customer
  ├─ SMS OTP (for mobile app or web)
  ├─ Push notification (for enrolled mobile app)
  ├─ Voice callback (for high-value wire transfers)
  └─ In-branch identity verification (CRITICAL score override)
        │
   ┌────┴────────────────────────────┐
   │ Customer passes challenge       │ Customer fails / times out
   │                                 │
   ▼                                 ▼
Channel re-submits transaction     Transaction blocked
with challenge_result: PASSED      Alert raised in Case Manager
        │
        ▼
FraudShield re-scores with
challenge_passed=true flag
(reduces score by configured amount)
        │
   ┌────┴───────────────┐
   │ Revised score LOW  │ Revised score still HIGH/CRITICAL
   │                    │
   ▼                    ▼
APPROVE               BLOCK + case alert

Configuring the score reduction for passed challenge The score reduction applied when challenge_passed=true is set in threshold-config.yaml under step_up_score_reduction. The default is −200 points. Don't set this so high that a step-up pass always results in APPROVE regardless of score.

Analyst feedback loop

Analyst dispositions in Case Manager are the primary feedback signal for ongoing model improvement. The feedback loop runs as follows:

Analyst marks an alert as False Positive in Case Manager.
FraudShield AI logs the disposition with the transaction's full RI profile.
The Tuning Insight Report (generated weekly) groups FP dispositions by their dominant RI driver.
The fraud operations team reviews the report and identifies RI miscalibrations driving FP clusters.
Tuning changes are made to the RI score scale or threshold (see Threshold Tuning).
Confirmed fraud dispositions are added to the model retraining dataset (see Model Retraining Cycle).

Disposition quality matters The accuracy of model improvement depends entirely on the quality of analyst dispositions. Make sure your team doesn't use Suspicious — No Action as a catch-all for unreviewed alerts. Encourage complete case notes and accurate disposition recording.