Face verification answers a specific question: Does the current user’s face match a trusted reference image?
Instead of returning a simple yes or no, a facial comparison system usually produces a numerical score. The business then compares that score with a configured threshold to determine whether the result should be accepted, rejected, or reviewed.
Face++ Face Comparing supports this 1:1 verification process by comparing two face images or face tokens and returning a confidence score together with reference thresholds. Face++ Face Comparing
1. What Is a Facial Comparison Score?
A facial comparison score represents the similarity between the biometric features extracted from two face images.
A typical verification flow uses:
- A trusted reference, such as an identity document portrait or enrolled account image
- A current face captured during onboarding, login, recovery, or transaction authorization
- A face comparison model that converts both faces into biometric feature representations
- A score measuring how closely those representations correspond
A higher score indicates stronger similarity. However, the score should not be interpreted as absolute proof of identity. It is a model output that must be evaluated against a threshold appropriate for the specific algorithm, version, dataset, and business scenario.
2. How a Score Becomes a Match Decision
The comparison score becomes actionable only when it is evaluated against a threshold.
For example:
- Score above the threshold: Treat as a potential match
- Score below the threshold: Treat as a non-match
- Score near the threshold: Request another capture or additional verification
The threshold controls the balance between security and conversion. A lower threshold accepts more users but may increase false matches. A higher threshold reduces false matches but may reject more legitimate users.
Face++ APIs provide reference thresholds to help interpret comparison results. Businesses should still validate the operating point using their own user population, capture conditions, attack exposure, and risk appetite.
3. False Acceptance and False Rejection
Two error rates are especially important when selecting a threshold.
False Acceptance Rate
The False Acceptance Rate, or FAR, measures how often the system incorrectly accepts two different people as the same person.
Reducing FAR is usually the priority for high-risk use cases such as financial transactions, account recovery, or access to sensitive information.
False Rejection Rate
The False Rejection Rate, or FRR, measures how often the system incorrectly rejects two images of the same person.
A high FRR creates unnecessary friction, repeated captures, manual reviews, and user abandonment.
Increasing the threshold usually reduces false acceptance but increases false rejection. Threshold selection is therefore a business and security decision, not just a technical configuration.
4. Why the Same Person Can Receive Different Scores
Two images of the same person do not always produce the same score. Comparison quality can be affected by:
- Blur or low resolution
- Strong backlighting or shadows
- Extreme head pose
- Partial facial obstruction
- Significant expression differences
- Glasses, masks, or heavy makeup
- Age differences between images
- Cropped or compressed document portraits
- Screen recapture or printed-photo artifacts
Poor reference images can limit performance even when the live capture is clear. Digital platforms should therefore apply image-quality checks before relying on the comparison score.
If quality is insufficient, requesting a recapture is often more appropriate than interpreting a low score as confirmed fraud.
5. Why Scores Are Not Universal
A score of 75 from one facial comparison model does not necessarily represent the same risk as 75 from another model.
Score distributions can change across:
- Algorithms and model versions
- Web APIs and device-side SDKs
- Demographic and geographic datasets
- Cameras and capture environments
- Reference-image types
- Image preprocessing methods
Face++ notes that performance figures and thresholds from its Face Comparing SDK do not automatically apply to other Face++ products because their algorithms and operating environments may differ. Face++ Face Comparing SDK
Businesses should therefore avoid copying a threshold from another product, market, or deployment without validation.
6. Face Match and Liveness Solve Different Problems
A strong comparison score answers: Do these two facial samples appear to belong to the same person?
It does not independently answer: Was the current sample captured from a genuine live person?
An attacker may use a high-quality photo, replayed video, face swap, mask, or injected media that resembles the legitimate customer. If the comparison layer evaluates only facial similarity, the resulting score could still be high.
Face++ liveness detection adds genuine-presence analysis. In a layered workflow:
- Capture integrity evaluates whether the media follows a trusted capture path.
- Liveness detection checks for presentation and injection attacks.
- Face comparison measures similarity with the trusted reference.
- Risk decisioning combines biometric, document, device, and session evidence.
A high comparison score should not override a failed liveness or capture-integrity result.
7. Risk-Based Thresholds for Different Events
Using one threshold for every situation may create either excessive risk or unnecessary friction.
A platform may apply different policies for:
- Routine login: Moderate threshold with trusted-device evidence
- New-device login: Higher threshold or additional liveness
- Account recovery: Strong face match, liveness, and recovery-risk checks
- Profile change: Step-up verification before updating trusted information
- High-value transaction: Higher assurance and transaction-risk analysis
- Uncertain result: Recapture or manual review instead of immediate rejection
The Face++ comparison score can contribute to this policy, but it should not determine the outcome alone. Device reputation, document results, liveness, account history, and behavioral context can materially change the decision.
8. How to Select and Monitor a Threshold
Threshold design should be based on real operating data rather than intuition.
A practical process includes:
- Building a representative set of genuine and impostor comparisons
- Measuring score distributions across important user groups and capture conditions
- Selecting target FAR and FRR levels
- Testing separate thresholds for different risk scenarios
- Creating a review or recapture band around uncertain scores
- Monitoring fraud loss, conversion, retries, and manual-review rates
- Revalidating thresholds after model, camera, or workflow changes
Platforms should also log the model version, threshold, input quality, liveness result, and final decision. This improves auditability and helps explain why a verification session was approved or escalated.
9. Frequently Asked Questions
Q1. Is a facial comparison score the probability that two faces are the same person?
It is better treated as a model-specific confidence or similarity measure. Its operational meaning depends on the algorithm and the threshold established through testing.
Q2. Does a higher facial comparison score always mean the user should be approved?
No. A high score can still occur in a spoofing or injection attempt. The result should be combined with liveness, capture integrity, device, and session evidence.
Q3. What should happen when a Face++ score is close to the threshold?
The platform can request a better capture, apply Face++ liveness detection, use additional identity evidence, or route the session for review.
Q4. Should every customer use the same threshold?
Not necessarily. Risk-based policies can apply different verification requirements according to the event, transaction value, device confidence, and consequences of an incorrect decision.
10. Turn Scores into Risk-Aware Decisions
Facial comparison scores are most valuable when they are treated as evidence rather than final decisions.
By combining Face++ face comparison with image-quality controls, liveness detection, secure capture, and contextual risk signals, digital platforms can reduce false acceptance while managing false rejection and user friction. The goal is not simply to maximize the score—it is to make a proportionate identity decision with enough evidence for the risk involved.
