XDRIP and XECHO card: Fake plays, real royalties. Streaming fraud and the shared royalty pool, with a timeline from the IFPI initiative on 14 September to Copyright Office comments due on 23 November.
Streaming Platform

Fake Plays, Real Royalties: Streaming Fraud and the Shared Pool

A prison sentence and a Copyright Office inquiry put streaming fraud on the record. How fake plays drain a shared royalty pool, and what auditable payouts fix.

7 min read

On 6 October, a federal judge in New York sentenced a North Carolina man to 18 months in prison for a streaming fraud scheme that ran from 2017 to 2024. The next day, the U.S. Copyright Office opened a public inquiry into music streaming fraud. Together they mark a shift: what the music business long treated as a platform moderation problem is now a matter for prosecutors and policymakers.

For anyone building music infrastructure, the details are worth reading closely. They show how fraud really works, who pays for it, and which parts of the problem better record-keeping can solve.

What the case shows

According to the U.S. Attorney's Office for the Southern District of New York, the scheme had three steps. The defendant created thousands of fake accounts on major streaming services, used software to make those accounts stream songs he controlled around the clock, and collected the royalties. At times he ran as many as 10,000 bot accounts at once. To avoid the obvious red flag of one track with impossible numbers, he spread the plays across a very large catalog, and he built that catalog with AI: hundreds of thousands of generated songs, streamed billions of times. In his own words, quoted by prosecutors, he needed "a TON of songs fast" to get around the platforms' anti-fraud policies.

The result was more than $8 million in royalties. The court ordered forfeiture of $8,091,843.64.

The most important sentence in the press release is not about the defendant. It is about the payment model: "Royalty payments are made proportionately to musicians and songwriters from a pool of funds." That is why streaming fraud is not a victimless trick played on a large platform. Under pro-rata payouts, every fake play takes a share of a fixed pool, and that share comes out of the payments owed to artists whose listeners are real.

Washington starts asking questions

The Copyright Office notice of inquiry (Docket No. 2026-6), published on 7 October in response to a request from Representative Scott Fitzgerald, makes the same point in policy language. It describes the pro-rata system, in which "the more a song is played on a streaming service, the more revenue that song's rightsholders will receive," and notes that this structure "can incentivize bad actors" to inflate plays. It lists the familiar methods: bot farms, click farms, playlist stuffing, account hijacking, and uploading copies or altered versions of other people's work.

The notice calls dilution of the royalty pool the primary harm, but it also names secondary ones that get less attention: distorted playlist and algorithm placement, and corrupted data that artists and venues use to decide when and where to tour. Fraud does not only take money. It also corrupts the numbers that the rest of the business relies on. Written comments are due by 23 November 2026, and reply comments by 21 December. Instructions are on the Copyright Office's policy page.

The industry response so far

The private sector is moving at the same time, mostly at two points: where music enters the system, and where plays are counted.

At the entry point, IFPI launched the Streaming Integrity Initiative on 14 September, backed at launch by the three major label groups and a long list of distributors. Participating distributors commit to five practices: verifying rights ownership and customer identities through Know Your Customer checks, vetting content for infringement, fraud and AI-related risks, acting against suspected fraud and repeat offenders, sharing intelligence where the law allows, and continuously measuring and improving their defenses.

At the counting point, the platforms are publishing more data. Deezer reported on 13 October that fully AI-generated tracks account for only 1 to 3% of its streams, but that up to 85% of the streams those tracks generated in 2025 were fraudulent, and that it excludes manipulated streams from royalty payments. On 20 October, Spotify said it has removed more than 75 million spammy tracks from its platform for serious or repeated violations, and that its 1,000-stream royalty threshold has become "a first line of defense" against content generated at scale. It also noted that "no single signal catches slop or spam on its own," and that AI detection "will only get harder as generative AI evolves."

Labels are filing takedowns at a pace that would have seemed absurd a few years ago. Music Week reported on 5 October that Sony Music had asked platforms to remove more than 260,000 AI-generated tracks by the end of September, up from 135,000 at the end of March. In May, a Sony executive put the possible share of fraudulent streams at somewhere between 5% and 10%, while admitting that "no one knows exactly."

That last admission is the core of the problem. Nobody can say with confidence how large the leak is.

Three questions every payout should answer

Seen from an infrastructure point of view, fraud resistance comes down to three questions that a royalty system must be able to answer for every payment:

  1. Who delivered this track, and what rights do they hold? This is the distributor layer that the IFPI initiative targets. A payout is only as legitimate as the claim of ownership behind it.
  2. Which plays counted, and why? This is detection: separating real listening from bots, farms and hijacked accounts. It is probabilistic by nature, and it is an arms race.
  3. How was the money calculated and where did it go? This is accounting: which pool, which share, which plays were excluded, and which rights holders were paid.

Most public debate focuses on the second question, because detection is where the drama is. But the first and third questions matter just as much, and they are the ones where design choices, not detection skill, make the difference. When rights claims are vague and payout calculations are closed, a fraudster only needs to slip past detection once. When the record of who owns what is clear, and the path from play to payment can be audited, fraud becomes easier to trace and money becomes easier to recover.

What a ledger can and cannot do

This is where we think blockchain records have a real but limited role, and it is worth being precise.

An on-chain record can establish, with a timestamp that cannot be quietly changed, who registered a work, what rights were claimed and how royalties are meant to be split. Payout logic written into a smart contract can make the calculation itself inspectable: the same inputs always produce the same split, and anyone with access to the record can check it. That speaks directly to the first and third questions.

What a ledger cannot do is tell a human listener from a bot. A fake play written to an immutable record is still a fake play, now permanently recorded. Detection, identity checks at upload and enforcement remain necessary, whatever the payment rail. We see on-chain records as a way to make the rights and accounting layers transparent, not as a replacement for the work platforms and distributors are doing on detection.

How we approach it at XECHO

XECHO is the music streaming platform we are building around fair royalties and direct artist monetization. It is in invite-only beta: access is by request, and our team reviews each request. XECHO is designed to record rights on-chain and to handle royalties through smart contracts. In the current beta, both of these run on testnet only; they are not live on mainnet and do not pay real royalties.

The cases of the past few weeks make the design goal concrete. The question an artist should be able to ask of any platform is not only "how many plays did I get?" but "which plays were counted, how was my share calculated, and where can I check it?" We think that should be answerable from the record itself.

XECHO is in invite-only beta. Access is by request at xecho.pro, and our team reviews each request.

Related Posts