Table of Contents - APTAStandards.com
Table of Contents - APTAStandards.com Table of Contents - APTAStandards.com
defines instruction, notification and advice message types for unique operating conditions. “Request-Response” message pairs were originally intended for exchange between an operator central system and a regional central system. However, depending on the system architecture, the message pairs can be configured for exchange between two operator central systems. Operator Central System 4.1.7 Security Requirements Exhibit 4.1-5 Request Response Pair Regional Central System Request/Response Request/Response Request/Response Operator Central System The standard mandates th e last bit position within any message bit map to be reserved for the Message Authentication Code (MAC) data element to validate the source and the text of the message between the sender and the receiver. The standard also makes reference to ISO/IEC 9807 (Banking and Related Financial Services) for message authentication. 4.1.8 Timing & Routing ISO Standard 8583 defines two alternative information exchange schemes including examples to accommodate transfer of data, in a batch or a file transfer format, in addition to the standard real-time “request-response” messages. These alternative approaches can be especially beneficial in a back-end information exchange, where a real time transfer of data to the higher tier or the central system is not as critical. These two alternatives provide a viable foundation for information exchange between both intra agency system components and different central systems that operate on a peer-topeer basis. Therefore these exchange schemes are applicable to the UTFS efforts. ISO/IEC 8583 describes a file transfer process that is designed to allow transfer of larger volumes of data in the minimum number of messages. The file transfer consists of submission of a group of file action messages (300 series), where the total number of Page 20
these messages constitutes a file. The File Name data element in the message indicates the name of the file to be updated at the receiver’s location. The Data Record data element in each one of these messages contains data from a number of business transactions. The data contained in the Data Record data element may, or may not be based on the message types identified in this standard. The structure of this data element is left to the parties involved in the exchange. A file transfer is initiated with a network message set (804/814), followed by a series of file action (340) messages and ended with another network message, as illustrated in Exhibit 4.1-6. Device Or Station/Depot Computer Exhibit 4.1-6 File Transfer Process 804 814 340 340 350 804 814 N times File Operator Central System or Regional Central System Batch transfer allows transaction details to be sent as a series of notification, or instruction messages with an optional reconciliation transaction. The Batch Transfer does not require a response message for every message sent. Control is maintained by the use of notification, or instruction acknowledgement messages, which may be sent periodically within the transmission of a batch. There are no specific message types needed to support the Batch Transfer. It is achieved by the use of the existing message types provided by the standard. The batch transfer is initiated by an 804/814 network management messages that define transfer related control data such as number of messages contained in the batch. In the example flow illustrated in Exhibit 4.1-7, a series of Financial Presentment Notification Messages (240) are used in the batch transfer. Page 21
- Page 1 and 2: SMART CARD STANDARDS AND SPECIFICAT
- Page 3 and 4: 4.4.7 Security Requirements........
- Page 5 and 6: Document History Revision Reason Fo
- Page 7 and 8: Acronym List UTFS Universal Transit
- Page 9 and 10: technology to achieve interoperabil
- Page 11 and 12: This report encompasse s the review
- Page 13 and 14: Identify S m art Card Indust ry S t
- Page 15 and 16: The standards and specifications th
- Page 17 and 18: These standards and specifications
- Page 19 and 20: Although there is no “one-to-one
- Page 21 and 22: 4.1.4.2 Card Management Data The st
- Page 23: with ISO/IEC 7816-6, there is no re
- Page 27 and 28: Phone interviews and/or email corre
- Page 29 and 30: The ITSO message body consists of i
- Page 31 and 32: Exhibit 4.2-2 Product Types Type Co
- Page 33 and 34: Capability Values or RFU Product Pr
- Page 35 and 36: opted to contract these services ou
- Page 37 and 38: e given careful consideration for a
- Page 39 and 40: - Transaction date and time - Trans
- Page 41 and 42: cardholder related data as in the c
- Page 43 and 44: CLIENT Exhibit 4.3-9 OFX Security S
- Page 45 and 46: may well be eliminated if, and when
- Page 47 and 48: Exhibit 4.4-4 Condition Dialogue St
- Page 49 and 50: 4.4.7 Security Requirements The Mes
- Page 51 and 52: Application Retailer Product Retail
- Page 53 and 54: Exhibit 4.6-1 CID Edge Interface Me
- Page 55 and 56: 4.6.8 Timing and Routing The CID Ed
- Page 57 and 58: 4.7.4.1 Transaction Data The “Far
- Page 59 and 60: 4.7.4.3 System and Device Data The
- Page 61 and 62: Following the authentication proces
- Page 63 and 64: Data” transaction messages propos
- Page 65 and 66: Field Name Description reading the
- Page 67 and 68: 4.8-7 Product Transactions Usage Me
- Page 69 and 70: 4.8.4.5 Peer-to-Peer Clearing and S
- Page 71 and 72: standard does not mandate the compl
- Page 73 and 74: Item Number Exhibit 4.9-2 Part 1 Fi
these messages constitutes a file. The File Name data element in the message indicates<br />
the name <strong>of</strong> the file to be updated<br />
at the receiver’s location. The Data Record data<br />
element<br />
in each one <strong>of</strong> these messages contains data from a number <strong>of</strong> business<br />
transactions. The data contained in the Data Record data element may, or may not be<br />
based on the message types identified<br />
in this standard. The structure <strong>of</strong> this data<br />
element<br />
is left to the parties involved in the exchange. A file transfer is initiated with a<br />
network message set (804/814), followed by a series <strong>of</strong> file action (340)<br />
messages and<br />
ended with another network message, as illustrated<br />
in Exhibit 4.1-6.<br />
Device<br />
Or<br />
Station/Depot<br />
Computer<br />
Exhibit 4.1-6 File Transfer Process<br />
804<br />
814<br />
340<br />
340<br />
350<br />
804<br />
814<br />
N times<br />
File<br />
Operator Central<br />
System<br />
or<br />
Regional Central<br />
System<br />
Batch transfer allows transaction details to be sent as a series <strong>of</strong> notification, or<br />
instruction messages with an optional reconciliation transaction. The Batch Transfer<br />
does not require a response message for every message sent. Control is maintained by<br />
the use <strong>of</strong> notification, or instruction acknowledgement messages, which may be sent<br />
periodically within the transmission <strong>of</strong> a batch. There are no specific message types<br />
needed to support the Batch Transfer. It is achieved<br />
by the use <strong>of</strong> the existing message<br />
types provided<br />
by the standard.<br />
The batch transfer is initiated by an 804/814 network management messages that define<br />
transfer related control data such as number <strong>of</strong> messages contained in the batch. In the<br />
example flow illustrated in Exhibit 4.1-7, a series <strong>of</strong> Financial Presentment Notification<br />
Messages (240) are used in the batch transfer.<br />
Page 21