Three Data Sources That Live in Different Worlds
Real estate data engineering integrates three primary data sources. MLS listing data describes the inventory. IoT data describes physical reality at the asset level. Transaction data describes financial reality across leases, sales, and operations. The three sources have different shapes, different update patterns, and different governance constraints. Unifying them is most of the engineering work in real estate platforms.
A data platform lead at a property technology company described the unification challenge to me last year. "Each source feels solvable on its own. The hard part is making them all describe the same property in ways that match up. Different identifier systems. Different update cadences. Different definitions of basic concepts." The matching work is unglamorous and load-bearing.
AI Velocity Blueprint
Measure and multiply engineering velocity using AI-powered diagnostics and sprint-aligned teams.
The patterns that work in real estate data engineering have settled into a recognizable shape through 2024 and 2025 as the major property technology platforms have matured. The patterns are not specific to any single platform; they reflect the underlying structure of the data sources.
What MLS Data Actually Looks Like
MLS data describes the inventory of properties available for sale or lease. The data is rich in some ways and structurally inconsistent across regions.
The basic shape is property listings with attributes (address, price, square footage, bedrooms, photos, description, listing agent). The fields are standardized within an MLS but vary across MLSs. Different MLS systems define different optional fields, use different valuation methodologies, and update on different cadences.
The update pattern varies. Some MLSs offer near-real-time data through RESO Web API. Others provide daily extracts. The aggregation services (ListHub, Bridge, MLSGrid) provide normalized access across multiple MLSs at varying levels of consistency.
The data quality is variable. Listings can have inaccurate fields. Photos can be misleading. Descriptions can be written by agents with varying attention to detail. The descriptive narrative carries information that does not appear in structured fields and contains information that contradicts structured fields.
The governance includes MLS rules about data use that restrict what platforms can do with listings. Republication, syndication, and use for AI training all have specific contractual constraints. Property technology platforms have to navigate these carefully.
For platforms ingesting MLS data, the work is normalization across MLSs, quality monitoring against expected patterns, and respect for the governance constraints. The work is ongoing rather than one-time because the source MLSs evolve.
What IoT Data Actually Looks Like
IoT data describes physical reality at the asset level. Sensors measure temperature, occupancy, water usage, electricity consumption, equipment performance, and many other parameters. The volume is large; the consistency is sometimes poor.
The basic shape is time-series data tied to specific devices and locations. The volume scales with sensor density. A modest office building with HVAC sensors, occupancy sensors, and utility monitoring can produce millions of data points per day. A large multifamily portfolio with comprehensive sensor coverage produces orders of magnitude more.
The protocols are heterogeneous. Modbus, BACnet, MQTT, vendor-specific APIs, and various legacy protocols all coexist in real buildings. The integration work to bring this data into a unified platform is substantial.
The data quality varies by sensor and by deployment. Calibration drift produces values that look correct and are not. Connectivity issues produce gaps. Sensor failures produce stuck values that look like normal data. The monitoring infrastructure has to detect these patterns.
For platforms ingesting IoT data, the work is protocol integration, data quality monitoring, time-series storage at scale, and aggregation to clinically meaningful views. The work is operationally complex relative to MLS or transaction data because of the volume.
What Transaction Data Actually Looks Like
Transaction data describes financial reality. Lease payments, sales transactions, operating expenses, capital expenditures, revenue, and the accounting around all of it.
The basic shape is event-based financial records with structured fields tying transactions to properties, parties, and dates. The data exists in property management systems, accounting systems, banking systems, and various operational platforms. The platforms each have their own conventions.
The update pattern is event-driven. Transactions occur and get recorded. The recording sometimes happens immediately (payment processing) and sometimes happens later (month-end reconciliation, year-end adjustments). Platforms have to handle both real-time and delayed updates appropriately.
The data quality is generally good for the financial components but variable for the operational classification. Categorization of expenses, allocation of revenue to specific units, and reconciliation across systems all have variability. The variability matters for analytics workloads.
The governance includes accounting standards (GAAP for most US operators, IFRS for international), tax requirements that vary by jurisdiction, and contractual requirements with investors. Property technology platforms have to support multiple accounting bases simultaneously.
For platforms ingesting transaction data, the work is integration with diverse operational systems, accounting normalization, time-series financial reporting, and audit trail maintenance. The work is precise rather than voluminous because financial accuracy matters.
The Unification Challenge
The three sources describe overlapping aspects of the same properties. The unification is harder than it should be because of inconsistent property identifiers and inconsistent definitions of basic concepts.
Property identification is the foundational problem. MLS data uses MLS-specific identifiers. IoT data uses building-specific identifiers. Transaction data uses property-specific identifiers from the property management system. The same property has different identifiers in each source. The matching work is partly deterministic (when shared identifiers exist) and partly probabilistic (matching by address, owner, or other attributes).
Definitions of basic concepts vary. What counts as a "unit"? Where does one apartment end and another begin in a building that has been combined or subdivided? What is the gross leasable area, and which definition does each system use? The definitions matter for analytics that combine data across sources.
Update timing varies. MLS updates daily; transactions update in real time; IoT updates continuously. The unified view has to handle the different cadences without producing inconsistencies that confuse downstream consumers.
The teams that handle this well treat it as a deliberate engineering challenge rather than as an afterthought. Identifier resolution, canonical definitions, and timing reconciliation all need explicit design. The teams that treat unification as something that will sort itself out produce platforms that nobody fully trusts.
What Modern Real Estate Data Platforms Look Like
Real estate data platforms that have matured through 2024 and 2025 share recognizable patterns.
A canonical property model that establishes the unified identifier and the definitions of basic concepts. The model evolves as the platform learns; it is the single source of truth for what a property is in the platform's terms.
Source-specific ingestion pipelines that normalize each source against the canonical model. MLS pipeline. IoT pipeline. Transaction pipeline. Each handles the source-specific quality and timing issues.
A unified data layer that produces the cross-source views. Property analytics that combines listing, physical, and financial data. Portfolio analytics that aggregates across properties. Operational dashboards that surface what is happening across the portfolio.
Observability that monitors data quality, freshness, and unification accuracy at each layer. Issues get detected at ingestion where possible, at unification where ingestion did not catch them, at consumption as a final safety net.
The platforms operate at scale that smaller real estate operators can leverage through SaaS rather than build themselves. Most operators in 2026 buy property technology rather than build it for this reason.
Evaluation Differnitator Framework
Why great CTOs don’t just build they evaluate. Use this framework to spot bottlenecks and benchmark performance.
Call to Action
What Logiciel Does Here
Logiciel works with property technology companies and large real estate operators building real estate data platforms or modernizing existing ones. The work is typically structured around source assessment followed by canonical model design and unification engineering.
The Unifying Data Across Systems framework covers the broader unification patterns that real estate extends. The Data Pipelines Explained framework covers the pipeline architecture decisions that depend on workload type.
A 30-minute working session is enough to assess your current real estate data architecture against the three-source reference.
Frequently Asked Questions
How do I handle the MLS data restrictions?
Through careful review of each MLS's data use rules and through contracts with aggregators (ListHub, Bridge, MLSGrid) that handle some of the governance complexity. Some use cases (AI training on listing data, for example) require specific arrangements that many platforms have not navigated.
What level of IoT sensor coverage justifies investment?
Depends on the use case. Predictive maintenance for major HVAC equipment justifies meaningful investment in larger buildings. Comprehensive room-level monitoring rarely justifies its cost for typical multifamily or office buildings. Start with high-value use cases and expand based on demonstrated returns.
How does this differ for commercial versus residential real estate?
Commercial workflows involve more complex leases (multi-tenant, percentage rents, expense pass-throughs) that complicate transaction data. Commercial IoT often focuses on energy management and equipment monitoring. Residential workflows involve more transactions at smaller dollar values and different MLS structures. The patterns adapt; the source categories are similar.
What about new data categories like sustainability metrics?
Increasingly important and often a fourth source. ESG reporting requirements, carbon tracking, water usage analysis. The patterns are similar to the existing three sources. Most platforms are adding this as an additional source rather than restructuring around it.
How does AI workload integration affect the data platform design?
AI workloads often need broader and fresher data than traditional real estate analytics. The platform design has to support AI consumption patterns alongside traditional analytical consumption. The trend is toward platforms that serve both with consistent data infrastructure rather than separate data systems. Sources: - RESO Real Estate Standards Organization, 2024 - NAR Real Estate Technology Survey, 2024
