ITS Transit Standards Professional Capacity Building Program
Module 10: Electronic Fare Payment Systems
HTML of the Course Transcript
(Note: This document has been converted from the transcript to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included.)
Mac Lister’s Introduction
ITS Standards can facilitate the deployment of interoperable ITS systems, and make it easier to develop and deploy regionally integrated transportation systems. However, these benefits can only be realized if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for promoting multimodalism and interoperability in acquiring and testing standards-based ITS Transit systems for public transportation providers.
I am Mac Lister, Program Manager, Knowledge, and Technology Transfer in the ITS Joint Program Office of the USDOT and I want to welcome you to our newly redesigned ITS Transit standards training program of which this module is a part. We have worked closely with the Federal Transit Administration and the American Public Transportation Association to develop this material. We are also pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new approach to training that combines web based modules with instructor interaction to bring the latest in ITS learning to busy professionals like you.
This combined approach allows interested professionals to schedule training at your convenience, without the need to travel. After you complete this training, we hope that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of the webinars.
ITS Transit Standards training is one of the offerings of our updated Professional Capacity Building (PCB) Training Program specific to transit industry domain to promote the use of ITS Transit standards such as TCIP, Automated Fare Collection, and Transit Management, to name a few. Through the PCB program, we prepare professionals to adopt proven and emerging ITS technologies that will make surface public transportation systems safer, smarter, and greener, which improves livability for us all. This series of online courses based on ITS Transit standards is in addition to a 35-module series available for free on ITS Standards for practitioners in state and local highway agencies and transit agencies. You can find information on additional modules and training programs on the USDOT website at www.pcb.its.dot.gov.
Please help us continue to make improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you again for participating and we hope you find this module helpful.
Jeffrey Spencer’s Introduction
ITS Transit Standards help simplify the complexities, overcome procurement challenges and reduce costs of acquiring ITS systems. I would like to use a simple example to explain how this approach to ITS Transit standards is analogous to our day-to-day life. Imagine that when buying a computer—and you want to buy an upgrade, a printer, or anything else—that you must always buy that same brand at an exorbitant price. Of course, this is not the case because standards have been successfully implemented to allow interoperability. Similarly, transit standards have been developed by transit professionals like you at a national level to encourage competition and limit costs within our industry.
I am Jeffrey Spencer, ITS Team Leader in the Office of Research, Demonstration, and Innovation of FTA within the USDOT and I would also like to welcome you to this ITS Transit standards training. FTA actively supports the development and implementation of transit standards and we hope that you find this series of online courses a useful tool in promoting standardization. We look forward to your participation and input.
Gary Yamamura: This module is part of the ITS transit standards professional capacity building program. This is module 10, electronic fare payment systems. Throughout this presentation, you'll see this activity slide, indicating that there are multiple choice pop quiz following this slide. You will use your computer mouse to select your answer. There is only one correct answer. Selecting the submit button will record your answer and the clear button will remove your answer if you wish to select another answer. You will receive instant feedback on your answer choice.
My name is Gary Yamamura and I’ll be moderating this module. I have more than 35 years of experience in a variety of industries, including financial services, mass transit, and mobile payments. As the owner/operator of two different management consulting firms, I have provided consulting services for numerous clients within those industries and have served as an interim chief operating officer, finance manager, and executive program manager for some of my many client organizations. Throughout my consulting career, I have served as a technical trainer and subject matter expert for payment technologies. I have brought experience and knowledge in the design, specification, procurement, development, implementation of electronic payment systems, including those used in e-commerce, m-commerce, and fare collection.
The target audience for this particular module are those interested in or involved in the purchase of a new electronic fare payment system. This module is a high level introduction to the terminology, architecture, and implementation methods for electronic fare payment systems. It is not intended to be a comprehensive discussion on these complex subjects, nor a general review of the many different aspects of fare collection. The content is designed to be of particular interest to organizations and individuals that are planning procurement of a new electronic fare payment system or upgrading an existing system.
The recommended prerequisite modules are listed on this slide. They fall into three distinct groups: decision makers, project managers, and project engineers. On the next few slides, a suggested curriculum path has been designed and is illustrated for each of these distinct groups. Decision makers. Project managers. And again, project engineers. The next four slides cover the core learning objectives for this module. Since I'm going to be covering the learning objectives in more depth in later slides, I'd like to skip forward to slide 16. The first learning objective for this module is to recognize and identify the commonly used terms in electronic fare payment. There are, of course, many unique terms in this industry. I will be introducing only a few of those to you. Many more are identified in the student supplement to this module. The characteristics, that is, architecture, features, costs, media, benefits, and challenges, etc., will also be covered within this segment.
To help put this information into context, I've provided an architecture diagram for you on slide 17. As you can see in this diagram, it's broken up into several distinct parts, each identified by a simple photograph. This high level diagram is intended to provide you with context for the terminology, methodologies, and other information included in this module. The specific components of any electronic fare payment system will vary, depending on the size and scope of agency operation, the modes of transit offered and the types of electronic fare payment system that is implemented. This illustration is only representative of the typical components of a multimode system. The major components of this system would typically include, starting from the bottom, fare media, readers to interact with that fare media, which we attach to a variety of local devices, in vehicles and in stations, some form of a central computer, moving to the top of the diagram, and in some instances, a regional clearinghouse to support interoperability between a variety of different agencies. Some of the components shown in the options are applicable only to certain types of electronic fare payment systems.
Let's talk about some of those commonly used terms. First and foremost is electronic fare payment system. Also known as automated fare collection system or AFC. This particular term could have several different definitions. For purposes of this training module, the term is used to describe a fare collection system that automatically calculates the fare due, determines that the fare payment media is authorized to be used, and has the required fare or right to ride, collects that fare where applicable, and records the fare payment data for subsequent analysis and reporting. Because such automation generally requires payment media that can be read electronically, electronic fare payment systems typically use—at a minimum—magnetically encoded tickets, contactless smart cards and/or most recently, mobile phones that can communicate via radio frequencies or by displaying a bar code that can be automatically read and validated by transit agency operated equipment. A broader definition could also be applied. However, using any broader definition would also increase the scope of the module beyond the time limits that are allowed.
Let's look at some additional commonly used terms. First of all, there are three basic electronic fare payment system types or methods. First of those are account based systems. This is comparable to credit card systems where the payment media is only a token to access centrally stored and managed account records. We'll talk more about this particular type of system later. Next are card based systems. This is the most common form of electronic fare payment systems today. In this particular type of system, fare product data is stored in the card memory and read and updated by readers in real time with each fare payment. And finally, there are open payment systems. This particular type of system uses contactless bankcards as the primary fare media. It is often combined with either a card or an account based solution to support prepaid fare products.
Another term that you should understand is fare policy. This is the set of rules for a transit agency that defines how, when, and by what methods passengers pay fares. The three most common policy structures are known as flat fare, zone fare and fare by distance. In a flat fare system, the most basic rule is that passengers pay a set fare regardless of the distance that they travel. In a zone fare system, the entire system is broken up into blocs or zones and the passenger's fare is determined by the number of zone boundaries that are crossed. And finally, a fare by distance system is as described, a system where the passenger pays a different fare depending on how far they travel. Distance based fare structures are common for commuter rail systems but are rarely applied to bus or tram systems, due to the difficulty in calculating, collecting fares. Enforcing fare by distance policies is also very difficult for those modes of transit, since fares are typically collected in advance, based on passenger's identification of the planned destination at the beginning of the journey, thus requiring the bus or tram operator to remember where the passenger is supposed to disembark. An alternative to such trust systems is a tap in, tap out program, where passengers are obligated to present fare media at the beginning and at the end of each journey.
System architecture is a term used to define the set of all components of an electronic fare payment system and the methods used to send information between those components. On this slide, I've presented a simple block diagram, which identifies the major components of most electronic fare payment systems. Some of these components would not apply necessarily to all different types of electronic fare payment systems. We'll see this diagram later in the presentation.
Fare value options include closed loop value, which is simply the prepayment of stored funds that can be used for payment of fares, and open loop value, which is prepaid or postpaid funds that can be used to make fare payments as well as purchases at other retail merchants. A simple example of open loop value would be a credit card, which obviously you might be able to use for payment of fares, but could also be used for purchases at any other retail organization.
Data elements and flow. One of the key differences between the different types of electronic fare payment systems is which data elements are used and how that data flows through the system. We'll be using this particular diagram, which I presented on slide 23, to describe how these data elements differ with the different types of electronic fare payment systems.
I'd like to shift now and start talking about the three different types of electronic fare payment systems, their specific features, characteristics and benefits. On slide 24, I presented the same diagram that you saw earlier. In this particular case, it shows data elements that are created within a card based system only. This particular type of electronic fare payment system was introduced in the mid-1990s. At that time, real time data networks were essentially nonexistent, in particular for moving vehicles such as buses. Thus, a centralized solution for fare calculation and payment processing wasn't technically feasible. Accordingly, fare product and transaction history information needed to be stored in card memory and the logic to calculate fare and to read and write card data had to be resident in the end devices, with the onboard buses. Although wired and wireless networks are now readily available, the vast majority of existing electronic fare payment systems are card based today. Since fare product data is recorded in card memory, card must be in close proximity to the authorized reader in order to receive products or any updates associated with the fare payment.
Let's go into more depth on the different features of a card based system. First of all, let's start with the fare media. In most card based systems, the media would consist of either magnetic stripe cards or contactless cards and contactless tickets, also known as limited use tickets. These particular forms of media are important because they have the ability to store data, which can be updated in real time with each fare payment. The fare media is responsible for storing passenger and fare product data, essential elements for the calculation of fare. The fare media is presented to readers. This is a variety of different devices that simply interact and have the ability to interact with the fare media. The readers hold the fare policy data and perform fare calculation. They also have the ability to not just read the data within the fare media, but to update it in real time.
The central computer in a card based system plays a relatively minor role. It is responsible primarily for storing and analyzing copies of the transaction history and generating reports, since it cannot be involved in real time in the calculation of fares or in the processing of fare media itself. The primary security mechanism for most card based systems is that the fare media and readers perform mutual authentication. This generally involves the use of some form of encryption that allows both the reader to verify that the media is valid, but also the media to verify that the reader is valid, since a rogue reader updating data within the card would be problematic for the system. Examples of card based systems today include the Charlie Card Program, or the Metropolitan Boston Transit Authority, the SmartLink program for the Port Authority Trans-Hudson system in New York and New Jersey, and the ORCA system, which is supported by various agencies in the Seattle, Washington region. Some of the key benefits associated with card based systems include, for the agencies, the ability to offer—excuse me—that it is offered by all leading fare collection system integrators and suppliers. Because it is the most common form of the electronic fare payment systems, there is a well-developed set of best practices and the access points can operate despite loss of communication to the central system. Secure transactions with fast transaction time is also a key benefit of this particular type of system. And for passengers, it means that a variety of prepaid fare products are available for purchase and use.
Some of the disadvantages associated with card based systems include, for agencies, that adding, that is, purchasing, fare products requires special devices that are capable of securely reading and writing data to the fare media. This requires a broad network for physical distribution of fare media and the fare products themselves. The central system is not updated in real time and therefore can't be used as a reliable source of passenger account data. A passenger, as an example, may ride the bus all day but go online and see that few, if any, of those transactions have actually been recorded in the central system. The access points require substantial intelligence and processing power and therefore are generally more expensive to buy and to maintain. Just as a reminder, each of those access points or readers must maintain a complete copy of the current fare policy and have all the intelligence to not only read and write data to the card, but actually to process, calculate fares, and determine what updates are required to the fare media.
There are a few technical challenges associated with card based systems. These include, as an example, automatic replenishment or autoload of fare products is a complex process and can often require several days to complete. The reason for this is because the automatic replenishment is often initiated by the central system. Since the central system is not talking in real time to the readers, it must deliver the information not just to one reader, but to every reader, since it also doesn’t know where the fare media will next be seen. Again, this could take several days to complete. Fare policy changes often require the delivery of software changes to every single field device. As mentioned, each reader device must have a complete copy of the fare policy, so even the introduction of a new fare product, such as a monthly pass, would require that software update to be delivered to every reader. And finally, card data security is absolutely paramount, since the central system is not the system of record for data. That is, it does not know in real time what products a passenger has, how much stored value they have to use, which passes are stored on the card and which ones are still eligible to be used for the system. The card itself is the system of record. If someone can change data within the card, then the system of record is broken and breached and therefore the system's security is compromised.
Let's move on to the second type of electronic fare payment systems, known as open payment systems. This particular type of system is the embodiment of many agencies' visions to be more like a retail merchant, participating in a payment system, rather than running the payment system. If not combined with an account based or card based solution, however, all fare payments must be collected as a dollar amount, that is, passes and transfer rights and those types of things cannot be a consideration. In an open payment system, the fare media is contactless bankcards only. The contactless bankcards would be presented to readers, as in any fare payment system, but in this particular case, the reader will simply interact with the fare media to read the static data within the card and it will then determine whether it should approve or deny the fare generally using a negative list, which is stored within the reader. The central system acts as a mechanism to send the bankcard payment authorization to a traditional merchant processor. It will then, if the transaction is declined, update the negative list, and send that negative list update to all of the readers. Security within this system is limited to the card's ability to support that security. Since contactless bankcards are issued by banks and not by transit agencies, we must accept the security that they offer. That particular security, at least today, is that the card is to generate a cryptogram that can be verified at some later point by the issuer. Examples of systems using open payment solutions include the electronic fare collection system of the Utah Transit Authority in Salt Lake, Utah, and the Ventra card system of the Chicago Transit Authority in Chicago.
Features of an open payment system include the use of contactless bankcards as the fare media. This is particularly advantageous to an agency, since it means that someone else is responsible primarily for the issuance of cards. The central system receives and processes batches of fare payment transactions, generates bankcard payment authorization requests, and transmits those to the acquirer. It's also possible, if designed well, that the central system may aggregate two or more payments from the same card to reduce processing costs.
Other features include access points. The access points or readers approve or deny fare payments based on a negative list or a positive list. They provide approval or decline to the passenger based on that list. As mentioned previously, the only media within an open payment system exclusively would be contactless bankcards, and mobile devices emulating contactless bankcards using most likely the near field communication, or NFC protocols.
Benefits associated with open payment systems include, for agencies, the reduction or elimination of the need for agency issued fare media. It may transfer portions of passenger servicing to bankcard issuers and it may also reduce the complexity of the software and field devices since generally it's a simple denial or approval based on a negative list. It may also reduce the need for ticket vending machines in a retail network since, as mentioned previously, open payment systems do not directly support the use of passes or transfer rights or any other types of prepaid media. For passengers, no advance knowledge of the fare structure is required. You simply tap your card when you board the bus or other vehicle or get into a station and the system determines how much fare you have to pay. No special fare media is required and therefore the passenger does not need to obtain that special fare media. Perhaps the biggest benefit of this type of system is the reduction or avoidance of agency responsibilities for operating the payment system since, to a great degree, the actual processing of payments, the responsibility of collecting money from the passenger, etc., are the responsibility of the banks that issue these cards. Some disadvantages associated with open payment systems would include, for agencies, the lack of ability to support prepaid fare products. Most agencies throughout the United States today support at a minimum a 30 day pass for passengers, which is in most cases a popular product for their passengers. Such prepaid fare products would be infeasible in this type of system without the introduction of either a card based or account based solution as a companion to the open payment system. There is limited or virtually no capability to perform a real time card authentication. As mentioned previously, the security associated with contactless bankcards is largely associated with a cryptogram which is generated by the card and then sent to the issuer for verification. Unfortunately, in today's processes, the process of going to an issuer and awaiting a response on an authorization request will often take several seconds and can take even up to 30 seconds to complete. In most transit systems, this type of timeframe would be unacceptable. Open payment systems typically use negative lists to handle the approval or denial of transactions at readers. This particular approach, that is, the use of negative lists to control the approval or denial of bankcard based fare payments is the subject of patent disputes. There's only a small percentage of passengers today that have contactless bankcards, perhaps one of the greatest disadvantages associated with this system. As a result, it is extremely unlikely in today's environment that an agency would be able to support the majority of their passengers since most would not have a contactless bankcard. For passengers, approval or denial may be incorrect, due to lag time for updates to the negative list and field devices.
Some of the technical challenges associated with fare payment systems include frequent and quick updates to the negative list and field devices is essential. As just mentioned previously, if a passenger, as an example, has experienced a denial of a payment, they would then appear on the negative list and would no longer be allowed to use their contactless bankcard to board any other vehicles. If they have subsequently made a payment, it is essential that they be removed from the negative list as quickly as possible. Card reader interface is defined by the networks and may not support the fast transaction times typically required within the transit industry. As of the recording date of this module, the United States is undergoing a process to convert all the magnetic stripe cards over to chip based cards under a specification known as EMV. The introduction of EMV is very likely going to introduce a new protocol for contactless communications, which will be considerably slower than those used by contactless bankcards today. This consideration should be evaluated carefully by the agency before implementing an open payment system.
Let's move on to the third type of electronic fare payment systems, known as account based systems. Similar to credit cards and loyalty systems where payment media is only a token used to identify a centrally stored management account, account based systems for fare payment introduced a similar concept. This is a new type of electronic fare payment system which uses something known as a thin client model, meaning that the field devices are only responsible for collecting information from the fare media and then sending on the request to the central computer, which ultimately makes the decision to approve or deny the transaction. Let's explore that in a bit more depth. The fare media in an account based system can be a variety of different devices, including contactless cards, limited use tickets, mobile devices, and even bar or QR codes. In this particular case, fare media acts solely as a token to access account, that is, data is not written in real time, nor updated in real time on the fare media. Information such as transaction history, fare products that have been purchased, the amount of stored value that's available, any rights that have accrued to the passenger for transfers or discounts, etc., are all information that may be stored within the central system. The reader plays a relatively limited role. It is responsible for interacting with the fare media, collecting information from the fare media and then sending the fare payment request through the central computer and awaiting a response. The central system performs the lion's share of responsibilities in this type of a system. It is responsible for maintaining all the passenger accounts, storing any prepaid fare products that have been purchased by passengers, and is responsible for calculating the fares in real time once a fare payment request is received from any reader in the field. The security associated with account based systems can vary depending on the implementation approach. At a minimum, fare media should be authenticated by the central computer or the reader to minimize the opportunities for counterfeit devices to be introduced. Examples of account based systems include the Ventra program of the Chicago Transit Authority in Chicago, and the new payment technology system of the Southeastern Pennsylvania Transit Authority in Philadelphia. Benefits associated with account based systems include, for agencies, that fare policy changes only need to be made at the central computer. Software in the readers is therefore less complex and therefore easier to maintain. And any networked device can at least theoretically be used to sell fare products, since there is no need to have special devices that can only interact securely with, as an example, contactless bankcards, to facilitate the sale of fare products. For passengers, wider sales network for fare products is therefore theoretically available depending on the ambitions and the capabilities of the agency to set up that network, and fare products and payment history is accessible via any networked device. It's also important to understand that since the central system is making the decision on nearly every fare payment in real time, it should be possible for the central system to update that information and make it immediately available for viewing by not only the passengers, but also agency and other customer service personnel.
Disadvantages for the agency include that offline readers must process fare requests using local negative or positive lists. Online, real time fare processing is infeasible without a fast, reliable communications network. As mentioned previously, we want to have transaction times that are well below those typically associated with credit card transactions. Within the industry, the nominal transaction time is considered to be about 500 milliseconds, or about half a second. It is a relatively new method with very few systems in revenue service and therefore few examples that can be leveraged for agencies considering this type of an approach. Technical challenges associated with account based systems include, as implied previously, the need for a high speed, reliable communications from stations and vehicles to the central computer. There's also a need for relatively complex logic to be employed at the central computer to process the transactions that were previously processed offline and then uploaded to the central computer.
Slide 38 provides a simple chart that provides a side by side comparison of the different key features and benefits associated with the different types of electronic fare payment systems. Most important to this are that the methods for security will vary dramatically from one type to another. The purpose and features and functions associated with the fare media will also vary dramatically from one type to another and the role of the central computer, of course, will change, depending on the fare payment system type selected.
Let's go to our first quiz. Which of the following is a feature of only an account based electronic fare payment system? Answer choices include a) the central computer sends a negative list to each reader, b) data store on the card is read and updated by the reader, c) contactless bankcards are the primary fare media, or d) the central computer is responsible for fare calculation.
Let's review each of those answers. The correct answer is d) the central computer is responsible for fare calculation. In an account based electronic fare payment system, the central computer holds all of the passenger, fare product, and history data and fare processing rules and uses this information to calculate the fare due for each fare payment. Answer a) the central computer sends a negative list to each reader is incorrect. This feature is applicable to all three types of electronic fare payment systems. B) data stored on card is read and updated by the reader is also incorrect. This feature is unique to a card based electronic fare payment system. And c) contactless bankcards are the primary fare media is incorrect, since this feature applies primarily to an open payment electronic fare payment system. Now that you've completed learning objective one section, you should be able to recognize and identify the commonly used terms in electronic fare payment, and the characteristics, architecture, features, costs, media, benefits, and challenges, of the leading electronic fare payment system methodologies.
Let's move on to learning objective two. The leaning objective number two is to recognize and identify the applicable national and international standards, rules and regulations for electronic fare payment systems and the benefits of applying them. It's also to recognize and identify where the lack of applicable standards create logical gaps in fare payment architectures that must be addressed by the agency.
Let's take a closer look at some of those standards, rules, and regulations. There are number of national and international standards and specifications that may be applicable to an electronic fare payment system. Applicability of these standards and specifications will vary depending on the type of system that you select. These standards and specifications unfortunately to not prescribe an end-to-end architecture and therefore may not ensure interoperability of systems or components. Let's take a look at several of those. Probably the most well-known of the international standards applicable to electronic fare payment systems is the ISO/IEC 14443 identification card standard, also known as contactless integrated circuit cards and proximity cards. This is a widely adopted standard for short range communications between contactless smart cards and readers. It applies to the physical and virtual cards and readers and is applicable to all different types of electronic fare payment systems.
A companion to that ISO 14443 standard is the ISO/IEC 7816 standard, specific to identification card and integrated circuit cards. This particular standard defines the physical dimensions of smart cards and a common set of instructions that should be supported. It is combined with ISO/IEC 14443 to help promote interoperability between cards and readers and is applicable to all electronic fare payment system types.
The ISO/IEC 18092 standard is more commonly referred to as near field communications or just simply, NFC. It defines the methods to enable short range communications between, in particular, mobile phones and readers, or mobile phones and cards. It is applicable to any electronic fare payment system where mobile devices may be used with the NFC protocol. Another international standard is the ISO/IEC 21481. This particular standard is a companion to the 18092 standard and falls under the umbrella of near field communications or NFC. In particular, it defines short range communications between two different types of devices known as active and passive. It is applicable to any electronic fare payment system where mobile devices using NFC are applied.
Another common standard used within electronic fare payment systems is the ISO/IEC 8583. This venerable standard defines the format and content of messages exchanged for bankcard transactions. It is applicable to any electronic fare payment system where bankcards are used either for fare payments or for purchases of fare products or cards of any kind.
The ISO/TR 14806 is not a standard but instead is a technical report. It defines the requirements for payment applications in a multi-application contactless bankcard use for fare payments. It describes the possibility, understand it again, this is not yet a standard, of adding data to a contactless bankcard to facilitate things like prepaid fare products or real time verification of cards, etc. It is applicable to an open payment electronic fare payment system, including those that also support card based fare payments.
ISO 24014 is a standard that includes rules for development and operation of a regional fare collection system. It is applicable primarily to card based electronic fare payment systems. Another standard which is becoming well known in the United States, but has already been deployed thoroughly throughout the rest of the world is EMV, also known as the Europay MasterCard Visa specifications. This particular set of specifications defines the use of chip based bankcards with merchant payment terminals. As mentioned previously, it's already been adopted widely internationally, and the U.S. adoption began in 2013 and is expected to continue for the next several years. It is applicable to open payment electronic fare payment systems and any electronic fare payment system that accepts bankcards for payment of any type of purchase.
There are a variety of specifications, known as the bankcard network specifications for contactless credit and debit cards. The card networks, including American Express, Discover, MasterCard, and Visa, have developed contactless card products which are used in the United States. Each of these products has a distinct product name, as an example, ExpressPay for American Express and ZIP for Discover. There are several separate applications that are required within the reader or the central computer to enable communications and interaction with these cards. The rules for card acceptance will also vary by network. Another standard that is important for all electronic fare payment systems is the payment card industry data security standards, more commonly known as PCI DSS or simply PCI. This set of standards defines the rules for securing bankcard data in any system that touches that data or stores it. It is applicable to all electronic fare payment system methodologies where bankcards are accepted in any form.
The APTA contactless fare media system standard, or CFMS, is a national standard developed by the American Public Transportation Association, specifically for card based systems. It is applicable therefore only to card based fare payment systems.
The transit communications interface profiles or TCIP was developed to be the ITS standards for transit management communications. It introduces a standard framework for exchanging data among various transit modules and systems. It includes a library of data elements, data frames, messages, and dialogs using the extensible markup language, or XML. It should be noted, however, that although TCIP has been adopted for use in other forms of transportation systems, its use in fare payment systems has not yet been formally approved.
On slide 57, I have listed a few other standards which are either evolving or largely applicable outside of the United States. The first of those is the integrated transport smartcard organization or ITSO. This is a standard largely used in the United Kingdom and is a standard for cards and terminals in a card based electronic fare payment system. Calypso is a European standard for card based electronic fare payment systems, where the media uses a microprocessor based chip to ensure exceptionally fast, and more importantly, very secure transactions. It is one of the most widely adopted international standards for electronic fare payment systems with project implementations in Europe, China, Canada, the United States, and even Latin America. And finally, CIPURSE, this is an evolving standard which is intended to be an open standard for card based fare collection systems which is focused primarily on the card data structure and card to reader security scheme.
Let's take a different look at each of these different types of electronic fare payment systems. For purposes of this segment, I'd like to use this diagram as shown on slide 58. The diagram shows that there are various components of a fare payment system, including the fare media, the readers, local devices, central computer, and optionally, the regional clearing house and payment processors. Within this segment, I'm going to show how this diagram will illustrate the movement of data through the systems and how the international standards apply. On this particular slide, the blue ovals show standards and where they are applicable to different components of the system. As an example, in the upper left hand corner, you see the ISO/IEC 14443. This particular standard defines the communication protocol between the fare media and the readers.
As evidenced by the information on the previous slide and on this chart on slide 59, you can see that there are a variety of gaps within the existing standards. These gaps create holes within an architecture if the standards themselves were used exclusively. Because of these gaps, it is essential that the agencies that are developing a specification for a new fare payment system, or an upgrade to an existing fare payment system, recognize the gaps and develop specifications, or processing rules, or performance standards so that any organization, company, or vendor supplying the system will understand how to fill those gaps. As one example, inter-system security. There is today no standard which defines a specific comprehensive security standard for system-to-system interoperability. It is important therefore for the agency to develop a set of mitigation tactics, including defining regional security rules and require adherence to widely adopted security encryption specifications such as the triple DES or AES standards. Another key gap in the standard would be component plug and play. Although it is highly desirable for any agency to be able to swap out components of the system and to procure new replacement components from any vendor, it is often difficult, if not impossible, to achieve this based on standards alone. The lack of device-to-device messaging standards as an example will inhibit the introduction of devices from new suppliers. It is therefore advisable for any agency to require open, that is, documented royalty-free interface specifications between all components of their system.
Let's move on to our second quiz. Which of the following electronic fare payment system features does the transit communications interface protocol or TCIP cover? The answer choices include a) local device to central computer message structure, b) card data structure, c) card to reader communication protocol or d) physical requirements for contactless farecard? Let's review the answers. The correct answer is a) local device to central computer message structure. The content and structure of messages exchanged between a field or local device and the central computer are included in the TCIP standards. B) card data structure, is not correct since this feature is defined in the APTA CFMS. C) card to reader communications protocol, is also incorrect. This feature is defined in the ISO/IEC 14443 standard. And finally, d) physical requirements for a contactless bankcard is incorrect. This feature is defined in the ISO/IEC 7816 international standard. Now that we've completed this section of the module, you should be able to recognize and identify the applicable national and international standards, rules and regulations for electronic fare payment systems and the benefits of applying them. You should also be able to identify where the lack of applicable standards create logical gaps in fare payment architectures that must be addressed by the agency.
So let's move on to learning objective number three. This objective is to evaluate the options for electronic fare payment by assessing the unique implementation issues of the transit industry and applying case studies of leading edge electronic fare payment technologies and methodologies.
Let's take a look first at the account based system. As mentioned previously, I'm going to use a diagram or simple box chart to show the movement of data within the various components of an account based system. As you can see in the chart on slide 65, each of the boxes identified as fare media, reader, local device, and central computer, has another box inside of it listing the types of data elements that would typically be generated by or pass through the particular component. In this particular type of system, the first step would be fare payment to be introduced to a reader. The card and the reader would then perform some form of card authentication. The reader would extract the card ID and data from the card and then generate a fare payment request using card and reader data. Step five of this process, the reader would transmit fare payment request to the central computer, perhaps through or via the local device, such as the ticket gate or farebox, onto the central computer. In step six, the central computer would receive the fare payment request, retrieve the account record from the central database, and calculate the fare. Central computer would then determine if fare product or other rights, that is for instance, a transfer right, exists within the account and is available to satisfy the fare. In the eighth step, the central computer would approve or decline the fare payment request and then the central computer would update the account record accordingly. In the tenth step, the central computer would send the response to the reader, again, if necessary, through the local device. The reader would then display an approval or decline to the passenger, allowing the passenger, if appropriate, to board the vehicle or to enter the station. Some of the key implementation considerations of an account based system include fare payment processing. There are a couple of different options. The first, which I've already mentioned previously, is online real time. That is, if a reader sends the fare request to the central computer in real time, the central computer makes a decision and responds and there is a need for a solution for offline conditions. The second option would be an offline batch type of solution. In this particular approach, the reader would make the decision using only a negative or positive list stored within the reader. It would then send a fare payment request on to the central computer but after the passenger was allowed to board or enter the station. The security associated with this type of system would involve some form of authentication at a minimum. For the network, high speed reliable communications are required at least for option number one, but beneficially for option number two as well. And finally, buses, if they're using any type of communications, would probably need to use cellular communications in order to at least enable the reader to send up transaction batches on a very regular basis.
Other implementation considerations include, for the fare products, with option number two, that is the offline batch solution, a negative or positive list in the readers must be updated quickly, or else passengers may be unable to pay a fare. Applicable standards include the ISO 14443 and 7816, and 8583 as well as TCIP. Additional operational benefits include that various forms of fare media can be supported. As mentioned previously, this might include contactless smartcards, limited use tickets, mobile phones displaying bar or QR codes, printed bar or QR codes, or mobile phones using NFC. The only limitation would be the capabilities of the reader. Bring your own device is certainly a possibility with an account based system. Bring your own device meaning that the passenger might have a mobile phone as an example and simply download an application, therefore sparing the agency from having to provide that media to the passenger. If the mobile device can also facilitate the sale of fare products, it can also, therefore, act as a virtual vending machine and limit the use or even the need for the agency to deploy ticket vending machines.
Fare products are digital. Because of that, sale and delivery is possible via any network device. It is possible to deliver fare products instantly, that is, buy now and use now. Since the central system would be facilitating the sale of any fare product, the fare product should be immediately available for use by the passenger. Autoloads are easily accommodated since, once again, only an update to the central system or central record is required and lost cards could easily be blocked and replaced. Centralized fare policy and rules mean that changes are required only in the central system when a fare policy change occurs. There is no need to send updates to every field device since there is no need to store fare policy information or to use fare policy information in those field devices. Accordingly, greater processing power and storage is possible since the central system is a single entity and more money can be spent on that entity to create and support those complex roles.
Let's move on to card based systems. Using the same diagram that you saw previously, you can see that the fare media reader and local device and central computer play quite different roles in a card based system. Within this system, step one is to prepare media to be presented to the reader by the card holder. Fare media and the reader then perform some form of mutual authentication. The reader would extract fare product and payment history from the card and in step four, the reader would then calculate the fare. Step five, the reader will determine if any fare product is available to satisfy the fare and in step six, the reader then updates the fare product and payment history on the card if necessary. Step seven, the reader would display approval or decline to the passenger and then step eight, the reader would record the result. From a passenger perspective, the transaction is now done. However, it must continue on because the information would need to be sent up to the central computer. So in step nine, the reader uploads the transaction records to the central computer, probably in a batch mode, potentially at the end of the day, and potentially through the local device that is the faregate or farebox if appropriate. The central computer would then, in the final step, record, analyze, and archive that information.
Considerations for implementation of card based systems include a robust application in the readers to perform fare calculation. Fare policy changes require software to be downloaded to every field device and transaction time under 350 milliseconds is necessary in general to avoid transaction tearing. Transaction tearing is a process where data has been read from the card, but in the processing or updating, the communication between the card and the reader is interrupted, and therefore the transaction has not yet been completed. In such cases, the passenger may be required to represent their card to reinitiate the transaction, or in a worst case scenario, the data may be corrupted, requiring the passenger to actually visit a customer service center in order to reactivate their card and to clear the data corruption.
Security of this type of system is essential. Comprehensive security key management and distribution process is therefore required and frequent updates are required to the negative list in the field devices so that they are capable of processing transactions in their typical offline mode. The network, there's minimum requirements there since the bandwidth is only required to support batch uploading which can occur at the end of the business day.
Special devices are required to read and write data on the fare media and therefore every entity that interacts with the card, whether to read it for customer service purposes or to read and write to it for purposes of updating the fare products or fare media information, each of those devices must have special information or special readers to interact with the fare media. Fare products can be sold online but it presents some intriguing challenges, since the information is only available online and must be written to the card, as mentioned previously, that information must then be delivered somehow to the readers in the field, a process that can take several days. Applicable standards include the ISO/IEC 14443, 7816, and 8583, as well as the APTA CFMS, NFC, and TCIP standards.
Some of the operational benefits include the ability to bring your own device. Mobile phones using an NFC interface and a custom design application can be used in this type of system. And it may reduce the cost of fare media distribution and replacement as a result. The system works offline by design. Offline field devices can therefore continue to process fare payments for long periods of time if designed to do so. There's extensive experience associated with this type of system. It is the method supported by nearly every major electronic fare payment system supplier and many different cards and devices have already been used in this type of system and therefore have been proven in revenue service.
And now we move to our final type of system, the open payment system. In the open payment system, as previously mentioned, the fare media and the readers play a relative—excuse me—the fare media plays a relatively minor role. Let's go ahead and walk through that entire process. For step one, the fare media is presented to the reader as usual. In step two, the reader extracts the card ID and other data from the card. In the third step, the reader will then check the card ID against a negative or a positive list, which is stored within the reader. It will then make a determination on the fare and display an approval or decline to the passenger. From the passenger's perspective, the transaction is now completed, but of course, we have yet to get an authorization on that transaction, so we need to continue. For step five, the reader would upload a fare payment transaction to a central computer, possibly via the local device. The central computer in step six would receive that fare payment request and would generate a traditional bank card authorization request, which would be sent to the payment processor. In step seven, the payment processor would either approve or deny that authorization request, causing in step eight the central computer to record the result, and if the authorization is declined, to add that card ID to the negative list and to distribute that update to all the readers in the field.
Implementation considerations for this type of system include that the fare policy is restricted to value based payments, meaning that a flat fare, that is, as an example, $2 per ride, is the only mechanism that could logically be supported by this type of system. The security is entirely dictated by the issuers of the cards, which are banks in the United States. Currently today, these types of cards lack a solution for offline card authentication. Accordingly, frequent updates are necessary to the negative list stored in the field devices in order to support the offline approval or denial of those transactions. The network would require reliable, although not necessarily fast transactions, from the reader to the central computer and the central computer to the payment processor. Other considerations include that the fare media is relying entirely on contactless bankcards issued by banks and the passenger's use of those cards. Since most passengers today would not have these cards in the United States in particular, it is necessary to create a solution for all the rest of the passengers that don't have this type of card, or choose not to use one. Fare products in general are not applicable, since this method only supports value based fares. Applicable standards include the ISO/IEC 14443, 7816, and 8583, as well as EMV-contactless, NFC, and TCIP standards.
Some of the operational benefits include the very obvious one, which is bring your own device. For every passenger that has a contactless bankcard, obviously the agency need not issue one to them, nor does the agency need to sell fare products to them since this type of system only supports value based fares. It would also support the ability for a passenger to use a mobile phone with an NFC interface and a mobile app to emulate a bank issued card. Both of these will reduce the cost of fare media distribution and replacement. And the system works by design offline. Offline field devices can continue to process fare payments for short periods of time if designed to do so.
What I'd like to do now is to take a look at three different case studies of agencies that have implemented these types of systems. Let's start with the Chicago Transit Authority's Ventra program. The Chicago Transit Authority's Ventra program is a multi-agency account based system which also has open payment acceptance capabilities. The standard features of this system include an extensive vending machine and retailer network for cards and fare product sales. Some of the unique requirements of the procurement included outsourcing of 100 percent of system operations, maintenance, and risk to the vendor supplying the system. It also included an aggressive, that is, six month transition from the old card based system to the new account based system. And exclusive use of contactless bankcards as fare media. The fare media introduced by the vendor included contactless prepaid MasterCard debit cards that were co-issued with the agency and also acceptance of bank issued contactless credit and debit cards. Some of the implementation issues faced by the agency included very negative public and media reaction to fees associated with the prepaid debit card and some early system glitches occurring shortly after initial implementation. The unreliable communications network also prevented real-time fare calculation, obligating the vendor to implement a second option associated with account based systems, basically doing offline batch type transactions for most of the fare payment requests.
Some of the key benefits associated with the program included, according to the agency's disclosures, over $5 million in annual savings in fare collections systems operations and the transfer of most financial and technology risk to the vendor for the life of the contract. As one example, any change in the fees associated with processing of bankcard transactions is borne by the vendor and cannot be passed on to the agency. There is significantly increased passenger convenience. Fare product and card distribution is now encompassed within a much broader network of retailers as well as vending machines. Fare product purchases are now possible via a website, which was not previously possible, and fare products are available through every one of the sales channels. There's also the ability, of course, to use contactless bankcard in lieu of cash fares on buses and in entering the train stations.
The second case study is for the greater Toronto area, or GTA PRESTO program. This particular fare payment system is a regional card based system, which also has open payment acceptance capabilities. Standard features include contactless card readers on every field device and extensive vending machine and retailer network for card and fare product sales. Some of the unique requirements in the procurement included that it was a multi-agency, multimode regional program. It required open interfaces, allowing for a variety of vendors to provide field equipment, both at the initial implementation and in the future, and it included an open payment acceptance component. Fare media in this system is a clearinghouse issued contactless farecard, but also supports bank issued contactless debit and credit card acceptance. Some of the implementation issues faced by the agency were, the initial reluctance of the largest agency in the region, the Toronto Transit Authority, to participate. There was also negative publicity and severe media reaction to delays, cost overruns, and a variety of change orders that were approved by the agency through the course of implementing the system, and there were a number of early glitches and delays associated with the first medium size agency to implement the PRESTO product.
Some of the key benefits included the creation of a regional fare payments program. Passengers could now transfer from one agency to the next using a single fare payment media. It has significantly reduced bus operator responsibilities for validating the fare products, where previously they had dozens of different ticket types, etc., all requiring visual verification by the bus drivers and tram operators. This has now been made entirely an electronic process. It has significantly reduced the use of cash fares and it has increased passenger convenience by increasing card and fare product distribution capabilities, and enabled passengers to use their contactless bankcards in lieu of cash fares on buses and in stations. It's important to note that in Canada, all bankcards have a contactless interface and therefore most passengers actually would have this type of card already in their wallet.
Our final case study is for the Jacksonville Transit Authority STAR Card program. This is a single agency card based system. The standard features include that it was a single agency program, and included in the procurement, a variety of vending machines and equipment to establish a retail network. Some of the unique requirements were to reduce the bus operator responsibilities for fare collection, to eliminate paper transfer tickets and associated thefts, and to simultaneously introduce a fare policy change, which eliminated a zone-based policy and went to a flat fare. On the previous topic of paper transfer tickets and thefts, it's also important to note that Jacksonville in particular was suffering from a series of assaults against their bus drivers, where passengers were stealing their transfer tickets. Each of the tickets was good for a free ride and therefore became valuable instruments to steal. The fare media in the STAR Card program are agency issued contactless fare cards and also limited use or disposable smartcard tickets. Implementation issues included an unanticipated operational cost, that is, they did not realize they were going to have to hire significant numbers of new staff and people to service all the new ticket vending machines. They lacked a broad distribution network for cards and fare products. Initially, did not feel that the retail network was going to be an important component, and therefore delayed its implementation. And the lead time to purchase smartcards was a surprise to them and actually ended up being several months and ended up delaying some of their implementations.
Some of the benefits associated with the program, and some of these are quite significant, they were able to reduce the fare payment transaction time by 63 percent. Previously, of course, most of the transactions were either a visually verified ticket or in most cases, cash. They reduced boarding time because of the reduced transaction time by about 25 percent, which enabled them to reduce the driving time per route by about one hour. That reduced pollution generated by the buses, since they were on the road less amount of time, and reduced their operating costs, in particular, in fuel savings, by about $60,000 a year, and eliminated a lot of their ticket printing costs, which was costing them about $86,000 per year. It enabled them to introduce a more flexible fare policy, including a greater variety of fare media and fare products. They were able to reduce fare evasion and transfer ticket theft and increase passenger convenience. And also, they discovered that they had dramatically better data, with their old cash and visually verified ticket system, they got very little information on what fare product passengers were using, where they were boarding, etc. Now they have significantly better information and are able to leverage that information to make better decisions about their fare policies and even their routes.
Let's move on to our third quiz. Which type of electronic fare payment system only supports value based fares? The answer choices include a) card based electronic fare payment systems, b) open payment electronic fare payment system, c) account based electronic fare payment systems, or d) all of the above? Let's review the answers. The correct answer is b) open payment fare payment systems. This type of system only accepts contactless bankcards which hold only card specific data that can't be changed. Since other forms of fare products would either need to be recorded in card memory or associated with an account in the central system, an open payment fare payment system can only support value based fares. A) card based electronic fare payment systems is incorrect because it can support a wide variety of fare products, including passes and various forms of prepared stored value. C) account based fare payment systems is also incorrect. This type of system can support a virtually unlimited variety of prepaid fare products, including a variety of different types of passes. D) All of the above is incorrect, since card based electronic fare payment systems and account based systems can each support a wide variety of prepaid fare products.
Now that you've completed this section of the module, you should be able to evaluate the options for electronic fare payment by assessing the unique implementation issues of the transit industry and applying the case studies of some of the leading electronic fare payment system methods.
Let's move on to our final learning objective, number four. For this learning objective, we would like to apply these newly developed skills to assess agency requirements in order to facilitate selection of a methodology and architecture for electronic fare payment system. And to support the procurement and implementation of a new electronic fare payment system or existing system enhancement. On slide 91, you see the systems engineering process Vee diagram. This diagram is used to illustrate the process from concept to production and operation of any type of system. We'll use it to explore a few elements associated with the selection, specification, and procurement of a new electronic fare payment system or defining an enhancement to an existing fare payment system. Only the first four steps will be applicable and will be explored within this module. It's important to remember when developing requirements that there will be corresponding needs to create system verification and validation, that is, test plans, to confirm that those requirements have been met. These are covered in other elements within the Vee diagram, but again, it won't be explored within this module.
The regional architecture and implications. This particular segment of the Vee diagram is used to define the vision and objectives for a regional fare payments program. If your system is for a single agency only, you can skip this step and move on to the next. If you are required to develop a regional solution, you'll want to create a program scope within this segment. That would include the infrastructures necessary to support the regional program, the regional fare products and services that will be supported by the region, and the procurement process and vendor contracts that will be shared across agencies participating in the regional program. It is also essential to define the program governance program, including as examples, stakeholder roles and responsibilities, who will be responsible for system validation and certification, and how revenues and expenses will be shared. This can be a cumbersome and time consuming process and I can't emphasize enough the need to allocate sufficient time and the resources to create your governance program.
Included within this step are the regional architecture and implications, that is, to define the system architecture, the interfaces between systems, and the security mechanisms that will be used. The financial settlement and clearing processes and the performance levels that will be expected for vendors that are supplying systems that will be used within the regional program. The next step in the Vee diagram is the feasibility study and concept exploration. During this phase, you should develop a high level concept for your electronic fare payment system. These would include defining your core objectives. That is, identify and document your business, technical, and schedule constraints. As an example, if you must have the system up and running within a year, 12 months should be a clear requirement under your core objectives. Document your program objectives and your desired implementation schedule, and as other examples, make your preliminary selection of the fare collection type of system you would like to employ. Verify your project feasibility and identify your key risks and secure management buy in and sponsorship.
The third step within the Vee diagram is the concept of operations. During this phase, you'll make a preliminary decision on the electronic fare payment system that you are going to employ. Your core objectives should include the definition of high level requirements for all stakeholders, establishing roles and responsibilities for all participants in the program, ensure common understanding of system concept and requirements, and establish system performance and program success metrics. In most cases this will include developing a concept of operations document, which will evaluate and document these particular elements in depth, and to share that concept of operation documents with not only key stakeholders, but potential suppliers as well.
As mentioned previously, you’ll want to document who all the stakeholders are, and form a core program team to support the rest of the implementation processes. You'll also want to identify and analyze the key components of the existing system and what changes or impacts will be borne by those components once the new system is being introduced. Then introduce a strategy for implementing the new system. Requirements definition. In this next critical step, you're going to be defining requirements for your new system. It is essential that you define business and functional needs. Identify also all your business and technical constraints, such as those associated with budget and schedule, and define your performance service levels. Be certain that all of these requirements remain consistent with your program objectives and encourage supplier innovation. One of the biggest challenges associated with requirements is avoiding the desire or the potential risk of predetermining what type of system you are going to obtain, and to specify that type of system. Your vendors may be able to come up with much more revolutionary and innovative ideas of how to solve for your particular requirements and so it is best, in my opinion, to offer requirements that are open ended, to tell them what your problems are that you'd like to solve and allow them to solve it, rather than determining in advance how you would like to solve it.
It is also important to ensure that your requirements are not prescribing a particular technology or solution, except when required due to technical constraints. Your requirements should not be ambiguous or allow for multiple interpretations and they should not use undefined terms, abbrs, or abbreviations.
Let's take a look at some sample requirements and look at those that are written well and those that are not applicable. During this fourth or final phase of the SEP that we're going to be looking at now, we're going to look at some detailed requirements and how they should be defined and analyzed. As mentioned previously, the requirements should cover both business and technical needs, functionality and appearance, and all aspects of performance. Again, it's important to avoid defining requirements that limit the technology choices of the bidders or that prescribe a method that may not be the optimal choice, or worse, that is technically infeasible or will perform poorly. In this particular example shown on slide 99, requirement number 2 is not a good requirement, because there are multiple contactless bankcard specifications, and as one example, a card can only be compliant with one. Additionally, these are specifications and not standards. The requirement reads, “Applicable components shall be fully compliant with the bankcard standards.” Requirement number 3 reads, “Users shall interact with TDMs using a 10 by 12 touch screen LCD monitor, which supports full color graphics.” This is also not a good requirement, since it creates a specification. You may find that a vendor, for instance, proposes a 9 by 12 touch screen because it is more reliable. Since reliability would be beneficial to the system, specifying a 10 by 12 system and limiting the vendor's choices would be disadvantageous to the agency.
Slide 100 is a repeat of a slide that you saw previously, and it simply presents the various features and benefits of the three different types of electronic fare payment systems, including account based, card based, and open payment solutions. The primary difference between these three types of systems, as a reminder, is where fare calculation occurs. In account based systems, it is generally in the central system. In card based systems, it occurs within the reader, and in open payment systems, fare calculation is not required, since it must be the same by definition for every user.
Let's take a look at some specific requirements and how they might be applied to select an appropriate type of electronic fare payment system for an agency. The first example requirement on slide 101 is, passengers must be able to purchase a fare product, for example, a pass or stored value, on any Internet connected device and immediately use that product to pay a fare. As you can see in the chart below, there is a green checkmark below the word account based, since two of the features of an account based system, fare products sold via any network device and, buy now/use now, are both applicable and meet this requirement. There's a red circle with a slash in the middle of it under card based, because one of the features of a card based system, in particular, fare product sold via agency-specific devices, would not meet the sample requirement. The same is also true for open payment, since the features of an open payment system, that is, that it supports only value based fares, is not compliant with the sample requirement.
Looking at another example requirement, this one reads, devices at points of entry, that is, faregates and fareboxes, shall use security mechanisms such as authentication, that prevent the use of counterfeit payment media before allowing entry or boarding. Once again, we see a green checkmark below the word account based in the chart below, since in account based system, if card authentication is employed, it would meet the sample requirement. Card based systems also has a green checkmark, since mutual authentication is a standard feature of this type of system. Under the open payment system box, we see the red circle with a slash through it, since the two most common features of an open payment system, that is contactless bankcards do not support local authentication, and card authentication may be performed by the issuer later, would not meet the sample requirements.
The third sample requirement reads, “The electronic fare payment system shall only accept for fare payments contactless bankcards that adhere to the ExpressPay, PayPass, payWave, or ZIP specifications.” There's a red circle with a slash through it under the account based box in the chart below, since the types of media used by this system would not include contactless bankcards. Similarly, there's a red circle with a slash through it under card based because the types of media are similar to those in account based and again, would not by default include contactless bankcards. The open payment box is checked because contactless bankcards are the default and in fact, only media accepted within this type of system.
And our final example requirement reads, “Fare payment processing shall support a variety of fare products including, but not limited to, the use of pass products, transfer rights, and discounts to special fare program participants.” There's a green checkmark in the table below under account based since one of its features supports any policy, would meet this sample requirement. Similarly, card based also has a green checkmark since it, like account based, also supports any fare policy. There's a red circle with a slash through it under open payments, since it only supports value based fares and therefore cannot meet the sample requirement.
As a final note, it's important to review the role of security in any electronic fare payment system. A comprehensive security program is essential, and should include for every agency some form of fare media authentication, protection for all messages that flow through the system, protection for all data stored in the system, and rules for accessing that data, encryption key management and distribution, where applicable, system monitoring and testing on a frequent basis, and procedures for handling security breaches, should one occur. The impacts of security breaches can be devastating for any agency as they can be for any merchant. It would not only potentially include the loss of fare revenue and the loss of passenger confidence, but also potentially significant embarrassment for the agency and significant cost to upgrade or potentially even replace its system, or to improve the security system that was originally deployed.
Let's move on to our final quiz. Which of the following is an important consideration when defining security requirements for an electronic fare payment system? The answer choices include a) sensitive data protection, b) protection of cash while being transported to a bank, c) on board surveillance systems for bus vehicles, or d) scheduling of daily fare payment reports. Let's review the answers. The correct answer is a) sensitive data protection. Protection of all sensitive, fare related data is a critical concern for all transit agencies and must be carefully documented in the form of requirements when procuring an electronic fare payment system. B) protection of cash while being transferred to a bank is not correct since, although important, protection of cash is not directly related to electronic fare payment system security. C) on board surveillance system for bus vehicles is also incorrect. Although also important, such surveillance systems are not directly related to electronic fare payment system security. And finally, d) scheduling of daily fare payment reports is incorrect. Report printing and delivery is not directly related to electronic fare payment system security.
Now that we've completed this section of the module, you should be able to apply your newly developed skills to assess agency requirements in order to facilitate selection of a methodology and architecture for electronic fare payment. And you should be able to support the procurement and implementation of a new electronic fare payment system or existing system enhancement. Let's review what we have learned. Electronic fare payment is the automated calculation, validation, collection, recording, and reporting of transactions using some form of electronic validation system and in many instances, electronic media for payment of rides on a public transit system. Electronic fare payment uses a variety of terms and abbrs that are unique to the transit fare collection industry. The three most common types of electronic fare payment systems are, card based, account based, and open payment. Various national and international standards can be applied. However, there are significant gaps between these standards which must be addressed by agencies that are procuring a new, or upgrade to, an existing electronic fare payment system. Careful analysis of agency requirements is required in order to identify the correct electronic fare payment system type. Data security plays a key role in every electronic fare payment system but the methods will vary depending on the type of electronic fare payment system selected.
On slide 112, a few resources are listed that you might refer to in order to get additional information about the various types of fare collection systems mentioned in this module. Additionally, the student guide includes a more comprehensive list of resources, including links to all of the various standards and how to get them and their costs mentioned within this module.
Thank you for participating in this module.
#### End of Module_10_Electronic_ Fare_Payment_Systems.mp4 ####