Happy Friday. This will be an unusual post because I admit I am shilling for one of my own projects. It's not all that unusual since it's an open source project from which I make no money and gain no benefits.

But it does give me an opportunity to talk about PDAP feeds. The title, it turns out, is kinda wrong... because PDAP was never great so it's hard to make it great again. At the same time, I do think the time and circumstances are moving towards making PDAP an important part of the industry conversation.

This is a public post, but will be of particular interest to MLS people and to brokerage operators. Maybe to a few tech people in the industry.

What Is PDAP?

Let's start with the basics. What the hell is PDAP?

PDAP stands for Participant Data Access Policy, and it comes from this NAR policy promulgated in May of 2020:

Participants' Rights, Section 18: Right of Participant to MLS Data Feed of Listing Content (Policy Statement 8.3)
A Multiple Listing Service must, upon request, promptly provide an MLS Participant (or the Participant’s designee) a data feed containing, at minimum, all active MLS listing content input into the MLS by or on behalf of the Participant and all of the Participant’s off-market listing content available in the MLS system. The delivery charges for the Participant’s listing content shall be reasonably related to the actual costs incurred by the MLS. The data feed must be in compliance with RESO Standards as provided for in MLS Policy Statement 7.90.
Note: MLSs will not limit the use of the Participant’s listing content by the Participant or the Participant’s designee. (Adopted 5/20M

Now, I wrote a post about the various data feeds out there and it might be worth reading as a refresher (or for the first time): IDX, VOW and Broker Feeds. Here's what I wrote there:

PDAP is not a grant of license either. It is a convenience play. From the MLS Handbook:
[insert the language I just quoted above]
All that PDAP says is that the MLS has to give to the brokerage all of the data that brokerage put into the MLS. That is, the brokerage owns the data, and the MLS is a “custodian” of sorts — the MLS must give that data back to the brokerage if/when the brokerage asks for it.
That’s all that PDAP is. There is no grant of license, since the MLS doesn’t own the rights to grant to the actual copyright owner — the brokerage who put the data into the MLS.

Now... I recently had a conversation with a proptech company executive talking about the PDAP feed and it forced me to remember my own experience trying to do Nexus MLS a couple of years ago. Our mutual experience is that roughly half of the MLSs we spoke to did not even know what PDAP was. The remaining half are further divided into a handful of MLSs who knew what it was, and could provide it with standard forms and such, and the rest who knew what it was but could not provide it. They would need to speak to the MLS vendor (Cotality, ICE, FBS, etc.) about setting it up... and we know the process for doing something like that.

I thought PDAP was totally underutilized by the industry, and still do. But it remains somewhat difficult for the MLS to provide the PDAP feed (as they are mandated to do... though NAR mandates on the MLS are... well...) and impossible for the brokerage.

Which leads to...

PDAP Utility

One evening, I just thought... is it that difficult? Can I vibe-code a solution?

The short answer is yes and no. Yes, I can and did vibe-code something that works; no, it is far from production ready. Let me introduce you to PDAP Utility, a free open source piece of code that is intended to be the starting point for real devs to do real work.

GitHub - rsh2k1-2026/pdaputility: OSS ConverterAppliance for producing brokerage-specific PDAP feeds from BBO/RETS MLS feeds
OSS ConverterAppliance for producing brokerage-specific PDAP feeds from BBO/RETS MLS feeds - rsh2k1-2026/pdaputility

I have tested it with some sample datasets I have access to, but obviously, could not test it with real live data (because I'm not an MLS nor a brokerage) or with live API endpoints.

Some of you can. As I wrote in the README, my motivation is simply to make it easier for the MLS to provide a PDAP, and for a brokerage to extract a PDAP if their MLSs cannot or will not provide it.

Many an MLS find it difficult to provide PDAP feeds because they do not own or control the MLS technology platform.

For a broker, who wants a PDAP feed, but belongs to multiple MLSs or to an MLS that does not have the wherewithal to provide a PDAP feed directly, it can be frustrating.

PDAP Utility is intended to help participants, designees, MLS operators, and software contributors turn existing listing-content feeds (particularly BBO and RETS feeds) into clean, brokerage-scoped CSV outputs.

Dump in BBO, get out PDAP is the simple idea.

Built for the MLS

In an ideal world, the MLS can (and many already do) provide a PDAP feed to any participant who asks for one. I know that MLS Grid provides one, as an example.

In the real world, the MLS has to ask the platform vendor to create it... and that often means time, money, and meetings to undertake product development.

I didn't think that was necessary in 2026. Every MLS has access to a data dump of its database, either as BBO (Broker Back Office) or as RETS. In some cases, the MLS might not have API endpoints or "data feeds" per se, but they can always generate a CSV file.

PDAP Utility is built to take in that CSV file, and output PDAP CSV files, at least at the per-office level. If endpoints are provided, the it is simple to have the PDAP Utility plug into all of that as well.

Since the MLS is allowed to charge a reasonable delivery fee for the PDAP, this could be a nice little revenue center as well. And PDAP Utility is entirely free to use and to modify as open source code. Have at it, if you want.

BBO --> PDAP?

I recognize that one area needing discussion is whether a brokerage can in fact take a BBO (Broker Back Office) feed and extract a PDAP feed from it. Because a brokerage does have to apply for and get a license to a BBO feed.

But here's what I wrote in the IDX, VOW and Brokerage Feed post:

BBO is another convenience play to let brokerages provide data to their vendors for internal tools. From NAR’s MLS Handbook:
“BBO Use” means use of BBO Data by participant and subscribers affiliated with the participant for the following purposes:Brokerage management systems that only expose BBO Data to participant and subscribers affiliated with participant. Customer relationship management (CRM) and transaction management tools that only expose the BBO Data to participant, subscribers affiliated with participant, and their bona fide clients as established under state law.Agent and brokerage productivity and ranking tools and reports that only exposes BBO Data to participant and subscribers affiliated with participant. Marketplace statistical analysis and reports in conformance with NAR MLS Policy Statement 7.80, which allows for certain public distribution.

BBO Use may only be made by participant and subscriber affiliated with participant, except that at the request of a participant, MLS must provide BBO Data to that participant’s designee. The designee may use the BBO Data only to facilitate the BBO Use on behalf of that participant and its affiliated subscribers.
Nowhere is there a grant of license, except perhaps to the “designee” of the brokerage participant, i.e., the technology vendor. But the overall intent is clear: BBO is just a “make life easier” for brokerage technology stacks. It has nothing to do with display of properties.

Your perspective may differ, but I believe that BBO is a "convenience" play, not a grant of license by the MLS. To the extent that there is a license, it is prohibiting certain actions that IDX and VOW cover – public display. Which means that I believe that a brokerage is fully within their rights to extract just their own data (which is what PDAP is) from it.

Obviously, the preference would be for the MLS to provide the PDAP feed. But as I said, half of the MLSs out there don't even know what it is.

Solution Looking for a Problem

There is, to be sure, a sort of objection to PDAP and by extension, the PDAP Utility project: you're trying to solve a non-problem.

No brokerage is asking for a PDAP feed. If the MLS doesn't know about it, it's because nobody wants one. So why bother?

I think that's a very fair point. If no one is asking for it, then there is no reason for the MLS to spend any cycles thinking about providing it.

That's where free open source can come in handy, and why I've launched PDAP Utility as just that. If no one is asking for a PDAP feed, then feel free to ignore it. But if someone does, then you have a free utility that will do it for you easily and simply without having to ask your platform vendor to undertake a coding project.

Wrapping Up

As mentioned, this is an unusual post. It's pretty short, for one. I am shilling one of my own projects (and it's free!). If you have the inclination, please feel free to check out the public repo and get involved. I am 100% certain that real tech people can dramatically improve my little vibe-coded effort.

If not, that's cool too. Just know that it exists if and when a brokerage comes knocking asking you for a PDAP feed.

-rsh