RESO 2019 Fall Conference Wrap - St. Louis

By Matt Cohen, CoreLogic, and RESO Staff

Welcome and State of the Standard

Art Carter, RESO Chair and CEO of CRMLS, welcomed us to St. Louis and the conference. Sam DeBord, CEO of RESO, thanked the Board of Directors and workgroup chairs, as well as the RESO staff and the sponsors.

Sam opened with the theme, "Consumers Choose the Winners," stating that they expect systems to work together and connect. We haven't had that in the industry, and that is a primary focus of RESO going forward – providing interoperability.

The focus needs to be on "business impact" and "results" – time, speed, efficiency, goals and profits.

What are the workgroups doing? In a nutshell:

• Data Dictionary: common language for tools
• Internet Tracking: tech ROI insights
• Payloads: certainty for scalable tools
• Universal Property Identifier (UPI): accuracy across platforms
• Research & Development: unique agent IDs, prioritizing solutions
• Transport: modern data sharing
• Distributed Ledger: insights over time
• Cross-Platform Interoperability: the ultimate goal
• Broker Advisory: "consumer" (business) feedback

There were two tracks at this conference: Business Track and Technical Track. The hashtag was #RESO19.

The 2020 RESO Spring Conference will be in New Orleans, April 20–23. The 2020 RESO Fall Conference will be October 26–29 in St. Petersburg, Florida.

Data Standards Drive Voice Innovation

Ami Berger, Cofounder and CTO at Voiceter Pro, talked about how data standards are reducing barriers. In 2018, they created an association product using proprietary APIs which was not ideal. Now they are providing an agent-facing MLS interface – making it possible to access expiring listings, broker opens, market stats, client messages and hotsheets. Using the RESO Data Dictionary with the RESO Web API has made it possible to quickly and easily develop a scalable backend and deliver a consistent experience to clients and end users. It shaves hours off development time for each client and makes it easier to bring new engineers up to speed quickly.

From Seeds to Success: A Stellar Harvest

Moderator: Melissa King; Panelists: Warren Bowley, Development Team Lead at Michael Saunders & Company; Amy Gorce, Principal, Business Development at CoreLogic; Kristin Youngk, Senior Program Manager at Zillow Group and Andrew Sheh, Chief Technology Officer at Remine

On April 25, 2018, Stellar MLS, previously known as My Florida Regional MLS, took the plunge into converting their MLS system to meet the Data Dictionary standard. Stellar MLS's business partners shared their experiences navigating through the conversion to the successes they have celebrated while working with a natively Data Dictionary-compliant MLS.

Amy from CoreLogic said the process isn't for the faint of heart. The most important thing to do up front is to get buy-in about what it means to go forth with this undertaking. For one thing, it's a yearlong commitment. It's important to understand the impact this will have on end-users. CoreLogic has gone through a half dozen or more of these conversions. It takes MLS staff time, and there is an impact on vendors and brokers further downstream. Kristin from Zillow said it took excellent project management and communication to move all the vendors along. Warren from Warren Saunders & Company is a data consumer as a broker. He got a translation document from Stellar MLS and planned ahead to change his processes that used the data. But now he's happy with the consistency and knowing that he can use any vendor using the Data Dictionary.

Andrew from Remine got credentials on a Thursday and by the following Tuesday was able to have all the data mapped. This let them launch the product within 30 days.

Kristin talked about how getting the Data Dictionary feed made it easier and increased the confidence in what they were receiving. In terms of listing input, it was possible to push data back into the system and increased confidence in reverse mappings and decreased errors. This can be a hurdle in other markets. From a user perspective, it reduced time to enter listings.

Melissa said losing translation is a real risk. It was a full-time job for an MLS staffer for a few months to stay on top of the process.

Amy said the other benefit from going to native Data Dictionary is that the mapping is done once, and it supports growth through the easier integration of other products. CoreLogic provides the map back to the client and they can provide it to whichever other vendors they want.

Melissa wanted to talk about options other than a full conversion. Amy says that Trestle is a Platinum-certified solution, which makes data consumption very efficient. Web API is still getting its wings, but ultimately provides efficiency as well. Moving from RETS to RETS + Data Dictionary to Web API + Data Dictionary is the path.

A question from the audience was how does this work for commercial? Amy replied that less work has gone into commercial but, ideally, we could get more of the commercial community and multifamily-oriented vendors involved at RESO.

Juli Pleitner from IRES MLS asked about the timeframe for the full conversion. Melissa said it should take about a year. Amy said it's gotten faster, but it depends how much change is needed. There are different approaches that can be taken.

Embracing RESO Standards Stateside and Internationally

Moderator: Jeremy Crawford, CEO at FMLS; Panelists: Jason Graham, Associate Director Product Development at The Canadian Real Estate Association, Chris Wade, Manager of Data Services and Compliance at FMLS, Rick Herrera, Director of Data Services at Realtor.com

With more than 850 member-organizations, the resulting work product of RESO in creating standards to address industry challenges are at the highest quality. Still, moving organizations from creation to adoption and utilization of RESO standards and getting them to fully embrace them for the benefits they provide continues to be an uphill battle, both in the U.S. and internationally.

Panelists have moved the envelope internally to embrace the RESO Data Dictionary (bidirectionally), Organizational Unique ID (OUID) and Universal Property Identifier (UPI) in the U.S. and Canada, directly benefiting their brokers, agents and technology partners.

Jason talked about how Realtor.com developed its own tools but how the IDs that RESO is developing are useful. Realtor.com can attach multiple listings to a property when they are submitted.

Chris has implemented UPI in the FMLS system. To use UPI, the listing needs to be auto-populated from public records with an APN. He's looking to see if one can be associated after the fact. They attach their OUID to their listings.

Jason said CREA is still on Data Dictionary 1.0 while they wait for more stabilization, and they'll be moving to newer standards soon. On the incoming side (getting data from boards), they debated whether to keep using their own national data standard or not. It's - but it's painful for MLS vendors, so decided to move to Web API and are waiting for local boards to provide that to CREA.

Chris said FMLS is Platinum-certified. Their effort started in 2016, by looking at the Data Dictionary. In early 2017, they started mapping data, and it took meetings every week for a year and a half. In 2017, there were three publishes of 50 changes each. They did not hear a peep from their membership. In 2018, there were two big publishes. They sent notices out to vendors and asked for feedback, and they found a few places where there were issues to deal with. The biggest issue for members was changing statuses - they got rid of Active/Contingent. In general, members are happy about the changes, and a lot of members didn't even know it happened.

Now the members see on the data input sheets what they see on sites like Realtor.com. Out of 200 data consumers, just a few weren't ready by the deadline. He pointed out that the local MLS understands the data best; it's best to do the mapping once locally by going Data Dictionary native versus having data recipients do it.

CREA talked about using the Data Dictionary French translation which works well, except for maybe the freeform text.

Rick talked about how nice it is to receive Platinum-certified feeds and how quick the mapping process is.

Universal Property Identifier Registry Demo

Presented by: Mark Bessett, Software Engineering Leader and Architect at CRMLS & RESO UPI Workgroup Chair

UPI provides unilateral, standards-based reference scheme for properties. It normalizes independent parcel-based information: deeds, taxes, permits, insurance claims, etc. It allows simpler deduplication and simplifies integration of various data sources when there's a shared property ID.

The UPI Registry proof-of-concept was presented as a live demonstration.

Imagine an API-driven marketplace of property-centric data supplied by leading firms in the industry. Using this registry, you can determine the validity of a given UPI via consensus and find links to this data on provider systems. With this registry, providers can "advertise" their products in an integrated, expandable way where their customers have high-confidence information for any property across the country, even internationally.

Ethical Considerations Concerning Predictive Analytics, AI, Machine Learning and Consumer Data

Moderator: Marilyn Wilson, Founding Partner at WAV Group and President at RETechnology.com; Panelists: David Gumpper, Head of Technology Consulting at WAV Group & Founder/CEO at Gumpper Group, LLC and Ryan Gumpper, Data Scientist at Gummper Group

With all the hyperbole, news and information swirling about the future of Artificial Intelligence, an aspect of the issue that has not generated as much coverage or conversation outside of academia is the ethical concerns related to these new technologies. What are the primary ethical issues attendant to these new technologies? What role(s) do the broker, MLS organizations, vendors, REALTORS®, and RESO have in elevating the ethical discussion and/or implementing ethical practices?

The Gummpers don't see AI replacing agents, who manage relationships. Nor will it replace brokers, who hold the liability. It may make some operations more efficient.

What could go wrong? Information input to an AI could continue bias. Garbage in, garbage out. Is it ethical to put someone's name, gender or age into an AI model? "How do we interrogate the algorithm," asked David, to make sure there's no redlining or gentrification. A study showed that human bias is worse but that AI bias is present. Having an algorithm that can be explained is good.

Note that the EU group (High Level Expert Group) working on GDPR is discussing AI – they have principles to abide by for AI.

The principles are:

• fairness
• purpose limitation
• data minimization
• transparency
• the right to information

Further, there are three foci to protect data in AI:

1. reduce the need for training data
2. uphold data protection without reducing the dataset
3. avoid the black box algorithm

We should show that we care about consumers as an industry.

RESO Speed Dating: What Are All of the Workgroups Doing for Your Business?

Presentations from all the RESO workgroups on how their workgroups are working to solve broker pain points and the business cases behind their efforts.

Broker Advisory Group – David Gumpper – The group gets brokers to articulate their challenges, then passes them to other workgroups to see if there is a place where RESO can make a difference.

R&D Workgroup – Greg Moore – This is the mouth of the RESO "funnel," working to further define business cases, do research, analyze possible solutions and send them to other workgroups.

Transport Workgroup – Stephen Ledwith and Paul Stusiak – This group provides a consistent and standard way of moving data. They review external standards and contribute back to those standards.

Data Dictionary – Brian Tepfer (for Rob Larson) – The group focuses on fitting all the different data from different companies into a single dictionary so it's easy to use.

Payloads Workgroup – Rick Trevino – This group helps define different predictable data sets (e.g., IDX or broker back office) that you might ask for from an MLS.

Universal Property Identifier Workgroup – Mark Bessett – The group helps tie all kinds of information about a property together, information that might come from different locations, via a common identifier.

Internet Tracking Workgroup – Chris Lambrou – There are many products in the real estate ecosystem – how do you measure effectiveness and ROI? Analytics. The focus of the group is creating standards for the data you need for analytics.

Distributed Ledger Workgroup – Mark Lesswing and Ashish Antal – Distributed ledgers deal with events that happen over time. For example, the lifecycle of a listing. They are creating an event model for real estate – all the events that occur in real estate systems that could be logged in a ledger. The goal is to come up with a standard for sharing events between systems.

Cross-Platform Interoperability Workgroup – Chris Haran – This group creates standards to help systems pass data back and forth, fostering innovation and creating efficiencies. This is a new workgroup in 2019 and the first one that is focused on transaction management.

Data Dictionary Workgroup

Workgroup Chair: Rob Larson, Chief Information Officer, CRMLS

I was not able to attend some of the Data Dictionary session while attending the Business Track session occurring next door.

Many changes were reviewed and voted on, and the meeting has been documented in RESO's collaboration system. | VIEW ONSITE NOTES

Your Technology, Your Bottom Line: Embracing Broker-Enabling Standards and Policies

Presenter: Joshua Lopour, Principal, DataLoft

Matt did not attend this meeting, but the presentation will be available for viewing.

Why Web API?

Presenter: Michael Hayes, Homes.com

Matt did not attend this meeting, but the presentation is now available for viewing.

The real estate industry has made great progress in how listings are shared since the introduction of FTP and RETS. The latest technology, the RESO Web API, will allow you to syndicate your listings faster and save you time and resources by reducing hosting and coding needs. This presentation is about why Homes.com is transitioning to Web API and why your company should make the switch, too.

RESO Web API Workshop - Understanding the RESO Web API

Presenter: Turan Tekin, Bridge Interactive

Matt did not attend this meeting, but the presentation is now available for viewing.

Back by popular demand! An expert shares why APIs are the way forward for real estate. They solve problems and create opportunities. Learn how to implement them.

Transport Workgroup

Workgroup Co-Chairs: Steve Ledwith, VP of Engineering for eXp Realty and Paul Stusiak, President and Owner of Falcon Technologies Corporation

The RESO Web API standard leverages open standards in authentication and data delivery, which greatly simplifies data access across applications and modern-day devices, products and services. The primary role of the Transport Workgroup (formerly Web API) is to provide standards for the exchange of transactional real estate business data. The RESO Web API provides functionality for both data access and creation, aligned with business needs identified across RESO Workgroups. | VIEW ONSITE NOTES

Web API Specification: Section 2.6 – Standard Resource Names

Paul Stusiak and Steve Ledwith opened the Transport discussions with the topic of nonstandard resource names in the Web API. Due to differences in interpretations of the Web API specification, vendors aren't consistently using Data Dictionary names for Standard Resources. This causes interoperability issues both within the residential real estate community as well as for vendors involved elsewhere in the transaction. The workgroup discussed how the language in Section 2.6 of the Web API specification (1.0.2+) needs to be clarified to enforce that Data Dictionary resources are used, when applicable. Further recommendations will be made by the Transport workgroup in their scheduled meetings over the next few months.

The EntityEvent Resource and Event Based Replication (RCP-027)

The EntityEvent proposal (RCP-027) and accompanying Data Dictionary proposal were developed with the help of a large number of members who have experienced the complexities of replication and ETL processes across the industry. Due to differences in implementations, paging limitations and issues with "Physical Timestamps" such as time zones, record backdating and clock drift, replication is challenging in the RESO Web API.

To streamline data transfer between MLS data sources and large-scale aggregators, brokerages and franchisors, and analytics consumers, a "log" based, technology-independent resource was created called EntityEvent. This resource contains EntityEvent records ordered by logical timestamps using the EntityEventSequence field. EntityEvent records are generated each time resource data changes occur on the Producer, meaning when resources are created, updated or deleted. This proposal does not attempt to interpret or classify raw source EntityEvent into their corresponding business events. As such, it allows for instantaneous replication of data with minimal payloads and little implementation overhead.

RCP-027 was adopted at the RESO Spring Technology Summit in Boise and is currently in DRAFT status. There were previously discussions about creating an open source prototype of RCP-027 as a proof of concept and reference implementation. Eric Finlay and Josh Darnell have begun on this prototype, which will include a server, client, and event generator. We're currently looking for volunteers to help. Please reach out to Paul or Josh if you'd like to be involved.

Standard for Unattended Authentication (RCP-026)

Replication of data is a primary use of the Web API. Several authentication methods are possible with the certification testing default method of OIDC workflow. This works well for interactive use but makes the replication workflow difficult to automate. This change proposal makes the Bearer Token method the certification testing default and requires that a method of unattended authentication MUST be available on servers where replication is used. This may take the form of either Client Credentials or long-lived Bearer tokens, both of which are already part of the existing Web API specification for version 1.0.2 and later.

The wording of section 2.1.1.2 OpenID Connect Standard (version 1.0.3 referenced herein) should be changed to:

REQ-WA103-SC2: The "OAuth 2 Bearer Token" Classification is awarded when ALL of the following testing rules are satisfied:

• • REQ-WA103-BT1
  • REQ-WA103-BT2

REQ-WA103-SC3: The "OAuth 2 Client Credentials" Classification is awarded when ALL of the following testing rules are satisfied:

• • REQ-WA103-CC1

For servers that support server-to-server communication, one of REQ-WA103-SC2 or REQ-WA103-SC3 are required. REQ-WA103-SC2 will be the default mechanism for unattended authentication.

It was discussed whether this be backported into version 1.03 and this will be a topic of further discussion in the next Transport meeting.

Lightweight Autofill API (RCP-022)

The purpose of this proposal is to provide a way to allow third-party data providers, such as photographers or those taking measurements, to send a bundle of data to the RESO Web API to be added to an existing record or so that new records may be auto-populated with these data.

In addition to RCP-022, there are additional proposals that address the creation of Data Dictionary resources to support RCP-022, as well as a proposal to produce a normative reference schema to accompany the Lightweight Autofill API. The schema portions of this work (RCP-025) will be addressed in the Common Schema subgroup, and this is one of their existing business cases.

RCP-022 MLS Autofill API Implementation

1. Service providers provide agents with MLS Autofill URL.
2. MLS Autofill URL points to an HTTP/HTTPS endpoint serving a JSON object.
3. An agent pastes the Autofill URL into a listing form.
4. The listing form fetches the JSON object and autofills desired form fields with data.
5. The JSON object has a tree structure with nested arrays of buildings, floors and rooms and a separate array of media resources at the root level.

The Chairs and workgroup request that RCP-022 be discussed and voted on in the next Transport workgroup meeting.

Hitting Out of the Park with RESO – Roundtables

Attendees separated into roundtables on various topics.

Table 4: Improving the RESO Standards: We're Seeking Your Business Needs, Opportunities and Challenges

This group documents business cases, related standards and other solution ideas, then may send a prioritized case to another workgroup to work on. Items discussed included:

• a unique agent identifier that would let us link records across MLS boundaries and states
• communication of image modification
• communication of photo copyright
• ADA compliance on photos - "alt tags"
• Measurement standards: square feet and room dimensions – How? Who? When? Standards like ANSI, BOMA, International standards, Alberta's approach
• License "meta" information for data feeds

We discussed past projects as well as ideas that were not prioritized in the past but could be in the future.

Doug Devitre brought the idea of using RESO standards to find agent real-time location (e.g., 10 closest agents to provide service). There's no company that's approached RESO about needing such a function, but the data could be sourced from some safety apps. But how would we do this safely?

How MLSs Can Help Brokers Make Better Decisions Using Data

Presenter: Eric Stegemann, TRIBUS

Matt did not attend this meeting, but the presentation is now available for viewing.

For too long, brokers have used gut and intuition to make decisions. With the entrance of iBuyers and well-funded new brokerage entrants, brokers need to utilize data to help them make better decisions. Eric discussed how brokers can use MLS / RESO data to make decisions on where to put offices, what locations are likely to be next and even what agents they might recruit. Data collection, data warehousing and BI were also discussed.

My Storyline on the Journey to Success with RESO

Speakers: Anton Roeger; Chairman, Chief Innovation Officer & Founding Partner at APC Data Analytics; Jamie Lee Derrickson, EVP and Chief Product Officer at APC Data Analytics; Noah Leask, President & Chief Executive Officer for APC Data Analytics, LLC

The development of applications for the real estate industry using RESO-compliant MLS data is limitless. The ability to create new software across multiple MLSs allows companies to leverage their resources to produce cutting-edge products for their MLSs, agents and brokers. Localized technology concepts for the betterment of the real estate industry can only be turned into a reality on a larger, national scale with the use of a common language. This demonstration showed the use of RESO-compliant fields to produce high level data analytics and the future of AI in relation to real estate.

APC created a statistical package to supplement the MLS in Charleston. The next step was to integrate with another MLS and then learn how to integrate on a national level one MLS at a time. They found out quickly that data from every MLS was different – some RETS 1.2, 1.5, 1.72 and custom APIs. The software built for Charleston didn't work on the second MLS. The cost made that nonviable.

Using Data Dictionary and the RESO Web API, implementation is very quick technically. These real-time data feeds let them create real-time statistics, and they script explanations for agents based on actual market conditions. They're now connected to both Trestle and Bridge to provide aggregated data.

Putting the Pieces Together – Interoperability Workgroup Meeting

Presented by: Chris Haran, Cross-Platform Interoperability Workgroup Chair & CTO at Midwest Real Estate Data LLC; Paul Stusiak, Transport Workgroup Co-Chair & President and Owner of Falcon Technologies Corporation; Steve Ledwith, Transport Workgroup Co-Chair & Vice President of Engineering for eXp Realty; and Joshua Darnell, Chief Architect for RESO

Common Schema is a relatively new group, created earlier this year at the RESO Spring Technology Summit in Boise. Interoperability is about helping tools work together and talk to each other elsewhere in the real estate transaction. The goal of Common Schema is to remove the "rough edges" of data exchange and make tools work more efficiently together through the RESO Web API. As you might imagine, these two efforts are related.

The focus was as follows:

• How do other industries handle interoperability and what can we learn?
• How can listing updates work in creating interoperability of the transaction?
• What's working for you?
• How do we hit a home run with Common Schema?

In healthcare, they need to keep up with changing regulations, better leverage AI with the right datasets, securely transfer and exchange data, and give patients access to their own data for a more informed patient. They've created Blue Button 2.0, providing an API to enable beneficiaries to connect Medicare claims with programs/services they trust. People can download a file with their information that they can then upload to another system, putting the patient in control of their data. The patient can also indicate that they are no longer working with a provider.

In finance, they are trying to promote competition, increase service offerings in underserved areas through reduction of costs via economies of scale and improve ease of use of tools for the customers. They've created Mobile Money for customers that want to send money across networks, especially in developing countries. Banking networks come together (as in Tanzania) to establish standards. They learned to allow the industry to define the rules, and success requires an industry champion. Identify a neutral broker, ensure everyone is speaking the same language, have a plan and don't expect to accomplish everything at once.

Interoperability involves co-opetition. "Whereby competitors agree to cooperate on certain aspects of the business but compete aggressively on others."

Listing update seems to be an area where this could occur. There are 20–30 different systems in the life of the listing involving different logins and different data entry points. The group dialed into "getting the listing." The agent meets with homeowner, they sign a listing agreement via TMS (info is input here: location, property ID, price, taxes, brokerage and agent name, and seller information), then listing data is input into the MLS by the agent or staff (the same data!). Then, the same standardized data goes to the brokerage, IDX and portals. To support these needs, Interoperability has implemented the Web API 1.1.0 Update specification (RCP WebAPI-010) in order to create partial listings from transaction management platforms.

There were questions:

• Why draft and not active?
  • This is due to the fact that the fields selected for the Update data shape might not be sufficient to complete a listing in every system. However, they should be enough to start a listing in a DRAFT status, in which case business rules aren't necessarily applied.
• How does this change listing workflow, including with computer vision?
  • It allows for listings to be created automatically through workflows outside of the traditional Vendor Listing Input Module. This opens up new possibilities for products designed to help streamline the listing input process.
• Is there anywhere else a listing could start?
  • The CMA is another possible source of listing data.
• Where else could a transaction management system (TMS) distribute data to?
  • Another TMS
  • A CRM system
  • Broker systems

The workgroup is looking at more of the transaction and documenting where these systems could work together.

How do we promote the concept of co-opetition, beyond Data Dictionary? Common Schema!

Thinking in Shapes: The Future of Interoperability

The key to interoperability is that queries and data sets currently vary a lot. Integrations are slow and brittle and require lots of extra code, especially local data and varying data sets. "Shapes" (standardized schema) create predictability while satisfying the local needs of each data provider.

By providing Locale and Synonym support and using the RESO Data Dictionary as a framework, data may be described in a manner that allows it to be predictably discovered and used. Data can be packaged into consistent bundles of resources such as Property, Member, Office, Teams, etc.).

Common schema should make front-end of choice and system of choice easier to implement in addition to increasing general interoperability.

Systems using this approach only need to be responsible for reading and writing to the common schema / shape rather than extensive mappings between hundreds of systems. In the cases where special data mappings are required, Common Schema cuts down on that work by allowing vendors to only implement the differences in schema rather than the entire Data Dictionary.

Common shape starts at the conversation between the MLS operator and system vendor. The conversation continues with each client vendor that enters the market. Local and Synonym will take work. But the result is a data catalog for your market. The goals for the group going forward are to:

• Create standard reference metadata for resources, fields, enumerations and relationships for DD 1.6+
• Create data shapes
• Localization and Internationalization

Web API: Opportunities, Challenges and the Next Evolution of Real Estate Data

Presenter: Scott Lockhart, CEO, Showcase IDX

Matt did not attend this meeting, but the presentation is now available for viewing.

RESO's new Web API data protocol is in its infancy, yet it's already rapidly starting to replace RETS in large and small MLSs across the country. Scott Lockhart gave a behind-the-scenes look into the experience of Showcase IDX in implementing Web API, including the wins, pitfalls, lessons learned and best practices that MLSs and technology companies can use as more MLSs adopt Web API. Scott was joined by Showcase IDX CMO, Kurt Uhlir, who also shared some of his insights on the parallels between Web API and his experience at the forefront of the multi-billion GPS and navigation industries.

Brokerages' Use of Standards

Presenter: Steve Ledwith, Vice President of Engineering for eXp Realty

Matt did not attend this meeting, but the presentation is now available for viewing.

This was an exploration of how eXp Realty is using standards to build tools, inform business processes and drive continuous improvement. Steve talked about how this technology-focused brokerage contributes to and benefits from being involved with RESO.

Research & Development Workgroup Meeting

Workgroup Chair: Greg Moore, Chief Technology Officer at RMLS

The RESO Research and Development Workgroup's purpose is to solicit and review submitted business cases and underlying business needs, opportunities and challenges from the real estate industry and identify how RESO can directly contribute benefits for the business needs of the industry with solutions developed through the creation and evolution of RESO standards. The Research and Development Workgroup performs a careful and critical examination of the submitted business cases and coordinates the delivery of potential solutions through standardization with other workgroups and individual subject matter experts within the RESO community.

Unique Agent Identifier – the goal would be to provide a unique ID to every licensed real estate professional, linked to all real estate licenses held, to create efficiency and clarity across all technology systems (association, MLS, franchisor, broker and consumer-facing technology). We must be careful about using "PII" for privacy and security reasons. What information would we leverage? We've talked about IEEE identity standards, blockchain and other technology. Is it centralized or decentralized? It should handle non-REALTORS®. Should it handle assistants? Would NAR go to bat with states to get licensure information for us? There are international considerations. We may need to spin up a subgroup.

Broker Tours – Right now, agents enter their information into multiple MLSs that do data shares JUST so they can create broker tours in multiple systems. Ashish wants agents to be able to opt into tours with a tour data share. What is the listing? What tour do they want to be part of (name and schedule)? What are the geo boundaries for tours? Are there instructions? Can we come up with a new tour schedule and tour data resource so listings can be associated with a particular tour native to another system and that information shared back.

Data Feed Authorization Information – Develop a resource via the RESO API for MLS to communicate the status of data feeds with data consumers. This will be an MLS managed resource the vendor would query to check the status of a data feed for their customers. This could also be utilized by MLSs to handle data feed reporting. The resource would allow vendors to automate the enabling and disabling of client sites and mobile applications. It could provide the vendor with the reason that a client site/app is not enabled. There is already a spreadsheet of fields/enumerations, and this may be moved over to the Data Dictionary Workgroup soon. Does there need to be a field added to the resource to allow a vendor's aggregation partner(s) to also access a vendor's payload?

Broker Advisory – Image Standards & Handling – The Broker Advisory Workgroup requests that the R&D Workgroup review and work with related RESO workgroups to address the below image-related issues:

• Challenge to efficiently manage images
• Challenge with copyrights – "right to use" for image.
  • The REBR language may be useful for articulating rules (e.g., delete these photos on status change).
• Challenge of ADA compliance for images.
  • The Data Dictionary contains ImageOf, LongDescription, ShortDescription where "alt" information can be stored. Should there be a field that identifies the information which contributes to ADA compliance?

Image Modifications – Numerous listing images uploaded to the MLS, used on broker and agent websites and apps, and syndicated for display on other Internet sites are heavily modified. While this can be an effective sales tool, some undisclosed modifications may be deceptive. National MLS policies and other steps should be implemented to address the risk this causes. The workgroup has been working on a field/enumeration that can be passed to the Data Dictionary Workgroup.

Measurement Standards – Measurement standards and subsequent square footage calculations lack a standard of measure definition. With price per square foot regularly used in CMA, AVM, statistics and appraisals, defining and disclosing the measurement method is needed. Would agents who need to enter the information be aware of different measurement standards?

New Construction-Specific Fields – When new construction properties are sold by real estate pros, providing fields to specifically define new construction properties in the RESO Data Dictionary will facilitate MLSs to better support real estate pros who wish to market and cooperate in the sale of new construction listings in their local MLS listings.

Big Engine Big Fuel

Bill Fowler, Senior Director of Industry Relations, Compass

Matt did not attend this meeting, but the presentation is now available for viewing.

In 2019, the "Broker Engines" being built to serve the next generation of agent and their clients have outpaced the policies that provide access to the information that fuels them. This has created new levels of strain between brokerages and MLSs, two partners who depend on one another. But this strain is temporary. There's an opportunity to come together and reset the relationship to meet the current and future technology landscape. This session outlined that opportunity and discussed the goals for achieving it.

Internet Tracking Workgroup Meeting

Workgroup Chair: Chris Lambrou, CIO at Metro MLS

Internet Tracking data is a key component for any modern-day data set. No longer is having the data secure and readily available enough. True statistics and analytics that show overall activity and underlying value are now expected and commonplace in the software industry. This Workgroup creates and maintains the recommended industry-wide standard for tracking all Internet, product and service activity surrounding real estate listing data, brokers, agents, consumers and utilized technology solutions.

The specification involves: event (e.g., a view, a login), actor (e.g., a person), object (e.g., a listing) and source (e.g., an MLS or IDX site). This spec is in Data Dictionary 1.7. In 2019, the Internet Tracking Summary Report was discussed. There's a white paper describing it on reso.org, and a number of enumeration changes have been made in 2019.

Leads. There was a suggestion from the group to review the "Submission from Lead Form" EventType. The current enumeration name is misleading – leads can be derived from an actor in different ways. Rename to "Lead Generated" or "Lead Delivered"? Perhaps split it into two enumerations - ListTrac calls it an "inquiry" and a "lead." But any inquiry COULD be a lead. How do we know the actors' intent when they click on a phone number or "contact the agent"?

Summary Report. The white paper on the RESO Standard Summary Report is on Confluence, and it's open for review. We're defining a "lo-fi" usage report back to a customer as a best practice. The metrics in the summary report will be in Data Dictionary 1.7.

Review of Industry Analytics Reports. We looked at reports from REcolorado, homes.com, ListTrac and RPR.

RESO Standards: Do Brokerages Really Care?

Presenter: Glenn Phillips, CEO, Lake Homes Realty

Matt did not attend this meeting, but the presentation is now available for viewing.

With full brokerage membership in 108 MLS and operating wholly owned (non-franchised) real estate brokerages in 26 states, Lake Homes Realty has a unique perspective of MLS, data and brokerage mindsets. Many challenges to acceptance of data standards are known, but some are not always apparent to all parties. RESO is filled with the parties who have already shown and believe in standards "buy in." However, not every brokerage or MLS believes in standards. And, interestingly, some who claim they believe actually have financial incentive to create obstacles and delays. From the trenches, Glenn presented an entertaining, candid and raw view of obstacles that must still be overcome before standards will be universally accepted.

Broker Advisory Workgroup Meeting

Workgroup Chair: David Gumpper, Head of Technology Consulting at WAV Group & Founder/CEO at Gumpper Group, LLC

Matt did not attend this meeting, but RESO CEO, Sam DeBord took notes at this meeting.

Review and Additional Discussion of Topics Covered During Last Meeting

a. Consumer Data Survey. Chair David Gumpper received feedback from the RESO Board of Directors on the consumer data survey that the group has been working on this year. Updates have been made and the survey will be moving forward for industry feedback.

b. Better Data on Transaction Fallout. There was a follow-up conversation on broker pain points, particularly transactions falling through. Are there ways for brokers to track the reasons for these transaction failures internally? There could be ramifications for future liability, yet also opportunities for agent feedback on productivity and chances to correct transactions that are likely to fail based on predictive analytics. Greater insights into transaction successes could also inform future clients in a more valuable way.

The group agreed that these kinds of standardized statistics would be unlikely to be shared across brokerages but could still benefit from a standard when tools need to be developed to support them. Anonymized data could potentially become a cross-brokerage opportunity for more insights.

c. Duplicate Listings and the UPID. Deduplication of listings and media are still a concern for brokers, and the Universal Property ID was the focus of solving these issues with the group. Practical issues with MLS policy were presented as current barriers. When two MLSs display the same listing in a different way, vendors are often required to display that data exactly as presented. Therefore, they must continue to display multiple listings for the same property. Inconsistency of display rules were a consensus problem, and the group asked if LeadingRE or another organization could lead an effort to streamline them.

Multiple members agreed that RESO has a responsibility to engage on these issues. The data has changed through standards adoption but, in most cases, the rules haven't changed. It was suggested that RESO be the facilitator to bring these groups together (e.g., CMLS, LeadingRE, Realty Alliance, MLS Grid, MLS Aligned, NAR MLS TEIAB).

Industry Review with Member Discussion

a. Replicating Millions of Records with a Single Set of Credentials. On the technical side, brokers' vendors stated that they're still often only allowed one set of credentials to access data from some systems, and it slows their ability to replicate. Without allowing parallel downloads of data, initializing work with a single MLS would mean downloading millions of records at a rate that would take weeks to finish.

b. Sold Data Available, But Accessible? Focusing on data policies that have been passed but still have practical issues, sold data was discussed. In some markets, sold data is available but practically unattainable because it is priced extremely high, according to some vendors. The marketplace is effectively blocking access to sold data for many, according to the speakers. RESO does not have a position on business models or pricing.

c. The Next-Generation Feed. Multiple brokers presented during the week on the future of more robust data feeds and faster/more efficient access to them. The MLS executives in the workgroup agreed in many ways – they would love to maintain one feed, but they are bound by contracts and policy.

There was a request for a model contract, possibly from NAR, that would allow an MLS and broker to cooperate with a single data feed that included back office data as well as data for display (traditional IDX or VOW data). Individual MLSs viewed current policy and contracts as so complex that there would be a need for a unifying body to develop the model. It was suggested that RESO could come up with the framework for the data solution, and then bring it to other organizations for further efforts.

RESO is already defining the broker back office feed in its Payloads Workgroup. It was discussed that there would be "tagged" display fields in this next-generation feed, and one defined set might be designated as the RESO IDX payload, thereby allowing one feed to be "back office and display" in one.

d. Playing in an Expensive Sandbox. Test data was a significant discussion for vendors. Getting access to credentials and data that actually works in a live system creates great costs for new market entrants. For example, if a product ties MLS data into public records data, it can't produce a working product for MLS verification when it is being fed fake addresses.

e. TSA Precheck for Vendors? The long-standing conversation of creating a TSA Precheck for vendors with a track record of using MLS data appropriately brought some suggestions. Creating a slow lane for new industry entrants would bring anticompetitive concerns. There was a suggestion that a "safe harbor" certification could allow for more certainty by all parties. Allowing organizations to affirmatively show that they understand the rules of the road could allow MLSs to make better, quicker decisions on data access for some.

The group agreed that a course could provide a certification or "badge" that ensured the data consumer (broker's staff or technology vendor) understands licensing rules, display rules, MLS policy, etc. There would be no requirement that an MLS make changes to its policy regarding data access, but many might use this certification course at their discretion in expediting data access. At a minimum, newer industry data consumers might be better educated on the process upfront.

Which organization might create/administer this course was discussed. Getting key stakeholders together in a shared environment to create the framework and initiate the content production was suggested.

Matt had to run before the final day, but RESO staff have filled in the gaps for him, and all presentations and onsite notes are updated within RESO's Confluence system.

RESO Certification: The Path Forward

RESO CEO Sam DeBord returned, Bloody Mary in hand, to lay out the path forward for RESO in terms of building and operating adequate testing tools for certification to the latest Data Dictionary and Web API standards. Joshua Darnell and Transport / Common Schema team fleshed out more details.

Paint Points, Ideas, Solutions: Hash it Out with Your Peers

RESO CEO Sam DeBord led a discussion that touched on topics that are important to technology vendors, MLSs and the real estate industry at large. It was a spirited conversation with many interesting points of conversation, including the following:

• RESO should create a "best practices" document on how to pull data and how communication should work between the client and the server.
• How best to code for multiple vendors without wasting time and effort; Common Schema will help with the differences between different vendors.
• Better documentation on how to consume the data from the vendors.
• RESO should provide more MUSTS than MAYS.
• RESO can better help technologists by eliminating the fear that they will be cut off or blacklisted due to complaint.
• NAR is reaching out to organizations to help them better understand certification policy
• Talked about the establishment of a RESO or Council of Multiple Listing Services (CMLS) course to teach new vendor companies how to use the data, rules, broker technology partners and the possible certification or endorsements to prove them.
• Technologists are asking for VOW feeds but aren't building VOW websites.
• Talked about including "Vendor Endorsements" in the OUID feed.
• CMLS is creating the repository for the organizations (Data Access Marketing); RESO OUID could tie and programmatically provide this information on contact information.
• Giving MLS more confidence that a vendor is better prepared to work with the MLS and handling their data. (A "TSA Pre-Check" for Vendors)
• Is there a common list of questions that all vendors need to be able to answer before they get the MLS access?
• Some vendors want the data to feed into their system before they have something to present to an MLS to confirm that they are serious and know what they are doing; thus the "TSA Pre-Check" concept.
• One possibility: A RESO Reference Server that Vendors can use to pull information into it and display the server information in their website or application to demonstrate what they can do; but we would need to control the unauthorized usage of data and help MLSs know that they are working with "good actors."
• NAR is merging IDX and VOW of private information; difference is how the information is being used; the payloads may be the same but the rules are different for each.
• There should be an agreed-upon licensing agreement among multiple MLSs; the challenge has been that everyone has their "one off" issue; across the nation, the number of these "one off" issues would be daunting.
• The R&D Workgroup is working on a Consumer Status server to help record the status of the users of the data.
• RESO should develop marketing materials on the value of switching from RETS to RESO Web API.

Distributed Ledger Workgroup Meeting

Workgroup Chairs: Mark Lesswing, SVP T3 Sixty; Ashish Antal, Director of Architecture, MLSListings, Inc.

The Chairs reviewed the purpose of the workgroup and recapped workgroup progress on Distributed Identity (DID) and Uniform Resource Names (URNs) before getting into two demonstrations of the Event Model from the brokerage and MLS perspective. The brokerage example showed use of the Event Model in the agent onboarding process, and the MLS example showed the Event Model in a real-time push application for subscribers. | VIEW ONSITE NOTES

Payloads Workgroup Meeting

Workgroup Chair: Rick Trevino, VP of Internet Technologies, MetroList

The Chair provided an overview of the workgroup's purpose and goals as relates to defining payloads for Data Dictionary v1.6 and 1.7, briefly discussed the testing tools and delved into the scope and status of back office payloads ahead of a line-by-line review of the Prospecting tab within the Back Office Payload Worksheet. | VIEW ONSITE NOTES