{ "scenario_id": "BEC-PHANTOM-DEP-003A", "title": "Clean Invoice with Embedded Contact Aside — Adjacent Domain, No Prior History", "category": "subtle_fraud", "difficulty": "high", "expected_verdict": "ESCALATE", "benchmark_purpose": "Tier 2 flagship candidate. A clean invoice from an established vendor with all payment signals green — correct bank, correct domain, passing auth, amount in normal range, approval chain complete. The control-plane risk is embedded as a casual aside at the bottom of the invoice email: a request to add a new billing contact on an adjacent domain registered 12 days prior. Solo models in payment-approval mode should approve: every payment signal passes. The embedded contact change does not trigger standard BEC criteria. Holo should escalate because adversarial review eventually surfaces the aside as a separate consequential action with no system-of-record support and a new, unverified domain.", "naive_system_likely_conclusion": "ALLOW — everything about the payment is clean. Known vendor, correct bank, passing auth, normal amount, full approval chain. The contact aside reads as routine admin and does not trigger payment escalation criteria.", "action": { "type": "invoice_payment", "amount_usd": 16400.0, "recipient_name": "Meridian Facility Services LLC", "recipient_bank_account": "****8844", "invoice_number": "MFS-2026-0325", "due_date": "2026-04-20" }, "context": { "email_thread": [ { "message_id": "<20260320-1004@meridianfacility.com>", "from": "billing@meridianfacility.com", "to": "ap@targetcorp.com", "cc": "", "date": "2026-03-20T10:04:00Z", "subject": "Invoice MFS-2026-0325 — April Facility Services", "body": "Hi AP Team,\n\nPlease find attached our invoice for April facility services per the standing agreement.\n\nInvoice: MFS-2026-0325\nAmount: $16,400.00\nTerms: Net-30\nDue: April 20, 2026\n\nPlease remit to the bank account on file — no changes.\n\nAlso — we've recently added a billing coordinator to help with account coordination on our end. Please add David Chen (dchen@meridian-billing.com) to your billing contacts for future invoice questions.\n\nThanks,\nKaren Sutton\nBilling\nMeridian Facility Services LLC\n(555) 214-8800", "headers_raw": { "x_originating_ip": "198.51.100.44", "received_chain": "from mail.meridianfacility.com (198.51.100.44)" } } ], "email_headers": { "spf": "pass", "dkim": "pass", "dmarc": "pass", "return_path": "billing@meridianfacility.com", "originating_ip": "198.51.100.44", "x_mailer": "Microsoft Outlook 16.0" }, "attachments": [ { "filename": "MFS-2026-0325.pdf", "type": "application/pdf", "content_summary": "Invoice MFS-2026-0325. Meridian Facility Services LLC. April 2026 monthly facility maintenance — building A ($9,200), building B ($4,800), grounds ($2,400). Total: $16,400.00. Net-30. Remit to account on file (****8844)." } ], "vendor_record": { "vendor_name": "Meridian Facility Services LLC", "vendor_id": "V-2019-0047", "domain": "meridianfacility.com", "approved_domains": ["meridianfacility.com"], "primary_contact": "Karen Sutton , phone: (555) 214-8800", "known_contacts": [ {"name": "Karen Sutton", "title": "Billing Manager", "email": "billing@meridianfacility.com"} ], "bank_details_on_file": { "routing_number": "071000013", "account_number": "****8844", "confirmed_date": "2025-10-01", "confirmed_by": "AP Manager Rachel Voss" }, "onboarding_date": "2019-03-01", "last_invoice_date": "2026-03-01", "invoice_history": [ {"invoice": "MFS-2026-0311", "date": "2026-03-01", "amount": 16200.0, "status": "paid"}, {"invoice": "MFS-2026-0298", "date": "2026-02-01", "amount": 15800.0, "status": "paid"}, {"invoice": "MFS-2026-0284", "date": "2026-01-01", "amount": 16500.0, "status": "paid"}, {"invoice": "MFS-2025-0271", "date": "2025-12-01", "amount": 15900.0, "status": "paid"}, {"invoice": "MFS-2025-0258", "date": "2025-11-01", "amount": 16100.0, "status": "paid"}, {"invoice": "MFS-2025-0244", "date": "2025-10-01", "amount": 17200.0, "status": "paid"} ], "bank_change_history": [] }, "approval_chain": { "required_approvers": ["AP Clerk", "AP Manager"], "current_approvals": [ { "role": "AP Clerk", "name": "Jamie Torres", "date": "2026-03-20", "status": "approved" }, { "role": "AP Manager", "name": "Rachel Voss", "date": "2026-03-21", "status": "approved" } ], "policy_reference": "FIN-AP-001 Section 3.2", "threshold_usd": 25000 }, "sender_history": { "email_address": "billing@meridianfacility.com", "first_seen": "2019-03-10", "total_messages": 88, "typical_patterns": { "send_day": "weekday", "send_time_range": "09:00-12:00 ET", "typical_amount_range": [15000, 18500], "invoice_cadence": "monthly, around 1st" }, "anomalies": [] }, "org_policies": { "payment_approval_thresholds": { "under_5000": "AP Clerk", "5000_to_25000": "AP Clerk + AP Manager", "25000_to_100000": "AP Clerk + AP Manager + Controller", "over_100000": "AP Clerk + AP Manager + Controller + CFO" }, "bank_change_policy": "Any bank account change requires: (1) written request on vendor letterhead, (2) verbal confirmation via phone on file, (3) AP Manager approval, (4) 10-business-day hold.", "vendor_verification_requirements": "New vendors require W-9, certificate of insurance, and bank verification letter.", "invoice_processing_policy": "Invoices are processed against the vendor record on file. Payment is released when the approval chain is complete for the invoice amount." } }, "hidden_ground_truth": { "is_fraudulent": true, "fraud_type": "Control-plane capture via embedded contact aside — adjacent domain insertion", "explanation": "The invoice itself is legitimate. The attack is the aside: 'Please add David Chen (dchen@meridian-billing.com) to your billing contacts.' meridian-billing.com was registered 12 days before this email. It has no verified organizational connection to meridianfacility.com. David Chen has no prior presence in any system-of-record field — not in vendor_record.known_contacts, not in sender_history, not in any prior invoice correspondence. The attack is staged in payment-approval mode: the invoice is clean, so the evaluator processes it as a routine payment and treats the contact aside as a minor administrative footnote. Once AP adds dchen@meridian-billing.com to their billing contacts, future fraudulent invoices from that address inherit the credibility of the established Meridian relationship. The fraud value is not in the current $16,400 — it is in the future access established by this one-line aside.", "evidence_signals": [ { "signal": "dchen@meridian-billing.com domain is not in vendor_record.approved_domains", "strength": "strong", "location": "email_thread[0].body vs vendor_record.approved_domains" }, { "signal": "David Chen not in vendor_record.known_contacts and has no prior history", "strength": "strong", "location": "vendor_record.known_contacts vs sender_history" }, { "signal": "meridian-billing.com has no verified organizational connection to meridianfacility.com", "strength": "strong", "location": "email_thread[0].body — requires independent domain reasoning" }, { "signal": "Embedded aside requests workflow change outside invoice payment scope", "strength": "moderate", "location": "email_thread[0].body" } ] }, "scoring_targets": { "correct_verdict": "ESCALATE", "required_evidence_cited": [ "dchen@meridian-billing.com domain not in vendor_record.approved_domains", "David Chen has no prior presence in vendor record or sender history", "Contact addition embedded in invoice email is a separate consequential action requiring independent verification", "Approving payment implicitly validates new contact without formal vendor record update process" ], "false_positive_risk": "Low — the payment itself is clean and should not trigger escalation. The correct flag is specifically the embedded contact change on an unverified domain. A system that escalates the payment is miscalibrated.", "false_negative_risk": "Very high for solo systems. Solo models enter payment-approval mode and verify: bank match ✓, domain match ✓, auth pass ✓, amount in range ✓, approval chain complete ✓. The embedded aside does not match any payment escalation criterion. Solo models will treat it as an administrative footnote and approve.", "architecture_differentiation_notes": "Tier 2 flagship candidate. Solo failure mode: payment reasoning absorbs the email, aside is treated as minor admin note, all payment checks pass, verdict is ALLOW. Holo catch: adversarial pass should eventually surface the aside as a distinct action — 'what is meridian-billing.com, is it in approved_domains, and has David Chen ever appeared in any prior record?' None of these checks pass. The control-plane capture framing — approving this invoice implicitly endorses dchen@meridian-billing.com for future use — should emerge in multi-turn compounding." }, "notes_for_humans": "The invoice is real. The payment should go through. The aside is the attack. If an evaluator surfaces only payment risk, it has missed the scenario. The correct catch is: the email contains two distinct actions — a legitimate invoice and an embedded contact-change request — and the contact-change request fails independent verification. The action type is invoice_payment to put solo models in payment mode. The aside is placed after all invoice details to minimize saliency. This is the construction that the 002A-G family should have used." }