HighLow’s operations team sometimes had to investigate a completed trade after a customer questioned the closing result. They already had the recorded outcome. What they needed was a dependable way to reconstruct the market evidence behind it.
HighLow was one of OM2’s largest customers, operating a regulated Australian short-duration trading product on our platform. In that environment, a small movement around expiry could determine whether a trade finished as a win or a loss, and a customer question quickly became a more precise operational question: which market observation had actually counted?
That need became Proof of Expiry.
How the trade reached its outcome
A High/Low trade began with a direction and an opening strike. Market ticks continued to arrive throughout the life of the trade. At expiry, the final tick before the expiry time became the closing rate. That rate was compared with the opening strike and the direction of the trade to determine the outcome.
The market did not stop at expiry; the trade did. That made the exact observation on the eligible side of that boundary consequential.
For the customer, though, the outcome alone was not always enough. If the market had appeared to move the other way around expiry, seeing only a final status did not explain why the trade had closed as it did.
The system therefore needed to preserve more than a result. It needed to make the evidence behind that result reconstructable.
Reconstructing what happened
Proof of Expiry did not make the settlement decision. It reconstructed the evidence behind it afterwards.
For a requested trade, the first delivered scope focused on expiry-time evidence: market observations within a configurable window around expiry, their timestamps and rates, and an explicit marker showing which observation was the deciding rate.
The surrounding observations mattered because they put the closing rate in context. An operations user could see what the market had been doing immediately before and after the boundary instead of receiving one isolated number with no explanation around it.
There was also an edge case. If no tick had been stored inside the configured evidence window, the response included the previous available observation rather than returning an empty result.
We considered a broader version that could also reconstruct evidence around the original trade time, including the rates offered when the trade was opened. That was designed as future scope; the first implemented phase stayed centered on the closing evidence around expiry.
The result was an evidence contract rather than another reporting field: a defined set of observations, timestamps and deciding-rate provenance that another operational workflow could depend on.
When the proof wasn’t ready yet
The trade itself had already been settled by the time Proof of Expiry was requested. The timing problem came afterwards: for recently settled trades, some of the information needed to assemble the proof was not always available to the service at the moment HighLow requested it.
That meant request time and evidence-ready time were different clocks.
The request therefore remained in progress until the required expiry evidence became available, and the completed proof was returned through a callback.
This asynchronous behavior was not architecture for its own sake. It followed directly from the product promise. If the answer could not be assembled yet, the system needed a way to accept the request and finish it later rather than pretend the evidence already existed.
Production use exposed a rarer failure case. If the service was interrupted while an accepted request was still pending, that request could not simply disappear. We later made accepted requests resilient to that interruption so the normal waiting flow could resume instead of leaving HighLow waiting for a callback that would never come.
If a system promises evidence, losing the request for that evidence is itself a product failure.
From API behavior to operational capability
As the capability moved into regular use, it became part of the operational investigation flow rather than just a server-to-server feature. Follow-up work brought Proof of Expiry closer to Support and made the returned market data and errors easier to inspect during an investigation.
The capability was used in HighLow’s operations. The product change was that a questioned outcome no longer had to end with a final status and an appeal to trust. The system could reconstruct the market context and identify the observation that had determined the result.
That changed what reliability meant too. Once another operational system depended on the proof, reliability included the obligation to complete an accepted evidence request, not only the availability of the service at the instant the request arrived.
The moment an outcome may later be questioned, evidence stops being a logging concern and becomes part of the product.