Blackhedge: a market platform where being late is the same as being wrong
A real-time equities platform. Market data, news and sentiment from many sources, unified into signals with risk scores, delivered as live dashboards and alerts, with order placement and funding built in.
- 4 histories per listed company, one clock
- 3 input classes, 3 different clocks
- 2 price series per symbol
- 1 fetch per symbol, however many watchers
- 0 signals delivered after expiry
What the platform does
Raw market data is not information. A price is a number, and a number without context, comparison and history tells an investor nothing they can act on. The platform closes that gap in four steps.
It ingests. Price and volume from market data feeds, news and company filings, and social and analyst sentiment. Three streams, three shapes, three rhythms.
It normalises. Everything lands in one model per symbol, with the time it was true recorded separately from the time it arrived.
It scores. Predictive models and sentiment analysis produce signals with risk scores attached, and behavioural clustering groups symbols by how they actually behave rather than by sector.
It reaches the investor. Live dashboards, personalised watchlists, real-time charts, and alerts that arrive when something changes rather than when somebody remembers to look. And where the investor wants to act on it, the platform places the order and handles the funding.
- Client
- Blackhedge, since acquired by Surmount AI
- Sector
- Fintech and capital markets
- Market
- Listed equities
- Our scope
- Platform architecture, market data ingestion, signal and risk engine, order placement, funding integration, cloud infrastructure
The one fact that shaped everything
The platform controls none of the things that can make it wrong.
The market opens and closes on its own schedule. A stock halts without warning. A company splits its shares and every historical price becomes a different number overnight. Settlement takes days. A data provider rate-limits, changes its prices, or falls behind. A venue accepts an order and then does not answer.
Every one of those is somebody else's decision, arriving without notice, and every one of them can turn a working system into a confidently wrong one without producing a single error.
That is what separates a market platform from a data product. A dashboard that is late is annoying. A trading signal that is late is an instruction to act on something that is no longer true. An unadjusted price history is not a gap, it is a model learning from a crash that never happened. An order sent twice is not a retry, it is a doubled position with real money in it.
So the architecture is mostly about knowing when the platform is wrong, and refusing to act when it cannot tell.
The four decisions that mattered
If you read nothing else on this page, read this.
Sessions, halts and staleness are held as first-class states, and an expired signal is dropped rather than delivered late.
The price as it traded and the price adjusted for the event, plus the event itself.
Pre-trade checks first, an identity that survives a retry, and reconciliation against the venue afterwards.
Because market data is metered, and a design that scales with users runs out of budget before it runs out of users.
The market has a state, and everything obeys it
Most systems treat lateness as slowness, something to be improved when there is time. In a market platform lateness changes whether the output is right or wrong, which makes it a correctness problem rather than a performance one.
The same is true of the market's own state. A stock can halt mid-session. A session can be shortened for a holiday. Pre-market and after-hours behave differently from the open. None of it is under the platform's control, all of it changes what a signal means, and an order sent into a closed or halted book is rejected by the venue after the investor has already been told it was sent.
A platform that ignores all this still works most of the time, which is precisely why it is dangerous. The failures are concentrated in exactly the moments when a user is paying most attention.
What we did
The session is a first-class state. Pre-market, open, closed, holiday and halted are things the platform knows rather than infers, because a signal produced at three in the morning and an order into a closed book are different kinds of wrong and need different answers.
Every input carries its own age. A price, a filing and a sentiment reading arrive at different times and go stale at different rates. A signal is only as fresh as the oldest thing that went into it, and it carries the time it was computed and the moment it stops being valid.
An expired signal is dropped rather than delivered late. In most products a suppressed notification is a missed opportunity. Here it is the correct outcome, because the alternative is telling somebody to act on a move that finished ten minutes ago.
A feed falling behind is a state, not a log line. If market data stops arriving, the platform knows it is working from an old picture and can say so, rather than presenting stale numbers as current.
Silence became a safe failure. When the platform cannot be confident a signal is current, it does not send one, which on a trading product is worth considerably more than coverage.
An order into a halt is stopped before it is sent, with a reason the investor can read, rather than accepted and then rejected by the venue a second later.
The platform can tell the difference between a quiet market and a broken feed. Those look identical from the outside and mean opposite things.
Signals carry their own expiry, so anything downstream, including the order path, can check whether the thing it is acting on is still true.
A corporate action rewrites the past
This is the failure that looks most like a working system, and it is the one most platforms in this space get wrong.
A company splits its shares four for one. Thursday's close was two hundred, Friday's open is fifty. Nothing has happened. Every holder has four times the shares at a quarter of the price, and their position is worth exactly what it was.
To a system reading raw prices, a stock has fallen seventy-five per cent overnight. A momentum model reads a collapse. A volatility model reads an extraordinary event. Alerts fire. Any indicator computed across that boundary is now wrong and will stay wrong for as long as its lookback window includes the split. Nothing errors. No feed breaks. The model produces a confident answer about an event that never occurred.
Dividends do a quieter version of the same thing. Symbol changes orphan a company's entire history under its old ticker. Mergers and delistings simply stop a series, and a watchlist entry that has silently ceased to exist is worse than one that says so.
What we did
Two price series per symbol, and the event itself. The price as it actually traded, the price adjusted for the action, and the corporate action recorded as a dated event in its own right.
Models read the adjusted series, so history is continuous and an indicator computed across a split is computed across a real one.
Statements and positions read the unadjusted one, because what somebody paid on the day is still what they paid, and an adjusted historical price is not the price anybody transacted at.
A symbol change is a link rather than a new record, so a company's history survives its ticker.
A delisting or suspension is a state on the instrument, so a watchlist shows a symbol that has stopped rather than one that appears to have gone quiet.
The models learn from a market that existed. A series that quietly contains four unadjusted splits will look accurate in testing and behave differently in the open, and the reason is almost impossible to find afterwards.
Alerts stop firing on events that did not happen, which protects the one thing an alerting product cannot afford to lose, which is the user's belief that an alert means something.
Positions and history disagree on purpose rather than by accident, because they are answering different questions and the platform holds both answers.
A company that changes its name keeps its past. That sounds obvious and is a schema decision that has to be made before it happens rather than after.
An order is placed once, and only if it can be
Everything upstream of an order is analysis, and analysis can be wrong and corrected. A model runs again on better data and produces a different answer. That is the system working.
The moment an order leaves, that stops being true. A retry that places a second order has not recovered from a failure, it has doubled a position with real money in it. And a dropped connection between sending an order and hearing back is not an edge case in a trading system. It is a Tuesday.
There is a second problem sitting in front of the first. An order that the venue will reject is worse than an order that fails, because the investor has already been told it went. Insufficient buying power. Funds that are technically present but not yet settled. A position size the account is not permitted. A market that is closed. A symbol that is halted. All of these are knowable before anything is sent.
What we did
Checked against reality first. Buying power, settled funds, position size, the market state and any account restriction are tested before an order leaves. An order the venue would reject is stopped here, with a reason somebody can read rather than a rejection code somebody has to interpret.
An identity, then a state. The intent to trade is recorded with its own reference, so a repeated request carries the same identity rather than becoming a second decision. Requested, submitted, acknowledged, filled or rejected is a state the order holds, not a value a function returned. A response that never arrives leaves the order in a known state to be resolved rather than in no state at all.
Reconciled against the venue afterwards. What happened is read back from where the order went, rather than inferred from the absence of an error, and positions are checked against the broker's record rather than trusted. Sending and filling are different claims, and only one of them is the platform's to make.
Funding is delegated. Money movement runs through a third-party wallet integration rather than a balance the platform holds itself, which keeps custody, and the regulatory weight that comes with it, where it belongs.
A network failure at the worst moment does not become a duplicate position. The design assumes the request may arrive twice, because eventually it does.
The investor finds out before the order goes, not after. A pre-trade check that explains itself is the difference between a platform that feels careful and one that feels unreliable.
The platform's view of a position and the broker's view are reconciled rather than assumed equal. Two systems that both believe they are right about a position is how a trading platform loses an afternoon.
Custody stays outside the platform, which removes a category of regulatory obligation rather than managing it.
One fetch serves every watcher
Market data is metered and rate limited. It is also the platform's largest variable cost, and the one that scales with success.
The obvious build has each screen ask for what it needs. Three investors watching the same symbol produce three calls for one price. At a thousand investors watching an overlapping few hundred symbols, the platform is paying many times over for the same number and pressing against a rate limit that belongs to somebody else.
That is not a performance problem that can be solved later. It is a unit economics problem that gets worse in direct proportion to how well the product is doing.
What we did
A symbol is fetched once and served to everyone watching it. A thousand investors watching the same forty symbols is forty fetches, not forty thousand. Cost tracks what the platform follows rather than how popular it is, which is a number the business controls.
Each kind of data is held for the length it is actually good for. A price is stale in seconds. A company fundamental is good for a day. A news article does not change at all. Treating them the same either wastes money or serves wrong numbers, and a cache that serves wrong numbers is worse than no cache.
Historical series are stored, not re-requested. Backfill is paid for once. Everything after that is read locally, which matters because model training and chart rendering are both read-heavy against the same history.
The cost curve improves per user rather than worsening. Adding investors adds load against a cache, not against a metered provider.
Rate limits stop being a scaling ceiling. The constraint moves from how many people are watching to how many symbols the platform follows.
Charts and dashboards are fast because the data is local, rather than fast because somebody bought a bigger plan.
A provider price change is a known impact rather than a surprise, because consumption is a function of coverage rather than of traffic.
Three sources that disagree
Prices, news and sentiment do not agree, do not arrive together, and are not wrong when they differ.
Price and volume are continuous during market hours, absent outside them, and precise. News and filings are irregular, sometimes arrive overnight, and are dated by publication rather than by receipt. Sentiment is noisy, continuous, and a reading rather than a fact.
Each input keeps the time it was true, separately from the time it arrived. A late article is not read as breaking news, and a model trained on a series that quietly backfilled late arrivals into their arrival slot learns from a market that never existed.
Disagreement is recorded rather than resolved. Price rising while sentiment falls is not a data quality problem to be averaged away. It is one of the more interesting things the platform can notice, and flattening it into a single number throws the signal away.
One shape per symbol downstream. Every model reads one series rather than three, so adding a fourth source is an adapter rather than a rewrite of everything that consumes market data.
The history is usable for training rather than only for display, which is the difference between a platform that can improve its models and one that can only run them. And a new data source is a week rather than a quarter.
Everything the platform knows about one company
An investor looking at a single listed company wants four things that normally live in four places: what the price has done, what the company has said, what has been written about it, and how the mood around it has moved. The platform holds all four as histories against one clock.
Price and volume, adjusted for every corporate action, so an indicator computed across a split is computed across a real one.
Filings and disclosures, dated by when they were published rather than by the period they describe, because a quarterly result is news on the day it lands, not on the last day of the quarter it covers.
News coverage, with what was written, when, and how far it travelled.
Sentiment as a series rather than a reading. A single positive or negative label on a company today is close to useless. A sentiment reading that has been falling for three weeks while the price held up is the interesting thing, and it only exists if the score was stored every time it was computed rather than overwritten.
And the rule that holds all four together
Any point in the past can only be read with what was actually known by then. The past keeps being revised after it happens. Financial figures are restated. Classifications change. An article is edited after publication. Read history through today's version of it and the analysis quietly knows things nobody knew at the time.
It is expensive precisely because it looks like success. A strategy tested against a revised past performs beautifully, then behaves differently in the open, and the gap is discovered with real money by which point the cause is almost impossible to find.
So a revision is stored as a new fact with its own date rather than as a correction to an old one, and the original is kept. The company view can then be read as it stands today, or as it stood on any date, and the two are different answers on purpose.
A company's history can be analysed rather than only displayed. Sentiment turns, coverage spikes and filings sit on the same timeline as the price, so a move can be looked at against what was happening around it. Backtests describe a market that existed. Peer comparison means something, because every company in a sector is being read on the same basis and on the same clock.
What is actually sensitive on a market platform
Most platforms protect customer data because it is private. On a trading platform the more pressing reason is that some of it is tradeable, and the difference changes what needs protecting and from whom.
Credentials to act on somebody's behalf. The platform places orders against a user's account. Those credentials are not a login, they are the ability to trade somebody else's money. They are held encrypted, scoped to the single purpose they exist for, and never in application logs, error reports or support tooling. A support engineer helping with a failed order sees the order, not the means to place another.
Pending orders, which are the most sensitive real-time data in the system. Knowing that a specific person is about to place a large order in a specific symbol, before it reaches the venue, is actionable information about an identifiable individual's intentions. Standing internal access to that is not a privacy risk in the ordinary sense. It is a market abuse surface. So access to live order flow is restricted, time-limited where it is needed at all, and logged with actor and reason rather than granted as a role.
Positions and watchlists, which reveal more than they look like they do. A holdings list is a financial profile. A watchlist is a statement of intent. Both are masked by role, so operational staff see what an operational question requires and not the composition of somebody's portfolio.
The identity and money layers, which the platform deliberately does not hold. Custody sits with the funding partner and the account relationship sits with the venue, which means the platform is not the holder of the identity documents and balances those relationships require. That is a scope reduction rather than a control, and it is worth more than any control it replaces.
A compromised platform does not become a compromised account. Trading credentials are encrypted and purpose-scoped rather than sitting alongside the data they protect.
Internal access to order flow is an event rather than a permission, which is the only version of that control a regulator would recognise.
Support can do its job without seeing a portfolio. Masking by role means the common operational task does not require the most sensitive read on the platform.
Two categories of obligation were declined rather than managed. Custody and identity verification sit with the partners whose business they are.
Which criterion a market platform lives on
Of the five trust services criteria, one carries most of the weight here, and it is the one that usually gets treated as an infrastructure metric.
Availability, on a market platform, is not a percentage in a service agreement. The market opens at a fixed time whether the platform is ready or not, and there is no rescheduling it. A trading system that is unavailable at the open has not degraded, it has failed for the day, and the users most affected are the ones who were relying on it most.
That reframes a great deal of the architecture. Caching market data is an availability decision as much as a cost one, because a rate limit reached at nine thirty is an outage. Holding session state means the platform behaves correctly through a halt rather than falling over on an unexpected condition. Reconciliation against the venue exists so that a partial failure resolves rather than persisting. And knowing a feed is stale, rather than serving old numbers as current, is availability of correct information rather than of the service.
Processing integrity is the second, and it belongs to the order path. A trade that happened must be recorded exactly once, in the state it actually reached, reconciled against the venue rather than against the platform's own optimism.
Confidentiality is the third, and on this platform it is unusual. The material that needs protecting is not only private, it is tradeable, so the control is as much about restricting internal access to live order flow as it is about protecting data at rest. The previous section sets that out.
The control set was designed against the criteria rather than mapped to them afterwards. That is a statement about how the platform was built. It is not a claim to hold an attestation, and where an operator needs one, the work is theirs to complete with an auditor.
The constraints we designed around
Platforms operating inside a market meet constraints set by exchanges, providers and regulators, none of whom negotiate.
Building for all of them on day one is not prudence, it is waste. The work is knowing which to design for up front, which to address when they become real, and which are somebody else's decision to be routed around cleanly.
Market data is licensed, not just purchased
The challenge. Real-time exchange data carries entitlement conditions on who may see it, how it may be displayed and how it may be redistributed. Delayed and real-time are different products with different obligations, and the difference is legal rather than technical.
What we did. Treated entitlement as part of the data model rather than as a contract in a drawer. What a given user is permitted to see is a property the platform holds, so display follows entitlement rather than assuming it.
The obligation is enforced by the system rather than by whoever remembers it, and a change in entitlement is a configuration change rather than an engineering project.
The venue is not always there
The challenge. Feeds fall behind. A broker connection drops. A provider changes a response shape without notice. None of it is under the platform's control and all of it happens during market hours, because that is when there is traffic.
What we did. Made every external dependency a state rather than an assumption. Behind, connected, degraded or unavailable are things the platform knows, and behaviour changes accordingly instead of failing on the next call.
A degraded dependency produces a reduced platform that tells the truth about itself, rather than a working-looking one serving numbers nobody should act on.
Alerts are a permission that is granted once
The challenge. A market platform depends on notifications, and the failure is asymmetric. Too few and the product's core promise fails quietly. Too many and the user turns them off at the operating system level, which is close to unrecoverable, because the product cannot ask again through the channel it just lost.
What we did. Alerts fire on a condition rather than on a schedule, expiry is checked before delivery, and thresholds are the investor's rather than the platform's, so the definition of a move worth knowing about belongs to the person being told.
Notifications keep meaning something, which is the only reason the channel survives. And an investor who set the threshold does not blame the platform for a quiet week.
Backtesting is where a market platform lies to itself
The challenge. A model tested against a series that was silently corrected, backfilled or unadjusted will look excellent and behave differently in the open. It is the most expensive kind of wrong, because it is discovered only with real money.
What we did. Kept both timestamps on every input, kept adjusted and unadjusted series separately, and recorded the inputs behind anything computed, so a result can be traced to the data that produced it rather than reproduced from a series that has since changed.
A backtest describes a market that existed, and a signal that behaved oddly can be investigated rather than argued about.
The impact, depending on your job
If you run the business
Correctness is the product. In most software a wrong number is a bug. Here it is a user acting on something untrue with their own money, and the reputational cost of that is not proportional to how often it happens.
The cost curve is the business model. Market data is the largest variable cost, and whether it scales with users or with coverage decides whether growth is profitable. This one scales with coverage.
Custody stayed outside the platform. Delegating funding to a third-party integration removed a category of regulatory obligation rather than taking it on, which is a strategic decision as much as an engineering one.
If you run engineering
The corporate action handling is the part worth your attention, because it is the failure that produces no error and is therefore the one most platforms in this space carry unknowingly. Two series and the event, models on one and statements on the other.
Then the order path. Pre-trade validation, an identity that survives a retry, and reconciliation against the venue rather than trust in a response.
If you run a delivery team
Most of what is on this page came from deciding where complexity lives. Market state is a state. Dependency health is a state. Freshness is a property carried on the data rather than assumed by the caller.
That is what makes the failure modes testable. A system that infers these things from the absence of errors cannot be tested against them, because there is nothing to assert on.
If you own the numbers
Market data spend tracks symbols followed rather than users served, so the largest variable cost is one the business sets rather than one the market sets.
Backfill is bought once. History is stored rather than re-requested, which is what makes model training affordable.
Order rejections at the venue cost support time, and pre-trade validation moves that cost from a person to a check.
Custody obligations sit with the funding partner, which is a permanent reduction in scope rather than an ongoing compliance cost.
Talk to the client, not just to us
Everything on this page is our account of our own work. If you are seriously evaluating us, we will arrange a reference call with a client who has been through a build like this one, and you can ask them the questions you would rather not ask us.
Technologies we built with
We name the layers rather than the suppliers on the market data and order path, because a supplier map is our client's exposure rather than our credential. Full detail available under NDA.
More case studies
View all case studiesInvestor Relations for ASX
Investor relations for ASX-listed companies, on one platform.
Read case studyIQEX
A platform that generates with AI, and knows exactly what each generation cost.
Read case studyAQYR
One recruitment platform for agencies, employers and the candidates between them.
Read case studyBuilding a platform where being late is the same as being wrong?
Tell us what you're building, and we'll tell you honestly how we'd approach it.