Compliance & Regulatory
GDPR, CCPA, BIPA, SOC 2, ISO 27001, and PSD3 regulatory alignment for FaceSign deployments.
FaceSign is designed to operate within strict regulatory frameworks. This page covers how FaceSign aligns with GDPR, CCPA, BIPA, SOC 2, ISO 27001, and PSD3, and what documentation is available for your compliance team.
GDPR
FaceSign operates as a data processor under the General Data Protection Regulation. Your organization is the data controller.
| GDPR requirement | How FaceSign addresses it |
|---|---|
| Lawful basis | Processing is based on your lawful basis as controller (typically legitimate interest or consent). FaceSign does not independently determine the lawful basis. |
| Data Processing Agreement (DPA) | Available on request. The DPA covers the scope of processing, data categories, retention, sub-processors, and breach notification obligations. |
| Data Protection Impact Assessment (DPIA) | FaceSign provides DPIA support materials, including a description of processing operations, risk analysis, and safeguards. Your DPO uses these to complete your organization's DPIA. |
| Data subject rights | FaceSign supports access, deletion, restriction, and portability requests. See Biometric Data Handling for details. |
| International transfers | FaceSign processing infrastructure is located in the EU and US. Where transfers occur outside the EEA, they are covered by Standard Contractual Clauses (SCCs) included in the DPA. |
| Breach notification | FaceSign notifies controllers within 72 hours of becoming aware of a personal data breach, as required by Article 33. |
| Data minimization | Raw biometric data is processed in memory and discarded. Only tokenized fingerprints and session metadata are retained. See Security Architecture. |
Biometric data is classified as special category data under GDPR Article 9. Your organization must establish a lawful basis for processing special category data (typically explicit consent or substantial public interest) before initiating verification sessions.
CCPA
FaceSign operates as a service provider under the California Consumer Privacy Act and CPRA amendments.
| CCPA requirement | How FaceSign addresses it |
|---|---|
| Service provider agreement | FaceSign processes personal information only on your behalf and for the business purpose specified in the agreement. |
| No sale of data | FaceSign does not sell personal information. Biometric data is used only for the verification session you initiated. |
| Right to know | FaceSign supports disclosure of what personal information is collected and how it is used, on request from the controller. |
| Right to delete | FaceSign deletes biometric data within 30 days of a valid deletion request. See Biometric Data Handling. |
| Sensitive personal information | Biometric data is classified as sensitive PI under CCPA/CPRA. FaceSign's use is limited to the purpose of identity verification. |
BIPA
The Illinois Biometric Information Privacy Act imposes specific requirements on the collection, storage, and use of biometric identifiers.
| BIPA requirement | How FaceSign addresses it |
|---|---|
| Written consent | BIPA requires informed written consent before collecting biometric identifiers. As data controller, you are responsible for obtaining this consent before initiating a FaceSign session. |
| Retention and destruction | FaceSign applies automatic retention limits: 12-month inactivity purge and 3-year maximum retention. See Biometric Data Handling for details. |
| Prohibition on sale | FaceSign does not sell, lease, trade, or otherwise profit from biometric identifiers or information. |
| Storage and protection | Biometric fingerprints are stored as one-way tokenized hashes with AES-256 encryption at rest and TLS 1.3 in transit. |
| Private right of action | BIPA provides individuals a private right of action for violations. Your compliance team should ensure consent mechanisms and data handling practices meet BIPA requirements before deploying in Illinois. |
SOC 2 Type II
FaceSign is pursuing SOC 2 Type II certification.
| Aspect | Status |
|---|---|
| Audit scope | Security, Availability, Confidentiality |
| Current status | In progress |
| Expected completion | Contact security@facesign.ai for the latest timeline |
| Controls in place | Encryption at rest (AES-256) and in transit (TLS 1.3), HSM key management, role-based access control, audit logging, vulnerability scanning |
SOC 2 Type II certification is not yet complete. Contact security@facesign.ai for the current status and to request a copy of the report when available.
ISO 27001
FaceSign is built to ISO 27001 security standards following secure-by-design and privacy-by-design principles.
| Aspect | Details |
|---|---|
| Information security management | Formal ISMS covering risk assessment, access control, incident management, and business continuity |
| Secure development | Security reviews integrated into the development lifecycle |
| Encryption standards | AES-256 at rest, TLS 1.3 in transit, HSM-managed key material |
| Access control | Role-based access with principle of least privilege |
PSD3 Strong Customer Authentication
The revised Payment Services Directive (PSD3) introduces stricter requirements for Strong Customer Authentication (SCA) and shifts liability for coached transfer fraud to payment service providers.
| PSD3 requirement | How FaceSign addresses it |
|---|---|
| Strong Customer Authentication | FaceSign provides multi-factor verification: inherence (biometric), plus optional knowledge or possession factors (conversation, email OTP, SMS OTP). |
| Coached transfer liability | PSD3 makes providers liable when customers are coached into authorizing fraudulent payments. FaceSign's coercion detection provides an auditable signal of whether the user was acting under duress at authorization time. |
| Dynamic linking | Verification sessions can include transaction-specific details (amount, recipient) that are confirmed by the user during the conversational node. |
| Audit trail | Every session produces a timestamped record including risk scores, transcript, and coercion analysis -- evidence for regulatory review and dispute resolution. |
Coercion detection as a PSD3 compliance tool
Under PSD3, a payment provider that processes a coached transfer may be liable for the loss. Traditional SCA (OTP + password) cannot detect coaching. FaceSign's coercion detection creates an auditable record that the user was -- or was not -- acting freely at the moment of authorization.
This gives providers:
- Evidence of due diligence -- The provider took steps beyond standard SCA to verify the user's state of mind
- A decision point -- High coercion risk scores can trigger manual review or transaction hold before funds are released
- Regulatory documentation -- Timestamped, structured data suitable for regulator requests
Available documentation
| Document | How to obtain |
|---|---|
| Data Processing Agreement (DPA) | developers@facesign.ai |
| DPIA support materials | privacy@facesign.ai |
| SOC 2 Type II report | security@facesign.ai (when available) |
| Security whitepaper | developers@facesign.ai |
| Sub-processor list | Included in the DPA |