Simplifying Self-Hosted Identity Verification Using Less Infrastructure, More Flexibility & Enhanced Interpretability

For organizations operating identity verification infrastructure themselves, performance and accuracy are only part of the equation. The technology also has to be practical to deploy, maintain, scale, and update.

That’s something we’ve heard consistently from customers. Organizations want the flexibility and control of self-hosted identity technology without adding infrastructure complexity every time they expand their capabilities. They want clearer, more interpretable verification results. And they need their identity stack to keep pace as new documents, fraud techniques, and business requirements emerge. 

That becomes increasingly important as identity verification expands. What may have started as a need to capture data from an identity document can quickly grow to include document verification, fraud detection, biometrics, and other capabilities. When each new capability requires separate infrastructure, organizations can find themselves managing an increasingly complicated identity technology stack.

With the latest release of v4000 for BlinkID Verify, we’re simplifying that experience by bringing document capture and data extraction together with identity document verification within a single self-hosted infrastructure.

One Self-Hosted Infrastructure for Extraction and Verification

Historically, customers using both BlinkID for document capture and data extraction, and Verify for identity document verification needed to deploy, scale, and maintain separate Docker images. The two products also used different API schemas, adding another layer of complexity for organizations integrating both products or moving from an extraction-only setup to using Extract & Verify together. 

Verify v4000 changes that. BlinkID extraction and Verify now ship within a single Docker container, providing one infrastructure for both capabilities. For engineering teams, that means fewer deployments to maintain and less infrastructure to manage. For the broader business, it creates a simpler path for expanding identity capabilities.

An organization might initially need to capture and extract information from an identity document, for example, but later require document authenticity checks or additional fraud detection as its business grows and the fraud industry evolves. With extraction and verification running on the same underlying infrastructure, adding those capabilities doesn’t require introducing and maintaining an entirely separate deployment. For existing BlinkID customers, it also creates a much faster path to testing Verify capabilities without first standing up separate infrastructure, making it easier to evaluate how document verification and fraud detection could fit into existing workflows. 

This is particularly valuable for organizations that choose self-hosted identity verification because of security, privacy, data residency, or regulatory requirements. They retain control over their infrastructure and identity data while reducing the operational burden that can come with maintaining multiple identity systems.

More Consistent APIs for Developers

We’re also introducing new Verify & Extract v3 APIs across our self-hosted deployments.

The v3 API standardizes request and response structures and removes or consolidates a number of legacy fields. Terminology is also more consistent across the API. For example, recommendedOutcome from the Verify response is now expressed more directly as a verification verdict, while legacy match levels have been replaced by sensitivity settings that more clearly describe how verification checks are configured.

Image quality checks have similarly been consolidated across both /extract and /verify endpoints. Instead of managing separate blur, glare, lighting, sharpness, DPI, and tilt match levels, these signals now sit within a unified image quality assessment.

The schema has also been harmonized across the Extract and Verify endpoints, making it easier to work with both capabilities through a consistent structure. For example, imageFront and imageBack are now standardized as imageFirstSide and imageBackSide across both endpoints, while extracted fields use consistent StringResult and DateResult structures, with date results incorporating parsed day, month, and year components. 

These may sound like small changes individually, but consistency matters when identity verification is embedded within complex production environments. Cleaner schemas and standardized terminology make integrations easier to understand and maintain, while giving teams a more consistent framework as they add capabilities.

The goal is ultimately straightforward: developers should spend less time translating between different structures and more time building the identity experiences their businesses need.

More Explainable Verification Results

Simplifying an API isn’t only about making integration easier. It should also make the information coming back from a verification easier to understand and act upon.

This is something we’ve consistently heard from customers: a verification result is most useful when teams can understand not only whether a document passed or failed, but why. Verify v3 responds directly to that need by making verification outcomes more transparent and actionable. 

Verify v3 introduces a simplified top-level response structure with separate statuses for the extraction and verification stages. It also adds a failedChecks array that identifies the specific checks responsible for an unsuccessful verification.

Instead of receiving only a broad outcome, organizations can more easily understand what happened during the verification process.

For example, a verification might fail because of evidence associated with a portrait forgery check or a generative AI check. Surfacing those signals directly gives developers and fraud teams greater context around the decision and makes it easier to determine what should happen next.

That additional visibility becomes increasingly valuable as fraud attacks grow more sophisticated. A rejected document isn’t necessarily the end of the decision. Depending on the reason, an organization may want to request another image, introduce additional verification, send the interaction to manual review, or reject it outright.

Greater Control Over Fraud and Conversion

There is no universal verification threshold that works for every organization, market, or interaction. A financial institution opening a high-value account may have a very different risk tolerance than a retailer verifying an identity for a lower-risk interaction. Even within the same organization, verification requirements may change depending on geography, product, customer type, or risk level.

Verify v3 standardizes default model sensitivity settings to give businesses greater flexibility to tune verification checks around their specific risk tolerance. Where a model may previously have used a default sensitivity of level 2, for example, v3 moves the default to level 5, providing more room to adjust sensitivity both higher and lower depending on the use case. 

Making verification more restrictive isn’t automatically better. Excessively aggressive settings can create false rejections and unnecessary retries for legitimate customers. Settings that are too permissive can increase fraud exposure.

Greater control allows businesses to tune verification around their own risk profile rather than forcing every identity interaction through the same rigid decision process.

Better Feedback When Something Goes Wrong

Not every unsuccessful identity verification is fraud. Sometimes the problem is much simpler: an image is blurry, glare obscures the document, a barcode isn’t readable, or part of the document has been cropped out of the image.

Verify v3 introduces revised warning and informational messages designed to provide more consistent feedback about these situations. The system can identify issues such as poor image quality, missing document sides, unreadable barcodes, cropped documents, and expired IDs.

For developers and support teams, clearer feedback can make problems easier to diagnose. More importantly, it creates an opportunity to help legitimate users recover from avoidable verification problems rather than simply presenting them with a failed result.

That’s an important distinction. Improving fraud detection is only one side of identity verification. Helping legitimate customers successfully complete verification is the other.

An Architecture Designed to Keep Up With Changing Documents

Governments continually introduce new identity documents, redesign existing ones, and update security features. For businesses operating across multiple markets, maintaining support for those changes can create an ongoing engineering burden.

The v3 APIs have been designed to make that process easier. Enum constraints will be replaced with more extensible OpenEnum schemas, allowing additional document coverage to be introduced through template updates between regular BlinkID deployments without requiring a breaking schema change.

Document coverage is consistently one of the most important requirements for organizations operating across multiple markets. With this more extensible approach, Microblink can roll out support for additional documents in a matter of weeks rather than waiting months for a larger deployment cycle. 

The release also updates the underlying extraction engine of Verify to BlinkID v8001, expanding support for new documents and document versions while improving OCR accuracy.

For customers, the benefit is less disruption as document coverage evolves. Instead of treating every new document type as another integration project, the underlying platform can continue expanding while the core integration remains stable.