Skip to content

3. Data Products and Data Transactions

3.1 Introduction

Data is a foundational asset of the digital economy, driving productivity, competitiveness, and sustained economic development. They underpin innovation across sectors, enhance the quality and efficiency of public services, and accelerate scientific discovery.

In this context, seamless, trusted, and secure data flows—across borders, industries, and interoperable data spaces—are essential.

As transformative technologies such as artificial intelligence (AI) and the Internet of Things (IoT) continue to mature and scale, the strategic relevance of structured data exchange, governed data sharing, and reliable data transactions will further intensify.

In this perspective, Gaia-X Data Exchange Services address the need for a robust framework that enables Trusted Data Transactions (JT025009 - EN 18235-1:2026).

Enabling digital transformation as well as developing innovative services requires the right data at the right time, aggregating from multiple sources to produce valuable insightful information. However, within most organizations, data sharing is too often stalled by stakeholder resistance, data governance policies, lack of tools, and inability to address regulatory constraints:

  • For a Data Producer, personal and non-personal data sharing is often associated with a legal risk (e.g. personal data, as per GDPR, shared without the person’s consent), with an industrial risk (e.g. data including some intellectual property or commercial secret communicated to competitors) or with a reputation and image risk (e.g. data privacy shaming if shared data is misused), while there are barely any established local benefits for sharing data.

  • For a Data User, appropriate use and corresponding usage restrictions are rarely clearly, nor formally, stated or are expressed in a legal form which is cumbersome to check and is difficult to enforce automatically.

  • For an entity’s legal and compliance structures, data access and governance processes are often fragmented, and verifications of appropriate data usage are complex and labor intensive (i.e. checking that received data are used in a not-illegal way is complex).

This complexity often results in decisions that are overly risk averse, blocking data sharing with a “stop first and thoroughly assess” mechanism, preventing business opportunities from driving digital transformation and from grabbing competitive advantages.

Overcoming these resistances requires to establish reliable trust mechanisms throughout the data sharing process.

First, the original Data Rights Holders need to be able to express how their data shall be used, and they need confidence that these constraints will be duly applied.

Then, the Data Users need evidence that the data is genuine, and that the usage authorization is legitimate (i.e. that they are not illegally using the data).

Respectively, the Data Providers need evidence that the data consumers have the authorization to receive the data (i.e. providing the data is legal).

The Gaia-X Data Transaction concept and its operational model provide such mechanisms and enable data rights holders to control how their data are used and by whom (this is called data sovereignty). In addition, they provide mechanisms to facilitate and demonstrate compliance with the European regulations regarding data (GDPR and Data Act).

3.2 Data Product

Data is transacted between data providers and data users through data products which are “data sharing unit, packaging data and metadata , and any associated licence terms” (JT025009 - EN 18235-1:2026).

Data Products include, without being limited to, metadata describing the data product and data licence terms as defined by the data rights holder, or by the data provider authorised to do so.

Examples of information included in, or is associated with a data product are: - specific purposes the data product is intended for, - terms of usage, - legal terms, - commercial terms, - price, if any, - consent and authorisations

3.3 Data Transaction

The concept of a Data Transaction can be understood under the general remarks below (JT025009 - EN 18235-1:2026):

  • A data transaction can be related to a broad set of scenarios, including but not limited to: one-time data exchanges, data subscriptions, API-based data exchanges (pull or push), data streaming, “code2data”, “data2code”.
  • A data transaction, in order to materialise, as part of a data sharing process, requires a data provider, a data user and the data product being transacted.
  • Traceability of the data transaction contributes to enhancing transparency, providing accountability, improving security and meeting compliance requirements.
  • The technical transfer of – or access to – the data, takes place as a result of the data transaction.
  • In some cases, the data are transferred from the data provider to the data user. In other cases, the data do not move while access to the data is given to the data user.
  • Data transactions do not necessarily imply a commercial relationship between the data provider and the data user, and does not necessarily imply the payment of a fee by the data user to the data provider in order to access and use the data.
  • Each data transaction is “unique” indicating that it is treated independently from other data transactions.
  • Data transactions and data spaces are interconnected concepts. Data spaces provide a foundation for managing and facilitating trusted data transactions, enabling stakeholders to leverage data effectively while ensuring governance and compliance.

The concept of data transaction can be described with the conceptual model hereafter (JT025009 - EN 18235-1:2026):

Data Transaction Conceptual Model

Figure 3.1 - Scope of Data Transaction

The concept of a data transaction relates to the following three phases:

  • Granting rights and Publication of the Data Product which is a provisioning phase leading to the publication of metadata and data policies,
  • Discovery and negotiation which is the phase leading to an agreement (data sharing contract) between a data provider and a data user regarding a data product,
  • the Data exchange or sharing and Data Usage phase operationalising the data sharing contract through a Data Transaction which includes also the access and usage of the data product by the data user.

[!NOTE] Although the activities depicted in Figure 3.1 can be executed in the order as displayed, certain data transactions may skip activities or reiterate parts of the process.

3.4 Data Transaction Conceptual Model

Data Transaction Phases Figure 3.2 - Data Transaction phases

Data are furnished by Data Producers to Data Providers who compose them into a Data Product to be used by Data Consumers. Data Producers can be data owners or data controllers in the GDPR sense, or data holders in the Data Act sense – other kinds of Data Producers can be defined by different ecosystems.

A Data Product is described by a Data Product Description, which must be a valid Data Product Description according to the Data Product Ontology class and is stored in a (searchable) Federated Data Catalogue.

Data Product Descriptions contain the Metadata describing the data (scope, format, quality, etc.) using an ontology which is defined by the ecosystem and contain information describing the contractual and operational aspects of the Service Offering (cost and billing, technical means, service level agreement, etc.).

This conceptual model distinguishes between contractual agreements governing service delivery and those governing the rights to use the data. Accordingly, the contractual agreements governing a data transaction consist of a Data Access Contract (DAC) and, where applicable, one or more Data Usage Agreements (DUAs). Together, these agreements implement the Data Sharing Contract concept as defined in EN 18235-1.

Before using a Data Product, the Data Consumer negotiates and co-signs a Data Access Contract (DAC) with the Data Provider. This Data Access Contract is based on the Data Product Description and includes the service configuration elements and mutually agreed and enforceable Terms of Usage, resulting from potential negotiations. Hence, a Data Product Description constitutes a Data Access Contract template.

The Data Access Contract is a Ricardian contract: a contract at law that is both human-readable and machine-readable, cryptographically signed and rendered tamper-proof, and electronically linked to the subject of the contract, i.e. the data. The parties can (optionally) request this contract to be notarized in a federated Data Access Contract Store.

Note

A Data Access Contract is often organized in several parts: (i) an ecosystem-level contract agreed/signed by all participants of the ecosystem (sometimes called ecosystem policy scheme), (ii) a frame contract between the Provider and the Consumer defining the overall terms and conditions governing the contractual relationship for a set of services and (iii) an application contract specific to the ordered service.

After such a contract is agreed and signed by both the parties, the Data Consumer can start accessing the data (Data Access) and then using the data (Data Usage), realizing the Data Product Access Contract. The contract negotiation can lead to both parties agreeing on a Data Access Logging Service (these logs might also include information needed for billing, inc. service level details, even if billing is outside Gaia-X perimeter).

If a specific license is attached to some data in the Data Product, then the Data Product Description shall contain a Data License defining the usage policies for the data and, before Data Usage, the Data License shall be derived into a Data Usage Agreement (DUA) signed by the Data Rights Holder and by the Data Consumer. Data Usage Agreements are notarized by a Data Usage Agreement Notary (DUA Notary) and can be revoked at any time.

The signed Data Usage Agreement is communicated to the Data Provider, who must check that the DUA is not revoked (through the DUA Notary) and that the DUA constraints are fulfilled. This check must be done before each Data Usage delivery (i.e. each time the data access is requested by a Data Consumer, especially for recurrent data access).

This signed Data Usage Agreement gives (a) to the Data Consumer the legal authorization to use the data in accordance with the constraints specified by the Data Rights Holder and (b) gives to the Data Rights Holder the assurance that the Data Consumer commits to respect these constraints.

Note

The signature can be a digital signature (as for instance an eIDAS signature) or simply an electronic form (as a click on a “I agree” button in a specific screen provided by the DUA Notary).

The Data Usage Agreement concept is a general concept which addresses every kind of licensed data and hence encompasses also the concepts of Consent from GDPR and of Permission from the EU Data Act. In case of data liable to legal regulation (e.g. GDPR or Data Act), the Data Usage Agreement must contain all information required by the regulation (in particular the purpose of usage).

If the Data Product contains data from several Data Rights Holders, then a Data Usage Agreement shall be signed by each Data Rights Holder and all these signed Data Usage Agreements shall be communicated to the Data Provider before Data Usage.

Note

Data Acces Contract (DAC) and Data Usage Agreement (DUA) are different in terms of objectives and actors.

A DAC is established between a Data Provider and a Data Consumer. It focuses on service delivery : technical configuration, billing, SLA, termination clauses, etc.

A DUA is established between a Data Rights Holder and a Data Consumer. It focuses on the usage conditions of the data contained in the Data Product.

Data Product Conceptual Model

Figure 3.3 - Overall Data Transactions conceptual model

3.5 BPMN processes

The following diagrams describe the data transaction processes in BPMN terms:

Data Transaction BPMN processes

Figure 3.4 - Data Transaction BPMN processes

3.6 Data License and Data Usage Agreement

Data Usage Agreements enable Data Rights Holders to control how their data are used and by whom (this is called data sovereignty).

Data Licenses contain a set of constraints related to the authorized or forbidden usage of the data in the Data Product. Data Usage Agreements are usually derived from the Data License but might differ according to the result of the negotiation between the Data Rights Holder and the Data Consumer. Data Usage Agreements also include additional information related to the identity of the Data Consumer, the detailed purpose of the data usage, the duration of the agreement, etc.

Data Usage Agreements contain two sets of constraints: the Data Access Prerequisites, which are enforced by the Data Provider before delivering access to the data, and the Data Usage Constraints, which are outside the scope of the Data Provider and shall be respected by the Data Consumer when using the data. For instance, restricting data access to research laboratories with a specific ISO certificate can be enforced by the Data Provider while restricting data usage to research related to a specific disease is enforceable only by the Data Consumer.

To enable automated processing, Gaia-X mandates the use of Open Digital Rights Language (ODRL) from W3C to express Data License constraints (cf. https://www.w3.org/TR/odrl-model/) – using an ontology which will usually be defined by the ecosystem.

A Data License can be generic, for instance “I agree that my data are used by any non-profit licensed health laboratory with XYZ security level” or specific “My data can be used only with a specific DUA signed by me and including the identity of the data consumer and the explicit consent of the data usage.”

In the first case (generic license), a DUA signed by the Data Rights Holder is pre-notarized and there is no need for further communication with the Data Rights Holder before Data Usage: the DUA identifier can be stored in the Data Product Description and the Data Consumer just needs to sign it, notarize it and communicate the identifier to the Data Provider.

In the second case (specific license), the Data Rights Holder must be contacted (either by the Data Consumer or by the Data Provider) in order to fill the DUA and sign it.

More details are provided in the Data Usage Operating Models section.

3.7 Mapping of Gaia-X Concepts with EU Data Regulation Concepts

The following table maps the Gaia-X concepts with the concepts used within the different European regulations around data (GDPR and the EU acts on data - DxA):

European Regulations Concepts Gaia-X Concepts
data processor in GDPR Data Provider
data subject in GDPR / user in DxA Data Rights Holder
consent in GDPR / permission or authorization in DxA Data Usage Agreement
recipient in GDPR / DxA Data Consumer

The following diagram details these relationships (European regulations concepts (black color), Gaia-X concepts (blue color)):

Concept mapping Gaia-X vs EU regulations

Figure 3.5 - Mapping of Gaia-X Concepts with EU Data Regulation Concepts

Suggest a modification