National Academies Press: OpenBook

Smartcard Interoperability Issues for the Transit Industry (2006)

Chapter: Chapter 6 - Findings of Data-Management Policies and Issues

« Previous: Chapter 5 - Findings of Data Flows Between Agencies
Page 74
Suggested Citation:"Chapter 6 - Findings of Data-Management Policies and Issues." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 74
Page 75
Suggested Citation:"Chapter 6 - Findings of Data-Management Policies and Issues." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 75
Page 76
Suggested Citation:"Chapter 6 - Findings of Data-Management Policies and Issues." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 76
Page 77
Suggested Citation:"Chapter 6 - Findings of Data-Management Policies and Issues." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 77
Page 78
Suggested Citation:"Chapter 6 - Findings of Data-Management Policies and Issues." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 78

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

This chapter is to examine critical issues and policies related to data management. A smart- card fare payment generates a transaction record every time a card is processed at a read-write device, with the exception of designated terminals that only provide remaining value informa- tion to the patron. These transaction records are an asset that has significant value and thus needs to be managed. A data-management policy provides the guidelines for the participants in an interoperable smartcard system for managing this data asset. At a minimum, a data-management policy should address the following: • Scope of the data-management policy; • Definition of the data types, – Data location, – Ownership and access rights, and – Data-protection measures; • Identification of the stakeholders and their roles and responsibilities; and • Other requirements-privacy. A data-management policy is a document updated as stakeholder needs change. Simi- lar to business rules, which may range from a one-page document (e.g., the business rules for TransLink) to a detailed set of requirements (e.g., the business rules for the Seattle RFC), data-management policies’ length and level of detail will vary according to stake- holder needs. Figure 15 illustrates a process for developing and maintaining a data-management policy. 6.1 Scope of the Data-Management Policy The scope and purpose of the data-management policy identifies to whom it applies, and the limitations of the data involved. In general, the data-management policy for an interop- erable smartcard fare payment system will apply to all agencies participating and accepting the smartcard for payment, the contractors supplying systems and services, and any non- transit participants. The data are generally limited to those generated during the fare payment operation. The scope and purpose of the data-management policy does not necessarily need to be updated unless organizational structural changes occur in the program. Because of the long-term nature of smartcard projects and the effort required by agencies to set up program-management structures, organizational structures are fairly stable once established. 74 C H A P T E R 6 Findings of Data-Management Policies and Issues

Findings of Data-Management Policies and Issues 75 6.2 Definition of the Data Types Smartcard systems capture detailed transaction and revenue data. Rules must be established for governing who has access to what data, particularly in environments where multiple private operators compete for ridership, because this type of data is generally considered confidential. The data sharing and information access policies also drive the security architecture of the inter- operable smartcard system. Two categories of data are associated with a smartcard fare payment system: • Transaction Data-Consists of the transactions generated as the smartcard system is used for payment or validation of ride privileges or when value is loaded to cards and • Operations Data-Consists of all non-transaction data collected while the smartcard system is operating. As discussed in Chapter 1, transit agencies take ownership of the service levels offered to rid- ers. This situation precipitates an environment of defending control of all data generated for a specific agency’s operations. 6.2.1 Data Location In a multi-agency environment, most operational data associated with each agency will be stored separately, primarily because of the differences in operations. Certain data, such as card holder identity on personalized cards, may be shared by multiple agencies because such data are loaded after card issuance. For example, a card issued by a university for identification purposes may contain a transit application that uses the identity information collected and encoded on the card by the university; this is used for transit-balance protection services. Given the current state of the technology, the fields and format of such data must, however, be established and coded at the time of card manufacture. Long-term goals of transit agencies in cities such as Washington, San Francisco, Seattle, and London include the future integration of other applications onto cards issued initially for transit service.Although development efforts are under way for card-operating systems (i.e., applications Establish Data Policy for Participants stablish ata olicy for articipants Identify Data Types Identify ata Types Identify Stakeholders Identify takeholders Monitor Stakeholder Needs onitor takeholder eeds Assign Access Rights ssign ccess ights Define Roles and Responsibilities efine oles and esponsibilities Needs Changing? eeds hanging? Modify Data Policy odify ata olicy Analyze Stakeholder Needs nalyze takeholder eeds No Yes Figure 15. Data-management policy development and maintenance process.

may be dynamically loaded onto cards in a secure manner after they have been issued to cus- tomers,) no such system is commercially available at a marketable price. Until systems permitting the dynamic loading of applications are further developed and tested, adding an application to an existing smartcard system will only be possible with the manufacture and issuance of new cards. 6.2.2 Data Ownership and Access Rights Substantial value is associated with data related to customer characteristics. The data referred to in this discussion include all types generated and collected in operating the fare payment system—both related to customers (transit riders) and the agency. Any contract for a smartcard fare payment system must define the following clearly: • Rights and Responsibilities—Associated with data generated through processing transactions; with the process of issuing, loading, and reloading transit-only cards; and with whether or not the transit application resides on a card with other applications. • Data Management—Assurance that any card-holder or card-activity data and financial and operational data from an agency are held securely so that they can be accessed by and released to only those authorized. • Confidentiality and Privacy Issues-Associated with personal (card holder) data created during fare payment system operations; data that can be linked to an individual card holder at any time are to be considered confidential and should not be released in any manner without card holder consent. For an agency-owned system, data ownership follows existing rules and regulations as they apply to public agencies. Some data, such as capital and operating expenditures, are subject to the Freedom of Information Act. However, personal data generated during fare payment systems operations should be excluded and only released in the most compelling circumstances to the proper authorities. For example, in the Hong Kong program, most cards issued are anonymous— approximately 10 percent are personalized (registered). If customers are not reasonably confi- dent that privacy is protected they will be unlikely to accept this new form of fare media. When a smartcard fare payment system is bank-sponsored, consortium-owned data ownership ultimately becomes a cost issue. Data ownership is an intangible benefit for which quantifying a value to a particular organization is difficult. The value of the data depends on how the data will be used by the capturing entity. In the most aggressive scenario, such data may be sold outright to an organization interested in targeting customers riding transit or using a specific transit mode. Regardless of the ownership model, data ownership has to be defined before entering a con- tractual relationship. However, data ownership requirements cannot be finalized until a fare pay- ment system concept is complete. The fare payment systems concept defines what data are generated and where in the system. During fare-systems operations, the fare payment system may generate temporary files, which a contractor may argue are proprietary and are an integral func- tion of the application software. A contractor may argue that the agency has no right to the files. Therefore, data ownership becomes a subject of negotiation once fare payment system services and equipment requirements have been finalized. 6.3 Identification of Stakeholders and Their Roles and Responsibilities As the smartcard program progresses and the system design is established, the location of the data at the different tiers in the architecture becomes evident. The stakeholder will vary depend- ing on the location of the data and how and where it is generated. Each stakeholder that needs to 76 Smartcard Interoperability Issues for the Transit Industry

have access to the data in the system will be required to meet responsibilities associated with the data’s specific role. The stakeholders of an interoperable smartcard system have different needs and those needs will affect the level of access to data required. Table 17 identifies the stakeholders, their needs, and the types of data they require. 6.4 Other Requirements—Privacy Consumer privacy is a growing concern in the smartcard industry. There is no universal law in the United States governing the use of personal information. The U.S. government has encour- aged the different industries to self-regulate the use of personal information. Each system should be analyzed on a case-by-case basis for the personal data collected through the normal course of business to determine if an individual’s right to privacy is at risk. If a regional farecard program is used beyond transit, this will likely complicate the already complex privacy issues inherent in this type of identity-based system. When marketing value is placed on information by a partici- pant in the smartcard program, such as a financial institution, guidelines and policies should be established regarding the collection and use of such data. In today’s business environment, information about customers has an intrinsic value. In con- trast to the European Union, no universal laws in the United States govern personal information. However, there are sectoral laws for industries such as the financial services and medical indus- tries, and for federal, state, and local government. Because laws specifically address financial pri- vacy, financial institutions distinguish privacy as follows: • Informational Privacy—Defined as the “claims of individuals, groups or institutions to deter- mine for themselves when, how, and to what extent information about them is communicated to others.” • Financial Privacy—Defined as the “rights of individuals to control the collection, storing, use, and dissemination of information concerning their personal financial affairs by their financial products and services.” Findings of Data-Management Policies and Issues 77 Stakeholder Data Needs Access Requirements Government • Funding • Competing obligations • Consolidated Performance-Related Data Transit Agency • Operating system • Service efficiency • Funding • Financial Data • Ridership Data • Customer-Support Data Customer • Customer service • Ease-of-use • Efficient access to information • Transaction Summaries • Card Configuration • Remaining Value Other Transportation • Highway and bridge tolls • Taxi • Revenue • User Profiles Non- Transportation • Private operators • FTA • Merchants • Ridership/Sales • Revenue Table 17. Stakeholder data-access matrix.

To determine if a smartcard fare payment system may be at risk of invading an individual’s right to privacy, the system’s data needs to be analyzed to determine the personal identifiable informa- tion that is collected in the normal course of business. If it is determined that an individual’s right to privacy is at risk, then the Privacy Alliance (a group of more than 80 global corporations and associations who work together toward on-line privacy for individuals) recommends taking the following steps to minimize the exposure to potential litigation: • Adopt and Implement a Privacy Policy—Any organization engaged in electronic-funds trans- fer has the responsibility to adopt and implement a policy to protect the privacy of personally identifiable information • Adopt a Notice and Disclosure Policy—Policy must be available before or at the time the per- sonally identifiable information is requested or collected • Provide Choice and Obtain Consent—Individuals must have a choice on how the personally identifiable information may be used or have the opportunity to opt out of such use • Ensure Data Security—Appropriate measures must be taken to ensure that personally identi- fiable information is reliable and protected from loss, misuse, and alteration • Ensure Data Quality and Access—Reasonable steps must be taken to ensure that data are accu- rate, complete, and timely 6.5 Current Trends The trend for managing smartcard-related data is to adopt the most conservative approach: • Each agency owns the transaction data generated in its system. • Any transaction record related to an adjoining agency’s service, such as a transfer, is to be made available only to the respective agency involved in the transaction. • Only ridership reports required by the FTA, through other inter-agency agreements, or through other public sources, may be available to all participants. • Financial and revenue data are to be reported on an aggregated basis, and each agency controls the distribution of its financial and revenue data. As interoperable systems become more common and economic benefits begin to materialize as a result of wider sharing of data, transit agencies may begin to cede the tight control common in the industry today. 78 Smartcard Interoperability Issues for the Transit Industry

Next: Chapter 7 - Findings of Proof of Concept Using Standard API »
Smartcard Interoperability Issues for the Transit Industry Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB Transit Cooperative Research Program (TCRP) Report 115: Smartcard Interoperability Issues for the Transit Industry explores interoperability; identifies information needed by public agencies to implement smartcard payment systems interoperability; examines the necessary information flows; and outlines a set of functions needed for a standard public domain application programming interface (API) that may be used in the development of a uniform application protocol data unit (APDU). The report also includes a prototype for an API and an APDU that demonstrates this “proof of concept” for International Organization for Standardization-compliant Type A and Type B cards.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!