What regulation reaches a real estate product

The first thing worth establishing is that regulatory obligations in housing attach to functions rather than to product categories. There is no rule that applies to "a proptech platform." There are rules that apply to screening a tenant, valuing a property for a mortgage, advertising a housing opportunity, and extending credit, and a single product may do several of those or move into one over time.

So the useful exercise is not to classify your company. It is to list what each feature decides, and then ask which obligations attach to each of those decisions.

The gradual change that surprises teams

Here is the pattern we see repeatedly, and it is worth recognising because it happens without any moment where somebody decides to change the product's role.

Version one shows information. A landlord sees an applicant's history, laid out clearly, and makes their own decision. The software is a way to present data, and the obligations mostly concern the accuracy and handling of that data.

Version two adds a summary, because users asked for one. Now the software is emphasising some facts over others.

Version three adds a score or a recommendation, because summarising the same way every time is what a score is. Now the software is applying criteria.

Version four is when a customer configures auto-decline below a threshold, because reviewing hundreds of applications is expensive. Now the software is making the decision.

At no point did anyone hold a meeting about whether the compliance position had changed. Each step was a small product improvement requested by users. But the product at version four is doing something categorically different from the product at version one, and the obligations that attach to it are different.

Here is a concrete version of the same pattern in a valuation product, because the transition is not unique to screening. Version one shows an engineer's estimate of a property's value next to the comparable sales it drew on, so a human loan officer can sanity-check it before using their own judgment. Version two starts flagging estimates that look unusual compared to recent local sales, which sounds like a helpful warning and is also the software forming an opinion about which numbers deserve scrutiny. Version three lets the estimate flow directly into a pricing worksheet without a re-entry step, because re-typing a number that is already on the screen wastes the loan officer's time. Version four is when a lender configures the workflow to proceed automatically whenever the estimate falls within a set range of the requested loan amount, because most estimates in that range were fine and manual review of every one of them was slow. The team that built version four was solving a real operational problem at every step. None of them set out to build an automated valuation model reaching a credit decision, and yet that is what exists by the last version, with the obligations described on AVM quality control standards in practice attaching to it whether or not anyone updated the product's compliance documentation.

The practical defence is to maintain a written list of what each feature decides, reviewed when features change. It sounds bureaucratic and it takes an hour a quarter, and it is the artefact that lets somebody notice the transition while it is happening rather than afterwards.

A useful habit for catching this early is to ask, for every feature request that touches a number, a score, or a recommendation: does this change what a human has to do next, or does it change what the software does next? A request that removes a step a human used to take is the request most likely to move the software from decision support into decision making, even when the request itself is phrased as a small convenience improvement and reviewed as one.

The four functions worth knowing about

Valuation. If your software estimates a property's value and that estimate is used in certain credit decisions or securitization determinations, the interagency AVM rule reaches it. Institutions must adopt policies, practices, procedures, and control systems ensuring the model adheres to quality control standards, which include random sample testing and reviews and compliance with applicable nondiscrimination laws [1]. Effective October 1, 2025 [1]. Covered on AVM quality control standards in practice.

Screening. If your software evaluates prospective tenants, fair housing obligations apply, and HUD's May 2024 guidance addresses this specifically including where algorithms and AI perform the function [2]. Covered on tenant screening and fair housing. Screening products that use consumer report data are also covered by a separate body of consumer reporting law, which is its own area and one to take to counsel early.

Advertising and audience selection. If your software decides who sees a housing listing, that is advertising of a housing opportunity, and HUD's guidance covers online platforms using targeted ads [2]. This is the least intuitive of the four for engineers, because delivery optimisation feels like a technical concern. Covered on housing advertising and audience targeting.

Credit. If your product participates in extending credit, a substantial additional body of law applies, and that is beyond this guide's scope. What is worth knowing is that a product can easily move close to credit: a product that connects applicants to lenders, or that pre-qualifies, may be closer to credit law than the team assumes.

Why the same feature can be in scope for one customer and not another

A detail that trips up teams selling the same software to multiple customers: the function a feature performs can depend on how a specific customer configures it, not only on how the software was built.

A screening product sold with every criterion adjustable and every decision routed to human review is, for that customer, a decision support tool. The same software sold to a different customer who sets every threshold to auto-decline and turns off the review step is, for that customer, making the decision. The code did not change. The obligations that reach each deployment can differ, because the obligations follow the function actually being performed, and the function is partly determined by configuration the vendor does not control after the sale.

This matters for how a vendor talks about its own compliance position. A vendor cannot truthfully claim its product is compliant in the abstract, because compliance depends on what a specific customer's specific configuration decides. What a vendor can do is build the product so that a compliant configuration is easy to reach and a risky one is visible, for instance by logging when a customer disables human review or sets a threshold outside a recommended range, so that at minimum there is a record of the configuration in place at the time a disputed decision was made.

The obligations that apply with any of them

Along with the function-specific rules are the ordinary ones that apply to most software handling personal information: security obligations, state privacy laws that may give consumers rights over their data, and contractual commitments to enterprise customers that frequently exceed the legal minimum.

Those are not specific to real estate and the engineering answers are the same as anywhere else. The financial services hub covers the general method of building to them at how to translate a regulation into engineering requirements, and the method applies here too.

What to write down

Three artefacts, and they are the inputs to every conversation with counsel you will have.

A decision inventory. For each feature, what it decides, what inputs it uses, and whether a human reviews the output before it takes effect. That last column is the one that changes most often and matters most.

A data inventory. What you hold about applicants, buyers, and tenants, where it comes from, and where it goes. Third-party data sources deserve special attention here, because data purchased from a vendor arrives with its own accuracy problems and its own correlations.

A change log for both. So that a shift from decision support to decision making is visible as an event rather than as an accumulation.

None of these is difficult. The reason they matter is that a legal question about a housing product is almost always specific, and specific questions cannot be answered from a general sense of what the product does.

A fourth artefact worth keeping alongside the three above is a short record of who was consulted before each feature that touches valuation, screening, advertising, or credit went live, and what they said. Not a full sign-off process for every change, which would slow the team down for no benefit on low-stakes work, but a note of the fact that counsel or a compliance-minded reviewer looked at the specific change and what they flagged. Six months later, when a specific decision is questioned, the difference between "we considered this and made a documented choice" and "nobody remembers discussing it" is the difference between a defensible position and a difficult one.

If you want help listing what your product decides before you build, get in touch.