Operating with a single biometrics vendor takes away two assets that only exist with active competition: production comparison data and real negotiating leverage at contract renewal. Without both, performance evaluation and pricing decisions depend on what the current vendor chooses to report.

This article explains when single-vendor dependence becomes operational risk, how to structure parallel operation, what to measure, the expected engineering effort, and how to migrate the face database to the new provider.

When does single-vendor dependence become operational risk?

Dependence becomes risk when there is no independent data to challenge what the vendor reports. Risk rarely shows up as a major incident. It shows up in silent adjustments: an SDK (the vendor's software development kit) version that changes liveness (biometric liveness detection) behavior without enough advance notice; a price increase at renewal because no tested alternative is running; an API degradation that drops the success rate for hours under a vague SLA (service-level agreement).

Each of these events is manageable alone. The problem is that, without reference data from a second vendor processing the same traffic, none of them can be assessed precisely.

Fraud managers and product teams face different versions of this problem. For fraud: facing a new attack technique, how do you assess whether the current vendor's protection is enough or another provider responds better? For product: if the rejection rate rises two points after an update, how do you tell whether the vendor or a flow change caused it?

Without parallel operation, both questions depend on data supplied by the very vendor being evaluated.

What does a second active provider generate that pure redundancy does not?

The distinction matters for whoever approves the budget. Passive redundancy — an idle vendor waiting for the first to fail — is hard to justify because it generates no return while the system works. A second active vendor, even receiving a fraction of traffic, generates what redundancy does not: comparison data under real production conditions.

With parallel traffic, you can answer questions that today depend on lab benchmarks or market word of mouth: what is the rejection-rate difference between the two vendors in my flow, with my audience? Which one handles lighting or device changes better? Which one has a more stable response time over the last 60 days?

That data changes the contract-renewal conversation. And it changes the internal conversation about where it's worth investing in flow optimization.

How do you structure traffic splitting?

There are three models. The choice depends on the immediate goal.

01

Fixed percentage split: part of the traffic (10%, 20%, 30%) goes to the second vendor; the rest stays with the first. It's the simplest model to implement and the most comparable, because both groups go through the same journey. For the comparison to be valid, the split must be randomized at the request level — without randomization, profile differences between groups contaminate the data.

02

Segmentation by product or flow: the second vendor serves one product line, vertical, or specific flow. A bank using biometrics for onboarding and post-enrollment authentication can test the second vendor only in authentication. This limits the impact on onboarding and generates data in a high-volume flow with behavior distinct from signup.

03

Sequential fallback: the first vendor is primary; the second only receives the request if the first returns an error or misses the configured timeout. This model solves availability risk, but it doesn't generate quality comparison data — the requests that reach the second vendor are, by definition, the ones the first vendor failed to process. The transaction profile is different, and the comparison is compromised.

For comparison data, fixed percentage split with request-level randomization is the cleanest starting point. For availability first, fallback is faster to implement.

What should you measure during parallel operation?

The goal of the dual-vendor period is to generate enough data to decide before the current vendor's contract comes up for renewal. The metrics that matter:

First-attempt success rate: how many transactions reach a conclusive result without a retry. This number is more revealing than the final approval rate, which can be masked by retries that users abandon before completing.

Rejection rate: how many transactions never reach a conclusive result. In production, this needs to be measured by segment, because averages hide very different behaviors. A 4% rejection rate can hide 12% among users over 60 on entry-level devices.

P90 and P99 response time: P50 is misleading. What matters is what happens in the slowest transactions, where abandonment is most likely. Vendors with a similar P50 can have very different P99 depending on infrastructure during peak hours.

Availability and incident recovery time: not just average uptime, but how long the vendor took to communicate and resolve each degradation. This history should be available in the SLA or on a public status page before you sign any contract.

Cost per conclusive transaction: the price charged per request doesn't reflect the real cost of the operation. Inconclusive requests consume budget without producing a result; support effort during stabilization rarely enters the initial math.

With three months of parallel operation and enough volume per segment, you can compare both vendors across each of these axes with real production data. For reference: the Fortface SDK records 97.9% first-attempt success, 4.1s average capture time, and backend processing of up to 800ms.

What is the integration effort for a second vendor?

Most engineering teams underestimate the effort of adding a second vendor because they treat it as an SDK swap. It isn't.

The SDK is the fastest part. What takes longer is everything around it: the routing logic that decides which vendor gets each request, the metrics collection that records each transaction's result per vendor, the dashboards that make the data comparable between the two, and the retry and fallback flows that need to keep working even when one vendor has high latency.

For a team experienced in biometric API integration, a realistic estimate is four to eight weeks of engineering to put the second vendor into parallel traffic with proper instrumentation. A well-documented SDK with active support during integration lowers that number. The absence of an abstraction layer in the existing code raises it.

Ongoing cost after integration depends mainly on how the vendor ships model updates. Vendors that update via configuration or API, without forcing a new app version, reduce maintenance effort over time. This point belongs in the contract, not just in the technical docs.

What should you do with the face database?

The face database isn't a blocker to adopting a second vendor. Two technical paths solve the migration without manual user re-enrollment, and almost all customers have original images stored.

The first path is a single batch migration: the stored original photos are used to generate a new biometric hash compatible with the new provider, in the background, with no impact on the user journey.

The second is progressive enrollment via API: with each new transaction or login, the system automatically registers the user with the new provider. The base migrates dynamically, with no extra action from the user and no batch processing needed.

The choice between the two depends on the volume of active users and the available migration timeline. In both cases, porting original images between vendors requires contractual review and sign-off from the DPO (Data Protection Officer) — the technical migration is solvable, but the legal basis has to be mapped out before any move.

What should you ask a second vendor during evaluation?

Evaluating a second vendor is different from evaluating a first one. You already have a real production reference, so the comparison stops being abstract.

On production performance: what is the rejection rate measured under real conditions, with what volume and what user profile? What part of that data is under NDA, and what part is public?

On face-database migration: does the vendor support batch migration to generate a new biometric hash from the original images? Does it also offer progressive enrollment via API? What's the process, and what are the technical requirements?

On model updates: when the liveness model is updated, how far in advance is the customer notified? Is the update applied automatically, or does the customer control the timing?

On incident history: what is the track record over the last 12 months? What was the average time between a degradation and its communication, and between communication and resolution? Is that data on a public status page, or does it depend on contacting support?

On integration support: is there a dedicated engineering team supporting the integration phase? Under what SLA, and up to which stage?

Vendors that cannot answer the last 12 months of incident history with precise data are telling you something about how they operate. That silence is data too.

Fortface as a second vendor

Fortface publishes its production data openly: 97.9% first-attempt success, 4.1s average capture time, backend processing of up to 800ms, and a SUS score of 95.5 — an A+ usability rating. Liveness is frictionless, with no movement challenges, certified to iBeta Levels 1 and 2 and ISO/IEC 30107-3, with protection against presentation and injection attacks. The SDK is available for Android, iOS, Web and Secure Link, in production at 180+ companies.

For teams evaluating a second vendor: request a technical conversation with the Fortface team.

To go deeper

  • Fortface solutions — how Fortface addresses every stage of the identity journey

Frequently asked questions

When does it not make sense to add a second vendor?
When transaction volume is low enough that the cost of integration and maintenance outweighs the value generated by the comparison data. Below a certain monthly volume — which varies by product and by flow — the parallel-operation period won't produce a sample large enough for a statistically valid comparison. In that case, better instrumenting the current vendor to collect detailed metrics per segment is more efficient than adding a second one.
Do two vendors cost double?
Total cost doesn't double, because traffic is split, not duplicated. Each vendor processes its share of the volume, not the full volume. Per-transaction pricing can vary between the two, which factors into cost per conclusive transaction. The fixed additional cost sits in initial integration, maintaining two SDKs, and the routing layer. That cost needs to be weighed against the value it generates: leverage at the current vendor's contract renewal, data for the migration decision, and reduced availability risk.
Does the second vendor need the same certifications as the current one?
It depends on the operation's regulatory requirement. ITI Normative Instruction 36/2026 requires liveness with detection of manipulated images and videos for the Electronic Registration Authority (AR Eletrônica). If the operation is regulated, both vendors need to meet the same requirement for parallel traffic to be valid in that flow. For flows with no specific regulatory requirement, certifications become an evaluation criterion, not an eligibility prerequisite.
How long does it take to get reliable data from parallel operation?
It depends on volume. With at least 10,000 transactions per month per vendor, three months is enough for a reasonably confident comparison of rejection rate and success rate. With lower volume, the period needs to be extended, or the comparison scope needs to be narrowed to segments with more homogeneous behavior.
What happens to biometric data during migration?
The technical migration is solvable: stored original photos are used to generate a new biometric hash compatible with the new provider. What needs to be mapped out before any move is the legal basis. Biometric data is sensitive personal data under the LGPD (Brazil's General Data Protection Law). Porting images requires a specific contractual clause with both vendors and sign-off from the DPO. The right order is legal first, technical second.