This article explains how to manage granular rights settings using the per-Digital Service Provider (DSP) grid on the FUGA Interface. You will learn how to configure distinct ownership, monetization, and timing rules for individual platforms that support User-Generated Content (UGC). This replaces the legacy single-value model while fully preserving your existing asset delivery behaviors.
What You Can Configure
Rights Claim Policy on FUGA controls how each DSP that supports user-generated-content (UGC) rights claims handles matches against your assets.
Earlier versions of FUGA carried a single Rights Claim Policy value per asset that applied to every UGC-respecting DSP. Assets configured under the single-value model continue to work; see "Where the default values come from" for how their previous values appear on the per-DSP grid.
The per-DSP grid replaces the single-value control on the asset detail page. Each row represents one connected DSP that supports rights claims, allowing you to define a specific Policy value and a Timing value for every asset.
The available Policy options determine how matched content is handled:
| Value | What it does |
|---|---|
| Monetize | Claim ownership and monetize matched user-generated content. |
| Block | Claim ownership and block matched user-generated content. |
| Report | Claim ownership without monetizing or blocking. Used for analytics. |
| None | Send no rights claim for this DSP. |
The available Timing options determine when the policy takes effect:
| Value | What it does |
|---|---|
| Apply policy immediately | The Policy applies as soon as the asset is registered with the DSP, before any consumer-facing visibility (which is gated separately by the release date). |
| Apply policy on release date | No rights claims are processed for this asset on the DSP until the official release date. The Policy applies from the release date forward. |
| Block until release date, then apply policy | FUGA claims ownership and blocks matched user-generated content until the release date. The Policy applies from the release date forward. The asset's streaming availability is governed separately by the release date itself. |
Valid Policy + Timing combinations.
The FUGA Interface dynamically restricts choices to valid combinations to prevent errors (such as selecting a block timing for a non-blocking policy).
| Policy | Apply policy immediately | Apply policy on release date | Block until release date, then apply policy |
|---|---|---|---|
| Monetize | ✅ | ✅ | ✅ |
| Report | ✅ | ✅ | ✅ |
| Block | ✅ | ✅ | ❌ |
| None | ✅ | ❌ | ❌ |
Configuration Examples and Scope
Policy and Timing are configured strictly at the asset level. The chosen parameters apply to every product the asset belongs to (such as a single, an album, or a compilation). It is not possible to establish different values for the same asset across different product packages.
An example setup for a single asset across multiple platforms might appear as follows:
| DSP | Policy | Timing |
|---|---|---|
| YouTube Content ID | Monetize | Block until release date, then apply policy |
| Meta | Report | Apply policy on release date |
| TikTok | Block | Apply policy immediately |
Two direct filters determine which platforms appear on your asset grid:
You must be connected to the DSP (an active distribution arrangement is in place).
The DSP must respect rights claims.
Because each platform features unique capabilities, a DSP that only supports monetization and reporting will hide the options for Block or None inside the selection dropdown.
Default Values and Legacy Migration
For assets originally configured under the legacy single-value model, the per-DSP grid is automatically seeded with the exact per-DSP equivalent of your previous choice. FUGA has already executed these platform-specific mappings behind the scenes; this interface update simply makes those mechanics visible.
This transition ensures that:
Delivered behavior is completely preserved. No changes occur until you manually edit a value.
The defaults explain themselves. If a DSP shows Monetize with timing Apply policy on release date as the default, that is exactly what the asset's single value was producing for that DSP.
Per-DSP capability is respected. If a DSP only supports two of the four Policy values, the default is the DSP's nearest equivalent to the asset's single value.
To discuss migrating your ingestion delivery feeds to the updated per-DSP model, please contact your FUGA representative or reach out via our support channel.
How to Configure Rights Claim Policies
To update your parameters manually via the FUGA Interface:
Open the asset. Navigate to the asset detail page for the asset you want to configure.
Open the Rights Claim Policy section. The single-value control is replaced by a grid. Each row is one of the DSPs you are connected to that supports rights claims.
Pick a Policy and a Timing per DSP. Select your desired Policy and Timing values from the dropdown menus on each DSP row.
Save.
The change persists immediately. The next time the asset is delivered to that DSP, the updated values are used.
Ingestion and API Integration
If you manage your catalog directly within the FUGA Interface, the per-DSP grid serves as the source of truth and requires no workflow adjustments.
However, if you deliver content using other ingestion methods—such as an Application Programming Interface (API), Extensible Markup Language (XML), or Digital Data Exchange (DDEX) ingestion—please note the following system behaviors:
Legacy Formats and Global Policies: Older delivery formats continue to operate on the single-value model. Per-DSP Policy and Timing values are only supported when delivering via the v3 API or the updated per-DSP ingestion paths.
Ingestion Overwrites: If you manually customize an asset's grid in the FUGA Interface and subsequently re-ingest that asset using a legacy single-value delivery path, your manual changes will be overwritten. The system will map the incoming single value across all connected platforms, replacing your custom settings.
Synchronizing Ingestion and Interface Updates: To manage assets using both manual updates in the FUGA Interface and automated delivery without data conflicts, you must migrate to the per-DSP ingestion path. On this updated path, the FUGA Interface and your ingestion data utilize the same system model, ensuring that the most recent update takes precedence.
Frequently Asked Questions
What happens to assets that had a global Policy set before per-DSP support was available?
The legacy single-policy value is preserved and dynamically mapped to every DSP that supports rights claims. The asset keeps its existing behavior. You see your previous choice reflected on every DSP row in the per-DSP grid.
Can I still set a single value that applies to all DSPs?
Not directly. There is no global assignment tool in the grid today; each row must be adjusted independently. Additionally, you may not be able to use the same value across every DSP, because each DSP only accepts the Policy and Timing options it supports. If one DSP in your grid does not support Block, you cannot set Block for that DSP.
Assets carried over from the single-value model are seeded with the per-DSP equivalent of that value on every DSP row, so they start from a coherent single-intent state without needing to be set by hand.
Which DSPs honor Policy + Timing settings, and do they all support the same options?
The grid filters by two rules: you are connected to the DSP, and the DSP respects rights claims. Of the DSPs that pass both filters, each one has its own subset of allowed Policy and Timing options. What appears in the dropdowns varies by DSP. The FUGA Interface is the source of truth for which DSPs appear and which options are valid for each.
Why does DSP X only show two Policy options when DSP Y shows four?
Each platform defines its own supported capabilities for handling User-Generated Content (UGC). The FUGA Interface dynamically updates to reflect these rules, ensuring that you can only select the values that the specific platform is capable of processing.
Can I set different policies per territory?
Not at this time. Territory-specific policy splits are outside the scope of this feature. The per-DSP model applies one Policy value and one Timing value per asset per platform, on a global basis.
Can I set asset-bundle policy templates (one template applied to many assets)?
Not today. Per-asset is the only level of granularity.
Can I set a different Policy or Timing for the same asset depending on which product it appears in?
No. Policy and Timing are configured strictly at the asset level. If an asset is included in multiple products (such as a single, an album, or a compilation), the same values are communicated to the DSPs every time the asset is delivered. Editing the values once on the asset detail page will propagate the changes across all associated products.
Can I update Policy or Timing on an asset after delivery?
Yes. Manual updates made within the FUGA Interface write directly to your per-DSP records. The modified values will take effect the next time the asset is delivered or updated on that platform. If you also deliver content via automated feeds, please review the ingestion behaviors outlined in the "Delivering via API or XML Ingestion" section.
What happens when a legacy single-value re-ingest hits an asset I've customized in the UI?
The incoming single-value ingestion will overwrite the custom per-DSP parameters previously configured in the FUGA Interface.
The system will map the legacy single value to its standard platform-specific equivalents and update the grid accordingly. Following the re-ingest, the asset will be governed entirely by those mapped values rather than your manual adjustments.