How MRT Fare Systems and Origin-Destination Data Work Using Mathematics

A fare gate sees a tap. The transport system eventually sees a journey.

Between those two statements sit identity tokens, timestamps, origin and destination, transfer rules, distance, backend processing, fare policy, privacy and a data model of how the city moves.

A passenger taps into an MRT station.

A transaction event is created.

entry event = [payment token, station, time]

Later, the passenger taps out.

exit event = [payment token, station, time]

Pair the correct entry and exit and the system can construct one rail trip:

trip = [origin, destination, entry time, exit time, distance, fare class]

At city scale, millions of such records become a demand field.

Singapore’s current public fare system is distance-based. MOT states that commuters pay according to distance travelled within a continuous public-transport journey, subject to transfer rules. The SimplyGo account-based ticketing system allows bank cards, mobile wallets and account-based travel cards to be used, with fare processing performed at the backend rather than entirely at the gate.

LTA DataMall also publishes monthly aggregated passenger-volume datasets by origin and destination train stations, while more detailed farecard transaction datasets are available on request in anonymised form for appropriate planning uses.

This article owns the mathematical layer from tap → trip → fare → aggregated demand evidence. It does not own the passenger’s best route through the network; that belongs to How MRT Routes and Transfers Are Optimised Using Mathematics. The permanent system hub is How MRT Works | It’s Mathematics.

The RFE — Why Does the Fare System Exist?

The weak answer is:

collect money

Revenue matters, but the system must do more.

It must:

identify the correct travel event without exposing unnecessary personal information;
apply the applicable fare rules consistently;
process taps quickly enough that payment does not become a station bottleneck;
support concessions and policy schemes;
allow legitimate corrections and refunds;
produce reliable aggregate evidence about travel demand.

The RFE of the fare system is to convert a physical journey into a fair, auditable payment event while preserving enough trustworthy demand evidence to help the transport system understand how people actually move.

Prompt 1 — How Are Entry and Exit Events Paired?

For payment token c, suppose an entry occurs at station i and time t_in.

An exit occurs at station j and time t_out.

Trip(c) = (i, tin, j, tout)

Journey duration is:

T = tout − tin

The system checks whether the pair is structurally plausible under fare and transfer rules.

A basic integrity condition is:

tout > tin

and the same token or recognised payment identity must represent the journey correctly.

MOT has publicly explained one subtle SimplyGo problem: different mobile devices linked to the same bank card can present different digital identifiers. That is why using one phone to tap in and a different device to tap out cannot always be reconciled automatically as one journey.

The mathematical lesson is identity equivalence.

same funding source
≠ necessarily same transaction token

A payment system must operate on the identifiers it can legitimately observe, not on hidden relationships it does not possess.

Prompt 2 — How Does Distance Become Fare?

Singapore uses distance-based public-transport fares.

Let travelled fare distance be d.

A generic piecewise fare function is:

Fare(d,c,t) = applicable fare rule
for distance d,
commuter category c,
and any time/policy condition t

The actual fare table is policy, not a universal mathematical law.

The important structure is that distance is mapped through a tariff function.

A continuous journey can contain several public-transport segments.

Journey = Segment1 + Segment2 + ... + Segmentn

Transfer rules determine whether those segments belong to one journey or separate journeys.

In May 2026, MOT reiterated that a 15-minute walking-transfer limit applies between different train stations for eligible transfers, including certain interchange situations requiring exit and re-entry. The rule exists to distinguish a continuing journey from a new journey for fare purposes.

Prompt 3 — Why Does Account-Based Ticketing Create a Latency Trade-off?

In card-based ticketing, some value and transaction logic can reside directly on the card and reader.

In account-based ticketing, the gate records a tap and backend systems perform later processing.

tap
→ local validation sufficient for gate flow
→ backend transaction processing
→ fare calculation / account update
→ history and notifications

This creates a systems trade-off.

If the fare gate waited for a slow remote backend check before every passenger could exit, transaction latency could become passenger queueing.

Let gate service time be s seconds per passenger.

One gate’s theoretical throughput is:

μgate = 1/s passengers per second

If s=0.6 s:

μ ≈ 1.67 passengers/s
  ≈ 100 passengers/min

If a remote check added only 0.4 s and total became 1.0 s:

μ = 60 passengers/min

A seemingly small transaction delay cuts theoretical gate throughput by 40%.

This is why MOT has described backend latency as a real design consideration in account-based ticketing.

A payment system can be financially correct and operationally wrong if it makes the gate too slow for the passenger field.

Prompt 4 — How Do Trips Become an Origin–Destination Matrix?

Aggregate trip records can be counted by origin i and destination j.

Oij(t) = number of journeys from station i to station j during time period t

For n stations, O is an n×n matrix.

Row sum gives departures from an origin:

Oi,out = Σj Oij

Column sum gives arrivals at a destination:

Oj,in = Σi Oij

DataMall’s current public datasets include monthly passenger volume by origin–destination train stations and station tap-in/tap-out volumes.

These aggregated datasets answer questions such as:

Which station pairs generate strong demand?
Which stations are mainly origins in the morning and destinations in the evening?
How does demand differ weekday versus weekend?
How does a new line change travel patterns?

They do not automatically reveal the exact route taken when several paths connect the same origin and destination.

Route assignment requires the separate routing model.

Prompt 5 — How Does OD Data Become Capacity Planning?

Origin–destination demand can be assigned to candidate routes.

Let p_ijr be the fraction of OD demand i→j using route r.

Σr pijr = 1

Passenger load on track section e is:

Le = Σi Σj Σr Oij pijr I(e∈r)

where I(e∈r)=1 when route r uses section e.

This converts fare-derived journey demand into section loads.

Compare those loads with delivered train capacity and the system can identify time-and-direction bottlenecks.

The Passenger Capacity pillar owns the next step.

Prompt 6 — Why Must Fare Data Be Privacy-Aware?

A travel record can be useful without needing to identify a named person.

For planning, the most important fields may be:

origin
+ destination
+ time bucket
+ passenger category where authorised
+ distance
+ aggregate count

DataMall’s on-request farecard dataset describes card numbers as anonymised.

Aggregation further reduces unnecessary granularity.

Suppose an OD cell has count n_ij.

Publishing aggregate counts rather than individual trajectories changes the data product from:

who travelled when and where

towards:

how many journeys occurred between these places in this period

The principle is data minimisation:

Keep enough structure to answer the transport question; do not preserve personal detail merely because the system could.

Prompt 7 — How Do Errors Enter Fare and OD Data?

Possible data-quality problems include:

missing tap-out,
different device used at exit,
duplicate event,
incorrect timestamp,
station identifier change,
backend processing delay,
refund or correction after initial transaction.

For observed journey duration T:

T = tout−tin

an implausibly negative or extremely long value can be flagged for review under authorised rules.

Aggregate OD counts can be checked against station totals.

Σj Oij ≈ station i entries for the same cohort and period

Disagreement can reveal missing records, incompatible filters or data-processing errors.

The correct action is reconciliation, not silent imputation without evidence.

Prompt 8 — How Can Fare Policy Change Demand?

Fare systems do not only record behaviour.

They can influence it.

If effective journey cost is:

Cgeneralised
= βtime T
+ βfare F
+ βwalk W
+ βcrowd X

a fare incentive can change the attractiveness of a time period or route.

MOT’s current fare policy includes distance-based fares, concession structures, pre-peak and Travel Smart Journey measures. Since 27 December 2025, all commuters can sign up for Travel Smart Journeys, which can reward eligible alternative travel choices on selected corridors.

The effect can be measured:

ΔDemand = demand after policy − baseline demand

But causal interpretation requires care because weather, school holidays, new lines and other changes may occur at the same time.

A proper evaluation compares against an appropriate counterfactual rather than assuming every observed change was caused by the fare intervention.

A Complete Fictional Fare-to-OD Example

Consider 10,000 fictional rail trips in a morning period.

Three origin–destination pairs dominate:

A→D = 2,800
B→D = 2,100
C→E = 1,600
other = 3,500

A→D has two possible routes.

Route 1 share = 70%
Route 2 share = 30%

Assigned passengers:

Route 1 = 1,960
Route 2 = 840

If a new connection reduces generalised cost on Route 2, its share rises to 50%.

new Route 1 = 1,400
new Route 2 = 1,400

The OD demand did not change.

Section load did.

This is why fare/OD data and route assignment must remain separate concepts.

The Fare/OD Deletion Tests

Remove token continuity: entry and exit cannot reliably become one trip.
Remove timestamps: journey duration and transfer logic disappear.
Remove fare distance: distance-based charging loses its input.
Remove transfer rules: several segments cannot be classified as one or multiple journeys.
Remove gate throughput: backend correctness can create physical queues without consequence.
Remove OD aggregation: millions of taps never become city-scale demand evidence.
Remove privacy boundaries: planning value becomes an excuse for unnecessary personal detail.
Remove data-quality checks: missing or mismatched taps quietly distort demand.
Remove route assignment: OD demand is mistaken for actual section load.

The Fare-System Paradoxes

The same bank card can produce different device identifiers.
Moving fare computation to the backend can improve payment flexibility while making immediate gate-side display harder.
A faster transaction can be more valuable to the railway than an immediate detailed calculation at the gate.
Individual transaction data become more useful for planning when transformed into less personally specific aggregates.
The same OD matrix can produce different line loads when route choices change.
A fare policy can become an operations tool by shifting when or how passengers travel.

The Fare and OD Audit

What event constitutes entry?
What event constitutes exit?
What token or identifier links them?
Can different devices create different identifiers?
What transfer rules define one continuous journey?
How is fare distance computed?
What passenger category or concession applies?
What calculation must happen locally versus at the backend?
How much gate latency is acceptable before queues grow?
How are missing or mismatched taps handled?
How are refunds and corrections reconciled?
What OD aggregation is needed for planning?
What privacy detail is unnecessary for the planning question?
How is OD demand converted into route and section load?
What policy change could alter demand itself?
What evidence would show the fare or OD model is wrong?

The World Return — When Taps Answer the Demand Forecast

Planning predicts:

OD demand
station entries
station exits
time-of-day peaks
route shares

Fare records return:

actual aggregated trips
actual time profile
actual OD counts

Residual:

eij = Oij,observed − Oij,predicted

If a new station generates much more demand than forecast, future timetable and station planning should learn.

If a fare incentive produces less behavioural change than expected, the demand-response model should learn.

If aggregated OD counts disagree with station entry totals, the data pipeline should be checked before the discrepancy becomes planning truth.

A fare system becomes part of transport intelligence when its payment records can return to planning without pretending that a transaction is the same thing as a person.

Conclusion — A Tap Is the Smallest Recorded Shadow of a Journey

A passenger taps in.

The gate accepts the payment identity.

The passenger travels.

The passenger taps out.

The system pairs the events.

Distance and transfer rules determine the fare.

At aggregate scale, the trip joins an origin–destination matrix.

That matrix helps explain where the city wants to move.

tap in
→ journey token
→ tap out
→ fare event
→ anonymised/aggregated trip
→ OD matrix
→ demand model
→ capacity and timetable planning
→ future journey

An MRT fare system works when a tap can become a fair payment, an auditable trip and useful aggregate evidence—without requiring the railway to know more about the passenger than the transport job needs.

Key Equations

Trip(c)=(origin,tin,destination,tout)
Paired fare transaction

T=tout−tin
Journey duration

Fare=F(distance,category,time/policy)
Generic fare function

μgate=1/s
Gate service rate

Oij(t)=trips from i to j
Origin–destination matrix

Oi,out=ΣjOij
Origin total

Oj,in=ΣiOij
Destination total

Σrpijr=1
Route-share conservation

Le=ΣiΣjΣr Oij pijr I(e∈r)
Section passenger load from OD demand

Cgeneralised=βtimeT+βfareF+βwalkW+βcrowdX
Generalised passenger cost

eij=Oobserved−Opredicted
OD World Return residual

Reader-safety and privacy note: This article uses aggregate and anonymised public-data concepts only. It does not provide methods for identifying individual commuters, defeating fare systems, bypassing payment, accessing private transaction records or linking anonymised travel data back to named people.

How MRT Fare Systems and Origin–Destination Data Work Using Mathematics: How a Tap Becomes a Journey