As an engineer focused exclusively on working with MLS data over the past three years, I’ve recently been encouraged by the lively debate over the future of MLSs.
Whether it’s the Parker Principles highlighting the need to “remove artificial and overly protective barriers to property data access and utilization via a universal licensing agreement,” thought leadership of the Council of Multiple Listing Services (CMLS), the drive of MLS 20/20 or the growing groundswell behind RESO, it’s clear that more MLSs are recognizing the need to innovate and evolve.
It’s also clear that many MLSs are still unaware or discount the benefits of these standardization efforts, risking the possibility of being left behind.
Given this complex landscape, I want to present another perspective — the perspective of the vendor engineer. We’re a relatively small group of highly-specialized professionals who focus on building the bridge between MLS data and the many stakeholders who wish to consume it.
In many ways, it’s our behind-the-scenes work that determines the quality and speed with which MLS data reaches the customer — and therefore influences the consumer’s perception of not only the software, but the brokerage, agent and the MLS itself.
Of course, technical considerations are not the most important factor in defining the future of MLSs by a long shot, but in following recent discussions, I realized that there are some assumptions and observations that don’t accurately reflect the reality that vendor engineers actually face when working on data integrations.
To clear up these misunderstandings, and hopefully, nudge future discussion in the right direction, here are the six misconceptions real estate tech engineers wish MLSs understood.
1. Technology is the biggest bottleneck in integrating with MLSs
Although there’s been a lot of debate around how to make the technical components of an MLS integration work smoother, the fact remains that the initial application step is the most time-consuming part of the whole process.
Speak to any experienced vendor and they’ll tell you the same. The irony is that, in an industry often criticized for outdated technology, the biggest impediment stems from an administrative issue.
While the technical process of the integration can be reduced to a handful of hours, it sometimes takes a few weeks, or even months, to get vendor certification from the MLS. This obviously delays the start of the technical integration, and on occasion, the customer’s timeline as well.
Of course, the careful vetting of third parties to access sensitive data is a critical process, but the speed, efficiency and accuracy of this process can benefit greatly from standardization and centralization.
In our experience, a majority of the approval criteria presented to us have been very similar among MLSs, which makes it ripe for reform.
Imagine the benefits of a system where vendors can obtain VOW or IDX certification from a single organization once, instead of independently coordinating with every single MLS. Such a “whitelist” of trusted vendors shared among MLSs would go a long way in reducing administrative costs for both MLSs and vendors.
MLS Grid is such an initiative already underway, drastically lowering the burden for vendors wishing to integrate with any of their member MLSs.
Improving the application process is the single fastest, cheapest and most impactful way MLSs can improve the third party integration experience.
2. RESO is a panacea vs. RESO won’t work for my market
RESO is probably the most ambitious and impactful MLS reform initiative, something I’m extremely excited about as a MLS engineer.
However, as with any ambitious project, there’s no shortage of controversy and resistance to change. One of the central issues is the inevitable balance between data standardization and regional diversity.
On the one hand, this dilemma presents a major challenge to RESO’s success, yet on the other, it shouldn’t prevent MLSs from joining the standard either.
From a vendor’s perspective, MLS data looking significantly different region-to-region is a simple fact of life. Working with our agent customers, it’s clear that these local market idiosyncrasies are a critical part of their business.
We’ve built a system that can handle these different feeds flexibly, honoring local quirks, but the prospect of RESO significantly simplifying this necessity is an extremely welcome one.
However, for RESO to be a viable solution for MLSs and vendors in the long term, they must be able to reconcile the benefits of standardization and the reality of regional diversity. The likely solution is a continued expansion of the RESO standard as seen in the efforts of RESO’s Data Dictionary Workgroup, who has expanded support to over 1,200 fields and 20,000-plus lookup values.
Of course, a blindly expansionist policy can lead to a bloated standard, which would defeat its very purpose. Hitting the right balance will be quite the challenge.
Given these issues, should MLS executives shy away from the standard?
To the contrary, I believe the imperative is that MLSs lean in further toward the RESO initiative.
First, as RESO continues to get adopted by more and more MLSs, as with any standard, vendors will always prioritize the integrations with the biggest bang for buck. Non-adoption will therefore naturally deter the influx of helpful technologies in that market.
Second, early and spirited involvement by MLSs in RESO’s development will ensure that regional requirements are included, and perhaps adopted by other MLSs as well.
The absence of a well-balanced standard, and/or the non-participation of MLSs can lead to the nightmare scenario for a tech company: the partial adoption of RESO.
It’s not difficult to imagine a world where the non-adoption of an effective standard leads to the simultaneous coexistence of RESO data and localized data for a given market.
We’ve already seen this in action in the handful of areas where customers rightfully demand the nuanced regional fields on top of the standardized fields, necessitating the implementation of a parallelized system.
This is a true lose-lose scenario where attempted standardization leads to increased costs and complexity for the vendor, erodes the data-centralization value MLSs bring and will fail to serve end-users by displaying inelegantly implemented data feeds.
A standard must be exactly that: an all-or-nothing institution. Coming short of that would put everyone in the ecosystem at risk.
This means that the effort to create a standard that works across the country, and the close involvement of as many MLSs as possible, are both critical to the creation of a high-value real estate tech environment.
In fact, I’d argue that there is no individual success for RESO, MLSs or vendors, only a shared destiny for all.
3. Moving away from XML to web APIs will be a huge positive overnight
Recently, there’s been a movement, with MLS 20/20 at its forefront, toward updating MLS systems to support web API frameworks instead of the legacy, XML-based system known as RETS. The narrative is that by embracing modern web standards, developers will have a much easier time working with MLS data, benefitting the industry as a whole.
While this thesis is theoretically sound, unpacking the practical implications paints a picture that’s less promising.
It’s important to point out that the current XML based framework, while not up to cutting-edge standards, is a functioning, familiar framework that engineers are comfortable working with.
This is in large part thanks to software libraries such as “gorets” that abstract the complicated nitty gritty of RETS for developers. In fact, even when RETS is replaced by RESO web API, such libraries will be updated to cover up the gorey (pun intended) details of the oData standard used by Web API.
Developers pride themselves on building and using abstractions, and this is a prime example. This means that both from a technical and business standpoint, it’s difficult to argue that this status quo is broken.
Perhaps more importantly, the debate over endpoint frameworks masks a more fundamental issue regarding the databases themselves. Regardless of how third parties connect to MLS databases, if the databases themselves are not up to standard, service quality and ease of integration can’t meaningfully be improved.
A persistent example of this issue has been timezones. Despite guidance from RESO, many MLSs have sub-par query datetime parsing, and assume all queries are made in a certain timezone.
Almost no MLSs return timezone data on listings, leaving developers to guess “which” 5 p.m. the open house occurs at — a messy and frustrating exercise to say the least. Exacerbating this problem, some MLS databases seem to explode if queried on a date field with a date that’s too far in the past, presumably because of improper sorting or indexing.
Whether a server response is in JSON or XML, these issues around response time, data structure ambiguity and querying challenges will continue to frustrate engineers. In my opinion, these problems should take priority over any transition from XML to JSON.
4. MLSs should strive to enable real-time querying of listing data
One of the other themes emerging recently is the idea that MLSs will offer a real-time architecture to their third party partners, eliminating the need for vendors to “mirror” or “replicate” MLS data in their own system.
This is certainly the holy grail of data distribution, increasing the control, speed and ease with which data can be accessed. It’s something that, again, in theory, vendors would love. However, the bar to make this a practical reality is quite high, perhaps prohibitively so.
To illustrate the point, let me compare the load on MLS servers in a mirrored architecture versus a real-time architecture.
Today, listing alerts and search vendors like RealScout generate thousands of listing queries per hour from email alerts, property searches and other listing-driven features. These queries, in a mirrored architecture, affect only the vendor’s servers, while the MLSs’ servers only get hit once, incrementally, to update the mirror.
In a real-time architecture, those thousands of queries per hour will, now multiplied over many vendors, hit the MLS servers directly. This can easily represent an increase in load by many orders of magnitude and will require a fundamental rethinking of MLS systems infrastructure.
Add to this the consumer expectation of fast listing search, the bar and cost is even higher.
Furthermore, since many vendors offering a relatively modern user experience provide additional filtering and logic not provided by the MLS — think school boundaries, crime data, commute time windows and upcoming open houses to name a few — those vendors may still choose to mirror the data to maintain their experience anyway.
While building a real-time JSON API architecture makes it easier for someone with no real estate/real estate tech experience to slap together some widgets at a hackathon, it doesn’t automatically meet the requirements for companies building the sleek experiences today’s and tomorrow’s users demand.
Thankfully, the RESO committee knows the importance of replication, and the API will continue to support this critical functionality.
Of course, an ideal real-time architecture isn’t impossible to build and support, but ROI on such an investment, especially considered at the scale of a typical MLS, is unlikely to make sense. With most MLS tech teams starving for resources as-is, and current RETS responses being in a non-ideal state to begin with, there’s a steep hill to climb.
In many ways, today, it’s the vendors who are shouldering the cost of a scalable, responsive architecture. Just as data is the core competency of the MLS, scalability is the core competency of the tech world. I’d suggest that this, once again, is an arrangement not broken enough (or at all) to warrant a massive overhaul.
5. There’s little room for improvement in current MLS database policies
There are opportunities for drastic improvements in even the most basic of MLS tech policies. Specifically, a significant number MLSs still have server access and connection limits on their data that is reminiscent of early web infrastructures of the 1990s.
Listing data is ever-changing, perishable information that requires third parties to refresh and reconcile relatively frequently.
In executing these best-practices, we’ve encountered MLSs that limit vendors to one query at a time, from one login, from one IP address or some combination of the three.
These data access policies came from an era when developers were physically building their own servers and cloud infrastructure was non-existent or incredibly expensive.
Today, these policies discourage the ecosystem from developing innovative, cloud-based applications that require more modern policies.
The investment/policy changes that would improve this situation are minimal, almost negligible, compared to a real-time architecture, but will increase the timeliness and accuracy of listing data greatly, driving higher quality for agents and consumers.
6. Regional compliance frameworks are working as intended
Having strong safeguards around data usage, distribution and branding is a key aspect of a healthy real estate market, and it’s something we embrace at RealScout.
On the other hand, like the issue around the application process, I believe compliance is an area ripe for standardization.
There are dozens of variations in required watermarks, disclaimers, reporting format and frequency. Each requires costly attention and custom code, both of which prevent vendors from spending more time ensuring better data quality and user experience.
These quirks result in time-consuming and distracting implement-audit-tweak cycles that drive vendors mad. A thorny compliance process can prevent vendors from moving into a market in the first place.
I think there’s a no-compromise opportunity to standardize the compliance requirements across MLSs. This is especially attractive since a standardized compliance scheme would not only reduce costs all around, it would actually increase compliance across the board.
In fact, many manual reporting processes could be automated and brought online, theoretically increasing the MLSs ability to gain transparency into how their data is being used. Again, MLS Grid is a leader in this regard.
Final thoughts
These six misconceptions remind us that not everything that is “cutting-edge” is automatically good for the ecosystem.
Instead, both technical and business practicalities must be taken into careful consideration to determine which initiatives have the highest ROI.
In fact, the worst thing that can happen is that the pursuit of buzz-wordy innovation distracts from higher impact initiatives that can be accomplished much sooner and more cheaply.
The good news is that there are many of these low-hanging fruits for MLSs to harvest to drastically improve third party integration and ecosystem health. Many, if not most of these reforms should also benefit MLS operations and bottom lines, making them true win-wins.
Although the need to reconcile national standardization and local business realities remains a critical yet difficult challenge, I’m optimistic that the industry can work out an acceptable solution.
The conviction that MLSs must innovate is an incredible blessing for the real estate ecosystem as a whole, and especially for developers like me.
Hopefully, the recommendations above will be taken as a welcome voice in the discussion about the future of MLSs. As vendor engineers, we work closest with MLS technology, and in many ways, the long-term success of the MLS is directly tied to our success and the success of our customers.
I am committed to being closely involved in the process of MLS innovation, and it’s critical that you make sure your market’s voice is heard as well. Let us, as partners, seize the moment, and build an open, safe and productive real estate technology ecosystem.
Anthony Sosso is the Senior Software Engineer for RealScout in LA. Connect with him on LinkedIn.
