RailExchangeWhere freight changes hands.One shared record of every rail freight movement — current, structured, and seen only by those entitled to it.
RailExchange is an operational data relay for the rail freight supply chain. Each party publishes what only it knows, once. Every party entitled to that event receives it immediately, as data an application can use.
Built to railML · Ingests what you have today · Australian-hosted
The problem
Rail has been losing the corridor for thirty years.
Melbourne–Sydney is Australia's busiest freight corridor. In the mid-1990s rail carried roughly a quarter of it. Today it carries almost none.
Rail did not lose on distance or capacity. It lost on cost and certainty — the two things a shipper actually chooses on. Both depend on information the industry already holds, but not in a form anyone can act on.
1994–95
28%
Rail share, Melbourne–Sydney
2024
2%
Rail share, Melbourne–Sydney
Source: BITRE / University of Wollongong analysis
Why now
The capital lever has been pulled. Utilisation is what is left.
May 2026
$45b
The Melbourne–Brisbane Inland Rail route was cancelled after costs reached $45 billion and completion slipped past 2036.
The objective survived
Unchanged
Moving more freight by rail remains policy. The existing network is now the only instrument to do it with.
National priority
Data
Data is one of four National Priority Action Areas in the National Freight and Supply Chain Strategy.
Every dollar not going into new alignment has to come back as better use of what is already built. That is a measurement problem before it is an engineering one.
Where it actually breaks
Seven handovers. Seven chances for the record to break.
Every handover is a transaction between two organisations, and today each one is bespoke — no standard in use, no common way of exchanging the data. One service between Melbourne and Brisbane or Perth crosses several below-rail networks, each with its own paths, possessions, notices, capacity and performance, in its own format, through its own channel: roughly twenty separate front doors for one movement.
Forwarder → Terminal
Booking, cutoff time, unit numbers
Terminal → Above rail
Load complete, consist as actually loaded
Above rail → Below rail
Ready to depart, train length, mass and profile
Below rail → Below rail
Handover at the network boundary
Below rail → Above rail
Running events, delay and attributed reason
Above rail → Terminal
Arrival ETA, consist and unload sequence
Terminal → Forwarder
Available for collection, gate booking
The gap, precisely
The data exists. It is not in a form anything can use.
Above-rail operators have asked networks for three things. Most of it is already provided — the gap is not collection, it is form. Documents, portals, notices and email cannot be consumed by an application, and none of it is current at the moment of the query.
| What operators asked for | Provided today as | Why it still does not work |
|---|---|---|
| Capacity available for a new or ad hoc path | Published documents and a request-and-assess process | Not queryable, and not current when the question is asked |
| Short-term availability, including cancelled paths | Notices and email, issued after the fact | A cancelled path is worth nothing by the time everyone hears about it |
| Path utilisation performance | Periodic performance reporting | Aggregated after the period, not reconciled to the operator's own record |
The concept
One record of the movement — structured, current, and readable only by those entitled.
Recorded once
Each event is captured where it happens, by the party who knows it first. No re-keying, no parallel spreadsheets.
Agreed at handoff
Where freight changes hands, both sides see the same timestamp. The dispute is settled before it starts.
Machine-readable
Published as data an application can consume, not as a document a person has to read and re-key.
Always current
True at the moment of the query, not as at last publication. A cancelled path is still worth something.
Read by role
Every party sees the movement through its own lens, and only what it is entitled to see.
The first two make the record true. The next two make it usable. The last one makes it shareable between parties who compete. All five have to hold at once — which is why no single participant can build this for themselves.
How it works
Publish once. Everyone entitled receives it.
Published in
Each party publishes what only it knows — path allocation, running events, consists, gate and slot movements, bookings — from the systems it already runs.
Reconciled once
Events are matched to a single movement, timestamped and attributed, so the same fact is not recorded and argued over in five places.
Relayed out
Parties subscribe to what they need. A ready-to-depart time set by the operator reaches the network and the terminal the moment it is set.
RailExchange relays transactions between parties as well as recording them. It carries no safeworking role and issues no movement authority — but it is a live operational path, not a passive mirror.
Scope
What RailExchange is not.
Not train control
No interface to signalling or safeworking. RailExchange cannot issue, alter or affect a movement authority.
Not a marketplace
It relays and records the bookings your systems make. It does not sell paths, slots or capacity, and sets no price.
Not a data broker
Participant data is never sold, licensed or on-shared. You keep ownership of everything you contribute.
Not a replacement
You keep the systems you have. RailExchange connects them — nothing is ripped out and nothing is migrated.
Being clear about the boundary is what makes the rest credible. RailExchange is an observation and coordination layer, and it earns its place without asking anyone to change how they operate.
The ask
One data extract, and one person to point at it.
No procurement, no integration project and no lock-in. A short session to look at one of your existing data extracts together, and you are live inside two weeks.