FinTechCryptoReview Prompt

Review Prompt to Grade Identity Proofing Readiness for the ETSI TS 119 461 Deadline

This Luna review prompt grades your identity proofing estate against ETSI TS 119 461, assuming the end-2026 QTSP attack-testing deadline and the AMLR and EUDI requirements stacking on the same foundations. Luna, the deepidv compliance agent, runs a scope census of every proofing flow feeding trust services or eIDAS-adjacent obligations, the pathway each implements (remote document plus biometric, eID, attended), and the components carrying testable claims, then builds an evidence inventory per flow: PAD results under ISO/IEC 30107-family methodology with lab, date, and tested configuration, IAD results covering virtual cameras, emulators, and stream substitution, and matching evidence at deployed operating points with demographic breakdowns, marking absent or component-only evidence explicitly. A drift audit flags every material difference between tested configurations and production, a runway plan lays out lab booking lead times, remediation cycles, and the critical path to deadline with AMLR-era and wallet assurance requirements mapped onto the same test investments, and a standing-measurement design sets the quarterly adversarial drills and in-production metrics that keep recertification a refresh. The output is a readiness register by flow, gap, lab dependency, owner, and date. Built for compliance and product leads in European identity proofing who need to answer "our vendor says they're certified" with whose configuration, which date, and which discipline.

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 drafting the readiness register outside the platform.
2
Add an INPUT block below the prompt listing each identity proofing flow, the pathway it implements, its components (capture, PAD, document checks, matching), and every test report you hold with its lab, date, and tested configuration.
3
Run the prompt and read the evidence inventory and drift audit together: a certificate only covers the configuration that was tested, so any SDK, capture, prompt, or model change since then reopens the question.
4
Work the runway plan backward from the deadline, booking lab slots first since lead times sit on the critical path, and assign an owner and date to every row in the readiness register.
5
Re-run quarterly with the standing-measurement results, and whenever a production configuration changes, so recertification stays a refresh rather than a rebuild.

The prompt

Luna, run an ETSI TS 119 461 readiness review across our identity proofing estate, assuming the end-2026 QTSP attack-testing deadline and the AMLR and EUDI requirements stacking on the same foundations.

Produce:
1. Scope census: every proofing flow feeding trust services or eIDAS-adjacent obligations, the pathway each implements (remote document+biometric, eID, attended), and the components carrying testable claims (capture, PAD, document checks, matching).
2. Evidence inventory: per flow, current PAD results (ISO/IEC 30107-family methodology, lab, date, tested configuration), IAD results covering virtual cameras, emulators, and stream substitution, and matching evidence at deployed operating points with demographic breakdowns. Mark absent or component-only evidence explicitly.
3. Drift audit: differences between tested configurations and production (SDK versions, capture parameters, prompts, models), since certificates describe what was tested, with each material drift flagged as reopening the question.
4. Runway plan: laboratory booking lead times, expected remediation cycles from first-pass findings, and the critical path to deadline, with the AMLR 2027-era and wallet assurance requirements mapped onto the same test investments.
5. Standing-measurement design: the quarterly adversarial drills and in-production metrics that keep recertification a refresh.

Output a readiness register: flow, gap, lab dependency, owner, date. Treat "our vendor says they're certified" as a question, not an answer: whose configuration, which date, which discipline.

Test it in Claude or another LLM

This prompt is built for Luna inside deepidv, where Luna works from your live verification records and per-decision evidence. You can dry-run the readiness grading in any general LLM first with a synthetic flow and test-report inventory before pointing it at your real proofing estate.

1
Paste the full prompt into Claude, ChatGPT, or Gemini, replacing the opening 'Luna,' with a role instruction such as 'Act as an eIDAS identity proofing auditor grading readiness for ETSI TS 119 461 attack testing.' Keep the five numbered deliverables as written.
2
Below the prompt, paste the synthetic sample block from this page so the model has flows, test reports, and production configurations to grade.
3
Add one framing line: 'This is synthetic test data. Where a test result is not in the input, mark the evidence as absent rather than assuming the flow was tested.'
4
Check the output shape: a scope census, an evidence inventory, a drift audit, a runway plan, and a standing-measurement design, rolled into a readiness register with an owner and date per gap. If any flow is credited with test evidence the input did not list, tighten the framing and re-run.
5
Once the shape is right, run it live in the deepidv dashboard where Luna works from your real verification records.

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.

PROOFING FLOWS (synthetic, fake):
- Flow A: remote document plus biometric onboarding for a QTSP customer, capture SDK v4.2 in production
- Flow B: eID-based onboarding, no biometric step
- Flow C: attended video session for high-risk applicants
TEST EVIDENCE (fake):
- Flow A PAD: ISO/IEC 30107-3 report, Lab X, 2025-03, tested on SDK v3.8
- Flow A IAD: none on record
- Flow A matching: vendor component report only, no demographic breakdown at the deployed threshold
LAB RUNWAY (fake): Lab X quoting a 14-week booking lead time
OPEN ITEM (fake): whether Flow C carries testable claims in scope for the deadline

Pairs with on deepidv

Sources & further reading

FAQ

What is ETSI TS 119 461?

It is the ETSI technical specification setting policy and security requirements for identity proofing of trust service subjects. It recognizes proofing pathways (physical presence, remote with identity documents and biometrics, existing eID means, and attended hybrids) and, in its current revision, requires demonstrable resistance to presentation attacks on the biometric step and injection attacks on the capture path. Qualified trust service providers face an end-of-2026 requirement to hold standards-compliant PAD, IAD, and matching accuracy testing.

What does the ETSI 119 461 Readiness Grader produce?

A scope census of proofing flows and testable components, an evidence inventory of PAD, IAD, and matching results per flow, a drift audit comparing tested configurations to production, a runway plan to the deadline, and a standing-measurement design. Everything rolls into one readiness register by flow, gap, lab dependency, owner, and date, with absent or component-only evidence marked explicitly.

Is a vendor's certification enough to meet the deadline?

Not on its own. A certificate describes the configuration that was tested on a given date under a given discipline, and a QTSP consuming a vendor's remote proofing inherits that vendor's test posture into its own audit. The prompt treats "our vendor says they're certified" as a question, asking whose configuration, which date, and which discipline, and flags any drift between the tested setup and production.

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