Tenant Screening Platform Problems: The 5 That Invite Fair Housing Claims, and How to Avoid Them

Why does a screening project become a report viewer?

The requirement that reaches a developer is usually pull credit, criminal and eviction data and show it to the leasing team in one place. That is a report viewer, it demos well, and it leaves the actual product untouched. The bureaus sell you inputs. What determines your loss rate, your fair housing exposure and your leasing velocity is the policy applied to those inputs, how consistently it runs, and whether you can evidence it afterwards.

A viewer moves the judgement to a human at a leasing office, which is precisely where inconsistency lives. Two agents in two properties reading the same report reach different conclusions, and the pattern of those differences is what a disparate impact analysis surfaces.

The second half of the same failure is deciding your Fair Credit Reporting Act posture late. The FCRA imposes obligations on entities that assemble or evaluate consumer information and furnish it to third parties for tenant screening decisions, so a platform other landlords use sits differently from one you run on your own portfolio. If those obligations apply, consumer file access, dispute handling and reinvestigation with defined timelines are first class features rather than a later phase. Put that question to counsel in week one, before any architecture is chosen. Retrofitting the consumer side later is expensive and usually gets discovered after the first demand letter.

Scope the first release around applicant intake with identity verification, a rules based decision engine with recorded reasons, payroll and bank income verification, document fraud checks and adverse action generation. That is $80,000 to $170,000 over 14 to 22 weeks in our delivery experience.

What goes wrong when existing criteria are turned into rules?

Every operator believes they have written criteria. What they usually have is a page that says minimum credit score, income of three times rent, no evictions in the last however many years, plus a set of unwritten practices that leasing staff apply daily: what counts as acceptable proof of income for a self-employed applicant, when a guarantor is offered instead of a decline, and when a higher deposit is used instead.

Turning that into a rule set forces every unwritten practice into the open, and it takes longer than anyone plans. Two things surface. Different regions apply different thresholds, which nobody had quantified. And some practices cannot survive being written down, because once a rule is explicit somebody has to own it, and the owner realises they would not defend it in writing.

That discomfort is the value of the exercise, and it needs counsel in the room rather than after the fact. Version the criteria set with effective dates, because you will change it and you need to know which version decided each application. Migrate historic decisions as records rather than as recomputable cases. And resist encoding a single blunt income multiple. Deposit stability across several months, income volatility and rent burden against local cost data predict payment behaviour better and treat variable earners more accurately.

Why do the bureau, payroll and record source feeds break after launch?

Four categories of supplier, four different failure modes. Bureau feeds break on certification and contract terms rather than technology: a permissible purpose configuration changes, or a certification is renewed with a different requirement. Payroll and bank connection providers such as Argyle, Truv, Pinwheel or Plaid break on coverage, meaning a payroll processor changes something and a segment of applicants can no longer connect. Criminal aggregators break on source availability, because a county changes how it publishes and coverage silently narrows. Eviction data varies enormously by county in quality and freshness.

The dangerous pattern is silent degradation rather than an outage. If a criminal source stops returning results for a jurisdiction, your platform reports clean applicants and nobody notices, because a clean result looks like a normal outcome. If a payroll provider loses coverage for an employer, applicants quietly fall back to document upload.

The fix is to monitor the shape of results, not just the availability of the endpoint. Track hit rates per source per jurisdiction, verified connection rates per provider, and fallback to document upload as a rate rather than an event, and alarm on a shift. Record for every decision which sources were queried and what each returned, including empty results, so the evidence shows what you actually knew. Then keep a manual review path usable when a source is degraded, because the alternative is declining people on the basis of missing data.

What happens when adverse action and disputes are not covered?

Adverse action is where a decentralised portfolio is most measurable and most often wrong. When an application is denied, or approved on worse terms such as a higher deposit or a required guarantor, notice obligations are triggered. In practice these go out inconsistently, late, or not at all, and the copy varies by office. Any regulator or plaintiff's firm looking at your process starts here, because it is countable.

Conditional approvals are the case most often missed entirely, since staff do not experience them as a denial. A higher deposit is a worse term, and the obligation follows.

Generation has to be automatic, triggered by the decision itself rather than by a person remembering. The notice identifies the consumer reporting agency that supplied the information, states the applicant's rights including the free file copy and the dispute route, and is delivered through a channel that records proof of delivery. Where an individualised assessment is required in a jurisdiction, capture it as structured input rather than a free text note.

Disputes are the other deferred gap. If you carry consumer reporting agency obligations, a dispute is a tracked case with a clock, a reinvestigation record of what changed, and propagation of corrections to every decision that relied on the disputed data. Building that after launch means going back through decisions already made. The useful side effect of doing both properly is that decline reasons become analysable, so you can run your own disparate impact review first.

Should you build custom or configure what you already own?

If you screen a few hundred applications a year, do not build. TransUnion SmartMove exists for exactly that operator and building anything would be indefensible. If you are mid sized with simple uniform criteria in markets without fair chance ordinances, RentSpree plus a bureau report will serve. If your only real problem is forged documents, buy Snappt and stop there. If you want an outsourced decision with a guarantee attached, look at what Findigs offers before you build the same thing.

Before commissioning anything, do the work that costs nothing. Write your criteria down completely, including the unwritten practices, and have counsel review them. Standardise your adverse action template and make sending it a required step in whatever tool you use today. Pull a few hundred recent decisions and check whether the stated criteria actually predict them, because if they do not, no software will make them consistent. Those three frequently remove the largest share of exposure and tell you what is left to build.

Build when two or more of these are true. Screening is part of a product you sell, in which case the platform is the business. You operate across jurisdictions with materially different record rules and cannot enforce them through training. Your criteria are genuinely differentiated and a packaged product forces you back to a blunt ratio. You need decision level evidence for fair housing defence and your current stack cannot produce it. Or fraud losses have become a line item and generic detection has stopped keeping up.

How do hidden costs get into the quote?

Five items produce most of the overrun in screening builds.

• Consumer reporting agency posture. If you carry those obligations, consumer file access, disputes and reinvestigation are effectively a second product with their own interface, timelines and support load.
• Supplier onboarding calendars. A credit bureau, a criminal aggregator, an eviction source and an identity provider are four contracts with four certification processes, and no amount of engineering effort compresses them. Start them in parallel with development, not after.
• Jurisdiction coverage. Every fair chance housing ordinance is separate rule work with separate counsel review, and the rule set needs effective dates because ordinances change.
• Document fraud depth. Metadata and editing artefact analysis, font and object anomaly detection and internal arithmetic checks are a specialist build.
• Criteria definition. Getting the unwritten practices written, quantified and approved by counsel is weeks of your people's time and it is never in a developer's estimate.

What keeps the number down is buying the data and building the decision. Integrate a bureau product for the report and put the engineering budget into policy, verification, consistency and evidence, which is where both the value and the risk live.

What separates a build that works from one that fails here?

Ask about FCRA posture in the first meeting. A developer who does not immediately ask whether you will be furnishing reports to third parties has not built in this space, and the answer determines the architecture rather than a feature list.

Ask them to model the decision out loud. You should hear applicant, identity, data source result with match confidence, jurisdiction rule set with effective dates, criteria version, decision with reasons, notice and dispute. If the sketch is applicants and reports, you will get a report viewer and inherit the compliance problem you were trying to solve.

Ask how a record with a weak identity match is handled. Criminal and eviction sources often match on name and date of birth alone, which returns records belonging to other people, and the applicants most affected are those with common surnames. The right answer stores match confidence per record with the fields that matched, sets a threshold below which nothing can drive an automated decision, routes those to human review with the evidence visible, and logs every suppressed record and why.

Then settle ownership in writing before kickoff. You should own the repository, the cloud accounts, the database and the full decision audit log. At Digital Heroes the client owns the code and the data from the first commit. Those records are the evidence in any fair housing or FCRA matter and may be needed years after the application was decided.