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.
