// INSIGHTS
Consent-First Face Recognition Check-In at Expo Scale
6 min read
Face recognition at an entrance is a solved engineering problem. Verification runs in under a second. The unsolved part is everything around it: what you collected, what you told the person, where the data went, and how quickly it is deleted. Under India's DPDP Act, biometric data is personal data and consent has to be specific, informed and freely given. Build the consent layer badly and the accuracy of your model is irrelevant.
Consent is the architecture, not a checkbox
We treat face recognition as an opt-in lane that sits beside the standard QR lane, never as a replacement for it. A delegate who declines loses nothing — no slower queue, no different treatment, no separate desk that signals disapproval. If declining carries a cost, the consent was not freely given.
The design consequences are concrete:
- Enrolment happens before the event, in the registration flow, where the delegate can read the notice without a queue behind them
- The notice states the purpose in plain language: verification at entry, for this event, for this duration
- We store a mathematical template, not the photograph, wherever the client's use case allows it. A template cannot be reversed into a usable face image
- Retention is bounded and stated up front, commonly deletion within 30 days of the event closing, with a deletion confirmation available
- Withdrawal is available at any time, including at the venue, and it takes effect immediately
Processing location matters as much as storage. For clients with a stricter posture, we run matching on-premise on venue hardware so that biometric templates never leave the building. That costs more and it is sometimes the only version a legal team will approve.
Measured performance
How the system is put together
1:1 verification, not 1:N search
The delegate presents a badge or QR that identifies them, and the face is used to confirm the claim. Verifying one identity is far more accurate and far less invasive than searching a crowd against a database.
On-premise inference option
Matching runs on venue hardware, with templates held locally and destroyed after the event. Nothing biometric traverses the public internet.
Human override on every gate
Staff can admit a delegate manually with a reason code. Every override is logged, so a rejected match becomes a data point rather than an argument at the door.
Tunable threshold per event
Match confidence thresholds are set with the client, explicitly trading false rejections against false acceptances. A media accreditation gate and a general expo entrance do not want the same setting.
Running an opt-in face lane
Write the consent notice with the client's counsel
Purpose, retention, storage location, withdrawal method. Plain Hindi and English. This is the first deliverable, before any technical work.
Enrol during online registration
The delegate uploads or captures a photo in their own time. Enrolment quality drives match accuracy far more than the camera at the gate does.
Calibrate on site under real lighting
Entrance lighting, backlight from glass doors and LED walls all affect capture. We test at the actual gate at the actual time of day before opening.
Delete and confirm
Templates are purged on the agreed date and a deletion record is produced for the client's file. This is part of the scope, not an afterthought.
The honest limitations
Face recognition is not uniformly accurate. Performance varies with lighting, camera angle, spectacles, masks, facial hair changes since enrolment, and demographic factors that are well documented in the research literature and are not fully solved by anyone. A system tuned to almost never falsely reject will occasionally falsely accept, and the reverse is equally true. There is no threshold that eliminates both. We set that threshold with the client, in writing, with the tradeoff stated, and we build the manual override path so a false rejection is a five-second inconvenience rather than a confrontation.
The second limitation is that it is often not the fastest option. A QR scan is already 8 to 14 seconds end to end including badge collection. Face verification does not dramatically beat that at a well-run desk, and it adds enrolment effort beforehand. Where it genuinely earns its place is repeated verification: re-entry across a three-day show, access to a restricted zone, or confirming that the person collecting a high-value item is the person entitled to it. If someone is proposing face recognition purely to shorten a first-day queue, the honest answer is usually that another printer would do more for less.
The third is perception. Some delegates will be uncomfortable regardless of how good your notice is, and that discomfort is legitimate. Design so it costs them nothing to say no.
Questions about consent and accuracy
Do you store delegates' photographs?
By default we store a non-reversible mathematical template rather than the image, and the source photo is discarded after enrolment. Some use cases, such as security incident review, require image retention, and where that is the case it is stated explicitly in the consent notice with its own retention period. It is never an unstated default.
What if a delegate refuses face recognition?
They use the QR lane, which is always open and always staffed at equal capacity. Their check-in time is comparable and their experience is not degraded. Refusal is recorded only as an absence of consent, and no biometric record is created.
Is this compliant with the DPDP Act?
Compliance depends on how you deploy it, not on the software alone. The elements that matter are a clear purpose-specific notice, genuine and revocable consent, data minimisation, bounded retention and appropriate security. We build all of those in and provide the documentation, but your data fiduciary obligations remain yours and your counsel should review the notice.
Evaluating face recognition for your event
We will tell you whether it fits your use case, including when it does not, before anything is built.
