Read Client Stories
Alex Kugell
Key Takeaways
- Verification and identification are different things. Matching your face against your own stored template is 1:1 verification. Searching your face against a database of many people is 1:many identification. The law treats them very differently.
- Some uses are now prohibited in the EU, including real-time remote biometric identification in public spaces by law enforcement and untargeted scraping of facial images to build databases.
- Biometric onboarding is the largest commercial application, and the hard engineering problem is liveness detection rather than face matching.
- Injection attacks have risen sharply and now rival presentation attacks as a primary threat, meaning fraudsters feed synthetic video directly into the capture stream rather than holding up a photo.
- Accuracy varies by demographic group, which is well documented and remains a live fairness problem rather than a solved one.
- If you are building this into a product, the compliance question comes before the technical one.
Facial recognition identifies or verifies a person from an image of their face.
This can be broken down into two very different activities with very different legal status (verification and identification), and confusing them is the most common error in writing about this subject.
The EU AI Act made several facial recognition practices outright illegal from February of that year, with fines reaching €35 million or 7% of global turnover, while leaving others entirely routine.
Let’s go over where facial recognition is genuinely used in 2026, the distinction that determines which category you fall into, and what the engineering actually involves.
At Trio, our developers assist companies in integrating a variety of new technologies, like facial recognition, securely and compliantly, drawing from their production experience in financial applications.
Verification vs identification
Almost every disagreement about facial recognition dissolves once you separate verification and identification, allowing you to apply different regulations and security concerns to the different use cases.
1:1 verification compares a live face against one stored template to confirm someone is who they claim.
This includes things like unlocking a phone, logging into a banking app, or matching a selfie to a passport photo during account opening.
The person being verified usually participates knowingly, and there is no database of other people involved. In the EU, this generally sits outside the high-risk tier entirely.
1:many identification searches a face against a database to work out who someone is, frequently without their knowledge.
Think of things like police matching CCTV against a watchlist, or a retailer scanning entrants against a list of suspected shoplifters. This is where the regulation often gets involved, and where the civil liberties arguments live.
The technology underneath is similar, but identification has implications that verification does not.
How does facial recognition actually work?
Regardless of the application, facial recognition typically tends to follow four steps:
Detection finds a face within an image or video frame and isolates it from the background.
Alignment and normalization adjust for angle, lighting, and scale so the comparison is like-for-like. A face turned thirty degrees away, for example, needs correcting before anything useful happens.
Feature extraction converts the face into a mathematical representation, usually a vector of several hundred numbers called an embedding or faceprint. This is not a stored photograph. It is a numerical signature, and a well-designed system stores the embedding rather than the image.
Matching compares that embedding against one template, for verification, or against many, for identification, and returns a similarity score. The system then applies a threshold to decide whether the score counts as a match.
That threshold is where most of the practical argument sits.
Set it loose, and you get false matches. Set it tight and legitimate users fail verification.
Unfortunately, there is no setting that eliminates both, only a choice about which error you would rather make, and in a banking context those two errors have very different costs.
What is facial recognition used for?
At the moment, there are a couple of different uses for facial recognition that we are seeing used in the market.
1. Biometric onboarding and identity verification
The largest commercial application we have come across, and the one most likely to matter if you are building a product.
A customer opening a bank account photographs their identity document, then takes a selfie. The system verifies the document is genuine, extracts the photo from it, and matches it against the live selfie.
This is 1:1 verification; it satisfies KYC requirements in most jurisdictions, and it replaces a branch visit.
2. Device and account authentication
This involves things like phone unlocking, banking app login, and even payment confirmation. Apple’s Face ID popularized it, and Android equivalents have followed.
The security model is incredibly important here since, on well-implemented systems, the biometric template never leaves the device and is held in dedicated secure hardware. Ultimately, this means that there is no central database of faces to breach.
That architecture is a large part of why this use case attracts so little controversy compared with the others.
3. Border control and immigration
With the right software, automated passport gates can compare a traveler’s face against the chip in their document, which is 1:1 verification against a document the traveler presented.
Some border agencies also run 1:many searches against watchlists, which is a different proposition legally and attracts correspondingly more scrutiny.
4. Physical access control
Offices, data centers and secure facilities use face-based entry in place of badges that can be lent or lost. Generally 1:1 or 1:few against an enrolled staff list, with consent, which keeps it uncontroversial in most jurisdictions.
Employee biometrics carry specific obligations in several places.
Illinois in particular, where the Biometric Information Privacy Act has produced sustained litigation against employers who collected prints or faceprints without written consent.
5. Healthcare
In healthcare, facial recognition is used in patient identification to prevent record mix-ups, access control for controlled drug storage, and in assisted living, locating residents who have wandered.
The patient-matching case is the most valuable and the least discussed in the industry, since misidentification in a clinical setting causes real harm.
6. Retail and hospitality
Loss prevention systems matching entrants against lists of suspected shoplifters are 1:many identification, usually without consent, and have attracted regulatory action in several countries.
There has been a fair amount of concern around this, though.
In addition, the technology can be used in age estimation for restricted goods, which sits in a different position, since it infers an attribute rather than identifying a person.
7. Law enforcement
The law enforcement use case has driven a lot of public debate.
Post-event analysis, matching recorded footage against databases after the fact, is treated as high-risk under the EU AI Act rather than prohibited.
Real-time scanning of public spaces is prohibited with some very narrow exceptions.
Misidentification here has produced documented wrongful arrests, disproportionately affecting people of color, which is the strongest argument the technology’s critics make and a fair one.
8. Event and venue entry
Stadiums and large venues use face-based ticketing to speed entry.
What does the law now say?
The regulatory position changed materially in the last couple of years, and we expect it to continue changing as the industry evolves.
Prohibited in the EU since February 2025
The EU AI Act’s Article 5 prohibitions became enforceable on 2 February 2025. Four are directly relevant:
Real-time remote biometric identification in publicly accessible spaces for law enforcement, prohibited with narrow carve-outs for specific serious crimes, missing persons and imminent threats, and even then requiring prior authorization and a fundamental rights impact assessment.
Untargeted scraping of facial images from the internet or CCTV to build or expand recognition databases.
Biometric categorization to infer race, political opinions, religious beliefs, trade union membership or sexual orientation.
Emotion recognition in workplaces and educational settings.
Penalties reach €35 million or 7% of worldwide annual turnover, whichever is higher.
The next milestone was originally set for 2 August 2026, but the EU’s AI Omnibus has since pushed high-risk system requirements to 2 December 2027 for standalone systems and 2 August 2028 for high-risk AI embedded in other products.
Facial recognition in fintech: the real engineering problem
Biometric onboarding is where most commercial facial recognition work now happens, and the difficulty is not where people expect.
Face matching is close to a solved problem. Modern algorithms achieve very high accuracy under reasonable conditions.
The hard problem is proving the face in front of the camera belongs to a live human being who is physically present.
Liveness detection
There are two broad approaches to liveness detection at the moment.
Passive liveness analyses a single image or short video for signs of a real face, using texture, depth cues, and reflection patterns, without asking the user to do anything.
Active liveness asks the user to turn their head, blink, or follow a prompt. Passive is better because it adds no friction; active is harder to defeat.
From what we have seen, plenty of systems run both, with active triggered only on elevated risk scores.
Injection attacks have changed the threat.
In the past, we used to see a lot of presentation attacks, where people would hold a printed photo, a screen, or a mask in front of the camera. Liveness detection handles these reasonably well now.
Instead, the issue has shifted to injection attacks, where the fraudster bypasses the camera entirely and feeds synthetic video directly into the application’s capture stream using a virtual camera driver or a compromised SDK.
Generative AI has made producing convincing synthetic faces cheap, and the video never passes through a real lens, so every optical cue your liveness model relies on is absent.
Defending against this involves device attestation, detecting virtual camera drivers, SDK integrity checks, and analysing the capture pipeline rather than only the image.
What are the risks and criticisms?
A balanced view needs these, and most vendor-adjacent content skips them.
Accuracy varies by demographic group: Extensively documented, and while error rates have fallen substantially across the board, the disparity has not fully closed. In a 1:many identification context applied at scale, even a small differential produces unequal harm.
Misidentification has real consequences: Documented wrongful arrests have followed facial recognition matches treated as evidence rather than as a lead requiring corroboration.
Consent is frequently absent: You can change a compromised password. You cannot change your face, which makes biometric data categorically different from other credentials and raises the stakes on any breach.
Function creep: A system installed for one purpose tends to acquire others. Attendance monitoring becomes behavior monitoring. This is a governance problem rather than a technical one, which is precisely why it is hard to solve with engineering.
Chilling effects: Whether people should expect privacy in public spaces is a genuine political question rather than a technical one, and reasonable people land in different places on it.
Building with facial recognition
If you are adding biometric verification to a product, there are a couple of steps you can take:
Establish whether you are doing verification or identification: This determines nearly everything downstream.
Map your jurisdictions: EU, Illinois, Texas, and the UK all impose different obligations.
Define your retention policy before you collect anything: How long you hold templates, and what deletion means in practice.
Choose a vendor on injection attack defense, not on matching accuracy.
Design the failure path properly: A meaningful share of legitimate users will fail verification, and what happens next determines whether they stay a customer.
Log for audit from day one: Retrofitting evidence trails under regulatory pressure is considerably more expensive.
Teams doing this well usually combine AI developers who understand the model behavior with backend engineers who can build the orchestration, plus someone who has worked under KYC and AML obligations before. That combination is scarcer than any one of the three.
At Trio, we place senior engineers with production experience in regulated financial environments through staff augmentation, dedicated teams, or software outsourcing.
Our fintech engineering covers the compliance requirements that sit around work like this.
See how we work or request a consult.
