Data Act B2B Data Sharing on FRAND Terms: The Contract and API Pattern for Data Holders

Under the EU Data Act, “we will share the data” is no longer a commercial concession you grant case by case. Where the law obliges you to share, it dictates the terms — fair, reasonable, non-discriminatory — and that turns a contract clause into an engineering commitment your API has to honour and evidence.

The Data Act, Regulation (EU) 2023/2854, became applicable on 12 September 2025. Early commentary fixed on connected-product user-access rights and on cloud switching. The provision that will quietly cost data holders the most engineering effort sits in Chapter III: the obligations that apply when you are required to make data available. The moment a sharing obligation exists, Article 8 says you must meet it on fair, reasonable and non-discriminatory terms and in a transparent manner. FRAND is not a negotiating posture here. It is a legal standard your systems have to satisfy and, when challenged, demonstrate.

When Chapter III actually bites

Chapter III does not invent a general duty to open your data to the market. It governs the terms once a sharing obligation already exists — where a user of a connected product directs you to share their data with a third party under Article 5, or where other Union or national law compels disclosure. So the first architectural question is not “how do we build the API” but “which of our data flows are in scope, and to whom”. If you have connected products in the field, or you sit in a sector where access mandates are emerging, you have candidates. The user-access rights on connected products are the most common trigger, and the recipient of a user’s instruction inherits the FRAND treatment the Act prescribes.

This is a data-lineage problem before it is an API problem: you cannot share fairly what you cannot identify, categorise and trace back to a lawful basis. Scope it too permissively and you have built an obligation you did not need; too restrictively and you are refusing lawful requests. Both are governance failures.

What “fair, reasonable and non-discriminatory” means in code

Non-discrimination is the requirement that has direct engineering consequences. Article 8 prohibits treating comparable categories of data recipients differently without objective justification. In practice that means you cannot give recipient A a richer feed, a faster interface or softer terms than recipient B in the same category, and you have to be able to show it. The evidence a regulator or an aggrieved counterparty will ask for is not your policy document. It is the record of what each requester was actually granted, and on what terms.

That record does not exist if sharing happens through ad hoc exports, a bilateral SFTP drop or a bespoke integration negotiated per deal. Each hand-off becomes its own snowflake, and you have no way of demonstrating that the fifth requester got the same deal as the first. The only defensible pattern is a single gateway through which all in-scope sharing flows, applying one policy, metering every access and writing an append-only log of who received what, when, in what format and under which terms.

Compensation is governed by Article 9. It must itself be non-discriminatory and reasonable, and it may include a margin. Where the recipient is an SME or a not-for-profit research organisation, compensation may not exceed the costs directly related to making the data available. And you must give the recipient the basis for the calculation in enough detail that they can check it against the Act. This is why metering is not optional plumbing: a cost-plus-margin charge needs a defensible measure of cost, which means counting requests, volumes and formats per recipient — the same telemetry that evidences non-discrimination.

The trade-secret problem the gateway has to solve

Mandated sharing does not require you to hand over your intellectual property wholesale. Trade secrets have to be identified and preserved, and the data holder may agree proportionate technical and organisational measures to protect them before disclosure. Only in narrow, evidenced circumstances may sharing be withheld altogether. The engineering consequence is that the gateway needs a classification layer: fields tagged as trade-secret-bearing are redacted, aggregated or transformed before they leave, according to the recipient’s category and the agreed measures, rather than filtered by hand each time. Doing this by manual review does not scale and does not produce consistent evidence. I have written separately on the redaction and classification discipline that keeps sharing from bleeding IP; the point for this pattern is that the classification has to be enforced at the gateway, not trusted to whoever runs the export.

Article 11 gives the complementary lever: technical protection measures against unauthorised use or disclosure once the data has left. Watermarking, usage constraints and the right to act on breach belong in the same design, so that “we protected the trade secret” is a control rather than an assertion.

The pattern, concretely

A single request handler carries the FRAND obligation. It authenticates the requester, resolves their category, checks the entitlement, meters and logs the access, and applies the classification-driven redaction before the payload leaves. The log is the evidence; the policy table is the non-discrimination guarantee; the redaction map is the trade-secret safeguard.

# Data-sharing gateway: one policy, metered access, trade-secret redaction.
# Every in-scope Data Act request flows through here so that fair,
# non-discriminatory treatment is enforced centrally and evidenced.

from datetime import datetime, timezone

def handle_share_request(requester, dataset_id, fmt):
    # 1. Resolve the recipient's category. Comparable categories must be
    #    treated alike (Art. 8): the tariff and feed come from the table,
    #    never from a per-deal negotiation.
    category = resolve_category(requester)                 # e.g. "sme", "commercial"
    terms = SHARING_POLICY[category]                       # tariff, rate limit, field set

    # 2. Check the lawful basis for THIS dataset and recipient.
    if not has_entitlement(requester, dataset_id):
        raise Forbidden("no sharing obligation or authorisation for this dataset")

    # 3. Enforce the agreed rate limit uniformly within the category.
    if over_rate_limit(requester, terms["rate_per_day"]):
        raise TooManyRequests("category rate limit reached")

    # 4. Redact trade-secret-classified fields per the agreed measures
    #    before anything leaves the boundary (Art. 8(6) safeguards).
    record = load_record(dataset_id)
    shared = redact(record, classification="trade_secret",
                    allowed_fields=terms["field_set"])

    # 5. Meter for compensation and evidence. Compensation must be
    #    reasonable and its basis disclosable (Art. 9), so we count
    #    volume and format per recipient.
    units = measure_units(shared, fmt)
    charge = terms["unit_cost"] * units + terms["margin"](category, units)

    # 6. Append-only audit line: this is the non-discrimination evidence.
    AUDIT_LOG.append({
        "ts": datetime.now(timezone.utc).isoformat(),
        "requester": requester.id,
        "category": category,
        "dataset": dataset_id,
        "fields": sorted(shared.keys()),
        "format": fmt,
        "units": units,
        "charge": charge,
        "policy_version": SHARING_POLICY["_version"],
    })

    return serialise(shared, fmt), charge

The policy version stamped on every log line matters more than it looks. When you change a tariff or a field set, you want to prove which recipients were served under which version, so that “we changed the terms for everyone at once” is demonstrable. The same discipline underpins the cloud-switching obligations elsewhere in the Act: it consistently rewards firms that can show, from their own logs, that they did what the terms required.

Contract and API are one artefact

The contract states the terms; the gateway enforces them; the log proves both happened. Treating these as separate workstreams — legal drafts the data-sharing agreement, engineering builds an export — is exactly how firms end up with terms they cannot evidence and a pipe that discriminates without anyone intending it. The Commission has recommended non-binding model contractual terms under Article 41 to help draft the agreement; they are a useful starting point, but they describe obligations your systems still have to make true. The reasonable compensation position, too, is still settling as guidance develops, so the calculation basis you expose should be one you can revise without rewriting the pipeline.

The firms that will struggle are the ones who read FRAND as a clause and shipped an export script. When a recipient alleges they were treated worse than a competitor, or a supervisor asks how your compensation was calculated, a promise in a contract is not evidence. A metered, versioned, append-only log is. Build the log first, and the terms have somewhere to live.