All insights

A value is not an exit

A property value model estimates a price. A simulation asks when that value might become usable cash, and what could get in the way.

THE ESTIMATETHE EXIT

The buyer has signed. The agreed price is close to the one a property app estimated months earlier. On the day a loan falls due, the seller opens her banking app and finds that the proceeds have not arrived. The seller, the loan and the transaction are hypothetical. The possibility is not: a price estimate can be accurate while a cash plan fails.

Go back to the day she first saw the estimate. She subtracted the mortgage from the figure on the screen and pictured what would be left to meet the loan. The calculation looked complete. It did not include the time needed to find a buyer, the chance that an offer might fall through, or the interval between a signed contract and usable funds. A model had answered one question well. The owner had mistaken it for an answer to another.

What the number knows

An automated valuation model, or AVM, uses property and market information to estimate a value. Recent comparable transactions, location and physical characteristics can all matter. Some AVMs use machine learning; others use more conventional statistical methods. The label describes the job, not one particular algorithm. In mortgage contexts, the Federal Housing Finance Agency's AVM rule describes the job as estimating the worth of collateral and requires quality controls for certain uses. It does not promise that the estimate is the cash a particular owner will receive.

The distinction matters even if the estimate is excellent. A completed sale is one observation of a transaction under particular conditions. It is not a promise that this owner can find the same buyer, at the same price, in time for her obligation. A valuation may come with a range or confidence measure. That range describes uncertainty about value under the model's definition. It does not, by itself, describe the route from listing to an accepted offer, from offer to closing, or from closing to spendable proceeds.

Picture two homes with similar estimated values. One has a large pool of buyers who can finance it. The other may appeal to a narrower group, or have an unusual feature that takes time to understand. A price model may already account for some of that difference. It may even use local liquidity signals. But unless it explicitly models the calendar and the possibility of no transaction, the identical figures on two screens do not imply identical chances of producing cash by the owner's deadline.

This is not an indictment of AVMs. It is a warning about asking a tool to answer a question it was not built to answer. The house may be worth the estimated amount. It may still fail to sell in time.

What a simulation must follow

A property simulation starts with a different unit of analysis: a possible course of events. The owner chooses an asking strategy. Buyers arrive or do not. Offers differ. Financing can succeed, stall or fail. Costs accumulate while the house is held. A sale may close after the deadline, or not close at all. The output is not necessarily one predicted ending but a distribution of outcomes under stated assumptions. NIST's Uncertainty Machine demonstrates the underlying principle of propagating uncertain inputs through a model, including inputs that move together. A property simulation has additional behavioral and transaction assumptions that NIST's example does not supply.

Suppose the owner compares a higher asking price with an earlier price reduction. The simulation ought to show more than two final sale prices. It should show how often each strategy reaches usable cash by her date, how much cash remains after debt and costs, and what happens in paths where no buyer completes. The probabilities would have to be estimated and tested on relevant property histories. The arithmetic alone cannot make them true.

The methods are not opposites. Machine learning finds relationships in observed data. Simulation runs a set of rules and uncertain inputs forward. An AVM's estimated value could be one input to a simulation, but it cannot certify the simulation's sale-time or closing assumptions. Machine learning could estimate pieces of that machinery, such as buyer-arrival patterns among similar listings or how often an offer reaches closing. A valuation model can represent uncertainty too. The meaningful distinction is the question visible at the end. What might this property be worth? What might happen if this owner tries to turn it into cash under these conditions?

A CONCEPTUAL MODEL

The same property.
Two different questions.

AUTOMATED VALUATION MODELWhat might it be worth?

Property characteristics and market evidence become an estimated value or range.

MARKET EVIDENCE
VALUE RANGE
PROPERTY SIMULATIONWhat might happen next?

Market conditions, choices and transaction events become possible cash outcomes over time.

LISTING DAY
CASH BY DATE?
TOGETHER, IF VALIDATED

How much usable cash, by when, and with what risk?

A conceptual comparison, not a forecast for a specific property or a description of a validated Oftu product.

Where the combination becomes interesting

Now imagine the two systems sharing a careful record of the same market. Property attributes, listing starts and withdrawals, price changes, offers where available, completed transactions, financing conditions and the costs of holding a home all carry different fragments of the story. A machine learning model might learn local patterns in those fragments. A simulation could then use the learned relationships to test decisions and expose the range of possible cash dates and amounts. This is a possible architecture, not a claim that Oftu already has every dataset or has validated every component.

There is a catch hidden in the phrase “lots of data.” Even an enormous file of completed sales cannot describe the listings that never sold. If withdrawn listings disappear, a model can learn a market in which nearly every attempted sale succeeds. If the same home is relisted under a new identifier, its long wait can look like a quick sale. If interest rates and buyer appetite weaken together, sampling them as independent inputs can populate the chart with futures the market would rarely produce. More rows do not repair a missing event or a broken join.

And the records do not explain themselves. One address may contain two units. A renovation may have happened between two recorded prices. A closing date can be mistaken for the date funds became usable. A model trained on one city's typical property may sound most certain on the unusual houses for which it has the weakest evidence. This is where AI might help organize messy descriptions and detect patterns across heterogeneous records, but it also creates new failure modes. Every inferred fact needs provenance; every confident pattern needs a test outside the data that suggested it.

The NIST AI Risk Management Framework asks builders to examine data suitability and representativeness, test and validate systems, document limitations, and monitor them in use. For property decisions, that translates into uncomfortable but useful questions. Does a forecast issued in March still work on properties listed in April? Are its deadline probabilities calibrated in thin markets as well as busy ones? Do its errors cluster around particular neighborhoods or property types? Does it remain honest about the outcomes that were never observed?

Fairness is part of that work, not a decorative final review. The FHFA's AVM rule includes nondiscrimination among its quality-control requirements for covered uses. A combined system could amplify a bad historical pattern if it treats past access to financing or past neighborhood prices as an unquestioned law of nature. Nor should a model's estimate become a self-fulfilling reason to withhold a buyer's opportunity. The answer is neither to ignore data nor to worship it. It is to know what a dataset records, what it omits, and who bears the cost when an inference is wrong.

The decision that remains human

Back before the hypothetical contract was signed, the useful output would not have been a more impressive number in a larger font. It might have been a comparison: list now and keep the price firm; list now with a planned reduction; arrange another source of cash and wait. For each choice, show the chance of funds arriving by the loan date, a range of net proceeds, and the cases that fail. Make assumptions inspectable. Let the owner change the deadline and see the answer move. Where evidence is thin, say so.

That would change what the technology does for her. The value estimate remains useful. It anchors a conversation about the asset. The simulation gives that conversation a calendar and a set of consequences. AI, used with care, could help both systems learn from a wider and messier record of the market. None of them can remove uncertainty, and no display should pretend otherwise.

On the day the loan falls due, the transfer might still be delayed. No simulation can promise otherwise. But an owner who saw that possibility months earlier could have started sooner, reserved cash or negotiated more time. The estimate could have been right all along. What she needed beside it was an honest account of when that price might become money, and what could prevent it.

Source notes