Your verification policy needs version numbers

Ask a lender how income is verified and you will usually get a good answer. Ask how that answer has changed over the last eighteen months, and which files were handled under which version, and the answer gets vaguer. The policy exists. It just does not have version numbers.

That gap matters more every year. Fair-lending review looks for files that were treated differently for no documented reason. GSE governance expectations ask you to show how decisions are controlled. Both are easier to satisfy when the policy is a thing with versions rather than a practice with a history.

A verification policy is more specific than 'verify income'. It says how confident a value has to be before it counts as verified. How many independent sources must agree. Which source types are allowed for a field, and which are required. What tolerance applies when two numbers, two percentages or two dates are close but not equal. And which fields are important enough that a person must always look, no matter how confident the system is.

Written down that way, most of what processors carry in their heads turns out to be a handful of thresholds and a list of fields. That is good news: thresholds and lists are things a system can enforce the same way on every file.

A policy you can edit in place is a policy you cannot cite. If the minimum confidence changed in March, a file decided in February has to be judged against the February policy — which means the February policy has to still exist, unchanged.

So publish versions, never edit them, and make activating a new version a deliberate act that does not rewrite what was already verified. Then 'which policy governed this file' always has an exact answer, and a policy change is a documented event rather than a drift.

Layering helps too. Most rules should apply across the whole operation, some should apply to a product or a field, and a few fields need their own treatment. A policy that layers from the whole tenant down to a single field lets you set a sensible default once and state the exceptions explicitly, instead of copying the whole policy for every variation.

Miji's verification policy covers exactly those settings — minimum confidence, agreeing sources, allowed and required source types, numeric, percentage and date tolerances, address comparison mode, and fields that always require a human. It is versioned, immutable once published, and layered from the tenant down to a single field; activating a version never alters facts that were already verified. Auto-verification ships switched off, so turning it on is your decision, made in the policy.

Two honest boundaries. Today the facts the policy governs come from the application and from the credit pull; Miji holds documents against the case but does not read values out of them. And replaying a proposed policy version against past loans before activating it is in development with design partners, not shipped. If a versioned policy is what your next exam needs, talk to us: hello@mijios.ai.