FinTechGenerator

Claude Prompt for Biometric Re-Verification Mapping

This generator prompt has Luna, the deepidv compliance agent, map a progressive background biometric re-verification path modeled on national mandates like Malaysia's MyDigital ID. It produces event-led re-authentication triggers that tie each verified user profile back to the underlying sensor provenance, so re-auth fires on risk events instead of arbitrary timers. Useful for fintech compliance and product teams expanding into markets with national digital identity schemes.

How to use this prompt

1
Paste the prompt into Luna in the deepidv dashboard to generate triggers against your real user profiles, or into Claude, ChatGPT, or Gemini to draft the re-verification policy from a description of your stack.
2
Customize the reference mandate (swap MyDigital ID for Aadhaar, Singpass, or the EU Digital Identity Wallet) and list the risk events that should force re-authentication, such as device change, dormancy, or high-value transactions.
3
Expect a mapped re-verification path: tiered triggers, the biometric check each tier requires, and how each profile links back to sensor provenance for audit purposes.
4
Review the map with legal and engineering, then implement the triggers in your verification flow and log every re-auth event against the originating sensor record.

The prompt

Luna, map a progressive background biometric re-verification path matching the security upgrades enforced across regional networks like Malaysia's MyDigital ID. Configure event-led re-auth triggers that tie verified user profiles back to the underlying sensor provenance natively.

Test it in Claude or another LLM

This prompt is built for the Luna agent inside deepidv, where it maps a progressive background biometric re-verification path aligned with regional upgrades like Malaysia's MyDigital ID and configures event-led re-auth triggers that tie verified user profiles back to native sensor provenance. Here is how to dry-run the same mapping exercise in any LLM with synthetic profile data first.

1
Paste the full prompt into Claude, ChatGPT, or Gemini and replace the direct address 'Luna,' with a role instruction like 'Act as a compliance architect designing a progressive biometric re-verification policy across regional identity networks.'
2
Paste the synthetic user-profile and trigger-event block below so the model has fake profiles, sensor provenance records, and example events to reason over instead of waiting for live session data.
3
Tell the model to produce event-led re-auth triggers and to map each verified profile back to the sensor provenance it was originally captured on (device model, attestation type).
4
Good output is a tiered re-verification path (which events trigger a step-up, which accept the existing credential) plus a triggers table where each rule names the event, the assurance bump, and the sensor-provenance check. If the model proposes re-verifying every user on every login regardless of event, the progressive logic is missing.
5
Once the output shape is right, run the prompt live in the deepidv dashboard where Luna executes it against your real user profiles and wires the event-led triggers into your re-auth flow.

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.

USER PROFILE + SENSOR PROVENANCE (synthetic, do not use real data):
USER ACME-TEST-001 | Jane Testcase | enrolled on Pixel-Test-7, Play Integrity attested | last re-verify 280d ago
USER ACME-TEST-002 | John Sample | enrolled on iPhone-Test-15, DeviceCheck attested | profile now logging in from new emulator fingerprint
REGIONAL UPGRADE: MyDigital ID style mandatory facial biometric step-up | assurance target: NIST IAL2 / AAL2
TRIGGER EVENTS: device change, dormant >180d, large transfer >$10,000, jurisdiction change

Pairs with on deepidv

Sources & further reading

FAQ

What is event-led biometric re-verification?

It is re-authentication that fires on specific risk events, such as a new device, a long dormancy period, or an unusually large transaction, instead of on a fixed calendar schedule. National schemes like Malaysia's MyDigital ID are pushing this model because it concentrates friction where risk actually appears, and regulators increasingly expect re-auth decisions to be traceable to a documented trigger.

Why does sensor provenance matter for biometric verification?

Sensor provenance proves a biometric sample came from a real physical camera or fingerprint reader rather than a virtual device or injection attack. Tying each verified profile back to its originating sensor record lets you trust later re-verification events and gives auditors a chain of custody from enrollment through every subsequent re-auth.

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