OHLC Consistency Validator

Practical promise. Detect impossible candle geometry with explicit tick tolerance, preserve the original evidence, and avoid turning a validation alert into an unsupported accusation or silent repair.

A candle can look ordinary while carrying an impossible relationship: its reported high may sit below its open, or its low may sit above its close. If that row enters volatility, return, chart, or risk calculations, the defect becomes harder to trace. An OHLC consistency validator is a small but valuable ingestion control because its decision can be reproduced from one row.

The control is deliberately narrow. It decides whether a bar satisfies a declared structural contract. It does not decide that a vendor made an error, reconstruct a replacement value, or certify that a passing bar is economically correct.

What the source fields mean

The current NYSE Closing Prices specification describes a daily product containing Open, High, Low, Last, and Total Volume. For that product, Open is the first qualifying trade price, High is the highest trade price, Low is the lowest, and Last is the final trade price. It also states that price fields are expressed in dollars to penny precision. Those definitions provide authoritative field context, but they do not create a universal repair algorithm.

Before validating, pin the actual contract for your source:

• instrument and venue scope;
• interval and session;
• currency and stored scale;
• adjusted or unadjusted basis;
• qualifying-trade and correction policy;
• tick size effective at the bar's time; and
• schema and source version.

Comparing fields with different bases can manufacture an alert even when each source value was valid in its own context.

The three invariants

Let $O$, $H$, $L$, and $C$ be normalized open, high, low, and close prices. Let $q>0$ be tick size and $n\ge0$ be the allowed tolerance in ticks. Convert the business tolerance once:

Then require all three relationships:

The first rule prevents an inverted range. The second makes high contain both body endpoints. The third makes low contain both endpoints. Equality passes.

Do not substitute an unexplained percentage. A one-tick allowance communicates a concrete source convention; a percentage changes with price and may conceal a parsing defect.

Boundary arithmetic you can check by hand

Set $q=0.01$ and $n=1$, giving $\epsilon=0.01$. Consider:

The high misses the body maximum by exactly $100.01-100.00=0.01$. Because equality is allowed, the bar passes. If only Open changes to $100.0101$, the gap becomes $0.0101$, which is beyond one tick and produces HIGH_BELOW_BODY.

This distinction is worth testing. Decimal prices such as 100.01 are not represented exactly in binary floating point. The implementations therefore add a tiny machine-roundoff guard—eight floating-point epsilons times the largest price magnitude. It prevents representation noise from flipping the equality case; it is not a hidden business tolerance.

One row can fail three ways

Now use zero tolerance with $O=102$, $H=101$, $L=103$, and $C=102$.

The range is inverted because $103-101=2$. High is below the body because $102-101=1$. Low is above the body because $103-102=1$. The useful output is the complete ordered list:

HIGH_BELOW_LOW
HIGH_BELOW_BODY
LOW_ABOVE_BODY

Stopping after the first issue throws away diagnostic evidence. Changing High to 103 or Low to 101 may produce valid geometry, but either change invents a value unless a downstream repair process has stronger source evidence.

Normalize scale before comparing

Some feeds store 100.01 as integer 10001. The package makes that convention explicit with price_scale=0.01. It multiplies all four prices by the same positive scale, then calculates the gaps in normalized price units. Tick size must use those same units.

The scale parameter is not a universal decoder. If one field is in cents and another is already in dollars, a single row-level scale cannot repair the schema mismatch. Reject or normalize the source record earlier, while preserving the raw payload.

Field failures are different from geometry failures

The reference implementations accept finite numeric prices only. Missing values, booleans, numeric strings, NaN, and infinities produce field-specific issues. Geometry is evaluated only when all four prices are valid. A non-empty timestamp must be ISO 8601 with Z or an explicit UTC offset. Optional volume may be zero but cannot be nonfinite or negative.

This ordering avoids a misleading result. If high="100" arrives as a string, the validator reports INVALID_HIGH; it does not coerce the value and pretend the source contract was satisfied.

The separation at the end is the most important operational rule: detection and repair are distinct stages.

The output is an audit record

Each result includes the input index, timestamp, validity flag, ordered issues, effective tolerance in price units, normalized prices when available, selected provenance, and a shallow copy of the raw row. The detector never edits the input.

In production, attach more lineage than the teaching implementation can assume: source file or message ID, ingestion timestamp, schema version, calendar version, adjustment version, and validator version. Quarantine can then preserve evidence while preventing propagation.

Why a failure is not automatically a provider error

An inconsistent row is evidence that the row and your declared contract disagree. Possible causes include:

• wrong decimal scale;
• a missing marker parsed as zero;
• mixed adjusted and unadjusted fields;
• fields aggregated from different venue scopes;
• an interval or timezone join error;
• a stale partial update; or
• an upstream publication defect.

The last explanation is only one candidate. Confirming it requires a reproducible source sample plus authoritative correction evidence, such as an official correction file, notice, or documented version change.

Historical-case decision: valuable, but not fabricated

A real historical case would make the operational value obvious if it included a dated original row, an official correction artifact, corrected values, and a measurable downstream effect. This review did not establish that complete evidence chain for a named OHLC bar. Therefore, this article does not publish a company, date, or alleged vendor error.

If two providers disagree, record the discrepancy as a research lead. Do not write “provider X was wrong” until the field bases match and an authoritative record confirms the correction. The fixtures and playground in this package are labeled synthetic for exactly this reason.

Use the playground as a validator console

Open the interactive OHLC validator. It begins with an informative first bar and provides three 36-row scenarios:

• Canonical mix: clean controls plus high, low, inverted-range, and volume failures;
• One-tick boundary: exact-tolerance rows and just-beyond-tolerance rows; and
• Malformed input: missing, string, nonfinite, and invalid timestamp cases.

Change tolerance in ticks, then use Back, Step, Play, Pause, and Reset. The diagram, current rule, issue list, raw row, provenance, and audit window recompute together. Reset is deterministic. Reduced-motion users retain the full step sequence without automatic animation.

Implementation and parity

The Python and TypeScript implementations follow the same order:

1. validate configuration;
2. copy raw input and provenance;
3. validate timestamp, price, and optional volume fields;
4. normalize price scale;
5. evaluate every geometric gap; and
6. emit one immutable diagnostic result.

The shared fixture fixes the equality policy, issue ordering, malformed input behavior, and provenance output. Separate tests cover scaled integer prices, invalid configuration, nonfinite values, and the 120-bar synthetic corpus.

Passing those tests proves agreement with this package definition. It does not prove that the configured tick size is point-in-time correct, that a passing source row represents every qualifying trade, or that any downstream trading decision is useful.

Practical failure modes

• Overbroad tolerance: hides a repeatable rounding or parsing problem.
• Wrong tick table: treats an instrument's current increment as historical truth.
• Silent coercion: turns a schema violation into plausible geometry.
• Automatic repair: destroys the raw evidence needed to identify the cause.
• Passing equals correct: overlooks stale, incomplete, adjusted-basis, or wrong-session bars.
• Provider disagreement equals proof: skips the official correction and provenance check.

The validator should run early, but it is only one control. Follow it with timestamp ordering, duplicate and gap detection, session membership, corporate-action basis checks, source reconciliation, and local outlier detection.

Summary

An OHLC consistency validator is valuable because its boundary is explicit and auditable. Normalize the declared scale, convert tick tolerance to price units, report every field and geometry issue, and preserve the original row. Treat the result as a detection—not a repair and not a verdict about a provider.

Continue with Hampel Bad-Tick Filter to detect observations that are internally possible but locally implausible.

Primary references

• NYSE Closing Prices Client Specification v2.2 — field definitions, price units, and product version context.
• NYSE Daily TAQ Client Specification v4.3 — lower-level timestamp, blank-field, symbol, sequence, and provenance context.
• SEC Final Data Quality Assurance Guidelines — reproducibility and correction-evidence discipline; not an OHLC methodology.