Last good price is the most recent price value that was considered valid and usable by a trading, risk or oracle system. When fresh market data is missing, delayed or clearly abnormal, the system may keep using that prior accepted value until a new valid price arrives.
What “last good price” means in trading and risk systems
Last good price is a continuity control, not a market truth claim. It is the most recent value a system has already accepted as valid, so downstream pricing, valuation, and risk workflows can keep operating when live market inputs are missing, stale, or obviously abnormal.
That makes the term useful in environments where price feeds are intermittent or noisy. The system is not saying the frozen value is current, only that it remains the best usable reference until a fresh, valid update arrives.
Why systems keep a last good price
The main purpose is operational continuity. Trading and risk engines often need a price to calculate exposure, margin, limits, revaluation, or alerts, and a blank field can be more disruptive than a cautiously retained prior value.
This mechanism is usually paired with validity checks that reject outliers, delayed ticks, duplicate events, or feed glitches. The design choice is pragmatic: preserve service behaviour while avoiding automatic acceptance of bad market data.
Where last good price differs from a live market quote
A live quote reflects the current observed market, while a last good price is a cached fallback based on prior acceptance. That distinction matters because stale values can lag fast-moving markets and may temporarily misstate a position’s economic reality.
In practice, the quality of the fallback depends on the rules behind it. A robust system should define when a price becomes invalid, how long a retained price may be reused, and what conditions force escalation to manual review or a degraded state.
How organisations should interpret the control
Last good price should be treated as a resilience mechanism with governance around freshness, source quality, and exception handling. It is most defensible when the system can explain why the retained value was accepted, when it was last validated, and what monitoring watches for prolonged feed failure.
For practitioners, the important question is not whether a fallback exists, but whether its use is visible, bounded, and appropriate to the instrument or workflow. A retained price that silently persists too long can distort valuation, hide data-feed incidents, or delay response to market-data failure.
Risk and Threat Considerations
Last good price can create hidden exposure when stale or manipulated values remain in use after the underlying market has moved. The risk is highest when downstream controls assume the retained value is fresh, because that can distort pricing, risk limits, margining, and exception reporting.
Failure mechanism: A bad or missing feed causes the system to keep reusing an older value, or an attacker influences input validation so that an abnormal price is treated as acceptable and becomes the new fallback.
Impact: Users and automated processes may trade, hedge, or report against an inaccurate reference point, which can lead to misvaluation, incorrect risk decisions, delayed detection of feed compromise, and avoidable financial loss.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Last good price depends on detecting abnormal or missing market inputs. |
| AU-2 — Event Logging | Systems using a retained price need traceability for when the fallback was used. | |
| CM-8 — System Component Inventory | Price sources and consuming systems must be known to govern where fallback logic applies. | |
| Recommendation — Monitor price-feed behaviour and alert on stale or abnormal values. Log each fallback decision and the input conditions that triggered it. Inventory market-data sources and systems that depend on last good price logic. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | Continuously monitoring feed quality helps detect abnormal or unavailable market inputs. |
| PR.DS-01 — Data-at-rest is protected | Stored fallback values must be protected from tampering and unauthorized change. | |
| Recommendation — Monitor data feeds for anomalies and service degradation that could trigger stale pricing. Protect stored pricing data and cached fallbacks from unauthorized modification. | ||
Practitioner Guidance
What to watch for: Treat repeated fallback use as an operational signal, not a normal state. If a last good price is being used frequently or for long periods, the source feed, validation logic, and downstream dependency chain need review.
Governance implication: Define who owns the validity rules, who approves fallback thresholds, and when the system must stop trusting the retained value and move to manual intervention or degraded processing.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org