FMV 2026 — Methodology deep-dive

This page documents the methodology behind the FMV / MPV / MSV calculation introduced in May 2026. It complements the user-facing FMV definition & algorithm and Market values: FMV, MPV & MSV pages and is intended for power users, API consumers, and partner integrations.

For the conceptual overview, start with Market values: FMV, MPV & MSV. For the stage hierarchy, see FMV definition & algorithm.

Recency weighting

Every transaction used by the FMV and MPV/MSV calculation is weighted by an exponential decay function of its age:

\[w_i = q_i \cdot 2^{-\,\Delta t_i / h}\]

where \(q_i\) is the transaction quantity, \(\Delta t_i\) is the number of days between the transaction event date and the calculation date, and \(h\) is the half-life.

The default half-life is 180 days, meaning that a transaction loses half of its weight every six months. Older transactions still contribute, but with diminishing influence.

IQR-based spread

The width of the MPV/MSV corridor is derived from the dispersion of the (weighted) transaction prices for a given part and condition. Per condition, the algorithm computes the 25th, 50th and 75th percentile on the weighted price distribution, and forms a coefficient of dispersion:

\[\text{IQR}_{\text{cv}} = \frac{q_{75} - q_{25}}{q_{50}}\]

The final spread for the corridor is the IQR coefficient clamped between a configurable minimum and maximum:

\[\text{spread} = \min\!\left(\max(\text{IQR}_{\text{cv}},\;\text{min}),\;\text{max}\right)\]

Defaults are min = 0.10 and max = 0.40. Companies can override either boundary, or supply a fixed override spread that bypasses the IQR-based calculation entirely. See Company Settings.

Per-condition values are then:

\[ \begin{align}\begin{aligned}\text{MPV} = \max\!\left(1.0,\;\text{median} \cdot (1 - \text{spread})\right)\\\text{MSV} = \max\!\left(1.0,\;\text{median} \cdot (1 + \text{spread})\right)\end{aligned}\end{align} \]

The 1 USD floor prevents degenerate values for very low-priced parts.

Factor calibration for thinly-traded parts

Parts with fewer than three transactions in a given condition do not generate a direct (Stage 1) MPV/MSV. Instead, ratios MPV/FMV and MSV/FMV are computed for comparable parts (same material domain and fleet) and the median ratio is applied to the part’s FMV to synthesise the corridor. This ensures every priced part has a stable MPV/MSV pair without producing wild values for parts where the data is too thin to support a direct calculation.

The ratio training set is restricted to parts with FMV stage < 5 (i.e. parts whose FMV itself is supported by transactions, not by fall-back values). Inversions where MPV > MSV are detected, logged into a dedicated anomaly table, and removed before the corridor is published.

Factor calibration runs per company profile, so a company that has overridden its spread boundaries gets factors trained against its own boundaries.

Quality dimensions

Each FMV row stores three quality dimensions plus the combined fmv_quality rating. The user-facing definition is at FMV Quality scorecard. Implementation-side notes:

  • data_basis is derived from the FMV stage and the number of transactions. The threshold of six transactions matches the min_transactions default of calculate_fmv(); if the default changes, the threshold should be revisited.

  • data_freshness thresholds are absolute (≥1 transaction in the window), not proportional, so the signal stays stable as the total transaction count in the database grows.

  • price_consistency checks per condition (NE, SV, AR) whether MPV ≤ FMV ≤ MSV holds. With three checkable conditions, zero failures = High, one = Medium, more = Low. With one or two checkable conditions, zero failures = High, otherwise Low.

Quality dimensions are recomputed on every calculate_fmv() run and copied into price_fmv_history so the historical record reflects the quality that was active at the time of each calculation.

Calculation cadence

The FMV / MPV / MSV calculation runs on the 1st of every month. Settings changes (company spread overrides) are picked up by the next scheduled run; they do not retroactively rewrite past values.

API exposure

The Evaluation KPI API endpoint exposes the FMV stage as fmvStage, allowing API consumers to assess the methodology and data basis behind every value. See the API documentation for the full schema.