Onfido — status

Status verification pending

The latest official observation is not fresh enough to confirm current service health.

Official incident resolved

Increase in Known Faces consider rate — ## Summary On August 26, 2026, an increase in the consider rate of Known Faces was observed during the period between 15:00 and 18:00 UTC. The overall observed consider rate of Known Faces increased from ~6% to ~23% across all regions. Perceived increase may have been higher or lower, depending on the client’s specific geography or vertical. The was driven by a change to how matching scores are calculated for Known Faces matches, which inflated scores for non-matching faces and thus causing many reports to return false matches and a **consider** result. ## Root Causes The change introduced a new algorithm for scoring matching faces, which is intended to improve Known Faces recall performance. This was extensively evaluated and validated by internal benchmarks before being released. Inadvertently, the transition from benchmarks to production partially failed to account for particular production environment characteristics. At the root, a single constant wasn’t properly converted in the transition, resulting in wrong behavior of the new scoring algorithm. ## Timeline     15:20 UTC: Change to Known Faces is released     17:35 UTC: Increased consider rate on Known Faces is noticed.     17:50 UTC: Change is rolled back. Consider rate drops soon after. ## Remedies We are reviewing internal benchmarks and testing procedures which can increase the safety of this kind of change. Specifically, ensuring internal testing reflects the real production landscape when it comes to datasets and that transitions from internal benchmarks and experiments to production are thoroughly tested. In addition, change procedures will be carried out with tighter monitoring so it allows us to notice and act faster.

Official incident resolved

Spike in Visual Authenticity failures on Facial Similarity Motion randomness checks — ## Summary On 24 August 2026, between 15:00 UTC and 06:53 UTC the following morning, Facial Similarity Motion checks using randomness challenges failed at a much higher rate than normal in the EU region. A stricter validation was applied to all customers in the region when it should have been limited to a single customer, causing verifications that would otherwise have passed to be rejected. Affected reports were returned with a "Visual Authenticity" failure. Because Motion checks are fully automated, the end users behind these reports were rejected with no manual review, and some attempted the check again and were rejected a second time. The clear rate for these checks fell from around 97% to around 54% for approximately 1.67% of Facial Similarity Motion reports were affected. Disabling the change restored normal clear rates immediately. Other Motion checks and other regions were unaffected. ## Root Causes A stricter validation of the motion randomness challenge was being trialled with a single customer, controlled by a per-customer configuration setting. A bug in our code meant the setting was evaluated without the customer identifier, so the stricter validation was applied to all customers in the EU region running Motion with randomness checks rather than to the intended one. Verifications that would have passed under the standard validation were rejected instead, and reported under the "Visual Authenticity" breakdown. No customer configuration or submitted data was at fault. ## Timeline All times UTC. * 24 August, 15:00: we enabled a stricter validation for motion randomness challenges in the EU region. Motion checks using randomness began failing at a much higher rate. * 24 August, 16:36: a customer reported a drop in workflow success rates and we began investigating. * 25 August, 04:18: we confirmed the elevated failure rate and escalated it. * 25 August, 06:53: we reverted the change and clear rates returned to normal within minutes. * 26 August: we deployed a permanent fix. ## Remedies * Strengthen the controls around customer-specific configuration changes to ensure they cannot be applied more broadly than intended. * Improve monitoring and alerting for Motion randomness clear rate checks so that unexpected changes in rejection rates are detected automatically and escalated more quickly.