Table of Contents - APTAStandards.com

Table of Contents - APTAStandards.com Table of Contents - APTAStandards.com

aptastandards.com
from aptastandards.com More from this publisher
29.06.2013 Views

Though the majority of the messages and related data elements have been designed for financial transaction interchange, they share some commonalities with public transit electronic fare payment transactions. 4.1.2 Applicability to UTFS Effort ISO/IEC 8583 lacks transit industry specific data elements and message types that need to be defined by APTA. The addition of this new information requires their submission to ISO/IEC, the international standards body that controls and maintains the changes to the standard. The timeline for an effort such as this is largely unknown, but estimated to be lengthy. For all the benefits offered, this standard may serve as a model for UTFS WP4 efforts. Of all the standards and specifications analyzed, ISO/IEC 8583 is the most established and widely implemented standard throughout the world. Financial data exchange of all magnetic stripe based credit card transactions follows this standard. Following the advancements in the card technologies, ISO/IEC 8583 has been updated to accommodate mostly contact based smart card transactions. Its financial industry focus led to the presence of a variety of clearing and settlement transactions exchanged between entities. Though it is mostly used for on-line real time “request-response” type transactions, the standard provides details for batch and file transfer mechanisms. 4.1.3 Common Message Structure ISO/IEC 8583 provides a common message structure, which defines three main sections for each message as illustrated in Exhibit 4.1-1. Exhibit 4.1-1 Common Message Structure Message Type Message Bitmap(s) Data Elements Message type consists of two elements, a version number and a message type identifier. The version number is allocated to indicate the version of the ISO/IEC 8583 standard followed by the interchange. The message type identifier is a three digit numeric field identifying the following: • Message class • Message function • Transaction originator Message class identifies whether it is a financial, administrative, or network management type of a message. Message function specifies if it is a request, response, notification or advice. The transaction originator digit identifies the originator of the message (e.g., issuer or acquirer). Page 14

Although there is no “one-to-one” relationship between UTFS defined message types and ISO/IEC 8583 defined message classes, this standard provides a flexible model, or foundation to further define transit industry related data elements in its body. The second element in the message structure defines whether it contains one or two bitmaps. A “1” in the bitmap indicates the presence of the corresponding data element in the message. Each bitmap has 64 bits, thus two bitmaps can provide the total of 128 data elements, as defined by the standard. The first (primary) bitmap is mandatory and represents the most frequently used data elements. The presence of the secondary bitmap is signified by a “1” in bit 01 of the primary bitmap. Bitmaps provide the application providers with the flexibility of choosing among a greater pool of data elements for varying industry segments, however, they tend to add extra overhead to the transaction speeds, especially in real-time data processing environments. The effects of this overhead may not be as significant for backend, processing environments such as clearing and settlement or reporting that are not as time sensitive as card to reader transactions. Messages are constructed using the message bit map as an index of present data elements. There are three types of data elements: • Primitive data element • Constructed data element • Composite data element Primitive data elements represent a single piece of information, whereas the constructed data element consists of a fixed number of sub-elements, all of which must be present. Composite data element consists of a large number of sub-elements. Most of these sub- elements fall into industry related categories such as auto rental data, or airline data. In order to define these categories, the concept of a “dataset” has been introduced. All the sub elements in a composite data element are divided into a certain number of datasets, each of which relates to an industry and contain a dataset identifier. The structure of a dataset is based on the message structure explained in this standard. There is also a provision for identifying sub-elements using the TLV data encoding method as an alternative to using a second level bitmap. Each composite data element can therefore contain a variable number of different datasets and can include both TLV and bitmap formats as illustrated in Exhibit 4.1-2. Page 15

Although there is no “one-to-one” relationship between UTFS defined<br />

message types<br />

and<br />

ISO/IEC 8583 defined message classes, this standard provides a flexible model, or<br />

foundation<br />

to further define transit industry related data elements in its body.<br />

The<br />

second element in the message structure defines whether it contains one or two<br />

bitmaps.<br />

A “1” in the bitmap indicates the presence <strong>of</strong> the corresponding data element<br />

in the message. Each bitmap has 64 bits, thus two bitmaps can provide the total <strong>of</strong> 128<br />

data<br />

elements, as defined by the standard. The first (primary) bitmap is mandatory and<br />

represents<br />

the most frequently used data elements. The presence <strong>of</strong> the secondary<br />

bitmap is signified by a “1” in bit 01 <strong>of</strong> the primary bitmap.<br />

Bitmaps provide the application providers with the flexibility <strong>of</strong> choosing among a<br />

greater pool <strong>of</strong> data elements for varying industry segments, however, they tend to<br />

add<br />

extra<br />

overhead to the transaction speeds, especially in real-time data processing<br />

environments. The effects <strong>of</strong> this overhead may not be as significant for backend,<br />

processing environments such as clearing and settlement or reporting that are not as<br />

time sensitive as card to reader transactions.<br />

Messages are constructed using the message bit map as an index <strong>of</strong> present data<br />

elements. There are three types <strong>of</strong> data elements:<br />

• Primitive data element<br />

• Constructed data element<br />

• Composite data element<br />

Primitive data elements represent a single piece <strong>of</strong> information, whereas the constructed<br />

data element consists <strong>of</strong> a fixed number <strong>of</strong> sub-elements, all <strong>of</strong> which must be present.<br />

Composite data element consists <strong>of</strong> a large number <strong>of</strong> sub-elements. Most <strong>of</strong> these sub-<br />

elements fall into industry related categories such as auto rental data, or airline data. In<br />

order to define these categories, the concept <strong>of</strong> a “dataset” has been introduced. All<br />

the<br />

sub elements in<br />

a <strong>com</strong>posite data element are divided into a certain number <strong>of</strong> datasets,<br />

each<br />

<strong>of</strong> which relates to an industry and contain a dataset identifier. The structure <strong>of</strong> a<br />

dataset is based on the message structure explained in this standard. There is also a<br />

provision<br />

for identifying sub-elements using the TLV data encoding method as an<br />

alternative to using a second level bitmap. Each <strong>com</strong>posite data element can therefore<br />

contain a variable number <strong>of</strong> different datasets and can include both TLV and bitmap<br />

formats as illustrated in Exhibit 4.1-2.<br />

Page 15

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!