Compliance Prompt for GENIUS Act Stablecoin CIP Routing
This **Luna** review prompt takes your active stablecoin wallet architecture and the joint **Customer Identification Program (CIP)** proposal issued under the **GENIUS Act**, then designs a tailored risk-based compliance routing flow. Luna, the deepidv compliance overseer, returns a CIP requirement map, a tiered routing design that places watchlist cross-comparison and record-keeping checks where they cost the least latency, a ledger-performance impact analysis, and a record-keeping and audit-trail spec. Built for compliance leads and engineering owners at crypto and fintech firms who run permitted payment stablecoin issuers and need to satisfy federal CIP, watchlist, and record-keeping obligations without slowing settlement on the ledger.
How to use this prompt
- 1
Open Luna in the deepidv dashboard and paste the full prompt, or run it in Claude, ChatGPT, or Gemini if you are sketching a routing design outside the platform.
- 2
Replace the INPUT section with your wallet and ledger architecture, your current CIP and watchlist screening logic, the per-stage latency and throughput budget on your ledger, and the joint-proposal sections your firm has already reviewed.
- 3
Run the prompt and read the CIP requirement map first: every joint-proposal CIP control is rated covered, partial, or gap with the evidence behind each rating and the section reference.
- 4
Hand the routing design and the ledger-performance impact analysis to your engineering owner, and route the record-keeping and audit-trail spec to your BSA officer; start with any control rated blocking.
- 5
Re-run the prompt after each routing change and after each new Treasury, FinCEN, or Federal Reserve publication so the design stays aligned to the final joint rule before your next examination.
The prompt
Luna, map our active stablecoin wallet and ledger architecture against the joint Customer Identification Program (CIP) proposal issued under the GENIUS Act, then design a tailored risk-based compliance routing flow. The flow must satisfy federal watchlist cross-comparison and record-keeping requirements without degrading our ledger performance budget. INPUT, the user will paste: - Active wallet and ledger architecture, with the verification stages each transaction touches (signup, deposit, on-chain transfer, withdrawal, counterparty change) - Current CIP and watchlist screening logic, including which lists are wired, the refresh interval, and the record-retention period - Per-stage latency and throughput budget on the ledger (p95 settlement target, any hard caps, peak transaction rate) - The joint-proposal CIP sections the firm has already reviewed - Any open Treasury, FinCEN, or Federal Reserve advisories the firm is tracking OUTPUT, return the following structured response: 1. CIP REQUIREMENT MAP For each CIP control the joint proposal sets: - The control (one-sentence summary with the joint-proposal section reference) - Current firm-level coverage (covered, partial, gap) - Evidence of coverage, or the evidence-absence reason 2. RISK-BASED ROUTING DESIGN - The tiered routing flow from signup through ledger settlement, with each stage and its assigned risk tier (low, elevated, high) - The specific watchlist cross-comparison check placed at each stage and tier, and whether it runs inline or asynchronously - The record-keeping write placed at each stage and the fields it captures - The escalation path when a tier promotes mid-transaction (low to elevated or high) 3. LEDGER-PERFORMANCE IMPACT ANALYSIS - Per-stage latency delta the proposed flow adds, measured against the supplied budget - Which checks breach a hard cap inline and the asynchronous or pre-computed alternative for each - Projected throughput at peak under the new flow and the headroom remaining 4. RECORD-KEEPING AND AUDIT-TRAIL SPEC - The record-keeping schema the firm should retain to satisfy the CIP record requirement (identity fields, screening result, decision rationale, timestamps) - The retention window and the cryptographic-receipt format for each screened event - How records and alerts route from Luna to the human investigation team for a Treasury, FinCEN, or Federal Reserve inquiry Be specific. Cite the joint-proposal section references where you can. Where the firm's input is insufficient to assess a control or a latency impact, flag the question instead of guessing.
Test it in Claude or another LLM
This prompt is built for the Luna agent inside deepidv, where Luna maps a firm's live stablecoin wallet and ledger architecture against the joint Customer Identification Program proposal issued under the GENIUS Act and designs a risk-based routing flow that holds ledger performance. You can dry-run the same workflow in any general LLM first with fake architecture and latency data to see the routing design before pointing it at real systems.
- 1
Paste the full prompt into Claude, ChatGPT, or Gemini, but replace the opening direct address 'Luna,' with a role instruction such as 'Act as an AML and sanctions compliance architect mapping a stablecoin wallet architecture against the joint CIP proposal under the GENIUS Act and designing a risk-based routing flow.' Keep the four OUTPUT sections (CIP requirement map, routing design, ledger-performance impact, record-keeping spec) exactly as written.
- 2
Under the INPUT section, paste the synthetic sample data block below so the model has a wallet and ledger architecture, current CIP and watchlist logic, and a per-stage latency budget to design against.
- 3
Add one framing line so the model knows this is an evaluation pass: 'This is synthetic test data. Where a control cannot be assessed from the input, flag it as an open question instead of guessing, and never claim coverage the input does not support.'
- 4
Check the output shape: you want a CIP requirement map with covered/partial/gap calls and joint-proposal section references, a tiered routing design that places each watchlist and record-keeping check at a named stage and risk tier, a ledger-performance impact analysis with per-stage latency deltas against the supplied budget and a note on which checks can run asynchronously, and a record-keeping and audit-trail spec. If any section reads vague or invents a control the input did not support, tighten the role line and re-run.
- 5
Once the output shape is right, run it live in the deepidv dashboard where Luna executes it against your real wallet architecture, ledger latency telemetry, and watchlist screening rule set.
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.
WALLET AND LEDGER ARCHITECTURE (synthetic, fake): - Issuer: ACME-STABLE-TEST-001 (PPSI applicant) - Stages: signup KYC, deposit, on-chain transfer, withdrawal, counterparty change - Ledger: LEDGER-TEST-A, target settlement p95 800ms; current CIP+screening adds 340ms inline at signup, 0ms at transfer CURRENT CIP AND WATCHLIST LOGIC (fake): identity collected at signup only; OFAC SDN cross-compare at signup, refresh weekly; no watchlist check on transfer or counterparty change; record retained 2 years LATENCY/THROUGHPUT BUDGET (fake): transfer stage hard cap 250ms p95; signup soft cap 1500ms; peak 1,200 transfers/min JOINT-PROPOSAL SECTIONS REVIEWED (fake): CIP record-keeping ref CIP-TEST-2026-04; watchlist cross-comparison ref CIP-TEST-2026-07 OPEN ITEM (fake): Treasury/Federal Reserve joint guidance tracked, fake ref TREAS-FRB-TEST-2026-XX
Pairs with on deepidv
FAQ
What does the joint CIP proposal under the GENIUS Act require for stablecoin issuers?
The GENIUS Act sets a federal framework for permitted payment stablecoin issuers, and the joint Customer Identification Program proposal issued under it asks issuers to verify customer identity, cross-compare customers against federal watchlists, and retain identifying records for a defined period. In practice that means identity collection and watchlist checks wired into the wallet flow and a record-keeping trail an examiner can pull on demand. This prompt maps your architecture to those CIP controls and designs the routing that satisfies them.
How does Luna keep CIP screening from slowing the ledger?
Luna designs a tiered, risk-based routing flow that runs the heaviest checks, full watchlist cross-comparison and record-write, on the stages and risk tiers that need them, and keeps low-risk traffic on a fast path. The output includes a per-stage latency and throughput impact analysis against the budget you supply, so you can see where a control adds delay and where it can run asynchronously without breaching CIP timing or record-keeping obligations.
Can I use this prompt outside the deepidv dashboard?
Yes. The prompt is written for Luna, the deepidv compliance overseer, but the structure works in Claude, ChatGPT, or Gemini as a self-assessment and design framework. You will get the CIP map, the routing design, and the impact analysis in any model; live architecture pulls, latency telemetry, and alert routing to your investigation team only work when it runs inside the deepidv dashboard.
Related prompts
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