The programmatic supply chain: who sits between the advertiser and the publisher?
Part of Supply path transparency
The short answer
The programmatic supply chain is every company between an advertiser's budget and a publisher's ad slot: agency or trading desk, DSP, any data or curation partner, SSPs, exchanges or resellers, the header wrapper and the ad server. Each adds a service and can take a fee, but only sellers in the payment flow appear in the SupplyChain object.
Key takeaways
- An open web impression can pass through a buyer side group (agency, trading desk, DSP) and a seller side group (SSP or exchange, resellers, wrapper, ad server) before it reaches the page.
- Fees enter at contract points on the buyer side and as revenue shares or margins on the seller side, and no single public file lists them.
- The SupplyChain object shows only the sellers in the flow of payment, so agencies, DSPs and curators that do not handle payment do not appear in it.
- A curated deal adds a packaging role that bid requests do not name, which is why curator, seller and origin should be written into the deal paperwork.
Who sits in the programmatic supply chain?
The chain can be drawn as a straight line from advertiser to publisher, and that line is a useful starting point. Money moves from left to right, and the ad request moves the other way, from the page out to bidders. The OpenRTB 3.0 specification (opens in a new tab) adds a warning about reality: header bidding has created a new decision point near the publisher, and it has become common to have more than one supply chain intermediary, such as an exchange that uses another exchange as a demand source.
OpenRTB 3.0 also explains why nobody in the middle sees the whole line. It assumes each entity has a business relationship, within a transaction, only with its directly connected neighbors. A DSP knows the exchange that sent the request, not the reseller two hops back. The public seller files and the SupplyChain object were built to fill that gap.
What does each party in the chain do?
Each party exists because it solves a problem for the party next to it. The table describes the role, what it adds and how it can be paid, without judging whether any role is worth its cost; that depends on the contract and the evidence a buyer can get.
| Party | What it adds | How it can be paid | Where a buyer finds it in the record |
|---|---|---|---|
| Agency or trading desk | Planning, buying, reporting and the operation of DSP seats | A fee or commission set in the agency contract | The agency contract and invoices |
| DSP | Bidding, targeting, frequency and budget control across many exchanges | A platform fee set in its contract | The DSP contract and log-level reports |
| Data or curation partner | Audience or contextual data, or a packaged set of inventory | A data or curation fee, charged to the buyer or paid by the seller side | Deal paperwork; the Deals API curator field where supported |
| SSP or exchange | The auction, floors, blocks, deal setup and payment to the seller | A share of the clearing price | ads.txt, sellers.json and the SupplyChain object |
| Reseller, network or sales house | Sales and operations for publishers that do not run their own | A margin or a revenue share agreed with the publisher | RESELLER lines, INTERMEDIARY entries and an extra schain node |
| Header wrapper and ad server | The page side auction among exchanges and the final choice of ad | A license or service fee paid by the publisher, where one applies | Can be invisible to the buyer; a wrapper can be listed as an ads.txt system |
| Publisher | The content, the audience and the ad slot | What remains of the price after every share above | The site's ads.txt and its PUBLISHER entries in sellers.json |
The ads.txt 1.1 specification (opens in a new tab) treats the selling roles alike: its first field is the domain of the SSP, exchange, header wrapper or other system bidders connect to. Buyer side roles never appear in the publisher's file. See the ad server and header bidding guides for the publisher side tools.
Where do fees enter the supply chain?
Fees enter in two ways. On the buyer side they are set in contracts: the agency agreement and the DSP agreement say what each keeps. On the seller side they can be shares of the price, taken as money passes each hop. OpenRTB 3.0 notes that latency and successive revenue shares tend to limit how many exchanges can be chained.
| Fee point | What the document says | Document |
|---|---|---|
| Auction and tech fees | Some auctioneers apply deal discounts or tech fees to bids; how they are applied must be consistent and transparent, and applying fees before the auction (net bidding) is encouraged | MRC Auction Transparency Standards (opens in a new tab), January 2026 |
| Monetization manager | Generally governed by a revenue sharing agreement in which the manager is paid a percentage of the inventory it sells | ads.txt 1.1 implementation guide (opens in a new tab), August 2022 |
| Curation | The deal can report its curation fee type: percentage of spend, flat fee, CPM, no fee or undisclosed; the type, not the amount | Deals API 1.0 (opens in a new tab) |
Which parties appear in the SupplyChain object?
Only some of them. The SupplyChain object specification (opens in a new tab) says the full chain of nodes represents all entities involved in the direct flow of payment for inventory, and that future versions may also include entities involved in the transaction but not in payment. Each node carries hp, which says whether it handles payment; for version 1.0 the specification says it should always be 1. The last node is the entity sending the bid request.
| Party | Node in schain? | Reason in the specification |
|---|---|---|
| Publisher's own seller account | Yes, first node in a complete chain | The first node represents the owner of the site, app or other medium |
| Each SSP, exchange or reseller that resells the request | Yes, one node each | A reseller must append its node; copying the chain without it is invalid |
| Header wrapper | Only when it is the system that sells and is paid | The asi field names the SSP, exchange or header wrapper bidders connect to |
| Data or curation partner | No, unless it is also a paid seller in the flow | Version 1.0 lists only entities in the flow of payment |
| DSP, agency and advertiser | No | They are on the receiving side; the chain ends with the entity sending the request |
OpenRTB 2.6 places the chain next to two other fields in the Source object. The OpenRTB 2.6 specification (opens in a new tab) defines fd as the entity responsible for the final impression sale decision, 0 for the exchange and 1 for an upstream source, and tid as a transaction ID that must be common across all participants in the request. Together they show who made the last decision and let a buyer join copies of one impression that arrive through different paths. The supply chain object guide explains each node field.
How does a curated deal change the chain?
A curated deal adds a role, not necessarily a hop. The Deals API separates three parties: the origin, the system where the deal is first entered and which receives bid responses for it, typically an SSP; the curator, the business that packaged the inventory, technology or data; and the seller, the business that contracted with the buyer. One company can hold all three roles, or three companies can. The specification says the API adds transparency into curated deals that is not currently available in the bid stream.
OpenRTB 3.0 adds a rule about how far a deal travels. Each entity brokers and executes deals among its directly connected supply and demand partners, and no other entity has any obligation under OpenRTB to extend or propagate those deals further up or down the chain. If inventory reaches the deal's exchange through a reseller, the deal sits on top of that resold path, and the SupplyChain object still shows it.
Tracing the chain behind a curated deal
- Name the three roles. Get the origin system, the curator and the seller in writing, by company and domain.
- Ask how the curator is paid. Note the fee type, and whether it comes out of the media price or the publisher's share.
- Get the domain list if the deal is static. Compare it with the sites the client approved.
- Check the paths for each domain. Confirm each site authorizes the origin system's seller account in ads.txt, directly or through a named reseller.
- Read live bid requests. Confirm the deal ID arrives with a complete SupplyChain object and no unexpected nodes.
What does a mapped supply chain look like on a real plan?
Fictional example
A self storage operator in eastern Ontario
A fictional self storage company with sites in Ottawa and Kingston wants display ads beside moving guides, home renovation and local news content, in English and French. Its agency is offered a curated deal by a data partner and asks the planner to map every company between the client's budget and the pages before signing.
On the buyer side the map is short: the agency's trading desk, one DSP seat, and the data partner, which is named as curator and charges a CPM type fee. On the seller side the planner reads the ads.txt file of each site in the deal. Most list the origin SSP as DIRECT. Three local news sites reach that SSP only through a regional sales house, so their requests carry two schain nodes.
The planner keeps the sales house sites, because each site's ads.txt declares the sales house and its sellers.json names the publishers, and notes in the deal sheet which sites run on a resold path. The trading desk will sample bid requests in week one to confirm no other nodes appear.
Which links in the chain can PlacementGraph check before a deal?
Frequently asked questions
Is the agency part of the programmatic supply chain?
Yes, as a buyer side party, though it never appears in seller files or in the SupplyChain object, which describe who sold an impression. The agency's role and fees are set out in its contract with the advertiser, which is where a client looks to see what the agency keeps.
Does a shorter supply chain always cost less?
Not always. A reseller hop can take a share, so a direct path can leave more of the price for the publisher. But a direct path can carry its own platform and data fees, and a reseller can be the only route to a site. Compare paths with log-level data, not with node counts alone.
What is the pchain field in a bid request?
In OpenRTB 2.6, pchain sits in the Source object next to schain. The specification defines it as a payment ID chain string containing embedded syntax described in the TAG Payment ID Protocol version 1.0. It is a recommended field, not a required one, so a request can leave it empty.
Does the DSP appear in the SupplyChain object?
No. The specification says the last node represents the entity sending the bid request, a seller side system such as an SSP or exchange. The DSP receives and reads the chain without adding itself, so buyer side parties are traced through contracts and DSP logs.
Sources
- OpenRTB 3.0 specification (opens in a new tab)IAB Tech Lab
- OpenRTB 2.6 specification (opens in a new tab)IAB Tech Lab
- OpenRTB SupplyChain object (opens in a new tab)IAB Tech Lab
- ads.txt Specification Version 1.1 (opens in a new tab)IAB Tech Lab
- ads.txt 1.1 Implementation Guide (August 2022) (opens in a new tab)IAB Tech Lab
- Deals API version 1.0 (opens in a new tab)IAB Tech Lab
- Digital Advertising Auction Transparency Standards (January 2026) (opens in a new tab)Media Rating Council
- ANA Programmatic Transparency Benchmark Reveals Widening Gap Between Top and Bottom Advertisers (Q1 2026) (opens in a new tab)ANA, May 27, 2026
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.