4. Message Structure
NPS-NCS operates a reliable and flexible transaction processing environment that efficiently routes Card Transactions between Merchants/Acquirers/ATM Networks, as applicable, and Issuers, and is comprised of state-of-the-art, fully redundant gateways and flexible applications. This document also describes the security measures used to protect sensitive data. The Message standard is robust and supports a wide range of functionality. To optimize the utilization of all features, users of this Message format are advised to perform necessary updates by the scheduled implementation date, using the latest version officially released by NCHL.
4.1 Message Structure Overview
An ISO 8583 online transaction message includes four parts, i.e. the message header, the message type identifier, the bitmap, and the data elements. The structure is shown as follows:
| Message Header | Message Type Identifier (MTI) | Bitmap | Data Elements | |||||
| Bitmap 1 | Bitmap 2 | 2 | 3 | 4 | ... | 126 | 127 | 128 |
Table 2: Message Structure
As the first element of the message, the message header records length of the message.
The message type identifier, the second element of the message, defines the general categories of the message, e.g. financial message or management message.
The bitmap defines message fields that appear in the message, including either one bitmap or two bitmaps. Primary Bitmap defines Fields 2 to 64; 1st bit of primary bitmap represents the presence of secondary bitmap which defines Fields 66 to 128.
The data element field is the major part of the message. Most of message fields are defined by ISO 8583 and the others are defined and used by NPS-NCS.
4.2 Message Header
Messages sent to NPS-NCS over a socket are required to begin with a 2-byte binary length field indicating the length of the Message that follows. The length of the 2-byte length field is not included in the overall length, all messages from/to NPS-NCS will begin with a 2-byte length field indicating the length of the Message that follows.
4.3 Message Type Identifier
The Message Type Identifier (MTI) begins each Message and is used to determine the Message type. Authorization Requests, Financial Requests, Authorization Advice Messages, and Network Management Messages, for example, are distinguished from each other by the Message Type Identifier. After the type of Message is established, the remaining Message fields can be interpreted in the appropriate context. The MTI is a 4-digit numeric field, where each digit starting from the left indicates - ISO 8583 version, the message class, the message function, and the message origin. Each message is required to have a message type identifier followed by the primary bitmap. The message type in ISO8583-1987 standard is mainly defined according to the source and destination of the message. This document defines the message type transmitted between National Payment Switch (NPS) and NPS Members.
4.3.1 Position 1 – Version Number
First position of the message type identifier (MTI) specifies the version of the ISO 8583 standard used to transmit the message
| MTI | Signifies | NPS Implementation |
|---|---|---|
| 0XXX | ISO 8583: 1987 Version | ✔ |
| 1XXX | ISO 8583: 1993 Version | ✘ |
| 2XXX | ISO 8583: 2003 Version | ✘ |
| 9XXX | Reserved for ISO Use | ✘ |
Table 3: Version Number of ISO 8583 Message
4.3.2 Position 2 – Message Class
Second position of the message type identifier (MTI) specifies the class of the message.
| MTI | Signifies | NPS Implementation |
|---|---|---|
| 01XX | Authorization Messages | ✔ |
| 02XX | Financial Transaction Messages | ✔ |
| 03XX | File Update Messages | ✔ |
| 04XX | Reversal Messages | ✔ |
| 08XX | Network Management Messages | ✔ |
Table 4: Message Class of ISO 8583 Message
4.3.3 Position 3 – Message Function
Third position of the message type identifier (MTI) specifies the function of the message which specifies how the message will flow within the system.
| MTI | Signifies | NPS Implementation |
|---|---|---|
| XX00 | Request | ✔ |
| XX10 | Request Response | ✔ |
| XX20 | Advice | ✔ |
| XX30 | Advice Response | ✔ |
Table 5: Message Function of ISO 8583 Message
4.3.4 Position 4 – Message Origin
Fourth position of the message type identifier (MTI) specifies the location of the message source.
| MTI | Signifies | NPS Implementation |
|---|---|---|
| XXX0 | Acquirer | ✔ |
| XXX1 | Acquirer repeat | ✘ |
| XXX2 | Issuer | ✔ |
| XXX3 | Issuer repeat | ✘ |
Table 6: Message Function of ISO 8583 Message
Following are the valid message type identifiers for NPS Card Switch online specifications:
| Value | Message Type | Purpose |
|---|---|---|
| 0100 | Authorization Request | A user-initiated, real-time request to an Issuer for deciding a Card Transaction that may or may not be ultimately applied to the Card Account. |
| 0110 | Authorization Response | Contains the approved or declined answer to the 0100 Authorization Request. |
| 0120 | Authorization Advice | The 0120 Authorization Advice Message provides a system-initiated notification to an Issuer member stand-in Authorization Response that was made on behalf of the Issuer by NCHL. The Message may be stored and forwarded or sent real-time. Acquirer member may also send a 0120 Authorization Advice Message with the final Card Sale amount after receiving a positive Authorization Response for the Card Sale in a Pre-Authorization Request. |
| 0130 | Authorization Advice Response | Contains the accepted or rejected answer to the 0120 Authorization Advice. |
| 0200 | Financial Transaction Request | A user-initiated, real-time request to an Issuer for deciding a Card Transaction that can be immediately applied to the Card Account. |
| 0210 | Financial Transaction Response | Contains the approved or declined answer to the 0200 Financial Transaction Request Message. |
| 0302 | File Update Request | Contains the file update request for maintaining the stand-in data. |
| 0312 | File Update Response | Contains the response to the file update request message. |
| 0420 | Reversal Advice | A system-initiated Request for a complete reversal of an earlier Authorization or Financial Transaction. The Message may be stored and forwarded or sent real-time. |
| 0430 | Reversal Advice Response | Contains the accepted or rejected answer to the 0420 Reversal Advice. |
| 0800 | Network Management Request (Network Messaging) | A system-generated, real-time request for the status of the system and key management. |
| 0810 | Network Management Request Response (Network Messaging) | Contains the status of the system and key management in response to the 0800 Network Management Request (Network Messaging). |
Table 7: NPS-NCS Message Type Identifier
4.4 Bitmap
After a Message is identified by the Message Type Identifier, the bit map is used to determine the data elements contained in a Message. Although many fields are optional, conditional, or mandatory for specific Message types, a means must exist to determine the fields that are represented in the subsequent stream of bytes. The bit map indicates the presence (1) or absence (0) of a data field. A message can contain one or two bitmaps. The valid combinations of the bit maps are:
• Primary bitmap
• Primary and secondary bitmap
4.4.1 Primary Bitmap
The primary bitmap (Bitmap 1) is the main bitmap. Each message has the primary bitmap. It is composed of 64 binary bits (8 bytes) following the message type identifier. Except the first bit, every bit corresponds to a data element from Field 2 to Field 64. The value of each bit indicates whether the field appears in the message or not:
• If a bit is 0, the corresponding data element does not present in the message.
• If a bit is 1, the corresponding data element presents in the message.
There is no field with the field number “1”. The first bit of the main bitmap is used to indicate whether it is followed by Secondary Bitmap (Bitmap 2).
4.4.2 Secondary Bitmap
The first bit of the primary bitmap indicates whether Secondary Bitmap (Bitmap 2) is present or not. Like the primary bitmap, secondary bitmap is composed of 64 binary bits (8 bytes). Secondary Bitmap corresponds to Field 66 to Field 128, and can be considered as an extension of the primary bitmap. There is no field with field number 65 which to indicate the presence of Tertiary Bitmap. Secondary Bitmap will be used only when the message contains data elements in Field 66 to Field 128.
4.5 Data Elements
The remainder of the Message consists of data elements, each of which represents a specific Message component, such as Field 2 – Primary Account Number (PAN), Field 4 – Transaction Amount, Field 7 – Transaction Date & Time, Field 102 – From Account Number etc. The Message Type Identifier and bit map form the initial segment of a Message, delineating its outset, with the subsequent portion being defined by an array of data elements. Data elements serve as the designated fields intricately carrying the essential information pertaining to the transaction itself. Each Data element has a specified meaning and format. For each data element there is specific data format, size, constraints and description, which are been mentioned in Chapter 6.