A Brief History of Real Estate Standards
The FTP Protocol
Back in the 1990s, before the Real Estate Transaction Standard (RETS), the exchange of real estate data was done using the FTP protocol.
The Cons of the FTP protocol
FTP did not allow for queries, such as “new real estate listings since last week”. FTP required transferring entire datasets and compared each download with the previous transfer.
RETS
One of the underlying issues with real estate data is that there is no nationwide MLS. There are over 600 individual MLSs each responsible for defining data their own way. RETS created in 1999 was a new standard born out of the idea to unify data between all of these MLSs. RETS was a vast improvement on simple FTP transfer and created a new technology framework.
The National Association of Realtors (NAR) referred to RETS as a common language within the real estate industry. NAR strongly encouraged all MLSs to adopt RETS as their data standard. Most MLS data exchange service providers in the US and Canada started using the RETS protocol over the course of the 2000s. For over a decade RETS was considered the gold standard.
RETS protocol has served the real estate industry for 20 years, however it still has a number of pain points. One pain point is field names, such as Days On Market or HOA Name, that are still quite different between markets.
The age and pain points lead to an inevitable call for a new standard to emerge.
RESO Web API
Similar to RETS, RESO is also a technology framework created in 2018. RESO’s main mission is to provide software to certify compliance with those standards for the real estate technology industry. The RESO standard’s goal is to facilitate software innovation, ensure application and data portability, eliminate redundancies, and obtain maximum efficiencies for all parties in the real estate industry.
The Reason for RESO
During the FTP to RETS era, many of the real estate companies and MLSs switched from paper-based MLS books to custom online software systems to serve their local markets. Due to inefficiencies of FTP and RETS many industry and MLS software applications could easily integrate and transfer data. This failure resulted in duplication of property listing databases across the web.
NAR saw the need for a web-based API to solve these common issues.
The goal of the RESO standard is to ensure that every software application can talk to each other by following a common standard. RESO defines real estate data in a structured way, specifying what fields should be used in what scenarios and values those fields can have.
The Benefits of RESO
The RESO standard allows developers to build software systems that are flexible, scalable and integrate with each other. RESO also believes that the new Web API makes integration easier with a streamlined process.
RESO Adoption
Even though the RESO standard only arrived in 2018, even before its arrival NAR started putting pressure on close to 100 MLS Providers to comply with the RESO standard within 60 days. The pressure from NAR significantly sped up the implementation of the RESO standard.
RESO Adoption at the time of writing this article (12/01/2022):
- 30 MLSs have adopted the RESO standard 85-100%
- 28 MLSs have adopted the RESO standard 50-80%
- 36 MLSs have adopted the RESO standard 1-49%
- an additional 23 MLSs are committed to the RESO adoption
All MLSs share one goal in common: they are all committed to fully comply with the new RESO Web API standard by 12/31/2023.
What’s even more compelling is that 90% of MLSs in the industry have RESO certified Web API services. However, many of the MLS’ customers still need to be converted from RETS to the RESO Web API.
Additionally, the RESO organization shared some details that confirm the acceleration of the RESO Web API adoption: “Over the past year, MLS participant brokers and their subscriber agents have increased their usage of Web API data feeds from less than 5% of the industry to nearly 25%. This transition will continue to pick up speed as the MLS industry dialogue has clearly shifted from ‘if’ an MLS will fully convert to ‘when’. MLSs are setting deadlines and communications plans to move their customers forward with Web API.”
What issues remain after the RESO Web API adoption?
Even after complete RESO standard adoption, some critical issues remain. One issue is that even though the standard sets certain criteria in stone, RESO still allows different MLSs to implement the fields differently.
A striking example of differing fields is the Sewer field. RESO sets the datatype and includes standard possible values for the field. However, an MLS may have their own custom values that do not match the RESO default values. This disparity can lead to further complications.
Another example is the “Days on Market” field. While this is a single field, there are three possible start dates from when the MLS can start counting a property being on the market. MLSs do in fact choose to implement this field based on any of the 3 different start dates.
Solving for RESO Pain Points
RESO has brought real estate a long way from the FTP days. However, there are still clear issues for SFR investors who operate across many MLS markets. Bold Street MLS Listings solves for all protocols (FTP, RETS, RESO) and data differences to provide a single unified and standardized data set and API.
For the “Days on Market“ example, Bold Street passes the DaysOnMarket data from the different MLSs as they present data. Bold Street though solves for unified data by supplying an additional custom field Bold_DaysOnMarket based on a single date field.
Bold Street partners and customers can work with one standard MLS data and integration standard.