Vendor Governance: When and Why to Use an AVM Vendor Firewall

The AVM Final Rule does not require vendor controls

Let's start with what the rule does not say. The Interagency AVM Final Rule does not require institutions to maintain a list of approved AVM vendors. It does not require vendor firewalls, whitelists, or blacklists. It does not prescribe which vendors an institution should or should not use.

What the rule does require is quality control standards — including confidence thresholds (Factor 1) and conflict-of-interest controls (Factor 3). Vendor governance is an operational tool that helps institutions implement these standards more effectively. It is not a regulatory requirement itself, but it can make regulatory compliance significantly easier to manage and demonstrate.

When vendor controls make sense

Institutions typically adopt vendor access controls for one or more of these reasons:

Contractual requirements

Some institutions have contractual relationships with specific AVM vendors. These contracts may specify which products are approved for use, which loan types they cover, or which geographies they are validated for. A vendor firewall in whitelist mode ensures that only contractually approved vendors are accepted at intake — preventing an operator from accidentally submitting an AVM from an unapproved provider.

Quality thresholds

Not all AVM vendors perform equally. An institution that monitors vendor-level confidence distributions may find that certain vendors consistently produce scores in the MEDIUM_LOW or LOW tiers. Rather than rejecting individual loans after the fact, a vendor firewall can prevent those vendors from entering the compliance pipeline at all.

Conflict-of-interest management

Factor 3 of the AVM Final Rule requires institutions to seek to avoid conflicts of interest. If an institution identifies a vendor with a material conflict — an ownership relationship with the originator, a data-sharing agreement with a party to the transaction — blocking that vendor at the firewall level is more reliable than relying on per-loan COI checks to catch every instance.

Regulatory guidance

While the AVM Final Rule does not mandate vendor controls, individual regulatory agencies may issue guidance or examination procedures that expect institutions to demonstrate vendor governance. An institution with a documented vendor management program — including performance monitoring, firewall controls, and governance decisions — is better positioned for examination than one relying solely on per-loan policy checks.

Three firewall modes

A well-designed vendor firewall supports three operational modes, each appropriate for different institutional contexts:

Allow All

No vendor filtering. All AVMs are accepted at intake regardless of vendor. Per-loan policy checks (confidence thresholds, COI triggers) still apply. This is appropriate for institutions that want maximum flexibility and prefer to manage vendor quality through per-loan controls rather than blanket access rules.

Block List

Specific vendors are blocked. All others are accepted. This is appropriate when an institution has identified a small number of vendors that should not be used — due to poor performance, conflict of interest, or contractual restrictions — but wants to accept AVMs from any other vendor without pre-approval.

Approved Only

Only vendors on the approved list are accepted. All others are blocked at intake. This is the most restrictive mode, appropriate for institutions with formal vendor management programs that require explicit approval before a vendor's AVMs can enter the compliance pipeline.

How vendor controls interact with COI policies

Vendor firewall controls and Factor 3 conflict-of-interest policies serve different purposes, but they interact. A vendor might be on the COI watchlist (triggering an alert or block at the loan level) and also appear in the firewall (preventing intake entirely). The two mechanisms work at different layers:

• Vendor firewall: Operates at intake. Blocks or allows vendors before any policy checks run. Binary decision: the vendor is accepted or rejected.
• COI watchlist: Operates at the policy check layer. Evaluates each loan against configured triggers after the data has entered the pipeline. Configurable response: block, alert, or log.

An institution might use both: the firewall blocks vendors that should never be used under any circumstances, while the COI watchlist flags vendors that require additional review or documentation but are not categorically prohibited.

Vendor analytics as the foundation

Effective vendor governance requires data. Before an institution can make informed decisions about which vendors to approve, block, or monitor, it needs to understand vendor performance across its actual loan corpus.

Key vendor metrics include MISMO-normalized confidence distributions, tier breakdowns, pass/alert/fail rates, geographic coverage, normalization quality (how cleanly the vendor's data normalizes), and PP10 coverage (what fraction of the vendor's scores carry a documented probabilistic claim).

These analytics are not just for firewall decisions. They are the intelligence layer that informs vendor contract negotiations, vendor diversification strategies, and the institution's overall AVM risk posture. The firewall is the enforcement mechanism; the analytics are the decision-making foundation.