The verification pipeline
Three checks run one after another inside the API call that uploads the image — document detection, face matching, then OCR — and the verdict comes back in the HTTP response. Every run is wall-clock budgeted (150 seconds by default); anything undecided goes to your review queue with a stated reason.
Document detection
When an image arrives, a custom-trained document-detection model answers one question before anything else runs: is there an ID document in this frame? If there is not, the submission never reaches the face or text stages.
- Document present: the frame is checked for an identity document, and a submission with none is not scored as a verification.
- Today: the detector is trained on US (Texas) driver's licences. That is the document class it recognises.
- Roadmap: passports and national ID cards (MRZ), PDF417 licence barcodes and UK / EU / AU document classes will follow — they are not available today.
Face comparison
Faces are detected and compared with a facial-recognition model. An image with no detectable face is never scored as a match.
- Reference matching: the portrait on the document is compared against an approved reference selfie — or a selfie against an approved document. A verified comparison is recorded on the submission as
face_comparison: matched. - Ghost-photo consistency: the secondary portrait printed on a licence is compared against the primary one, and a mismatch flags the submission for a human.
- Two assurance flows, chosen per token: document-check (the default) lets a licence approve on detection plus OCR alone, and says so — the response carries
face_comparison: none. Strict (require_face_match) parks the submission for review until a face comparison anchors the subject. - References must be approved: only an approved image is used as the reference, and if it cannot be retrieved or holds no detectable face the submission parks rather than approving on the remaining evidence.
OCR, scored against the subject
The document's text is read with an OCR engine and scored against the details the subject provided. Identiwise does not just extract text — it measures how far the document agrees with the person's own account of who they are.
- Scores name, date of birth, licence number and street independently, wherever each appears in the read.
- Region-agnostic dates: day/month/year, month/day/year and ISO orders all match, and matching is case-insensitive, including accented characters.
- The score is stored with the submission, so a reviewer sees the evidence behind a decision rather than a bare verdict.
Age estimation, alongside the pipeline
An upload can also be sent for age estimation — type=analyze returns an
estimated age from a selfie, and type=verify_age answers an age gate against the
min_age set on the token. Identiwise does not perform emotion recognition or
gender inference. These are estimates from a model. If the model cannot be reached the API
returns an error and asserts nothing about the person.
What happens next
Every submission ends in one of three states, and your team can act on any of them from the admin console.
Approved automatically
The document was detected and the evidence agrees. The response records which assurance level the approval carries — a face comparison that ran and passed, or a document-check approval with no reference on file.
Pending review, with a reason
Multiple faces, an internal mismatch on the document, a missing or face-less reference, or a token that demands a face match with nothing to match against — the submission parks and says which. The OCR score travels with it as evidence.
Rejected
A reviewer rejects the submission and can require a re-upload, which reopens the verification for the subject and prompts them for exactly the item that failed.
The review queue is where humans stay in the loop. Administrators see every parked submission with its reason, score and AI metadata, open the stored images through time-limited pre-signed URLs, approve or reject, request a re-upload, and exchange messages with the subject in the hosted verification UI. Subjects can also correct their own details from the same page when the token allows it; an erasure request can be lodged by an administrator, or by your own client through the subject erasure route.
An outage is never a verdict about a person. If one of the models is unavailable, the submission parks for review naming the unavailable check — it is never recorded as a failed match, a missing face or a document that did not read.
Built for compliance
Processor, not controller
Identiwise processes verification data on your instructions; you remain the controller and decide what is collected and how long it is kept. Tenant data is separated at every query and that separation is mechanically linted in CI.
Data sovereignty
Customer data is processed and stored on IONOS Cloud in Frankfurt, Germany, and nowhere else. Sub-processors are EU-based, and images are held in private storage that is never served publicly.
Erasure on request, with an audit trail
Subjects and administrators can lodge erasure requests (Art. 17); an approved erasure removes the stored images and the records together. An append-only audit log records document views, exports, review decisions and erasures. Automated retention purging is on the roadmap.