AnalysisHigh riskComparison recommended

AI Playbook for Wire Transfer Fraud — Business Email Compromise

A manufacturer wired $890,000 to a fraudulent account after receiving an email that appeared to come from the CFO authorizing a vendor payment. The fraud was discovered 48 hours after the wire. The company has filed a police report and engaged the bank's fraud team.

When to use this playbook

  • Use this playbook when the decision looks like the situation above: A manufacturer wired $890,000 to a fraudulent account after receiving an email that appeared to come from the CFO authorizing a vendor payment.
  • It is a fit when you have source files in hand and need a structured, reviewable analysis — not a generic chat answer about "Wire Transfer Fraud — Business Email Compromise".
  • Do not use it as a substitute for licensed, legal, clinical, or authorized official judgment in the domain.

What you'll need

  • Wire transfer record (originating bank, amount, recipient account, routing number)
  • The fraudulent email chain (full headers)
  • The legitimate CFO email domain and authentication records (SPF, DKIM, DMARC)
  • The company's wire authorization procedure
  • Timeline of events from receipt of fraudulent email to wire execution

Attachments: Documents (Documents)

The Prompt

You are a fraud investigator supporting a business email compromise wire recovery. I am attaching:

Work only from the attached source files. If a conclusion is not supported, say so.

Produce:
1. Analyze the email headers to identify the originating IP, spoofed domain vs. lookalike domain, and whether DMARC would have blocked this if properly configured.
2. Trace the recipient account: what institution, what account type, and does it match known money mule patterns (recently opened, no prior wire history)?
3. Identify the procedural failure: which wire authorization steps were skipped or bypassed?
4. Tell me the 24-hour recovery window steps: SWIFT gpi trace, FinCEN rapid response, and what the bank's obligation is under UCC Article 4A.
5. Prepare the narrative for the FBI IC3 complaint and identify what additional documentation the receiving bank will need to freeze the funds.

Call out where independent models are likely to disagree, and list follow-up documents a reviewer should request.

What to expect

  • Email forensics summary with authentication failure analysis
  • Recipient account risk profile
  • Procedural failure map
  • Recovery action checklist with time windows
  • FBI IC3 complaint narrative

Review before you act

  • Validate this output against source files before relying on it: Analyze the email headers to identify the originating IP, spoofed domain vs. lookalike domain, and whether DMARC would have blocked this if properly configured.
  • Validate this output against source files before relying on it: Trace the recipient account: what institution, what account type, and does it match known money mule patterns (recently opened, no prior wire history)?.
  • Validate this output against source files before relying on it: Identify the procedural failure: which wire authorization steps were skipped or bypassed?.
  • Validate this output against source files before relying on it: Tell me the 24-hour recovery window steps: SWIFT gpi trace, FinCEN rapid response, and what the bank's obligation is under UCC Article 4A.
  • Confirm every cited figure, date, counterparty, or requirement against the attached originals — models compress and can drop a qualifier.
  • Treat disagreement between models as a review item, especially on classification, materiality, and recommended next action.
  • Do not authorize an operational, clinical, legal, credit, or enforcement action solely because the models agree.

Why compare models on this

For Wire Transfer Fraud — Business Email Compromise, running the same attachments across independent models is useful because the hard part is classification and completeness, not fluency. The workflow is already designed to surface email forensics summary with authentication failure analysis; recipient account risk profile; procedural failure map; recovery action checklist with time windows. Those are comparison artifacts — they only exist if more than one model runs. Typology labels (bust-out vs. first-party vs. third-party) and ring membership often diverge across models when data is incomplete. Divergence is a reason to hold and verify, not to auto-file a SAR.

Fraud DetectionPayments FraudAnalysisHighDocuments

See governed multi-model AI on your own prompt

Compare GPT-5, Claude, and Gemini side by side, with human review and a decision record built in.