Automated fare collection systems

From Policy Atlas
Jump to: navigation, search

Automated fare collection systems allow passengers of transportation systems to pay transit fees in a more efficient manner, through an automated and often mechanized system, to replace conductor fare collection. This policy allows for passengers to pay their fares often in advance of entering the system, cutting down on traffic at the entrance points. The original system was patented in 2000, [1] and has various set ups used in different systems. These systems involve a variation on fare policies and types of riders and trips accounted for. The two primary payment structures are one time payment upon entry, and entry and exit fees. This electronic method allows for generalized and specialized data collection, and cuts down on payment evasion.[2]

CONCEPT


Goals
Example

An automated fare collection systems could be put into use in a whole transit system for a city, on the bus, light rail, and heavy rail systems. On the buses and lightrail this would allow for passengers to simply get on the bus and insert a ticket into a machine on entering to be properly charged. On the subway this would allow allow riders to efficiently and enter and exit the station by paying through an automated system. They could pay for their ticket in a variety of ways before entering the station, and then their ticket or electronic pass would be processed in 1-2 seconds by a machine when entering the system, and then processed on their exit from their destination, at which point they could either be charged a flat rate or a rate for the number of stops they travelled. Other payment methods could be implemented such as reduced rates for low income passengers that could appear the same as a fare pass but be read and charged differently by the machine. This would require greater upfront infrastructural costs but over time save money on paying conductors to collect fares from each passenger individually. This also would allow a transit authority to collect information on which stations or routes had the most traffic at what time, to increase service to specific areas as needed.

Tradeoffs

Tradeoffs of implementing this policy may include:

  1. Fewer jobs provided (conductors not needed to collect or mark tickets).
  2. Expensive infrastructure to set up and maintain.
  3. Requires more complex station design to filter people through payment (on rail).
  4. Learning curve for new technology, assistance needed to explain to some people.
  5. Potential security risk (calculated terrorism target, fewer employees available in emergencies).
  6. Higher costs though more higher paying jobs created (technicians, data analysts).
Compatibility Assessment

If answered yes, the following questions indicate superior conditions under which the policy is more likely to be appropriate:

  1. Is there a bus or rail system in place that needs an efficient way to charge for service?
  2. Is enforcing payment a problem with transit service?
  3. Are fare collectors an inhibiting cost to running this transit system?
  4. Does the transit system need a way to charge for length of trip?
  5. Does the transit system hope to have less money in rotation?
Design

The following questions should be considered when determining how to implement this policy:

  1. Should this system be a flat rate, or charge by length of travel?
  2. Should this system charge varying rates for peak times versus no peak times?
  3. What types of fare cards should be used? Should single use cards with temporary strips be issued, or are there more consistent riders for whom a multiple use reloadable card can be issued?
  4. Can the fare system be unified across trip types for all forms of public transportation in one city or metropolitan region?
  5. Are there groups that should receive lower rates for riding (eg. low income, student, senior)?
  6. Where in the rider experience should the fare collection happen (eg. when entering the station, on the bus or railcar)?
  7. What data should fare system record? This could include information such as time of day, date, length of trip, individual card data, location, and could influence the type of system put in place.

ADOPTION


PolicyGraphics
Adopters

STAKEHOLDERS


Supporters
Opponents

REFERENCES


Research
Resources
Footnotes
  1. https://www.google.com/patents/US6957772
  2. http://www.sciencedirect.com/science/article/pii/S0739885910000788
  3. https://www.sbstransit.com.sg/index.aspx
  4. http://web.mta.info/fares/
  5. http://www.wmata.com/fares/
  6. https://www.sfmta.com/getting-around/transit/fares-passes
  7. http://www.touchngo.com.my/CMS/Personal/TNG-Usage/Transit/
  8. http://istanbulkart.iett.gov.tr/en/istanbulkart/pages/istanbulkart-types/474
  9. https://www.wsws.org/en/articles/2014/07/21/rail-j21.html
Related Policies

PolicyAtlas is maintained by volunteer contributors. For instructions on how to join PolicyAtlas, simply create an account and read about how to contribute a policy.

You can also follow @PolicyAtlas and contact us on: Twitter Icon.png Twitter, Facebook Icon.png Facebook, Instagram Icon.png Instagram and Email.