FinTechGenerator

Generator Prompt to Simulate a Shared-Device Fraud Ring Against Onboarding

This **Arbiter** generator prompt takes your onboarding stack and the largest ring cluster in the 2026 industry data, **70 identities across 13 devices, one device anchoring 16 verification events**, then replays it in the sandbox. Arbiter, the deepidv autonomous red agent, handles **ring construction** from kit-realistic assets with reused forged documents, shared device fingerprints perturbed per attempt, and rotating residential proxy exits across countries, paces a **deployment schedule** that mimics observed ring behavior including off-peak windows and sub-ten-minute cross-border intervals, runs **detection measurement** recording which signal fires first and at what fleet size the stack links the cluster (target: the third account, not the seventieth), escalates **evasion** by mutating the surviving ring arm with fresh renders and new device profiles to test lineage matching, and emits a **findings register** ranked by exploitability with a weekly regression suite. It never touches production customer records; sandbox persona kits only. Built for fraud and platform leads who need proof their fleet detection catches a ring early, not in archaeology.

How to use this prompt

1
Open Arbiter in the deepidv dashboard and paste the full prompt, or run it in Claude, ChatGPT, or Gemini if you are scoping the simulation outside the platform.
2
Replace the INPUT section with your onboarding flow, your fingerprinting and device-clustering signals, and your current linkage thresholds.
3
Run the prompt and read the detection measurement first: at what fleet size did the stack link the ring, against the third-account target?
4
Route any late-linkage or evasion-survivor finding to platform engineering with the signal that should have caught it.
5
Schedule the simulation to re-run weekly and refresh the kit assets whenever a new persona-kit family appears in the wild.

The prompt

Arbiter, simulate a shared-device fraud ring against our onboarding stack, modeled on the largest cluster in the 2026 industry data: 70 identities across 13 devices, one device anchoring 16 verification events.

Build and run the campaign in the sandbox:
1. Ring construction: generate a persona fleet from kit-realistic assets, reused forged documents across multiple identities, shared device fingerprints with per-attempt perturbation, and rotating residential proxy exits across at least three countries.
2. Deployment schedule: pace onboarding attempts to mimic observed ring behavior, including off-peak submission windows and cross-border intervals under 10 minutes for shared assets.
3. Detection measurement: record, per attempt, which signal fired first (document reuse, device clustering, velocity, provenance lineage) and at what fleet size the stack linked the cluster. Target: linkage at or before the third account, not the seventieth.
4. Evasion escalation: after first detection, mutate the surviving ring arm, fresh document renders from the same kit family, new device profiles, slower pacing, and measure whether lineage matching still connects it to the original cluster.
5. Findings register: rank every gap by exploitability, name the signal that should have caught it, and emit the regression suite to re-run weekly.

Do not touch production customer records; sandbox persona kits only.

Test it in Claude or another LLM

This prompt is built for the Arbiter agent inside deepidv, where Arbiter runs the ring against a real onboarding stack under sandbox controls. You can dry-run the campaign structure in any general LLM first to see the measurement shape before executing it live.

1
Paste the full prompt into Claude, ChatGPT, or Gemini, but replace the opening 'Arbiter,' with a role instruction such as 'Act as a fraud red-team lead designing a shared-device ring simulation.' Keep the OUTPUT sections exactly as written.
2
Under the INPUT section, paste the synthetic sample block below so the model has an onboarding flow and detection signals to design against.
3
Add one framing line: 'This is a sandbox design exercise with synthetic persona kits. Target linkage at the third account, not the seventieth.'
4
Check the output shape: a ring construction plan, a deployment schedule, detection measurement by fleet size, an evasion escalation step, and a findings register. If the design never states the fleet size at linkage, tighten the framing line and re-run.
5
Once the output shape is right, run it live in the deepidv dashboard where Arbiter executes the ring against your onboarding stack in the sandbox.

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.

ONBOARDING FLOW (synthetic, fake): document capture, selfie match, device fingerprint, geolocation
DETECTION SIGNALS (fake): document fingerprint index, shared-device clustering, cross-border velocity, generation-lineage matching
LINKAGE THRESHOLD (fake): flag a cluster at 3+ accounts sharing an asset
RING SHAPE (fake): 70 identities, 13 devices, one device anchoring 16 attempts, 3 proxy-exit countries
OPEN ITEM (fake): whether lineage matching survives fresh document renders from the same kit family

Pairs with on deepidv

Sources & further reading

FAQ

What does a shared-device ring simulation test?

Whether your onboarding stack links a coordinated fleet, reused documents and shared devices across many identities, before it finishes onboarding. It is modeled on the 2026 data's largest cluster: 70 identities across 13 devices, with one device anchoring 16 verification events.

What is the detection target?

Linkage at or before the third account in the fleet, not the seventieth. Catching a ring at three accounts is defense; catching it at seventy is archaeology. The simulation records which signal fires first, document reuse, device clustering, velocity, or provenance lineage, and at what fleet size the cluster is linked.

Is this safe to run against production?

Yes. The campaign uses sandbox persona kits and never touches production customer records. After first detection it mutates the surviving ring arm with fresh renders and new device profiles to test whether lineage matching still connects it to the original cluster.

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