Representativeness Under the EMIR 3.0 AAR: Instrumenting Your Clearing Data

The representativeness obligation under the EMIR 3.0 Active Account Requirement reads like a clearing rule. It is really a data rule wearing a clearing rule’s clothes, and the firms that treat it as the latter are the ones that will struggle to evidence it.

EMIR 3, Regulation (EU) 2024/2987, came into force on 24 December 2024 and introduced the Active Account Requirement (AAR) at Article 7a of EMIR. In-scope counterparties above the clearing thresholds must hold an operational account at an EU central counterparty for a defined set of contracts: euro- and Polish zloty-denominated over-the-counter interest rate derivatives, and euro-denominated short-term interest rate derivatives. Holding the account is the easy part. The hard part is the representativeness limb: your EU account must carry a representative sample of your activity, not a token trade parked there to satisfy an auditor. That is a claim about the shape of your portfolio, and proving it is a data-engineering task before it is a compliance one.

What “representative” actually means here

The detail lives in the regulatory technical standards. ESMA published its final report on 19 June 2025, and the standards were adopted as Commission Delegated Regulation (EU) 2026/305, published in the Official Journal on 6 February 2026 and in force from 26 February 2026. Verify the operative text against that instrument rather than the summaries, including this one.

The mechanism is a grid. For each class in scope, the RTS defines a finite set of subcategories formed by combining a maturity range with a trade-size range. Within that grid, a counterparty has to clear through its EU active account in the most relevant subcategories for its own activity over a reference period, and to do so with a minimum number of trades per subcategory. The baseline is five trades per most relevant subcategory per reference period, reduced to a single trade where the contracts subject to the clearing obligation exceed half of the counterparty’s activity in that class. Two thresholds bound the population: counterparties with an aggregate outstanding notional below EUR 6 billion, excluding client clearing, fall outside the representativeness obligation altogether, and those with the largest books, above EUR 100 billion, must cover a wider spread of subcategories than smaller in-scope firms.

Two features of that design matter for how you capture data. First, only proprietary activity counts; client clearing volumes are excluded from the numerator and the denominator. Second, “most relevant” is defined relative to your own portfolio, so you cannot answer the question without first measuring your whole book. Representativeness is a ratio, and you own both halves of it. The operational conditions and the reporting template that sit alongside this obligation are covered in our reading of the AAR reporting template; this piece is about the layer underneath, the data that has to feed it.

The data model this obligation implies

To evidence representativeness you need, for every in-scope trade, a small set of attributes captured reliably at booking: the class, the tenor from which the maturity band is derived, the notional from which the size band is derived, a flag for whether it was cleared at the EU active account, and a flag distinguishing house from client activity. None of that is exotic. What defeats firms is that these attributes are scattered across booking systems, clearing gateways and reporting stores that were never designed to be reconciled against one another, so the same trade carries a different tenor in two places and no agreed size band anywhere.

The subcategory assignment is the part to get right early, because it is a modelling decision, not a lookup. Maturity bands and size bands have to be assigned by the same deterministic logic the RTS uses, applied identically across every source, and pinned to the version of the standards in force for the reference period. If you let two teams band tenors differently, your coverage numbers will not reconcile and you will not know which figure to defend. This is the same discipline that governs any regulated dataset: the taxonomy is fixed, the lineage from raw field to reported figure is traceable, and the assignment logic is testable. It is the argument we made about training-set representativeness under AI Act Article 10, and it transfers directly: a sample you cannot characterise is a sample you cannot defend.

The query that evidences coverage

Once the attributes are clean, the evidence is a single aggregation: for each subcategory over the reference period, how much of your proprietary activity ran through the EU account. The query below is deliberately plain, because the point of an evidence artefact is that a supervisor, an auditor and your own risk team can all read it and get the same answer.

-- Representativeness coverage over a rolling reference period.
-- One row per subcategory (class x maturity band x size band), showing
-- how much of your relevant proprietary activity ran through the EU
-- active account. Client clearing is excluded by design.

WITH scoped AS (
    SELECT
        asset_class,          -- 'EUR_IRD', 'PLN_IRD', 'EUR_STIR'
        maturity_band,        -- assigned from tenor by the RTS grid logic
        size_band,            -- assigned from notional by the RTS grid logic
        notional_eur,
        cleared_at_eu_ccp     -- booked to the EU active account?
    FROM clearing_trades
    WHERE trade_date >= :period_start
      AND trade_date <  :period_end
      AND is_house_trade = TRUE   -- proprietary activity only
)
SELECT
    asset_class,
    maturity_band,
    size_band,
    COUNT(*)                                    AS total_trades,
    SUM(notional_eur)                           AS total_notional_eur,
    COUNT(*) FILTER (WHERE cleared_at_eu_ccp)   AS eu_cleared_trades,
    ROUND(100.0 * COUNT(*) FILTER (WHERE cleared_at_eu_ccp)
          / NULLIF(COUNT(*), 0), 1)             AS eu_share_pct
FROM scoped
GROUP BY asset_class, maturity_band, size_band
ORDER BY total_notional_eur DESC;

Rank the output by notional and the most relevant subcategories rise to the top. The eu_cleared_trades column against the required minimum is your coverage test, subcategory by subcategory. Run the same query as a pandas groupby if your trade data lives in a warehouse notebook rather than a database; the logic is identical and so is the artefact it produces. Store the result set with the parameters that generated it, because the defensible thing is not the number, it is the reproducible number.

Where the sample goes thin

The failure modes are predictable. A firm clears the required trades but concentrates them in one or two convenient subcategories, leaving the grid sparse where its real activity sits; the coverage looks fine in aggregate and fails the moment anyone groups it the way the RTS does. Client trades leak into the house count and inflate the sample with volumes that do not qualify. Maturity banding drifts between systems, so a subcategory that looks covered in the booking system looks empty in the reporting store. And the reference period is misaligned, so the sample being reported does not match the window being measured.

The reporting cadence gives you a fixed cadence to catch these. Submissions fall every six months, on 31 January and 31 July, against a rolling reference period, with the first submission due on 31 July 2026 covering activity from 25 June 2025. That is the deadline to instrument for, and it is close. Confirm the exact dates and windows against the current ESMA templates, which have been revised since first publication.

None of this is difficult engineering. It is disciplined capture: agree the banding logic once, apply it everywhere, keep the lineage from booking field to reported figure intact, and run the coverage query continuously rather than the week before the return is due. A thin or skewed sample will not survive being grouped the way a supervisor groups it, and by then the trades have already been booked. Representativeness is decided at the point of capture, not at the point of reporting.