6. Data Element Description

6.1 Convention

This chapter defines each of the data element included in the bitmaps currently supported by NPS-NCS. The conventions that are used to represent the data elements are defined first, followed by the fields themselves.

6.1.1 Field Type Attribute

The following table defines how the data elements are interpreted in standard format of field attributes:

Notation	Interpretation
a	Alphabetic characters only (includes blanks)
b	Binary data
n	Numeric characters only (0,1,2,3,4,5,6,7,8,9)
s	Special characters only
an	Alpha and numeric characters only
cn	Compressed numeric code, namely BCD code
as	Alpha and special characters only
ns	Numeric and special characters only
ans	Alphanumeric and special characters only
z	Track data
x	The character 'C' or 'D' to indicate Credit or Debit value

Table 47: Abbreviation used in data element description

6.1.2 Field Length

Each data element is described in a standard field length format, the following table define how field length is to be interpreted:

Field Length	Interpretation
-digit(s)	Fixed length in number of positions. For example, n-10 indicates a 10 digit numeric field.
...digit(s)	Variable length in number of positions. For example, an...7 indicates a variable alphanumeric field with up to 7 positions.
LLVAR	Variable length (LLVAR) fields are composed of a length indicator and the data. The length indicator refers to the number of bytes contained in the data portion of the field whose length shall be less than 100. Example (LLVAR):Length Indicator = 07 Data Field: PAYMENT
LLLVAR	Variable length (LLLVAR) fields are composed of a length indicator and the data. The length indicator refers to the number of bytes contained in the data portion of the field whose length shall be less than 1000. Example (LLLVAR):Length Indicator = 013 Data Field: SPECIFICATION

Table 48: Abbreviation used in data element length

6.1.3 Date and Time

Data elements defining date and time are described in a standard format, the following table defines how date and time are to be interpreted:

Notation	Interpretation
YY	Year (two digits, 00 – 99)
MM	Month (two digits, 01 – 12)
DD	Day (two digits, 01 – 31)
hh	Hour (two digits, 00 – 23)
mm	Minute (two digits, 00 – 59)
ss	Second (two digits, 00 – 59)

Table 49: Abbreviation used for date and time

6.1.4 Data Representation

• All message data fields are aligned on a byte boundary.

• All data is encoded either in EBCDIC or ASCII display representation. The choice of character set depends upon the configuration.

• All fields with data type "b" (binary) are encoded as the display representation of the hexadecimal value. For example, if the field contains the decimal number 959, the application would first convert it into the equivalent hexadecimal representation, 3BF, and then convert that number into the display representation.

• All lengths given indicate the logical number of positions required. For example, a field specified as n-12 indicates that 12 digits are required. The physical length of the field is inferred from the encoding. Using the above example, the physical length of a field of type n-12 would be 12.

• All numeric, type n, fields are right-justified with leading zeros.

• All binary, type b, fields are right-justified with leading zeros.

• All other field types are left-justified with trailing blanks. This only applies if the field is of fixed length.

• Where a field expresses an amount, it will be represented without a decimal point. For example, the amount 23.47 would be represented as 2347. The decimal places are implied.

• Where a field expresses a rate (i.e. a conversion rate), the rate is expressed as xnnnnnnn, where x denotes decimal positions from the right. For example, the number 67123890 is interpreted as 7.123890.

6.2 Data Elements Description Components

Following parameters are covered while describing the data elements of NPS-NCS Switching Interface Specification:

Components	Information Type
Type	Type of data element with field length
Format	Format of data element
Description	Description of data element
Echo	Requirement of echoing the data element in response
Validation	Rules to validate the data element
Presence	Participation of data element in messages

Table 50: Data Elements Description Components

6.3 Detailed Descriptions of Data Elements

6.3.1 DE - 2 Primary Account Number (PAN)

DE- Primary Account Number (PAN)
Type	n..19
Format	LLVAR
Description	This is the Card Number or Primary Account Number of up to 19 digits encoded on Track 1 & Track 2 of the magnetic stripe and tag 5A in EMV data.
Echo	It should be echoed in response.
Validation	The length of PAN should be between 14 – 19 digits.
Presence	The switch requires this field in all 01xx, 02xx, 03xx, 04xx messages.

6.3.2 DE - 3 Processing Code (Pcode)

DE- 3 Processing Code (Pcode)
Type:	n-6
Format:	Fixed
Description:	This field describes the type of a Card Transaction along with the affected account. The Processing Code is used with the Message type to define the type of Card Transaction sent by the Card Acceptor. This element is composed of 3 subfields: Position Length Description 1-2 2 Describes a specific Card Transaction 3-4 2 “From” Account for Card Transactions 5-6 2 “To” Account for transfers

Position 1 & 2	Transaction Type
00	Purchase (of goods or services)
	Purchase with Gratuity or Tip
	Purchase Cancellation / VOID
01	Cash Withdrawal/Cash Advance
03	Preauthorization
	Preauthorization Cancellation
	Preauthorization Completion
09	Purchase with Cashback
	Purchase with Cashback Cancellation
14	Recurring Billing (Recurring Payments) – goods or services
15	EMI/Installment Payment – goods or services
18	Account Verification
20	Refund/ Merchandise Return
21	Deposit
22	Credit Adjustment
26	Original Credit Transaction (OCT)
28	Load Transaction
29	Fund Transfer Credit
30	Balance Inquiry
36	Cheque Book Request
37	Statement Request
38	Mini Statement
40	Fund Transfer Debit
90	Utility Payment
98	PIN Change

Position 3 & 4	From Account Type
00	Default Account
10	Saving Account
20	Checking Account
30	Credit Account

Position 5 & 6	To Account Type
00	Default Account
10	Saving Account
20	Checking Account
30	Credit Account

Echo	It should be echoed in response.
Validation	Processing Code should be from above list.
Presence	This field is required in all 01xx, 02xx and 04xx messages.

6.3.3 DE - 4 Amount, Transaction

DE - 4 Amount Transaction
Type:	n-12
Format:	Fixed
Description:	This field is the Card Transaction amount requested by the Cardholder in the local currency of the Card Acceptor. The value is right justified with leading zeros.
Echo:	It should be echoed in response.
Validation:	The amount field is zero filled and right justified. The decimal places are implied. Example, 000000150070 represents amount 1500.70.
Presence:	The switch requires this field in all messages except network management and file update messages. This field should be zero-filled for Account Verification transactions, Balance Inquiry transactions, Mini Statement transactions, and PIN Change transactions.

6.3.4 DE - 5 Amount, Settlement

DE - 5 Amount Settlement
Type:	n-12
Format:	Fixed
Description:	Settlement Amount is the Card Transaction amount in the Issuer’s currency. This field represents the amount for which the transaction will settle in the settlement currency. If the fees are to be applied by the switch, this field will include the fees.
Echo:	It should be echoed in response if this presents in request message.
Validation:	The amount field is zero filled and right justified. The decimal places are implied. Example, 000000150070 represents amount 1500.70. Whenever Field 5 – Amount, Settlement is present, Field 9 - Conversion Rate, Settlement, Field 16 - Conversion Date, and Field 50 – Currency, Settlement Code must also be present within a Message.
Presence:	The switch requires this field in the messages when field 50 is present. If the Card Transaction currency and Issuer’s currency are the same, this field will not be populated.

6.3.5 DE - 6 Amount, Cardholder Billing

DE - 6 Amount Cardholder Billing
Type:	n-12
Format:	Fixed
Description:	This field represents the amount billed to the cardholder in the currency of the cardholder's account, exclusive of cardholder billing fees. It is the representation of the amount converted from the currency of the acquiring country to the cardholder's billing currency. The rate used to make the conversion is taken from data element 10.
Echo:	It should be echoed in response if this presents in request message.
Validation:	The amount field is zero filled and right justified. The decimal places are implied. Example, 000000150070 represents amount 1500.70.
Presence:	The switch requires this field in the messages when field 10 and field 51 are present.

6.3.6 DE - 7 Transmission Date and Time

DE - 7 Transmission Date and Time
Type:	n-10
Format:	Fixed, MMDDhhmmss
Formatted as below:	Position Length Definition Range 1-2 2 Month 01-12 3-4 2 Day 01-31 5-6 2 Hour 00-23 7-8 2 Minute 00-59 9-10 2 Second 00-59
Description:	The date and time the request is first entered into the data interchange system, expressed in Coordinated Universal Time (UTC) (formerly known as Greenwich Mean Time - GMT). The value must be a valid date and time. Once set, this field remains unchanged for the life of the transaction. The Transmission Date and Time and the Field 11- Systems Trace Audit Number are used to uniquely identify Card Transactions.
Echo:	It should be echoed in response.
Validation:	This field should be in numeric format. Example, Feb 8, 2:30:37 pm represented as 0208143037.
Presence:	The switch requires this field in every message.

6.3.7 DE - 9 Conversion Rate, Settlement

DE - 9 Conversion Rate, Settlement
Type:	n-8
Format:	Fixed
Description:	It contains the conversion rate for settlement amount. The Settlement Conversion Rate is the factor used by NCHL, based upon the Currency Conversion Source, in the conversion from the currency in which the Card Transaction was conducted to the Issuer’s currency. The Transaction Amount (Field 4) is multiplied by the Settlement Conversion Rate (Field 9) to determine the Settlement Amount (Field 5).
Echo:	It should be echoed in response.
Validation:	The left-most digit denotes the number of positions that the decimal separator shall be moved from the right. This field should be in numeric format. For example, the number 67123890 is interprets for rate 7.123890%.
Presence:	If the Card Transaction currency differs from the Issuer’s currency, NPS-NCS will automatically insert this field during transmission. If the Card Transaction currency and Issuer’s currency are the same, this field will not be populated.

6.3.8 DE - 10 Conversion Rate, Cardholder Billing

DE - 10 Cardholder Billing
Type:	n-8
Format:	Fixed
Description:	In cases where a transaction takes place in a currency other than the cardholder's billing currency, this field represents the rate used to make a conversion from the transaction amount in the acquiring institution's currency to the currency of the cardholder's account. Transaction amount is multiplied by cardholder billing conversion rate to determine cardholder billing amount.
Echo:	It should be echoed in response.
Validation:	The left-most digit denotes the number of positions that the decimal separator shall be moved from the right. This field should be in numeric format. For example, the number 67123890 is interprets for rate 7.123890%.
Presence:	The field is required for cross country transactions when field DE-51 is present.

6.3.9 DE - 11 System Trace Audit Number (STAN)

DE - 11 System Trace Audit Number (STAN)
Type:	n-6
Format:	Fixed
Description:	The Systems Trace Audit Number (STAN) is a number assigned by a transaction originator to assist in identifying a Card Transaction. The STAN remains unchanged for the life of the Card Transaction.
Echo:	It should be echoed in response.
Validation:	This field should be in numeric format with zero filled and right justified.
Presence:	This data element is required in all messages. An audit number starting at 1 that will increment for each subsequent transaction from 000001 to 999999.

6.3.10 DE - 12 Local Transaction Time

DE - 12 Local Transaction Time
Type:	n-6
Format:	Fixed, HHMMSS Formatted as below: Position Length Definition Range 1-2 2 Hour 00-23 3-4 2 Minute 00-59 5-6 2 Second 00-59
Description:	The Local Transaction Time represents the time of the transaction in the local time zone of the transaction originator, expressed in hours, minutes, and seconds.
Echo:	It should be echoed in response.
Validation:	This field should be in numeric format. For example, value 171453 represents local time 5:14:53 pm.
Presence:	This data element is required in all messages. This field must remain unaltered for the life of the message.

6.3.11 DE - 13 Local Transaction Date

DE - 13 Local Transaction Date
Description:	This field represents the local date at the terminal when the transaction occurred.
Type:	n-4
Format:	Fixed, MMDD Formatted as below: Position Length Definition Range 1-2 2 Month 01-12 3-4 2 Day 01-31
Description:	This field represents the local month and day at the terminal when the transaction takes place. The value in this field must be a valid date.
Echo:	It should be echoed in response.
Validation:	This field should be in numeric format. For example, value 0214 represents local date: 14 February.
Presence:	This data element is required in all messages. This field must remain unaltered for the life of the message.

6.3.12 DE - 14 Expiration Date

DE - 14 Expiration Date
Description:	This field represents the expiration date of the card in the format YYMM.
Type:	n-4
Format:	Fixed, YYMM Formatted as below: Position Length Definition Range 1-2 2 Year 00-99 3-4 2 Month 01-12
Description:	The year and month after which the Card Number expires. The value in this field must be a valid date.
Echo:	It does not require to be echoed in response.
Validation:	This field should be in numeric format. For example, value 2311 represents card expiry date as November 2023.
Presence:	This field is required for all 0100 Authorization Request and 0120 Authorization Advice Messages from a Merchant/Acquirer. For all other Message requests, this field is required for Card Transactions not containing valid Track Data. For 0420 Reversal Advice Messages, the Expiration Date is not required if it is not received in the Response that is being used to generate the Reversal Advice. This data element is required in all card not present transactions such as e-commerce, manual entry transactions. If either track1 or track2 is captured by the terminal, this field becomes optional. If this field is present, it will be forwarded to the Issuer member.

6.3.13 DE - 15 Settlement Date

DE - 15 Settlement Date
Description:	This field represents the settlement date of the transaction in the format MMDD.
Type:	n-4
Format:	Fixed, MMDD Formatted as below: Position Length Definition Range 1-2 2 Month 01-12 3-4 2 Day 01-31
Description:	The month and day funds will be transferred between Acquirer member and Issuer member.
Echo:	It should be echoed back in the response.
Validation:	This field should be in numeric format. For example, value 0911 represents for a transaction which will settle on September 11.
Presence:	This field is mandatory for all Card Transactions that originate from an ATM Network. For all other Card Transactions, this field may optionally be sent by the Merchant/Acquirer.

6.3.14 DE - 16 Conversion Date

DE - 16 Conversion Date
Type:	n-4
Format:	Fixed, MMDD Formatted as below: Position Length Definition Range 1-2 2 Month 01-12 3-4 2 Day 01-31
Description:	The month and day the conversion rate is effective to convert the Card Transaction amount from the original Card Transaction currency into the Settlement currency based on the Currency Conversion Source.
Echo:	When present, it should be echoed back in the response.
Validation:	This field should be in numeric format. For example, value 0911 represents the currency conversion date for September 11.
Presence:	If the Card Transaction currency differs from the Issuer’s currency, NCHL will automatically insert this field during transmission. If the Card Transaction currency and Issuer’s currency are the same, this field will not be populated. For a cross-currency conversion, Field 16 should be present along with Field 6 and Field 51.

6.3.15 DE - 18 Merchant Category Code (MCC)

DE - 18 Merchant Category Code (MCC)
Type:	n-4
Format:	Fixed
Description:	This field is used to represent the merchant’s type of business, product, or service using the standard Merchant Category Code (MCC) while generating the request which is used to determine the validity of the requested transaction.
Echo:	It is not to be echoed back in the response.
Validation:	This field should be in numeric format with zero filled and right justified. The value should be present as per ISO 18245 MCC codes.
Presence:	This field is mandatory for all 01XX, 02XX, 04XX Messages. The preferred MCC list is provided in Annexure 1.

6.3.16 DE - 19 Acquiring Country Code

DE - 19 Acquiring Country Code
Type:	n-3
Format:	Fixed
Description:	This field contains the code of the country where the acquiring institution is located.
Echo:	If present, it is to be echoed back in the response.
Validation:	This field should be in numeric format. The value should be present as per ISO 3166 for country code list.
Presence:	Issuers member will always receive this field for 0200 Financial Transaction Messages as this is a mandatory field from Acquirers member/network. The valid country code list is provided in Annexure 2.

6.3.17 DE - 22 Point of Service Entry Mode

DE - 22 Point of Service Entry Mode
Type:	n-3
Format:	Fixed
Description:	This field indicates the method by which the PAN was entered as well as the terminal's PIN entry capabilities. This element is composed of 2 subfields and formatted as below: Position Length Meaning Description 1-2 2 PAN Entry Mode Indicates the method by which the Card Number was entered into the system 3 1 PIN Entry Capability Indicates the ability of a terminal (POS Device) to accept PIN data Digit 1 & 2 PAN Entry Mode Example 00 PAN Entry Mode Unknown Assign “00” by default when other values listed for this field do not apply or the PAN Entry Mode is unknown 01 Manual Card Number is manually entered into a POS Device (key entry), including mail and phone orders 02 Magnetic Stripe Card swiped using a POS Device 03 Barcode/QR Code/Payment Code Used for scanning Bar Code or QR code payment, containing either Payment Token or a Card Number, using a POS Device 04 Optical Character Reader (OCR) Used for scanning special characters, such as the account numbers on the bottom of a check 05 Integrated Circuit (IC) Card Reader (Contact) Chip Card Transaction (Chip Card is inserted into a Contact Chip Payment Device) 07 ECommerce Card Transactions by Internet or online orders for which the Cardholder enters their Card Account information into a computer-based browser (not a Merchant mobile app, or any payment method in which Card Account information is stored by the Merchant or their Agent) 10 Stored Card Account Stored Card Account: Where directed by the Cardholder, a Merchant may use Stored Card Account information to conduct Card Not Present Card Sales. PAN Entry Mode 10 is required for Card Sales that are processed using Stored Card Account information. PAN Entry Mode 10 is optional for Merchant-Initiated Transactions, which includes Recurring Payments, Installment Payments, and Unscheduled Payments. PAN Entry Mode 10 must not be assigned to QR Code/Bar Code/Payment Code Transactions, Contactless Card Transactions, or Card Sales with Card Account information stored by an Issuer or provisioned in a digital wallet. 81 Radio Frequency Identification Indicator – Magnetic Stripe Radio Frequency Identification Indicator – Magnetic Stripe: Contactless ZIP® Card Transactions (“tap and pay”) for which the Track Data is obtained from the chip. Contactless transactions using a Mobile Payment Device containing magnetic stripe Card data. Contactless transactions using a Mobile Payment Device containing tokenized magnetic stripe Card data. 82 Mobile Commerce (mCommerce) Mobile Commerce (mCommerce): Online purchases using a Mobile Payment Device with Merchant mobile apps or mobile browsers connected to either cellular data networks or WiFi networks. PAN Entry Mode 82 must not be assigned to Card Transactions for which the Cardholder uses their Stored Card Account information. 83 Radio Frequency Identification Indicator - Chip Radio Frequency Identification Indicator - Chip: Contactless Chip Card transactions (“tap and pay”). Contactless transaction using a Mobile Payment Device containing Chip Card data. Contactless transaction using tokenized Chip Card data. 86 Contactless Interface Change Contactless Interface Change: Identifies when a Chip Card Transaction with a dual-interface Card switches from a contactless Chip Card Transaction to a contact Chip Card Transaction. 90 Voice Authorizations 91 Voice Response Unit (VRU) 92 Batch Authorizations 93 Batch Authorization Cash Access 95 Chip card with unreliable CVD or iCVD 99 Reserved for NCHL Digit 3 PIN Entry Capability 0 Unspecified or Unknown 1 PIN Entry Capability Terminal (POS Device) having PIN entry capability 2 No PIN Entry Capability Terminal (POS Device) does not have PIN entry capability 8 PIN PAD Inoperative Terminal (POS Device) has PIN entry capability, but PIN pad is not currently operative 9 Terminal Verified PIN PIN verified by terminal device (POS Device)
Echo	It is not mandatory to be echoed in response.
Validation	POS Entry Mode should be from the above list.
Presence	This field is required in all 01XX, 02XX, 04XX request messages.

6.3.18 DE - 23 Card Sequence Number

DE - 23 Card Sequence Number
Type:	n-3
Format:	Fixed
Description:	This field is a number used to uniquely identify the Card used to access the Account. It is used for distinguishing between separate cards having the same PAN and is only used in IC card transactions.
Echo:	It is not mandatory to be echoed back in the response.
Validation:	This field should be in numeric format.
Presence:	For quick EMV issuer and full chip issuer, DE 23 will be sent to the issuer in the request.

6.3.19 DE - 25 Point of Service Condition Code

DE - 25 Point of Service Condition Code
Type:	n-2
Format:	Fixed
Description:	This field is used to indicate the condition under which the transaction occurred. Value Meaning 00 Normal 01 Customer Not Present 02 Unattended Terminal 03 Merchant Suspicious 05 Customer Present, Card Not Present 06 EMI Transaction 07 Recurring Payment 08 MO / TO Request 10 Customer Identity Verified 51 Request for Account and CVD verification without authorization for Standing Instruction 59 e-Commerce Request 71 Card present, Magnetic stripe cannot be read
Echo:	It is not mandatory to be echoed back in the response.
Validation:	This field should be from above list. This field should compare with DE-22 and DE-61.
Presence:	It is required in all 01XX, 02XX, 04XX request messages.

6.3.20 DE - 28 Amount, Fees

DE - 28 Amount, Fees
Type:	an-9, x + n8
Format:	Fixed Formatted as below. Position Length Definition 1 1 Valid values for Transaction Fee: C = Credit D = Debit 2-9 8 Fee Amount (Numeric)
Description:	This field represents an additional fee amount such as acquirer convenience fee / terminal surcharge etc. applied to the international transactions. This field consists the same currency value as used in DE-4.
Echo:	When present is to be echoed back in a response.
Validation:	This field should be in alphanumeric format.
Presence:	It is required if additional fee is applied in transaction. First character contains C or D (for Credit or Debit) following the 8-digit amount where last two digits will represent the decimal places. For example, fee amount 499.75 is represented with value D00049975.

6.3.21 DE - 29 Amount, Fees

DE - 29 Amount, Fees
Type:	an-9, x + n8
Format:	Fixed Formatted as below. Position Length Definition 1 1 Valid values for Transaction Fee: C = Credit D = Debit 2-9 8 Fee Amount (Numeric)
Description:	This field represents an additional transaction fee amount applicable to the cardholder for any kind of transactions. This field consists the same currency value as used in DE-4.
Echo:	When present is to be echoed back in a response.
Validation:	This field should be in alphanumeric format.
Presence:	It is required if transaction fee is applied in transaction. First character contains C or D (for Credit or Debit) following the 8-digit amount where last two digits will represent the decimal places. For example, fee amount 499.75 is represented with value D00049975.

6.3.22 DE - 32 Acquiring Institution Code

DE - 32 Acquiring Institution Code
Type:	n..11
Format:	LLVAR Formatted as below. Position Length Definition 1-2 2 Length of AIC digits (LL) 3-(LL+2) Variable Acquiring Institution Code
Description:	This field identifies the unique number assigned by NCHL to the Acquirer member institutions.
Echo:	It should be echoed back in the response.
Validation:	This field contains a 2-byte length followed by assigned Acquiring Institution Code. The maximum length of Acquiring Institution Code is 11. For example, If the assigned Acquiring Institution Identification Code is ‘36123456’, the length of this field will be 08 bytes.
Presence:	This field is required in all type of messages.

6.3.23 DE - 33 Forwarding Institution Code

DE - 33 Forwarding Institution Code
Type:	n..11
Format:	LLVAR Formatted as below: Position Length Definition 1-2 2 Length of FIC digits (LL) 3-(LL+2) LL Forwarding Institution Code
Description:	The prearranged code which serves to identify the institution forwarding a request message to NCHL. This field can be changed for a particular transaction.
Echo:	It should be echoed back in the response.
Validation:	This field contains a 2-byte length followed by Forwarding Institution Code. The maximum length of Forwarding Institution Code is 11. If the institution forwarding the message to NCHL has no assigned Processor ID, the value in this field would be '00000000', and the length of this field would be 8 bytes. If the institution forwarding the message to NCHL has a Processor ID of '12345678', the length of this field would be 8 bytes.
Presence:	This field is required in all types of international transactions and domestic transactions when Third Party Processor (TPP) is involved.

6.3.24 DE - 35 Track 2 Data

DE - 35 Track 2 Data
Type:	z..37, ans
Format:	LLVAR
Description:	This field is the standard Track 2 data encoded on the magnetic stripe of the Card as captured by the device, excluding the LRC (Longitudinal Redundancy Check), beginning sentinel, and end sentinel data. The Track 2 data field is present when valid Track 2 is used to initiate the Card Transaction.
Echo:	It should not be echoed back in the response.
Validation:	This field contains a 2-byte length which is zero-filled and right-justified. This length is followed by up to 37 digits Track 2 data as per ISO 7813 standard. The Track 2 data must contain characters from the set '0-9', '=', and 'D'; any other characters are considered illegal.
Presence:	This field is required in all types of card present transactions. If the Card information is magnetically captured and Track 2 Data is captured, this field must be sent. If both Track 1 Data and Track 2 Data are present in a message, Track 1 will not be validated, and preference may be given to Track 2 Data validation. For Chip Card Transactions, this field must contain the track data from the chip image, not from the magnetic stripe. This remains the same for a particular transaction. This is not used in reversal.

6.3.25 DE - 37 Retrieval Reference Number (RRN)

DE - 37 Retrieval Reference Number (RRN)
Type:	an-12
Format:	Fixed, YDDDHHSSSSSS Formatted as below.
Description:	This field is a document reference number to track all messages related to a given transaction and is supplied by the acquirer, which identifies all Messages and correlates the Response Message with the original Request.
Echo:	It should be echoed back in the response.
Validation:	• ‘HH’ should be derived from DE-12 Time, Local transaction. • Last 6 digits of RRN should be equal to the STAN (DE-11). • For International transactions (acquiring outside Nepal), NCHL may receive an RRN in a format other than NCHL format i.e. 12 digits alpha numeric but not in YDDDHHSSSSSS format.
Presence:	• Presence of this field is mandatory for all types of transactions. • In reversal messages, the acquirer is required to transmit DE-11 and DE-37 of the original transaction. • The value should be same in request as well as response. And this value should remain same during complete transaction cycle.

6.3.26 DE - 38 Authorization Identification Response

DE - 38 Authorization Identification Response
Type:	an-6
Format:	Fixed
Description:	This field is the six-position approval Response Code (Authorization Code) that is assigned by the source of the approved Response.
Echo:	This authorization code is assigned by an issuer/NCHL.
Validation:	This field contains a 6 bytes alphanumeric value including spaces.
Presence:	This field is required for all successful authorized transactions. This is to be generated by the issuer / NCHL and should not be filled by the acquirer. For domestic transactions, this field should not contain all zeroes or all blank spaces or special characters in response.

6.3.27 DE - 39 Response Code

DE - 39 Response Code
Type:	an-2
Format:	Fixed
Description:	This field is the standard ISO Response Code that indicates the status of the Request/Advice.
Echo:	It is assigned by an Issuer.
Validation:	This field contains a 2 bytes alphanumeric value as per below Response Code List.
Presence:	Mandatory for all transactions whether successful or unsuccessful, this field is present in response as per below list.

Response codes and their definition is listed here.

Response Code	Definition	Required Action
00	Approved or completed Successfully	Approve
03	Invalid Merchant	Decline
04	Capture Card	Decline
05	Do not Honor, In case CVD, CVD2, iCVD, CAVV verification fails, Inactive or Dormant account	Decline
07	Pick-up Card, special condition	Decline
08	Issuer Timed Out	Decline
12	Invalid transaction or if member is not able to find any appropriate response code	Decline
13	Invalid amount	Decline

Response Code	Definition	Required Action
14	Invalid card number	Decline
15	No such issuer	Decline
17	Customer cancellation (for void)	-
20	Invalid response	Decline
21	No action taken	Decline
22	Suspected malfunction	Decline
25	Unable to locate record	Decline
27	File Update field edit error	Decline
28	Record already exists in the file	Decline
29	File Update not successful	Decline
30	Format error	Decline
34	Suspected fraud	Decline
36	Restricted card	Decline
38	Allowable PIN tries exceeded	Decline
39	No credit Account	Decline
40	Requested function not supported	Decline
41	Lost Card	Decline
43	Stolen Card	Decline
51	Not sufficient funds	Decline
52	No checking account	Decline
53	No savings account	Decline
54	Expired card	Decline
55	Invalid PIN	Decline
56	No Card record	Decline
57	Transaction not permitted to Issuer/Cardholder	Decline
58	Transaction not permitted to Acquirer/terminal	Decline
59	Transactions declined based on Risk Score	Decline
61	Exceeds withdrawal amount limit	Decline
62	Restricted card	Decline
63	Security violation	Decline
64	Original amount incorrect	Decline
65	Exceeds withdrawal count limit	Decline
67	Hard capture (requires ATM pick-up)	Decline
68	Response received too late	Decline
71	Deemed Acceptance	Approve
74	Transactions declined by Issuer based on Risk Score	Decline
75	Allowable number of PIN tries exceeded	Decline
76	Invalid/nonexistent “to” Account specified	Decline
77	Invalid/nonexistent “from” Account specified	Decline
78	Invalid/nonexistent Account specified (general)	Decline
81	Cryptographic Error	Decline
82	Invalid CAVV	Decline
87	Network unavailable	Decline
89	Invalid MAC	Decline
90	Cut-off is in process	Decline
91	Authorization system or Issuer system inoperative	Decline
92	Unable to route transaction	Decline
93	Transaction cannot be completed. Compliance violation	Decline
94	Duplicate transmission detected	Decline
95	Reconcile error	Decline
96	System malfunction	Decline
97	Fallback Transaction declined	Decline
98	Duplicate Reversal	Decline

Response Code	Definition	Required Action
99	Duplicate Transaction	Decline
CI	Compliance error code for issuer	Decline
CA	Compliance error code for acquirer	Decline
E1	AAC Generated	Decline
E2	Terminal does not receive AAC and TC	Decline
E3	ARQC validation failed by Issuer	Decline
E4	TVR validation failed by Issuer	Decline
E5	CVR validation failed by Issuer	Decline
ED	E-commerce decline	Decline
P5	PIN Change/Unblock failed	Decline
P6	New PIN not accepted	Decline
I1	Transaction type not supported for acquirer	Decline
I2	Transaction type not supported for issuer	Decline
I3	Transaction from originating country not allowed for acquirer	Decline
I4	Originating country not supported by issuer	Decline
I5	Originating channel not allowed for issuer	Decline
I6	Origination point not supported for bin	Decline
I7	Invalid transaction currency for acquirer	Decline
1A	Customer Authentication Required	Only applicable to Process Code 18, Account Verification.
N1	System up	The Messages can be routed through this connection.
N2	Soft down	The system is available but Messages should only be routed through this connection as a last resort.
N3	System down	No Messages should be routed through this connection.
N7	Decline for AVS or CID mismatch	This Response Code is only applicable to Host Capture Authorizations.

Table 51: Response Code List

6.3.27.1 Response Code Scenario

1. Message Validation Error

a. When NCHL receives 0100/0200 request from Acquirer member bank and at the time of data validation if NCHL detects an error, then NCHL would decline the transaction and respond back to acquirer with response code ‘CA’ in 0110 / 0210 response message and DE-44 specifying data element in error. For this response code member acquirer bank should not send a reversal.

b. When NCHL receives 0110 / 0210 response from Issuer member bank and at the time of data validation in response if NCHL detects an error, then NCHL would decline the transaction and respond back to acquirer with response code ‘CI’ in 0110 / 0210 response message. At same time NCHL would generate a reversal to member issuer bank with response code ‘CI’ with DE-44 specifying data element in error.

c. If NCHL receives 0420 reversal from Acquirer member bank and at the time of data validation if NCHL detects error, then NCHL would respond with 0430 back to acquirer with response code ‘00’ and DE-44 specifying the data element in error only for presence of DE 14/35/45/52/63 and absence of DE 39. For this response code member acquirer bank should not raise repeat reversal. Acquirer has to rectify their message and settle those specific transaction offline.

2.Issuer response Timed Out/Late response (STIP not activated)

When NCHL sends 0100 / 0200 request to Issuer member bank and do not receive response within the stipulated time, NCHL response back to acquirer with response code ‘91’and sends reversal to issuing member bank with response code ‘91’ indicating a full reversal.

3.Issuer offline/Signed off

If Issuer member bank is in offline/signed off and NCHL receives 0100 / 0200 request from the acquirer and if issuer member bank is not a part of STIP, then NCHL will response back with ‘91’ response code to Acquirer member bank. Acquirer need not generate reversal for this transaction.

4.Acquirer Time-out

When an acquirer sends a 0100/ 0200 message to NCHL but do not receive the response within the stipulated time, then acquirer sends a reversal 0420 message with response code ‘68’.

5.Terminal Failure

When an acquirer has received an approved response 0110/ 0210 with a valid DE-38 but fails to send the response to the terminal, then acquirer sends a reversal 0420 message with response code ‘22’. For ATM transactions response code may be ’21’.

6. Customer Cancellation

When an acquirer sends a 0100 and has received an approved response 0110 with a valid DE-38 but customer cancels the transaction by sending a void transaction at POS terminal, then acquirer sends this void as reversal with response code ‘17’ to NCHL.

7. E-commerce Implementation

a. If for an E-commerce transaction, acquirer is sending DE 48 Tag 054 as 05/06/07/08 in request then NCHL will route the transaction to the issuer and if issuer approves the transaction NCHL will route the successful response code ‘00’ to the acquirer.

b. If for an E-commerce transaction, acquirer is sending DE 48 Tag 056 as 05/06/07/08 in request then NCHL will route the transaction to the issuer and if issuer decides to reject this with decline response code ‘ED’. NCHL will route the declined response to the acquirer.

c. If for an E-commerce transaction, acquirer is sending DE 48 Tag 056 as 05/06/07/08 in request then NCHL will route the transaction to the issuer and if issuer declines the transaction with response code other than ‘ED’ transaction then NCHL will route the declined response code to the acquirer.

d. If for an E-commerce transaction, acquirer is sending DE 48 Tag 056 as 05/06/07/08 in request then NCHL will route the transaction to the issuer and if issuer declines the transaction with response code other than ‘ED’ and that response is not from the table defined in DE 39 then NCHL will route this to the acquirer with response code ‘CI’ and NCHL will log this as issuer compliance as IEC039. NCHL will also send reversal to the issuer for the same with response code ‘CI’ and DE 44 as IEC039.

8.International e-Commerce Transactions of NepalPay Cards

a. In case of International e-Commerce transactions, NCHL will populate e-Commerce Indicator Tag054 in DE-48 as ‘08’ irrespective of CVD2 presence in the transaction.

b. Issuer can identify an e-commerce transaction from value ‘810’ in DE-22 (PoS Entry Mode) and value ’59’ in DE-25 (PoS Condition Code).

c. Issuer from values in data fields, like DE-6 (Amount, Cardholder Billing), DE-51 (Currency Code, Cardholder Billing), DE-19 (Acquiring Country Code), Merchant Country Code in DE-43 (Card Acceptor Name/Location), can identify the transaction as International.

9. Original Credit Transaction (OCT) Message

In case of OCT transaction, the merchant acquirer bank will reject the transaction with response code 03 in case of incorrect merchant PAN or merchant (merchant account) status. Merchant acquirer bank shall not populate response code 71 (deemed acceptance) in any case. In case the originator is receiving response code 71 from NCHL, originator bank shall not reverse the debit to the consumer. In case the originator bank times out with NCHL, originator should mark the transaction with response code 71. Originator has to reconcile the OCT messages having response code 71 with the raw data file / settlement report received from NCHL.

6.3.28 DE - 41 Card Acceptor Terminal Identification

DE - 41 Card Acceptor Terminal Identification
Description	Card Acceptor Terminal Identification identifies a Point of Service Device at the Card Acceptor location where the Card Transaction originates. Merchants, Acquirers, and TPP Networks can fill this field with any ID number that assists them in identifying specific Point of Service Devices. It should be unique within that acquirer but need not be unique within the several acquirers/networks.
Type	ans-8
Format	Fixed
Echo	It is to be echoed back in response.
Validation	This field contains 8 bytes alphanumeric and special characters.
Presence	This field is required in all messages.

6.3.29 DE - 42 Card Acceptor Identification Code

DE - 42 Card Acceptor Identification Code
Type	ans-15
Format	Fixed
Description	This field contains the identifier of card acceptor i.e. Merchant ID operating the point of service. The value in this field is network dependent.
Echo	It is not to be echoed back in response.
Validation	This field contains 15 bytes alphanumeric and special characters.
Presence	This field is required in all transaction request messages.

6.3.30 DE - 43 Card Acceptor Name / Location

DE - 43 Card Acceptor Name / Location
Type	ans-40
Format	Fixed, Formatted as below. Position Length Description 1-22 22 Terminal/Merchant’s Name, left-aligned and space-padded. 23-35 13 Terminal/Merchant’s City, left-aligned and space-padded. 36-37 2 Terminal/Merchant’s state (01-07) 38-40 3 Terminal/Merchant’s country code (524)

Description	This field is used for the card acceptor name and location. It is presented in a format which is printed on the customer's statement.
Echo	It is not mandatory to be echoed back in response.
Validation	This field contains 40 bytes alphanumeric and special characters.
Presence	This field is required in all transaction request messages.

6.3.31 DE - 44 Additional Response Data

DE - 44 Additional Response Data
Type:	an..50
Format:	LLVAR
Description	Data element number of the first field where error occurred for which the rejection has happened. The detail of the reject reason is listed in below table.
Echo	This is to be generated and populated by NCHL for response messages.
Validation	This field contains a 2-byte length field which is zero filled and right justified, followed by up to 50 alphanumeric characters. The total length of this field cannot exceed 52 bytes.
Presence	This is conditional and should be present in responses for all those transactions which are rejected by NCHL.

Reject Reason codes and their values is listed here.

Reject Reason Code	Entity	Error in Data Element	Reject Reason
Issuer Compliance Reject Reason code
AMTI	Acquirer	MTI	Invalid MTI for this transaction type - If MTI is 0200 when transaction is DMS type - If MTI is 0100 when transaction is SMS type
A002	Acquirer	2	Card number absent in transaction request.
A003	Acquirer	3	Processing code does not match with standard values.
A004	Acquirer	4	Amount absent in financial transactions.
A005	Acquirer	5	For international transaction this should be present.
A006	Acquirer	6	For international transaction this should be present.
A007	Acquirer	7	Transmission date and time absent in request.
A011	Acquirer	11	DE-11 i.e. STAN is absent in Request.
A012	Acquirer	12	Transaction time is absent or Time exceeds its max limit i.e. DE-12.
A013	Acquirer	13	Transaction date is absent or Date exceeds its max limit.
A014	Acquirer	14	Card expiration date is absent in CNP transaction.
A015	Acquirer	15	Settlement date is absent.
A018	Acquirer	18	MCC is absent or present in negative MCC list.
A019	Acquirer	19	Acquirer institution country code is absent.
A022	Acquirer	22	Pan entry mode and pin entry Cap is absent or not as per standard list.
A023	Acquirer	23	For an EMV based transaction this should be present.
A025	Acquirer	25	POS condition code is absent or not as per the standard list.
A032	Acquirer	32	Acquirer ID absent or not as per the value for the acquirer in standard table.
A033	Acquirer	33	For international transaction this should be present.
A035	Acquirer	35	Track2 absent in card present transaction.
A037	Acquirer	37	RRN is absent.
A038	Acquirer	38	DE38 is present in Request from acquirer.
A039	Acquirer	39	DE39 is absent in the reversal.
A041	Acquirer	41	DE-41 is absent.
A042	Acquirer	42	DE-42 is absent.
A043	Acquirer	43	DE-43 is absent.
A044	Acquirer	44	DE-44 is present in request from acquirer.
A048	Acquirer	48	DE-48 is absent for this transaction.
A049	Acquirer	49	DE-49 is absent.
A052	Acquirer	52	PIN block is not present in pin based transaction
A054	Acquirer	54	In Cashback transaction, value in DE-54 greater than DE-4 or DE 54 is absent
A055	Acquirer	55	IC data is absent in chip based transaction
A061	Acquirer	61	DE-61 is absent
A063	Acquirer	63	DE-63 is absent for Account Verification message.
A070	Acquirer	70	DE-70 is absent for Network management message.
A090	Acquirer	90	DE-90 is not present in reversal request / advice
A091	Acquirer	91	DE-91 is not present in file update message
A104	Acquirer	104	DE 104 is absent in OCT Message received from originator
A105	Acquirer	105	DE 105 is absent in token based transaction
A106	Acquirer	106	DE 106 is absent in cardless transaction
A120	Acquirer	120	DE 105 is absent
A125	Acquirer	125	DE-125 is absent for file update message.

Reject Reason Code	Entity	Error in Data Element	Reject Reason
Acquirer Compliance Reject Reason code
I003	Issuer	3	Processing code does not match with request.
I004	Issuer	4	Transaction Amount does not match with request.
I006	Issuer	6	Cardholder Billing Amount does not match with request.
I007	Issuer	7	Transmission Date and Time does not match with the request.
I012	Issuer	12	Transaction time does not match with the request.
I013	Issuer	13	Transaction date does not match with the request.
I014	Issuer	14	Card Expiration date is present in response.
I019	Issuer	19	Acquiring institution country code does not match with the request.
I023	Issuer	23	Card sequence number is not present in response for full issuer chip based transaction.
I035	Issuer	35	Track2 present in response.
I038	Issuer	38	Authorization code not present in successful response. Transaction will be rejected.
I039	Issuer	39	Response code not present in response or not from the valid list. Transaction will be rejected.
I048	Issuer	48	DE-48 is absent for this transaction.
I049	Issuer	49	Value does not match with the request or not present in response.
I051	Issuer	51	Value does not match with the request or not present in response.
I052	Issuer	52	PIN block present in response.
I054	Issuer	54	Absent in balance inquiry reply and logging in cash based transaction.
I055	Issuer	55	ARPC is not present in response for full issuer chip based transaction.
I061	Issuer	61	DE-61 present in response.
I063	Issuer	63	DE-63 present in response.
I090	Issuer	90	DE-90 present in 0110/ 0210 response or absent in 0430 response.
I102	Issuer	102	Present in response from issuer but value does not match with request.
I103	Issuer	103	Present in response from issuer but value does not match with request.
I104	Issuer	104	Field Missing in Response message from merchant acquirer in OCT message.
I120	Issuer	120	Value does not match with the request or not present in response.

Table 52: Response Code List

6.3.32 DE - 45 Track 1 Data

Type:	z..76
Format:	LLVAR
Description	This field contains the Track1 data as read from the card stripe by the terminal. The format of the track should be in ISO 7813 format. The transaction will contain this field if track2 data is not available or the terminal cannot read track2.
Echo	It should not be echoed back in response.
Validation	This field contains a 2-byte length field which is zero filled and right justified, followed by up to 76 alphanumeric characters. The total length of this field cannot exceed 78 bytes.
Presence	This field is optional in all transaction messages.

6.3.33 DE - 48 Additional Data 1 (Private Use)

DE - 48 Additional Data 1 (Private Use)
Type:	an...999
Format:	LLLVAR
Description:	This field contains private data associated with NCHL messages. The contents of field 48 are tag based to identify the individual element within the data field. The tag based value is formatted using the “tag-length-value (TLV)” encoding procedure. Tag Presence Length Description Values 050 Mandatory an-6 Channel Code Channel Description GENATM Transactions from ATM MICATM Transactions from Micro ATM GENPOS Transactions from POS ECOMRC Transactions from Ecommerce WALLET Transactions from wallet MOBILE Transactions from mobile 051 Conditional n..4 CVD2 Value - 052 Conditional a-1 CVD2 Match result Value Description M Matched N Not matched 053 Conditional a-1 CVD/iCVD Match result code Value Description M Matched N Not matched 054 Conditional n-2 Ecommerce indicators Value Description 05 Secure Ecommerce with 3D Secure 06 Not authenticated security transaction. Merchant attempted to authenticate using 3D secure 07 Non-authenticated Security Transaction 08 Non-secure transaction 15 Secure E-Commerce transaction registration with OTP 17 Secure E-commerce transaction registration with other method 21 Secure E-commerce transaction with valid Image select or valid OTP 31 e-Commerce (Card + OTP) - OTP Authentication by IAS 33 e-Commerce (with only card details) 35 e-Commerce with Card and Online Pin 50 Quick Checkout, Authenticated by Issuer IAS (Card + OTP) 51 Quick Checkout Authenticated by Issuer (Card + Online Pin) 055 Conditional n-6 Fraud Score To be populated by NCHL NCHL will send 999999 to the issuer as default value indicating that fraud checking is not performed by NCHL. 060 Conditional n-2 Transaction Authorization Indicator During chip transactions, if the issuer has opted for on-behalf or EMV STIP services, NCHL is populated, ensuring a seamless and secure request process. Value Description 01 If it is authorized successfully in STIP. Only available in STIP for EMV full chip Issuers in STIP mode. 02 If it is authorized successfully in STIP. Only available in STIP for Quick EMV Issuance. 03 Decline in STIP 04 ARQC validation is done by NCHL and is successful. 05 ARQC & CVV/iCVV validation is done by NCHL and is successful. 06 ARQC, CVV/iCVV & PIN validation is done by NCHL and is successful. 07 NCHL will reject the transaction based on CVR validation in case of Quick EMV. Issuer will receive authorization advice with this value. 08 ARQC validation failed at NCHL when issuer is participating in quick EMV issuance or EMV STIP. Issuer will received authorization advice message with this value. 09 NCHL will reject the transaction based on TVR validation in case of Quick EMV. Issuer will receive authorization advice with this value. 061 Conditional n-30 Transaction Id Transaction Id-contains a unique transaction id that is used for E-Commerce transaction 070 Conditional an-10 Loyalty Points Digits Position Description 2 1-2 LT = Loyalty CB = Cashback 8 3-10 The value of loyalty point or cashback amount supporting 2 decimal points, right justified with leading zeros. Example: Loyalty based transaction with loyalty point 10.75, value of tag 070 becomes LT00001075 Cashback based transaction with cashback value 1055.83, value of tag 070 becomes CB00105583 [Note: Cashback amount will also be populated in DE-54 of the request message. 071 Conditional n-8 Loyalty Redemption Points Contains the value of loyalty redemption point (supporting 2 decimal points), right justified with leading zeros. Example: For redemption point 1534, value of tag 071 becomes ‘00153400’. 080 Optional n-9 Income tax PAN number This contains the income tax PAN number 081 Optional n-13 Customer mobile /telephone number This tag captures the customer mobile number including country code Note: Tag data length is always represented in 3 bytes.

Echo:	When NCHL sends a request, it is essential to note that the information should not be echoed back in the response.
Validation:	This field contains a 3-byte length field which is zero filled and right justified, followed by up to 999 alphanumeric characters. The total length of this field cannot exceed 1002 bytes. Each tag is required to have a length of 3 bytes, and the data must be populated in accordance with the specified format.
Presence:	Tag Requirements Tag 050 Should be present for all transactions (01XX, 02XX, 04XX) both in request and response. Tag 051 Shall be present for ‘Card Not Present’ transaction in request. Same will be optional for Token based E-Com transactions. Tag 052 Should be present for all 'Card Not Present' scenarios and value should be 'M' in response, after successful CVD2 verification by Issuer. Should be present for all 'Card Not Present' scenarios and value should be 'N' in response, in case of a failed CVD2 verification by Issuer. It is strongly recommended that for every transaction issuer must perform CVD2 verification. Tag 053 Should be present for all 'Card Present' scenarios and value should be 'M' in response, after successful CVD/iCVD verification by Issuer. Should be present for all 'Card Present' scenarios and value should be 'N' in response, in case of a failed CVD/iCVD verification by Issuer. It is strongly recommended that for every transaction issuer must perform CVD/iCVD verification. Tag 054 Should be present for all E-Commerce transaction in request. Tag 055 Should be populated by NCHL and will be sent to the issuer as per issuer configuration for generating fraud score. Issuer will not send this to NCHL in response. Tag 060 Should be present for all EMV based transactions and to be populated by NCHL and issuer will not send this in response. Tag 061 Should be present in all E-commerce transaction request and not to be echoed in response from the issuer, However NCHL will populate this field in response and send this to the acquirer. Tag 070 Should be present for loyalty-based transactions both in request and response. Tag 071 Should be present for loyalty redemption-based transactions both in request and response. Tag 080 Acquirer can populate Income Tax PAN number in request. Tag 081 Acquirer can populate mobile/telephone number in request.

6.3.33.1 DE – 48 for Dynamic Key Exchange

DE-48 specification for network messages will not follow TLV format. DE-48 will follow LLLVAR format where last 6 digits of the field will have key check value. Key length will vary basis on Double/ Triple length key. The below is applicable in Network Management messages to be used in Dynamic Key Exchange.

Table 53: Key Exchange Format

6.3.34 DE - 49 Currency Code, Transaction

DE - 49 Currency Code, Transaction
Type:	n – 3
Format:	Fixed
Description:	This field identifies the currency as per ISO 4217 for currency code of a particular transaction amount as listed in Annexure 2. For example, NPR transactions will contain value 524, INR transactions will contain value 356 and dollar transactions will contain value 840. This field identifies the Currency type of the following amount fields:
Amount Fields:	Amount, Transaction (DE - 4) Amount, Fees (DE - 28) Amount, Fees (DE - 29) Replacement Amounts (DE - 95)
Echo:	It should be echoed back in response.
Validation:	This field is composed of 3 digits, zero filled and right justified.
Presence:	This field requires in all transaction messages.

6.3.35 DE - 50 Currency Code, Settlement

DE - 50 Currency Code, Settlement
Type:	n – 3
Format:	Fixed
Description:	This field identifies the currency as per ISO 4217 for currency code of a particular settlement amount as listed in Annexure 2. This field identifies the Currency type of the following amount fields:
Amount Fields:	Amount, Transaction (DE - 5)
Echo:	It should be echoed back in response.
Validation:	This field is composed of 3 digits, zero filled and right justified. When DE – 5 is present, this field should be present.
Presence:	This field requires in all cross-country transaction messages.

6.3.36 DE - 51 Currency Code, Cardholder Billing

DE - 51 Currency Code, Cardholder Billing
Type:	n - 3
Format:	Fixed
Description:	This field identifies the currency as per ISO 4217 for currency code of a particular cardholder billing amount as listed in Annexure 2. This field identifies the Currency type of the following amount fields:
Amount Fields:	Amount, Transaction (DE - 6)
Echo:	It should be echoed back in response.
Validation:	This field is composed of 3 digits, zero filled and right justified. When DE – 6 is present, this field should be present.
Presence:	This field requires in all cross-country transaction messages.

6.3.37 DE - 52 Personal Identification Number (PIN) Data

DE - 52 Personal Identification Number (PIN) Data
Type:	b - 16
Format:	Fixed, ANSI Format
Description:	The block of data containing encrypted PIN block. PIN should be encrypted as a block of 16 hexadecimal digits. This field must contain the encrypted ANSI PIN block.
Conditions for Presence:	Positions 1-2 of Field 22 (POS Entry Mode) equals 05 or 95 The Cardholder verification method is online PIN, and The Chip Card Terminal and Acquirer support online PIN. Additionally, this field must be present for PIN Change (Process Code 98) transactions and must contain the current PIN.
Echo:	It should not be echoed back in response.
Validation:	It should be 16 characters hexadecimal numbers which can be validated through HSM.
Presence:	Mandatory for all pin-based transactions.

6.3.38 DE - 54 Additional Amounts

DE - 54 Additional Amounts
Type:	an…120
Format:	LLLVAR
Description:	This field indicates additional amounts for a transaction. In a 0100/0120/0200/0220 message, this field represents the cashback amount. In any 01xx/02xx response message, it can be used to deliver account balances to acquirer. Each balance is represented as a 20-byte field and is managed as below. Digit 01 - 02 Account Type 00 Unspecified / Unknown 10 Saving 20 Checking 30 Credit 90 Cash Back Digit 03 - 04 Balance / Amount Type 00 Default 01 (ATM Only) Ledger Balance 02 (ATM Only) Available Balance 90 Cash Back Digit 05 - 07 Currency Code NNN ISO Currency Code as per Annexure 2 Digit 08 Amount Sign C Positive Balance D Negative Balance Digit 09 - 20 Amount NNNNNNNNNNNN For balance enquiry this shall be populated in response. For purchase with cashback request message (DE-3 = 09), this field shall be populated and value would be: Position Length Value 1-2 2 90 3-4 2 90 5-7 3 524 8 1 D 9-20 12 Cash bank amount
Echo:	It should be populated in transaction response message. For cashback, when presents in request message, should not be echoed in response message.
Validation:	This field contains a 3-byte length field which denotes the total field length followed by up to six balance subfields. Each subfield is 20 bytes in total. The maximum length is 123 bytes.
Presence:	This field is conditional one, for all balance inquiry this should contain the customer balance and for purchase with cashback transactions this should contain the cash back amount. For example: • ATM Balance Inquiry and Cash Withdrawal with Balance would be: 0401001524C0000012345001002524C000001234567. • Purchase with cashback would be: 0209090524D000001234500.

6.3.39 DE - 55 Chip Data (IC Data)

The following tables consists of mandatory (M), conditional (C) and optional (O) subfields (tags) associated for field 55 (IC Data).

DE - 54 Additional Amounts
Type:	an…120
Format:	LLLVAR
Description:	This data element is present in full-issuance chip transactions. DE 55 must be ‘TLV’ encoded and must contain the information (mandatory and optional) as specified in below message layouts. Each element will consist of three sub components, a “Tag”, a “Length” and a “Value”. The tags and the length are hexadecimal values. Name Length (Byte) Tag 1 - 2 Tag Length 1 Tag Value Variable This field will contain as many tags as required in the above manner as long as the maximum length of the field does not exceed the maximum permissible limit. The length of DE 55 will be equal to the total length of all the tag-length-value sets. This field may contain some tags that the receiving issuer or acquirer does not recognize or does not expect. The receiver must ignore such tags and continue processing the next tag in DE 55
Echo:	ARQC should not be echoed back in response. Issuer should generate the ARPC and send back to acquirer.
Validation:	It can be validated as per TLV rules.
Presence:	To meet the needs of changing of the subfields, this field uses a TLV (tag-length-value) representation, i.e. each subfield consists of tag (T), length of subfield value (L) and subfield value (V). The attribute of tag is bit and is represented with hexadecimal system occupying 1~2 bytes. For example, “9F33” is a tag that occupies two bytes, while “95” is a tag that occupies one byte. If the last five bits of the first byte of the tag (note: bytes are sequenced from the left to the right, so that the first byte is the byte at far left. bit sequencing follows the same rule) are “11111”, it shows this tag occupies two bytes, e.g. “9F33”; otherwise the tag occupies one byte, e.g. “95”. • Tag 9F33 = 10011111 00110011, here last five bits of first byte (9F) is 11111 this means this tag would be of 2 byte length. • Tag 95 = 10010101, here last five bits of first byte (95) is 10101 this means this tag would be of 1 byte length.

The following tables consists of mandatory (M), conditional (C) and optional (O) subfields (tags) associated for field 55 (IC Data).

S.N.	Data Element	Description	Tag	Length	Format	0100/0200	0110/0210	0120/0220	0420	Content Condition
1	Amount Authorized	Authorized amount of the transaction	9F02	6	n-12	M	-	M	O	-
2	Amount Other	Secondary amount associated with the transaction representing a cash back amount	9F03	6	n-12	C	-	C	O	Mandatory when Cash at Checkout is allowed and there is a Cash at Checkout amount except 0400/0420
3	Application Identifier (AID)	Identifies the application as described in ISO 7816-5	9F06	5-16	b	O	-	O	O
4	Application Interchange Profile (AIP)	Indicates the capabilities of the Card to support specific functions in the application	82	2	b	M	-	M	O
5	Transaction Counter (ATC)	Counter maintained by the application in the chip (incrementing the ATC is managed by the chip ICC)	9F36	2	b	M	-	M	O
6	Application Cryptogram (AC)	Application Cryptogram generated by the Chip Card when requesting online processing and used by the Issuer to verify the authenticity of the Card in online authorization messages	9F26	8	b	M	-	M	O
7	Application Usage Control (AUC)	Indicates the Issuer’s specified restrictions on the geographic usage and services allowed for the application	9F07	2	b	O	-	O	O
8	Cryptogram Information Data	Indicates type of cryptogram i.e., Application Authentication Cryptogram (AAC), Transaction Certificate (TC), Application Request Cryptogram (ARQC)	9F27	1	b	O	-	O	O
9	Card Verification Method (CVM)	Indicates the results of the last CVM performed	9F34	3	b	O	-	O	O
10	Results Dedicated File (DF) Name	Identifies the name of the DF as described in ISO 7816-4	84	5-16	b	M	-	O	O	-
11	Form Factor Indicator	The type of payment Card used in a Card Transaction.	9F6E	8, var.	b	C	-	C	C	If the Form Factor Indicator data is available on the Card, the Merchant, Acquirer or Processor must forward this information to the Issuer.
12	Interface Device (IFD) Serial Number	Unique and permanent serial number assigned to the IFD by the manufacturer	9F1E	8	an-8	O	-	O	O	-
13	Issuer Application Data	Contains proprietary application data for transmission to the Issuer in an online transaction.	9F10	Var. up to 32	b	M	-	M	O	-
14	Issuer Authentication Data (IAD)	Data sent to the Integrated Circuit Card (ICC) for online Issuer authentication must contain a concatenation of the following data	91	8-16	b	-	C	-	-	Present if online Issuer authentication performed
15	Issuer Script Template 1	Contains proprietary Issuer data for transmission to the Integrated Circuit Card (ICC) before the second GENERATE AC command	71	Var. up to 127	b	-	C	-	-	Present if sent by Issuer
16	Issuer Script Template 2	Contains proprietary Issuer data for transmission to the Integrated Circuit Card (ICC) after the second GENERATE AC command	72	Var. up to 127	b	-	C	-	-	Present if sent by Issuer
17	Storage Data	A location for Merchants to store information in the chip on the Chip Card during a Card Transaction.	DF3F	Var. up to 114	b	O	-	O	O	-
18	Terminal Application Version Number	Version number assigned by the payment system for the application	9F09	2	b	O	-	O	O	-
19	Terminal Capabilities	Indicates the Card data input, CVM, and security capabilities of the terminal	9F33	3	b	M	-	M	O	-
20	Terminal Country Code	Indicates the country of the terminal represented	9F1A	2	n-3	M	-	M	O	-
21	Terminal Type	Indicates the environment of the terminal, its communications capability, and its operational control	9F35	1	n-1	O	-	O	O	-
22	Terminal Verification Results (TVR)	Status of the different functions as seen from the terminal	95	5	b	M	-	M	O	-
23	Transaction Date	Local date that the transaction was authorized	9A	3	n-6, YYMMDD	M	-	M	O	-
24	Transaction Type	Indicates the type of financial transaction represented by the first two digits of the Processing Code	9C	1	n-2	M	-	M	O	-
25	Transaction Currency Code	Indicates the Currency Code of the transaction	5F2A	2	n-3	M	-	M	O	-
26	Unpredictable Number (UN)	Value to provide variability and uniqueness to the generation of a Cryptogram	9F37	4	b	M	-	M	O	-
27	Transaction Sequence Counter (TSC)	Counter maintained by the terminal that is incremented by one for each transaction	9F41	2-4	n, 4-8	O	-	O	O	-
28	Issuer Script Results	Indicates the result of the terminal script processing	9F5B	Var	b	-	-	C	O	Present if scripts were sent by Issuer in original response

Table 54: List of Basic Information (Mandatory) Subfields of Field 55

6.3.40 DE - 56 Customer Related Data

DE - 56 Customer Related Data
Type:	ans…999
Format:	LLLVAR,Binary, TLV
Description:	This field is used by Merchants, Acquirers, and Issuers to support the exchange of Customer Related data. This field uses binary data based on TLV format, and each record is formatted as below. Position Length Description 1 1 Hexadecimal value 2-3 2 Data set length (hexadecimal value of the length of the data set) 4-999 996 Data Data Set ID 01, Account Related Data Data Set 01 - Account Related Data enables Merchants and Acquirers to consistently link transactions initiated with PAN or Payment Tokens. Tag Length Tag Name Description Encoding Condition 01 Variable up to 29 bytes Payment Account Reference (PAR) A unique non-financial reference assigned to a given PAN or Payment Token. LLVAR, an..29 Optional 02 Variable up to 29 bytes PAN Reference Identifier A unique non-financial reference assigned to a given PAN. May be used for non-transaction activity for that PAN.May be used for non-transaction activity for that PAN. LLVAR, an..29 Optional Note:Note: For the data set, each Tag Number and Tag Length within the data set is to be sent in hexadecimal format. However, Tag values are not sent in hexadecimal format.
Echo:	It should be echoed back in response if presents in request.
Validation:	It can be validated as per TLV rules.
Presence:	This field is optional in all messages (01XX, 02XX, 04XX).

6.3.41 DE - 61 Point of Sale (POS) Data

DE - 61 Point of Sale (POS) Data
Type:	ans…13
Format:	LLLVAR
Description:	This field indicates the specific Card information capture conditions that are present at the time a Card Transaction took place at the point of sale. This field is formatted as follows: Position Length Description 1 1 POS Device Attendance Indicator 2 1 Partial Approval Indicator 3 1 POS Terminal Location Indicator 4 1 POS Cardholder Presence Indicator 5 1 POS Card Presence Indicator 6 1 POS Card Capture Capabilities Indicator 7 1 POS Transaction Status Indicator 8 1 POS Transaction Security Indicator 9 1 POS E-commerce Transaction Indicator 10 1 POS Type of Terminal Device 11 1 POS Card Data Terminal Input Capability Indicator 12-13 2 Reserved (zero-filled) Digit 1 Code: POS Device Attendance Indicator This is a 1-digit code indicating whether the POS Device is attended by the Merchant’s representative or operated by the Cardholder. Digit 1 Code: : POS Device Attendance Indicator Definition (Digit - 1) 0 Attended terminal (POS Device) 1 Unattended terminal (POS Device) 2 No terminal (POS Device) used 9 Unknown Digit 2 Code: Partial Approval Indicator This is a 1-digit code indicating whether the Merchant, Merchant Processor, ATM, etc., supports Partial Authorization Approvals. Note: A positive Authorization Response must be provided for the full amount of the merchandise portion of a Card Transaction prior to approving the Cash at Checkout portion of the Card Transaction. Digit 2 Code: Partial Approval Indicator Definition (Digit - 2) 0 Partial Approval Not Supported 1 Partial Approval Supported: Merchandise can be partially approved Cash at Checkout can be partially approved 2 Partial Approval Supported: Merchandise can be partially approved Cash at Checkout must be fully approved or declined 3 Partial Approval Supported: Merchandise must be fully approved or declined Cash at Checkout can be partially approved 4 Partial Approval Supported: Merchandise must be fully approved or declined Cash at Checkout must be fully approved or declined Digit 3 Code: POS Terminal Location Indicator This is a 1-digit code indicating the location of terminal (POS Device). Digit 3 Code:POS Terminal Location Indicator Definition (Digit - 3) 0 On premises of Merchant facility 1 Off premises of Merchant facility (Merchant terminal-remote location) 2 On premises of Cardholder (home PC) 3 No terminal (POS Device) used (voice/ARU authorization) 9 Unknown Digit 4 Code: POS Cardholder Presence Indicator This is a 1-digit or letter code indicating whether the Cardholder is present at the point of sale, and explains the condition if the Cardholder is not present. Digit 4 Code:POS Cardholder Presence Indicator Definition (Digit - 4) 0 Cardholder present 1 Cardholder not present, unspecified 2 Cardholder not present, mail/facsimile order 3 Cardholder not present, telephone/ARU order 4 Cardholder not present, standing order/Merchant-Initiated Transactions (i.e., Recurring Payments) 5 Electronic Order 9 Unknown Digit 5 Code: POS Card Presence Indicator This is a 1-digit code indicating whether the Card is present at the point of sale. Digit 5 Code: POS Card Presence Indicator Definition (Digit - 5) 0 Card Present 1 Card Not Present 9 Unknown Digit 6 Code: POS Card Capture Capabilities Indicator This is a 1-digit code indicating whether the terminal (POS Device) has Card capture capabilities. Digit 6 Code:POS Card Capture Capabilities Indicator Definition (Digit - 6) 0 Terminal (POS Device)/operator has no Card capture capability 1 Terminal (POS Device)/operator has Card capture capability 9 Unknown Digit 7 Code: POS Transaction Status Indicator When the final Card Sale amount is not known at time of the Authorization Request, such as for Automated Fuel Dispenser, Incremental Authorization, and restaurant and transit fare Card Transactions, a 1-digit or letter code indicating the purpose or status of the Request. 0100 Authorization Message Requests with the pre-Authorization indicator is used in Position 7: POS Transaction Status Indicator. Usage of “A, D, E, I, N, P, R, S, T, and U” is mandatory for Merchant-Initiated Transactions (MIT) using a Payment Token, and recommended for MIT transactions using a PAN. Usage of “V” is recommended for Issuer Installment Payments using a Payment Token or a PAN. Digit 7 Code: POS Transaction Status Indicator Definition (Digit - 7) 0 Partial Approval Not Supported Digit 8 Code: POS Transaction Security Indicator This is a 1-digit code indicating the Card Acceptor’s security assessment of the Card presenter. Digit 8 Code: POS Transaction Security Indicator Definition (Digit - 8) 0 No security concern 1 Suspected fraud (Merchant suspicious) 2 ID verified 9 Unknown Digit 9 Code: POS E-commerce Transaction Indicator This is a 1-digit code indicating the POS transaction type for the 0100 Authorization Request. Merchants and Acquirers must populate this field with ZERO (0) if the POS transaction type is unknown. Digit 9 Code: POS E-commerce Transaction Indicator Definition (Digit - 9) 0 Unknown/Unspecified 1 Transaction is not an e-commerce transaction 4 In-App Authentication 5 Card Transaction is a secure e-commerce transaction (Cardholder authenticated) 6 Merchant attempted to authenticate the Cardholder information, but was not able to complete authentication 7 E-commerce Card Transaction with data protection but not using Cardholder authentication 8 E-commerce Card Transaction without data protection 9 Reserved B Buy Online Pickup In Store (BOPIS) Digit 10 Code: POS Type of Terminal Device This is a 1-digit code indicating the type of terminal used during the transaction. Digit 10 Code: POS Type of Terminal Device Definition (Digit - 10) M Mobile POS 0 Unspecified 9 Mobile POS Digit 11 Code: POS Card Data Terminal Input Capability Indicator This is a 1-digit code indicating the ability of the terminal (POS Device) used by the Merchant to electronically capture Card Transaction Data. This position should reflect the highest level of capability of the POS Device: if the terminal is capable of reading Chip Cards and magnetic stripes, the POS Device should be identified as an integrated circuit card reader (using value 5). Digit 11 Code: POS Card Data Terminal Input Capability Indicator Definition (Digit - 11) 0 Unspecified 1 No terminal (POS Device) used (voice/ARU authorization) 2 Magnetic stripe reader 3 Bar Code/Payment Code 4 Optical Character Recognition 5 Integrated Circuit Card Reader 6 Key entry only (manual) 7 Magnetic stripe reader and key entry C Radio Frequency Identification (RFID) – Chip H Hybrid – Integrated Circuit Card Reader & contactless capabilities R Radio Frequency Identification (RFID) – Magnetic Stripe S Secure Electronic Transaction (SET) with certificate T SET without certificate U Channel-encrypted Electronic Commerce Transaction (SSL) V Non-secure Electronic Commerce Transaction Digit 12-13 Code: Reserved (zero-filled) Reserved and zero-filled. Digit 12-13 Code: Reserved (zero-filled) Definition (Digit - 12-13) 00 Zero-filled
Echo:	It should not be echoed back in response.
Validation:	This field should be in the format as described above.
Presence:	This field requires in all transactions.

6.3.42 DE - 63 Account Verification Service (AVS)

DE - 63 Account Verification Service (AVS)
Type:	ans…999
Format:	LLLVAR
Description:	This field is self-defined field for cardholder verification purpose. The presence of this field indicates the Address Verification Service should be used to perform Address Verification for the Card Transaction. This field is mandatory if Positions 1-2 of Field 3 (Processing Code) contains a value of 18 (Card Account Verification) and the Merchant elects to validate the identity of the Cardholder via the Cardholder's billing address. Seq. Definition Attribute Description 1 ID Verification Indicator n-1 0 – Not Present 1 - Present 2 Name Verification Indicator n-1 0 – Not Present 1 - Present 3 Mobile Verification Indicator n-1 0 – Not Present 1 - Present 4 OTP Verification Indicator n-1 0 – Not Present 1 - Present 5 CVV Verification Indicator n-1 0 – Not Present 1 - Present 6 ID Type n-2 01 – Nationality 02 – National ID 03 – Driving License 04 – Voter Card 99 – Other ID Card 7 ID Number n..20 LLVAR Filled with the serial number of the corresponding ID type. Note: If the serial number is less than 20 bytes, spaces will be padded to the right. 8 Name ans..50 LLVAR Name is a field with variable length. 9 Mobile n..15 LLVAR Mobile phone number is a field with variable length. 10 OTP ans..40 LLVAR The first 20 bytes used to store the OTP key value, which is submitted by the Acquirer, and the last 20 bytes used to store the OTP. 11 CVN2 n-3 Acquirer need to fill CVN2 for the Issuer to conduct CVN2 verification.
Echo:	It is assigned by an Acquirer, echo is not required
Validation:	This field should be of numeric 3 byte length followed by up to 999 bytes alphanumeric and symbol characters.
Presence:	This field requires in all account verification transaction messages.

6.3.43 DE - 70 Network Management Information

DE - 70 Network Management Information
Type:	n – 3
Format:	Fixed
Description:	This field is required in all 08xx messages. It indicates the type of network request to be processed. The following table lists the available codes:
Available Codes:	Value Description 001 Logon 002 Logoff 012 Logoff due to Debit Cap Limit Exceed 201 Cutoff 301 Echo Test 161 Member Bank Initiated Key Exchange Request 162 NCHL Initiated Key Exchange Request
Echo:	It should be echoed back in response.
Validation:	This field is a numeric zero filled field which is right justified.
Presence:	This field requires in all network messages (08XX).

6.3.44 DE - 90 Original Data Element

DE - 90 Original Data Element
Type:	ans…13
Format:	LLLVAR
Description:	This field indicates the specific Card information capture conditions that are present at the time a Card Transaction took place at the point of sale. This field is formatted as follows:
Position Length Description 1 – 4 4 Original Message Type Identifier (0100, 0120, 0200) 5 – 10 6 Original Systems Trace Audit Number (STAN) from Field 11 11 - 16 6 Original Local Transaction Time from Field 12 17 - 20 4 Original Local Transaction Date from Field 13 21 – 31 11 Original Acquiring Institution Identification Code from Field 32, right justified, zero-filled 32 - 42 11 Original Forwarding Institution Identification Code from Field 33, right justified, zero-filled
Echo:	If present, it should be echoed back in response.
Validation:	Original data elements should be of this format as described. If DE 90 is absent in request / not matching with the original transaction then the transaction will not be sent to the issuer.
Presence:	This field requires in all reversal messages (04XX) and conditional in some financial messages such as refund (01XX / 02XX).

6.3.45 DE - 91 File Update Code

DE - 91 File Update Code
Type:	n – 3
Format:	Fixed
Description:	This field is required in file update messages either to add a record, delete a record, change an existing record, replace a record, or retrieve a copy of the existing record. The following table lists the field structure:
Function Description 301 Add Record 302 Update Record 303 Delete Record 304 Replace Record 305 Inquire Record
Echo:	If present, it should be echoed back in response.
Validation:	Field data shall be provided as per the given format.
Presence:	This field requires in file update messages (0302/0312).

6.3.46 DE - 95 Replacement Amounts

DE - 95 Replacement Amounts
Type:	an – 42
Format:	Fixed
Description:	This field is required in reversal messages 04xx where partial amount was dispensed. The following table lists the field structure:
Position Length Description 1 – 12 n - 12 Actual Amount, Transaction 13 – 24 n - 12 Actual Amount, Settlement 25 a - 1 Actual Transaction Fee Sign 26 – 33 n - 8 Actual Transaction Fee 34 a - 1 Actual Settlement Fee Sign 35 - 42 n - 8 Actual Settlement Fee
Echo:	If present, it should be echoed back in response.
Validation:	For an ATM transaction if DE 95 is greater than DE 4 then the transaction should get rejected.
Presence:	This field requires in partial reversal messages (04XX).
Note:	Partial reversal is not supported/recommended from ATM terminals.

6.3.47 DE - 102 Account Identification 1

DE - 102 Account Identification 1
Type:	ans..20
Format:	LLVAR
Description:	This field is used to contain “from account number” of the cardholder to debit an authorized amount. Alternatively, this field can be used to return a “from account number” by the issuer host after authorization. In Card to Card fund transfer, for debit transaction, issuer Bank must send the “From Account Number” from which will be debited for transfer amount. i.e. the cardholder account number.
Echo:	It is optional to echoed back in response.
Validation:	This field should be of numeric 2 byte length followed by up to 20 bytes alphanumeric and symbol characters (From Account Number).
Presence:	This field requires in all transaction messages.

6.3.48 DE - 103 Account Identification 2

DE - 103 Account Identification 2
Type:	ans..20
Format:	LLVAR
Description:	This field is used to contain “to account number” of the beneficiary to credit an authorized amount. Alternatively, this field can be used to return a “to account number” by the beneficiary / acquirer host after credit. In Card to Card fund transfer, for credit transaction, Acquirer/beneficiary Bank must send the “To Card Number/ To Account Number” which is to be credited for the transfer amount.
Echo:	It is optional to echoed back in response.
Validation:	This field should be of numeric 2 byte length followed by up to 20 bytes alphanumeric and symbol characters (To Card Number/ To Account Number).
Presence:	This field requires in all FT/ Credit transaction messages.

6.3.49 DE - 104 OCT Data

DE - 104 OCT Data
Type:	ans..999
Format:	LLVAR,TLV Format
Description:	Tag Presence Length Terminology Description 001 C ans-30 Bill number Invoice number or bill number 002 C ans-15 Mobile number Mobile number for top-up or bill payment 003 C ans-30 Store ID A distinctive number associated to a Store 004 C ans-30 Loyalty number Loyalty card number as provided by store or airline 005 C ans-30 Reference ID Any value as defined by merchant or acquirer in order to identify the transaction 006 C ans-30 Consumer ID A subscriber ID given by the merchant for subscription services 007 C ans-100 Purpose Remarks for the Purchase 008 M n-1 Remitter instrument type This will contain the instrument type by which the Debit was processed. 1- Card 2- QR 009 M ans-50 Remitter instrument ID This will contain the ID of the Instrument used for Debit (Card Number, Account Number, VPA ID etc. ...) 010 C ans-50 Remitter Name This field will contain remitter name, if remitter name is greater than 50 characters, use first 50 characters 011 C ans-20 Merchant Account Number Merchant Bank Account Number 012 C n-2 Payload Format Indicator Defines the version release, the first version should be numbered “01”. 013 C n-2 Point of initiation method 1st character: Method of data presentation by Merchant 1 = QR 2 = NFC 3-9 = Reserved for future use 2nd character: Static/ Dynamic indication 1 = static 2 = dynamic 3-9 = Reserved for future use 014 C n-2 Tip or Convenience fee indicator 01: Indicates Consumer should be prompted to enter tip 02: Indicates that merchant would mandatorily charge a flat convenience fee 03: Indicates that merchant would charge a percentage convenience fee 015 C n-12 Tip or Convenience fee – amount Tip OR Convenience fee amount 016 C ans-5 Convenience fee percentage The Convenience Fee Percentage is specified as whole integers between 000.00 (for 0%) to 100 (100.00%). E.g. “11.95” Note: 0 or 100 is not a valid value. 017-025 C ans-100 Reserved Reserved for NCHL
Echo:	If present, it should be echoed back in response.
Validation:	Field data shall be provided as per given format. Tag length is always represented in 3 bytes.
Presence:	This remains same for a transaction. For all OCT transactions this field is mandatory. For all other transactions this field shall not be present.

6.3.50 DE - 105 Token Data

DE - 105 Token Data
Type:	ans..999
Format:	LLVAR,TLV Format
Description:	Tag Presence Length Terminology Description 001 M an-19 Token ID Token Value corresponding to the PAN 002 M n-4 Token Expiration Date Expiry Date for the Token. The date is in YYMM format, where YY = year (00–99) and MM = month (01–12). 003 C ans-36 Token Reference ID Reference ID corresponding to the Token. Optional for Token Reference based E-com transaction. Mandatory in other scenarios. 004 C n-10 Wallet ID ID allocated for the Particular Wallet. Optional for wallet-based E-com transaction. Mandatory in other scenarios. 005 M an-2 Token Type EC - ECOM/COF (e-commerce/ card on file) SE - SE (secure element) HC - CBP (cloud-based payment) 006 C an-1 Token Status A - Active for payment I - Inactive for payment (not yet active) S - Temporarily suspended for payments D - Permanently deactivated for payments 007 C ans-29 Payment Account Reference (PAR) This will have data if provided by the issuer. The value needs to be Populated from Tag 9F24 008 C ans-11 Token Requestor ID Contains the assigned Token Requestor ID 009 M an-2 TSP Validation Result 01 –Token / Cryptogram Validation Successful 02 – Token / Cryptogram Validation Failed 03 – Token Validation Successful 04 – Token Validation Failed 010 C n-2 Device Type Device from which the transaction was initiated. 01 - Mobile phone 02 – Tablet 03 – Wearable 99 - Unknown 011 C ans-48 Device ID Contains Device ID 012 C n-15 Device Number This tag contains the full or partial phone number when available. 013 C n-2 Number of Active Tokens Number of Tokens Currently Active for this PAN 014 C n-2 Number of Inactive Tokens Number of Token currently Inactive for this PAN 015 C n-2 Number of Suspended Tokens Number of Token currently Suspended for this PAN 016 C n-2 User Account Score A score between 1 and 5 indicating how trustworthy the device user's account is. Five is most trusted. A value of 0 (zero) means that the account was not checked by wallet or wallet owner. 017 C n-2 Device Score A score between 1 and 5 indicating how trustworthy the device is. Five is most trusted. A value of 0 (zero) means that the account was not checked by wallet or wallet owner. 018 O ans-100 Card Holder Address Address of the Card Holder 019 O ans-9 Device Location Latitude and longitude coordinates of device location 020 O ans-45 Device IP Cardholder’s device IP address 021 O ans-25 Card Holder Name Name of the Card Holder 022 C n-2 Token Advice Reason 01 - Provision complete notification. 02 - State of token changed on device upon lifecycle management request from Issuer. 03 - State of token changed on vault upon lifecycle management request. 04 - State of token changed on vault upon lifecycle management request from TSP CSP. 05 - Meta data changed 023 C n-2 Previous Token State Possible Values are: 01-LINKED 02-ACTIVE 03-SUSPENDED 04-UNLINKED 024 C n-2 New Token State Possible Values are: 01-LINKED 02-ACTIVE 03-SUSPENDED 04-UNLINKED 025 C n-16 SI registration ID When there is a token registration/replenishment/cancellation against a SI registration ID 026 C ans-15 Merchant ID ID of the merchant requesting the token. Mandatory for Card on file scenarios 027 C ans-45 Merchant Name Name of the merchant requesting the token. Mandatory for Card on file scenarios 028 C ans-45 TR Name Token requestor name. Mandatory for Card on file scenarios
Echo:	If present, it should be echoed back in response.
Validation:	This remains same for a transaction. Tag length is always represented in 3 bytes. For any Token based transaction this field should be mandatory. For all other transactions this field will not be present. For Token based E-Com/SI/SFA transactions, these fields will be received from the acquirer. Same will be forwarded to the issuer only if the issuer if certified to receive token based fields.
Presence:	This is mandatory for all Token Based transactions.

6.3.51 DE - 106 Cardless Transaction Data

DE - 106 Cardless Transaction Data
Type:	ans..999
Format:	LLVAR,TLV Format
Description:	Tag Presence Length Terminology Description 001 M an-20 Acquirer ATM account/ VPA Account Number/ VPA allocated for the account used by Acquirer for Cardless cash withdrawal transactions. 002 C an-16 TXN ID The transaction ID generated by the Acquirer to confirm on the Debit. 003 M n-10 Mobile Number Customer Mobile Number from which the Debit will happen. 004 M an-10 Verification Code First 4 characters for Bank/ third party channel Code as defined by Nepal Rastra Bank + 6 characters of issuer generated verification code. Note: First 4 characters = “0000”, is assigned for NCHL. 005 M n-4 Bank Code Unique Bank Code of the Acquirer provided by Nepal Rastra Bank. 006 M n-12 RRN The RRN received for Customer Debit 007 M n-12 Transaction Amount Transaction amount of cardless withdrawal. 008 M an-8 Terminal ID Terminal ID of the terminal assigned by acquirer.
Echo:	If present, it should be echoed back in response.
Validation:	This remains same for a transaction. Tag length is always represented in 3 bytes. For any Cardless cash withdrawal transaction this field should be mandatory, for all other transactions this field will not be present.
Presence:	This is mandatory for all Cardless cash withdrawal transaction.

6.3.52 DE - 120 Additional Data 2 (Private Use)

DE - 120 Additional Data 2 (Private Use)
Type:	ans..999
Format:	LLLVAR, TLV Format
Description:	This contains additional data for ATM, POS, e-Commerce and other transactions.
Echo:	If present, it should be echoed back in response.
Validation:	This remains same for a transaction. Tag data length is always represented in 3 bytes.
Presence:	This is optional for all messages.

6.3.52.1 DE – 120, Pin Change Transaction

1. For PIN Change - Request

The PIN change transaction can be initiated from any ATM terminals, and it is also within the scope of this transaction to be initiated from POS terminals managed by banks and their branches providing flexibility to facilitate customers in remote areas.

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	98	PIN Change Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
003	Product Indicator	3	An-3	PNC	Pin Change
004	New PIN Block	16	b-16		New PIN Block
			For example, the field 120 for PIN Change request transaction is as follows: 04800100298002003ATM003003PNC004016A1B2C3D4E5F610F9 047 - Length of the field 120 001 - Tag 1 002 – Length of tag 1 data 98 – Value of Tag 1 (Transaction Type) 002 – Tag 2 003 – Length of tag 2 data ATM – Value of Tag 2 (Channel Indicator) 003 – Tag 3 003 – Length of tag 3 data PNC – Value of Tag 3 (Product Indicator) 004 – Tag 4 016 – Length of tag 4 data A1B2C3D4E5F610F9 – Value of Tag 4 (New PIN Block)

2. For PIN Change - Response

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	98	PIN Change Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
003	Product Indicator	3	An-3	PNC	Pin Change
			For example, the field 120 for PIN Change response transaction is as follows: 02600100298002003ATM003003PNC 025 - Length of the field 120 001 - Tag 1 002 – Length of tag 1 data 98 – Value of Tag 1 (Transaction Type) 002 – Tag 2 003 – Length of tag 2 data ATM – Value of Tag 2 (Channel Indicator) 003 – Tag 3 003 – Length of tag 3 data PNC – Value of Tag 3 (Product Indicator)

6.3.52.2 DE – 120 for ATM Transaction, Mini Statement

1. For Mini Statement - Request

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	38	Mini Statement Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
003	Product Indicator	3	An-3	MST	Mini Statement
005	Number of Mini Statement Records	2	n-10	Number of statement records	Number of statement records for mini statement data is 10.
			For example, the field 120 for Mini Statement request transaction is as follows: 04200100238002003ATM00300210003003MST00500207 033 - Length of the field 120 001 - Tag 1 002 – Length of tag 1 data 38 – Value of Tag 1 (Transaction Type) 002 – Tag 2 003 – Length of tag 2 data ATM – Value of Tag 2 (Channel Indicator) 003 – Tag 3 003 – Length of tag 3 data MST – Value of Tag 3 (Product Indicator) 005 – Tag 5 002 – Length of tag 5 data 07 – Value of Tag 5 (statement for last 7 transactions)

For Mini Statement - Response

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	38	Mini Statement Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
003	Product Indicator	3	An-3	MST	Mini Statement
005	Number of Mini Statement Records	2	n-10	Number of statement records	Number of statement records for mini statement data is 10.
006	Mini Statement Data	297	ans-297	Statement Data	Last 10 transaction data along with final balance.
			The mini statement format consists of 27-character width for each statement, with trailing spaces sent if no additional data exists. A total of 11 rows, comprising 10 rows statements and 1 row account balance, should be transmitted. For all rows, each row (27-characters) shall comprise of below format. Digits Length Description 1-8 8 Date (YYYYMMDD) 9 1 Space character 10-12 3 Channel of the performed transaction 13 1 Space character 14-15 2 Entry (DR/CR for Debit/Credit) 16-27 12 Amount For example, field 120 for 10 mini statement transactions is structured as follows: 33700100238002003ATM003003MST0050021000629720231201 ATM DR00000050000020231202 POS DR00000025000020231203 ATM DR00000100000020231204 ATM DR00000120000020231205 ECM DR00000170000020231206 ATM DR00000070000020231207 ATM DR00000100000020231208 DEP CR00005000000020231209 CHK DR00000900000020231210 IPS CR00000250000020231215 BAL CR000035703487 336 - Length of the field 120 001 - Tag 1 002 – Length of tag 1 data 38 – Value of Tag 1 (Transaction Type) 002 – Tag 2 003 – Length of tag 2 data ATM – Value of Tag 2 (Channel Indicator) 003 – Tag 3 003 – Length of tag 3 data MST – Value of Tag 3 (Product Indicator) 005 – Tag 5 002 – Length of tag 5 data 10 – Value of Tag 5 (Number of Mini Statement Records) 006 – Tag 6 297 – Length of tag 6 data (Mini Statement Data) This tag contains mini statement data of 10 statements and 1 balance containing of 27 characters each. The data is as follows: 20231201 ATM DR000000500000 20231202 POS DR000000250000 20231203 ATM DR000001000000 20231204 ATM DR000001200000 20231205 ECM DR000001700000 20231206 ATM DR000000700000 20231207 ATM DR000001000000 20231208 DEP CR000050000000 20231209 CHK DR000009000000 20231210 IPS CR000002500000 20231215 BAL CR000035703487

6.3.52.3 DE – 120 for ATM Transaction, Card to Card Fund Transfer

Transaction Flow for Card to Card Funds Transfer

1. The Cardholder inserts his card into the ATM.
2. Cardholder enters his card PIN.
3. Cardholder selects card-to-card funds transfer.
4. Cardholder inputs the beneficiary’s card number.
5. After proceeding, the ATM initiates a new fund transfer message.
6. The Acquirer switch forwards fund transfer Debit transaction requests to NCHL.
7. NCHL forwards a Debit transaction request to Issuer.
8. Issuer bank debits the cardholder's account, responds with success to NCHL.
9. NCHL responds with Debit success to Acquirer.
10. The Acquirer switch then forwards fund transfer Credit transaction requests to NCHL.
11. NCHL forwards a Credit transaction request to Beneficiary.
12. Beneficiary bank credits the receiver's account, responds with success to NCHL.
13. NCHL responds to the acquirer switch with a successful response.
14. Acquirer switch responds to the ATM with a successful response.
15. Cardholder receives a receipt at the ATM confirming the successful fund transfer.

In the outlined card-to-card fund transfer scenario as above, three essential processes must be meticulously managed to ensure the seamless completion of the transaction. Firstly, the cardholder initiates the transfer by inserting their card, entering the recipient's details, and authorizing the transaction at the ATM. Secondly, the financial transaction undergoes a debit leg, involving the issuer bank. Thirdly, the financial transaction undergoes a credit leg, involving the beneficiary bank. Finally, the successful completion of the fund transfer is communicated back to the cardholder through the ATM, providing a comprehensive and transparent confirmation of the transaction.

1. For Fund Transfer – Debit Leg fund transfer message

a)Request

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	40	Fund Transfer Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
003	Product Indicator	3	an-3	FTD	Fund Transfer Debit
007	Sender PAN	LLVAR	n..19		Card number of the sender
008	Beneficiary PAN	LLVAR	n..19		Card number of the beneficiary

b)Response

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	40	Fund Transfer Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
003	Product Indicator	3	an-3	FTD	Fund Transfer Debit
007	Sender PAN	LLVAR	n..19		Card number of the sender
008	Beneficiary PAN	LLVAR	n..19		Card number of the beneficiary

2. For Fund Transfer – Credit Leg fund transfer message

a)Request

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	29	Fund Transfer Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
003	Product Indicator	3	an-3	FTC	Fund Transfer Credit
007	Sender PAN	LLVAR	n..19		Card number of the sender
008	Beneficiary PAN	LLVAR	n..19		Card number of the beneficiary

b)Response

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	29	Fund Transfer Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
003	Product Indicator	3	an-3	FTC	Fund Transfer Credit
007	Sender PAN	LLVAR	n..19		Card number of the sender
008	Beneficiary PAN	LLVAR	n..19		Card number of the beneficiary

6.3.52.4 DE – 120 for ATM Transaction, Cheque Book Request

1. Cheque Book Request

1. Cheque Book Request
Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	36	Cheque Book Request Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
003	Product Indicator	3	an-3	CQB	Cheque Book Request
009	No of Cheque	2	n-2	-	Number of pages of the cheque

2. Response to Cheque Book Request

2. Response to Cheque Book Request
Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	36	Cheque Book Request Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
003	Product Indicator	3	an-3	CQB	Cheque Book Request
009	No of Cheque	2	n-2	-	Number of pages of the cheque

6.3.52.5 DE – 120 for ATM Transaction, Statement Request

1. Statement Request

1.Statement Request
Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	37	Statement Request Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
003	Product Indicator	3	an-3	STM	Statement Request
010	From date	8	yyyymmdd	-	Statement date starting from

2. Response to Statement Request

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	37	Statement Request Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
003	Product Indicator	3	an-3	STM	Statement Request
010	From date	8	yyyymmdd	-	Statement date starting from

6.3.52.6 DE – 120 for Utility Payment (Bill Payment)

1. Bill Payment Request

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	90	Utility Payment Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM POS ECM OTH	ATM based transaction POS based transaction Ecom based transaction Other Channels
003	Product Indicator	3	an-3	BIL FEE INT DTH RNT TOP NEA WAT BRO OTH	Bill Payment Fee Payment Internet Bill Payments Direct To Home and Cable TV House Rent Payment Telecom Mobile Top-up NEA Bill Payment Khanepani Bill Payment Broker or Capital Payments Others
011	Bill Number/ In-voice Number	100	ans…40	…	Bill Payment Transaction Unique Reference Number.
012	Payer Details	100	ans…40	…	Bill Payment Transaction Payer Details
013	Payee Details	100	ans…40	…	The Ultimate Beneficiary of Bill Payment Transaction.
014	Consumer ID	35	ans…35	…	Customer Identification Number
015	End to End Id	35	ans…35	…	Payment End to End Id for reconciliation
099	Purpose	100	ans…50	…	Remarks for the Purchase

2. Response to Bill Payment Request

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	90	Utility Payment Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM - ATM based transaction POS - POS based transaction ECM - Ecom based transaction OTH - Other Channels	ATM based transaction POS based transaction Ecom based transaction Other Channels
003	Product Indicator	3	an-3	BIL - Bill Payment FEE - Fee Payment INT - Internet Bill Payments DTH - Direct To Home and Cable TV RNT - House Rent Payment TOP - Telecom Mobile Top-up NEA - NEA Bill Payment WAT - Khanepani Bill Payment BRO - Broker or Capital Payments OTH - Others	Bill Payment Fee Payment Internet Bill Payments Direct To Home and Cable TV House Rent Payment Telecom Mobile Top-up NEA Bill Payment Khanepani Bill Payment Broker or Capital Payments Others

6.3.52.7 DE – 120 for Utility Payment (Government Revenue Payment)

1. Government Revenue Payment Request

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	90	Utility Payment Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM POS ECM OTH	ATM based transaction POS based transaction Ecom based transaction Others
003	Product Indicator	3	an-3	FTX PTX LTX	Federal Government Revenue Payment Provincial Government Revenue Payment Local Government Revenue Payment
012	Payer Details	100	ans ...40	...	Payers Details
015	End to End Id	35	ans...35	...	Payment End to End Id for reconciliation
016	Category Purpose	4	ans-4	...	Category of the payment type defined by NCHL
017	EBPP Number	100	ans...35	...	Electronic Bill Presentment Payment generated from GoN Portal
018	rcAgency Code	100	ans...35	...	Revenue collecting agency/office code and name
019	rcAgency Name	100	ans...50	...	Revenue collecting agency/office code and name
020	Fiscal Year	4	yyyy	...	Fiscal Year
021	Tax Payer Id	35	an...35	...	Tax Payer Id
022	Revenue Collecting Bank	35	ans...35	...	Revenue collecting Bank
099	Purpose	100	ans...50	...	Remarks for the Purchase

2. Response to Government Revenue Payment Request

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	90	Utility Payment Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
				POS	POS based transaction
				ECM	Ecom based transaction
				OTH	Others
003	Product Indicator	3	an-3	FTX	Federal Government Revenue Payment
				PTX	Provincial Government Revenue Payment
				LTX	Local Government Revenue Payment
012	Payer Details	100	ans...40	…	Payers Details
015	End to End Id	35	ans...35	…	Payment End to End Id for reconciliation
016	Category Purpose	4	ans-4	…	Category of the payment type defined by NCHL
017	EBPP Number	100	ans...35	…	Electronic Bill Presentment Payment generated from GoN Portal
018	rcAgency Code	100	ans...35	…	Revenue collecting agency/office code and name
019	rcAgency Name	100	ans...50	…	Revenue collecting agency/office code and name
020	Fiscal Year	4	yyyy	…	Fiscal Year
021	Tax Payer Id	35	an…35	…	Tax Payer Id
022	Revenue Collecting Bank	35	ans...35	…	Revenue collecting Bank
099	Purpose	100	ans…50	…	Remarks for the Purchase

6.3.52.8 DE – 120 for Utility Payment (Recurring Payment)

1. Recurring Payment Request

Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	90	Utility Payment Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM	ATM based transaction
				POS	POS based transaction
				ECM	Ecom based transaction
				OTH	Others
003	Product Indicator	3	an-3	INU	Insurance Premium Payment
				CCP	Credit Card Bill Payment
				SIP	Capital Mutual Fund Payments
				FEE	Fees Payment
				BIL	Bill Payment
				EMI	EMI/Loan Payment
				OTH	Others
014	Consumer ID	35	ans…35	…	A Customer ID given for subscription services
015	End to End Id	35	ans...35	…	Payment End to End Id for reconciliation
023	Participant ID	35	ans…35	…	Unique ID of the Third Party System
024	Policy Number or Debit Note	35	ans…35	…	Policy Number or Debit Note
025	Credit Card Number	19	n..19	…	Credit Card Number
026	Recurring Term	3	n-3	…	Payment term of the particular recurring payment
027	Payment (Beneficiary) entity	35	ans…35	…	Beneficiary to receive the payment
028	Reference ID	35	ans..35	…	Any value as defined by merchant or acquirer in order to identify the transaction
099	Purpose	100	ans…50	…	Remarks for the Purchase

2. Response to Recurring Payment Request

2. Response to Recurring Payment Request
Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	90	Utility Payment Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM POS ECM OTH	ATM based transaction POS based transaction Ecom based transaction Others
003	Product Indicator	3	an-3	INU CCP SIP FEE BIL EMI OTH	Insurance Premium Payment Credit Card Bill Payment Capital Mutual Fund Payments Fees Payment Bill Payment EMI/Loan Payment Others
014	Consumer ID	35	ans…35	...	A Customer ID given for subscription services
015	End to End Id	35	ans...35	...	Payment End to End Id for reconciliation
023	Participant ID	35	ans…35	...	Unique ID of the Third Party System
024	Policy Number or Debit Note	35	ans…35	...	Policy Number or Debit Note
025	Credit Card Number	19	n..19	...	Credit Card Number
026	Recurring Term	3	n-3	...	Payment term of the particular recurring payment
027	Payment (Beneficiary) entity	35	ans…35	...	Beneficiary to receive the payment
028	Reference ID	35	ans…35	...	Any value as defined by merchant or acquirer in order to identify the transaction
099	Purpose	100	ans…50	...	Remarks for the Purchase

6.3.52.9 DE – 120 for Utility Payment (Insurance Payment)

1. Insurance Payment Request

Insurance Payment Request
Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	90	Utility Payment Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM POS ECM OTH	ATM based transaction POS based transaction Ecom based transaction Others
003	Product Indicator	3	an-3	INU	Insurance Premium Payment
024	Policy Number	20	ans…35	…	Insurance Policy Number
027	Payment (Beneficiary) entity	35	ans…35	…	Beneficiary to receive the payment
029	Consumer Name	35	ans…35	…	Consumer Name
030	Date of Birth	8	yyyymmdd	…	Date of birth
031	Policy Amount	12	n-12	…	Total Amount with last 2 as decimal
032	Premium Amount	12	n-12	…	Premium Amount with last 2 as decimals
033	Policy Period	2	n-2	…	No of years of the policy
099	Purpose	100	ans…50	…	Remarks or description

2. Response to Insurance Request

Response to Insurance Request
Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	90	Utility Payment Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM POS ECM OTH	ATM based transaction POS based transaction Ecom based transaction Others
003	Product Indicator	3	an-3	INU	Insurance Premium Payment
024	Policy Number	20	ans…35	…	Insurance Policy Number
027	Payment (Beneficiary) entity	35	ans…35	…	Beneficiary to receive the payment
029	Consumer Name	35	ans…35	…	Consumer Name
030	Date of Birth	8	yyyymmdd	…	Date of birth
031	Policy Amount	12	n-12	…	Total Amount with last 2 as decimal
032	Premium Amount	12	n-12	…	Premium Amount with last 2 as decimals
033	Policy Period	2	n-2	…	No of years of the policy
099	Purpose	100	ans…50	…	Remarks or description

6.3.52.10 DE – 120 for Utility Payment (EMI Payment)

1. EMI Payment Request

EMI Payment Request
Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	90	Utility Payment Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM POS ECM OTH	ATM based transaction POS based transaction Ecom based transaction Others
003	Product Indicator	3	an-3	EMI	EMI Payment
027	Payment (Beneficiary) entity	35	ans…35	…	Beneficiary to receive the payment
034	Total Amount	12	n-12	…	Total Amount with last 2 as decimal
035	EMI Amount	12	n-12	…	EMI Amount with last 2 as decimals
036	No of Instalment	3	n-3	…	No of payment Instalment
099	Purpose	100	ans…50	…	Remarks or description

2. Response to EMI Request

Response to EMI Request
Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	90	Utility Payment Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM POS ECM OTH	ATM based transaction POS based transaction Ecom based transaction Others
003	Product Indicator	3	an-3	EMI	EMI Payment
027	Payment (Beneficiary) entity	35	ans…35	…	Beneficiary to receive the payment
034	Total Amount	12	n-12	…	Total Amount with last 2 as decimal
035	EMI Amount	12	n-12	…	EMI Amount with last 2 as decimals
036	No of Instalment	3	n-3	…	No of payment Instalment
099	Purpose	100	ans…50	…	Remarks or description

6.3.52.11 DE – 120 for Utility Payment (Tax Refund)

1. Tax Refund Request

Tax Refund Request
Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	90	Utility Payment Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM POS ECM OTH	ATM based transaction POS based transaction Ecom based transaction Others
003	Product Indicator	3	an-3	TXR	VAT Refund Transaction
014	Consumer ID	35	ans…35	…	Customer Identification Number
015	End to End Id	35	ans…35	…	Payment End to End Id for reconciliation
037	Seller PAN Number	20	an-20	…	Seller Business PAN Number
038	Invoice Date	8	yyyymmdd	…	Bill Invoice Date
039	Consumer Additional Information	100	ans…50	…	Customer Additional Information
040	Original Txn ID	35	ans…35	…	Original Transaction Id
041	Tax Amount	12	n-12	…	Amount including 2 decimal digits
099	Purpose	100	ans…50	…	Remarks or description

2. Response to Tax Refund Request

Response to Tax Refund Request
Tag	Description	Length	Format	Value	Remarks
001	Transaction Type	2	an-2	90	Utility Payment Processing Code (First two characters of DE – 3)
002	Channel Indicator	3	an-3	ATM POS ECM OTH	ATM based transaction POS based transaction Ecom based transaction Others
003	Product Indicator	3	an-3	TXR	VAT Refund Transaction
014	Consumer ID	35	ans…35	…	Customer Identification Number
015	End to End Id	35	ans…35	…	Payment End to End Id for reconciliation
037	Seller PAN Number	20	an-20	…	Seller Business PAN Number
038	Invoice Date	8	yyyymmdd	…	Bill Invoice Date
039	Consumer Additional Information	100	ans…50	…	Customer Additional Information
040	Original Txn ID	35	ans…35	…	Original Transaction Id
041	Tax Amount	12	n-12	…	Amount including 2 decimal digits
099	Purpose	100	ans…50	…	Remarks or description

6.3.53 DE - 121 Additional Data 3 (Advice Reason Code)

DE – 121 Additional Data 3 (Advice Reason Code)
Type	ans..999
Format	LLLVAR
Description	This field gives the reason for which a STIP advice is sent.
Useful values	1001 – Issuer Signed off 1002 – Issuer Time out / not responding
Echo	It should be echoed back in response, if present in the request.
Validation	This field contains a 3-byte length field which is zero-filled and right-justified, followed by up to 999 alphanumeric and symbol characters. The total length of this field cannot exceed 1002 bytes.
Presence	This field is conditional and should be present for all STIP-based transactions.

6.3.54 DE - 122 Additional Data 4 (Private Use)

DE – 122 Additional Data 4 (Private Use)
Type	ans..999
Format	LLLVAR
Description	This field contains private data associated with NCHL messages.
Echo	It should be echoed back in response, if present in the request.
Validation	This field contains a 3-byte length field which is zero-filled and right-justified, followed by up to 999 alphanumeric and symbol characters. The total length of this field cannot exceed 1002 bytes.
Presence	This field is optional in all transaction messages.

6.3.55 DE - 123 Additional Data 5 (Private Use)

DE – 123 Additional Data 5 (Private Use)
Type	ans..999
Format	LLLVAR
Description	This field contains private data associated with NCHL messages.
Echo	It should be echoed back in response, if present in the request.
Validation	This field contains a 3-byte length field which is zero-filled and right-justified, followed by up to 999 alphanumeric and symbol characters. The total length of this field cannot exceed 1002 bytes.
Presence	This field is optional in all transaction messages.

6.3.56 DE - 124 Additional Data 6 (File Action Code)

DE - 124 Additional Data 6 (File Action Code)
Type:	ans..999
Format:	LLVAR
Description:	This field is required in file update response messages of add a record, delete a record, change an existing record, and replace a record. The following table lists the field structure: Action Code Description 300 Ok 301 Unable to locate record on file 302 Duplicate, old record replaced 303 File locked out 304 Format error
Echo:	If present, it should be echoed back in response.
Validation:	Field data shall be provided as per given format.
Presence:	This field requires in file update response messages (0312).

6.3.57 DE - 125 Additional Data 7 (File Data Record)

DE - 104 OCT Data
Type:	ans..999
Format:	LLVAR
Description:	This field contains file update data associated with file data updates and inquiries. The contents of field 125 are tag based to identify the individual element within the data field. The tag based value is formatted using the “tag-length-value (TLV)” encoding procedure. Tag Presence Length Description Values 001 Mandatory an-2 Instrument Type Function Description NP NepalPay Card DS Discover Card VS VISA Card MC Master Card CU China UnionPay Card MT Maestro Card 002 Mandatory an-2 Card Status Function Description 00 Card issued, not active 01 Active 02 Card lost (blocked), keep card 03 Card stolen (blocked), keep card 04 Blocked by PRM, return card 08 Blocked by Switch, return card 09 Blocked by Issuer, return card 003 Conditional an-12 PVV (PIN Offset) Example: 1234FFFFFFFF It is left filled with ‘F’, tag 27 is mandatory for this. 006 Conditional n-6 Expiry Date Value Description YYYY Year MM Month 009 Conditional an-2 Number of Accounts The total number of accounts associated with the card 010 Conditional Ans…20 Account Number Should match field format received in balance updates. 011 Conditional an-2 Card Status Value Description 00 Default Account 10 Saving Account 20 Current Account 30 Credit Account 012 Conditional an-2 Account Status Value Description 00 Open 01 Dormant 02 Blocked 03 Closed 015 Conditional ans-10 Account Description 022 Conditional n-2 Default Primary Account Type Value Description 00 Default Account 10 Saving Account 20 Current Account 30 Credit Account 027 Conditional n-12 PIN Change Date The date, in YYMMDDhhmmss format, the PIN was last changed. 030 Conditional ans-154 Daily Amount Limit Profile Position Length Value 1 - 2 2 No of Amount Limit Profile 3 - 9 7 NPRATMD (=Domestic ATM Daily Limit) 10 - 21 12 Amount Limit 22 - 28 7 INRATMD (=India ATM Daily Limit) 29 - 40 12 Amount Limit 41 - 47 7 BTNATMD (=Bhutan ATM Daily Limit) 48 - 59 12 Amount Limit 60 - 66 7 USDATMD (=International ATM Daily Limit) 67 - 78 12 Amount Limit 79 - 85 7 NPRPOSD (=Domestic POS Daily Limit) 86 - 97 12 Amount Limit 98 - 104 7 INRPOSD (=India POS Daily Limit) 105 - 116 12 Amount Limit 117 - 123 7 BTNPOSD (=Bhutan POS Daily Limit) 124 - 135 12 Amount Limit 136 - 142 7 USDPOSD (=International POS Daily Limit) 143 - 154 12 Amount Limit 031 Conditional ans-82 Daily Count Limit Profile Position Length Value 1 - 2 2 No of Count Limit Profile 3 - 9 7 NPRATMD (=Domestic ATM Daily Limit) 10 - 12 3 Count Limit 13 - 19 7 INRATMD (=India ATM Daily Limit) 20 - 22 3 Count Limit 23 - 29 7 BTNATMD (=Bhutan ATM Daily Limit) 30 - 32 3 Count Limit 33 - 39 7 USDATMD (=International ATM Daily Limit) 40 - 42 3 Count Limit 43 - 49 7 NPRPOSD (=Domestic POS Daily Limit) 50 - 52 3 Count Limit 53 - 59 7 INRPOSD (=India POS Daily Limit) 60 - 62 3 Count Limit 63 - 69 7 BTNPOSD (=Bhutan POS Daily Limit) 70 - 72 3 Count Limit 73 - 79 7 USDPOSD (=International POS Daily Limit) 80 - 82 3 Count Limit
Echo:	The information should not be echoed back in the response.
Validation:	This field contains a 3-byte length field which is zero filled and right justified, followed by up to 999 alphanumeric characters. The total length of this field cannot exceed 1002 bytes. Each tag is required to have a length of 3 bytes, and the data must be populated in accordance with the specified format.
Presence:	It shall present in file update related message (0302 and 0312).