Verifying that someone is who they say they are stopped being a technology problem. Any decent model has compared two faces well for years.
The problem is elsewhere, and it is twofold: knowing there is a person on the other side and not a photo, and what you do with that data afterwards.
First, the legal part
Biometric data is sensitive data, and that changes the whole regime.
In Chile, Law 21.719 comes into force on December 1, 2026, with 72-hour breach notification and fines up to 20,000 UTM. In Costa Rica, Law 8968 requires informed, express consent, and PRODHAB holds powers to order processing to stop.
In both countries, storing faces puts you in the most demanding category. And a biometric breach cannot be fixed like a password breach: a password can be changed, a face cannot.
Second, spoofing
This is the point most often underestimated.
A photo cannot tell a person from a photo of that person. If your verification accepts an image, someone can hold a printout to the camera and pass. That attack requires no technical skill: it requires a printer.
That is why liveness detection exists. With a short video you can analyse whether there is a real person in front of the camera or an image. Passive liveness is the kind that asks the user for nothing — no turning the head, no blinking on cue: it runs on the video already recorded, adding no friction for the legitimate user.
Third, and most important: what you store
Here is the design decision that defines everything else.
There are three ways to solve it, and they are very different:
- Store the images. The worst. You hold a repository of faces with names next to them, which is exactly what an attacker wants and what regulators scrutinise.
- Store the face vectors. Better than the photo, but still biometric data: it uniquely identifies a person. Not looking like a face does not take it out of the category.
- Store nothing. Process in memory, respond and discard. A record that a query happened remains, with its result and date, but no image and no vector.
The third is the only one that removes you from the problem instead of managing it. You cannot leak what you do not have.
Four questions before contracting
If you are evaluating a face verification service, these four separate the field:
- Do you store images or vectors? If the answer takes a while, you already know.
- Does it run liveness, and is it passive? Without liveness you are validating photographs.
- What happens when there is no face in the image? It should return an error, not a "no match". That difference matters the day someone disputes why they were rejected.
- Who sets how strict it is? An attendance app's threshold cannot be a bank onboarding's. If the vendor fixes it for you, one of the two cases will be miscalibrated.
What we built
EgoFaceV is our face verification API. It takes a reference photo and a short video, and answers whether it is the same person and whether they are live, with the tolerance the consumer defines.
It stores no photos, videos or face vectors. Everything is processed in memory and discarded on response; only the record that a query happened remains, with its score and date, for audit and usage.
If it detects no face in the reference or the probe, it returns an error rather than an ambiguous negative. And if your case does not allow video, it accepts a photo — but you lose liveness, and that is worth saying up front rather than after.
Contracted through the contact form, defining use case, volume and tolerance. Tell us what you need to verify.