...

Biometric authentication: login and confirmation of operations by face

Biometric authentication confirms that the login, transfer or change of data is made by the same person you have already verified. The customer looks into the front camera, NeuroVision checks that a live person is in front of it, not a photo, mask or deepfake, and matches the face against the reference. The face authentication route is chosen under 572‑FZ: the Unified Biometric System (EBS) with an accredited organisation, or a repeated check by document.

Confirming an action by face

1:1 matching against a single customer reference, not a search
up to 6 h lifetime of a check session (from 15 minutes)
from 13 ₽ per repeated face check
Web SDK and WebView in the app Result in the API and the webhook The decision stays in your system

The price is the “Liveness check” package of the price matrix calculator at 100 000 sessions a year; at 10 000 it is 15 ₽

Biometric authentication by face: is this the person you have already verified

A look into the camera instead of an SMS code

Identification answers the question “who is this” and is done once, at registration, by document. Authentication answers the question “is this him again?” and is repeated every time the customer logs in or performs an action.

  • 01

    1:1 matching, not a search

    The platform does not look for the person among all customers but matches them against a single reference linked to the account in advance: the face from a previous check or the photo in the document that the customer shows right now. If you need to find out whether this person is among other accounts, that is a 1:N search, covered on the page about searching for a person by face in a database.

  • 02

    Without live presence, matching is worthless

    A customer's photo can be found on social networks, and a video can be generated. That is why face authentication always starts with Liveness: first the platform makes sure that a live person is in front of the camera, and only then compares their face with the reference.

  • 1:1 matching against a single customer reference
  • up to 6 h lifetime of a check session
  • Liveness before the face is compared

Six moments when an SMS code is not enough

An SMS code confirms that the person holds a phone, but not that they are the account owner. SIM cards are reissued on a forged power of attorney, and codes are extracted by phone. A face check goes where a mistake costs the most.

  • Login from a new device

    Biometric login to the app when the account is opened on a phone that was not used before. On a familiar device the customer logs in as usual; the face check is only for a change of device.

  • Access recovery

    The customer forgot the password, lost the phone or changed the number. Access reset is a favourite point for account takeover: a fraudster calls support on behalf of the owner. A face check stops them before the password is changed.

  • Large transfer or withdrawal of funds

    Confirming a payment by face when the amount is above a threshold, the recipient is new or the withdrawal goes to an external wallet. Ordinary payments go through without extra steps.

  • Change of details and contacts

    A new card for payouts, a new phone or email in the profile. After such a change the fraudster gets both the money and control of the account, so it is confirmed separately.

  • Signing an application or contract

    A loan application, consent to a deal, confirmation of an instruction. The face confirms the intent of the person who passed the check at registration.

  • Start of a shift or an order

    A courier, driver or contractor confirms that it is really them working, not the person to whom the account was handed over or sold.

Four lawful routes of face authentication after 572‑FZ

Since 2023 organisations have been prohibited from keeping customers' biometrics for identification and matching faces against it for authentication, except for matching against the EBS (Part 1 of Art. 15 of 572‑FZ). So the route is chosen first, and only then the technology.

  • Via the EBS and an accredited organisation

    The main route, named directly in the law. The customer submits biometrics to the Unified Biometric System once, and your company confirms their actions through the information system of an accredited organisation, which matches the face against EBS vectors (Part 4 of Art. 16 of 572‑FZ). So that a spoof does not reach matching, a live presence check is placed before it; how it fits into your process is determined at connection. How to connect the EBS

    Suitable for:

    Banks, brokers, fintech, anyone who needs legally significant authentication

  • Repeated check by document and selfie

    The reference is not stored: at the moment of risk the customer photographs the passport again and takes a selfie with Liveness, and the platform matches the face with the photo in the document and compares the document data with the account data. It takes longer than a look into the camera, but suits rare actions such as access recovery or a change of details. Check by passport and selfie

    Suitable for:

    For access recovery and rare operations

  • Matching against a reference KYC session

    The new check is linked to the customer's previous successful session, and the face in Liveness is matched with the face from it. You receive only a “match / no match” answer, without photos and personal data. Whether this route can be used in your process, and on what basis, is decided by your lawyer before launch.

    Suitable for:

    At a lawyer's decision

  • Device biometrics plus Liveness

    For daily login, the smartphone's built-in face unlock: matching happens on the device, and your company does not receive the biometrics. NeuroVision face checks are kept for the risky actions from the block above, when a phone unlock alone is not enough.

    Suitable for:

    For frequent login to the app

How confirming an operation by face works

Face authentication fits into your scenario as a single step: the app requests a check, the customer looks into the camera, your system receives the answer and decides whether to carry out the operation. Example: confirming a transfer in the app.

Step 1

The app requests a check

The customer submits a transfer above the threshold. Your server creates a check session and specifies which reference to compare the face with: the photo in the document or the customer's previous check. The session lives from 15 minutes to 6 hours; after that it cannot be completed.

The app requests confirmation of a transfer
Step 2

The customer passes Liveness

The screen shows a short explanation and consent, then the camera oval. The customer brings their face closer to the camera. Liveness makes sure that a live person is in front of the camera, not a photo, screen, mask or video.

The customer passes Liveness
Step 3

The platform compares the face

The live face is compared with the reference. At the same time the frame is searched for signs of a deepfake, face swapping and extraneous faces.

The face is compared with the customer's reference
Step 4

Your system makes the decision

The result arrives via the API and by webhook: match, no match or could not be checked, with the reason. Match: the operation goes through. The face of another person: the session gets the status “suspicious” and is closed; you stop the operation and pass it to the security team.

The check result in your system

A second biometric factor: strictness for the amount and risk of the operation

  • False acceptance is the main risk for money

    The probability that the system takes someone else's face for the customer's face is called FAR. For withdrawals and changes of details it must be minimal: here it is better to ask the customer to try again once more than to let a fraudster through.

  • False rejection is the main risk for conversion

    The probability of not recognising the real customer is FRR. Poor light, an old camera, glasses with glare. For login to the app the strictness is lower: a customer who is refused three times goes to a competitor.

  • The threshold depends on the operation

    A transfer between your own accounts and a withdrawal to a new external wallet carry different risk. Set the rules in your own system: up to what amount a password is enough, where a face check is needed, and where a face and document check is needed. The rules and the decision on the operation stay on your side.

  • The face is a factor, not the only key

    Biometrics are not used alone for the most dangerous actions: they are combined with what the customer knows and with the device they work on. Passwordless face login is good for convenience, but a transfer of all savings is confirmed with two factors.

Any biometrics has two errors: letting a stranger in and not letting your own customer in. The stricter the check, the less often the first and the more often the second occurs. So strictness is chosen not for the whole app but for each action.
How to choose an algorithm and metrics is covered in the article “A face recognition system: how it works and where it is used”.

What is checked while the customer looks into the camera

Face matching is the last step. Before it, the platform filters out everything that fakes a live person and checks whether the frame can be trusted at all.

  • A printout, a photo on a phone or tablet screen, a photo from social networks in front of the camera Refusal
  • A mask or a recorded video with blinking instead of a live face Refusal
  • The customer did not fit into the oval, turned away or left the frame Try again

  • Deepfake: the face is generated by a neural network (GAN, diffusion models) Suspicious session
  • Face swap in the frame Suspicious session
  • More about classes of attacks is on the page about deepfake protection

  • The face in Liveness matches the customer's reference: the photo in the document or a previous check
  • The face of another person: the session is closed immediately Suspicious session
  • The reference is unusable, for example it contains no face: a repeated check by document is needed Try again

  • There are extraneous faces in the frame: someone is prompting or holding the phone Scenario setup
  • A medical mask, glasses, a headwear: the platform detects them, and whether to allow them is up to you Scenario setup
  • Weak light or the face is covered by a hand Try again
  • “Rejected”: the check is not passed, the customer can try again
  • “Suspicious session”: a sign of deception, the operation is stopped and passed to the security team
  • “Scenario setup”: enabled in the KYC editor
  • “Try again”: the customer is shown a hint on what to fix

Face authentication and the law: 572‑FZ, the EBS and customer consent

A face image used to confirm identity is biometric personal data. Two laws apply to it: 152‑FZ on personal data and 572‑FZ on identification and authentication by biometrics. Below is a summary of the norms as of October 2026. It is a guide for a conversation with a lawyer, not a legal opinion.

  • In the information systems of organisations, sole proprietors and notaries it is prohibited to process, including to collect and store, biometrics used for identification, except for collection for placement in the EBS (cl. 1 of Part 1 of Art. 15 of 572‑FZ) 572‑FZ
  • Biometrics for authentication may be processed only to confirm a match with EBS vectors under the conditions of Art. 16 (cl. 2 of Part 1 of Art. 15 of 572‑FZ) 572‑FZ
  • Biometrics presented for authentication may be stored for no longer than 10 days, to review customer complaints, and are then destroyed (cl. 3 of Part 1, Part 2 of Art. 15 of 572‑FZ) 572‑FZ

  • A company may use the system of an accredited organisation to confirm a customer's action, intent or authority, if the customer has given consent (Part 4 of Art. 16 of 572‑FZ) 572‑FZ
  • Before authentication, customer data from your system is matched with ESIA, and only after that does the organisation receive identifiers for matching (Part 6 of Art. 16 of 572‑FZ) 572‑FZ
  • You must apply personal data protection measures and certified cryptographic protection tools (Part 5 of Art. 16 of 572‑FZ) 572‑FZYour company

  • An organisation that matches faces against EBS vectors in its own system is accredited: own funds of at least 500 million roubles, financial security of liability of at least 100 million, databases only in Russia, an FSB licence for encryption tools, connection to GosSOPKA (Part 2 of Art. 17 of 572‑FZ) 572‑FZ
  • The accreditation procedure is the Rules approved by Government Resolution No. 810 of 22.05.2023 572‑FZ

  • Authentication with cross-border transfer of biometrics is prohibited (Part 21 of Art. 3 of 572‑FZ) 572‑FZ
  • The retention period of session data is set in the scenario, and personal data is destroyed on request via the API NeuroVision
  • Where data is processed and on what terms is fixed in the contract NeuroVisionYour company

  • The law does not apply to matching performed not by an automated system but by an authorised employee (cl. 2 of Part 2 of Art. 1 of 572‑FZ) 572‑FZ
  • Nor to operational-search activity, defence, state security, migration registration and the issue of identity documents (cl. 1 of Part 2 of Art. 1 of 572‑FZ) 572‑FZ
  • Whether your scenario falls under an exception is decided by a lawyer: for a commercial service the exceptions of Art. 1 generally do not apply Your company
  • The summary of the norms is simplified: 572‑FZ as amended on 28.12.2024, 152‑FZ as of October 2026; check the current versions in ConsultantPlus. How the EBS works and how it differs from commercial biometric systems is covered in the article “The Unified Biometric System (EBS)”; how to store biometrics in KYC is covered in “On-premises or cloud KYC”.

Who needs confirmation of actions by face

Wherever an account holds money, access to property or the right to act on behalf of a person.

  • Banks and payment services

    • Confirming banking operations by face
    • Login to the banking app from a new phone
    • Change of the number linked to the account Learn more
  • Brokers and investment platforms

    • Withdrawal of funds to new details
    • Signing instructions
    • Recovering access to an account Learn more
  • Crypto services and wallets

    • Withdrawal to an external address
    • Change of device and access keys
    • Protection against account takeover via support Learn more
  • Car sharing and rental

    • The account owner is behind the wheel, not the person it was handed to
    • Confirmation before an expensive tariff
    • Protection against account resale Learn more
  • Contractor and delivery platforms

    • Confirmation before a shift or an order
    • Change of the card for payouts
    • Protection against account “renting” Learn more
  • Marketplaces and online services

    • Change of seller details
    • Login to the personal account from a new device
    • Confirmation of an online exam or an 18+ subscription

If the customer cannot or does not want to pass a face check

  • Did not submit biometrics to the EBS

    Offer a customer without EBS vectors a repeated check by document and selfie, or the previous method of confirmation. Do not make submitting biometrics a condition of using the service.

  • Refused the face check

    Keep the password and the one-time code, but add restrictions on risky actions: a withdrawal limit, a delay when details are changed, a call from support.

  • Genuinely cannot pass the check

    An old camera, poor light, a facial injury. After several failed attempts, switch the customer to a document check or to an employee rather than blocking the account.

  • The fallback route is not a loophole

    A fraudster will choose the weakest method. So access recovery without a face must be no easier than with a face: a document, a delay, confirmation through an old contact.

The law expressly prohibits refusing service to someone who does not agree to biometrics (Part 13 of Art. 3 of 572‑FZ, Part 3 of Art. 11 of 152‑FZ). A fallback route is needed even before launch, and it must not be a loophole for a fraudster.
A scenario without a face step is built separately in the KYC editor, with document verification and anti-fraud. When and how to re-check customers is covered in the article “Repeated KYC”.

How much a repeated face check costs

The price is per check session with all attempts. The reference is usually created once, at customer registration, and each subsequent confirmation is a short face check without a document.

  • Document + liveness

    from 29 ₽ per session

    Enable the package

    Initial check at registration: document, document anti-fraud, selfie or Liveness, matching the face with the photo in the document. The same session is a repeated check by document for access recovery.

  • For confirming operations

    Liveness check

    from 13 ₽ per session

    Enable the package

    Liveness without a document: protection against photos, screens, masks and deepfakes, signs of face swapping and extraneous faces, matching with the customer's reference.

  • Face API

    on request

    Calculate the price

    1:1 matching via the API with your own capture interface. Terms and price depend on your scenario.

The “Liveness check” in the price matrix calculator costs 15 ₽ per session at 10 000 sessions a year, 14 ₽ at 50 000, 13 ₽ at 100 000. “Document + Liveness” is 33 ₽ at 10 000. The first month is a free test, payment only for completed checks. An exact calculation is in the the calculator in the price matrix.

Connection: Web SDK, app, KYC link or REST API

The face check is embedded in your website, personal account or mobile app. The scenario and checks are changed in the personal account without development.

Confirmation by face on the website and in the personal account

The widget is connected by a script or an npm package and works in the browser on a computer and a phone. It shows hints, the consent screen and repeated attempts; the logo, colours and texts are configurable. Web SDK documentation

  • Result in the webhook and the API
  • No personal data in the response with a reference
  • Scenario in the KYC editor
  • Documentation and demo

Terms of connection

1 month test, a personal manager, support under contract, payment for checks.

Glossary: authentication, reference, EBS and Liveness

Terms you will meet in the contract, the API response and a conversation with a lawyer.

Biometric authentication
Confirmation that an action is performed by the same person, by their face or other biometrics. Login, transfer, signing, each time anew.
biometric authentication
Identification
Establishing a person's identity, as a rule by document. It is done once, at registration.
identification
1:1 matching
Matching a face against a single reference of a specific customer. It answers the question “is this him?”.
face match
Reference
A face image or template against which the live face is compared: the photo in the document or the customer's previous check.
reference
Biometric template
A numeric vector into which a face is turned. Templates are compared, not photographs.
face template
UBS
The Unified Biometric System is a state system through which organisations carry out identification and authentication by biometrics. More — in the article about the UBS.
Unified Biometric System
Accredited organisation
A company that under Art. 17 of 572‑FZ may match faces against EBS vectors in its own system and provide authentication to others.
accredited biometric provider
Liveness
A check that a live person is in front of the camera, not a photo, a video, a mask or a deepfake.
liveness detection
FAR and FRR
The shares of false acceptances (a stranger let in) and false rejections (your own customer not let in).
false accept / false reject rate
Second factor
Additional confirmation for a risky action on top of a password or login.
step-up authentication
Passwordless login
Login without entering a password: by face, a device key or a link.
passwordless login

Licences and certificates

Innovation Promotion Foundation

The project «Development of a multimodal system using artificial intelligence "Neuromed" for managing the diagnostic processes of a clinic on the basis of the "Neurovision" computer vision platform» is supported by the Innovation Promotion Foundation within the federal project «Domestic Solutions»

We will select a face confirmation scenario

Tell us which customer actions you want to confirm and whether you have access to the EBS, and we will propose a lawful route and the strictness of the check, and calculate the price.

Can't put your request into words? Book a call and our team will contact you at a convenient time

Book a call

The 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.

Frequently asked questions about biometric authentication

It is confirmation that a login or operation is performed by the same person the company has already verified. The customer looks into the front camera, the system checks that a live person is in front of it, and compares their face with the reference: the photo in the document or a previous check.

Yes, but sensibly. For daily login the smartphone's own biometrics are the most convenient: matching happens on the device. NeuroVision face checks are placed on risky actions: login from a new device, access recovery, a large transfer, a change of details.

For organisations, as a general rule, no. Part 1 of Art. 15 of 572‑FZ prohibits processing biometrics for identification in one's own systems (except collection for the EBS), and for authentication only matching against EBS vectors under the conditions of Art. 16 is allowed. So the route is chosen before launch: the EBS via an accredited organisation or a repeated check by document.

The customer must submit biometrics to the EBS and give consent to authentication. Your company connects to the system of an accredited organisation (Part 4 of Art. 16 of 572‑FZ). What role the NeuroVision live presence check plays in this process is determined at connection; we will select a scenario at a consultation.

Offer a repeated check by document and selfie with Liveness: the reference is not stored, and the face is matched with the photo in the document that the customer shows right now. Or keep the previous method of confirmation with restrictions on risky actions.

Liveness filters out printouts, screens, masks and recorded video, and the frame is searched for signs of a deepfake and face swapping. If the frame shows signs of substitution or the face of another person, the session is marked as suspicious and closed. There is no absolute protection, so the decision on the operation stays with your system.

For the customer, a few seconds: bringing the face closer to the camera. With Liveness the check takes from a few seconds to a minute, depending on how quickly the customer performs the actions. The check session is valid from 15 minutes to 6 hours; after that it must be created again.

No. Refusal of authentication by biometrics cannot be a reason to refuse a service or servicing (Part 13 of Art. 3 of 572‑FZ), and providing biometrics cannot be mandatory (Part 3 of Art. 11 of 152‑FZ). Keep a fallback route, but no easier than the route with a face.

A face check is an explicit customer action at the moment of the operation. Behavioural biometrics quietly analyses how a person types, touches the screen and moves the mouse. They are combined: behaviour signals a risk, the face check confirms the action. More in the article on behavioural biometrics.

The “Liveness check” package is from 13 ₽ per session; at 10 000 sessions a year it is 15 ₽. The initial check at registration, “Document + Liveness”, is from 29 ₽. Face API is on request. The first month is a free test. The calculation is in the price matrix.