The EMIR 3.0 Active Account Requirement: Operational Conditions and the Reporting Template

The Active Account Requirement is not an attestation you sign once. It is a data obligation you have to be running continuously, and the reporting template ESMA issued in April 2026 makes that impossible to fudge at the deadline.

Most coverage of the Active Account Requirement (AAR) treats it as a policy question: should your firm hold an account at an EU central counterparty, and how much should you clear through it. That framing is a year out of date. EMIR 3.0 — Regulation (EU) 2024/2987 — entered into force on 24 December 2024, the AAR became applicable on 25 June 2025, and the conditions were fixed by Commission Delegated Regulation (EU) 2026/305, published in the Official Journal on 6 February 2026. In April 2026 ESMA released the reporting templates and instructions. The policy debate is settled. What is left is an engineering problem: capturing the right data, in the right shape, from your clearing activity, and populating a template that a competent authority will read.

The first submission is due 31 July 2026, covering the period from 25 June 2025 to 30 June 2026. After that, reporting settles into a semi-annual cycle on 31 January and 31 July each year, each filing covering a twelve-month reference period. If you are in scope and you have not built the capture yet, you are already reporting on a period that has closed.

What the template actually asks for

ESMA’s package is not one form. It is a set of structured templates that together demand four distinct kinds of evidence:

1. Counterparty identification. Who you are, your identifiers, and your position in a group where clearing thresholds are assessed at consolidated level.
2. Activities and risk exposures. The aggregate figures that establish whether and where you cross the thresholds, including subsidiary-level data for consolidated groups.
3. Representativeness compliance. Trade counts by subcategory, trade-size band and maturity range, at both the third-country (Tier 2) CCP and the EU CCP.
4. Operational conditions. A declaration that the account meets the conditions in the Delegated Regulation, backed by supporting evidence.

Read those four as data feeds, not as sections of a document. Each one draws from a different system — your reference data, your position and threshold monitoring, your clearing records, and your operational documentation — and each one has to reconcile with the others. The template is the join. If those systems do not currently agree with one another, the reporting exercise is where that disagreement becomes visible to a supervisor.

Operational conditions are a systems claim, not a sentence

The operational conditions are the part firms are most tempted to treat as boilerplate, and the part where a declaration is easiest to make and hardest to defend. The Delegated Regulation asks you to show that the account is permanently functional: contractual arrangements, policies and procedures, IT connectivity and internal systems all in place, with resources capable of supporting high-volume clearing at short notice. The touchstone is a stress scenario — the ability to absorb a sharp increase in clearing activity, of the order of a threefold rise, such as an abrupt shift away from a Tier 2 CCP — and to keep clearing new in-scope trades under both normal and stressed conditions.

“Permanently functional” is a claim about running systems. The evidence a supervisor will expect behind the declaration is concrete: the clearing agreement, proof of live IT connectivity to the EU CCP, and written capacity statements from the CCP or clearing member confirming the ability to handle a large volume increase, alongside stress-test results. A counterparty that clears at least 85% of its relevant activity at EU CCPs is treated differently on the operational conditions — but that is a threshold you have to be able to evidence with data, not assert. If you cannot produce the connectivity logs and the capacity confirmation on the day, you have signed a declaration your systems cannot stand behind.

Representativeness is a rolling count, not a snapshot

Representativeness is where the reporting gets genuinely computational, and where a point-in-time attestation collapses. You are not asserting that you cleared something through the EU account. You are proving that you cleared a representative spread of your activity: across the most relevant subcategories, defined by maturity range and trade size, in each in-scope class. The instructions set the shape — broadly, five subcategories per euro-denominated OTC interest rate class, four for euro short-term interest rate derivatives, and one for the Polish zloty class — and a minimum of five trades per relevant subcategory per reference period, measured on an annual average, dropping to one where a subcategory already accounts for more than half of your trades in that class.

Two details make this a continuous data exercise rather than a year-end assembly. First, the “most relevant” subcategories are the ones where you clear the most at the Tier 2 CCP — so the subcategories you must satisfy at the EU CCP are defined by activity you may not control until it has happened. Second, the reference period varies by class and by portfolio size: shorter windows for the largest books, longer ones below the notional cut-offs, and a twelve-month window for the zloty class regardless. You cannot compute this correctly unless you have been tagging every cleared trade with its class, subcategory, CCP type and timestamp all along. Instrumenting the clearing data for exactly this calculation is the work; I have written separately on how to structure that capture.

Generating the template from clearing data

The representativeness template is the one worth automating first, because it is the one that cannot be reconstructed by hand at the deadline. The core logic is small: rank the subcategories by Tier 2 activity, count EU-cleared trades in each, normalise to an annual average, and apply the minimum-trade test. Everything else is plumbing to your trade store.

# aar_representativeness.py
# Populate the ESMA AAR representativeness template from cleared-trade records.
# Ranks subcategories by Tier 2 activity, then tests EU clearing against the
# minimum on an annual-average basis. Verify shapes against the RTS and the
# ESMA instructions before filing.

from collections import defaultdict
from dataclasses import dataclass

MIN_TRADES = 5            # minimum cleared trades per relevant subcategory
DOMINANCE_FRACTION = 0.5  # drops the minimum to 1 above this share of the class

# Number of "most relevant" subcategories to report, per in-scope class.
SUBCATS_PER_CLASS = {
    "EUR_OTC_IRD": 5,
    "EUR_STIR": 4,
    "PLN_OTC_IRD": 1,
}

@dataclass
class Trade:
    trade_id: str
    asset_class: str   # e.g. "EUR_OTC_IRD", "EUR_STIR", "PLN_OTC_IRD"
    subcategory: str   # maturity x size bucket, per the instructions
    ccp_type: str      # "TIER2" or "EU"

def most_relevant(trades, asset_class, n):
    # Subcategories where the counterparty clears the most at the Tier 2 CCP.
    counts = defaultdict(int)
    for t in trades:
        if t.asset_class == asset_class and t.ccp_type == "TIER2":
            counts[t.subcategory] += 1
    return sorted(counts, key=counts.get, reverse=True)[:n]

def minimum_required(class_total, subcat_tier2):
    # One trade suffices where the subcategory is more than half the class.
    if class_total > 0 and subcat_tier2 / class_total > DOMINANCE_FRACTION:
        return 1
    return MIN_TRADES

def build_rows(trades, asset_class, periods):
    # 'periods' normalises the reference window to an annual average; it
    # varies by class and portfolio size, so pass the right value per class.
    n = SUBCATS_PER_CLASS[asset_class]
    class_total = sum(1 for t in trades if t.asset_class == asset_class)
    rows = []
    for sub in most_relevant(trades, asset_class, n):
        tier2 = sum(1 for t in trades if t.asset_class == asset_class
                    and t.subcategory == sub and t.ccp_type == "TIER2")
        eu = sum(1 for t in trades if t.asset_class == asset_class
                 and t.subcategory == sub and t.ccp_type == "EU")
        annual_avg_eu = eu / periods
        needed = minimum_required(class_total, tier2)
        rows.append({
            "asset_class": asset_class,
            "subcategory": sub,
            "trades_tier2": tier2,
            "trades_eu": eu,
            "eu_annual_average": round(annual_avg_eu, 2),
            "minimum_required": needed,
            "met": annual_avg_eu >= needed,
        })
    return rows

This is deliberately thin. The value is not the arithmetic; it is that the calculation runs against your live trade store on any date, so you know in March whether a subcategory is short, not on 30 July. The met flag is your early warning: a subcategory that is failing with two months of the reference period left is a subcategory you can still fix by clearing into it.

Build the capture now, not the report later

The recurring mistake with obligations like this is to treat the deadline as a document deadline and to start writing in July. The AAR does not work that way. By the time the reference period has closed, the trades that would have made you representative either happened or they did not; there is no retrospective clearing. Proving an active, operationally ready EU clearing account is a continuous data exercise, and the template is simply the point at which that data is inspected. This is the same shift that DORA forced on operational-resilience evidence, where continuous reporting replaced the point-in-time board pack — the supervisor now expects the running record, not the year-end assertion.

So the action for an in-scope counterparty is not to schedule the filing. It is to instrument the accounts, the activity and the representativeness now, so that the 31 July submission is a query against systems that already hold the answer. Figures such as the notional cut-offs, the 85% operational threshold and the exemption below roughly EUR 6 billion in outstanding notional should be read straight from the Delegated Regulation and the ESMA instructions for your class, not from memory. If you build the capture to produce the template on demand, the deadline is an export. If you do not, it is a reconstruction — and a reconstruction of clearing activity that has already stopped being changeable is the one report you cannot get right.