29.06.2013 Views

Table of Contents - APTAStandards.com

Table of Contents - APTAStandards.com

Table of Contents - APTAStandards.com

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Though the majority <strong>of</strong> the messages and related data elements have been designed for<br />

financial transaction interchange, they share some <strong>com</strong>monalities with public transit<br />

electronic fare payment transactions.<br />

4.1.2 Applicability to UTFS Effort<br />

ISO/IEC 8583 lacks transit industry specific data elements and message types that need<br />

to be defined by APTA. The addition <strong>of</strong> this new information requires their submission<br />

to ISO/IEC, the international standards body that controls and maintains the changes to<br />

the standard. The timeline for an effort such as this is largely unknown, but estimated<br />

to be lengthy. For all the benefits <strong>of</strong>fered, this standard may serve as a model for<br />

UTFS<br />

WP4 efforts.<br />

Of all the standards and specifications analyzed, ISO/IEC 8583 is the most established<br />

and widely implemented standard throughout the world. Financial data exchange<br />

<strong>of</strong><br />

all magnetic stripe based credit card transactions follows this standard. Following the<br />

advancements in the card technologies, ISO/IEC 8583 has been updated to<br />

ac<strong>com</strong>modate mostly contact based smart card transactions. Its financial industry focus<br />

led<br />

to the presence <strong>of</strong> a variety <strong>of</strong> clearing and settlement transactions exchanged<br />

between entities. Though it is mostly used for on-line real time “request-response”<br />

type<br />

transactions, the standard provides details for batch<br />

and file transfer mechanisms.<br />

4.1.3 Common Message Structure<br />

ISO/IEC 8583 provides a <strong>com</strong>mon message structure, which defines three main sections<br />

for<br />

each message as illustrated in Exhibit 4.1-1.<br />

Exhibit 4.1-1 Common Message Structure<br />

Message Type Message Bitmap(s) Data Elements<br />

Message type consists <strong>of</strong> two elements, a version number and a message type identifier.<br />

The version number is allocated to indicate the version <strong>of</strong> the ISO/IEC 8583 standard<br />

followed by the interchange. The message type identifier is a three digit numeric field<br />

identifying the following:<br />

• Message class<br />

• Message function<br />

• Transaction originator<br />

Message class identifies whether it is a financial, administrative, or network<br />

management type <strong>of</strong> a message. Message function specifies if it is a request, response,<br />

notification or advice. The transaction originator digit identifies the originator <strong>of</strong> the<br />

message (e.g., issuer or acquirer).<br />

Page 14

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

Saved successfully!

Ooh no, something went wrong!