FACEIO Privacy Best Practices

After a user gives consent and completes enrollment, fio.js returns a Facial ID. This anonymous UUID identifies the enrolled user within your FACEIO application. Your backend can associate it with an account record, but the Facial ID is not a biometric hash and does not grant access by itself.

FACEIO itself, including the FACEIO service, fio.js, the Widget, REST API, and Console, does not store, handle, or access biometric hashes. The facial recognition engine selected by the application owner creates and manages the biometric hash used for face matching. Its storage region, credentials, retention, and deletion configuration remain under the application owner's control.

Your backend remains responsible for mapping a Facial ID to the correct user account and deciding whether an authentication result permits a login or another protected action. Do not treat a client-side result as a complete authorization decision.

When you create a FACEIO application and add fio.js to a website or web app, you remain responsible for the purpose and operation of that integration. This includes end-user notices, consent or another applicable lawful basis, account linking, backend authorization, retention, deletion, fallback access, support, and compliance with laws that apply to your organization and use case.

Do not enroll a user without the required notice and explicit end-user consent. Explain why facial authentication is offered, how the user can choose another access method where required, and how the associated Facial ID can be deleted after consent is withdrawn, facial authentication is disabled, or the account is closed.

For customers in the EU, EEA, UK, or Switzerland, application owners are required to use AWS Rekognition with their own AWS account, region, access keys, IAM permissions, logging, retention, and deletion controls, or deploy PixLab Insight on-premises inside infrastructure they control. FACEIO and PixLab | Symisc Systems are not responsible for a customer's AWS configuration, AWS credentials, region choice, cloud logs, on-premises infrastructure, retention policy, deletion workflow, consent process, or legal basis for processing.

FACEIO On-Premises includes the PixLab Insight facial recognition engine. In this deployment, facial recognition processing and its data, including biometric hashes, remain inside infrastructure operated by the application owner.

Define these requirements before launch and map them to the getting started guide, fio.js integration guide, REST API deletion workflow, and security settings. Product, legal, and engineering teams should review applicable requirements, including the EU General Data Protection Regulation (GDPR) ↗ where relevant.

Before enrolling a new user, explain what facial authentication will be used for and request consent at the point where the user chooses to continue. Requirements for facial data and biometric identifiers vary by jurisdiction, so the application owner must determine the notice, consent, and alternative-access requirements that apply to its use case.

Use this checklist when implementing fio.js facial authentication in a production website or web application. It covers the user-facing and backend controls required around enrollment and authentication.

• Place the consent request close to the action that starts enroll(), not hidden in a generic terms page.
• Provide a visible removal path in account settings or a documented support workflow so users can disable facial authentication and request Facial ID deletion.
• If a user deletes their account, treat that action as revocation of biometric authentication consent and delete the associated Facial ID when applicable.
• Do not auto-enroll users. Call enroll() only after the user has received the required notice and chosen facial authentication.
• Keep the purpose specific. If the use of facial authentication changes, update the notice and obtain any additional consent required before using it for the new purpose.
• Keep private values on the server. Never expose FACEIO REST API keys, AWS credentials, or other backend secrets in frontend code.
• Define authorization separately. Your backend must decide whether a successful authentication result permits login, recovery, or another protected action.

• Place facial authentication notices where users make the enrollment decision, not only in a footer policy.
• Explain what a Facial ID is, how it relates to the user's account, and how deletion requests are handled.
• Document the purpose of facial authentication, the selected recognition engine, fallback options, and the retention periods under your control.
• Provide a support path for users who want to remove facial authentication, ask privacy questions, or report an enrollment issue.
• Follow accessibility standards ↗ and provide a reasonable alternative for users who cannot or do not want to use face authentication.

• If a user deletes their account or disables facial authentication, delete the associated Facial ID through the FACEIO REST API when applicable. A successful deletion purges the Facial ID and associated payload and instructs the selected facial recognition engine to delete its biometric hash.
• Define how long your own enrollment records, authentication events, and audit records are retained, and align that policy with the Services Privacy Policy and Services Terms of Service.
• Delete or de-identify the account mapping, payload, and related records held in your own systems when they are no longer required under your policy.
• Use webhooks to keep your backend synchronized when enrollment, authentication, or deletion events affect account state.