WAV Group’s tech workgroup met to recap the recent Real Estate Standards Organization (RESO) conference. By all accounts, the RESO API standards have made remarkable strides to make it easier for brokers and their vendors to access MLS records for their applications – but we have a long way to go on this critical mission, because the industry is still heavily fragmented. Some systems like Trestle and MLS Grid have made the effort of consuming MLS data more reasonable by consolidating across multiple markets, but for most brokers and vendors, they are still relying on the real estate transaction standard (RETS). This is not intended to be a technical post, but will explain what is happening today across more than 500 MLSs and offer ways that MLSs can help with fragmentation.
Background on MLS data distribution
In the early 90s, MLSs pioneered the process of making the MLS records available to brokers and their vendors. Initially, the transport method was file transfer protocol or FTP. Basically, each MLS dumped all of their data onto a server and brokers and vendors could go grab it. From there, it was sorted and normalized so products worked across different markets. It is hard, painstaking work. National tech firms would literally download all MLS data from more than 1,000 MLSs at the time – every day!
FTP was replaced by RETS in the late 90s when IDX was born. RETS is still in place in just about every MLS market today. With RETS, brokers and vendors do not need to pull all of the data every time (like FTP) but can pull only those parts of the MLS records that changed since the last time they were accessed.
RETS was a major leap forward, but the effort to painstakingly map data that uses different field names and field numerations is horrible. Most of all, RETS is a real estate industry specific method of organizing and moving data – completely foreign to the methods that anyone outside of the real estate industry would ever know or understand. Aside from the learning curve, RETS also usually requires full replication of the MLS data on the vendor servers.
Around the year 2015 or so, RESO published the first WebAPI standard. An API is an application programming interface. Every technology student is taught to work with APIs – and they work pretty much the same across all industries. It is based on Odata, a global technology protocol. Basically, it is a lot easier than RETS. Alongside the RESO WebAPI standard is the RESO Data Dictionary. The data dictionary determines what we call fields in the MLS records, along with how they are formatted – for example, a full bathroom = 1, not “one” or “full’ or whatever name the MLS picks. The data dictionary allows for automated mapping of the data between the MLS system and the broker or vendor solution.
The Problem of Fractionalization Continues to Plague Broker and Vendor Systems
One of the most important inflection points for the RESO WebAPI and Data Dictionary standards happened when the National Association of REALTORS® issued a mandate that all Realtor association owned MLSs have one year to update their systems to the new standards that are released each year. In theory, every market should be on the same standard by the end of the year in which the update is published. NAR has not enforced the standard by penalizing or revoking an association’s MLS charter for non-compliance.
Sadly, the industry does not move to the new standards all at once. It is piecemealed as various MLS vendors make the conversion to the new standard. MLS data aggregators like Trestle and MLS Grid tend to update all markets representing about ¾ of all MLS data in America, but the balance of markets change randomly, and often without much notice. When these systems change, it breaks the data mapping to the applications.
RESO has done a great job of offering certification to MLSs, and recently to vendors and brokers. The organization will look at your data and make sure that you are aligned with the current certifications. The problem here is that the 1,300 fields represent about 70% of the data in the MLS. As a result, any application that requires all fields, or most fields (like a VOW) are missing some key data from the WebAPI. In many markets, vital local data related to farms, waterfront, ski-in / ski-out accessibility, or hurricane shutters are not in the payload. RESO makes great strides to include more and more fields each year, but we are still a long way from the finish line (if a finish line even exists). Because of this, many large brokers and vendors still use RETS instead of the more efficient WebAPI.
What Brokers and Vendors Can Do To Solve the Fractionalization Problem
Be an advocate for positive change!
First and foremost, the best way to solve the fractionalization problem is to continue to support RESO. It’s a non-profit, so you benefit from the contributions.
Secondly, voice your opinion at your local MLS. Any MLS can participate in CoreLogic’s Trestle program or MLS Grid. Trestle provides a full data set including non-data dictionary fields. This is particularly important in Navica, Rapattoni, Black Knight, and to some degree, FBS. FBS was the first vendor to launch the SparkAPI, and they now offer the WebAPI as well. Consumers of data from FBS markets have a single access point in the Spark Datamart for all markets and FBS maximizes adoption of RESO Standards. Having your MLS join one of these multi-market programs like Trestle or MLS Grid also delivers a great backup to the local offering. It essentially provides a frontend-of-choice for technology providers.
Overall, the industry is moving in a positive direction to eliminate fractionalization of MLS data and we all owe a debt of gratitude to the volunteers and staff at RESO for making real estate applications much better and less expensive to brokers and agents.
