What starts as "automate some of the document checks" becomes, very quickly, a question about trust. Who decides what's suspicious? What happens when the system is wrong? How do you deploy AI in a workflow where a false positive delays a student's visa and a false negative lets fraud through to a UK university? A single mess up can cause catastrophic loss. This is what building that system actually looked like.

01 - Problem

8 compliance officers. A million documents a month. And a process that was entirely manual.

Edvoy processes applications for students applying to UK and EU universities from India and Bangladesh. Every application involves academic documents - marksheets, transcripts - plus financial documents: bank statements, sponsorship letters, loan approvals. Before any of it reaches a university, a compliance officer has to verify it.

With 50,000+ students per month and 15–25 documents per student, that's approaching a million documents a month passing through a team of roughly ten people. Each one reviewed manually. Each one a judgment call.

The volume alone was an operational problem. But the deeper problem was fraud — and fraud at a level of sophistication that manual review was increasingly not equipped to catch.

Fraud was happening at every layer:

• Marksheet grades edited in Photoshop with fonts carefully matched

• Math that almost adds up — but doesn't

• Portal mismatches: document claims a result the university's own system doesn't show

• Bank emails sent from personal Gmail addresses dressed as official correspondence

• One agent, twelve students, grade distributions too similar to be coincidence

• Screenshots of results pages submitted as official documents

• Same academic record resubmitted under a different name

What got lost:

• Fraud that looked clean to a tired human reviewer

• Patterns that only become visible across dozens of applications

• Time compliance officers spent on repetitive checks that should never have reached them

The cost of that:

Students with fraudulent documents reaching UK universities. Edvoy's compliance reputation on the line. And a team burning out on volume they were never designed to handle alone.

So we asked:

How do we build an AI system that reduces repetitive verification burden — without removing human authority from decisions that actually matter?

02 - The real scope

The surface ask was: automate document flagging. The actual problem was harder and more interesting

how do you build an AI system that compliance officers will trust enough to act on, that has clear lines of human authority, that creates an audit trail, and that fails safely when it's uncertain?

Getting the verification logic right was one challenge. But the design challenge, the one that actually determined whether this system would be adopted or ignored was building the right relationship between what the machine does and what the human decides.

The principle we established early: AI assists, humans decide. Not as a disclaimer, but as a design constraint that shaped every workflow we built. The system flags, scores, routes, and surfaces evidence. It does not approve or reject. That authority sits with compliance officers, always.

Three things had to be true for that to work in practice. The confidence scoring had to be honest, a REVIEW verdict had to mean something genuinely uncertain, not a hedge against system liability. The evidence had to be surfaced in a way officers could actually evaluate, not just a score to rubber-stamp. And overrides when an officer disagreed with the system had to require documentation and escalation, because an unconstrained override path is just manual review with extra steps.

03 - The technical ground

Why the first approach broke, and what replaced it.

The first version of the OCR pipeline used spatial extraction, Apple Vision, bounding boxes, nearest-neighbour label-finding, regex heuristics. It was brittle almost immediately. Bangladesh passports have bilingual labels in Bengali and English. Indian marksheets have wildly different layouts per board, an Anna University marksheet looks nothing like a VTU transcript, which looks nothing like a Bangladesh HSC certificate. Every new document type required new parsing logic. The regex layer grew to several hundred lines and still failed on edge cases.

Switching to Qwen-VL, a vision-language model running entirely on-device replaced approximately 400 lines of spatial parsing logic with a single structured prompt returning validated JSON. The model understands document layout semantically. It doesn't need to know where on the page a field appears; it understands what the document is trying to say. That shift from positional logic to semantic understanding was the architectural decision that made the rest of the pipeline stable.

Everything runs offline. Student documents contain passport data, academic records, and financial information, sending any of that to an external cloud OCR API introduces a data privacy risk the project couldn't accept. All inference runs locally on-device.

04 - The verification engine

14 checks. Each targeting a different fraud vector.

Every document runs through all 14. Each returns a status, a confidence score, and the specific evidence that triggered it. The final output routes the application to PASS, REVIEW, or FAIL.

• File sanity - corrupted files, wrong MIME types, suspiciously small PDF

• Duplicate grade hash - same academic record resubmitted under a different name

• Math consistency - totals that don't add up, percentages that contradict stated grade bands

• PDF forensics - multiple font layers, invisible text, metadata mismatches

• JPEG error level analysis - compression history anomalies consistent with image manipulation

• Screenshot detection - EXIF patterns, resolution, aspect ratios matching screen captures

• Institution validity - fuzzy match against UGC lists and blacklisted universities

• Subject validity - subjects claimed don't match known curriculum for that board

• Declaration date - date is in the future, or predates the institution's founding

• Bank email validation - domain MX check, personal email detection, bank domain repository

• Portal verification - live result lookup against Anna University, Punjab, Bangladesh boards

• MRZ cross-check - independent passport fraud gate (see below)

• OCR field extraction - required fields missing or unparseable

• Confidence score assembly - weighted aggregate → PASS / REVIEW / FAIL

The MRZ layer is its own fraud gate.

PassportEye extracts the Machine Readable Zone independently of Qwen-VL. A cross-check then compares MRZ fields against the visual layer. A tampered passport - genuine MRZ, edited visual content - shows a mismatch. That's what catches document compositing fraud. The most sophisticated category in the set.

another option in testing is using a vendor like hyperVerge for verifing passports with government databases.

Portal verification

Portal verification rounds out the engine with live result lookups across all 12 supported university and board portals - Anna University, VTU, JNTUH, JNTUK, Mumbai University, Delhi University, SPPU, Osmania, Punjab, CBSE, and both Bangladesh HSC and SSC boards. Every academic result being claimed is cross-referenced against the institution's own records before the application progresses.

Financial document pipeline

The financial document pipeline handles everything beyond the academic layer. Bank statements are parsed for account details, balance history, and transaction patterns. Loan and sponsorship letters are extracted and cross-referenced against the student's stated financial position. Every financial document name is verified against the student profile - a mismatch flags for review before a human ever sees it. Bank email validation adds a final check: domain MX records, personal email detection, and a maintained bank domain repository catch fake correspondence at the source.

05 - The routing problem

OCR reads "RV College of Engineering." The system needs to know that maps to VTU, not Anna University.

Portal verification is only useful if the system correctly identifies which portal to query. That routing problem turned out to be one of the more complex engineering challenges in the project.

The solution runs three layers in sequence. Register number format patterns come first - a 12-digit numeric ID routes to Anna University, a format like 1BM14CS001 routes to VTU, a specific pattern structure disambiguates between JNTUH and JNTUK by region. When register number patterns are ambiguous or unavailable, a fuzzy college name lookup runs against a 1,149-college affiliation corpus built from official university sources. The college name matching required a significant-token guard - without it, "XYZ College of Engineering" scores over 90% similarity against "RV College of Engineering" simply because they share the generic phrase. The guard strips non-identifying tokens and checks that the distinctive part of the name actually matches. State and education type heuristics provide a third fallback for cases neither prior layer can resolve confidently.

Building the affiliation corpus took meaningful time - 1,149 colleges across eight universities, assembled from official TNEA lists, VTU institution codes, and university-published rosters. It's not glamorous work. But the routing logic is only as reliable as the data it runs against.

06 - AI pre-screening interviews

The most experimental part of the system - and the one that changed how universities think about Edvoy.

Beyond document verification, the platform introduced AI-assisted student interviews before university submission. The goal was to verify intent and identity consistency at a layer that documents alone can't reach - a fraudulent application with perfect paperwork still fails if the student can't speak to their own academic history.

Students join a scheduled video interview. The system records, transcribes, and evaluates responses across six dimensions: confidence, consistency, English proficiency, intent to study, future planning awareness, and identity alignment with the submitted documents. Specific questions probe knowledge of their chosen course, their university, their academic background, and their post-study plans. The system generates a structured confidence signal for each dimension, flags areas of concern, and routes the complete interview package - video, transcript, and scoring - to a compliance officer for final review.

The interview system was designed to run with compliance officers in the loop throughout early deployment, with their review of AI-generated scoring used to validate and calibrate the model over time. It operates as a supplementary signal, not a gate - a student who interviews poorly doesn't get automatically rejected, but the flags surface clearly alongside the document verification results in the officer's review queue.

07 -Governance

The override path is where accountability lives.

The confidence-based routing system — PASS, REVIEW, FAIL — handles the clear cases automatically. The interesting design problem is what happens when an officer disagrees with the system's verdict.

The override workflow requires documented reasoning at the point of override and routes to compliance leadership for approval before the decision takes effect. Validated override outcomes are then selectively incorporated into future model calibration — not every override, because some represent legitimate edge cases the system should learn from, and others represent officer error that it shouldn't. That distinction matters and requires human judgment to make.

The documentation requirement isn't distrust of compliance officers. It's the mechanism that prevents the system from becoming manual review with extra liability. An unconstrained override path means the AI layer is decorative — it adds process without adding accountability. The override workflow is where the "AI assists, humans decide" principle has real teeth.

08 - Outcome

Manual review time cut from hours to minutes. Every fraud vector covered. The compliance team unchanged in size - but operating at a scale that would have required tripling it.

The platform launched across the full compliance workflow: document intake, OCR extraction, 14-check verification, portal cross-referencing across 12 institutions, financial document validation, AI pre-screening interviews, confidence-based routing, and governed override handling.

Review time per student - the headline number. Manual verification for a clean, automatable case dropped from 1–2 hours to under 10 minutes. That's an 85–90% reduction in time-per-case - consistent with the industry benchmark for intelligent document processing automation, where McKinsey reports up to 80% reduction in manual data entry tasks at 99.5%+ accuracy, and Forrester documents an average 60% reduction in processing time as the floor for well-implemented IDP deployments. The Edvoy system, operating on a narrower, better-defined document set than generic IDP, hit the higher end of that range.

OCR extraction accuracy. The shift from spatial regex heuristics to Qwen-VL brought field extraction accuracy to the 99%+ range that industry benchmarks set as the target for structured printed documents under good conditions. The previous spatial extraction approach was operating well below this - failing on bilingual passports and non-standard marksheet layouts with enough frequency to create meaningful downstream review burden. A 1% character error rate on a document with 50 critical fields means roughly one wrong field per document reaching a compliance officer. The semantic model eliminated that class of error almost entirely for in-scope document types.

Fraud detection coverage - by vector. The 14-check engine covers every fraud category the compliance team had previously encountered, plus pattern-level detection they had no mechanism for at all:

• Math tampering - caught automatically. Grade totals that don't sum, percentage-to-grade mismatches. Previously required a compliance officer to manually calculate on every submission.

• PDF forensics + JPEG ELA - invisible to the human eye, fully automated. Multiple font layers, invisible text overlays, and compression anomalies are detectable only computationally. This fraud class was effectively undetectable before the system existed.

• Duplicate grade hash - cross-application pattern detection. An agent submitting the same academic record under different student names is flagged on the second submission. Previously, each application was reviewed in isolation — this pattern was invisible.

• Portal mismatch - live cross-referencing across all 12 supported portals. The result claimed on the document is checked against the institution's own records automatically, replacing what was previously an ad-hoc manual lookup that only happened when an officer was already suspicious.

• MRZ cross-check - document compositing fraud caught at a layer that human review cannot access. The Machine Readable Zone is extracted and verified independently of the visual layer. This is the check that catches genuine-MRZ, edited-visual-content fraud - the most sophisticated category in the set and one that was previously invisible to the compliance process entirely.

Compliance officer capacity - the real impact. At 50,000+ students per month and 15–25 documents each, the previous process required officers to be the primary fraud detection mechanism on close to a million documents. The system routes clean, high-confidence cases through automatically. Only REVIEW and FAIL cases reach the officer queue - with structured evidence, specific flags, and a confidence score already assembled. Officers are now decision-makers on pre-triaged cases, not document processors. Industry data from KYC automation deployments shows manual review requirements dropping by up to 90% when AI-assisted triage is implemented correctly. The Edvoy system's confidence-based routing targets a comparable reduction for the automatable subset of its caseload.

Agent-level fraud - visible for the first time. The duplicate grade hash check operates across the entire application database, not just within a single submission. An agent submitting documents with statistically similar grade distributions across multiple students is now surfaced as a pattern. This class of fraud was structurally invisible under manual, per-application review - it required seeing many applications simultaneously, which no individual officer was positioned to do. The system does this automatically on every submission.

What changed most fundamentally wasn't any single metric. It was the nature of the compliance officer's job. Before: the only fraud detection layer, working through volume, hoping to catch what looked wrong. After: the decision layer on top of a system that has already done the detection, assembled the evidence, and routed by confidence. That's a different role - and a sustainable one at a scale that was becoming operationally untenable.

09 - Reflection

The hardest design problem wasn't the fraud detection. It was the governance.

I've worked on AI-adjacent products before, but this was the first time I was designing the relationship between an AI system and human decision-makers in a context where the stakes were genuinely high - a wrong decision delays a student's visa or allows a fraudulent application through to a university that trusts Edvoy's compliance process.

What I kept coming back to was this: the system's value isn't in its accuracy rate. It's in its trustworthiness. An accurate system that compliance officers don't trust will be ignored. A slightly less accurate system that surfaces clear evidence, explains its reasoning, and defers to humans on genuinely uncertain cases will be used - and will improve over time as the humans who use it catch its errors.

The override workflow embodies that principle more than anything else in the build. Overrides require documented reasoning and escalation approval not because we didn't trust compliance officers, but because unconstrained override paths erode system accountability. If every uncertain case gets manually overridden without a record, you've built a compliance tool that looks automated but is still entirely manual - plus the liability of having an AI layer that nobody audits.

The pre-screening interview system pushed that thinking further. Documents can be forged. Interviews are harder to fake at scale. Designing the interview layer as a supplementary signal rather than a gate was a deliberate choice - it keeps human authority central while adding a verification surface that the rest of the pipeline couldn't reach. Nine years of product work has taught me that the systems people trust most are the ones that are honest about what they can and can't do. This one was designed around that from the start.

Tags: AI product design · Trust & safety · Compliance systems · OCR pipeline · Fraud detection · Human-in-the-loop · Governance design · Financial document verification · AI interviews · Systems architecture