Lately, there has been a lot of discussion about MLSs enabling subscribers to update the MLS system from a different system. All I can say is, “Finally!” Clareity Consulting suggested this could well be the future of MLS back in 2005, just after the RETS “Update” standard enabling such updates was released, and we used the following diagram both in an article and in industry presentations. Note that we also suggested that some brokers would directly syndicate, while others would still syndicate through the MLS (Syndication as a Service) – and that’s been happening increasingly as well today.
But, there are challenges ahead for brokers who want to enter the listings into their own systems first, manage them there, and then update MLSs. This discussion will get a bit technical in parts, but it’s important to understand the details.
First, even if a local MLS organization wanted to turn on the capability to use their own systems for initial entry and management, not every MLS vendor supports the RETS Update method. RETS Update has always been an optional part of the RETS standard to implement, and there has not been demand in most markets to do so. It will take time – maybe significant time – for MLS vendors to implement it. It’s not as simple as it might seem because there are implications for the architecture of the MLS system well beyond the RETS server. I’ll come back to that later.
Right now, if the broker system submits listings into the MLS system, one by one or in a batch, listings that don’t comply with all data validation and business rules (“DV/BRs” from now on) will be rejected – and sometimes the error messages that come back from MLS systems aren’t very easy to interpret. The difficulty for brokers will be to build and maintain systems that can duplicate the MLS’s DV/BRs in their own listing input module. Note that the MLSs’ DV/BRs are rarely completely written down. Sometimes even MLS staff can’t easily articulate all of the rules that have been written into the software over the years. Also, the RETS standard is not yet capable of communicating all of the business rules; it can communicate most, but not all.
Once RETS’s capability to communicate all of the business rules is complete, MLS systems that currently have their DV/BRs built into the code of their listing management module are going to have to re-architect so that the rules are accessible to the RETS server. These rules include:
- “Edit Mask” (i.e., the data type and number of characters per field),
- “Update Help” (descriptive text for what belongs in the field),
- “Validation Expression” (required for an additional level of input validation), and possibly also
- “Presentation” (describing groups of fields, columns for layout, and more).
If all these rules are exposed through RETS, broker systems can read them in and potentially generate the listing input screen automatically.
Some have argued that all of this technical stuff isn’t necessary. In their view, a brokerage can just send in an update transaction, get back errors, and modify its code. However, this is a long and painful approach – not just for the creation of the system, but when dealing with change over time. Especially if a brokerage is waiting till the last moment to submit listings, they can’t afford to have listings kicked back as invalid by the MLS when there’s no one around to figure out what went wrong and fix it in conjunction with the listing agent. Especially at first, the trial-and-error approach will be very frustrating for agents as well. Also, if you think building and maintaining the system manually to accommodate the DV/BRs of a single MLS will be difficult, imagine if you are a broker belonging to many MLSs, and you want to submit a particular listing to several or all of them. Each MLS may have different fields, values for those fields, and business rules. This situation cries out for automation.
Someone might ask, “What if the industry cuts through this Gordian Knot by requiring every MLS have the same DV/BRs, or by consolidating MLSs into only a few, or even one?” Regardless of MLS structure or the desire to simplify, the truth remains that real estate is local. The lake frontage and boat launch fields that may be a required field in one market make no sense in the desert. The complexity of actual real estate and the data needed for agents to do their job can’t just be thrown aside to simplify a technical problem.
There are additional complexities that can’t be ignored. For example, what if the listing must be tied to a public record or other licensed data? Are brokers ready to license that data too, so it can be integrated with their own listing input screens? Again, building and turning on the RETS Update method is just the starting point. There are additional needed changes that are going to take some time:
- Enhancing the RETS standard to be able to articulate all types of business rules
- Changing the architecture of some MLS systems so business rules are not buried in the listing maintenance module
- Building out broker systems sophisticated enough to deal with data definitions and business rules for multiple MLSs
Hopefully this explanation of the challenges to the evolving model of MLS listing maintenance will inspire people to work toward solving the challenges ahead.
Share this post: