Spark Platform Part 2: Explaining the Legal Framework

I explained in my first post about the Spark Platform what its likely benefits would be, but if it’s to be successful it must provide legal, technological, and business-culture frameworks. This post looks at the legal framework.

Despite the simple description of the Spark Platform’s operation in the previous post, from a legal perspective, things are a bit more complex. Consider a basic example, a broker buying an IDX website through the Spark Platform:

• The broker is buying a product through a platform provided by FBS and is making payment to FBS.
• The product the broker buys contains data from the MLS in which the broker participates.
• The product will be delivered by a product or service provider (PoSP), who is under contract with FBS through the Spark Platform.
• The resulting IDX website, branded as the broker’s but operated by the PoSP, will deliver data to consumers who visit it.

Thus, there are five entities—FBS, MLS, broker, PoSP, and consumer—each of whom likely has expectations about the conduct of most or all of the other four. So, for example, MLS expects FBS to collect money from the broker and pay part of it to MLS; the broker to pay FBS and not violate the MLS rules in the website; the PoSP to build a website that complies with the MLS display requirements (defined in the Spark API); and the consumer to use the MLS data only for her personal, non-commercial use. The broker expects MLS to provide data through FBS/Spark to the PoSP; FBS to take the broker’s payment and remit the appropriate amount to the PoSP; and the PoSP to deliver an IDX site compliant with MLS policies.

The purpose of written contracts among parties to a transaction is to articulate their expectations up-front so that they can enforce them down the road. In a case like this, paper contracting would be terribly inefficient. Think about how many parties there might be in the single example given above: one FBS, one MLS, one broker, one PoSP and perhaps thousands of consumers visiting the resulting IDX site. Even electronic contracting where each party at each level creates its own contracts would be inefficient. Even if you don’t count the consumers, you have to have one contract for every broker or agent IDX site.

Mitch Skinner (Twitter: @MitchellSkinner), a lawyer in our firm and sometimes author on this blog, has managed to solve this legal framework problem for a couple individual MLSs, in one case for the MLS to be able to offer a digital marketplace to its subscribers, and in other cases for the MLSs to provide a completely online contracting platform for IDX sites. He describes the digital marketplace as working like this:

• A product or service provider (PoSP) enters one contract with MLS saying it will behave according to MLS’s rules; the parties enter this contract via a ‘click through’ on the MLS’s digital marketplace site.
• A brokerage enters a contract with MLS, also via click-through, saying it will behave according to MLS’s rules and that it will be held responsible for conduct of the PoSPs and agents. 
• The brokerage then selects PoSPs that it wants to work with by checking them off (opt-in) directly on the digital marketplace’s interface. Only PoSPs approved by the brokerage will be available to that brokerage’s agents. 
• Selected PoSPs’ products including MLS’s data then become available to the brokerage’s firm and agents. 
• There are no paper contracts at all.

“The jury’s out,” says Mitch, “on whether this approach will be scalable or sustainable.” He says, “Our clients using it have not been using it long enough to say for sure.” In theory, he notes, this approach could lead to a much higher number of transactions between PoSPs and brokerages than currently occurs in MLSs where every transaction must be accompanied by one or more paper contracts.

The Spark Platform promises to take this approach, which we’ve developed on a “one-off” basis for some of our clients, and deploy it across all the MLSs that work with the Spark Platform. In this model, there will be a single contract between FBS and the MLS; then, the Spark Platform will provide the contracts that are the basis for interactions among PoSPs, brokerages, and consumers.

Importantly, the Spark Platform recognizes that different MLSs have different policies. So, with regard to IDX, for example, some MLSs may require a particular field to be displayed on an IDX site, others may permit but not require it, and others may prohibit it. The Spark Platform allows the MLS to do a one-time setup (with later modifications as necessary) to specify these display requirements. It also permits the MLS to identify disclaimers and supply required logos for display. Every PoSP working with a broker in that MLS will automatically receive the data with all the necessary information about what the rules require, permit, and prohibit display of. As I understand it, the MLSs will even be able to set up end-user license terms, binding on consumers who visit the IDX sites, that those sites will inherit through the Spark Platform.

None of these steps is trivial, and I expect there will be lots of kinks to work out. And candidly, I have not even reviewed all the contracts that allow this to work (though a client just yesterday asked that we begin that review). But in principle, this approach offers a way to dramatically simplify both the process of entering into contracts and the process of communicating to contracting parties what their obligations are.

Next time, I’ll consider the technological framework that Spark supplies. In my Inman Connect presentation this afternoon, I’ll talk about the challenges in the business framework, but the blog post on that topic will probably not appear until next week. In the meantime, I welcome your comments and questions. What do you think? Does this make sense?

-Brian