Tenant Screening Platform Development: Can You Prove Every Decline Was Consistent and Legal?

Why screening is a regulated product wearing the costume of a web form

A regional operator with 14,000 units has a screening process that looks like this. The applicant submits through the property website. A leasing agent pulls a report from a screening provider, glances at the score, opens two uploaded pay stubs, does mental arithmetic against a three times rent rule, and approves or declines. On decline, some agents send the adverse action notice from a template, some call the applicant and explain, and some do neither. There is no record of what decision rule was applied, and no way to answer the question that eventually arrives from a fair housing tester or a state attorney general: show us your criteria and show us that they were applied identically to every applicant.

The market has real products in it. TransUnion SmartMove is a solid packaged answer for small landlords. RentSpree handles application flow well. Snappt built a genuine business on document fraud detection because the problem is that real. Findigs went further and sells a decision, not a report. Contemporary Information Corp operates as a consumer reporting agency with the obligations that carries. Each of them is a legitimate purchase and for a lot of buyers the honest advice is to buy one.

The reason operators and marketplaces still build is that the decision, not the data, is the product. 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. That logic is your business and it does not fit inside a report viewer. Everything below assumes you have counsel involved, because screening sits under the Fair Credit Reporting Act, the Fair Housing Act, and a growing set of state and municipal rules, and no blog is a substitute for a lawyer who knows your markets.

Problem 1: you may be acting as a consumer reporting agency without having decided to

This is the first question to put to counsel and most teams put it last. The FCRA imposes obligations on entities that assemble or evaluate consumer information and furnish it to third parties for tenant screening decisions. If you build a platform and other landlords use it to decide on applicants, your posture is different from a platform you use only on your own portfolio. The obligations that follow include permissible purpose, accuracy procedures, disclosure to consumers, and a reinvestigation process for disputes with defined timelines.

What a custom build does when the answer comes back that you carry those obligations: build the consumer facing side as a first class part of the system rather than a bolt on. A consumer can request their file, a dispute creates a tracked case with a clock, a reinvestigation records what changed, and corrections propagate to every decision that used the disputed data. Retrofitting that into a landlord only platform is expensive and usually discovered after the first demand letter. Decide the posture in week one, with counsel.

Problem 2: matching is where the wrong person gets declined

Credit, criminal, and eviction data arrive from different sources with different matching keys. Credit comes back on a full identity match. Criminal record aggregators and county sources often match on name and date of birth alone, and common names produce hits belonging to other people. Eviction data quality varies enormously by county and by how the court publishes filings. A platform that concatenates these results and presents them as one record will, at volume, decline people for someone else's history, and the applicants most affected are those with common surnames, which is precisely the pattern a fair housing analysis will surface.

What a custom build does: never treat a returned record as identified. Store match confidence per record with the fields that matched, and set a threshold below which a record cannot drive an automated decision and must go to human review with the evidence visible. Log every suppressed record and why. That is a fairness control and a defence control at once, because how you concluded this was the same person becomes a stored, reviewable fact.

Problem 3: pay stubs are trivially forged, and connected data ends the argument

An applicant can buy a convincing pay stub for a few dollars, or edit a genuine one in a browser. Bank statement PDFs are just as easy. This has become a real loss source for landlords and it is why Snappt exists and why underwriting products moved toward verified data. Detecting a forged document is a genuinely hard problem: you are looking at metadata, at editing artefacts, at font and layout inconsistencies, and at internal arithmetic that does not tie.

What a custom build does: prefer verified sources and treat documents as the fallback. Payroll connections through providers such as Argyle, Truv, or Pinwheel, and bank account connections through Plaid or a comparable aggregator, give you income and deposit history from the source rather than from an uploaded image. Offer that path first with a clear consent flow, and reserve document upload for applicants who cannot connect, which is a real population you must not exclude. For documents, run the checks that actually work: PDF producer and modification metadata, embedded font and object anomalies, arithmetic consistency between gross, deductions, and net, and cross document consistency such as employer name matching between stubs and the bank deposit descriptors. A model that scores a document is useful. A model that scores a document without letting a human see why is a lawsuit.

The design point most teams miss: income assessment should not be a single ratio. Deposit stability over months, income volatility, and rent to income against local cost data tell you far more about whether someone will pay than a static multiple, and they treat gig and variable income applicants more accurately, which is both fairer and better underwriting.

Problem 4: criminal and eviction rules are jurisdictional, and they change under you

The use of criminal history in housing decisions has been the subject of HUD guidance, and a growing number of states, counties, and cities have adopted fair chance housing rules that restrict what may be considered, how far back, and at what point in the process. Several jurisdictions restrict use of eviction filings that did not result in judgment, and some provide for sealing of records. Which rules bind you depends on where the property is, and the answer changes when a new ordinance passes.

What a custom build does: make jurisdiction a first class object with an effective dated rule set, exactly as you would for a tax rule. Each property inherits the rules of its location. The rule set defines which record categories may be considered, lookback limits, whether an individualised assessment is required before an adverse decision, and the sequence in which information may be requested. The engine then filters records before they reach a decision, and logs the filtering. When a new ordinance takes effect, you change one rule with a date and every affected property follows, rather than emailing 60 leasing offices and hoping. Have counsel own the rule content. Your job is to build the mechanism that makes their guidance enforceable rather than aspirational.

Problem 5: adverse action is your compliance artefact, and it is the thing done worst

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

What a custom build does: adverse action generation is automatic and non optional, 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 dispute route, and is delivered with proof of delivery. Conditional approvals count and are frequently missed. Where an individualised assessment is required locally, capture it as structured input rather than a free text note. The useful side effect is that once notices are automatic and archived, your decline reasons become analysable, and you can run your own disparate impact review before someone else does.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the honest shape. A focused first release, meaning applicant intake with identity verification, a configurable decision engine with recorded reasons, payroll and bank income verification, document fraud checks, and adverse action generation, runs $80,000 to $170,000 in 14 to 22 weeks. A full platform adding bureau and record source integration, jurisdiction rules, dispute workflow, a landlord portal, guarantor handling, and fairness reporting runs $200,000 to $500,000 over 9 to 15 months.

What drives price up specifically in screening: acting as a consumer reporting agency, because the consumer side obligations are a substantial second product. The number of data sources, since a credit bureau, a criminal aggregator, an eviction source, and an identity provider are four separate contracts, each with a certification process on a calendar you cannot compress. Jurisdiction coverage, because every fair chance ordinance is separate rule work. And fraud detection depth, since serious document analysis is a specialist build.

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

Build versus buy, and when buying is obviously right

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

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 alone. Your criteria are genuinely differentiated, for example an income model that accommodates gig workers or a risk based deposit ladder, 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 your fraud losses have become a line item and generic detection has stopped keeping up.

How to choose a developer for a tenant screening platform

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 that question determines the architecture, not a feature list.

Ask them to model the decision. You should see 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.

Ask what they have actually integrated. Plaid, Argyle, and a criminal record aggregator are three different problems, and bureau certification has its own timeline a developer should describe from experience.

Ask who owns the code and the decision records, in writing, before kickoff. You should own the repository, the cloud accounts, and the audit log. At Digital Heroes the client owns the code from the first commit. Your decision history is the evidence in any fair housing or FCRA matter, and it must be retrievable long after any vendor relationship ends.