Note on figures cited below. Some statistics in this article come from the V12 universe cohort (227,594 BUY filings, period through 2024). Since 2025-01-01 the live out-of-sample BUY universe (28 markets) shows a 52.96 percent win rate and a +8.59 percent mean 90-day return on 20,688 filings. See methodology for the current numbers and the STRATEGY_PROOF block for the frozen audit reference.
A €5 million insider purchase is not larger than a $5 million one. It only looks that way if you stop reading halfway through the number.
The problem is not accounting, it is comparability
Insider transaction datasets are full of numbers that appear precise and are often not comparable. A director buys 200,000 shares in Paris, another sells stock worth SEK 12 million in Stockholm, a third exercises options in New York for $3.4 million. If you line those figures up without currency normalization, you are not comparing conviction, scale, or even rough economic significance. You are comparing typography.
For a publication that covers multiple markets, this matters immediately. Rankings of the "largest buys this week" become nonsense if one market reports in euro, another in pounds, another in dollars, and a fourth in kroner. Aggregate charts by month become hostage to exchange-rate drift. A strong dollar year will make US transactions look mechanically larger in a euro-based publication, even if underlying behaviour is unchanged. That is not a market signal. It is arithmetic wearing a fake moustache.
We therefore convert every transaction into EUR before it enters comparative analysis.
That choice is partly editorial and partly statistical. Editorial, because our readership needs a common unit. Statistical, because any cross-sectional comparison needs a shared numeraire if the raw observations come from different currency zones. The alternative is to force readers to do mental FX conversion while reading. Readers have many talents. Currency triangulation should not be a prerequisite.
Why EUR, specifically
We use EUR because the publication is Europe-centred and because a large share of the markets we cover either report directly in euro or are commonly benchmarked against euro-area capital markets. There is nothing metaphysically superior about EUR as a base currency. If we were publishing a US-only product, USD would be the obvious choice.
The important point is consistency. Pick one base currency and keep it fixed for analysis. Constantly switching the base currency by article or region creates a subtler version of the same problem you were trying to solve. The numbers remain internally coherent only within each piece, not across the archive.
What goes wrong if you do nothing
Three errors show up repeatedly when datasets are left in local currency:
- False size rankings. A CHF 2 million purchase and a £2 million purchase are not equivalent. Yet they will often be presented side by side as if they were.
- Distorted time series. If the SEK weakens materially against EUR, the euro value of Swedish insider activity falls even when local-currency activity is flat. That is not necessarily a decline in insider appetite. It may just be Sweden being Sweden in the FX market.
- Broken aggregation. Summing local-currency values across markets is indefensible. "Total insider buying this month was 480 million" is a sentence that requires a currency unit. Without one, it is decorative.
None of these mistakes is exotic. They are routine, and because they are routine, they are dangerous. The eye gets used to them.
Why the transaction date matters more than the filing date
The central methodological choice is not only whether to convert, but when to convert. We use the FX rate on the transaction date, not the filing date.
That sounds obvious until you look at how disclosure regimes work. In many markets, insiders have a reporting window after the trade occurs. Under the EU Market Abuse Regulation, persons discharging managerial responsibilities and persons closely associated with them must notify transactions within a set deadline, commonly framed as T+3 business days under Article 19. In the US, Form 4 is generally due within two business days after the transaction. The filing date is therefore often later than the economic event.
If you convert using the filing-date FX rate, you are measuring disclosure timing plus currency movement, not the value exchanged when the trade happened.
Economic exposure changes on the trade date
Suppose an insider buys shares on Monday in a non-euro market and files on Thursday. If the local currency appreciates 2 percent against EUR between Monday and Thursday, a filing-date conversion will overstate the euro value of the purchase by 2 percent relative to the actual economic commitment made at execution.
That may not sound dramatic for one trade. Scale it across thousands of filings and several years, and the noise compounds. The problem is worst when:
- reporting lags are long,
- currencies are volatile,
- the analysis focuses on tails, such as "largest transactions",
- the article spans periods of acute FX stress.
A transaction-date conversion aligns the currency translation with the moment the insider assumed or reduced exposure. That is the event of interest.
Filing dates still matter, just not for FX translation
This does not mean filing dates are irrelevant. They are crucial for event studies that examine market reaction to disclosure, because the market cannot react to a filing before the filing exists. If the research question is "what happened after investors learned about the trade?", then the filing timestamp is central.
But that is a different question from "what was the economic size of the trade?" One date for disclosure analysis, another for value normalization. Mixing the two is how methodology notes become apology notes.
| Market | Regulator | Rule | Deadline | Notes |
|---|---|---|---|---|
| FR | AMF | MAR Art 19 | T+3 | PDMR and PCA notifications under the EU regime. |
| EU | ESMA | MAR Art 19 | T+3 | Framework applies across EU member states with national implementation and regulator portals. |
| US | SEC | Exchange Act Section 16, Form 4 | T+2 | Most insider transactions by officers, directors, and 10% holders are reported on Form 4. |
The FX history table is the unglamorous machinery that makes this work
People enjoy discussing alpha. Few enjoy discussing reference tables. The reference tables are usually more useful.
To convert every trade at the transaction-date rate, you need a clean FX history table keyed by date and currency pair. At minimum, that table should allow a deterministic lookup from (trade_date, local_currency, EUR) to a rate.
What the table needs to contain
A practical FX history table usually includes:
datebase_currencyquote_currencyratesourcetimestamp_loadedquality_flag
If the dataset contains only one local-currency amount per filing, the conversion formula is straightforward:
[ \text{value_eur} = \text{value_local} \times \text{fx_local_to_eur on trade date} ]
If your source stores EUR per unit of local currency, use multiplication. If it stores local currency per EUR, use division. This is obvious until someone flips the convention in a CSV and your Swiss trades suddenly become moon landings.
Direct pairs versus triangulation
Not every currency pair is equally available from every source. In practice, there are two common approaches:
- Direct local-to-EUR rates, where available.
- Triangulation through a major currency, typically USD, if direct rates are missing.
Direct rates are cleaner. Triangulation is acceptable if documented and consistently applied. If you triangulate, preserve the intermediate rates and the exact formula used. Future you will want to know why a NOK trade from 2021 converted to a suspiciously specific euro amount.
Missing dates, weekends, and market holidays
Trades can occur on dates for which your FX source has no published daily observation, especially around weekends and holidays. That creates a choice.
The usual options are:
- previous available business-day close,
- same-day official fixing if available,
- next available business-day rate, less common and usually less defensible,
- intraday timestamped rates, ideal but often unavailable in broad historical pipelines.
For an archive-scale workflow, the standard choice is to use the previous available business-day rate when the transaction date lacks a direct daily observation, while flagging the imputation. It is not perfect. It is usually the least bad option.
Why source consistency matters
It is tempting to patch gaps from whatever free source is nearby. Resist the temptation unless you enjoy subtle basis differences. Central bank reference rates, market close rates, and vendor mid rates can diverge. Usually not by much, but enough to create avoidable inconsistencies in edge cases.
A single documented source hierarchy is preferable:
- primary source,
- fallback source,
- imputation rule.
That hierarchy should be stable over time. Methodology drift is the bureaucratic cousin of look-ahead bias.
Repricing every trade, step by step
The phrase "we convert everything to EUR" sounds simple because the messy parts are hidden in the word "everything".
Step 1, preserve the original filing values
Never overwrite the original amount and currency. Store:
- original transaction amount,
- original currency,
- share count where available,
- reported price per share where available,
- transaction date,
- filing date.
The converted EUR amount is a derived field, not a replacement. If a regulator later amends a filing, or if you discover a parsing error, you need the raw values intact.
Step 2, identify the transaction amount to convert
Not every filing presents value in the same way. Some give:
- number of shares and price per share,
- total consideration,
- derivative notional values,
- multiple line items in one filing.
Where total consideration is missing, compute it from shares multiplied by price per share, if both are available. If either is missing, the EUR value may be n/a for that line item. Better a visible gap than a fabricated certainty.
This is especially important with derivatives and option exercises. The reported "price" may be an exercise price, not the market value of the acquired position. If your article compares gross cash outlay, that may be fine. If it compares economic exposure, it may be misleading. The currency conversion is the easy part. The financial interpretation is where the traps live.
Step 3, join to the FX table on transaction date and currency
For each line item:
- take the transaction date,
- take the local currency,
- retrieve the EUR conversion rate for that date,
- apply the documented formula,
- record the rate used.
This should be reproducible and auditable. If a reader asks why a trade converted to €1,184,273.62 rather than €1,184,000, there should be an answer beyond "the database said so".
Step 4, aggregate only after conversion
If a filing contains several transactions in the same currency on the same day, you can convert line by line and then sum, or sum first and convert once. Mathematically, those are equivalent if the same rate applies to all lines.
If a filing spans multiple dates or multiple currencies, convert each line item separately and aggregate in EUR afterwards. This avoids cross-date contamination and keeps the audit trail clean.
Step 5, keep the rate metadata
For each converted observation, retain:
- FX source,
- rate date,
- whether the rate was direct or triangulated,
- whether the date was exact or imputed from a previous business day.
This metadata is not decorative. It lets you quantify how much of the archive rests on exact same-day rates versus fallbacks, and it helps identify periods where conversion quality may be weaker.
What a simple FX history table should look like
A compact design is usually enough. For daily conversion, you do not need a cathedral.
Example schema
| field | type | purpose |
|---|---|---|
fx_date |
date | Date of the rate |
from_ccy |
text | Original transaction currency |
to_ccy |
text | Base currency, here EUR |
rate |
numeric | Conversion rate |
rate_type |
text | Official, close, midpoint, triangulated |
source_name |
text | Source provider |
is_imputed |
boolean | Whether prior-day fallback was used |
loaded_at |
timestamp | ETL audit timestamp |
The key design choice is not sophistication but determinism. Given a transaction in GBP on 2024-02-13, the system should always return the same EUR rate unless the source itself is revised and the revision is logged.
A note on precision and rounding
Store rates and converted values at reasonably high precision, then round only for presentation. Rounding too early creates aggregation drift. Ten thousand tiny rounding errors can become a visible discrepancy in monthly totals.
This is not a philosophical issue. It is a spreadsheet issue, which is usually worse.
Where currency normalization helps, and where it does not
Converting everything to EUR improves comparability. It does not solve every measurement problem in insider data. Some limitations survive translation intact.
It helps with cross-market ranking
This is the obvious win. Once every trade is in EUR, you can rank transactions across France, Sweden, the UK, Switzerland, and the US on a common scale. The "largest buy" is at least numerically coherent.
It helps with aggregate trend analysis
Monthly or quarterly totals become interpretable. If euro-normalized insider buying rises across the archive, you can discuss whether that reflects broader behaviour, sector composition, or market conditions. Without normalization, aggregate totals are barely fit for decorative use.
It does not remove issuer-size effects
A €1 million purchase at a €500 million company is not the same signal as a €1 million purchase at a €50 billion company. Currency normalization does not account for market capitalization, free float, or average daily turnover. Those require separate scaling.
It does not fix disclosure heterogeneity
Regimes differ in thresholds, filing formats, amendment practices, and treatment of derivatives. A normalized EUR amount still sits inside a legal and reporting framework that may not be fully comparable across jurisdictions.
It does not neutralize FX as an economic factor
There is one subtle point worth stating plainly. If you are analysing the economic significance to a euro-based observer, then converting to EUR is exactly what you want. If you are analysing the local-currency significance within the issuer's domestic market, local-currency values may still matter.
For example, a SEK 10 million insider purchase may be best understood relative to Swedish salary norms, local investor behaviour, or company-specific context. The EUR conversion is necessary for cross-border comparison, but it is not always the only lens worth keeping.
The regulatory backdrop, and why evergreen sources are enough
The methodology does not depend on a fashionable data vendor note. It rests on ordinary regulatory plumbing.
Under the EU Market Abuse Regulation, insider dealing disclosures by PDMRs and associated persons are governed by Article 19, with notifications made within a defined post-transaction window. ESMA has published Q&A and technical material clarifying the framework. National regulators such as the AMF provide the operational disclosure environment in their jurisdictions.
In the US, Section 16 reporting and Form 4 deadlines create a similarly clear distinction between the transaction date and the disclosure date. The legal architecture differs, but the methodological implication is the same. The trade occurs first. The filing follows.
That sequencing is why transaction-date FX conversion is the defensible default for economic-size analysis across markets.
The notification obligations set out in Article 19 of MAR are intended to provide information to the market on transactions conducted by persons discharging managerial responsibilities and persons closely associated with them.
A few edge cases worth not pretending away
Methodology notes are often written as if the data were tidier than they are. A few awkward cases deserve daylight.
Multi-currency issuers and ADRs
An issuer may trade in one market, report in another currency, and have insiders transacting through instruments linked to yet another venue. ADRs are the classic headache. In such cases, convert the actual transaction consideration currency, not the issuer's reporting currency. The filing tells you what changed hands. Believe it.
Derivatives and zero-priced grants
Some filings include awards, grants, or derivative transactions with reported prices of zero or nominal values. A zero in the filing does not mean zero economic significance. It means the reported field is not a useful measure of value for your purpose. Mark the EUR amount as n/a if no defensible cash-value computation exists.
Amended filings
If a filing is amended, the converted EUR amount should be recalculated from the amended raw values using the same FX methodology. Do not preserve stale conversions simply because they arrived first. Markets have enough ghosts already.
Historical redenominations
Most modern archives will not be dominated by pre-euro legacy currencies, but if they are present, the FX table needs explicit handling for redenominations and currency succession. This is not common in recent insider datasets, but when it appears it is not the sort of issue one should improvise over lunch.
Why this matters editorially
A publication earns trust by making numbers comparable before making them dramatic.
Readers will forgive complexity if it is necessary. They will not forgive false precision dressed as simplicity. Saying "we convert everything to EUR at the transaction-date FX rate" is not a flourish. It is a promise that a Swedish sale, a British purchase, and a US option exercise can sit in the same table without insulting arithmetic.
It also makes the archive more reusable. Once every filing has a preserved local value and a documented EUR equivalent, you can build rankings, sector aggregates, issuer histories, and screening tools without re-litigating the currency question each time. The alternative is a newsroom that keeps rediscovering exchange rates like a Victorian naturalist finding beetles.
The practical next step is straightforward: publish the FX methodology alongside any cross-market insider ranking, and expose the rate date and source in the underlying data model. The open question is more interesting, whether future analysis should also present a second normalization layer, scaling EUR transaction values by issuer market cap or average daily volume, so that "large" means more than "large after currency conversion."
Sources & further reading
- ESMA, Questions and Answers on the Market Abuse Regulation (MAR)regulator2026-05-17
- Regulation (EU) No 596/2014 on market abuse (Market Abuse Regulation), Article 19regulation2014-04-16
- AMF, Market Abuse Regulation resourcesregulator2026-05-17
- U.S. SEC, Form 4 Statement of Changes in Beneficial Ownershipregulator2026-05-17
- U.S. SEC, Fast Answers: Forms 3, 4, 5regulator2026-05-17
- European Central Bank, Euro foreign exchange reference ratescentral bank2026-05-17
- Bank for International Settlements, Foreign exchange turnover and market structureresearch2022-10-27
Editorial note, this article was assembled without live web research (Grok unavailable in this generation pass). Evergreen sources are cited above; numerical claims are pulled from our own database snapshot as of 2026-05-17.
Insiders Trades backtest cohort
Our analysis of insider transactions within the French market reveals intriguing insights into currency normalization. With a sample of 16,101 priced trades, the mean 90-day return stands at -0.24%, accompanied by a win rate of 43.74% and an annualized Sharpe ratio of -0.08. In contrast, a broader global universe encompassing 227,594 BUY filings across 17 markets shows a more pronounced aggregate mean 90-day return of -1.70% and a Sharpe ratio of -0.08. These figures highlight the nuanced performance of insider transactions in France, suggesting that while insider activity may not yield positive returns on average, it performs relatively better than the overall market context. However, it is essential to consider the limitations posed by the sample size and the 90-day time horizon in drawing definitive conclusions.
Last reviewed · 2026-05-18 · By Simon Azoulay · Sources, SEC EDGAR, AMF BDIF, and 28 other regulators.
