National Academy of Sciences | 150 Year Anniversary

Questions? Call 800-624-6242

| Items in cart [0]

The National Academies Press

Rights & Permissions

topleft topright

TCRP Report 115: Smartcard Interoperability Issues for the Transit Industry (2007)
Transit Cooperative Research Program (TCRP)

Citation Manager

Transportation Research Board. "2.2.3 Financial Exposure and Risk Associated with Advanced Features." TCRP Report 115: Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press, 2007.

Please select a format:

BibTeX EndNote RefMan


Page
23
bottomleft bottomright
Page
23
Front Matter (R1-R9)
Summary (1-2)
Chapter 1 - Introduction (3-3)
1.2 Elements of Fare Payment Interoperability (4-4)
1.3 Interoperability Across Regions (5-5)
1.4 Interoperability Beyond Transit (6-6)
1.5.1 Acceptance of Contactless Bank Cards (7-8)
1.5.3 Multiple Payment-Enabled Devices (9-9)
1.6 Hypothetical Examples - Interoperability Between WMATA and TransLink (10-10)
1.6.1 Information to Be Exchanged for Payment (11-12)
1.6.3 Process for Determining the Net-Settlement Position (13-13)
2.1 Management and Organizational Issues (14-14)
2.1.1 Establishing a Governing Body or Project Sponsor (15-16)
2.1.2 Identifying and Mitigating Operational Differences (17-17)
2.1.3 Establishing a Framework for Program Funding (18-18)
2.1.4 Creating a Rollout Schedule (19-19)
2.1.5 Developing a Contracting Strategy (20-21)
2.2.2 Funds Pool Management (22-22)
2.2.3 Financial Exposure and Risk Associated with Advanced Features (23-23)
2.3.2 New Processes (24-24)
2.4 Equipment Design Issues (25-25)
2.5.2 Supplier Behavior (26-26)
2.5.3 Supplier Compliance with Available Standards (27-27)
Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs (28-28)
3.1.1 SmarTrip (29-33)
3.1.2 TransLink (34-34)
3.1.3 Chicago Card (35-35)
3.1.4 Central Puget Sound Regional Fare Coordination (RFC) Project (36-36)
3.1.5 Go-To Card (37-37)
3.1.6 Orlando Regional Alliance for Next Generation Electronic Payment System (ORANGES) (38-38)
3.1.7 Go Ventura (39-39)
3.1.8 Transit Access Pass (TAP) (40-40)
3.1.9 Compass (41-41)
3.1.10 Octopus (42-42)
3.1.11 EZ-Link (43-43)
3.1.12 Oyster (44-44)
3.2.1 Commonalities and Differences (45-46)
3.2.2 Current Trends and New Developments (47-47)
3.4.2 SmarTrip (48-48)
3.5 Summary (49-50)
4.1 Industry Interoperability Analysis (51-51)
4.2.1 Physical Layer (52-56)
4.2.2 Data Layer (57-59)
4.2.3 Application Layer (60-60)
4.2.4 Security Layer (61-66)
4.3 Gap Analysis (67-68)
5.1 Development of Conceptual Fare Payment System Architecture (69-69)
5.2 Identification of the Data Types (70-70)
5.3.2 Operation Data Flows (71-73)
6.1 Scope of the Data-Management Policy (74-74)
6.2.1 Data Location (75-75)
6.3 Identification of Stakeholders and Their Roles and Responsibilities (76-76)
6.4 Other RequirementsPrivacy (77-77)
6.5 Current Trends (78-78)
7.1 Use of Standard API in Proof of Concept (79-82)
7.2 Development of AFC Simulator (83-84)
7.3 Demonstration (85-85)
7.4 Conclusion (86-86)
Chapter 8 - Conclusions (87-91)
Appendix A - Set of Functionality for a Standard API (92-99)
Abbreviations used without definitions in TRB publications (100-100)

Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 23
Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems 23 may be a "virtual" funds pool where each agency holds its own share of the total amount. Exam- ples of how the money within the funds pool can be used are · Periodic movement of funds between member agencies to compensate for fare payments, pur- chases, or loads by one participant's cardholders on another participant's system; · Periodic payment of transit services used by cardholders; and · Coverage of charge-backs for transactions that should not have been posted. Revenue is generated by investing the funds pool float (i.e., interest earned on unallocated funds) contained within the funds pool. The member agencies must decide how the float should be invested [e.g., certificates of deposits (CDs) or money markets] so that the money can grow in a low-risk manner, or alternatively, how the funds may be used to meet the working capital needs of the agencies. It can be a challenge for the member agencies to agree how to allocate the float. 2.2.2.1 Funds Pool Float Strategies Regional programs that have followed a central clearinghouse model have developed float allo- cation formulas to arrive at how revenue from e-cash sales within the funds pool float is distrib- uted among the participating agencies. The formulas are typically tied to the amount of electronic purse (or transit-specific purse) loads that occur on equipment at a given agency. Responsibility for negotiating the float allocation formula is usually assigned to the finance committee. 2.2.3 Financial Exposure and Risk Associated with Advanced Features Smartcard technology allows for features not supported by other fare payment technologies, including · Autoload--The automatic loading of fare value once a specified threshold is reached; and · Balance Protection--Value replacement insurance if a card is lost or stolen. Although beneficial to both the patron and agency, these features represent a potential risk for the member agencies. The challenge for participating agencies is agreeing on a common way of managing the risk of added functionality. 2.2.3.1 Autoload The autoload feature involves linking a smartcard to a debit or credit account that automati- cally adds funds from the account to the smartcard when a predetermined value threshold is reached. Depending on how the feature is implemented, autoload can result in a situation where a card has been loaded with additional value before receiving bank authorization to debit the linked account. The autoload feature can be implemented following one of two models. In a post-funded autoload model, the card is loaded with additional funds once it reaches a predetermined threshold, and the funds are then subsequently obtained from the linked account. In a pre-funded autoload model, when the card balance falls below a predetermined threshold, a load request is initiated, the funds are obtained, and the card is loaded with the additional value on the next entry to the system. An additional pre-funded autoload type is a directed autoload, where the patron requests a load of the card for a given value and the funds are approved in advance of an autoload issuance. 2.2.3.2 Balance Protection The balance protection feature replaces the value that was on the card when it becomes lost, stolen, or damaged. The balance protection can also leave the member agencies at risk of losing fare revenue. If a card with balance protection is lost or stolen, the risk of the card being used