FinTechCryptoReview Prompt

Claude Prompt for Telemetry Integrity and Injection Audits

This red-team prompt instructs Arbiter, the deepidv fraud-detection agent, to audit the last 100 high-risk verification sessions for virtual camera signatures and telemetry tampering that standard liveness checks miss. It scores each session across hardware attestation, signal coherence, and environment fingerprinting, then returns per-session flags plus aggregate attack signatures and threshold recommendations. It is built for fraud and risk teams at fintechs and crypto platforms facing injection attacks.

How to use this prompt

1
Paste the prompt into Arbiter in the deepidv dashboard for live session data, or into Claude, ChatGPT, or Gemini with an export of your session telemetry attached.
2
Scope the inputs: set the time window (default last 7 days), the risk tier threshold, and any cohort filter such as jurisdiction, device OS, or customer segment.
3
Run the audit and expect per-session flags with the failing pillar, a confidence score, and a P0/P1/P2 action, plus an aggregate view of the top 3 attack signatures observed.
4
Act on the triage tiers: freeze P0 sessions and queue SAR review, push P1 sessions to enhanced review within 24 hours, and feed P2 marginal calls into model retraining.
5
Re-run monthly and compare the recommended detection-threshold adjustment and estimated false-positive rate against the prior window to track drift.

The prompt

Arbiter, perform a deep audit on the last 100 high-risk sessions. Analyze the device telemetry for "virtual camera" signatures or "telemetry tampering" patterns. Flag any sessions where the sensor signal lacks the natural Gaussian noise characteristic of a physical smartphone lens.

INPUT, the user will scope:
- Time window for the 100-session sample (default: last 7 days)
- Risk tier threshold (default: high-risk only)
- Optional cohort filter: jurisdiction, device OS, customer segment

AUDIT METHODOLOGY, for each session in scope:

1. HARDWARE ATTESTATION
- Did the session present a valid DeviceCheck (iOS) or Play Integrity (Android) attestation?
- If yes: does the attestation match the device fingerprint claimed elsewhere in the session?
- If no: rank as P0 (likely emulator or jailbroken / rooted device)

2. SIGNAL COHERENCE
- Does the camera frame stream exhibit natural Gaussian noise patterns consistent with a physical CMOS sensor?
- Are frame timestamps monotonically increasing with realistic jitter (5 to 20 ms variance under normal lighting)?
- Are motion-blur patterns consistent with handheld capture, or unnaturally clean (suggesting a synthetic feed)?

3. ENVIRONMENT FINGERPRINT
- Virtual machine indicators: hardware MAC patterns, sensor presence, CPU virtualization flags
- Instrumentation: Frida hooks, Magisk modules, Xposed framework presence
- Driver signatures: virtual camera drivers (OBS, ManyCam, virtual webcam SDKs)

OUTPUT, per flagged session:
- Session ID, customer ID, timestamp, risk tier
- Failing pillar (Hardware / Signal / Environment) with specific signal that fired
- Confidence score (HIGH / MEDIUM / LOW)
- Recommended action: P0 (immediate freeze and SAR queue), P1 (enhanced review within 24h), P2 (cohort retraining input)

AGGREGATE OUTPUT:
- Total sessions audited
- Total flagged (count and percentage)
- Top 3 attack signatures observed across the cohort
- Recommended detection-threshold adjustment for the next 30-day window
- Estimated false-positive rate at the proposed threshold

Be specific. Reference the actual signal patterns. If a session passed all three pillars, do not flag it. If a session failed one pillar with low confidence, mark P2 and explain the marginal call. Do not soften the findings to make the detection stack look better than it is.

Test it in Claude or another LLM

This prompt is built for the Arbiter agent inside deepidv, where it audits live high-risk verification sessions for virtual-camera and telemetry-tampering signatures (emulators, Frida hooks, synthetic feeds). Before you wire it to real session data, you can dry-run the same audit logic in any LLM with a few synthetic sessions to confirm the methodology and output shape match what your team needs.

1
Paste the full prompt into Claude, ChatGPT, or Gemini, but replace the opening direct address "Arbiter, perform a deep audit..." with a role instruction such as "Act as a device-fraud and telemetry-integrity analyst. Audit the following sessions for virtual-camera and tampering signatures using the methodology below."
2
Paste the synthetic sample data block (below) under the prompt so the model has concrete sessions to score against the three pillars (hardware attestation, signal coherence, environment fingerprint).
3
Add a scope line so the model does not invent defaults, for example: "Scope: last 7 days, high-risk tier only, no cohort filter."
4
Check the output: for THIS prompt good output names the failing pillar per flagged session with the specific signal that fired (e.g. missing Play Integrity attestation, frame jitter outside 5 to 20 ms, OBS virtual-camera driver), assigns HIGH/MEDIUM/LOW confidence and a P0/P1/P2 action, leaves clean sessions unflagged, and ends with an aggregate block (count and percentage flagged, top 3 attack signatures, a proposed detection threshold, and an estimated false-positive rate). Reject any output that softens findings or flags a session that passed all three pillars.
5
Once the output shape and reasoning look right, run the prompt live in the deepidv dashboard where Arbiter executes it against your real high-risk session telemetry instead of the synthetic sample.

Synthetic sample data to paste alongside the prompt

Fake test data, safe to share with any LLM. Swap in your own once the output looks right.

Synthetic test sessions (clearly fake, no real PII):
SESSION SESS-TEST-A1 | customer ACME-TEST-001 | 2026-06-10T09:12Z | high-risk | iOS DeviceCheck: VALID, fingerprint match: YES | frame jitter: 11ms avg | noise: natural Gaussian | drivers: none
SESSION SESS-TEST-B2 | customer ACME-TEST-002 | 2026-06-10T14:40Z | high-risk | Play Integrity: ABSENT | frame jitter: 0.4ms (locked) | noise: flat/synthetic | drivers: OBS-VirtualCam detected
SESSION SESS-TEST-C3 | customer ACME-TEST-003 | 2026-06-11T02:05Z | high-risk | DeviceCheck: VALID, fingerprint match: NO | frame jitter: 9ms | noise: natural | env: Frida hook + Magisk module present

Pairs with on deepidv

Sources & further reading

FAQ

How do you detect virtual camera injection attacks in KYC sessions?

Injection attacks bypass the physical camera, so detection shifts from the face to the signal: hardware attestation (DeviceCheck on iOS, Play Integrity on Android), natural Gaussian sensor noise that a real CMOS lens produces, realistic frame-timestamp jitter, and environment checks for virtual camera drivers, emulators, and instrumentation frameworks like Frida. A session that fails any of these pillars deserves manual review even if the face itself looks live.

What is telemetry tampering in identity verification?

Telemetry tampering is when an attacker manipulates the device signals sent alongside a verification session, spoofing sensor data, replaying captured frames, or running the session inside an emulator so the feed looks like a genuine smartphone capture. It defeats face-level liveness checks because the injected video can be a real face; the tampering only shows up in the device and signal metadata, which is what this audit prompt inspects.

Run it with live verification data

These prompts work in any LLM. Inside the deepidv dashboard, Luna, Arbiter, and Arc run them against your real sessions, screening lists, and audit trails.

Book a Demo