Ask a head of research distribution how many places a single note goes, and the answer is usually longer than they would like. Direct email to clients. The firm's own portal, if it has one. A handful of third-party platforms, each with its own upload process, its own metadata rules and its own readership report. And now, increasingly, AI agents on the buy side that want to read the note too.
Each of those channels was added for a good reason. Together they create a lot of work, and a lot of places for something to go wrong.
This piece is about doing that job once.
The cost of every channel being separate
When each destination is its own integration, the same problems repeat.
- Publishing is repeated. The same note is formatted, tagged and sent several times, by hand or by a set of scripts that someone has to maintain.
- Corrections lag. When a note is superseded or withdrawn, every channel has to be updated. Miss one and an old forecast stays in circulation.
- Entitlements drift. Who can see what is set separately in each place. Over time those settings stop matching each other and stop matching the contract.
- Readership is scattered. Each platform reports reads its own way, so nobody can see in one view who read a note, where and how.
None of this is a technology failure in any single system. It is what happens when there is no common layer underneath them.
One publish, every channel
Research Protocol sits underneath. A provider publishes a note to the hub once, and the hub does the rest.
The note becomes available, under the provider's entitlements, to the provider's own clients reading on Research Protocol, to every connected buy-side firm entitled to it, and to AI agents acting for those firms. The same rules apply whichever way the reader arrives.
For third-party platforms, the outbound Distribution Gateway fans the note out in each destination's format. Channels today cover RIXML, SFTP and HTTPS, alongside an AlphaSense ingestion connector built to AlphaSense's published ingestion API. Supersedes and withdrawals follow the original note automatically, so a correction made once is a correction made everywhere. Embargoes can be held and released centrally. Every delivery is logged, and failed deliveries raise an alert rather than going quiet.
Your own branded portal
Many providers want their own front door as well. On Research Protocol a broker can run a branded research portal on its own subdomain, with its own logo, colours, fonts and favicon, and its own forecast templates. Readers can register themselves, gated by country, investor type and disclaimer acceptance.
The portal is built on the same hub. It is not a separate copy of the library with separate permissions. A note published once appears on the portal, to connected readers and to agents, all from the same source.
Entitlements that hold everywhere
The provider decides who sees what. Entitlements can be set per organisation and per user, and scoped by sector, company, analyst or entitlement code. Every read is checked against them, whether the reader is a fund manager in a browser, a developer using the API or an AI agent calling a tool.
That consistency is the point. An agent does not get a wider view than the people at the firm it works for. A reader on a branded portal does not see something the contract does not cover. PDFs can be watermarked per reader.
Content stays under the provider's control throughout. It can be hosted encrypted in UK South Azure storage, or left on the provider's own servers and served by signed redirect, so the file never leaves home until an entitled reader asks for it.
Readership in one report
The other half of distribution is knowing what happened next.
On Research Protocol, providers see readership across channels in one report. Reads on the hub by people are shown separately from reads by AI agents, so it is clear how much of a note's audience is now software. Readership imported from other platforms sits alongside them. And when an AI system quotes a note in its answer, that is counted as its own consumption type rather than being folded into document reads, because a quote and a download are different things and should be reported as such.
For a head of research, that turns a pile of separate reports into one picture: who read the note, through which channel, and whether they were a person or an agent.
Connecting is short
A provider can send notes to the hub in two ways today.
- REST push from your own publishing system, in batches of up to 100 notes, with a resend of the same note treated as an update rather than a duplicate.
- The provider console, where a note is published by hand with its PDF attached, or with a link to the copy on your own servers.
Both work whether the hub hosts your files or they stay with you. If your notes already go out in another form, such as RIXML, tell us what you have and we will talk it through with you.
Typical onboarding takes 5 to 10 working days. The interface is available in nine languages.
What this adds up to
Publishing once does not mean giving up control. It means setting the rules once and having them applied everywhere, seeing every read in one place, and adding new channels, including AI agents, without another integration project each time.
If you run research or research distribution and want to see how this would work with your library, email [email protected]. You can also read more about the hub on the home page.