Most identity verification is designed for someone sitting at home with a phone and a passport, deliberately trying to open an account. A large amount of real-world verification is not that: it is a technician at a customer site confirming they are handing equipment to the right person, a courier completing a delivery that requires proof of identity, an assessor verifying a claimant in their home, a field agent onboarding a customer who has never used the app. The constraints are different — intermittent connectivity, one hand free, a person who was not expecting to be verified — and a flow built for the desktop case fails in all of them.
This covers what changes when verification happens away from a desk, drawing on a field service platform DSS — the engineering team behind aIDentix — built for a client providing hardware support to schools across England.
What is actually different about verification in the field?
Four constraints, none of which apply to self-service onboarding:
Connectivity is unreliable. A basement, a rural site, a building with poor signal. A flow that requires an uninterrupted round trip to a verification API will fail, and it will fail after the customer has already handed over their document.
The person being verified did not initiate it. They are not motivated to get through a five-step flow. Every additional step has a materially higher abandonment cost than in self-service, because there is no funnel to re-enter.
Two people are present. This is the one genuine advantage. A field agent can confirm physical presence directly, which changes what the software needs to prove — the risk shifts from impersonation to record-keeping.
The record has to survive the visit. Whatever is captured must be attributable, timestamped and retrievable months later, because that is when it will be questioned.
Capturing confirmation at the point of handover
In the schools platform, the confirmation step was built directly into the mobile application. When a repaired device was returned to a customer, a custom signature capture feature within the mobile app recorded the customer’s confirmation at the moment of handover. A separate questionnaire confirmed the device’s condition before repair and required customer sign-off through the same mobile agent application.
Two design decisions in that are worth generalising.
Confirmation was captured at the moment of the event, not reconstructed afterwards. A signature collected at handover is evidence. A note typed at the end of the day recording that a handover occurred is a recollection, and it will not hold up when disputed.
The condition questionnaire ran before the work, with sign-off. This is the pattern that prevents the dispute rather than resolving it. Recording agreed state at the start of an interaction removes the ambiguity that later disagreement depends on. The equivalent in a verification context is recording exactly which document was presented and what it showed, at the point it was presented.
Telling people a verification is coming
The platform used a Twilio integration to send SMS notifications to customers about upcoming field agent visits.
This looks like a scheduling convenience. In a verification context it is a completion-rate mechanism. The single largest cause of failed in-person verification is the person not having their identity document with them, because nobody told them they would need it. An SMS ahead of a visit stating what document to have available converts a wasted trip into a completed check — and a wasted trip in field operations costs considerably more than a failed self-service attempt.
The same applies to remote employee onboarding, where the equivalent failure is an employee joining a scheduled verification call without their passport.
Routing the right person to the right job
Agents were grouped by skill and scheduled according to delivery region, so that qualified personnel handled the appropriate tasks, with Google Maps integration for efficient routing.
Skill-based routing matters more for verification than for general field work, because verification competence is not uniform. Confirming a domestic passport is one skill. Assessing a foreign identity document, or handling a case where the presented document does not match the record, is another. Routing on capability rather than proximity alone is what prevents an agent making a judgement call they were not trained for — and it is why the escalation path needs to exist before it is needed.
Chain of custody as a verification pattern
The warehouse side of the platform is a useful analogue. Barcode generation automated item tracking within large warehouses, and engineers scanned barcodes on receipt, finalising transfer orders line by line rather than confirming a whole consignment at once.
Line-by-line confirmation is the principle worth borrowing. A single “verification completed” flag records that something happened. A per-item record — which document was presented, which check was performed, which result was returned, who confirmed it — records what happened. When a verification is questioned eighteen months later, the difference between those two records is the difference between an answer and a shrug.
The same reasoning applies to the reported benefits of that implementation: improved inventory accuracy through automated tracking, and a streamlined transfer process that saved time and reduced manual error. Both came from making each step individually recorded rather than making the process faster.
Designing a field verification flow
Practical constraints, in order of how often they are missed:
- Capture first, verify second. The document image and any liveness capture should be stored on the device immediately and submitted when connectivity allows. Do not make the capture depend on the network.
- Make the pending state explicit. The agent needs to know whether the check has been submitted, whether it returned, and what the result was — including when that answer arrives after they have left.
- Notify before the visit. Tell the person what to have with them. This single message is the highest-return element of the whole flow.
- Record the agent’s own confirmation separately from the automated result. They are different evidence. An agent confirming physical presence and a system confirming document authenticity are two independent facts, and collapsing them into one field loses both.
- Define the escalation path in advance. When a document fails or is unavailable, the agent needs an action that is not improvisation.
- Timestamp everything at capture, not at sync. A record uploaded at 18:00 for an interaction at 11:00 must say 11:00.
Where mobile verification is genuinely required
Field and in-person verification is not a lesser version of self-service onboarding. It is the only workable option in several situations: high-value account opening where the institution requires physical presence, regulated deliveries with proof-of-identity requirements, home-visit assessments, equipment handover under contract, and remote employee onboarding where a document check happens over a scheduled call rather than through a consumer app.
What those share is that the verification is one part of a longer interaction. The software’s job is to make the identity step the shortest thing that happens during the visit, and the best-recorded.
aIDentix provides document capture, OCR extraction, face matching and liveness detection through an API that can be embedded in a mobile or field application. It is built by DSS, whose field service implementations include the platform described here.
Frequently asked questions
How is field identity verification different from self-service onboarding?
Four constraints: connectivity is unreliable, the person being verified did not initiate it and is less motivated to complete steps, two people are physically present which shifts risk from impersonation to record-keeping, and the record must remain attributable and retrievable months later when it is questioned.
How does identity verification work with unreliable connectivity?
Capture first, verify second. The document image and any liveness capture are stored on the device immediately and submitted when connectivity allows. A flow requiring an uninterrupted round trip to a verification API will fail, and it will fail after the person has already handed over their document.
What should a field agent record during an in-person identity check?
The agent’s own confirmation of physical presence and the automated verification result should be recorded separately — they are two independent facts and collapsing them into one field loses both. Capture confirmation at the moment of the event rather than reconstructing it later, and timestamp at capture rather than at sync.
How do you improve completion rates for in-person verification?
Notify the person before the visit stating which document to have available. The single largest cause of failed in-person verification is the person not having their identity document with them because nobody told them they would need it. In field operations a wasted trip costs considerably more than a failed self-service attempt.
What digital onboarding tools support remote employee verification?
Any platform exposing document capture, OCR extraction, face matching and liveness detection through an API can be embedded in a mobile or field application. The differentiator is not the checks themselves but whether the flow tolerates intermittent connectivity and records per-step evidence rather than a single completion flag.