ITS Transit Standards Professional Capacity Building Program

Module 10: Electronic Fare Payment Systems

HTML of the PowerPoint Presentation

(Note: This document has been converted from a PowerPoint presentation to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)

Slide 1:

Welcome - Graphic image of introductory slide. Please see the Extended Text Description below.

(Extended Text Description: Welcome - Graphic image of introductory slide. A large dark blue rectangle with a wide, light grid pattern at the top half and bands of dark and lighter blue bands below. There is a white square ITS logo box with words "Standards ITS Training" in green and blue on the middle left side. The word "Welcome" in white is to the right of the logo. Under the logo box is the logo for the U.S. Department of Transpotation, Office of the Assistant Secretary for Research and Technology.)

Slide 2:

Welcome slide with Mac Lister and screen capture of home webpage. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled "Mac Lister" has a photo of Mac Lister, Program Manager Knowledge and Technology Transfer, ITS Joint Program Office, on the left hand side, with his email address, Mac.Lister@dot.gov. A screen capture snapshot of the home webpage is found on the right hand side - for illustration only - from August 2014. Below this image is a link to the current website: www.pcb.its.dot.gov - this screen capture snapshot shows an example from the Office of the Assistant Secretary for Research and Development - Intelligent Transportation Systems Joint Program Office - ITS Professional Capacity Building Program/Advanced ITS Education. Below the main site banner, it shows the main navigation menu with the following items: About, ITS Training, Knowledge Exchange, Technology Transfer, ITS in Academics, and Media Library. Below the main navigation menu, the page shows various content of the website, including a graphic image of professionals seated in a room during a training program. A text overlay has the text Welcome to ITS Professional Capacity Building. Additional content on the page includes a box entitled What's New and a section labeled Free Training. Again, this image serves for illustration only. The current website link is: http://www.pcb.its.dot.gov.)

Slide 3:

Welcome slide with Jeffrey Spencer and screen capture of home webpage. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled "Jeffrey Spencer" has a photo of Jeffrey Spencer, ITS Team Leader, Federal Transit Administration, Office of Research, Demonstration and Innovation, on the left hand side, with his email address, Jeffrey.Spencer@dot.gov. A screen capture snapshot of the home webpage is found on the right hand side - for illustration only - which is the same screen snapshot from Slide 2. Below this image and to the right is the Federal Transit Administration (FTA) logo.)

Slide 4:

ITS Transit Standards Professional Capacity Building Program

Module 10: Electronic Fare Payment Systems

Gary Yamamura

Slide 5:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

Slide 6:

Instructor

Head shot photo of the instructor, Gary Yamamura.

Gary B. Yamamura
Principal Consultant
Three Point Consulting, Inc.
Oceanside, CA USA

Slide 7:

Target Audience

Slide 8:

Target Audience (cont.)

Slide 9:

Recommended Prerequisite(s)

  Decision-Maker Project Manager Project Engineer
Module 1: Introduction to ITS Transit Standards
Module 2: Transit Management Standards, Part 1 of 2
Module 3: Transit Communications Interface Profiles (TCIP), Part 1 of 2
Module 4: Transit Communications Interface Profiles (TCIP), Part 2 of 2 N/A
Module 5: Transit Management Standards, Part 2 of 2 N/A

Slide 10:

Curriculum Path (Decision-Maker)

Curriculum Path for Decision Maker. Please see the Extended Text Description below.

(Extended Text Description: Curriculum Path for Decision Maker: A graphical illustration indicating the sequence of training modules and where this module fits in. Each module is represented by a box with the name of the module in it and a flow chart showing the logical flow of the modules with the current module boxed in red. The first three boxes are green and aligned horizontally, green signifying "Recommended Pre-requisites." The first box is "Introduction to ITS Transit Standards, Module 1." Below that, connected by a line, is a box with the text "Transit Management, Part 1 of 2." Below that, connected by a line, is a box with the text, "TCIP, Part 1 of 2." From here, the lines branch out into three text boxes that are horizontally sequenced and are in blue, signifying "Optional Modules." These three boxes are: "Traveler Information, Part 1 of 2", "Electronic Fare Payment Systems" outlined in red, and "Transit and the Connected Vehicle Environment/Emerging Technologies, Applications, and Future Platforms.")

Slide 11:

Curriculum Path (Project Manager)

Curriculum Path for Project Manager. Please see the Extended Text Description below.

(Extended Text Description: Curriculum Path for Project Manager: A graphical illustration indicating the sequence of training modules and where this module fits in. Each module is represented by a box with the name of the module in it and a flow chart showing the logical flow of the modules with the current module boxed in red. The first three horizontally sequenced boxes are green. The first box is "Introduction to ITS Transit Standards, Module 1." Below that, connected by a line, is a box with the text "Transit Management, Part 1 of 2." To the right of this box, is "Transit Management, Part 2 of 2". Below that "Transit Management, Part 1 of 2", connected by a line, is a box with the text, "TCIP, Part 1 of 2." To the right of this box, is "TCIP, Part 2 of 2." From here, the lines branch out into four text boxes that are horizontally sequenced. The first two: "Traveler Information, Part 1 of 2" and "Arterial Management & Transit Signal Priority, Part 1 of 2" are green; the last two are "Electronic Fare Payment Systems" outlined in red, and "Transit and the Connected Vehicle Environment/Emerging Technologies, Applications, and Future Platforms." Below "Traveler Information, Part 1 of 2," is the text box "Traveler Information, Part 2 of 2" coded in blue. Below "Arterial Management & Transit Signal Priority, Part 1 of 2", is the text box "Arterial Management & Transit Signal Priority, Part 2 of 2," coded in blue.)

Slide 12:

Curriculum Path (Project Engineer)

Curriculum Path for Project Engineer. Please see the Extended Text Description below.

(Extended Text Description: Curriculum Path for Project Engineer: A graphical illustration indicating the sequence of training modules and where this module fits in. Each module is represented by a box with the name of the module in it and a flow chart showing the logical flow of the modules with the current module boxed in red. The first three horizontally sequenced boxes are green. The first box is "Introduction to ITS Transit Standards, Module 1." Below that, connected by a line, is a box with the text "Transit Management, Part 1 of 2." To the right of this box, is "Transit Management, Part 2 of 2". Below that "Transit Management, Part 1 of 2", connected by a line, is a box with the text, "TCIP, Part 1 of 2." To the right of this box, is "TCIP, Part 2 of 2." From here, the lines branch out into four text boxes that are horizontally sequenced. The first two: "Traveler Information, Part 1 of 2" and "Arterial Management & Transit Signal Priority, Part 1 of 2" are green; the last two are "Electronic Fare Payment Systems" outlined in red, and "Transit and the Connected Vehicle Environment/Emerging Technologies, Applications, and Future Platforms." Below "Traveler Information, Part 1 of 2," is the text box "Traveler Information, Part 2 of 2" coded in green. Below "Arterial Management & Transit Signal Priority, Part 1 of 2", is the text box "Arterial Management & Transit Signal Priority, Part 2 of 2," coded in green.)

Slide 13:

Learning Objective #1

Slide 14:

Learning Objective #2

Slide 15:

Learning Objective #3

Slide 16:

Learning Objective #4

Slide 17:

Learning Objective #1

Recognize and Identify:

Slide 18:

Learning Objective #1

Typical Electronic Fare Payment System (EFPS) Architecture and Components

Typical architecture and components for an Electronic Fare Payment System. Please see the Extended Text Description below.

(Extended Text Description: Typical architecture and components for an Electronic Fare Payment System: A diagram that identifies many of the most common components and services associated with an Electronic Fare Payment System each represented by a colored box that is connected by a colored line to the other boxes. Each of those colored boxes is located within one of seven groups, each of which is represented by a photograph or other graphical image. The first group, in the upper left corner of the diagram is represented by the photograph of an office scene of desks, chairs and computer monitors. Within this group are boxes labeled "Card Inventory Management", "Card Order Fulfillment", and "Card Encoding Machine". The second group, in the upper right corner, is represented by the image of a world globe to the left of the letters "w w w". It includes only one box labeled "Website". Between these two groups are boxes labeled "Payment Processor" and "Central Computer" and underneath those two boxes is an oblong labeled "Network". The next group, on the far left side, centered vertically, is represented by the photo of people working in a call center. Within this group is one box labeled "Customer Service Terminal". The group to the immediate right of the call center box is represented by the photo of a large bus. Within this group are four boxes labeled, from top to bottom, "Depot Computer", "Probing System", "Farebox", and "Reader". The next group to the right is represented by the photo of a train. Within this group are six boxes labeled, from top to bottom and left to right, "Station Computer", "Handheld Validator", "Reader", "Faregate", "Ticket Office Machine", and "Ticket Vending Machine". Under each of the last three boxes is a box labeled "Reader". To the right of that group is the photo of a retail store that includes a sales clerk in front of a cash register and two customers. Within this group are two boxes labeled "Retail Terminal" and "Reader". The final group at the bottom center of the diagram is represented by the photo of a large group of people boarding a tram. Within this group is one box labeled "Fare Media".)

Slide 19:

Learning Objective #1

Commonly Used Terms

Electronic Fare Payment System (EFPS)

Slide 20:

Learning Objective #1

Commonly Used Terms EFPS Types

Slide 21:

Learning Objective #1

Commonly Used Terms

Fare Policy

Slide 22:

Learning Objective #1

Commonly Used Terms

System Architecture

The set of all components of an EFPS and the methods used to send information between those components.

System Architecture. Please see the Extended Text Description below.

(Extended Text Description: System Architecture, relevant description: A simple, box diagram that illustrates the components of a typical Electronic Fare Payment System that perform the bulk of the work in receiving, processing and storing fare payment data. There are four white boxes in the diagram laid out in the straight line, each connected by arrows. These boxes, from left to right, are labeled "Fare Media", "Reader", "Local Device", and "Central Computer". There are two additional white boxes, one above and one below the Central Computer box and each of those boxes is also connected to the Central Computer box by arrows. The box on the top is labeled "Regional Clearing House" and the box on the bottom is labeled "Payment Processor". Within each of the Regional Clearing House, Payment Processor, and Local Device boxes is another smaller white box labeled "Optional". A list of examples appears below the Fare Media, the Local Device, and the Payment Processor boxes.)

Slide 23:

Learning Objective #1

Commonly Used Terms

Fare Value Options

Slide 24:

Learning Objective #1

EFPS Architecture

Data Elements and Flow

Data Elements and Flow: An expanded version of the System Architecture diagram shown on Slide #21 that identifies the specific types of data elements that flow through Electronic Fare Payment Systems. Please see the Extended Text Description below.

(Extended Text Description: Data Elements and Flow: An expanded version of the System Architecture diagram shown on Slide #22 that identifies the specific types of data elements that flow through Electronic Fare Payment Systems. These boxes have been color-coded to identify, where applicable, data elements that are unique to one of the three most common Electronic Fare Payment System types: Card-based (in green), Open Payment (in Orange) and Account-based (in Yellow). Data elements appearing in a white box are common to all types. A key explaining this color-coding scheme appears in the lower left corner of the diagram. The boxes listed the data elements are aligned vertically within each of the six larger boxes, which, as described on Slide #19, are labeled "Fare Media, "Reader", "Local Device", "Central Computer", "Regional Clearing House", and "Payment Processor". Within the Fare Media box is one white box at the top labeled "Card ID & Data" and three green boxes below labeled "Travel Rights", "Fare Products", and "Fare History". Within the Reader box are three white boxes at the top labeled "Reader ID & Data", "Location Data", and "Card ID & Data" followed by four green boxes labeled "Fare Product", "Trxn (Transaction) Record", "Fare Product Update", and "Fare History Update". Below these are two additional white boxes labeled "Fare Disposition" and "Negative List" followed by one green box labeled "Fare Policy". Within the Local Device box are four white boxes at the top labeled "Device ID", "Reader ID & Data", "Location Data", and "Card ID & Data" followed by two green boxes labeled "Fare Product" and "Trxn Record". Below those is one yellow box labeled "Fare Disposition" and the bottom is one white box labeled "Negative List Update". Within the Central Computer box are six white boxes at the top labeled "Device ID", "Reader ID & Data", "Location Data", "Card ID & Data", "Fare Product", and "Trxn Record" followed by a yellow box labeled "Fare Disposition". Below that is one white box labeled "Negative List Update", an orange box labeled "B/C (bankcard) Pymt (payment) Authoriztn (authorization)", and a white box labeled "Fare Policy". Within the Regional Clearing House box are two white boxes labeled "Trxn Record" and "Negative List Update". Within the Payment Processor box are two orange boxes labeled "B/C Pymt Authoriztn" and "B/C Pymt Approval".)

Slide 25:

Learning Objective #1

Card-Based Systems

Feature Overview

Open Payment Systems Feature Overview. Please see the Extended Text Description below.

(Extended Text Description: Open Payment Systems Feature Overview: A further expansion of the System Architecture diagram shown on Slides #22 and 24 that describes certain key components of the system in greater detail or by examples that appear in text boxes most of which have an arrow pointing to one of the original boxes in the diagram. The first text box points to the Fare Media box. The first bulleted item lists "magnetic stripe" and "contactless cards / tickets" as examples of the types of fare media that are used in this type of system. The second bulleted item explains that fare media "stores passenger and fare product data". The second text box points to the Reader box. It explains that the readers "hold fare policy data and perform fare calculation". The third text box points to the Central Computer box. The first bulleted item explains that the central computer "stores and analyzes a copy of transaction history" and it "generates reports". The fourth text box is labeled Security. It contains one bulleted item that explains that the primary security in this type of system "fare media and readers perform mutual authentication". The fifth text box is labeled Examples. The list of bulleted examples of card-based systems are the "Massachusetts Bay Transportation Authority (MBTA) Charlie Card program, Boston", the "Port Authority of New York & New Jersey Trans-Hudson (PATH) SmartLink program, New York and New Jersey", and the "One Regional Card for All (ORCA) program, which various participating agencies in the Seattle, Washington region".)

Slide 26:

Learning Objective #1

Card-Based Systems

Benefits and Disadvantages

Key Benefits

Slide 27:

Learning Objective #1

Card-Based Systems

Benefits and Disadvantages

Disadvantages

Slide 28:

Learning Objective #1

Card-Based Systems

Technical Challenges

Slide 29:

Learning Objective #1

Open Payment Systems

Feature Overview

Card-based Systems Feature Overview. Please see the Extended Text Description below.

(Extended Text Description: Card-based Systems Feature Overview: A further expansion of the System Architecture diagram shown on Slide #22 that describes certain key components of the system in greater detail or by examples that appear in text boxes most of which have an arrow pointing to one of the original boxes in the diagram. The first text box points to the Fare Media box. The first bulleted item lists "contactless bankcards only". The second text box points to the Reader box. It explains that the reader "interacts with fare media" and "approves or denies the fare payment request using a negative list". The third text box points to the Central Computer box. The first bulleted item explains that the central system "sends bankcard payment authorization requests to a Merchant Processor" and it "updates the negative list if authorization is declined". The fourth text box is labeled Security. It contains one bulleted item that explains that for the primary security in this type of system the "card generates a cryptogram that can be verified by the card’s issuer". The fifth text box is labeled Examples. The list of bulleted examples of open payment systems are the "Electronic Fare Collection (EFC) system of the Utah Transit Authority (UTA) in Salt Lake City, Utah" and the "Ventra program of the Chicago Transit Authority (CTA) in Chicago, Illinois".)

Slide 30:

Learning Objective #1

Open Payment Systems

Feature Overview

EFPS type which relies on bank-issued cards as the fare media. Initial fare processing is performed by the field devices and final authorization and settlement are performed later by the central computer.

Central System

Slide 31:

Learning Objective #1

Open Payment Systems

Feature Overview (cont.)

Access Points

Fare Media

Slide 32:

Learning Objective #1

Open Payment Systems

Benefits and Disadvantages

Key Benefits

Slide 33:

Learning Objective #1

Open Payment Systems

Benefits and Disadvantages

Disadvantages

Slide 34:

Learning Objective #1

Open Payment Systems

Technical Challenges

Slide 35:

Learning Objective #1

Account-Based Systems

Feature Overview

Account-based Systems Feature Overview. Please see the Extended Text Description below.

(Extended Text Description: (Animation) Account-based Systems Feature Overview: A further expansion of the System Architecture diagram shown on Slide #22 that describes certain key components of the system in greater detail or by examples that appear in text boxes most of which have an arrow pointing to one of the original boxes in the diagram. The first text box points to the Fare Media box. The first bulleted item is "contactless cards / tickets, mobile devices, and bar and quick reference (QR) codes". The seconded bulleted item explains that the fare media "acts solely as a token to access account information". The second text box points to the Reader box. It explains that the reader "interacts with the fare media" and "sends fare requests to the Central Computer". The third text box points to the Central Computer box. The three bulleted items are "maintains passenger accounts", "stores fare products", and "calculates fares". The fourth text box is labeled Security. It contains one bulleted item that explains that the primary security scheme "Varies but, at a minimum, fare media should be authenticated by the central computer or the reader". The fifth text box is labeled Examples. The list of bulleted examples of card-based payment systems are the "Ventra program of the Chicago Transit Authority (CTA) in Chicago, Illinois" and the" New Payment Technology (NPT) program of the Southeastern Pennsylvania Transit Authority (SEPTA) in Philadelphia, Pennsylvania".)

Slide 36:

Learning Objective #1

Account-Based Systems

Benefits and Disadvantages

Key Benefits

Slide 37:

Learning Objective #1

Account-Based Systems

Benefits and Disadvantages

Disadvantages

Slide 38:

Learning Objective #1

Account-Based Systems

Technical Challenges

Slide 39:

Learning Objective #1

EFPS Methodologies

Comparative Analysis

Methodology Primary Security Scheme Fare Processing Logic Fare Products & Passenger Rights Fare Media
Account-based
  • Card authentication
  • Performed by central computer
  • Fare policy changes made to central computer only
  • Stored in central account records
  • Fare product sold via any networked device
  • Contactless card
  • Limited use ticket
  • Bar/QR code
  • Mobile device
Card-based
  • Card/Reader mutual authentication
  • Performed by reader
  • Fare policy changes downloaded to all field devices
  • Stored on card
  • Fare product sold via agency-specific devices
  • Contactless card
  • Magnetic farecard
  • Limited use ticket
Open Payment
  • N/A
  • Yes/No decision performed by reader
  • N/A: Supports only value-based fares
  • Contactless bankcards
  • Mobile device emulating contactless bankcard

Slide 40:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

Slide 41:

Learning Objective #1

Which of the following is a feature of only an account-based EFPS?

Answer Choices

  1. The central computer sends a negative list to each reader
  2. Data stored on card is read and updated by the reader
  3. Contactless bankcards are the primary fare media
  4. The central computer is responsible for fare calculation

Slide 42:

Learning Objective #1

Review of Answers

A small graphical red and yellow X representing incorrect.a) The central computer sends a negative list to each reader
Incorrect. This feature is applicable to all three types of EFPS.

A small graphical red and yellow X representing incorrect.b) Data stored on card is read and updated by the reader
Incorrect. This feature is unique to a card-based EFPS.

A small graphical red and yellow X representing incorrect.c) Contactless bankcards are the primary fare media
Incorrect. This feature applies primarily to an open payment EFPS.

A small graphical green and yellow check mark representing correct.d) The central computer is responsible for fare calculation
Correct! In an account-based EFPS, 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.

Slide 43:

Learning Objective #1

Summary of Learning Objective #1

After completing this section of the module, the reviewer should be able to recognize and identify:

Slide 44:

Learning Objective #2

Learning Objective #2

Recognize and Identify:

Slide 45:

Learning Objective #2

Standards, Rules, and Regulations

Overview

Slide 46:

Learning Objective #2

Standards, Rules, and Regulations

ISO/IEC 14443 Identification cards - Contactless integrated circuit cards - Proximity cards

Slide 47:

Learning Objective #2

Standards, Rules, and Regulations

ISO/IEC 7816 Identification cards, Integrated circuit cards

Slide 48:

Learning Objective #2

Standards, Rules, and Regulations

ISO/IEC 18092 Information technology, Telecommunications and information exchange between systems, Near Field Communication, Interface and Protocol (NFCIP-1)

Slide 49:

Learning Objective #2

Standards, Rules, and Regulations

ISO/IEC 21481, Information technology, Telecommunications and information exchange between systems, Near Field Communication Interface and Protocol -2 (NFCIP-2)

Slide 50:

Learning Objective #2

Standards, Rules, and Regulations

ISO/IEC 8583, Financial transaction card originated messages, Interchange message specifications

Slide 51:

Learning Objective #2

Standards, Rules, and Regulations

ISO/TR 14806 Intelligent transport systems, Public transport requirements for the use of payment applications for fare media

Slide 52:

Learning Objective #2

Standards, Rules, and Regulations

ISO 24014 Interoperable Fare Management Systems (IFMS)

Slide 53:

Learning Objective #2

Standards, Rules, and Regulations

Europay, MasterCard, Visa (EMV) Specifications

Slide 54:

Learning Objective #2

Standards, Rules, and Regulations

Bankcard Network Contactless Credit and Debit Card Specifications

Slide 55:

Learning Objective #2

Standards, Rules, and Regulations

Payment Card Industry Data Security Standards (PCI DSS)

Slide 56:

Learning Objective #2

Standards, Rules, and Regulations

American Public Transportation Association (APTA) Contactless Fare Media System (CFMS) Standard

Slide 57:

Learning Objective #2

Standards, Rules, and Regulations

Transit Communications Interface Profiles (TCIP)

Slide 58:

Learning Objective #2

Standards, Rules, and Regulations

Integrated Transport Smartcard Organization (ITSO)

Calypso

CIPURSE

Slide 59:

Learning Objective #2

EFPS Architecture

Gaps Created by the Lack of Applicable Standards

EFPS Architecture - Gaps Created by the Lack of Applicable Standard. Please see the Extended Text Description below.

(Extended Text Description: EFPS Architecture, Gaps created by the lack of applicable standards is a simple, block diagram that identifies the elements of electronic fare payment systems (represented by white text boxes) are covered by national or international standards, regulations or specifications (represented by blue oblong shapes) and, separately, which elements are not covered (represented by yellow text boxes). Most of the white and yellow text boxes are grouped within six larger white boxes, which appear in two horizontal rows, one with four boxes and the second, below the first, with two boxes. There is either a white or a yellow text box in between each pair of the larger white boxes. These text boxes represent the communication protocol and/or physical connection that is used to send messages between the systems components that are represented by those larger white boxes. Blue arrows connect the blue oblongs to the white text boxes to identify those system elements that are covered by the standard, regulation or specification listed within the blue oblong. From top to bottom and left to right, the larger white boxes are labeled as "Fare Media", "Reader", "Local Device", "Central Computer", "Regional Clearing House", and "Payment Processor". The first two blue oblongs are labeled "ISO/IEC 14443" and "NFC" and have arrows connecting them to a white text box labeled "Communication Protocol" between the larger white boxes labeled "Fare Media" and "Reader". The next blue oblong is labeled "ISO/IEC 7816" has two arrows connecting it to two different white text boxes each labeled "Command Set". One of those text boxes is in the larger white box labeled "Fare Media" and the second is in the larger white box labeled "Reader". The next blue oblong is labeled "PCI DSS" and has two arrows, one connecting it to a white text box labeled "Bankcard Security" in the larger white box labeled "Central Computer" and the second connecting it to the white text box labeled "Bankcard Data Security" in the larger white box labeled "Payment Processor". The next blue oblong located on the right side of the diagram is labeled "TCIP" and has four arrows, one connecting it to the white text box labeled "Message Structure" in the larger white box labeled "Central Computer", a second one connecting it to the white text box labeled "Message Structure" in the larger white box labeled "Local Device", a third one connecting it to a white text box labeled "Message Structure" in the larger white box labeled "Reader" and the fourth one connecting it to a white text box labeled "Message Structure" in the larger white box labeled "Regional Clearing House". The next blue oblong located on the left side of the diagram is labeled "APTA CFMS" and has three arrows, one connecting it to a white text box labeled "Card Data" in the larger white box labeled "Fare Media", a second one connecting it to the white text box labeled "Message Structure" in the larger white box labeled "Central Computer", and a third one connecting it to the white text box labeled "Message Structure" in the larger white box labeled "Regional Clearing House". The last blue oblong located in the lower left corner of the diagram labeled "ISO/IEC 8583" has one arrow connecting it to the white text box labeled "Bankcard Transactions" in the larger white box labeled "Payment Processor". There is a long text box at the bottom of the diagram, which reads "Yellow boxes indicate EFPS elements not covered by standards".)

Slide 60:

Learning Objective #2

Key Gaps in Existing Standards

Gap Gap Description Mitigation Tactics
Inter-system security
  • Lack of comprehensive security standards inhibit system-to-system interoperability
  • Define regional security rules
  • Require adherence to widely adopted security /encryption specifications (e.g. 3DES, AES)
Component "plug-and-play"
  • Lack of device-to-device messaging standards inhibit introduction of devices from new suppliers
  • Require open (e.g. documented, royalty-free) interface specifications
New media integration
  • Lack of card/reader security standards inhibit use of new payment media in card-based systems
  • Require comprehensive security protocols and management scheme
User Interface
  • Lack of interface standards promotes different experience at different devices/channels
  • Define regional or agency-specific rules for user interface look, feel, and flow
Other
  • System updates/changes
  • Require mechanism for secure, remote software updates

Slide 61:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

Slide 62:

Learning Objective #2

Which of the following EFPS features does the Transit Communications Interface Protocol (TCIP) cover?

Answer Choices

  1. Local device to central computer message structure
  2. Card data structure
  3. Card to reader communication protocol
  4. Physical requirements for contactless farecard

Slide 63:

Learning Objective #2

Review of Answers

A small graphical green and yellow check mark representing correct.a) Local device to central computer message structure
Correct! The content and structure of messages exchanged between a field (local) device and the central computer are included in the TCIP standards.

A small graphical red and yellow X representing incorrect.b) Card data structure
Incorrect. This feature is defined in APTA CFMS.

A small graphical red and yellow X representing incorrect.c) Card to reader communications protocol
Incorrect. This feature is defined in ISO/IEC 14443.

A small graphical red and yellow X representing incorrect.d) Physical requirements for a contactless farecard
Incorrect. The feature is defined in ISO/IEC 7816.

Slide 64:

Learning Objective #2

Summary of Learning Objective #2

After completing of this section of the module, the reviewer should be able to recognize and identify:

Slide 65:

Learning Objective #3

Learning Objective #3

Evaluate the Options for Electronic Fare Payment by:

Slide 66:

Learning Objective #3

Account-Based System

Fare Payment Transaction Flow

Account-based System Fare Payment Transaction Flow. Please see the Extended Text Description below.

(Extended Text Description: Account-based System Fare Payment Transaction Flow is a simple box diagram that uses four of the same system elements included in the diagram previously shown on Slide 22 to illustrate the flow of data through those system elements in an account-based system. There are four large square boxes aligned horizontally across the top of the diagram labeled "Fare Media", "Reader", "Local Device", and "Central Computer". Each of these boxes has a smaller white text box inside of it and is connected to the box next to it with a horizontal line with arrows on each end. The text box within the Fare Media box has two bulleted items: "Card ID" and "Limited card data". The text box within the Reader box has three bulleted items: "Reader data", "Card authentication logic & keys", and "Offline negative list". The text box within the Local Device reads "Optional". The text box within the Central Computer box has four bulleted items: "Fare policy", "Passenger rights", "Fare products", and "Transaction History". Aligned in three columns below the large square boxes are nine white text boxes that describe the flow of data. There are two additional white text boxes at the bottom of the diagram. The first white text box reads "Step 1: Fare media is presented to reader". The second white text box located directly below the first reads "Steps 2: Reader & card perform card authentication". The third white text box located directly below the second reads "Step 3: Reader extracts card ID and data from card". The fourth white text box located to the right of the Step 1 box reads "Step 4: Reader generates fare payment request using card and reader data". The fifth white text box located directly below the fifth reads "Step 5: Reader transmits fare payment request to central computer (via local device, if applicable)". The sixth white text box located to the right of the Step 5 box reads "Step 6: Central computer receives fare payment request, retrieves account record from central database and calculates fare". The seventh white text box located directly below the sixth box reads "Step 7: Central computer determines if fare product or other right (e.g. transfer) in account is available to satisfy fare". The eight white text box located directly below the seventh box reads "Step 8: Central computer approves or declines fare payment request". The ninth white text box located directly below the eight box reads "Step 9: Central computer updates account record". A tenth white text box positioned below and to the left of the ninth box reads "Step 10: Central computer sends response to reader (via local device, if applicable). The eleventh white text box located to the left of the tenth box reads "Step 11: Reader displays approval or decline to passenger".)

Slide 67:

Learning Objective #3

Account-Based System

Implementation Considerations

Fare Payment Processing

Security

Network

Slide 68:

Learning Objective #3

Account-Based System

Implementation Considerations (cont.)

Fare Media Distribution

Fare Products

Applicable Standards

Slide 69:

Learning Objective #3

Account-Based System

Operational Benefits

Various forms of fare media could be supported

"Bring Your Own Device"

Slide 70:

Learning Objective #3

Account-based System

Operational Benefits (cont.)

Fare products are digital

Centralized fare policy and rules

Slide 71:

Learning Objective #3

Card-Based System

Fare Payment Transaction Flow

Card-based System Fare Payment Transaction Flow. Please see the Extended Text Description below.

(Extended Text Description: Card-based System Fare Payment Transaction Flow is a simple box diagram that uses the same structure described for slide 66. This diagram illustrates and describes the flow of fare payment data in a card-based system. There are the same four large square boxes aligned horizontally across the top of the diagram labeled "Fare Media", "Reader", "Local Device", and "Central Computer". The text box within the Fare Media box has five bulleted items: "Card ID", "Mutual authentication logic & keys", "Passenger rights", "fare product data" and "Transaction history". The text box within the Reader box has four bulleted items: "Fare policy", "Fare logic", "Negative list", and "Mutual authentication logic & keys". The text box within the Local Device reads "Optional". The text box within the Central Computer box has two bulleted items: "Negative list" and "Transaction history". Below those square boxes are 10 white text boxes aligned in three columns. The first column includes the following text boxes and text: "Step 1: Fare media is presented to reader", "Step 2: Fare media / reader perform mutual authentication", "Step 3: Reader extracts fare product and payment history from card", "Step 4: Reader calculates fare", "Step 5: Reader determines if any fare product can satisfy fare", "Step 6: Reader updates fare product and payment history on card", "Step 7: Reader displays approval or decline to passenger", and "Step 8: Reader records results". The second column includes one text box with the text: "Step 9: Reader uploads transaction records to central computer (via Local Device, if appropriate)". The third column includes one text box with the text: "Step 10: Central computer analyzes and archives records".)

Slide 72:

Learning Objective #3

Card-Based System

Implementation Considerations

Fare Payment Processing

Slide 73:

Learning Objective #3

Card-Based System

Implementation Considerations (cont.)

Fare Media Distribution

Slide 74:

Learning Objective #3

Card-Based System

Operational Benefits

"Bring your own device"

System works offline

Extensive experience

Slide 75:

Learning Objective #3

Open Payment System

Fare Payment Transaction Flow

Open Payment System Fare Payment Transaction Flow. Please see the Extended Text Description below.

(Extended Text Description: Open Payment System Fare Payment Transaction Flow is a simple box diagram that uses the same structure described for slide 66. This diagram illustrates and describes the flow of fare payment data in an open payment system. There are the same four large boxes aligned horizontally across the top of the diagram labeled "Fare Media", "Reader", "Local Device", and "Central Computer" plus one additional box labeled "Payment Processor". The text box within the Fare Media box has two bulleted items: "Card ID" and "Limited card data". The text box within the Reader box has three bulleted items: "Negative list", and "Bankcard processing logic" and "Yes/No fare logic". The text box within the Local Device reads "Optional". The text box within the Central Computer box has three bulleted items: "Negative list", "Bankcard payment processing logic" and "Bankcard payment aggregation logic". Below those square boxes are eight white text boxes aligned in three columns. A ninth white text box is located above and to the right of the larger white boxes. The first column includes the following text boxes and text: "Step 1: Fare media is presented to reader", "Step 2: Reader extracts card ID and other data from card", "Step 3: Reader checks card ID against negative or positive list", "Step 4: Reader displays approval or decline to passenger". The second column includes one text box with the text: "Step 5: Reader payment transactions to central computer (via Local Device, if appropriate)". The third column includes three text boxes with the text: "Step 6: Central computer aggregates fare payment transactions and generates and transmits bankcard payment authorization requests to Payment Processor", "Step 8: Central computer records result, if authorization request declined. Central computer adds card ID to negative list", and "Step 9: Central computer transmits updated negative list to all field devices".
The last text box reads: "Step 7: Payment Processor approves or declines authorization request.)

Slide 76:

Learning Objective #3

Open Payment System

Implementation Considerations

Fare Payment Processing

Security

Network

Slide 77:

Learning Objective #3

Open Payment System

Implementation Considerations (cont.)

Fare Media

Fare Products

Applicable Standards

Slide 78:

Learning Objective #3

Open Payment System

Operational Benefits

"Bring your own device"

System works offline

Slide 79:

Case Study. A placeholder graphic of a traffic operations center indicating a case study. The image shows a large room with a series of computer work stations in six visible rows leading into the distance. People are seated and working at several workstations. There is a blue rectangle at the top of the image of the traffic operations center with the title "Case Study." DOT and RITA logo in lower left corner and Standards ITS Training logo in lower right corner.

Slide 80:

Learning Objective #3

Case Study

Chicago Transit Authority (CTA) Ventra Program

EFPS type: Multi-agency, Account-based with Open Payment

Slide 81:

Learning Objective #3

Case Study

CTA Ventra Program Key Benefits

Slide 82:

Learning Objective #3

Case Study

Greater Toronto Area (GTA) Presto Program

EFPS type: Regional Card-based with Open Payment

Slide 83:

Learning Objective #3

Case Study

Greater Toronto Area (GTA) Presto Program (cont.)

Slide 84:

Learning Objective #3

Case Study

GTA Presto Program Key Benefits

Slide 85:

Learning Objective #3

Case Study

Jacksonville Transit Authority (JTA) Star Card

EFPS type: Single agency, Card-based system

Slide 86:

Learning Objective #3

Case Study

JTA Star Card Key Benefits

Slide 87:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

Slide 88:

Learning Objective #3

Which type of EFPS only supports value-based fares?

Answer Choices

  1. Card-based EFPS
  2. Open Payment EFPS
  3. Account-based EFPS
  4. All of the above

Slide 89:

Learning Objective #3

Review of Answers

A small graphical red and yellow X representing incorrect.a) Card-based EFPS
Incorrect. A card-based EFPS can support a wide variety of fare products including passes and various forms of prepaid stored value.

A small graphical green and yellow check mark representing correct.b) Open Payment EFPS
Correct! Open payment EFPS only accept 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 EFPS can only support value-based fares.

A small graphical red and yellow X representing incorrect.c) Account-based EFPS
Incorrect. This type of EFPS can support a virtually unlimited variety of prepaid fare products, including passes.

A small graphical red and yellow X representing incorrect.d) All of the above
Incorrect. Card-based EFPS and account-based EFPS can each support a wide variety of prepaid fare products, including passes.

Slide 90:

Learning Objective #3

Summary of Learning Objective #3

After completing this section of the module, the reviewer should be able to:

Slide 91:

Learning Objective #4

Learning Objective #4

Apply Newly Developed Skills to:

Slide 92:

Learning Objective #4

Systems Engineering Process Vee Diagram

Requirements Development and Analysis

Systems Engineering Process Vee Diagram - Requirements Development and Analysis. Please see the Extended Text Description below.

(Extended Text Description: Systems Engineering Process Vee Diagram Requirements Development and Analysis is a diagram with a series of text laid out in the shape of the letter vee, relevant author's description: This diagram identifies the standard steps that should be included in the planning, specification, and implementation of any type of system. Four of these steps are applicable to the development of specifications for a new electronic fare payment system or an upgrade to an existing electronic fare payment system. These steps are labeled "Regional Architecture(s)", "Feasibility Study / Concept Exploration", "Concept of Operations", and "System Requirements". The other 10 steps in the Vee Diagram and the other text elements on the inside and outside of the vee are not applicable to this module.)

Slide 93:

Learning Objective #4

Applying the SEP

Regional Architecture and Implications

The four applicable steps of the Systems Engineering Process Vee Diagram. Please see the Extended Text Description below.

(Extended Text Description: The four applicable steps of the Systems Engineering Process Vee Diagram from Slide 92 are presented as a graphic in the lower right corner of this slide. The first of those steps, labeled "Regional Architecture(s)" is highlighted in red to indicate that the information on this slide pertains to that step.)

Slide 94:

Learning Objective #4

Applying the SEP

Regional Architecture and Implications (cont.)

The four applicable steps of the Systems Engineering Process Vee Diagram. Please see the Extended Text Description below.

(Extended Text Description: The four applicable steps of the Systems Engineering Process Vee Diagram from Slide 92 are presented as a graphic in the lower right corner of this slide. The first of those steps, labeled "Regional Architecture(s)" is highlighted in red to indicate that the information on this slide pertains to that step.)

Slide 95:

Learning Objective #4

Applying the SEP

Feasibility Study / Concept Exploration

During this phase, the agency should develop a high level concept for its EFPS.

The four applicable steps of the Systems Engineering Process Vee Diagram. Please see the Extended Text Description below.

(Extended Text Description: The four applicable steps of the Systems Engineering Process Vee Diagram from Slide 92 are presented as a graphic in the lower right corner of this slide. The second of those steps, labeled "Feasibility Study / Concept Exploration" is highlighted in red to indicate that the information on this slide pertains to that step.)

Slide 96:

Learning Objective #4

Applying the SEP

Concept of Operations

During this phase, a preliminary decision on EFPS type is made.

The four applicable steps of the Systems Engineering Process Vee Diagram. Please see the Extended Text Description below.

(Extended Text Description: The four applicable steps of the Systems Engineering Process Vee Diagram from Slide 92 are presented as a graphic in the lower right corner of this slide. The third of those steps, labeled "Concept of Operations" is highlighted in red to indicate that the information on this slide pertains to that step.)

Slide 97:

Learning Objective #4

Applying the SEP

Concept of Operations (cont.)

The four applicable steps of the Systems Engineering Process Vee Diagram. Please see the Extended Text Description below.

(Extended Text Description: The four applicable steps of the Systems Engineering Process Vee Diagram from Slide 92 are presented as a graphic in the lower right corner of this slide. The third of those steps, labeled "Concept of Operations" is highlighted in red to indicate that the information on this slide pertains to that step.)

Slide 98:

Learning Objective #4

Applying the SEP

Requirements Definition

The four applicable steps of the Systems Engineering Process Vee Diagram. Please see the Extended Text Description below.

(Extended Text Description: The four applicable steps of the Systems Engineering Process Vee Diagram from Slide 92 are presented as a graphic in the lower right corner of this slide. The third of those steps, labeled "System Requirements" is highlighted in red to indicate that the information on this slide pertains to that step.)

Slide 99:

Learning Objective #4

Applying the SEP

Requirements Definition (cont.)

The four applicable steps of the Systems Engineering Process Vee Diagram. Please see the Extended Text Description below.

(Extended Text Description: The four applicable steps of the Systems Engineering Process Vee Diagram from Slide 92 are presented as a graphic in the lower right corner of this slide. The third of those steps, labeled "System Requirements" is highlighted in red to indicate that the information on this slide pertains to that step.)

Slide 100:

Learning Objective #4

Applying the SEP

Requirements Definition (sample)

Applying the SEP - Requirements Definition (sample). Please see the Extended Text Description below.

(Extended Text Description: The four applicable steps of the Systems Engineering Process Vee Diagram from Slide 92 are presented as a graphic in the upper right corner of this slide. The third of those steps, labeled "Concept of Operations" is highlighted in red to indicate that the information on this slide pertains to that step. Applying the SEP Requirements Definition (sample) is a table of sample requirements used to show examples of requirements that meet and those that don’t meet the standards defined in the System Engineer Process for well-written requirements. The raw table data itself is included below at the end of this description. It has four columns with the headers "#", "Category", "Requirement", and "Description". There are five rows below these headings numbered 1 through 5 in the # column. The cells in Row #1 read "Fare Product Distribution", "Passenger purchases of fare products", and "Passengers must be able to purchase a fare product (e.g. pass, stored value) on any internet-connected device and immediately use that product to pay a fare". The cells in Row #2 read "Standards", "Contactless Bankcard standards compliance", and "Applicable components shall be fully compliant with the bankcard standards". The cells in Row #3 read "TVM – User Interface", "Touchscreen with full color graphics", and "Users shall interact with TVMs using a 10" x 12", touchscreen LCD monitor which support full color graphics". The cells in Row #4 read "Security", "End-to-end Encryption", and "All data exchanges between subsystems, subsystem to central computer, and central computer to external system shall be fully encrypted using an industry standard encryption algorithm and a key length of not less than 128 bits. The cells in Row #5 read "Service Levels", "Fare Payment Transaction Time", and "Transaction times from recognition of the payment media by the reader to the display of the fare payment disposition shall be less than 500 ms".

Raw table data included below in table format:

# Category Requirement Description
1 Fare Product Distribution Passenger purchases of fare products Passengers must be able to purchase a fare product (e.g.: pass, stored value) on any internet-connected device and immediately use that product to pay a fare.
2 Standards Contactless Bankcard standards compliance Applicable components shall be fully compliant with the bankcard standards
3 TVM - User Interface Touchscreen with full color graphics Users shall interact with TVST using a 10" x 12", touchscreen LCD monitor which supports full color graphics.
4 Security End-to-end Encryption All data exchanges between subsystems, subsystem to central computer, and central computer to external system shall be fully encrypted using an industry standard encryption algorithm and a key length of not less than 128 bits.
5 Service Levels Fare Payment Transaction Time Transaction times from recognition of the payment media by the reader to the display of the fare payment disposition shall be less than 500 ms.

)

Slide 101:

Learning Objective #4

Selecting the Correct EFPS Type

EFPS Characteristics

Methodology Primary Security Scheme Fare Processing Logic Fare Products & Passenger Rights Fare Media
Account-based
  • Card authentication
  • Performed by central computer
  • Fare policy changes made to central computer only
  • Stored in central account records
  • Fare product sold via any networked device
  • Contactless card
  • Limited use ticket
  • Bar/QR code
  • Mobile device
Card-based
  • Card/Reader mutual authentication
  • Performed by reader
  • Fare policy changes downloaded to all field devices
  • Stored on card
  • Fare product sold via agency-specific devices
  • Contactless card
  • Magnetic farecard
  • Limited use ticket
Open Payment
  • N/A
  • Yes/No decision performed by reader
  • N/A: Supports only value-based fares
  • Contactless bankcards
  • Mobile device emulating contactless bankcard

Slide 102:

Learning Objective #4

Selecting the Correct EFPS Type

Matching Requirements to EFPS Characteristics

Sample Requirement: Passengers must be able to purchase a fare product (e.g. pass, stored value) on any internet-connected device and immediately use that product to pay a fare.

Selecting the Correct EFPS Type - Matching Requirements to EFPS Characteristics. Please see the Extended Text Description below.

(Extended Text Description: Selecting the Correct EFPS Type Matching requirements to EFPS characteristics is a table used to illustrate how agency requirements are matched to a particular type of Electronic Fare Payment System type. Above the table is the text of a sample requirement that reads, "Passengers must be able to purchase a fare product (e.g. pass, stored value) on any internet-connected device and immediately use that product to pay a fare". The raw table data itself is included below at the end of this description. The header of the first column is "EFPS Type" and the header of the second column is "Fare Product Distribution". There are three rows below the headers with the labels "Account-based", "Card-based", and "Open Payment". The Fare Product Distribution column in the Account-based row has three bulleted items that read: "Stored in central account records", "Fare product sold via any networked device", "Buy now, use now". There is a green circle with a check mark in the middle next to the last two of these bulleted items. The circles indicate that these characteristics are a compliant with the sample requirement. A larger green circle with a check mark in the first column indicates that an account-based system’s characteristics would be able to meet the sample requirement. The Fare Product Distribution column in the Card-based row has three bulleted items that read: "Stored on card", "Fare product sold via agency-specific devices", and "Buy now, use now". There is a red circle with a red line across the center next to the second of these characteristics to indicate that it is not compliant with the sample requirement. There is a green circle with a check mark in the middle next to the third characteristic to indicate that it compliant with the sample requirement. There is a larger red circle with a red line across the center in the first column to indicate that at least one of these card-based system characteristics fails to meet the sample requirement. The Fare Product Distribution column in the Open Payment row has one bulleted item that reads: "N/A: Supports only value-based fares". There is a red circle with a red line across the center next to this characteristic to indicate that it is not compliant with the sample requirement. There is a larger red circle with a red line across the center in the first column to indicate that at least one of these open payment system characteristics fails to meet the sample requirement.

Raw table data included below in table format:

EFPS Type Fare Product Distribution
Account-based
  • Stored in central account records ^Fare product sold via any networked device Buy now, use now
Card-based
  • Stored on card
  • Fare product sold via agency-specific devices
  • Buy now, use now
Open Payment
  • N/A: Supports only value-based fares

)

Slide 103:

Learning Objective #4

Selecting the Correct EFPS Type

Matching Requirements to EFPS Characteristics

Sample Requirement: Devices at points of entry (e.g. faregates, fareboxes) shall use security mechanisms (e.g. authentication) that prevent the use of counterfeit payment media before allowing entry/boarding.

Selecting the Correct EFPS Type - Matching Requirements to EFPS Characteristics. Please see the Extended Text Description below.

(Extended Text Description: Selecting the Correct EFPS Type Matching requirements to EFPS characteristics is a table similar to that used on Slide 102 to illustrate how agency requirements are matched to a particular type of Electronic Fare Payment System type. Above the table is the text of a sample requirement that reads "Devices at points of entry (e.g. faregates, fareboxes) shall use security mechanisms (e.g. authentication) that prevent the use of counterfeit payment media before allowing entry/boarding." The raw table data itself is included below at the end of this description. The column headers of this table are "EFPS Type" and "Payment Media Security". The row labels are identical to those on the table on Slide 102. The Payment Media Security column in the Account-based row has one bulleted item that reads: "Card Authentication". There is a green circle with a check mark in the middle next to that characteristic to indicate it is compliant with the sample requirement. A larger green circle with a check mark in the first column indicates that this account-based system characteristic meets the sample requirement. The Payment Media Security column in the Card-based row has one bulleted item that reads: "Card/Reader mutual authentication". There is a green circle with a check mark in the middle next to that characteristic to indicate that it is compliant with the sample requirement. There is a larger green circle with a check mark in the middle in the first column to indicate that this card-based system characteristic meets the sample requirement. The Payment Media Security column in the Open Payment row has two bulleted items that read: "Not applicable – Contactless bankcards do not support local authentication: and "Card authentication may be performed by issuer later". There is a red circle with a line across the center next to each of these characteristics to indicate that each is not compliant with the sample requirement. There is a larger red circle with a line across the center in the first column to indicate that at least one of these open payment system characteristics fails to meet the sample requirement.

Raw table data included below in table format:

EFPS Type Payment Media Security
Account-based
  • Card authentication
Card-based
  • Card/Reader mutual authentication
Open Payment
  • Not applicable - Contactless bankcards do not support local authentication
  • Card authentication may be performed by issuer later

)

Slide 104:

Learning Objective #4

Selecting the Correct EFPS Type

Matching EFPS Features to Requirements

Sample Requirement: The EFPS shall only accept for fare payments contactless bankcards that adhere to the ExpressPay, PayPass, payWave, or ZIP specifications.

Selecting the Correct EFPS Type - Matching EFPS Features to Requirements. Please see the Extended Text Description below.

(Extended Text Description: Selecting the Correct EFPS Type Matching requirements to EFPS characteristics is a table similar to that used on Slide 102 to illustrate how agency requirements are matched to a particular type of Electronic Fare Payment System type. Above the table is the text of a sample requirement that reads, "The EFPS shall only accept for fare payments contactless bankcards that adhere to the ExpressPay, PayPass, payWave or ZIP specifications." The raw table data itself is included below at the end of this description. The column headers of this table are "EFPS Type" and "Fare Media". The row labels are identical to the tables on slides 102 and 103. The Fare Media column in the Account-based row has three bulleted items that read: "Contactless card", "Limited use ticket", and "Bar Code/QR Code". There is a red circle with a line across the center next to each of those bulleted items to indicate that each is not compliant with the sample requirement. A larger red circle with a line across the center in the first column indicates that at least one of these account-based system characteristics fails to meet the sample requirement. The Fare Media column in the Card-based row has three bulleted items that read: "Contactless card", "Magnetic farecard", and "Limited use ticket". There is a red circle with a line across the center next to each of these characteristics to indicate that each is not compliant with the sample requirement. There is a larger red circle with a line across the center in the first column to indicate that at lease one of these card-based system characteristics fails to meet the sample requirement. The Fare Media column in the Open Payment row has one bulleted item that reads: "Contactless bankcards (only)". There is a green circle with a checkmark in the middle next to this characteristic to indicate that is compliant with the sample requirement. There is a larger green circle with a checkmark in the middle in the first column to indicate that this open payment characteristic meets the sample requirement.

Raw table data included below in table format:

EFPS Type Fare Media
Account-based
  • Contactless card
  • Limited use ticket
  • Bar Code/ QR Code
Card-based
  • Contactless card
  • Magnetic farecard
  • Limited use ticket
Open Payment
  • Contactless bankcards (only)

)

Slide 105:

Learning Objective #4

Selecting the Correct EFPS Type

Matching EFPS Features to Requirements

Sample Requirement: Fare payment processing shall support a variety of fare policies including, but not limited to, the use of pass products, transfer rights, and discounts to special fare program participants.

Selecting the Correct EFPS Type - Matching EFPS Features to Requirement. Please see the Extended Text Description below.

(Extended Text Description: Selecting the Correct EFPS Type Matching requirements to EFPS characteristics is a table similar to that used on Slide 102 to illustrate how agency requirements are matched to a particular type of Electronic Fare Payment System type. Above the table is the text of a sample requirement that reads "Fare payment processing shall support a variety of fare policies including, but not limited to, the use of pass products, transfer rights and discounts to special fare program participants". The raw table data itself is included below at the end of this description. The column headers of this table are "EFPS Type" and "Fare Payment Processing". The row labels are identical to the tables on slides 102, 103 and 104. The Fare Payment Processing column in the Account-based row has three bulleted items that read: "Performed by central computer", "Fare policy changes made to central computer only", and "Supports any policy". There is a green circle with a checkmark in the middle next to each of those bulleted items to indicate that each is compliant with the sample requirement. A larger green circle with a checkmark center in the middle in the first column indicates that these account-based system characteristics all meet the sample requirement. The Fare Payment Processing column in the Card-based row has three bulleted items that read: "Performed by reader", "Fare policy changes downloaded to all field devices", and "Supports any policy". There is a green circle with checkmark in the middle next to the third characteristics to indicate that it is compliant with the sample requirement. There is a larger green circle with a checkmark in the middle in the first column to indicate that one of these card-based system characteristics meets the sample requirement. The Fare Payment Processing column in the Open Payment row has two bulleted items that read: "Yes/No decision performed by reader" and "Supports value-based fares only". There is a red circle with a line across the center next to the second characteristic to indicate that it is not compliant with the sample requirement. There is a larger red circle with a line across the center in the first column to indicate that at least one of these open payment characteristics fails to meets the sample requirement.

Raw table data included below in table format:

EFPS Type Fare Payment Processing
Account-based
  • Performed by central computer
  • Fare policy changes made to central computer only
  • Supports any policy
Card-based
  • Performed by reader
  • Fare policy changes downloaded to all field devices
  • Supports any policy
Open Payment
  • Yes/No decision performed by reader
  • Supports value-based fares only

)

Slide 106:

Learning Objective #4

Selecting the Correct EFPS Type

Role of Security in an EFPS

Slide 107:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

Slide 108:

Learning Objective #4

Which of the following is an important consideration when defining security requirements for an EFPS?

Answer Choices

  1. Sensitive data protection
  2. Protection of cash while being transported to a bank
  3. On-board surveillance systems for bus vehicles
  4. Scheduling of daily fare payment reports

Slide 109:

Learning Objective #4

Review of Answers

A small graphical green and yellow check mark representing correct.a) Sensitive data protection
Correct! 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 EFPS.

A small graphical red and yellow X representing incorrect.b) Protection of cash while being transported to a bank
Incorrect. Although important, protection of cash in not directly related to EFPS security.

A small graphical red and yellow X representing incorrect.c) On-board surveillance system for bus vehicles
Incorrect. Although important, such surveillance systems are not directly related to EFPS security.

A small graphical red and yellow X representing incorrect.d) Scheduling of daily fare payment reports
Incorrect. Although important, report printing and delivery is not directly related to EFPS security.

Slide 110:

Learning Objective #4

Summary of Learning Objective #4

After completing this section of the module, the reviewer should be able to apply newly developed skills to:

Slide 111:

What We Have Learned

  1. 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
  2. Electronic fare payment uses a variety of terms and abbrs that are unique to the transit fare collection industry
  3. The three most common types of electronic fare payment systems are: card based, account-based, and open payment.

Slide 112:

What We Have Learned (cont.)

  1. 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.
  2. Careful analysis of agency requirements is required in order to identify the correct EFPS type.
  3. Data security plays a key role in every EFPS but the methods will vary depending on the type of EFPS selected.

Slide 113:

Resources

See Student Guide for a more comprehensive list of resource documents and materials.

Slide 114:

Thank you for completing this module.