Identity Signal Fragmentation: Risks and Rewards

Our recent study showed that only 21% of companies use one ID verification vendor, while most of the remaining respondents reported having multiple solutions. Now, a multi-vendor identity verification (IDV) stack can be both rewarding and risky for the same reason: each tool or solution sees a different part of the verified person. 

On the one hand, this division of labor can bring deeper expertise and useful independence. On the other, identity signal fragmentation can also become costly and vulnerable when evidence, rules, and case history are split as well.

In this article, we will break down what identity signals and identity signal fragmentation are, as well as their pros and cons to inform your IDV stack decisions.

Common identity signals include:

• Identity document evidence: the visual inspection zone, portrait, MRZ, barcode, RFID chip data, and the results of document authenticity checks.

• Biometric evidence: a selfie or video capture, face match, liveness result, fingerprint, or voice sample.

• Device evidence: device integrity, rooted or jailbroken status, camera source, and emulator indicators.

• Session context: session binding, timestamp, IP address, geolocation, and proxy indicators.

• Database and screening results: government records, AML, sanctions or PEP screening, and other authoritative data matches.

• Behavioral evidence: interaction patterns and anomalies that help distinguish a normal user from scripted activity.

• Identity history: earlier verifications, account recovery events, and links to documents or devices seen before.

Its risk rises when that distribution extends to policy, case history, and decision ownership, since the tools may all perform their assigned checks correctly while the organization loses the connection between the evidence and the final outcome.

As part of our research “The New Shape of Identity Threats”, Regula asked 850 companies to choose the description closest to their current IDV setup. 

Only 21% said they use one vendor organization-wide. The remaining 79% rely on some mix of regional providers, secondary testing vendors, internal components, platform-managed tools, or manual checks.

At the same time, only 8% openly described their ID verification as highly fragmented. The wider results show a much larger gray area: 25% combine vendors with in-house components, 21% use different providers by region or service, 13% keep a second vendor for performance testing, and 11% manage several tools through a platform. In other words, fragmentation is factually more common than the 8% figure suggests.

We want to be clear: one vendor doesn’t automatically mean “good”, nor do many vendors mean “bad”. As we can see, multi-tool IDV is common, but the difference lies in how it is run: deliberate specialization with shared policy can be effective, while disconnected tooling and divided ownership will likely cause issues and inconsistencies.

Some providers perform better with certain document types, customer groups, or capture conditions. 

That’s why many testers tend to account for that: NIST, for example, publishes face recognition and age estimation results by image type and demographic group rather than reducing performance to one universal score. Namely, Regula ranked first in MAE (mean absolute error) Across Geography in NIST’s FATE-AEV, meaning its solution consistently has the lowest error across the tested regions of birth.

So once testing shows a clear advantage, the specialist should handle only the part of the verification process where that advantage has been proven. This might be a particular document family, country, or age-assurance requirement, while the main provider continues to handle the remaining traffic.

The verification policy should state when the specialist is used, which result carries authority, and how that result reaches the case record.

Regula’s study found that 13% of respondents use another vendor specifically to measure fraud or accuracy performance. This provider serves as an independent benchmark, processing some or all of the same cases as the main vendor so the company can compare their results.

At first, the second provider is usually kept in shadow mode, meaning its output does not affect the customer decision. Its purpose is to identify disagreements and changes in performance that deserve further review.

At the same time, those disagreements need to be checked against confirmed outcomes before they carry much weight. For instance, a stricter provider may stop more fraud but also reject more legitimate customers.

Before testing starts, the company should define:

• which cases both providers will receive;

• which fraud and customer-friction measures will be compared;

• how failed captures and retries will be counted;

• who will review differences and approve any policy changes.

The comparison should cover the full customer process, including failed submissions and abandonment.

A backup provider can keep an important verification route available when the primary service is down or performing poorly. This reduces dependence on one supplier and gives the company another option during an outage.

The backup route should apply the same required checks as the primary route. A customer who would normally go through document authenticity checks and liveness should not receive a lighter review because the main provider is unavailable. When the backup cannot complete a required check, the case should follow a predefined outcome, such as delayed processing or manual review.

Before the backup goes live, the company should document which checks cannot be skipped, how the provider’s results map to internal decision rules, and where the full case record will be stored. Capacity also needs testing, since a provider that works well on a small sample may struggle when all primary traffic is redirected at once.

Among the 90 respondents who use a platform to manage several ID verification tools, 83% said they had established capabilities for assessing whether submitted evidence was AI-generated, synthetic, or enhanced. The figure for the full sample was 58%.

The same pattern was found in biometric capture. Sixty-nine percent of the platform group said they could fully verify that biometric data was captured live with strong controls, compared with 46% of all respondents.

Another benefit of an all-in-one platform is the ability to keep the evidence and the business decision together. A case can contain the document and biometric results, capture details, policy version, and reviewer action without requiring an investigator to rebuild the history from several systems.

This is especially useful when outside services are connected to the platform. Their original results can be retained while their business meaning is translated into the company’s own decision terms.

A useful case record should preserve:

• the original component result and reason code;

• the evidence source and capture method;

• the rule, threshold, and policy version applied;

• retries, overrides, reviewer actions, and timestamps.

If the tools are fragmented, they need interfaces between them, which may sometimes cause code to be translated incorrectly or capture context to be dropped.

A platform reduces those transfer points when the main checks run inside the same system. Specialist services may still connect from outside, but their results can feed into the same person's record, policy, and review process.

A platform should also allow an individual specialist to be replaced without forcing the company to redesign the entire verification process.

At minimum, procurement should confirm that:

• an integration failure cannot default to approval;

• completed cases can be exported in a usable format with results, timestamps, and reviewer actions;

• replacing a connected provider does not make historical cases unreadable or change internal reason codes;

• policy settings and version history are documented well enough to rebuild past decisions.

In this context, putting all identity signals in one place means giving a unified record for the person’s identity history, the evidence used for the event, the policy applied, and the final reason code.

Every connected component should meet a small evidence contract:

• the customer and case ID;

• the evidence source and capture method;

• the raw result and reasoning;

• the tool version and policy version;

• the timestamp, reviewer action, and retention reference.

Regula IDV Platform can support this model when a company wants full identity lifecycle management, supported by orchestrated workflows, document checks, biometrics, screening, and case records all in one.

Together, Regula’s technologies provide:

• Document verification: authenticity checks, data extraction, and cross-checking between the visual inspection zone, MRZ, barcode, and RFID chip.

• Global document coverage: more than 16,000 document templates from 254 countries and territories, covering 138 languages, including Latin and non-Latin scripts.

• Biometric verification: face matching and liveness detection against printed photos, video replays, video injections, and realistic masks.

• Compliance and identity management: KYC and age-assurance processes, AML/PEP screening, centralized profiles, and identity history.

• Case evidence: session review, detailed interaction logs, audit records, geolocation history, and device history.

• Pre-configured workflows: Roll out a KYC scenario in about 20 minutes, with no installation headaches, using ready-to-run white-label components. Deployment can be on-premises or cloud-hosted for quick setup and full control of data.

Talk to our team about how Regula IDV Platform can unite all your ID verification needs under one solution.