Electronic income verification works by reading the documents an applicant already sent — pay stubs, bank statements, tax forms, the payroll response, the licence — and producing the figures a decision needs, rather than by asking an outside database what someone earns. It can be proved right the same way any replacement for human work is proved right: run it over files whose outcome you already know, and read every case where it disagrees with the person who decided at the time. What changes is where the evidence comes from — the disagreements, not the agreements — and how carefully both kinds of error are counted, because a process that misses a forged document and one that flags a genuine one fail in opposite directions and cost different people. Botminds’ Income and Document Verification is built to be tested that way: every figure opens at the page it came from, so a disagreement can be settled rather than argued.
The figures in the worked examples below come from the fictional sample files the solution ships with. This page does not state an accuracy percentage for it, because no honest one exists until you have run it on your own files — which is the entire point of what follows.
What is electronic income verification?
It is the part of underwriting that reads a referred applicant’s documents and produces the figures the decision needs — verified income, monthly obligations, the identity match, and a list of what does not add up — without a person doing the reading. It is not automated underwriting. The decision, the declines, the referrals and the signature stay with people; what moves is the hour of comparison that precedes them.
The distinction matters more than it sounds, because the two things are tested differently. An automated decision is judged on outcomes months later: defaults, losses, fair-lending results. Automated verification is judged immediately and exactly, because every figure it produces has a right answer sitting on a page in the same file. That is an unusually comfortable position to be in, and most buyers under-use it.
How does electronic income verification work, step by step
Six steps, run in an order that is not arbitrary: each one depends on the last having finished honestly.
Agent
Read and sortOpens every page of every document, identifies what each one is, and extracts each figure with the page and position it sits on.
Never: Never guesses a figure it cannot read — it asks for a better copy
Agent
Check the documentsRuns the integrity checks on every page: fonts and layout, file history, gross to net, tax rates, year to date, balances carried.
Never: Never declines or calls fraud — a person decides
Agent
Classify the bank activityClassifies every deposit and payment, ties each pay stub to its deposit, and finds recurring obligations the application did not list.
Never: Never reads beyond the statements provided
Agent
Match the identityMatches name, date of birth, social security number, address and employer across the licence, the payroll response, the statements and the credit report.
Never: Never overrides the identity check’s own result
Agent
Calculate the incomeApplies the credit policy figure by figure to produce verified income and the obligations behind the ratio.
Never: Never counts income without a document
A person decides
Decide and signThe analyst approves, declines or refers at the verified figure, and signs with the meaning of the signature recorded.
A person decides
Send the requestA request for a missing document goes to the applicant only when the analyst sends it.
A person decides
Resolve a signalA fraud analyst takes any held file; clearing a signal takes a written reason that a second person reads.
Where it is reliably accurate, and where it is not
Accuracy is not one property. The work splits into three kinds of task with genuinely different error behaviour, and a single percentage across all three tells a buyer nothing.
Three kinds of task, three kinds of error
| The task | What “wrong” looks like | How reliable it can be | What to do about the residue |
|---|---|---|---|
| Arithmetic on figures already read | Effectively never wrong — subtraction and percentages have one answer | Deterministic: the same input gives the same output every time | Nothing. Test it once and trust it |
| Reading a figure off a page | A transposed digit, a column read from the wrong row, a smudged scan | High on clean documents, lower on photographs and re-scans | Require the page beside the figure, so a person can check in seconds |
| Judging what something is | A transfer classified as income, a subscription classified as debt, a genuine document flagged | The weakest of the three, and the one that needs measuring | Count both error directions separately, and review the flagged population |
That split has a regulatory consequence worth knowing before you start writing a validation plan. In April 2026 the OCC and the Federal Reserve replaced the 2011 model risk guidance, and the new guidance draws its scope tightly: “model” means “a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates”, and it “excludes simple arithmetic calculations, such as those found within spreadsheets, as well as deterministic rule-based processes and software where there are no statistical, economic, or financial theories underpinning their design or use.” It also says plainly that generative and agentic systems “are novel and rapidly evolving” and “are not within the scope of this guidance” (OCC Bulletin 2026-13).
What the April 2026 guidance covers, and what it leaves you to design
| The piece of work | Inside the guidance? | What that means in practice |
|---|---|---|
| Gross to net, tax rates, year-to-date arithmetic | No — a deterministic rule-based process | Test the rules once, version them, and treat a change as a change to credit policy |
| Reading a figure off a scanned page | Not clearly — no statistical or economic theory underpins it | Measure it anyway, as an operational control: sample pages and check the figure against the page |
| A credit score or a default model fed by the output | Yes | The existing model risk framework applies to it unchanged |
| A generative or agentic system doing the reading | Explicitly out of scope | The guidance tells you to use your own risk management and governance practices; it does not tell you what they are |
| Which documents are required, and how income is counted | No — this is credit policy | Versioned policy, exception reporting, and the same treatment for the same facts |
The guidance is still the right shape to borrow from even where it does not bind. Its three validation components — conceptual soundness, outcomes analysis and ongoing monitoring — map cleanly onto this work, and one of them has a definition you can use directly: “outcomes analysis compares model outputs to corresponding real-world outcomes to assess model performance relative to model objectives and business use”, and it “can take many forms, including … standalone activities such as back-testing or outlier analysis” (OCC, Model Risk Management: Revised Guidance).
How do you back-test verification on closed files?
You take files you have already closed, run the verification over them as though they were new, and compare what it produces with what your analyst produced at the time. The outcome you are comparing against is not the loan’s performance — that is a different and much slower question. It is the figures: the verified income, the monthly obligations, the identity result, and whether a document was flagged.
Three things make the exercise honest, and all three have to be fixed before the first file is run. The comparison has to be between two figures rather than two verdicts, so that a difference can be traced to its cause. The pass line has to be set in advance, because a line drawn after the results is a line fitted to them. And the disagreements, not the agreements, have to be where the effort goes — ninety-five per cent agreement is the uninteresting part of any such result.
Note what this does not require: live traffic, a pilot population, or a decision that depends on the outcome. That is the advantage of a closed file. Nobody is harmed by the test, nothing has to be unwound, and the analyst’s original working is sitting in the file to argue with.
Building the comparison set
The composition of the set decides what the test can discover, and the natural instinct — take the last 300 files — produces a set with almost no declines, almost no fraud and almost no hard documents in it. A designed set is better.
How to compose a comparison set, by what each slice can prove
A designed set of 300 closed files
- Approved, clean — 45% · 45%
- Approved after a request — 20% · 20%
- Declined — 15% · 15%
- Confirmed altered documents — 10% · 10%
- Hard to read — 10% · 10%
What arrives on its own, taking the last 300 files
- Approved, clean — 78% · 78%
- Approved after a request — 14% · 14%
- Declined — 7% · 7%
- Confirmed cases — under 1% · 1%
Four rules keep the set defensible. Span at least two quarters, because document mix moves with the seasons and with the products you were promoting. Include every confirmed altered-document case you hold, however few. Include the files that were hard for a person — missing pages, photographs of screens, applicants with no bank account, files in a second language — because what a verification process does when it cannot answer matters more than what it does when it can. And keep the original analyst’s working, so that a disagreement can be adjudicated rather than assumed.
Reading the disagreements
Every disagreement falls into one of four buckets, and the proportions tell you different things. Classifying them is the actual work of the back-test; counting them is not enough.
The four ways a disagreement can resolve, and what each one is evidence of
| Bucket | What it means | What it is evidence of | What to do with it |
|---|---|---|---|
| The process was right, the analyst was not | A figure, an obligation or an income type the analyst missed under time pressure | The business case. This is the value you are buying | Count them, and price them: each one is a decision that was made on a wrong number |
| The analyst was right, the process was not | A misread figure, a misclassified credit, a rule applied where it should not have been | The risk. Each needs a root cause, not a tally | Fix the cause or document the limit; re-run the set afterwards |
| Both defensible, policy ambiguous | A payment made by a third party; a seasonal income annualised two different ways | A gap in credit policy, not a fault in either party | Write the rule, version it, and the disagreement disappears |
| Unresolved after review | Nobody can say from the file which figure is right | The honest residue, and the number to report | Report it as its own line. A back-test with no unresolved cases has usually not been read carefully |
One failure mode is worth naming in advance because it is common and silent. If the people classifying the disagreements are the people who chose the software, the third and fourth buckets quietly drain into the first. The April 2026 guidance has a name for the remedy — “effective challenge”, meaning “critical analysis conducted by objective experts”, performed by individuals with “sufficient independence to maintain objectivity, as well as the organizational standing and influence to effect any change” (OCC). On a verification back-test that is satisfied cheaply: have the adjudication done by analysts who did not run the evaluation, and record who adjudicated each case.
What is a false positive on a tamper check?
It is a genuine document that a check marks as suspicious. They happen constantly and most of them are innocent in origin: a stub printed to PDF and re-saved on its way through an email system, a statement photographed instead of downloaded, a payroll correction that breaks the year-to-date arithmetic, a mid-period pay rise, an employer whose template genuinely uses three font families.
A signal and a finding are different objects, and confusing them is the expensive mistake
A signal: An arithmetic or document test that did not come out as expected.
A finding: A conclusion a named person reached after reading the evidence.
A signal: The check, automatically, on every page.
A finding: A fraud analyst, with a second reader on the decline.
A signal: A hold and a referral. Never a decline, never a notice to the applicant.
A finding: A decline, a report where one is required, and a specific reason.
A signal: Whatever the checks produce. Tuning it down to look tidy hides forgeries.
A finding: As low as the evidence honestly supports.
A signal: An applicant waits while a person looks. Measurable in hours.
A finding: A creditworthy applicant is refused, on a record. Measurable in reputation.
A signal: Flagged share of clean files in the comparison set.
A finding: Confirmed cases, counted by the fraud team, never by the checker.
The cost asymmetry is what should drive the design. A false positive costs an applicant a delay and the lender an analyst’s time; a missed forgery costs the lender a loan that should not have been made. That argues for a sensitive checker whose output is never a decision — which is exactly how the checks in the solution behave. The tamper checker “never declines or calls fraud — a person decides”, and every signal shows the arithmetic it rests on, so the review is a reading rather than a retest. How the individual checks work, and the five honest reasons a stub can fail one, are in how to identify fake pay stubs.
A signal, with the arithmetic that produced it
The steps that may not be automated
Two of them are set by regulation rather than by preference, and a design that gets them wrong will not survive its first examination.
The first is the request to the applicant. A notice of incompleteness has to specify “the information needed”, designate “a reasonable period of time” to provide it, and inform the applicant that failure to provide it “will result in no further consideration being given to the application” (12 CFR 1002.9(c)(2)). Drafting that automatically is useful and saves real time. Sending it without a person is a communication from the lender that no person has read.
The second is the decision and its reason. A statement of reasons “must be specific and indicate the principal reason(s) for the adverse action”, and statements resting on “the creditor’s internal standards or policies” are insufficient (12 CFR 1002.9(b)(2)). The Official Interpretations go further on exactly the case that automation creates: where a decision method “contain[s] features that call for automatic denial because of one or more negative factors”, then “when a creditor denies the credit request because of an automatic-denial factor, the creditor must disclose that specific factor” (Official Interpretations to 12 CFR 1002.9(b)(2)).
Read that against a verification process and the design rule is obvious. Any automatic hold or automatic refusal must be able to say which specific factor caused it, in words an applicant can act on. “Our checks flagged your file” is not such a factor. “The year-to-date figure on your 28 August pay stub is the same as the one on your 25 September stub” is.
Does an automated decision need a reason?
Yes, and the reason has to be the real one. Regulation B’s standard applies to the decision regardless of how it was reached, which puts a practical constraint on the whole architecture: anything in the chain that could move a decision has to be inspectable after the fact. A score that cannot be decomposed, a classifier whose output is a number between zero and one, or a signal with no stated arithmetic behind it all produce the same problem thirty days later, when the applicant asks why.
This is why “every figure opens at the page it came from” is a compliance property and not only a usability one. It is also why the honest acceptance test for any such system is to take a decided file at random and try to reconstruct, from what the system kept, the sentence you would send the applicant. If you cannot write that sentence, the file was not verified; it was processed.
The OCC’s examiners make the adjacent point about overrides. Policy exceptions in retail lending fall into credit policy, credit scoring overrides and documentation, and “exception types and volumes should be controlled, with appropriate reporting to identify and track exceptions and appropriate analysis to determine causes, impact, and any need for corrective action” (OCC, Retail Lending, version 2.0). A cleared tamper signal is an exception in exactly that sense. Counting clearances, and reading why they were cleared, is the control that stops an automated check being quietly switched off one file at a time.
What to have ready before an examiner asks
Less about the technology than buyers expect, and more about the governance around it. The questions are predictable enough to prepare for, and the preparation is a by-product of running the back-test properly.
What to be able to produce, before anybody asks
- The credit policy that was in force, with its version and date
Income-counting rules, document rules, the stated-versus-verified tolerance and the ratio maximum, as they stood when the file was decided.
- The back-test design, written before the run
Sample composition, the comparison, the pass line, and who adjudicated the disagreements — showing they were not the people who chose the tool.
- The disagreement log, classified and unedited
All four buckets, including the unresolved ones. The temptation to tidy this is the one to resist.
- Both error rates, separately
Confirmed cases found, and the flagged share of files that turned out clean. One without the other is not a measurement.
- Exception and clearance reporting
How many held files were cleared, by whom, with what written reason, and the review of those clearances.
- A decided file, reconstructed end to end
One real file, from documents to verified figures to the reason sent to the applicant, with every figure opening at its page.
- The ongoing monitoring plan
What is re-measured, how often, and what happens when it moves — the back-test is a baseline, not an event.
The wider buyer’s questions — what to ask a vendor, what it costs, what a pilot should produce — are a different exercise, and are set out in income verification software: nine questions before you buy. The parallel exercise for statements specifically is in bank statement verification software.
One file, with every figure tied to the page behind it
Questions people ask
How accurate is automated income verification?
There is no single number, and a vendor offering one is averaging three different kinds of task. Arithmetic on figures already extracted is deterministic and effectively always right; reading a figure off a page is highly reliable on clean documents and less so on photographs; judging what a credit or a document is, is the weakest part and the one worth measuring. Measure them separately, on your own files, against the analyst who decided them at the time.
How do you test an income verification model?
Borrow the shape of model validation even where the guidance does not bind you: check that the design is sound, compare outputs with real outcomes, and keep monitoring after go-live. For verification, the middle one is a back-test on closed files — the OCC’s April 2026 guidance defines outcomes analysis as comparing “model outputs to corresponding real-world outcomes”, and names back-testing as one form of it. Set the pass line before the run, and have the disagreements adjudicated by people with no stake in the result.
Can automated income verification replace an underwriter?
No, and the parts it cannot replace are specified rather than cultural. Regulation B requires a specific statement of reasons for adverse action and, where a decision method denies automatically on a factor, requires that specific factor to be disclosed. A request for a missing document is a communication from the lender. What automation replaces is the comparison work — opening a dozen PDFs and checking them against each other — not the decision at the end of it.
What is a false positive on a tamper check?
A genuine document the check marks as suspicious: a stub re-saved on its way through email, a photographed statement, a payroll correction that breaks the year-to-date arithmetic, an employer whose template uses several fonts. They are not a defect to be tuned away, because tuning them down hides forgeries too. They are a cost to be measured — the flagged share of files that turn out clean — and contained, by making sure a signal holds a file for a person rather than declining it.
How many files should a verification pilot cover?
Enough to span at least two quarters and to contain every confirmed altered-document case you hold, which usually means a few hundred rather than a few thousand. Composition matters far more than volume: an unselected recent sample will be around three-quarters clean approvals and will contain almost no declines and almost no fraud, so it cannot discover the two things you most need to know.
Does an automated decision need a reason?
Yes. A statement of reasons for adverse action “must be specific and indicate the principal reason(s)”, and internal standards or policies are not an acceptable reason. The Official Interpretations add that where a method denies automatically on a negative factor, the creditor must disclose that specific factor. In practice this means every automatic hold or refusal has to name the figure that caused it, which is also the only form of output a back-test can adjudicate.