Automated income verification in auto lending: what it may decide

Automated income verification is software reading an income document — usually a pay stub — and saying whether it supports the income the application claimed. It does four things a person would do: find the figures on the page, convert them to a monthly amount, compare that amount with the application, and return a verdict with a reason. What it must not do is decide anything that was never arithmetic in the first place, which is most of the interesting cases. In Botminds' Dealer Funding Status Assistant the check returns pass, review, fail or missing with the reason, clears a document on upload only where the lender's own settings allow it, and never re-decides income: a waiver goes to the analyst the funding policy names, with the policy test assembled in front of them.

The product numbers below are the solution's own sample data, on a fictional lender and fictional buyers. There is no accuracy rate on this page, because the sample data does not carry one and an invented one would be worse than none. The regulatory material comes from the OCC, the CFPB, Regulation B and a Federal Reserve Bank of Philadelphia working paper, linked where they appear.

What automated income verification actually is

It is a document check, not an income decision. The distinction is the whole subject. Reading $2,412.50 from a stub, multiplying by 26 and dividing by 12 is arithmetic, and a machine does it faster and more consistently than a person at four o'clock. Judging whether that income will still be there in three years is not arithmetic, and no amount of document reading gets you there.

The OCC's handbook separates the two cleanly when it sets out what a capacity analysis has to weigh: "Three important considerations for a prudent capacity analysis are level of income, expected reliability of the income, and level of expenses" (OCC, Retail Lending, version 2.0). An automated check can establish the level. Reliability and expenses are somebody's judgement, informed by the file.

The same section says where verification sits in the supervisory picture, and it is higher than most people assume: "Information verification practices: Sufficient due diligence should support credit information before it is used." Not after it is used, and not when a question is raised — before. A check that runs at upload, while the dealership is still in the conversation, is doing that; a check that runs during a post-funding quality review is doing something useful but different.

Note also what the handbook says can be verified a different way: "Some data can be reasonably verified using credit reports (including other debt obligations), public records (bankruptcies, judgments, etc.), and personal information (name and address, Social Security number, etc.)." Income is conspicuously not on that list. It comes from documents, which is why the document check is the control.

The four things a check on a pay stub must do

Any product in this space should be able to show you each of the four, separately, on a document you choose.

Read the page. Employer, employee, pay period start and end, pay date, gross for the period, year-to-date gross, and the deductions if your standard looks at net. The period dates matter more than the pay date, and a check that reports the pay date as the period is wrong in a way that compounds.

Do the arithmetic. Convert the period figure to a monthly one using the frequency the stub shows, not the frequency the application claimed. The commonest error on a funding desk is treating a fortnightly stub as twice-monthly.

Compare. Monthly figure against the income stated on the application, inside a tolerance the lender has set. Whether that tolerance is five per cent or ten is a policy decision; whether it exists is not.

Return a verdict with a reason. Not a score, not a confidence percentage on its own, but one of a small set of outcomes a human can act on, each carrying the sentence that explains it.

Where the tolerance comes from

From your own funding policy, and it should be written down before any software is bought. A tolerance is the lender's statement of how much disagreement between an application and a document it is prepared to treat as rounding rather than as a discrepancy. Set it too tight and the desk drowns in returns on deals that were always fine. Set it too loose and the check stops being a check.

Two things make a tolerance defensible. It is approved by a named person — in the solution's sample data the funding team lead owns it, at version 7, approved on the second of October — and it is the same for every dealership and every buyer. A tolerance that is quietly relaxed for the dealerships that complain loudest is a fair lending problem wearing an operations costume.

The exposure is not evenly spread, either. Longer-term paper is written for borrowers who are more stretched, which is exactly where an overstated income does the most damage. A Federal Reserve Bank of Philadelphia working paper on auto loan terms found the pattern in a national sample.

We show that borrowers who take out six- or seven-year loans face greater credit and liquidity constraints. They have lower credit scores, live in lower-income neighborhoods, and have significantly higher credit card utilization prior to booking their auto loan.

An, Cordell and Tang, Federal Reserve Bank of Philadelphia, working paper 20-18 (May 2020)

Read that beside your own term mix. If a growing share of your book is seventy-two and eighty-four month paper, the income tolerance on those tiers is doing more work than the same number on a sixty-month deal, and it deserves its own line in the policy rather than inheriting the general one.

How to test an automated document check: the back-test

There is exactly one honest way to buy one of these, and it is to run it over files you have already decided. Pull a sample of past deals, hide your analysts' conclusions, let the check run, then compare. Everything else — accuracy claims, benchmark tables, a demonstration on the vendor's own documents — tells you nothing about your own standard, your own dealerships' document quality or your own tier mix.

False clears cost more than false returns

A false return is a document the check sent back that an analyst would have accepted. It costs a dealership an irritated telephone call and the deal perhaps a day. It is visible the moment it happens, because the dealership complains.

A false clear is a document the check accepted that an analyst would have returned. It costs you a funded loan written on income that was not there, and it is invisible — nobody complains about a deal that funded. You find them in a post-funding quality review, months later, in batches, and each one is a documentation exception on a loan you already own.

That asymmetry should drive every configuration decision. It is the reason a Review verdict exists at all; it is the reason the tolerance is a policy question rather than a tuning parameter; and it is the reason the only number worth putting a ceiling on in a contract is the false clear rate. In the solution's sample configuration the asymmetry is built into which conditions may clear without a person: insurance, residence and identity can clear on upload, and income clears only inside the approved tolerance — because a wrong address is recoverable and an overstated income is not.

The supervisory view points the same way. Undocumented income is one of the things an auto finance examination looks for as evidence of a high-risk book, and it is a funding-desk failure before it is ever a credit failure. A check tuned to maximise its clear rate is a machine for producing them, which is why the clear rate is the wrong thing to put in a contract and the false clear rate is the right one.

What the check must never decide

Four things, and all four are decisions rather than readings.

Whether to waive the condition. A waiver is the lender choosing to fund without the evidence its own policy asks for, and it belongs to the person the policy names. In the solution's sample data that request arrives with the whole test assembled — tenure, payment-to-income, whether the first stub matched the application, whether the tier allows a waiver at all — and the analyst approves, declines, keeps the condition or reassigns it.

Whether unusual income counts. Variable pay, a second job, benefit income, self-employment: all of these are read the same way by a document check and weighed very differently by a credit policy. The handbook's phrase is the right test — "expected reliability of the income" — and reliability is not on the page.

Whether to decline. A decline is adverse action, and Regulation B requires the statement of reasons to be substantive: it "must be specific and indicate the principal reason(s) for the adverse action. Statements that the adverse action was based on the creditor's internal standards or policies or that the applicant, joint applicant, or similar party failed to achieve a qualifying score on the creditor's credit scoring system are insufficient" (12 CFR 1002.9(b)(2)). A document check has no business generating that sentence.

And whether the file is complete. That one is subtler. Regulation B gives a creditor a route for a file that is short of something the applicant can supply: a notice of incompleteness, naming what is needed and the period in which to provide it, under 12 CFR 1002.9(c). Sending it is a creditor's act with a clock attached, not a verdict that a reader of documents issues.

An upload that states the test before the document is sent

What an examiner will ask you for

Not the model. The evidence that you know what the check does and that somebody owns it. The OCC's examination procedures tell examiners to "Analyze the level, composition, and trends of underwriting and loan documentation exceptions, and determine the potential impact on the quantity of risk" — composition and trend, not a total. If your documentation exceptions are flat in number but shifting towards income, that is the finding.

The CFPB's auto finance procedures are more specific still about what gets requested, and one item on the list surprises people: alongside "loan/lease applications and verification of information relied on in determining ability to repay" and the "contents of underwriting and closing files" sits "relevant computer program and system details" (CFPB, Auto Finance examination procedures). The check itself is in scope. So are the "operating checklists, worksheets, and review documents" that say how it is meant to be used.

Running it beside your analysts first

Run it silently for a month. The check sees every income document as it arrives and writes its verdict where the dealership cannot see it; the analysts work exactly as before. At the end you have a live back-test on a full month of your own volume, including the bad weeks, and you can turn clearing on one condition at a time.

Start with the conditions where a mistake is cheap and visible. Proof of residence is a good first: the test is mechanical — is the tenant the buyer, does the address match the contract, is the document inside the date window, is it signed — and a wrong answer surfaces immediately. In the sample data that re-check ran four named tests on an uploaded lease in three seconds and flipped the deal into the afternoon wire. Income last, and with the tolerance set where your policy already sits rather than where the pilot looks best.

A condition cleared on upload, and the deal moving

One last caution about the number everybody asks for first. An accuracy rate quoted without a sample, a standard and a split between the two kinds of error is not a measurement; it is a marketing figure with a decimal point. Ask what the denominator was, who decided the truth, and how many of the errors were clears.

To see the check, the verdicts and the hand-off it produces on real deals, start from Dealer Funding Status Assistant.

Questions people ask

How does automated income verification work?

It reads the document, converts the period figure on it to a monthly amount using the frequency the document shows, compares that amount with the income on the application inside a tolerance the lender has set, and returns a verdict with a reason. Good implementations name the individual tests they ran — employer, period dates, gross, year-to-date — so a reviewer can see which one failed rather than only that something did.

Is automated income verification accurate?

That question has no answer outside your own files, which is why a back-test is the only sound way to buy one. Accuracy also hides the distinction that matters: a check can be highly accurate overall and still be clearing documents your analysts would have returned. Count false clears and false returns separately, and treat the first as the number to bound.

Can a lender verify income without pay stubs?

Often, within its own standard — bank statements, a written verification from the employer, tax returns for the self-employed, award letters for benefit income. What a lender will accept differs by credit tier and is set in its documentation standard rather than by law. An automated check should read whichever documents your standard allows and refuse the ones it does not, rather than quietly accepting a substitute.

What is a false clear?

A document the check accepted that a person would have returned. It is the expensive error, because it is invisible: nobody complains about a deal that funded, so false clears are found in a post-funding review, in batches, as documentation exceptions on loans the lender already owns. A false return — a document sent back that should have passed — is irritating but self-reporting.

Should a machine decide an income exception?

No. An exception is the lender choosing to fund without the evidence its policy asks for, and the OCC expects responsibility and authority for approving exceptions to be in writing with regular reporting. What software can usefully do is assemble the test — tenure, payment-to-income, whether the first document matched the application, whether the tier allows it — and put it in front of the named person whose decision it is.

What records do you need to show an examiner?

The documentation standard the check was configured against, the back-test with its sample and both error rates, who approved the tolerance and when, which conditions may clear without a person and why, every verdict with the document and the reason behind it, every waiver with its policy test and signature, and exceptions by reason and by dealership over time. Composition and trend matter more than the total.