How a disclosure is sized against what the market traded
Whether an event is inside information is a judgement. Whether it was material enough to reach your firm's own threshold is arithmetic - and it needs a denominator that is honest about which way it is wrong.
On this page
What this decides, and what it does not
It takes what your firm cleared in an auction, divides it by what each delivery period actually traded, and marks the periods reaching the share your disclosure policy treats as material.
Whether an event is inside information, and whether it must be published, remain your decisions. This screens for materiality; it does not make the call, and it produces no determination that anything should or should not have been disclosed.
Your inputs never leave the browser
The cleared volume and threshold you enter are held in the browser tab only. They are not sent to a server, not written to the URL and not stored, which is also why they do not survive a reload and why the page cannot be shared by link in the state you are reading it.
A position is the most sensitive thing a desk holds, and the only way to promise it is not retained is not to receive it.
Download CSV creates an assessment file in your browser containing every delivery period, your inputs, the threshold, coverage and source details. It includes computed price impacts and model error where available. A missing simulation stays marked as not computed. The download sends no positions to the server.
When a delivery day becomes assessable
The delivery-day picker reaches as far as the auction has published, not as far as today. Day-ahead for tomorrow clears in the early afternoon of the day before, around 12:15 UTC in winter and 11:15 UTC in summer, so from that moment tomorrow is the day the page opens on and the day the Latest button returns you to. GB clears earlier still: its hourly day-ahead auction publishes at 10:00 UTC in winter and its half-hour auction in the afternoon, and each is offered on its own clock rather than on the continental one.
Intraday auction 3 is the exception, and it is a fact about the auction rather than about the data. Its gate closes on the delivery day itself, so no result for tomorrow can exist today at any hour and the picker never offers one.
This matters because the disclosure decision does not wait. A position cleared in tomorrow's auction has to be sized while tomorrow is still ahead of you, and the arithmetic is available the moment the auction it is measured against goes public.
Our own copy of an auction does not arrive the instant it publishes, so for the delivery days the exchange still serves the page does not wait for it. Where our stored copy has no volume for the day, the table is read from the exchange at the moment you ask, and the publisher is the only thing standing between publication and the arithmetic. The exchanges serve today and tomorrow and refuse anything older, which is the same window the re-clear works in, so beyond it the stored copy is what answers.
If periods or market volumes are missing, Fetch from publisherchecks the selected market, auction and delivery day again, including when our stored copy is only partial. It appears only for supported sources while the delivery day can still be requested. The result reports whether usable market volumes came back; an empty or failed response keeps the existing assessment. Your positions and threshold stay in the browser. Imported positions remain attached to their original delivery timestamps, and newly recovered periods stay blank. Review period matches and durations after fetching, especially for MWh inputs. This reads public data for this assessment; it does not archive the day for future visits.
A delivery day with nothing on it says which kind of nothing it is. If the auction has not cleared, the page says so and gives the time it publishes, because nothing is missing. If it has cleared, is outside the window the exchange still serves, and we hold no rows, the page calls it a collection gap instead. Italy is read live from the exchange on every request and has no published schedule recorded here, so its empty day says only that the exchange returned nothing.
The four denominators, and which way each is wrong
There is no single “market volume” for a delivery period. Four denominators are available depending on what the publisher served, and each is wrong in a different, stateable direction. The console names which one answered and which way it biases your percentage - because a share is only as honest as what it was divided by.
- Buy and sell, published and sided
- Two figures for one interval, and neither is 'the' volume. The SIGN on your position picks which one you are measured against, so a sale and a purchase of the same size are genuinely different shares here. It is one auction's own cleared volume for one market area: the two sides differ by what crossed the zone's borders.
- Traded volume, one exchange's
- That venue's published figure for its own market area. Volume your firm cleared elsewhere in the same coupled area is in neither the numerator nor the denominator.
- The curve crossing, ours not the exchange's
- Used where no cleared volume was published. It is the crossing of the aggregated curves for the whole coupled area, so it runs roughly a tenth above any single exchange's traded volume: your share against it is biased LOW by about that tenth - the direction that UNDER-flags. A period reading just under your threshold deserves a second look. It cannot represent block orders, and has no buy/sell split, so the sign on your volume does not change the percentage.
- A shared order book
- Where an exchange publishes one merged book for every zone clearing at the same price, the crossing is that whole group's volume rather than one zone's. Your share is biased LOW wherever the zones were uncongested, again the direction that under-flags. The price is the zone's own either way, and a period where the zone was congested off carries its own book.
MW and MWh
The market publishes rates. MW is a rate averaged over each delivery period, so a share of published volumes is independent of how long a period is. MWh is energy per delivery period, and every figure is converted for you against that day's own period length - or against each period's own length, on a day whose periods are not all equal.
Equivalent positions have the same share in either unit. Select “Interpret input as” to match your report before entering positions. Changing it reinterprets the numbers already entered; it does not convert them. On a quarter-hour period, 100 MWh means 400 MW, so changing 100 from MW to MWh changes the assessed position fourfold.
Enter a flat signed position, paste one value per period, or import a CSV or TSV with period indices or delivery timestamps. Headers may name the position column MW or MWh; select the matching unit. ISO timestamps must include Z or a UTC offset, which distinguishes the repeated hour on an autumn clock change. On a clock-change delivery day, the ledger and simulation headings also show UTC offsets so both occurrences can be distinguished.
Zero is an entered position and is assessed as zero. Blank cells, unmatched timestamps and omitted periods remain unassessed. Invalid rows are reported by line; duplicate periods are excluded rather than choosing one position silently. Review the matched count and import issues before relying on the totals.
Periods needing review
The review queue orders volume mismatches first, then periods at or over your threshold, uncertain periods and near misses. Missing inputs or market volumes stay in the queue as incomplete assessments. A near miss has an upper share estimate reaching at least 90% of your policy threshold; this review aid does not change the threshold or verdict.
Filter by review status or show every period, and sort by priority, delivery time or largest share. These controls are in the URL; your private positions and threshold remain in browser memory. The summary reports entered positions only, with assessed coverage shown beside the results. Coverage appears before the result cards, including on mobile, so partial assessments are qualified before their totals.
The counterfactual
Opening a re-clear loads the curves on demand. For a captured auction, the loading message warns that an archive call can take longer if one is needed. When saved curves arrive, the panel labels them Archive call. Italy's curves are read live and do not use this archive.
For a period backed by an aggregated curve, the console can re-clear the auction without your volume and report the difference between the price that cleared and the price that would have.
That is a stronger materiality signal than share alone: a large share that moved nothing, and a small share that moved the clearing price, are different facts. It is still a counterfactual over a published aggregate - it cannot represent block orders, and it assumes everything else would have been submitted unchanged.
Select Simulate on a row to open the re-clear as its own full-width section below the periods, with the delivery period in its heading and a link back to the table. Each price impact names its basis and geographic scope. A reconstructed result uses an hourly model and carries its trailing out-of-sample mean absolute error beside the price shift. Compare the shift with that error before reading it as material. Changing the assessed position resets an open curve simulation to that position. Edits within the scenario editor remain separate from the assessment and its CSV export.
Reading the period table
One row per delivery period of the day, with your volume, the period's market volume, your share, and whether it reached your threshold. The chart above it draws the same share against the threshold line: a ninety-six-row table cannot show that two afternoon periods crossed and the rest did not.
The filter decides which rows the table shows; the complete daily ledger is folded directly beneath it and keeps every available period, including periods with missing positions or market volume. It is also the text alternative to the share chart, which is why it stays in the page whatever the filter is set to. The CSV export always includes this whole ledger regardless of the filter.