Searching for a person by face in a database — is matching one face against all the faces in your own database: past KYC‑sessions, the blacklist and person lists. The platform shows that this person has already been checked under a different passport or is on a stop list, and returns the match with a confidence score. What to do next is up to you. The search covers only the database you have built, with the consent of the people concerned.
Search across your face database
The price follows the price matrix on the publication date
Anyone who has passed a check once will be recognised next time — even with a different passport, phone and device.
Face search in a database answers not “is this the same person as in the passport?” but “have we seen this person before — and under what name?”. In 1:1 comparison a face is matched against a single photo; in 1:N search, against all the faces in the selected lists: past customers, employees, the stop list. 1:1 comparison is covered in detail on the page about face recognition.
The search covers the faces you have collected: from your own KYC‑sessions, uploaded files and your cameras. There are no open sources, social networks or other people’s databases in the search.
The platform returns not a name but candidates: a list entry, the session where the face appeared, and the match confidence. How many candidates to show and from what threshold — is up to you.
A match with the blacklist or a past session flags the check as suspicious. Whether to block, send for manual review or let through — is decided by your employee or a scenario rule.
The mechanics are the same — a face is matched against a list. The tasks differ: which list, where its faces come from and what to do on a match.
On every new check the face is matched against the faces from past sessions. If the same person has already been checked with a different passport or other data, the session gets the “suspicious” status. Typical cases: loans and credit under different passports, bonuses and promo codes for new customers, multiple accounts of sellers and contractors, finding linked accounts.
A face from a session is added to the blacklist in one click. On the next attempt the platform rejects the session, even if the person brings another passport and gives a new phone number. Suitable for fraudsters and mules, customers with confirmed fraud and contractors removed from the platform.
A person list can be built from photos: upload files in the console or send them via API. Each person has their own fields: reason for adding, department, validity period. This is how a visitor stop list, a list of employees and contractors, or an event attendee list is kept.
The source of faces can be a camera, a folder of photos or archived video. When a face from the list appears in a frame, the system sends an alert to the responsible employee. This covers access to a site by list, a stop list at a venue and search of your frame archive.
Searching for a face in a database takes four steps. In a KYC scenario they run on their own in every session; in Face API — on your request. How face recognition works in general is described on the page about face recognition
Faces enter the database from your KYC sessions automatically, from uploaded photos or via API. The customer gives consent before filming, and Liveness Liveness at the entrance keeps screen photos and masks out of the database — the list stays clean.
A biometric template is built for each face — a numeric vector. The search compares templates, not photos. A face that is too small or turned too far will not enter the database: the minimum size and permitted rotation are set in the settings.
A new photo or frame is matched against all the faces in the selected lists: past customers, the blacklist, the stop list. You can search several lists at once and set a confidence threshold.
The response is the best candidate or all matches above the threshold, with a confidence score and a link to the record. In KYC a match changes the session status; in Face API — it goes to your system or as an alert to an employee.
On every new check the customer’s face is compared with the faces from the past sessions of your account. No separate request is needed — the feature is enabled in scenarios.
If the same face has already appeared with a different document, name or date of birth, the session gets the “suspicious” status. Such a customer cannot pass the check automatically.
In the console the identifier of such a session is highlighted in red. A click opens the list of all sessions where this face appeared — with dates, documents and outcomes.
A person may have changed their passport at 20 or 45, got married or simply forgotten that they had already registered. That is why a match is a reason for manual review, not an automatic refusal.
The session export includes a mark of the customer’s first visit to your system. The report can be filtered: new only, returning only or all.
Duplicate search complements authenticity checks: a forged document is caught by anti-fraud, while an impostor with a genuine passport belonging to someone else is caught by matching the selfie with the photo in the document.
A forged or someone else’s passport can pass a document check. A face is harder to fake: someone who comes a second time is recognised by face, not by the form data.
Other signals that help find linked accounts at registration — phone, device, document stop list — are described on the page about registration anti-fraud.
A passport stop list can be bypassed with a new passport. A face blacklist cannot: it relies on the face, not on the document data.
In the session card the employee clicks the crossed-out circle icon and confirms the action. The face goes to your account’s blacklist; no development on your side is needed.
If the face in a new session matches a face from the blacklist, the session is rejected with the code [fraud] black list, and the console shows the note “User is on the blacklist”.
The check works in scenarios where “Face blacklist” is selected. You can keep different scenarios for different products: for example, a strict one for issuing a loan and a lenient one for a subscription.
Record in the person’s card why the person was added and until when. Review the list: keeping a face on the blacklist longer than your purpose requires is not allowed — this is a personal data processing requirement.
You set the confidence threshold
The database query specifies the minimum match confidence. For the blacklist the threshold is usually set higher, so as not to turn away an honest customer; for duplicate search — lower, with disputed cases sent for manual review.
The best candidate or all
You can get the single most similar face or all matches above the threshold. The second option is needed when one person may have registered several times.
Database quality matters
False matches are more often caused by small, blurred and side-angle photos in the database itself. That is why faces below the set size and with a strongly turned head are not added to the list, and Liveness filters out screen captures.
Errors go both ways
The system may show the wrong person (a false match) or fail to find the right one (a missed match). Photo quality and database size affect this, so a person makes the decision on a match, and accuracy for your database is best checked in a test scenario with your data.
The larger the database, the more the threshold matters. A high one — fewer false matches, but a higher risk of missing the right person. A low one — the opposite. The setting depends on what is at stake.
How algorithm accuracy is compared and where recognition errors come from is covered in the article “Face recognition accuracy in KYC”.
A face used to establish who is in front of you is biometric personal data. Strict rules apply to its processing by organisations in Russia, and database search falls directly under them. Below are the provisions your scenario depends on. This is a guideline, not a legal opinion: agree the design with a lawyer.
The query “search for a person by face” often means searching by photo on the internet. That is not our scenario — and here is where the boundaries lie.
The search covers only your account’s database. You cannot use NeuroVision to find an unknown person by photo in open sources.
The search does not include government databases, databases of other NeuroVision customers or purchased lists. Each account has its own isolated database.
If the face is not in your lists, the result is “no matches”. The platform does not guess who it is.
A match is a signal. Whether to refuse, block or let through — is decided by your employee or a rule you have set.
If the law requires you to identify a customer by biometrics, this is done through the Unified Biometric System. Search in your own database serves anti-fraud.
You set the list, cameras and retention periods as the data operator. Without a purpose, consent or a legal basis a face is not added to the database.
Face search is needed wherever one person can come back — for money, a bonus or access that has already been refused.
In KYC, duplicate search and the blacklist are included in the session price. Separate search across your lists via Face API and on-premises installation are priced by volume.
The “Document + liveness” package: document recognition and anti-fraud, selfie, Liveness, face-to-document matching, search across face lists and blocking by the blacklist.
on request
Person lists, search across several lists with a confidence threshold, match alerts, sources — files, cameras, archive. Pay per request.
on request
Installation on your servers: the face database and search never leave your infrastructure. For banks, state-owned companies and sites without internet access.
At 10 000 KYC‑sessions a year the “Document + liveness” package costs 33 ₽ per session, at 50 000 — 30 ₽, at 100 000 — 27 ₽. You pay only for completed checks; test scenario terms are available from a manager. For an exact calculation, see the calculator in the price matrix.
Face search works in the NeuroVision cloud or in your perimeter. The scenario and lists are configured in the console. Get a test scenario
A test scenario on your account, cloud or your own server, payment only for completed checks.
Terms you will meet in the account, the API response and in conversation with a lawyer.
Tell us whom and where you want to recognise — customers at onboarding, blocked users or visitors to a site — and we will advise which list is needed, how to obtain consent and how much it will cost.
Can't put your request into words? Book a call and our team will contact you at a convenient time
Book a callThe company is included in the register of IT companies and the register of personal data operators of the Russian Ministry of Digital Development.
Address: Moscow, Presnenskaya Embankment 12 — Moscow City business centre, Federation Tower. Nearest metro stations: Delovoy Tsentr and Mezhdunarodnaya.
How face recognition works, how algorithm accuracy is checked and where the legal boundary lies — in our blog
It is matching one face against all the faces in your own database: past KYC‑sessions, the blacklist, lists of employees or visitors. The platform shows matches with a confidence score, and your company makes the decision on them.
1:1 comparison answers the question “is this the same person as in the passport photo?”. 1:N search answers “have we seen this person in our database and under what name?”. In technical literature, 1:N search is called face identification against a database.
No. NeuroVision searches only your account’s database — the faces you collected yourself with the consent of the people concerned. There are no open sources, social networks or other people’s databases in the search.
Enable search across past sessions in the KYC scenario. If the face has already appeared with a different document or data, the session gets the “suspicious” status, and the console opens the list of all this person’s sessions.
An employee adds a face from a session to the blacklist in one click. On the next attempt the session is rejected with the code [fraud] black list, even if the person brings another passport: the check relies on the face, not on the document.
Yes, in the console. It has person lists: photos are uploaded as files or via API, and each record gets its own fields — for example, a reason and a term. You can search several lists at once.
Yes, as with any recognition: the system may show the wrong person or fail to find the right one. Photo quality and database size affect this, so you set the confidence threshold, and disputed matches are checked by an employee. Accuracy for your database is best checked in a test scenario with your data.
A face image used to establish identity is biometric personal data: written consent is required (part 1 of Art. 11 of 152‑FZ), and 572‑FZ restricts the processing of biometrics by organisations outside the EBS. Legality depends on the purpose and procedure of the check — agree the design with a lawyer before launch.
In the NeuroVision cloud or on your servers when installed in the perimeter. The session retention period is set in the scenario. Session data is deleted on request — one session or all of a user’s sessions at once.
In KYC, search across past sessions and the blacklist are included in the “Document + liveness” package — from 29 ₽ per session. Face API and on-premises installation are priced by volume; test scenario terms are confirmed by a manager.
