December 8, 2021 3:35 pm

Who doesn’t care about money?

Everyone cares about money. 

What is the cost of my ride? What discounts am I allowed to use? What discounts are available to me? In the transit standardization world, GTFS-Fares have been a long time discussion, since 2013 and with a proposal in 2018. It is with great excitement that we are presenting GTFS-Fares v2 🎉.

Caption: Xie Lipton on Unsplah

Fares are complicated

When we think of a ride fare, we often think of the price of a single ride or a monthly pass. Unfortunately, fare structures can get much more complicated. The result is that only a limited number of transit agencies are able to describe their most basic fares, while many more agencies find it impractical to describe any of their fares using the current GTFS model. Moreover, the rigid model currently in place proves difficult to extend with the crucial information that transit riders need in the decision making process. This is why GTFS-Fares was ready for a major update. 

GTFS-Fares v2 proposal supports a better and clearer description of the complexity of fares.  

This new version is addressing: 

  • Time-based fares (i.e., peak hour vs off-peak hour)
  • Distance-based fares
  • Rider category discounts
  • Fare containers (i.e., magnetic cards to load money or fares onto)
  • Fare products (i.e., passes that can be used for travel at a cheaper rate, such as a monthly pass)
  • Fare capping
  • Detailed payment methods and locations of payment

Isn’t that wonderful? 🌟 

Read the rest of the blog post to learn about the status of the proposal and get more precise details. 

State of the project 

Over the past few months MobilityData has been supporting early implementors in getting this project up and running. As of now, we have at least 3 producers and 1 consumer for a subset of the proposal. All the details on what exactly is being produced & consumed are here.

Modeling fares introduced complexities greater than GTFS Schedule itself. Being a large proposal, collaboration with external stakeholders is key for making the proposal thorough and actionable from conception to implementation. Moreover, GTFS does not benefit from having regular releases since changes are made based on community-wide consensus. This means that changes take time to model and get right.

MobilityData will continue the efforts in seeking more producers and consumers to stabilize the extension and allow its adoption as widely as possible. Can your organization be an implementer? Reach out to

Caption: Christian Wiedige on Unsplah

GTFS-Fares v2 in details

GTFS Schedule currently describes transit fares using files fare_attributes.txt and fare_rules.txt. File fare_attributes.txt describes a basic fare price, payment, and transfers. File fare_rules.txt associates fares to Origine – Destination itineraries along a route. 

To better represent the puzzle of fares for the agencies, many extensions are being included in GTFS-Fares v2. Here is a summary: 

Extension nameDescription
GTFS-FareDataProcessing of fare cost of individual legs of travel and transfers for different conditions of travel: networks, areas, distance, and timeframes. 
GTFS-RiderCategoriesRider categories that are eligible for certain fares.
GTFS-FareContainersDescriptions of fare media (i.e., paper tickets, smart cards, digital wallets) that can be used to load and use fares.
GTFS-FareProductsFare products that describe the different passes that can be purchased by a rider.
GTFS-FareCappingFares that can be capped after a price threshold has been spent within a timeframe. 
GTFS-TravelRules Travel rules for time prior and locations that certain actions can be done: booking or purchase, show-up or check-in time, validation or stamping, boarding.

GTFS-Fares v2 finds the cost of travel by processing individual legs of travel on an overall journey. 

Using file fare_leg_rules.txt, the cost of each individual leg is determined and the corresponding transfer rules between legs are calculated using file fare_transfer_rules.txt

Example A: Basic fare with transfer

First the cost of the leg is defined in fare_leg_rules.txt

Then, the transfer rules are defined in fare_transfer_rules.txt

In this example the cost to travel a leg is 3.30 CAD, and the fare can be used to transfer for free to other legs of travel for 5400 seconds (or 90 minutes). 

Example B: Flat fare but free for children (rider categories)


STS (Sherbrooke, CA-QC) has a flat fare for 90 minutes but is free for some categories of population. We can use GTFS-RiderCategories and GTFS-FareData to describe such categories of population:

For more examples, such as special fare for location, fare containers, choice between fares and many more, consult the open proposal here: GTFS-Fares v2.

Some uses cases to consult: