Smartcard Interoperability Issues for the Transit Industry (2006) / Chapter Skim
Currently Skimming:
Pages 14-27
The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.
From page 14... ...
As the interoperability model shows, the first step toward creating an interoperable smartcard payment system is to identify the institutional requirements of the participants. Fare payment interoperability, regardless of technology used (e.g., smartcard, paper-based, or magnetic stripe)
|
From page 15... ...
Participation in a governing body may require an agency to cede complete control over the common elements of the interoperable system. Even agencies that have an excellent working relationship may find adapting to a common governing body challenging.
|
From page 16... ...
2.1.1.3 Management Committee Regions that lack a lead agency or a regional planning organization to champion the interoperable fare payment project may elect to form a management committee to oversee the project. Each of the participating agencies is represented on the management committee.
|
From page 17... ...
(including those in New York; Washington, DC; Atlanta; and Los Angeles) start with a lead agency implementing a new AFC system to meet their immediate needs and then expand the use of the new AFC technology to other agencies in the region.
|
From page 18... ...
– The function may need to scale up or down, depending on demand or utilization levels. – There is potential for the provider to share the service across multiple projects.
|
From page 19... ...
At a minimum, the business case consists of the following parts: • Estimated capital cost of the system; • Existing operating costs; • Operating and maintenance costs after system implementation; • Schedule for implementation; • Risk factors; • Initial operational cost (start of revenue service) ; and • Regional/management/lead agency oversight, administration, and management.
|
From page 20... ...
pass. The rollout of these agencies will need to occur simultaneously to avoid affecting patrons who use the common fare product.
|
From page 21... ...
and Canadian deployments have retained the services of consultants specializing in transit and electronic payments. As an outside party with best practices developed over multiple projects, experts can assist the participating agencies with overall program strategy, document preparation, procurement assistance, and critical decision making throughout design and implementation.
|
From page 22... ...
2.2 Financial Management Issues Financial integrity is the highest priority for any agency participating in an interoperable fare payment system. This section discusses the key financial management decisions and issues that must be addressed, including • Transaction clearing and settlement, • Funds pool management, and • Financial exposure risk associated with advanced features.
|
From page 23... ...
may be a "virtual" funds pool where each agency holds its own share of the total amount. Examples of how the money within the funds pool can be used are • Periodic movement of funds between member agencies to compensate for fare payments, purchases, 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.
|
From page 24... ...
before being "hot listed" (or negative listed) needs to be covered.
|
From page 25... ...
2.3.3 Convenience Based on the experience in San Francisco and Washington, DC, patrons in other regions will most likely embrace a regional interoperable system once they understand the increased convenience this type of fare payment system offers. The challenges of the new technology and process are minimized once riders gain an increased understanding of its use.
|
From page 26... ...
A smartcard specification needs to define items such as data elements, objects, API, and an APDU command set for an interoperable fare payment system. The issues for discussion are categorized as follows: • Business justification, • Supplier behavior, and • Supplier compliance with available standards.
|
From page 27... ...
fare payment systems possible. Proprietary solutions were developed long before standardization discussions began.
|
Key Terms
This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More
information on Chapter Skim is available.