FinTechCryptoTask Prompt

FATF Plenary Watchlist Auto-Calibrator Prompt for Luna | deepidv

This prompt directs **Luna**, deepidv's compliance overseer agent, to convert the outcome of a **FATF plenary session** into concrete risk-model and transaction-monitoring changes for FinTech and crypto compliance teams. After each plenary, FATF adds or removes jurisdictions from its "Jurisdictions under Increased Monitoring" (grey list) and "High-Risk Jurisdictions subject to a Call for Action" (black list), and the operational work of re-scoring customers, beneficial owners, and correspondent counterparties usually drags on for weeks. Luna reads the plenary statement alongside your current jurisdiction exposure and entity graph, then returns recalibrated country risk tiers, updated transaction monitoring sensitivities, a list of affected corporate entity networks, and a regulator-ready change log. The target user is a BSA/AML officer, MLRO, or compliance engineer who needs the watchlist refresh reflected in production controls the same day it is published.

How to use this prompt

1
Open the deepidv dashboard and route to Luna (or paste the prompt into Claude, ChatGPT, or Gemini if you are testing outside the suite). Luna is the compliance overseer agent that owns risk-model and monitoring changes.
2
Replace the INPUT block: paste the full text of the latest FATF plenary public statement (grey-list additions/removals and black-list status), then attach your current country risk register and your list of in-scope corporate entity networks with their registered jurisdictions and beneficial-owner countries.
3
Run the prompt. Expect a structured response: a delta of jurisdiction risk-tier changes, recommended transaction monitoring threshold and sensitivity adjustments per jurisdiction, the specific entity networks that now cross a higher risk band, and a dated change log you can hand to an examiner.
4
Route the entity-network flags to your case management queue and the threshold changes to your transaction monitoring engineer for staging; do not push sensitivity changes to production without a human review of the false-positive impact.
5
Re-run after every FATF plenary — three times a year (typically February, June, and October) — and any time FATF issues an interim statement. Keep each run's change log so you can show a continuous, dated record of watchlist responsiveness.

The prompt

Luna, ingest the country movements finalized in the latest FATF plenary session and translate them into recalibrated cross-border risk scores and transaction monitoring thresholds across every affected jurisdiction and connected corporate entity network. You are deepidv's compliance overseer agent. Treat the FATF plenary statement as the authoritative source for which jurisdictions enter or leave the grey list (Jurisdictions under Increased Monitoring) and the black list (High-Risk Jurisdictions subject to a Call for Action). Do not invent jurisdiction movements that are not in the pasted statement.

INPUT, the user will paste:
- The full text of the latest FATF plenary public statement, including grey-list additions, grey-list removals, and any black-list status changes.
- Their current country risk register: each in-scope jurisdiction and its present risk tier.
- Their in-scope corporate entity networks: parent entity, registered jurisdiction, subsidiaries, and ultimate beneficial owner (UBO) countries.
- Current transaction monitoring thresholds and sensitivity settings per jurisdiction (if available).
- Any internal policy constraints (for example, jurisdictions already under an internal restriction, or a maximum acceptable false-positive increase).

OUTPUT, return the following structured response:

1. **Jurisdiction risk-tier deltas.** For each jurisdiction that moved in the plenary statement, show the prior tier, the new recommended tier, and a one-line rationale tied to its FATF status. Separate grey-list (Increased Monitoring) changes from black-list (Call for Action) changes. Apply a moderate tier increase for grey-list additions, the highest tier for black-list additions, and a recommended tier decrease for any jurisdiction removed from monitoring.

2. **Transaction monitoring recalibration.** For each affected jurisdiction, give concrete, directional threshold and sensitivity changes — for example, lowered cash-equivalent reporting thresholds, increased scrutiny on correspondent and cross-border flows, and tightened velocity rules. State the expected direction of false-positive impact so the team can size the review load before staging.

3. **Affected corporate entity networks.** List every entity network that now crosses a higher risk band because its registered jurisdiction or a UBO country moved. Name the parent, the triggering jurisdiction, and whether the trigger is registration or beneficial ownership. Flag networks tied to black-list jurisdictions for enhanced due diligence or restriction review.

4. **Recommended actions and routing.** Specify which items go to the case management queue (entity re-review), which go to the transaction monitoring engineer (threshold staging), and which require MLRO sign-off before any production change. Mark anything that should not auto-apply.

5. **Regulator-ready change log.** Produce a dated record listing each jurisdiction movement, the resulting risk-tier and monitoring change, and the routing decision, formatted so an examiner can read it as a continuous record of watchlist responsiveness.

Be specific. Use the exact jurisdictions, tiers, and entity names from the input — never placeholders. Keep every recommended production change gated behind human review, and call out any jurisdiction movement in the statement that you could not map to the user's register so nothing falls through.

Test it in Claude or another LLM

You can dry-run this prompt in any general LLM (Claude, ChatGPT, or Gemini) using synthetic data before wiring it to Luna in the deepidv dashboard. The goal is to confirm the agent produces a clean structured response — risk-tier deltas, monitoring changes, flagged entity networks, and a change log — without touching any real customer or transaction data. Use the fake input below, which contains clearly labeled TEST jurisdictions and FAKE entities so nothing is mistaken for a live watchlist.

1
Paste the full prompt into the LLM, then paste the synthetic sampleInput block below in place of the INPUT section.
2
Confirm the model separates grey-list (Increased Monitoring) changes from black-list (Call for Action) changes and assigns a distinct risk tier to each.
3
Check that every flagged corporate entity network in the output traces back to a jurisdiction that actually moved in the synthetic plenary statement — no phantom flags.
4
Verify the transaction monitoring section gives concrete, directional threshold or sensitivity changes per jurisdiction rather than vague advice.
5
Confirm the change log is dated and lists each jurisdiction movement and the resulting action, so it reads like something an examiner could review.

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.

INPUT (SYNTHETIC — TEST/FAKE DATA, DO NOT USE IN PRODUCTION):

FATF PLENARY STATEMENT [TEST — FICTIONAL]:
- Added to Increased Monitoring (grey list): Republic of Testland, Faketonia
- Removed from Increased Monitoring: Samplegrad
- High-Risk subject to Call for Action (black list): Dummystan (newly added)

CURRENT COUNTRY RISK REGISTER [FAKE]:
- Testland: Tier 2 (Medium)
- Faketonia: Tier 1 (Low)
- Samplegrad: Tier 3 (High)
- Dummystan: Tier 3 (High)

IN-SCOPE CORPORATE ENTITY NETWORKS [FAKE]:
- Network A: parent "Acme Test Holdings" (reg. Faketonia), 2 subsidiaries, UBO country: Faketonia
- Network B: parent "Globex Sample Ltd" (reg. Samplegrad), UBO country: Testland
- Network C: parent "Initech Dummy Corp" (reg. Dummystan), UBO country: Dummystan

Pairs with on deepidv

Sources & further reading

FAQ

Does Luna apply the watchlist changes to my production systems automatically?

No. Luna returns recommended risk-tier and transaction monitoring threshold changes plus the affected entity list, but a human reviewer approves them before anything reaches production. The prompt is designed so the output stages cleanly into your case management and monitoring tools, with a change log that records who approved what and when.

How often should I run this prompt?

Run it after each FATF plenary, which usually publishes three times a year, and after any interim FATF statement on a specific jurisdiction. For crypto desks with fast-moving cross-border flows, re-running on the day of publication keeps your country risk register from lagging the public watchlist.

What is the difference between the FATF grey list and black list in Luna's output?

Luna separates the two. Grey-list jurisdictions (Increased Monitoring) get a moderate risk-tier bump and tightened monitoring sensitivity. Black-list jurisdictions (Call for Action) trigger the highest risk tier and, where relevant, recommended enhanced due diligence or restriction flags on connected entities, mirroring FATF's distinction between heightened monitoring and counter-measures.

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