How Dhaka Metro Works in 2026

How Dhaka Metro works from your first tap to the exit

A passenger journey through tickets, smart cards, train control, platform doors and announcements

You arrive at Mirpur 10 with your phone in one hand and your card in the other. A tap gets you through the fare gate. Upstairs, a display tells you a train is approaching. When it arrives, the train doors line up with the openings along the platform.

Nothing about the journey asks you to understand radio communication or braking control. Yet those systems have to cooperate before you can take a seat. Following a passenger from entry to exit is a useful way to see what they do.

This article uses an imagined journey, not a timed service report. “Confirmed for Dhaka” identifies publicly documented Line 6 features. “Illustrative mechanism” explains common engineering without claiming access to Dhaka’s internal design.

Figure 1 A conceptual passenger journey from ticketing to exit Equipment appearances and station scenes are illustrative

1 Buying a ticket

If you need a Single Journey Ticket, the Ticket Vending Machine is where software meets cash and moving parts. You choose a destination, pay and collect the ticket. DMTCL describes both single journey tickets and reusable MRT Pass travel.

For station recharge, DMTCL lists TVMs and the Excess Fare Office as MRT Pass top-up points; its April 2026 Line 6 FAQ also describes online payment followed by AVM use.

Figure 2 Buying a ticket joins payment processing to physical delivery Illustrative transaction flow

Illustrative mechanism: the application works with payment hardware and a dispenser. It must distinguish “payment accepted” from “ticket delivered”. A dispenser jam after payment is a different failure from rejected money. A useful machine needs an accountable recovery process for each. This is why a ticket machine cannot be designed as a touchscreen alone.

Look more closely at the transaction. Selecting a destination creates an intention to buy. Inserting money creates a payment event. Preparing a ticket creates another event. Delivering it completes the physical handover. Those events can occur seconds apart, and an interruption between them changes what the system owes the passenger.

For an illustrative design, a transaction identifier lets the machine connect these events. The amount accepted, the requested journey and the dispensing result should belong to the same attempt. A restart should not turn an unfinished sale into an apparently successful one simply because the payment was recorded first.

There is a practical difference between a user-facing message and evidence. “Please collect your ticket” tells you what to do. A sensor or device status helps the machine determine whether dispensing happened. Neither alone proves that the whole purchase is correct. Payment, ticket preparation and delivery need a consistent outcome.

A useful way to think about the Single Journey Ticket is as a travel entitlement with rules. A reusable pass carries a continuing relationship with the fare system. They may both be presented to a reader, but their purchase, reuse and exit handling differ. Similar-looking plastic does not mean identical business behaviour.

2 What happens inside the card

A contactless transit card contains a chip and an antenna. The reader’s electromagnetic field lets a compatible passive card communicate without a battery. DTCA’s procurement notice identifies Rapid Pass as a FeliCa IC card; Sony documents FeliCa’s 13.56 MHz communication and controlled access to card data.

Think of stored value as protected application data. Having a compatible radio reader does not automatically grant permission to change that value. The card application, authorized equipment and transaction records together support fare collection. We should not infer the exact MRT Pass chip model, cryptographic keys or memory layout from the Rapid Pass technology name.

Three questions sit behind a secure tap. Which card or application is present? Can the participants establish the required trust? What operation is this reader allowed to perform? Identification, authentication and authorization address those different questions.

A card number can identify a record without being sufficient permission to spend or increase its value. Likewise, a device that can display a balance is not necessarily entitled to recharge it. This separation is the same reason that seeing a bank account number does not let someone transfer money from it.

A physical tap also has limits. The card must remain in a usable radio field long enough for the intended exchange. If you move it away during an update, software needs to determine whether the operation completed. Repeating a request without checking can be as problematic as never retrying it. The exact command sequence belongs to the card application and equipment design.

This is why “the balance is on the card” is only the beginning of an explanation. The system also needs permission checks, evidence of completed operations and a way to resolve uncertainty. None of that can be reduced to an unprotected number printed on a chip.

Figure 3 The card chip reader and access permissions work together An illustrative mechanism rather than Dhaka card configuration

3 Recharging and updating value

You pay for a recharge on your phone while your card is sitting in your wallet. The payment succeeds. Why does the official guide still tell you to tap at an Add Value Machine, or AVM?

Confirmed passenger step: the Rapid Pass online recharge guide requires that tap to add the recharged value to the card. It also allows only one pending online recharge at a time.

Illustrative mechanism: payment confirmation and updating the physical card are separate events. The website cannot rewrite an unconnected card in your pocket. The AVM provides an authorized interaction with the card. A reliable implementation must also deal with an interrupted update and prevent a completed recharge from being applied twice. The published passenger instructions do not reveal the exact database, queue or recovery protocol used in Dhaka.

Figure 4 Online payment and physical card updating are separate steps The AVM requirement is official and the internal processing is conceptual

For an arithmetic example only, imagine a card with 500 units of stored value and an online recharge of 1,000 units. The expected value after successful application is 1,500 units. The point is the transition between those values, not a statement about current recharge limits or fares.

Immediately after payment, “money accepted” may be true while “card updated” is still false. During the AVM interaction, the equipment must resolve whether the value update has completed. If the card was updated but an acknowledgement was lost, blindly applying another 1,000 units would produce the wrong result.

An illustrative design therefore distinguishes a new request, a request awaiting application, an uncertain result and a confirmed completion. These are teaching states; they are not claimed to be Dhaka’s actual database status names. The table shows why one green tick on a payment screen cannot describe every part of a physical-card recharge.

Table 1 Illustrative recharge states These are teaching labels

The engineering goal is to apply one successful payment once, even when a passenger retries or a connection fails. Software engineers often call the retry property idempotency: repeating the same logical request should not create another financial effect. Reconciliation is the later process of checking that payment records, applied value and equipment records agree.

Notice how this changes customer support. A helpful investigation asks which step completed and which evidence exists. It does not assume that every missing balance means payment failed, or that a successful payment proves the card was written. The published AVM rule makes that distinction visible to an ordinary passenger.

4 Getting through the fare gate

The fare gate first needs to decide whether your ticket or card permits entry. Then it has to operate a barrier around a moving person. These are connected jobs with different inputs.

Illustrative mechanism: a reader exchanges data with the ticket, validation logic evaluates the transaction, and a controller commands the barrier. Passage sensors can help determine whether someone is still in the lane. A passenger stopping halfway through should be considered by the gate’s safety logic; a successful card read alone does not describe the whole crossing. Dhaka’s exact gate sensor arrangement and decision sequence are not established here.

A state machine describes what a device is doing now and which transitions are permitted next. In a simplified gate, the states might be waiting, reading, authorized, open for passage and ready to close. A fault is a separate condition with its own response. These are illustrative names, not labels taken from a Dhaka gate controller.

Figure 5 A gate cycle connects ticket validation with physical passage This is an illustrative state model

Why use states instead of a collection of unrelated commands? Because “open the barrier” means different things depending on what has already happened. A second card arriving while someone is still in the lane should not make the controller forget the first crossing. A reader timeout should not automatically be treated as a valid ticket.

Timing also matters. The card transaction, motor movement and passenger movement finish at different speeds. A controller needs appropriate feedback for each. The passenger may have a suitcase, walk slowly or pause to help a child; passage logic must be designed for people rather than an idealized stopwatch.

This does not establish the exact obstruction response of any installed gate. It explains the design question: when information is incomplete, what actions remain permitted, and what should the passenger and staff be told? A visible error and a recoverable transaction are usually more useful than a screen that confidently reports the wrong outcome.

Table 2 A simplified fare gate state model Not Dhaka controller logic

5 Finding out when the train will arrive

On the platform, suppose the display shows three minutes. That is our storytelling example, not a promised interval. An estimate can change when an earlier station takes longer to clear.

Confirmed for Dhaka: DMTCL documents Communication Based Train Control, or CBTC, and automatic train arrival information. Illustratively, passenger information can use operational train progress and the expected remaining journey to calculate an arrival estimate. Knowing where a train is and predicting when it will arrive are related, but they are not the same calculation.

Figure 6 Arrival estimates combine movement progress and expected journey time Illustrative prediction inputs

Imagine two trains at the same point on a route on different days. One approaches a clear station; the other must wait because a train ahead has not finished boarding. Their position can be identical while their arrival times differ. Distance alone cannot describe the remaining journey.

An illustrative prediction combines movement progress with expected running and stopping time, then revises the estimate as conditions change. A long dwell at the previous platform affects the next platform’s prediction. A service regulation decision can do the same. The exact inputs and prediction algorithm used in Dhaka are not established by the public information cited here.

Train location itself should not be imagined as an ordinary phone map refreshed by GPS. Railway control can use onboard movement measurement and fixed references along the route. A reference can correct accumulated position uncertainty; communication makes the relevant information available to other equipment. The sensor combination differs by railway.

The distinction matters when judging a display. A changing estimate can reflect new information rather than a broken screen. An estimate that never changes despite a stopped train can be more misleading. Good passenger information should represent uncertainty usefully, while the movement-protection system continues to perform its separate safety task.

6 Stopping and opening the doors

The train must slow down and finish its stop where the train doorways match the platform openings. Automatic operation can adjust traction and braking against a target stopping position. Protection functions constrain unsafe movement. This is a feedback problem: the control system responds to updated movement information rather than relying only on a timer.

Confirmed for Dhaka: DMTCL describes synchronized platform and train doors. Illustrative safety checks can include a stopped train, an acceptable stopping position and permission to open on the platform side. Their precise implementation and stopping tolerances are not publicly verified in this article.

Figure 7 An illustrative stopping and door permission sequence Dhaka confirms synchronized doors but this is not its published control logic

The platform doors and the entry fare gates should not be confused. One controls access to the paid area; the other separates passengers from the track and provides a boarding opening when a train is available.

In a simplified boarding sequence, arriving at the station does not immediately mean “open every door”. The train has to be in an acceptable state for boarding, and the relevant side must be selected. After an opening command, equipment status matters again: the command alone cannot tell the rest of the railway what physically happened.

The same reasoning applies before departure. If the required door status is unavailable, there needs to be a defined operational response. Passengers see a pause; staff may be dealing with a missing confirmation, an obstruction or another condition. The particular diagnosis cannot be inferred merely from the fact that doors reopen.

This is also where a general-purpose software analogy reaches its limit. Retrying a web request may be harmless. Repeating a physical movement command without understanding the current state can have consequences. Door coordination therefore combines control, feedback and operating procedures. It is not simply two animations starting together.

7 Following displays and announcements

Inside, the display changes to the next station and the speakers play a familiar message. DMTCL confirms automatic next station displays and announcements. A typical Passenger Information System combines configured route information with journey progress, then selects the appropriate screen content and audio.

The voice does not have to be generated live by AI. In a 2024 interview, Kimeya Orin described recording announcements for Dhaka Metro. Selecting a human recording at the right moment is an automation task in its own right. The interview supports that recording history; it does not prove that every message heard today uses the same recording or reveal the train’s exact triggering logic.

Suppose the route direction is changed for the return trip. In a typical system, the station sequence, destination, next-stop information and opening-side messages must remain consistent with that direction. A perfectly clear recording is still wrong if it is selected for the wrong journey state.

One illustrative software approach uses events: the journey starts, a station is approached, a stop is reached, or a service message is requested. Display and audio functions respond to the relevant event and route data. An event is a description of something that happened, not proof that a specific message-broker product is installed in Dhaka.

There is also a human channel. During an unusual situation, staff may need to give instructions that an ordinary next-station recording cannot cover. Passenger information is useful when routine messages, service changes and human communication work coherently. Automatic playback is one part of that task.

Figure 8 Route and journey progress guide display and audio selection Illustrative internal information flow

For a reader interested in software, this is a useful testing example. Check the route direction, journey state, selected text, selected recording and actual playback together. Testing only whether the speaker produces sound misses the meaning of the announcement.

8 Completing the journey at the exit

At the destination, reusable card users tap again; single journey tickets are returned through the exit mechanism described by DMTCL. The fare system has to apply its travel rules and process the journey. We do not need to invent a particular entry record format or claim that every gate contacts a central server on every tap to explain the principle.

Illustrative fare calculation: match the entry and exit stations to the applicable fare table, apply any eligible card rule, authorize the stored value deduction and record the completed journey. This explains the business logic without specifying where Dhaka stores each field or how it commits a card update. An unmatched entry or insufficient value needs an exception process rather than an invented normal fare.

Figure 9 A reusable card journey is processed at exit Illustrative fare workflow rather than Dhaka record layout

Consider a final illustrative case. A passenger remembers entering, but the exit equipment cannot establish a valid matching journey. That is not a situation to solve by inventing an origin or silently subtracting an arbitrary amount. It needs the fare system’s authorized exception process and usable evidence for staff.

The important engineering question is how the system distinguishes a normal exit from an unresolved record. Which operation completed? Which information can be trusted? Can the passenger understand the next step? These questions connect ticketing to the same ideas we saw at the machine and the AVM.

A complete passenger journey is therefore a chain of confirmed outcomes. Payment is accepted, a usable ticket or card is available, entry is permitted, boarding conditions are satisfied, passenger information matches the journey and exit is processed. Each link has a normal path and a way to handle an incomplete one.

For the passenger, the trip ends at the exit. For operators, transaction reconciliation, fault monitoring and preparation for the next service continue. That is what makes the journey interesting: each simple action depends on equipment knowing what happened, what is permitted next and what to do when a step fails.