Your compliance team needs documented consent before collecting facial biometric data for payment authentication. This script template covers regulatory requirements across GDPR, CCPA/CPRA, BIPA, and relevant state biometric privacy laws.
Purpose of This Template
Use this consent script when implementing facial recognition for payment authentication, identity verification, or fraud prevention. It addresses three compliance requirements:
- Informed consent: Users understand what biometric data you're collecting and why.
- Purpose limitation: You've documented specific, legitimate uses.
- Opt-in requirement: Users actively agree before you capture facial geometry data.
This isn't a general privacy policy. It's a standalone consent mechanism that runs before your system captures facial scan data for the first time.
Prerequisites
Before deploying this script, verify three things:
- Data classification: Document facial recognition data as biometric identifiers in your data inventory. Refer to PCI DSS Requirement 3.2.1 if processing it alongside cardholder data.
- Retention policy: Know how long you'll store facial templates and have documented destruction procedures.
- Vendor agreements: If using a third-party facial recognition SDK, ensure your contract specifies who owns the biometric data and prohibits secondary use.
You also need legal review in every jurisdiction where you'll collect this data. Illinois BIPA, Texas Capture or Use of Biometric Identifier Act, and Washington HB 1493 each impose different consent standards and private rights of action.
The Consent Script
FACIAL RECOGNITION PAYMENT AUTHENTICATION CONSENT
Before you use facial recognition to authenticate payments,
we need your explicit consent to collect and process your
biometric data.
WHAT WE COLLECT
We will capture a facial geometry template, a mathematical
representation of the distances between features on your face.
This template cannot be reverse-engineered into a photograph.
WHY WE COLLECT IT
We use your facial template to:
- Authenticate your identity when you initiate a payment
- Prevent unauthorized account access
- Detect and prevent fraud
We do NOT use facial data for marketing, cross-selling, or
any purpose unrelated to payment authentication and fraud
prevention.
HOW LONG WE KEEP IT
We retain your facial template for [SPECIFY: duration] or
until you close your account, whichever comes first. You
may request deletion at any time by [SPECIFY: method].
WHO HAS ACCESS
Your facial template is encrypted and stored separately from
your payment credentials. Access is restricted to:
- Authentication systems that verify your identity
- Fraud detection systems that analyze transaction risk
- [SPECIFY: third-party processor name] under contract
We will never sell your biometric data. We will not share
it with third parties except as required by law or with
your separate consent.
YOUR RIGHTS
You have the right to:
- Refuse consent (you can still use [SPECIFY: alternative
authentication method])
- Withdraw consent and request deletion of your facial
template
- Receive a copy of our biometric [data retention policy](/glossary/data-retention-policy)
- File a complaint with [SPECIFY: relevant data protection
authority]
CONSENT
□ I have read and understood this notice
□ I consent to the collection and use of my facial geometry
template for payment authentication and fraud prevention
as described above
□ I understand I can withdraw this consent at any time
[Accept] [Use Alternative Authentication]
How to Customize It
Duration specification: Replace [SPECIFY: duration] with your actual retention period. If subject to Illinois BIPA, document why your retention period is necessary. Consider: "for the duration of your account relationship plus 90 days to resolve disputed transactions."
Deletion method: Replace [SPECIFY: method] with your actual process. Be specific: "by emailing [email protected]" or "through the Privacy Controls section of your account settings."
Third-party processor: If using a vendor SDK (FaceTec, iProov, Onfido), name them here. Your vendor contract should require them to process biometric data only on your instruction.
Alternative authentication: Replace [SPECIFY: alternative authentication method] with your fallback option. Users who decline facial recognition consent must still be able to authenticate, typically via PIN, password, or SMS-based MFA.
Data protection authority: For EU users, specify the relevant supervisory authority. For California users, reference the California Privacy Protection Agency. For Illinois users, note their private right of action under BIPA.
Checkbox vs. button: The template uses checkboxes to create clear affirmative consent. Some jurisdictions require users to check multiple boxes to demonstrate they've read specific disclosures. Consult counsel on whether a single "Accept" button meets your requirements.
Validation Steps
After deploying this consent flow, validate five controls:
1. Consent timestamp logging: Verify you're recording the date, time, and version of the consent script each user accepted. Store this in an auditable system separate from the biometric data itself. If you face a regulatory inquiry, you need proof of valid consent for every enrolled user.
2. Withdrawal mechanism testing: Confirm that when a user withdraws consent, your system:
- Stops using their facial template for authentication.
- Deletes the template within your documented timeframe.
- Logs the deletion with a timestamp.
- Preserves the consent/withdrawal audit trail.
3. Fallback authentication: Test that users who decline facial recognition can still complete transactions using your alternative method. Document this in your procedures to demonstrate that consent is truly optional.
4. Cross-border data flow: If transferring facial templates across borders, verify you have appropriate transfer mechanisms (Standard Contractual Clauses, adequacy decisions, or binding corporate rules). GDPR Article 9 treats biometric data as a special category requiring additional safeguards.
5. Vendor contract alignment: Pull your SDK vendor agreement and confirm it matches your consent script. If your script says "we will never sell your biometric data" but your vendor contract includes a broad license grant, you have a compliance gap.
Run this validation quarterly, not just at launch. Regulatory requirements change. Washington's My Health My Data Act took effect in March 2024 and may require consent script updates if you're processing health-related biometric data.
One final check: if processing facial recognition data in the same environment as cardholder data, document how you're meeting PCI DSS Requirement 12.10.4.2 (detection and alerting for unauthorized access to sensitive authentication data). Facial templates used for payment authentication fall under "sensitive authentication data" in some interpretations.
