Biometric Data Policy

This is IDFire's publicly available written policy establishing a retention schedule and guidelines for permanently destroying biometric identifiers and biometric information, published as required by the Illinois Biometric Information Privacy Act, 740 ILCS 14/15(a).

Effective: 24 September 2026  ·  Last updated: 24 September 2026  ·  Version: 1.0

1. What we collect

IDFire collects facial biometric identifiers: a live image of your face, and a three-dimensional map of its geometry.

We do not collect voice biometrics. IDFire has permanently retired voice as a biometric modality, following NIST SP 800-63B-4 § 3.2.3.2, which states that biometric comparison based on voice shall not be used. Voice is neither collected, compared nor enrolled on any path.

Facial biometrics are the only biometric modality we collect. We do not collect iris or retina scans, fingerprints, palm prints, hand geometry, gait or keystroke dynamics.

Our software contains dormant support for additional modalities that is disabled, unreachable by any user, and captures nothing. If we ever enable another modality, we will update this policy and obtain a fresh written release before any collection begins. We would rather disclose that dormant code exists than let a future configuration change quietly falsify a sentence in this policy.

1.1 What these terms mean

Illinois law distinguishes two things, and the distinction matters for what this policy covers.

• A biometric identifier is a retina or iris scan, a fingerprint, a voiceprint, or a scan of hand or face geometry. It does not include writing samples, signatures, photographs, demographic data, or physical descriptions such as height, weight, hair colour or eye colour.
• Biometric information is any information, however captured or stored, that is based on a biometric identifier and used to identify a person.

We treat both as covered by this policy, and we treat the protected mathematical reference derived from your face as biometric information even where a narrower reading might not require it. We also treat it as special-category personal data under Article 9(1) GDPR, and as sensitive personal information under California law.

The scan of the face on your identity document, and the comparison of your live capture against it, are within scope. A photograph on its own is not a biometric identifier under Illinois law, but the scan of face geometry we derive from it is, so we do not rely on that distinction to narrow our obligations.

2. Why we collect it

We use facial biometrics for exactly three purposes:

1. Liveness. To establish that a real, live person is present, and not a photograph, mask, recording or synthetic forgery.
2. Document match. To confirm that the person presenting an identity document is the person pictured in it.
3. Uniqueness. To confirm that you do not already hold an IDFire identity, because IDFire is designed so that one human holds one identity.

We do not use biometrics for advertising, for profiling unrelated to identity, for emotion or demographic inference, or to identify you to anyone outside IDFire.

3. We obtain a written release before we collect anything

Before any biometric capture, we display a notice that states:

• that a biometric identifier is being collected and stored;
• the specific purpose for the collection;
• the length of term for which it will be collected, stored and used; and
• to whom it may be disclosed.

We then ask you to sign a written release. Capture cannot proceed until that release is recorded.

You can decline. Identity verification through document checks remains available, though features that depend on biometric assurance will not be.

4. What is actually stored

We do not store your photograph. The raw capture and the depth map are used to derive a protected mathematical representation and are not written to durable storage. They exist in memory only for the life of the single request that carries them, and that memory is overwritten before the request returns, on every path including error paths.

What we retain is a transformed vector: a renewable, many-to-one protected biometric reference in the sense of ISO/IEC 24745. No exact inverse of it exists, with or without our key.

5. Retention schedule

We permanently destroy your biometric identifiers and biometric information on the earliest of:

1. your withdrawal of biometric consent, or your revocation of biometric enrolment;
2. deletion of your IDFire account;
3. satisfaction of the initial purpose for collecting them; or
4. 24 months after your last interaction with IDFire.

Texas requires destruction within a reasonable time and no later than the first anniversary of the date the purpose for collection expires. Purpose satisfaction triggers destruction here independently of the 24-month cap, so that requirement is met on its own terms. Colorado requires deletion on the earliest of purpose satisfaction, 24 months from your last interaction, or 45 days after we determine that storage is no longer necessary; the schedule above meets each of those.

The 24-month period is shorter than the three years Illinois permits. We chose a single number that satisfies Illinois (740 ILCS 14/15(a)), Colorado (C.R.S. 6-1-1314), Texas (Bus. & Com. Code § 503.001) and California simultaneously, rather than applying different periods by state.

The clock runs from your last interaction, so an active user's biometric data does not expire while they keep using IDFire. The cap bites on dormant and deleted accounts. A deleted account's last interaction is the deletion.

6. Destruction guidelines

• Raw captures are overwritten in memory at the end of the request that carried them. They are never written to disk.
• Stored vectors are set to null in the identity record. The automated process that applies the Section 5 schedule is built and deployed, but it currently runs in report-only mode: it identifies records that are due for destruction without itself deleting them, and destruction is carried out under operator control. We are completing the safety soak that the process requires before it is allowed to delete on its own. Destruction on your request, on withdrawal of consent, and on account deletion is carried out now and does not depend on that work.
• Derived copies held by our matching service are revoked through a durable work queue, so that a transient failure results in a retry rather than in a copy surviving.
• Search index residue. An approximate-search index over face vectors held a second on-disk copy of every stored reference. We have retired that index rather than rely on database vacuuming to clear it.
• Backups age out on a fixed schedule. Data deleted from the live system may persist in a backup until that backup expires, and we do not restore deleted biometric data from backups.

7. Bans and the persistent record

We are asked how a service that bans people can also promise to destroy their biometric data. Our answer is that the durable ban-evasion layer is not biometric.

• For unlawful conduct only — fraud, child sexual exploitation, sanctions evasion, credible threats of violence — and only where a documented evidence pack supports it and two independent reviewers agree, we may retain a biometric record for the duration of the ban. That retention is still subject to the 24-month cap in Section 5. A ban does not create indefinite biometric retention.
• For every other ban, we keep a non-biometric record only: a keyed hash of identity document number, date of birth and issuing authority, plus device lineage. A document number is not a biometric identifier.

The full published category list is in Section 11 of the Terms of Service. No ban category is triggerable by your exercising a right against us. Children and vulnerable users are never biometrically watchlisted.

8. Disclosure, and no profit

We do not sell, lease, trade or otherwise profit from biometric identifiers or biometric information.

We do not disclose them except: with your consent; where required by a valid subpoena, warrant or court order; or to a processor bound by contract to the protections in this policy and prohibited from any other use.

9. Safeguards

We store and transmit biometric information using a reasonable standard of care within our industry, and in a manner at least as protective as that in which we handle other confidential and sensitive information: encryption in transit and at rest, hardware-backed key custody, least-privilege access, and audit logging of access.

10. Your choices and rights

• Decline. You may refuse biometric enrolment. Document-based verification remains available.
• Withdraw. You may withdraw biometric consent at any time in the app. Withdrawal destroys the authentication template and ends biometric sign-in.
• Delete. Deleting your account erases your biometric data, subject only to the ban assessment in Section 7 and to any legal hold. See idfire.ai/delete-account.
• Access, correct, port, object and appeal — as set out in Section 9 of the Privacy Policy.

11. Automated decisions and human review

If our uniqueness check concludes that you already hold an IDFire identity, enrolment is refused automatically at the point of detection. A liveness failure likewise fails verification automatically.

You may require that a person review either decision, put your case, and contest the outcome, by writing to privacy@idfire.ai. We maintain an adjudication record of uniqueness reviews.

12. What this policy does not claim

A document that claims everything is perfect is not credible. These are the honest limits.

• We do not claim the stored vector is anonymous, de-identified, or not personal data. It is special-category personal data from the moment of collection. We retain the binding between it and your identity record and can re-link them; separating them across schemas is a security and minimisation control, not an anonymisation claim.
• We do not claim absolute irreversibility. We assert irreversibility under the standard threat model of ISO/IEC 30136, in which the transform key remains secret. We do not claim resistance to an attacker holding both the stored reference and the key.
• We do not claim the vector cannot authenticate. Anything searchable one-to-many is, mathematically, a set of one-to-one comparisons. What we commit to is a service contract: the store exposes no one-to-one endpoint and returns a verdict rather than a similarity score.
• We do not claim biometric error rates of zero. Biometric systems have measurable false-match and false-non-match rates, and we report them disaggregated across demographic groups.
• We do not claim the two-vector separation has shipped. See Section 4.

13. Contact

Questions about this policy, or requests relating to your biometric data: privacy@idfire.ai.

IDFire Technologies Inc., a Delaware corporation.