TRANSACTION SECURITY

Next Generation Transit Ticketing

UL offers a point of view on the impact of cloud computing on Automated Fare Collection transport systems, addressing the sales, inspection and validation processes.


WHY NEXT GENERATION TRANSIT TICKETING MATTERS

Today, AFC systems are in use by a little more than half of the transit systems globally.1

Today, AFC systems are in use by a
little more than half of the transit systems globally.1

Automated Fare Collection (AFC) systems have been in use for several years, growing in popularity around the world because of their ability to streamline transit for travelers, operators and authorities. Today, AFC systems are in use by a little more than half of the transit systems globally.1 While there is still significant opportunity for AFC expansion, cloud computing — projected to grow 229 percent from 2013 through 2020 across platforms, services and applications2 — can advance the next generation of transit ticketing by enhancing the efficiency of the traveler experience and reducing costs for operators and authorities. However, there are a number of issues and potential barriers that must be addressed to bring about cloud-based ticketing.3

 

CONTEXT

AFC systems were first introduced about 20 years ago to help cut costs, control increasing fraud rates experienced by the public transport industry and simplify the traveler experience.4 At many transit agencies, the need to replace old or outdated systems was a critical impetus for considering modernization.5 Transit ticketing is important because the manufacture and distribution of fare media (i.e., forms of payment such as tokens and proprietary transit system payment cards), ongoing equipment maintenance and the collection and processing of cash require transit agencies to spend up to 15 percent of their total revenue on collecting fares.6

 

AFC facilitated a transition from the use of tokens and paper tickets dispensed by staff or self-service vending machines to the use of contactless smart cards, which have now become the global standard.7 Over the past two decades, transit agencies have made significant investments to automate ticketing processes, provide and accumulate data on system usage and reduce staffing costs.8 Today, around 200 systems globally use smart cards or other AFC technologies for ticketing and transit operations.9

 

Travelers have been a key force behind the transit fare payment evolution. Their desire for fast, efficient fare payments, more payment choices (including transit smart cards, contactless payment cards, contactless ID cards and NFC-enabled smartphones10) and additional payment security have pushed the industry to adopt newer technology.11 According to a survey conducted by MasterCard, 47 percent of U.S. commuters would be willing to use their mobile phones to make transit payments, 66 percent say they would likely use a tap-and-go payment method and 75 percent wish there was one payment card that could be used to access all mass transit systems within their local city.”12 Based on the level of consumer demand, Jupiter Research predicts that mobile ticketing across all forms of transit will triple in the next five years.13

 

Although the benefits of AFC to public transport are clear, there is new pressure to further reduce costs and to better address limitations encountered with the initial closed-loop AFC systems (i.e., systems that used a proprietary, single-purpose payment card) relative to regional integration, interoperability, device neutrality, customer convenience and fraud reduction.14 This pressure is evidenced by London’s 2013 decision to phase out the Oyster card system and move to open-loop card payment of fares due to the $195 million annual cost of Oyster.15 The Chicago Transit Authority also introduced the Ventra open fare system in 2013, with the goal of achieving $50 million in savings over 12 years.16  Additionally, one recent study of the public transport industry found that executives who had spent millions of dollars to implement AFC systems had quickly begun to identify risks surrounding the rising cost of maintaining those systems moving forward.17 In today’s increasingly cash-constrained environment, it appears that public transport authorities and operators may be increasingly open to and in need of a new innovative approach to transit ticketing.

In 2013, the city of London phased out the Oyster card system and moved to open-loop card payment of fares due to the $195 million annual cost of Oyster.15

In 2013, the city of London phased out the Oyster card system and moved to open-loop card payment of fares due to the $195 million annual cost of Oyster.15

 

WHAT DID UL DO?

At UL, we have formulated a vision for what we believe is next for transit ticketing. To do this, we leveraged our insights about the needs and emerging issues of the public transport industry — which are grounded in our extensive experience working with transit authorities and operators, helping to implement and secure AFC systems — and coupled this with an assessment of technology trends. Based on this, we see the advances of cloud computing fueling the next generation of transit ticketing, what we refer to as cloud-based ticketing.18

 

We see three areas where the cloud will have the biggest impact on fare collection: identification, fare calculation and payment. We believe that by decoupling these three functions, cloud-based ticketing will allow new developments in any one area to be used in fare collection without affecting the other systems.19

 

The main purpose of identification (ID) in a cloud-based ticketing system is to link the customer to their central transit account. A variety of ID types can be used, including an existing contactless transport card, a contactless bank card, a virtual card on an NFC- enabled mobile phone and a contactless student/citizen card. The key requirements are to secure the ID via authentication and ensure that the infrastructure of the operator supports that form of ID.20

 

Based on validations captured during usage of the transport service, the back-end system (which deals with databases and data processing and launches the operating system’s programs in response to front-end system requests and operations)21 calculates an aggregated fare. The moment of fare calculation can be days after the actual usage.22

 

Cloud-based ticketing supports multiple payment options to fund the transit account; for example, through a pre-paid wallet, a direct debit or a credit transfer. In addition, fare payment in the cloud can be taken directly from the debit or credit bank account of the customer.23

 

In our vision of cloud-based ticketing, the majority of data and logic currently present in transit terminals and fare media would move to the cloud. As a fare medium, the customer would only need a contactless device that stores an ID and offers a means to prove this ID is authentic. The terminals of the transit operator would have their own IDs and would act as a relay between the fare medium and the back end. The actual transaction between the customer

Cloud-based ticketing supports multiple payment options to fund the transit account; for example through a pre-paid wallet, a direct debit or a credit transfer.

Cloud-based ticketing supports
multiple payment options to fund the transit account; for example through a pre-paid wallet, a direct debit or a credit transfer.

and the operator would occur in the cloud. The back end would then implement all the required logic for the primary fare collection processes. A detailed description of how cloud-based ticketing would impact the sales, inspection and validation processes follows.24
    
  1. Sales: the customer purchases a fare product online

  • Fulfillment of the purchase would be limited to linking the fare medium ID with the fare product stored in the back end. Nothing from the purchase would be stored on the fare medium, neither during the sale nor at a later time.
  • The cloud-based ticketing system would support all current and future fare products, ranging from pre-paid and pre-specified options to pay-now, post-paid and post-specified forms.
  • Payment for the fare product would be done using existing payment technology. Both remote and proximity payments can be supported due to the isolation of payment from the rest of the sales process. In other words, the means of ID would be decoupled from the means of payment.
  • Instead of presenting the fare medium to a terminal (i.e., contactless reader) to exchange the ID, a customer could still manually enter their ID. This customer ID would be either engraved on the plastic card or present in the mobile app. Alternatively, the customer could use their email address as their ID.
  • Optionally, transport operators could create dedicated transit accounts in the cloud, as the equivalent of “stored value” on the card. Funding this “wallet in the cloud” could be done similarly to other prepaid accounts.
  • Finally, in the case where cloud-based ticketing is fully implemented, sales would be possible without a ticket vending machine. The actual delivery of the fare product would be stored in the customer’s central account.25

   2. Validation: the customer presents their fare medium to a terminal (e.g. a gate or validator)

  • The fare medium would authenticate itself to the back end, mediated by the terminal. Authentication of the back end to the fare medium would not be required since validation would not change the fare medium. This would eliminate any risk of unauthorized changes on the fare medium.
  • The terminal would request the back end to authorize the travel by sending its own ID, together with the presented fare medium ID.
  • The back end would verify if a valid fare product is related to the presented fare medium ID, and would send an authorization response message to the terminal.
  • The terminal would act upon the receipt of the authorization response message, either opening or remaining closed. Both a gate and a validator would give visual and audio signals. The terminal would also display fare product information to the customer.
  • The back end would then perform actual journey determination, fare calculation and billing. For performance reasons, these activities can be done after the authorization response is sent to the terminal. The back end would be able to perform complex fare calculations like monthly fare capping. Both the time and processing possibilities of the back end are much larger than of a terminal.
  • In case of a direct debit, the back end would be able to charge any kind of account (e.g. a credit, debit, mobile phone or an online payment account).
  • Cloud-based ticketing would also provide the flexibility to implement alternative validation processes (e.g., using long-range communication).26

   3. Inspection:the customer presents their fare medium to the handheld device of the

Revenue Inspection Officer

  • Similar to the validation process, the fare medium would authenticate itself to the back end, mediated by the handheld.
  • The handheld would then send an inspection request to the back end, including the presented fare medium ID and its own ID.
  • The back end would acknowledge the inspection request to the handheld.
  • Based on the validation information, the back end would determine if the customer is entitled to travel. The back end would charge a correction fee to the customer in case no valid fare products were present to justify that travel. This correction fee could be included on the bill in the case of a post-paid option or could be included during the next purchase. In the latter case, the back end would decline any subsequent validation authorization request until the correction fee were paid.
  • In the case of a “not always on-line” handheld device, the customer’s eligibility for the journey would be verified in the back end after the registrations are uploaded (e.g. at the end of the day). The actions in case of unjustified travel would be the same as stated above.
  • Similar to the validation process, cloud-based ticketing would enable alternative inspection processes, such as where long-range communication technology were used. This would entail moving both the ID and the authentication from the inspection device to the back end.27
    Similar to the validation process, cloud-based ticketing would enable alternative inspection processes, such as where long-range communication technology were used. This would entail moving both the ID and the authentication from the inspection device to the back end.27

    Similar to the validation process, cloud-based ticketing would enable alternative inspection processes, such as where long-range communication technology were used. This would entail moving both the ID and the authentication from the inspection device to the back end.27

     

There are two other key areas of impact relative to cloud-based ticketing:

  • A cloud-based ticketing system would support both anonymous and registered customers. Although the anonymous solution would have limited privacy concerns, it is in the operator’s interest to know its customers. Therefore, in return for sharing personal details with the transport operator, the customer could receive benefits like multiple payment options or reduced fares. Additionally, in the registered solution, the privacy of the customer would need to be properly protected.
  • The apportionment, clearing and settlement between the different actors in the fare collection scheme would be unaffected by cloud-based ticketing. Existing clearinghouse systems could be used.28

IMPACT

Cloud-based ticketing is UL’s recommendation for how to advance public transport fare payments, a process that today consumes a significant percentage of the industry’s revenue.29 We believe our vision offers substantial benefits to transport authorities, transit operators and travelers:

 

Transport Authorities

 

Reduced card issuance costs

Since a cloud-based ticketing system can accept multiple kinds of existing fare media, the costs for the transport authority to issue cards can be reduced.

 

Reduced retail network costs

The terminal in a cloud-based ticketing system is just a relay between the fare medium and the back end. This gives transport authorities the ability to use existing contactless readers in laptops or NFC phones or to issue contactless enabled USB dongles. In all cases, the customer would be able to do home loading of purchases.

 

Increased customer loyalty

A cloud-based ticketing system would provide the transport authority with a number of options to set up enhanced loyalty schemes.

 

Advertisement platform

Real-time access to check-in and check-out information is valuable as an advertisement platform to retailers in station areas. On an “opt-in” basis, customers could couple their mobile phone number to the fare medium they use. Retailers would then be able to send messages to these phones, with offers targeted to the specific customer.

 

Value added services

The cloud-based ticketing solution would give the transport authority the opportunity to contract providers of other transport services that are used in the mobility chain of their customers, such as parking, taxi and bike or car rental. Along the same lines, the solution could also be used as a “city card,” covering a wide range of offerings such as libraries, museums, events and public services.30

 

Transport Operators

 

Decreased capital expenditures

Instead of a large number of expensive terminals as are employed in current card- centric, offline fare collection systems, an operator could use simple and comparatively low-cost terminals.

A cloud-based ticketing system would enable a range of self-service options to be provided, significantly reducing the current amount of customer support questions.

A cloud-based ticketing system
would enable a range of self-service options to be provided, significantly reducing the current amount of customer support questions.

 

Reduced total cost of ownership 

Since most of the logic would be implemented in the back end of a cloud-based ticketing system, any change in this logic would affect only the back-end system and not the thousands of terminals in the transport network. For example, the rollout of a new fare product or the upgrade of security would become much simpler and hence, much cheaper.

 

Lower costs for customer support

A cloud-based ticketing system would enable a range of self-service options, significantly reducing the current amount of customer support questions. Additionally, the system would also provide these services to the help desk and gate line staff, better enabling them to deal with customer support questions.

 

Improved operations

In a cloud-based system, the data on actual usage of the public transport would be available in real time. This would allow a transport operator to proactively act or quickly react to situations (e.g., a bottleneck).

 

Flexibility in defining and implementing new products

Instead of complicated implementation and rollout scenarios, new products could be defined centrally (on a few host systems) and quickly rolled out to customers.

 

Travelers

 

Flexibility in used fare medium type

The cloud-based ticketing system would support multiple types of fare medium. The only restriction would be that the fare medium be supported by one of the communication protocols of the terminal.

 

Flexibility in the used payment means

Both during the sales and validation processes, it would be possible to transfer funds directly from a customer account to the account of the operator. The cloud-based ticketing solution would give customers the flexibility to select different accounts, (e.g., bank mobile phone or an online payment account like PayPal) the only requirement would be that the back end implement the payment protocol or simply interface with a payment service provider.

 

Single check-in and check-out

Cloud-based ticketing for a multimodal and multi-operator transport network would eliminate the need for the customer to check in and check out multiple times during the journey (i.e., per operator and per transport mode). To accommodate this, each transport operator would simply upload its fare rules to the back end, where the fare calculation would be completed. After analysis of the completed journey, the back end would apply the appropriate fare rules for the multi-operator and multimode journey, ensuring each operator is properly compensated.

 

Enhanced customer support

The customer would be able to instantly get information from the back end about the check-in or check-out validations that took place, the remaining balance in the transport account or online purchases (by contrast, this process would take hours with current systems due to the time delay between a check-in and the presence of the transaction in the back end). With a cloud-based system, the information could be pulled or pushed. A customer with an internet access device could directly query the back end, while a customer with a mobile phone could receive SMS messages from the back end.31

 

The reality of cloud-based ticketing might seem far off to some transport authorities and operators, particularly those with existing card-centric, offline fare collection systems. However, we believe that public transport systems that follow the path toward a cloud-based future will reap benefits as they progress, and we advise authorities and operators to take steps towards cloud-based ticketing during every regular update cycle of their ticketing infrastructure.32

 

Sources

Get more New Science

+1 847.664.2040