Remote onboarding looks simple: a customer photographs an ID on their phone, and a model reads it, assesses it, and passes the result along. Behind that flow sits a training set that is harder to build than it appears. Phone captures vary far more than flatbed scans, with different lighting, angles, backgrounds, and cameras. The stakes are unusual too: one wrong character in a document number can fail an onboarding and send a legitimate customer to manual review. Guidelines therefore have to be built for messy real-world captures, not clean samples, and every ambiguity left unwritten becomes label noise the model will learn.
The first label is usually the document type, which determines the fields to expect. Typical classes include passports, national IDs, driver’s licences, residence permits, and proof-of-address documents such as utility bills and bank statements, each with its own expected fields.
Three decisions need explicit rules. First, version and issue-year variants: say whether each layout is its own class or a sub-attribute. Second, front versus back: label each side separately, because the fields differ. Third, an “other/unsupported” class for anything outside the taxonomy. Without it, annotators force unfamiliar documents into the nearest class, and the model learns to be confidently wrong. Review the taxonomy against real submissions regularly, since new document versions appear over time.
Core fields are name, date of birth, document number, issue and expiry dates, issuing country, address, nationality, and sex. List which fields each document type carries, and what to do when one is absent, since not every document has every field.
Many documents print data twice: in the visual inspection zone and in the machine-readable zone (MRZ). Annotating both enables cross-checks but doubles the work, and you need a rule for which zone wins when they disagree.
Also choose the output type: a bounding box trains detection, a transcription trains reading, and a normalized value, such as an ISO date, trains the downstream schema. Many teams collect all three, which works only if the guideline keeps them clearly separate and says which one each annotator is producing at each step.
Then settle the decisions that cause the most disagreement:
Quality labels often drive what the customer sees next. A wrong “retake” frustrates users and can lead them to abandon onboarding, while a wrong “fine” pushes unreadable images downstream, where they fail extraction or land in manual review.
Define each defect separately: blur, glare and reflections, low light, cropping, skew, occlusion (a finger over the card), low resolution, and screen-recapture. Give each a severity scale, such as none, mild, moderate, and severe, with reference images at every level so annotators calibrate to the same standard.
Then define the overall verdict, where annotators diverge most, with a functional rule: an image is “usable” if every required field can be read with confidence, however it looks to the eye. A slightly soft photo with a sharp document number passes; a crisp photo with glare across the expiry date does not.
Collect these cases as they appear and fold each ruling back into the guideline, so the same question is not answered differently next month by a different annotator.
Measure fields and quality labels differently. For fields, report exact match, which matters when one character can fail an onboarding, and character error rate, which shows how close the misses are, per field. For quality labels, track inter-annotator agreement, especially on the usable versus retake verdict. Two controls hold it together: gold-set audits to catch drift, and escalation of ambiguous cases to a senior reviewer, with each outcome recorded as a guideline update. Low agreement usually signals an unclear definition, not careless annotators.
KYC images are dense with personal data. Use a vetted workforce, controlled environments, and access logs. Mask fields the task does not need, such as the photo and address during quality-only jobs, so each annotator sees only what the job requires. Set retention limits and delete data when the project ends. Prefer synthetic or consented data where possible, since it removes much of the risk before annotation begins. Selfie matching and liveness are adjacent tasks that need their own guidelines.
A good KYC annotation spec defines the taxonomy, field rules, output types, quality severities, and a functional “usable” verdict, then backs them with strict QA and careful data handling. Precision on small details, one character, one verdict, one clearly written rule, is what lets a model read real customer photos the way the onboarding team needs. Teams that write this before labeling begins spending far less time relabeling later. Get this right, and good customers avoid needless retakes or reviews. To get more details, contact us through Contact Globik AI - Talk to AI Experts.
KYC document annotation is the labeling of ID images, such as passports and national IDs, so models can classify documents, extract fields, and judge image quality. It produces the training data behind automated customer onboarding at banks, neobanks, and fintechs, where a person photographs an ID and a model must read it.
Annotate name, date of birth, document number, issue and expiry dates, issuing country, address, nationality, and sex, where each document carries them. Also decide whether to label both the visual zone and the machine-readable zone, and write a rule for which one wins when they disagree.
An ID image is usable when every required field can be read with confidence. Judge it by readability, not appearance. A soft photo with a sharp document number passes, while glare over the expiry date means the customer must retake it. This functional rule keeps annotators consistent and ties the label directly to the prompt customers see.
Use field-level exact match and character error rate for transcribed fields, and inter-annotator agreement for quality labels. Add gold-set audits, which seed known-answer items into the queue to catch drift, and an escalation path so ambiguous cases reach a senior reviewer.
Protect it with a vetted workforce, access controls, logging, and masking of fields the task does not need. Set retention limits, and use synthetic or consented data wherever possible to reduce risk before annotation starts.
