mls-data-access-vault-contract-profile

MLS + Mortgage Data Access Vault Contract Profile v0.1 draft. PropTech-specific profile of the AI Procurement Decision Card v0.2 + v0.3 vault contract — names the RESPA (12 CFR Part 1024), ECOA Reg B (12 CFR Part 1002), Fair Housing Act (42 USC §3601), HMDA (12 CFR Part 1003), GLBA (16 CFR Parts 313 + 314), MLS member policy (NAR Code of Ethics + 2024 settlement), and state real-estate-commission personally identifiable data categories as concrete data_vault_targets field exemplars, pairs each with default retention_envelope rules a residential-real-estate broker / mortgage lender / PropTech procurement reviewer can sign without re-deriving them per vendor, and threads through the consent_basis_declaration field so each authorization is explicitly tied to one of the seven PropTech consent doctrines (RESPA-required disclosure, ECOA written application, Fair Housing-required collection, MLS member-vendor access, consumer explicit opt-in, GLBA Financial Privacy Rule, judicial order or subpoena).

Part of the Kinetic Gain Protocol Suite.

Status: v0.1 draft. The profile at profile.json, the canonical example at examples/pacific-coast-mortgage-ai-underwriting.json.

Why this exists

A mortgage lender or residential broker reviewing an AI vendor today does the analysis across at least six overlapping regulatory frames:

1. RESPA / TRID review — does the vendor see Loan Estimate fields? Closing Disclosure fields? Settlement-services-provider lists? Are RESPA Section 8 kickback concerns mitigated?
2. ECOA Reg B review — does the vendor see credit-application content? Adverse-action reason codes? Government-monitoring fields? Co-applicant information?
3. Fair Housing Act + HMDA review — does the vendor's output produce disparate impact across protected classes? Are reasonable-accommodation requests honored? Is HMDA reporting captured cleanly?
4. GLBA review — does the vendor handle Non-Public Personal Information (NPPI)? Does the GLBA Privacy Notice + Safeguards Rule + state financial-data law cover the vendor relationship?
5. NAR + MLS review — does the vendor access MLS data? Is the 2024 NAR settlement's buyer-broker compensation disclosure honored?
6. State real-estate-commission review — California DBO, Oregon OLO, Washington DFI, Nevada Mortgage Lenders Division, etc. — each names specific vendor relationship + disclosure requirements.

Today these six reviews land in six different documents — a DPA, a fair-lending model risk document, an ECOA recordkeeping appendix, a GLBA privacy notice, a NAR settlement addendum, and one or more state-specific addenda — and the buyer's signature at the end of the procurement cycle is a single signature against a single DPA that nobody can replay against the six separate review trails.

This profile gives the six reviews one common shape. The buyer's Decision Card declares which consent basis authorizes each data_vault_targets[] entry. Each entry maps to one of the five core PropTech regulatory categories (RESPA + ECOA + Fair Housing + MLS + GLBA). The retention_envelope[] ties each field to a TTL + a redact-on-expiry mode + a signed deletion-proof endpoint. The vendor's runtime stays unchanged — it just reads the contract.

What the profile asserts

A Decision Card that conforms to this profile declares:

• A consent_basis_declaration[] block naming which of the seven PropTech consent doctrines authorizes each named data-use category.
• A data_vault_targets[] entry per RESPA / ECOA / Fair Housing / MLS / GLBA category the vendor's product collects, each tagged with its profile_category_code, its consent_basis, and the vendor's vendor_field_treatment (tokenized / hashed / cleartext).
• A retention_envelope[] rule per data_vault_targets entry with a TTL that meets or exceeds the federal floor + state record-retention requirements + a redact_on_expiry action drawn from the profile's per-category defaults.
• A deletion_proof_uri + deletion_signer_key_uri so deletion receipts append cleanly to the buyer's audit-stream.

The profile does not:

• Define a new schema. Decision Cards conforming to this profile are valid against the AI Procurement Decision Card spec at v0.3.
• Claim RESPA, ECOA, Fair Housing Act, HMDA, GLBA, NAR-settlement, or state-real-estate-commission compliance. Compliance is a posture established by the lender / broker's overall program. This profile is readiness scaffolding.
• Endorse a tokenization vendor or a model-risk-management vendor. The Decision Card's vault choice stays the buyer's.

The five PropTech regulatory category families

Family	Citation	Categories named	Default TTL range
RESPA	12 CFR Part 1024 (TRID)	Loan Estimate fields, Closing Disclosure fields, Settlement-Services-Provider list, Affiliated Business Arrangement disclosures, Escrow account records	P3Y–P5Y
ECOA Reg B	12 CFR Part 1002	Race + ethnicity government monitoring, Sex government monitoring, Credit application data, Adverse action notice records, Appraisal + valuation record, Co-applicant information	P25M–P7Y
Fair Housing Act	42 USC §3601 + 24 CFR Part 100	Protected-class self-identification (race, color, religion, sex (incl. SO + GI per Bostock), familial status, national origin, disability), Reasonable accommodation / modification request	P5Y–P7Y
MLS member access	NAR Code of Ethics + 2024 Settlement	MLS listing content, Buyer-agent compensation, Showing history	P1Y–P5Y
GLBA	16 CFR Parts 313 + 314	Non-public personal information (NPPI)	P5Y

The full per-category rationale lives in profile.json.

Seven consent doctrines

Code	Doctrine	When it applies
respa-required-disclosure	RESPA + TRID required disclosure (Loan Estimate, Closing Disclosure)	All purchase / refinance mortgage applications
ecoa-written-application	ECOA Reg B written application (12 CFR §1002.4)	All credit applications; data use limited to credit decision + ECOA recordkeeping
fair-housing-required-collection	Fair Housing Act + HMDA required collection of government-monitoring fields	All HMDA-reportable loans
mls-member-vendor-access	Vendor accesses MLS data as member-licensee per MLS policy + NAR Code of Ethics	MLS-integrated vendors only
consumer-explicit-opt-in-granted	Consumer-supplied explicit opt-in	CRM, marketing pipeline, post-closing engagement
glba-financial-privacy-rule-required	GLBA Privacy Rule (16 CFR Part 313) required disclosure + opt-out	All consumer-financial-relationship data uses
judicial-order-or-subpoena	Per 12 CFR §1002.12(b)(2) (ECOA) or RESPA §1024.12	Legal-process-driven disclosure

A mortgage lender deploying AI underwriting typically declares multiple consent bases — ecoa-written-application for credit-decision data + fair-housing-required-collection for HMDA monitoring + respa-required-disclosure for TRID generation + glba-financial-privacy-rule-required for operational fraud-detection.

Example

examples/pacific-coast-mortgage-ai-underwriting.json — Pacific Coast Mortgage Holdings' 2026 Q3 Decision Card approving VendorR LoanDecision v5.2 for residential mortgage underwriting in CA/OR/WA/NV. Shows:

• Quad consent_basis_declaration[] covering ECOA + HMDA + RESPA + GLBA data uses.
• Ten data_vault_targets[] entries spanning SSN + name + race/ethnicity monitoring + income + employment + appraisal + Loan Estimate fields + adverse-action reason codes + disability accommodation request.
• Six retention_envelope[] rules with TTLs spanning P25M (ECOA floor) → P7Y (HMDA + state floor) → P5Y (RESPA + state floor).
• An approved-with-conditions decision with four real-product conditions: DPA countersign before deployment, vault implementation verified by IT, no autonomous adverse-action issuance (human underwriter in the loop), quarterly fair-lending committee review.

Composes with

Repo	Role
ai-procurement-decision-spec	The base spec this profile extends (v0.3 vault contract + retention envelope)
phi-vault-contract-profile	Sibling HealthTech profile — HIPAA's 18 identifiers instead of RESPA + ECOA + Fair Housing + MLS + GLBA categories
pii-student-vault-contract-profile	Sibling EdTech profile — FERPA + COPPA categories
respa-readiness-evidence-bundle	Sibling PropTech profile — names RESPA's eight obligation families
mortgage-decision-record-audit-stream	Sibling PropTech repo — the audit-stream ledger that records each AI tool's mortgage-record access against this Decision Card
mortgage-applicant-bias-coverage-lab	Sibling PropTech profile — pairs ECOA Reg B + HMDA + Fair Housing protected classes with bias-coverage requirements
title-chain-evidence-incident-card-profile	When a vault-contract violation produces an incident, the Incident Card profile is the right artifact

Compliance posture

PropTech-readiness scaffolding for AI procurement vault-contract evidence in residential real estate + mortgage finance. The profile and its example support a lender's or broker's program toward RESPA readiness (12 CFR Part 1024), ECOA Reg B readiness (12 CFR Part 1002), Fair Housing Act readiness (24 CFR Part 100), HMDA reporting readiness (12 CFR Part 1003), GLBA readiness (16 CFR Parts 313 + 314), NAR 2024 settlement readiness, and 50+ state real-estate-commission + state-mortgage-lender-license + state-financial-data law alignment — does not by itself establish compliance with any of them. Per the standing public-language guardrail: readiness · evidence · posture · controls · scaffolding — never "RESPA-compliant" or "fair-lending-cleared" without an external attestation.

License

MIT — see LICENSE. Spec/profile repos in the Suite are MIT-licensed so adopters can implement freely; reference implementations are AGPL-3.0.