AVM quality control standards in practice

The interagency final rule implementing section 1473(q) of the Dodd-Frank Act took effect on October 1, 2025 [1]. It applies to mortgage originators and secondary market issuers using automated valuation models to determine the collateral worth of a mortgage secured by a consumer's principal dwelling, in certain credit decisions or securitization determinations.

The rule requires adopting policies, practices, procedures, and control systems to ensure covered AVMs adhere to quality control standards designed to: ensure a high level of confidence in the estimates produced; protect against the manipulation of data; seek to avoid conflicts of interest; require random sample testing and reviews; and comply with applicable nondiscrimination laws [1].

It deliberately does not prescribe how, giving institutions flexibility based on size and the risk and complexity of the transactions involved [1]. That flexibility, as in the HIPAA Security Rule, means you owe a documented decision for each factor rather than an exemption.

The practical consequence of that flexibility is worth spelling out, because it is easy to read as permission to do nothing formal. A small institution using a single third-party AVM at low volume can reasonably choose a lighter approach to random sample testing than a large issuer running its own model across a national portfolio, and the rule allows for that difference. What it does not allow is skipping the decision about what approach fits the institution's own size and risk. The written record that says "given our volume and risk profile, we sample at this rate and review at this cadence" is the artefact the rule is actually asking for, regardless of how light or heavy that approach turns out to be.

Here is what each factor asks of a build.

Confidence in the estimates

The first factor is about the model being good at its job in a way you can demonstrate.

What this looks like in engineering terms is straightforward: a held-out evaluation set, accuracy metrics tracked over time, and confidence intervals rather than point estimates. The part teams build too little of is the segmentation. A model with strong overall accuracy can be substantially worse on particular property types, price bands, geographies, or transaction contexts, and an aggregate metric conceals that entirely.

So the check is not one accuracy number. It is accuracy by segment, with the segments chosen to include the ones where you have less data, because sparse segments are where confidence degrades and where aggregate reporting hides it.

A concrete case worth walking through: a valuation model trained mostly on suburban single-family homes, because that is where most transactions in the training data came from, will typically show strong aggregate accuracy while performing worse on rural properties, condominiums with unusual fee structures, or newly built homes with no comparable sales history yet. If the reporting stops at the aggregate number, none of that shows up, and the model keeps producing confident-looking estimates for exactly the property types it understands least. The fix is not a different model. It is reporting that makes the weak segments visible instead of averaging them away.

The second part is knowing when the model should decline to answer. A valuation model that produces a number for every input, including inputs unlike anything in its training data, is producing false confidence. Building an explicit abstention path, where low-confidence cases route to human appraisal rather than returning a number, is both better engineering and a much easier thing to defend.

Protection against manipulation of data

This factor is often read as a model concern and it is mostly an input concern.

The question is whether someone with an interest in the outcome can influence the inputs the model uses. That covers a range of concrete mechanisms: whether property characteristics can be edited by a party to the transaction, whether comparable sales data comes from a source that can be filled with false entries, whether user-supplied information about condition or improvements feeds the estimate, and whether the same person can both request a valuation and modify the data it draws on.

The engineering answers are ordinary integrity controls. Provenance tracking on every input, so you can say where each figure came from. Immutable records of what the model saw at the time it produced a given estimate, which also serves the auditability requirement. Separation of duties between requesting a valuation and editing underlying data. And monitoring for the pattern where an input is edited shortly before a valuation is requested, which is the typical sign of the behaviour this factor exists to catch.

That last one is worth building as an alert rather than a report, because it is actionable in the moment and useless six months later.

Avoiding conflicts of interest

Largely a process and organisational factor rather than an engineering one, but it has a technical component worth naming.

If the system allows the party who benefits from a higher valuation to influence the valuation process, whether by selecting the model, choosing the comparables, re-running until a satisfactory number appears, or adjusting inputs, that is a design problem. The engineering control is to record every valuation request and its result, including the ones that were discarded, so that a pattern of re-running until the number is right is visible rather than invisible.

Systems that only store the accepted valuation cannot show this, and the absence is difficult to distinguish from good behaviour.

A related pattern worth checking for specifically: a workflow where a valuation request can be cancelled and immediately resubmitted with different inputs, such as a corrected square footage or an updated list of recent improvements, without any link recorded between the original request and the resubmission. Each individual resubmission may be entirely legitimate, since inputs genuinely do need correction sometimes. What makes it a conflict of interest risk is the absence of a link: without one, a party who resubmits five times and keeps only the highest result looks, in the data, identical to five unrelated homeowners who each requested a valuation once. Recording a session or request-chain identifier that survives a cancel-and-resubmit cycle is a small schema change that makes the pattern visible.

Random sample testing and reviews

This is the factor that matches most directly how we build, because it describes a continuous evaluation process in regulatory language.

A defensible implementation samples valuations on an ongoing basis, compares them against an independent standard such as a subsequent appraisal or an actual sale price where available, records the comparison, and tracks the distribution of error over time. Random selection matters, because a sample chosen by anyone with an interest in the result is not a sample.

Two things make this substantially more useful. Stratify the sample so that sparse segments are represented, since pure random sampling from a skewed population will under-sample exactly the cases where the model is weakest. And retain the results for the long term, because the value is in the trend, and a gradual change in the error distribution over a year is the signal you most want and the one short retention windows delete.

Compliance with applicable nondiscrimination laws

The fifth factor is a quality control standard requiring covered AVMs to comply with applicable nondiscrimination laws [1], and it is the one that cannot be satisfied by anything except measurement.

The mechanics are on testing a model for disparate impact, and the reason removing protected attributes does not address it is on why removing the protected field is not a defence.

The specific concern in valuation has a long documented history in housing, and it is why this factor was included. A model trained on historical valuations learns historical patterns, including any that reflect past discrimination in the market it learned from. The model is not doing anything wrong in a technical sense; it is accurately reproducing what was in the data. That is precisely the problem.

Making it a build artefact rather than a review

The pattern we would recommend, and it is the same one across every regulated industry: turn each factor into checks that run continuously, keep a written decision record for the approach you chose to each factor, and retain the results for the long term.

Doing that produces the policies, practices, procedures, and control systems the rule asks for, as a byproduct of building, rather than as a document written alongside a system that may or may not implement it. The reasoning is on using evals as compliance evidence, and it applies with unusual directness here because this rule explicitly names testing.

Whether the rule applies to your institution and which of your models are covered are questions for counsel. If you want help building the measurement once that is settled, get in touch.