Table of Contents - APTAStandards.com
Table of Contents - APTAStandards.com Table of Contents - APTAStandards.com
4.1.4.3 System and Device Data The system and device data related messages are not addressed by this standard. However, the MTI 300 series File Action message class (including 362/340), as explained in the previous section, provides some flexibility to achieve the functionality similar to what is proposed by the Interface Specification Functional Description. The File Action messages are used to: • Add, change, delete or replace a file or record • Inquire into a file • Perform card administration (such as reporting lost or stolen cards) Therefore this message class can be utilized for Negative List, Hotlist, CID Parameter update and Application Update messages proposed by the WG4. 4.1.4.4 Event Data Similar to the schema in the System and Device Data section, there is no specific coverage for this message type in this standard. The MTI 300 series File Action Message class (including 362/340) can also be utilized to carry event data in the Data Record data element of the message. Further definition of the structure, format and content of this data element would be required for the event data transmission. 4.1.4.5 Peer to Peer Clearing & Settlement The ISO/IEC 8583 provides support for bo th peer-to-peer and central system based clearing and settlement schemes. The reconciliation message class supports the exchange of data between two institutions to reach agreement on financial totals. The calculation of the Amount Net Reconciliation data element is achieved by netting the debit and credit amounts in the reconciliation message. The standard defines two types of reconciliation: • Checkpoint reconciliation • Final reconciliation Checkpoint reconciliation period is defined by the Reconciliation Indicator field in the message. A final reconciliation period is ident ified with the Date Reconciliation field and contains any number of checkpoint reconciliation periods. The Reconciliation Data Primary of 12 parts contains all the individual values needed to calculate the net reconciliation in the Amount Net Reconciliation data element. 4.1.5 Data Elements Bit 55 is the Integrated Circuit Card (ICC) data element and is a special form of composite data element used to transmit ICC related data. If the data is in accordance Page 18
with ISO/IEC 7816-6, there is no requirement for a dataset identifier or dataset bitmap as these functions are covered by the ISO/IEC 7816-6 TLV coding structures. The result is that the dataset identifier is replaced by the “T” element, the dataset length object by the “L” element, and the sub elements by the “V” element. Data that is not compliant with the ISO/IEC 7816-6 can still be submitted in this field as long as it follows the standard composite data element structure as defined by the standard as illustrated in Exhibit 4.1-3. Exhibit 4.1-3 Standard Composite Data Element Structure Dataset Identifier Field 55 ICC Related Data Dataset Length Dataset Bitmaps Sub Element Exhibit 4.1-4 contains a sample application of the ICC field with the transit industry related data elements. Exhibit 4.1-4 Sample Structure of Field 55 Field 55 ICC Data Name Value Description Dataset Identifier 71 Fare Transaction Dataset Length 512 Total length of the sub-elements present Dataset Bitmap 0110000001100000 Indicates the following fields that are present Sub-elements Transit Application Profile Object Product Index Object Pass and Transfer Object Transaction History Object Dataset Identifier 43 Load Value Transaction Dataset Length 384 Total length of the sub-elements present Dataset Bitmap 0001010000100000 Indicates the following fields that are present Sub-elements Stored Value (SV) Product Object Add Value Transaction History Object Transaction History Object 4.1.6 Message Sequences The standard provides detailed sequences for message exchange and routing rules. Typically messages consist of a “request-response” pair that is initiated by either card issuers or acquirers, as illustrated in Exhibit 4.1-5. There are provisions for message repetitions when original request message is not responded. Additionally, the standard Page 19
- 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: 4.1.4.2 Card Management Data The st
- Page 25 and 26: these messages constitutes a file.
- 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
4.1.4.3 System and Device Data<br />
The system and device data related messages are not addressed by this standard.<br />
However, the MTI 300 series File Action message class (including 362/340), as<br />
explained in the previous section, provides some flexibility to achieve the functionality<br />
similar to what is proposed by the Interface Specification Functional Description. The<br />
File Action messages<br />
are used to:<br />
• Add, change,<br />
delete or replace a file or record<br />
• Inquire into a file<br />
• Perform card administration (such as reporting lost or stolen cards)<br />
Therefore<br />
this message class can be utilized for Negative List, Hotlist, CID Parameter<br />
update<br />
and Application Update messages proposed by the WG4.<br />
4.1.4.4 Event Data<br />
Similar<br />
to the schema in the System and Device Data section, there is no specific<br />
coverage for this message type in this standard. The MTI 300 series File Action Message<br />
class (including 362/340)<br />
can also be utilized to carry event data in the Data Record<br />
data element <strong>of</strong> the message.<br />
Further definition <strong>of</strong> the structure, format and content <strong>of</strong><br />
this<br />
data element would be required for the event data transmission.<br />
4.1.4.5<br />
Peer to Peer Clearing & Settlement<br />
The ISO/IEC 8583 provides support for bo th peer-to-peer and central system based<br />
clearing and settlement schemes. The reconciliation message class supports the<br />
exchange <strong>of</strong> data between<br />
two institutions to reach agreement on financial totals. The<br />
calculation <strong>of</strong> the Amount Net Reconciliation data element is achieved by netting<br />
the<br />
debit and credit amounts in the reconciliation message. The standard<br />
defines two types<br />
<strong>of</strong> reconciliation:<br />
• Checkpoint reconciliation<br />
• Final reconciliation<br />
Checkpoint reconciliation period is defined by the Reconciliation Indicator field in the<br />
message. A final reconciliation period is ident ified with the Date Reconciliation field<br />
and contains any number <strong>of</strong> checkpoint reconciliation periods. The Reconciliation<br />
Data<br />
Primary<br />
<strong>of</strong> 12 parts contains all the individual values needed to calculate the net<br />
reconciliation in the Amount Net Reconciliation data element.<br />
4.1.5 Data Elements<br />
Bit 55 is the Integrated Circuit Card (ICC) data element and is a special form <strong>of</strong><br />
<strong>com</strong>posite data element used to transmit ICC related data. If the data is in accordance<br />
Page 18