How to compare two faces with Myaza Trust
Compare two face photos when you need a 1:1 similarity verdict. This check is separate from liveness and from searching a customer book.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- Sandbox match, review, no_match and no_result are handled separately.
- Consent and photo-size requirements are enforced.
- The application stores and re-reads the check ID.
- A simulated verdict is never presented as a live engine result.
Compare two face photos when you need a 1:1 similarity verdict. This check is separate from liveness and from searching a customer book.
Before you begin
Two clear face photos
Permission and consent to compare the photos
Use a team member with permission for this control. Check the organisation and environment before changing a setting. Review the current price before a paid check or ongoing enrolment. Screenshots show an example workspace or the public integration reference; they do not show a real customer or a completed paid check.
Set up and use the capability
Step 1: Open Face match and choose the environment
In the dashboard, open Verification → Spot Checks → Face match. Choose Sandbox for your first test. Check that Spot Checks is available to your organisation and that your role can run the comparison. The standalone API uses the same engine and verdict history. Sandbox returns simulated outcomes; it cannot prove real-photo matching accuracy.
Integration reference: Sandbox behaviour
Step 2: Prepare two different, clear photos
Use two consented photos with a readable face in each. JPEG, PNG and WebP are supported. Do not send the identical photo twice. Upload each photo into its own side of the Face match form and confirm the consent requirement. Review the displayed organisation thresholds rather than expecting a per-request threshold to override the recorded policy.
Integration reference: Compare
Step 3: Review thresholds and run the comparison
Check your organisation’s match threshold and review floor before running a paid Production comparison. Run the two-photo check once and keep its check ID. A match is the engine’s similarity verdict at the recorded threshold; it does not prove the person is live or controls an account. Where manual review is required, compare the photos and record your policy decision separately.
Integration reference: The verdict
Step 4: Integrate the same comparison on your backend
Call POST /api/kyc/face/compare using a secret key and consent: true. Supply exactly one photo source for each side: imageA or mediaAId, and imageB or mediaBId. An image can be a supported public URL, data URI or base64. For reusable files, upload them through POST /api/kyc/face/upload and pass the media IDs. Keep biometric inputs and secret keys server-side.
Integration reference: Uploading first (optional)
Step 5: Handle all four verdicts
Read faceCheck.verdict, confidence and the thresholds recorded with that check. match is at or above the pass mark; review lies between the floor and pass mark; no_match is below the floor. no_result means no comparison could be produced and carries no charge. Do not collapse review or a service failure into match. A completed no-match comparison can still be billed.
Integration reference: The verdict
Step 6: Use history to reconcile and audit
Store the check ID against the intended application action. Retrieve GET /api/kyc/face/checks/{id} after a lost response or when reviewing a past comparison. The history endpoint filters by verdict and date and identifies API-initiated checks. Re-reading an existing result is different from running another comparison; do not blindly repeat a paid check to find its earlier outcome.
Integration reference: History
Get more from the capability
Choose review thresholds as an organisation policy and keep the thresholds recorded with every verdict.
Use upload IDs when you have a legitimate need to reuse an authorised photo, rather than repeatedly transmitting large inline files.
Combine this with subject binding and a live-person check when the action requires account-holder assurance.
Test before relying on it
Run the supported Sandbox or simulator scenarios for this product. Where a tool is Production only, check access and scope first, then use only a permitted, deliberately reviewed Production test. A documentation screenshot or a successful page load is not an end-to-end integration test.
Sandbox match, review, no_match and no_result are handled separately.
Consent and photo-size requirements are enforced.
The application stores and re-reads the check ID.
A simulated verdict is never presented as a live engine result.
Troubleshooting
The API rejects a photo URL
Check that it resolves to a permitted public address and serves readable supported bytes.
The result is no_result
Use the error explanation and improve the capture. This is not no_match and is not charged.
A publishable key is refused
The standalone face comparison is secret-key only. Call it on your backend.
Open the setup and integration references
Read the integration reference
Back to Solutions. Choose the capability you want to activate, then follow its own guide.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
