← Industries/PropTech & Real Estate
Promethean for PropTech & Real Estate
EU AI Act Annex III §5(b) classifies AI for creditworthiness + credit-score evaluation as high-risk — squarely capturing mortgage-AI and tenant-screening tools that incorporate credit-based scoring. US Fair Housing Act adds disparate-impact scrutiny under HUD's Discriminatory Effects Standard. Promethean's per-decision evidence layer is what makes 'every rental denial can be reproduced, every model version is traceable across protected classes' verifiable rather than asserted.
Who this is for
Compliance + product teams in proptech SMBs (tenant-screening · mortgage-AI · property-valuation · rental-decision platforms). Typically:
- Seed–Series B proptech with 5–50 engineers; 1–3 AI features in production.
- Customer base: landlords + property managers + mortgage brokers + iBuyers + lending platforms.
- Decision volume: 5k–100k tenant-screen / valuation / rental decisions per month per customer cluster.
- Multi-tenant by landlord/property-manager; multi-jurisdiction (state-level fair-housing variation in US, member-state in EU).
- Already facing class-action exposure (US tenant-screening class actions in 2023-2025).
The regulatory pressure
EU AI Act Annex III §5(b) — creditworthiness + credit-score
AI for evaluating creditworthiness of natural persons or establishing their credit score is high-risk (fraud-detection AI is carved out). Captures mortgage-AI directly; captures tenant-screening AI to the extent it incorporates credit-based scoring. Full Chapter II applies including Art. 12 record-keeping.
Deep-dive →US Fair Housing Act + HUD Discriminatory Effects Standard (24 CFR §100.500)
Tenant-screening + housing-finance AI cannot produce disparate impact on protected classes (race, colour, religion, sex, familial status, national origin, disability). HUD's 2024 guidance specifically called out AI/algorithm-based tenant screening; the disparate-impact rule (codified 2023) governs the legal standard. Per-decision evidence underpins fair-housing audits.
GDPR Art. 22 — automated decisions on housing access
Rental denial is clearly a 'legal effect or similarly significant'. Solely-automated denials prohibited unless an exception applies; meaningful human intervention required.
Deep-dive →Equal Credit Opportunity Act (ECOA) — adverse-action notices
US lenders must provide specific adverse-action reasons when denying credit. AI-driven denials need traceable, articulable reasons per decision.
Where LLMs typically run in PropTech & Real Estate
Tenant-screening risk classification
Classifier producing approve / conditional / decline per applicant. Closed-enum output; always-human reviewer gate on decline decisions (fair-housing audit-trail).
Mortgage-application AI assistance
Classifier + extractor combination handling first-pass mortgage applications. Reviewer-gate on schema-violations + low-confidence; deterministic fallback on adverse decisions to manual underwriting.
Property-valuation (AVM)
Classifier producing valuation estimate + confidence-band. Reviewer-gate on out-of-range estimates; chain shows model-version-per-valuation for retrospective audit.
Lease-clause extraction
Extractor pulling key clauses from leases. Schema-bound output; reviewer-gate on jurisdiction-specific edge cases.
How the substrate maps to your audit
| Your LLM feature | What the regulator asks | Promethean evidence |
|---|---|---|
| Tenant-screen decision | Fair-housing disparate-impact analysis + per-decision rationale. | L12 entry with reviewerVerdict + specHash; statistical bias audits run against chain. |
| Adverse-action notice | ECOA requires articulable reasons per decision. | outputCanonicalHash binds the rationale; spec defines the closed-enum reason categories. |
| Mortgage-AI handoff to underwriter | Meaningful human review on adverse mortgage decisions. | Always-human reviewer gate + verdict per decision; override rate visible. |
| Property valuation | Which model version produced this AVM? Can we reproduce it? | specHash + modelIdentity per L12 entry; valuation reproducible from inputs + model version. |
| Annual fair-housing review | All decisions in scope across protected-class demographics. | Time-bounded chain export; pair with demographic table for disparate-impact statistics. |
Which Promethean tier fits
Recommended for typical SMBs in PropTech & Real Estate
Production€499 / month flat
Up to 25 specs · 1M entries / month · hourly OTS anchoring · multi-tenant · federation read-only.
Production tier (€499/mo) suits typical proptech SMB volumes: 25 specs, 1M decisions/month, hourly OTS anchoring, multi-tenant (one platform serving many landlords). Scale (€1,199/mo) is the upgrade for SMBs hitting >25 specs (specialised models per state / property type) or preparing for HSM custody (roadmap) for the LLM signing keys when selling into major property-management chains.
Larger PropTech & Real Estate operators with multi-tenant or framework-template needs upgrade to Scale (€1,199 / month flat).
What this looks like in practice
Hypothetical: a tenant-screening SMB during a class-action discovery phase
A tenant-screening SMB is named in a fair-housing class action alleging disparate impact across racial demographics. The plaintiff's e-discovery demands: every decision in a 24-month period, the model version per decision, the rationale per denial. Without Promethean: months of log-archeology + a damaging narrative that the SMB can't fully reconstruct the audit trail. With Promethean: a chain-export filtered to the period; specHash sequence shows the screening-model version per decision; reviewer-verdict shows always-human engagement on denials. The defense lawyer pairs this with a contemporaneous demographic table, runs disparate-impact analysis under HUD's 2023 Discriminatory Effects Standard against verifiable data, and reaches favorable settlement at a fraction of the originally-projected exposure.
Frequently asked
We process tenant applications in 30+ US states. How does Promethean handle state-by-state fair-housing variation?
The substrate stores the per-decision metadata in a uniform structure (L12 entries with specHash, modelIdentity, reviewerVerdict, recordedAtIso). State-level audits filter the chain by tenantId (state-jurisdiction) or by recordedAtIso (when the relevant state law applied). The fair-housing analysis itself is operator-side — Promethean provides the verifiable substrate for the analysis, not the analysis itself.
Tenant-screening data has demographic fields that are sensitive. Are they ever in the chain?
No. The L12 chain stores SHA-256 hashes only (inputHash, outputCanonicalHash). Demographic data is on the operator's side; the chain proves what was decided, but not what was in the application. For fair-housing analysis, the operator pairs the chain export with their separately-held demographic table — both produced by the same data pipeline but stored separately to comply with proportionality requirements.
Mortgage-AI adverse-action notices: how does Promethean help?
ECOA requires adverse-action notices to specify the principal reasons for denial. AI-driven denials make this hard because LLM outputs aren't always categorical. The substrate's closed-enum outputSchema forces the LLM into a finite set of decision categories (or fires fallback). The reason code in each L12 entry is verifiable + categorisable. When the borrower contests, you produce the per-decision evidence backing the notice — and the regulator can verify it independently.
Property valuation can be life-affecting (e.g. eminent-domain). What about high-stakes outputs?
High-stakes valuations should run with the always-human reviewer-gate; the L12 entry records the reviewer's verdict explicitly. When the valuation is contested later (in court, in eminent-domain proceedings), the chain provides the per-decision evidence: which AVM model was used, what comparables, what the reviewer's adjustment was. That stands up to expert-witness challenge better than a screen recording or a Datadog log.
We sell into both US + EU markets. Different rules apply. How do we manage that?
Two specs (or more): one for US-jurisdiction decisioning, one for EU-jurisdiction decisioning. Each spec's hash is unique; the L12 entry's specHash makes the jurisdiction-of-decision verifiable. The Promethean handoff packets (Enterprise tier) generate jurisdiction-specific evidence (EU AI Act §5(b) for EU; ECOA / Fair Housing for US). One workspace; multi-jurisdiction audit.
Definitions used on this page
The substrate primitives referenced above (L12 receipt chain, spec hash, reviewer gate, fallback behaviour, OpenTimestamps anchor, tenant ID) all have canonical definitions in the glossary: