How DocinVault Tests Liveness and Document Integrity Against Spoofing

Learn how document checks, facial similarity, liveness detection, presentation-attack testing, injection testing, manual review, and application security work together inside a remote identity verification system.

DocinVault biometric liveness and document-integrity testing workflow

Remote identity verification has a difficult responsibility.

It must determine whether submitted evidence is usable and consistent while also identifying attempts to manipulate the document, impersonate another person, replay previously recorded media, or interfere with the verification process.

No single model, score, or image check can answer all of these questions.

DocinVault uses a layered approach that can combine document assessment, biometric binding, liveness detection, presentation-attack controls, injection-attack testing, application security testing, and manual review.

01

Remote verification faces several different attack types

An attacker may attempt to:

  • Upload an altered document
  • Display a document on another screen
  • Print and re-photograph an identity document
  • Replace a portrait
  • Modify a date or document number
  • Submit inconsistent front and back images
  • Use a photograph instead of a live person
  • Replay a video
  • Present a mask
  • Inject pre-recorded or generated biometric data into the process
  • Exploit an application or API weakness

These attacks do not all target the same layer.

A document check cannot prove that a live person is present. A liveness check cannot confirm that every printed field is genuine. A biometric laboratory result cannot determine whether an API has an authorization vulnerability.

Meaningful assurance therefore requires multiple controls.

02

Document assessment begins with evidence quality

Before document information can be assessed, the evidence must be usable.

DocinVault can evaluate:

  • Blur
  • Sharpness
  • Lighting
  • Reflection
  • Cropping
  • Missing sides
  • Document position
  • Capture suitability

Unusable evidence can be rejected with clear retry guidance. This improves security and completion because the guest knows what must be corrected instead of receiving an unexplained failure.

03

Document integrity uses multiple signals

Depending on the document and configured workflow, DocinVault can combine:

  • Template consistency
  • Font and typographic comparison
  • MRZ checksum validation
  • Visible-field consistency
  • Front and back consistency
  • Expiry assessment
  • Document security signals
  • NFC-derived information
  • Chip or electronic-seal integrity
  • Manipulated-photo detection
  • Screen-presentation detection

The Issuing Countries catalog explains that no single document signal is treated as universally conclusive. The measures used depend on the document, issuing market, capture method, and customer risk policy.

04

Facial similarity and liveness answer separate questions

Facial similarity

Facial similarity asks whether the person completing the verification resembles the portrait associated with the identity document.

Liveness

Liveness asks whether biometric evidence is being captured from a live person present during the session.

A system may use active or passive methods depending on the configured flow.

DocinVault can use facial similarity, active or passive liveness, dynamic selfie methods, and manual review. Its practice statement also describes detection approaches associated with flat surfaces, gaze, 3D masks, silicone masks, paper images, and screen presentations.

05

What iBeta testing demonstrates

iBeta Level 2 testing mark

iBeta Level 2

iBeta performs biometric presentation-attack detection testing under ISO/IEC 30107-3.

Level 1 and Level 2 testing use defined attack instruments and testing conditions, with Level 2 addressing a more demanding attack scope.

The correct interpretation is that the tested DocinVault liveness component was evaluated against the presentation attacks and conditions identified in the relevant laboratory evidence.

It should not be interpreted as:

  • A guarantee that every possible spoof will be detected
  • Certification of the entire DocinVault platform
  • A complete application security assessment
  • Proof that every customer configuration performs identically
  • A replacement for operational monitoring or manual review

ISO/IEC 30107-3 defines presentation-attack testing and reporting, not complete system-level vulnerability assessment.

06

What BixeLab testing adds

BixeLab biometric testing mark

BixeLab

BixeLab testing provides additional evidence concerning presentation-attack detection and injection-attack resistance within the tested scope.

Presentation attacks attempt to fool the capture process through artifacts presented to the camera or sensor.

Injection attacks attempt to insert manipulated or pre-recorded data into the processing path rather than presenting it naturally through the intended capture flow.

These assessments answer different questions and should therefore be reported separately.

DocinVault's tested biometric component has undergone BixeLab presentation-attack and injection-attack evaluation within the scope identified by the corresponding evidence. This does not mean that the whole platform is spoof-proof.

07

Praetorian tests another part of the system

Praetorian security testing mark

Praetorian

Biometric testing does not replace application and API security testing.

Identity platforms also need to protect:

  • Session creation
  • Authorization
  • Account roles
  • API endpoints
  • Webhook delivery
  • Evidence access
  • Administrative interfaces
  • Cloud configuration
  • Data export
  • Integration secrets

Praetorian assessments focus on identifying exploitable application, API, cloud, and product-security weaknesses, then supporting remediation and retesting.

DocinVault's security practices include secure development controls, annual vulnerability scanning and penetration testing, finding classification, remediation service levels, and restrictions on releasing systems with unresolved critical or high findings.

08

Manual review remains important

Automated verification should not force every case into a simple yes or no result.

A low-confidence or inconsistent case may need:

  • Another capture attempt
  • A different document
  • Human review
  • A live video check
  • Additional evidence
  • A customer-defined exception process

DocinVault can return statuses such as approved, rejected, pending, or needs review.

The customer determines:

  • Accepted evidence
  • Similarity thresholds
  • Retry count
  • Manual-review range
  • Decision rules
  • Operational consequence

This is especially important in hospitality, where a failed automated check can affect a real guest arriving at a property.

09

Layered assurance is more useful than one perfect score

Remote identity verification is strongest when the system combines several forms of evidence.

A reliable workflow may include:

  • Capture-quality checks
  • Document consistency checks
  • MRZ or NFC evaluation
  • Facial comparison
  • Liveness assessment
  • Presentation-attack controls
  • Application and API protections
  • Manual review
  • Audit history
  • Customer-defined decision rules

The result is not simply a claim that a document looks real. It is a structured outcome supported by the checks, evidence, thresholds, and review process configured for that workflow.

10

Frequently asked questions

Clear distinctions between document, biometric, injection, and application-security testing.

Review the verification controls available for your workflow

Contact the DocinVault team to discuss document checks, biometric configuration, manual-review paths, and integration requirements.

contact@docinvault.com