RuPay - Online Switching Interface Specification

National Payments Corporation of India
RuPay - Online
Switching Interface
Specification
Version 1.6 Year 2013
Release Year 2013

Table of Contents
Table of Contents
Table of Contents __________________________________________________________________________________ 1
List of Figures ______________________________________________________________________________________ 7
List of Tables _______________________________________________________________________________________ 8
Confidentiality and Copyright Notice _________________________________________________________ 10
Document Control ________________________________________________________________________________ 11
Chapter 1 About This Manual _______________________________________________________________ 16
1.1 Audience ___________________________________________________________________________________ 16
1.2 Organization of the Manual _____________________________________________________________ 16
1.3 Exclusion ___________________________________________________________________________________ 16
1.4 Document Convention____________________________________________________________________ 16
1.5 More Information _________________________________________________________________________ 17
1.5.1 Related Publication ________________________________________________________________________________ 17
1.5.1.1 RuPay Global Clearing and Settlement (RGCS) ____________________________________________ 17
1.5.1.2 Operating Rule _______________________________________________________________________________ 17
Chapter 2 Introduction _______________________________________________________________________ 18

2.1 RuPay Switching Service _________________________________________________________________ 18
2.2 Transaction Flow SMS ____________________________________________________________________ 18
2.3 Transaction Flow DMS ___________________________________________________________________ 18
2.3.1 Authorization ______________________________________________________________________________________ 19
2.3.2 Clearing _____________________________________________________________________________________________ 19
2.3.3 Settlement __________________________________________________________________________________________ 19
2.4 Routing _____________________________________________________________________________________ 20

Chapter 3 Message Structure ________________________________________________________________ 21
3.1 Message Structure ________________________________________________________________________ 21
3.1.1 Message Header ____________________________________________________________________________________ 21
3.1.2 Message Type Identifier ___________________________________________________________________________ 21
3.1.2.1 Position 1- Version Number_________________________________________________________________ 21
3.1.2.2 Position 2 – Message Class __________________________________________________________________ 21
3.1.2.3 Position 3 – Message Function ______________________________________________________________ 22
3.1.2.4 Position 4 – Message Source ________________________________________________________________ 22
3.1.3 Bitmap ______________________________________________________________________________________________ 23
3.1.3.1 Primary Bitmap ______________________________________________________________________________ 23
3.1.3.2 Secondary Bitmap ___________________________________________________________________________ 23
3.1.3.3 Third Bitmap _________________________________________________________________________________ 23
3.1.4 Data Elements ______________________________________________________________________________________ 24
3.2 RuPay Implementation of ISO 8583 ____________________________________________________ 24

3.3 Private Use Fields _________________________________________________________________________ 24
RuPay - Online Switching Interface Specification

Version 1.6 Year 2013 NPCI © 2011 Confidential Page 1 of 197
Table of Contents
Chapter 4 Message Definition _______________________________________________________________ 25

4.1 Authorization Message ___________________________________________________________________ 25
4.1.1 Description of Authorization Message ___________________________________________________________ 25
4.1.2 Message Type Identifier for Authorization Message ____________________________________________ 25
4.2 Financial Message_________________________________________________________________________ 25

4.2.1 Description of Financial Message _________________________________________________________________ 25
4.2.2 Message Type Identifier for Financial Message _________________________________________________ 25
4.3 File Update Message ______________________________________________________________________ 25

4.3.1 Description of File Update Message ______________________________________________________________ 25
4.3.2 Message Type Identifier for File Update Message _______________________________________________ 26
4.4 Reversal Message _________________________________________________________________________ 26

4.4.1 Description of Reversal Message _________________________________________________________________ 26
4.4.2 Message Type Identifier ___________________________________________________________________________ 26
4.5 Network Management Message_________________________________________________________ 26

4.5.1 Description of Network Management Message __________________________________________________ 26
4.5.2 System Sign-On and Sign-Off ______________________________________________________________________ 27
4.5.3 Cutover Message ___________________________________________________________________________________ 27
4.5.4 Echo Message ______________________________________________________________________________________ 27
4.5.5 Message Type Identifier for Network Management Message __________________________________ 27
4.6 Advice Message ____________________________________________________________________________ 28

4.6.1 Description of Advice Message ___________________________________________________________________ 28
4.6.2 Message Type Identifier for Advice Message ____________________________________________________ 28
Chapter 5 NPCI System Functionalities ____________________________________________________ 29

5.1 Data Communication _____________________________________________________________________ 29
5.2 Message Logging at NPCI _________________________________________________________________ 29
5.3 Key Security and Management __________________________________________________________ 29
5.4 Static Key Exchange_______________________________________________________________________ 30
5.5 Dynamic Key Exchange___________________________________________________________________ 30
5.5.1 Master Sends a New Key __________________________________________________________________________ 30
5.5.2 Slave Send a New Key _____________________________________________________________________________ 31
5.6 Key Exchange Scenarios _________________________________________________________________ 31

5.7 PIN Encryption / Decryption Process __________________________________________________ 32
5.8 Time-Out Management ___________________________________________________________________ 32
5.9 Liquidity Management Module _________________________________________________________ 32
5.10 Matching Criteria – Key Data Fields ____________________________________________________ 33
Chapter 6 Member Responsibility __________________________________________________________ 34
6.1 Issuer Responsibility _____________________________________________________________________ 34
6.1.1 Message Supported by Issuer _____________________________________________________________________ 34
6.1.2 Maximum Response Time _________________________________________________________________________ 34
6.1.3 Authorization Cycle and Failure Condition Involving Issuer ___________________________________ 34
6.1.3.1 Authorization normal completion __________________________________________________________ 34

Table of Contents
6.1.3.2 Failure Conditions ___________________________________________________________________________ 35

6.1.3.3 Message Validation Failure at NPCI for an Issuer Response ______________________________ 35
6.1.3.4 System Failure during Authorization Request/ Financial Request to Issuer ____________ 36
6.1.3.5 System Failure during Authorization Response/ Financial Response from Issuer _____ 37
6.1.3.6 Late Response from Issuer __________________________________________________________________ 38
6.1.4 Stand-in functionality _____________________________________________________________________________ 38
6.1.4.1 Stand in Processing, Late Response from Issuer (NPCI Stand In) ________________________ 39
6.1.4.2 Stand in Processing, No response from issuer (NPCI Stand In) __________________________ 40
6.1.4.3 Stand-in Processing, Node Offline or Issuer Signed-off ___________________________________ 41
6.2 Acquirer Responsibilities________________________________________________________________ 42

6.2.1 Message Supported by Acquirer __________________________________________________________________ 42
6.2.2 Maximum Response Time for Acquirer __________________________________________________________ 43
6.2.3 Authorization Cycle and Failure Conditions Involving Acquirer _______________________________ 43
6.2.3.1 Authorization Normal Completion _________________________________________________________ 43
6.2.3.2 Failure Conditions ___________________________________________________________________________ 44
6.2.3.3 System Failure Acquirer Authorization / Financial Request (Acquirer Aware) ________ 44
6.2.3.4 System Failure Acquirer Authorization / Financial Request (Acquirer Unaware) ______ 45
6.2.3.5 Validation Failure at NPCI for Acquirer Message __________________________________________ 45
6.2.3.6 Acquirer Unable to Complete a Transaction due to the Terminal Failure (POS) ________ 46
6.2.3.7 System Failure NPCI (Aware) Authorization /Financial Response ______________________ 47
6.2.3.8 System Failure NPCI (Unaware) Authorization / Financial Response ___________________ 47
6.2.4 Advice message scenarios for acquirer __________________________________________________________ 49
6.2.4.1 Advice message normal completion ________________________________________________________ 49
6.2.4.2 Advice Delivery from Acquirer following Timeout ________________________________________ 49
Chapter 7 Message Format___________________________________________________________________ 51

7.1 Transaction Identification _______________________________________________________________ 51
7.1.1 Notations Used in Message Format _______________________________________________________________ 52
7.2 Message Format for Issuer ______________________________________________________________ 53

7.2.1 Current (Phase – I) Requirements ________________________________________________________________ 53
7.2.1.1 Purchase ______________________________________________________________________________________ 53
7.2.1.2 Purchase with Cashback _____________________________________________________________________ 54
7.2.1.3 RuPay Implementation of E-Commerce Purchase (Secure / Non-Secure) ______________ 55
7.2.1.4 E-Commerce 3D Purchase (Secure / Non-Secure) ________________________________________ 57
7.2.1.5 E-Commerce Refund _________________________________________________________________________ 58
7.2.1.6 Cash at PoS ___________________________________________________________________________________ 58
7.2.1.7 Cash Withdrawal - ATM _____________________________________________________________________ 60
7.2.1.8 Balance Inquiry ______________________________________________________________________________ 61
7.2.1.9 Reversal Message ____________________________________________________________________________ 62
7.2.1.10 Decline Message______________________________________________________________________________ 63
7.2.1.11 Network Management _______________________________________________________________________ 65
7.2.1.12 Pin Change ____________________________________________________________________________________ 65
7.2.1.13 Mini Statement _______________________________________________________________________________ 66
7.2.1.14 Card to Card Fund Transfer _________________________________________________________________ 67
7.2.1.15 Mobile Number Update ______________________________________________________________________ 70
7.2.1.16 Cheque Book Request _______________________________________________________________________ 71
7.2.1.17 Statement Request ___________________________________________________________________________ 72
7.2.1.18 Declined Advice (Quick EMV) _______________________________________________________________ 73
7.2.2 Future (Phase II) Requirements __________________________________________________________________ 75
7.2.2.1 Equated Monthly Instalment (EMI) ________________________________________________________ 75

Table of Contents
7.2.2.2 Loyalty Redemption _________________________________________________________________________ 76

7.2.2.3 Authorization Advice ________________________________________________________________________ 77
7.2.2.4 File Update ___________________________________________________________________________________ 78
7.2.2.5 Loyalty Inquiry _______________________________________________________________________________ 79
7.2.2.6 Refund ________________________________________________________________________________________ 80
7.3 Message Format for Acquirer ___________________________________________________________ 81

7.3.1 Current (Phase I) Requirements __________________________________________________________________ 81
7.3.1.1 Purchase ______________________________________________________________________________________ 81
7.3.1.2 Purchase with Cashback _____________________________________________________________________ 83
7.3.1.3 RuPay E-Commerce Purchase (Secure / Non-Secure) ____________________________________ 84
7.3.1.4 E-Commerce 3D Purchase ___________________________________________________________________ 85
7.3.1.5 E-Commerce Refund _________________________________________________________________________ 86
7.3.1.6 Cash at PoS ___________________________________________________________________________________ 87
7.3.1.7 Cash Withdrawal - ATM _____________________________________________________________________ 88
7.3.1.8 Balance Inquiry ______________________________________________________________________________ 89
7.3.1.9 Reversal ______________________________________________________________________________________ 90
7.3.1.10 Decline Message______________________________________________________________________________ 91
7.3.1.11 Network Management _______________________________________________________________________ 92
7.3.1.12 Pin Change ____________________________________________________________________________________ 93
7.3.1.13 Mini Statement _______________________________________________________________________________ 94
7.3.1.14 Card to Card Funds Transfer ________________________________________________________________ 95
7.3.1.15 Biometric Onus Authentication _____________________________________________________________ 96
7.3.1.16 Mobile Number Update ______________________________________________________________________ 98
7.3.1.17 Cheque Book Request _______________________________________________________________________ 99
7.3.1.18 Statement Request __________________________________________________________________________ 100
7.3.2 Future (Phase II) Requirements _________________________________________________________________ 101
7.3.2.1 Equated Monthly Instalments (EMI) ______________________________________________________ 101
7.3.2.2 Loyalty Redemption ________________________________________________________________________ 102
7.3.2.3 Loyalty Inquiry ______________________________________________________________________________ 104
7.3.2.4 Refund _______________________________________________________________________________________ 105
Chapter 8 Data Element Description _____________________________________________________ 107

8.1 Annotation Convention for Attributes ________________________________________________ 107
8.2 Data Elements Information Components ____________________________________________ 107
8.3 Detailed Description of Data Elements _______________________________________________ 108
8.3.1 DE – 2 Primary Account Number ________________________________________________________________ 108
8.3.2 DE – 3 Processing Code ___________________________________________________________________________ 109
8.3.3 DE – 4 Amount, Transaction _____________________________________________________________________ 110
8.3.4 DE – 5 Amount, Settlement _______________________________________________________________________ 111
8.3.5 DE – 6 Amount, Cardholder Billing ______________________________________________________________ 112
8.3.6 DE – 7 Date and Time Transmission_____________________________________________________________ 113
8.3.7 DE – 9 Conversion Rate, Settlement _____________________________________________________________ 114
8.3.8 DE – 10 Conversion Rate, Cardholder Billing ___________________________________________________ 115
8.3.9 DE – 11 System Trace Audit Number ____________________________________________________________ 116
8.3.10 DE – 12 Time, Local Transaction______________________________________________________________ 117
8.3.11 DE – 13 Date, Local Transaction ______________________________________________________________ 118
8.3.12 DE – 14 Date, Expiry ___________________________________________________________________________ 119
8.3.13 DE – 15 Date, Settlement ______________________________________________________________________ 120
8.3.14 DE – 16 Date, Conversion _____________________________________________________________________ 121
8.3.15 DE – 18 Merchant Category Code _____________________________________________________________ 122

Table of Contents
8.3.16 DE – 19 Acquiring Country Code______________________________________________________________ 123

8.3.17 DE – 22 Point of Service Entry Mode _________________________________________________________ 124
8.3.18 DE – 23 Card Sequence Number ______________________________________________________________ 125
8.3.19 DE – 25 Point of Service Condition Code _____________________________________________________ 126
8.3.20 DE – 28 Amount, Fees _________________________________________________________________________ 127
8.3.21 DE – 32 Acquiring Institution Code ___________________________________________________________ 128
8.3.22 DE – 33 Forwarding Institution Code ________________________________________________________ 129
8.3.23 DE – 35 Track 2 Data __________________________________________________________________________ 130
8.3.24 DE – 37 Retrieval Reference Number ________________________________________________________ 131
8.3.25 DE – 38 Authorization Identification Response _____________________________________________ 132
8.3.26 DE – 39 Response Code ________________________________________________________________________ 133
8.3.26.1 Response code scenarios ___________________________________________________________________ 135
8.3.26.2 E-commerce 3 D Implementation _________________________________________________________ 136
8.3.26.3 RuPay Implementation of E-commerce ___________________________________________________ 136
8.3.27 DE – 40 Service Condition Code ______________________________________________________________ 138
8.3.28 DE – 41 Card Acceptor Terminal ID __________________________________________________________ 139
8.3.29 DE – 42 Card Acceptor ID _____________________________________________________________________ 140
8.3.30 DE – 43 Card Acceptor Name / Location _____________________________________________________ 141
8.3.31 DE – 44 Additional Response Data ___________________________________________________________ 142
8.3.32 DE – 45 Track I Data ___________________________________________________________________________ 144
8.3.33 DE – 48 Additional Data _______________________________________________________________________ 145
8.3.34 DE – 49 Currency Code, Transaction _________________________________________________________ 151
8.3.35 DE – 50 Currency Code, Settlement __________________________________________________________ 152
8.3.36 DE – 51 Currency Code, Cardholder Billing __________________________________________________ 153
8.3.37 DE – 52 PIN Data _______________________________________________________________________________ 154
8.3.38 DE – 54 Additional Amount ___________________________________________________________________ 155
8.3.39 DE – 55 Chip Data ______________________________________________________________________________ 157
8.3.39.1 Authorization Message DE – 55 Presence Descriptions __________________________________ 157
8.3.40 DE – 60 Advice Reason Code __________________________________________________________________ 161
8.3.41 DE – 61 PoS Data Code ________________________________________________________________________ 162
8.3.42 DE – 62 Private Data 1-Biometric Data _______________________________________________________ 165
8.3.43 DE – 63 Private Data 2, Encrypted Biometric Data __________________________________________ 166
8.3.44 DE – 70 Network Management Information Code ___________________________________________ 167
8.3.45 DE – 90 Original Data Element ________________________________________________________________ 168
8.3.46 DE – 91 File Update Code ______________________________________________________________________ 169
8.3.47 DE – 95 Replacement Amount ________________________________________________________________ 170
8.3.48 DE – 101 File Name ____________________________________________________________________________ 171
8.3.49 DE – 102 Account Identification 1 ____________________________________________________________ 172
8.3.50 DE – 103 Account Identification 2 ____________________________________________________________ 173
8.3.51 DE – 120 Private Data 3 _______________________________________________________________________ 174
8.3.52 DE – 121, 122, 123 Private Data 4 – 6 ________________________________________________________ 180
8.3.53 DE – 124 File Action Record and Data ________________________________________________________ 181
8.3.54 DE – 126 Additional Data-Biometric Data ___________________________________________________ 182
8.3.55 DE –127 Additional Data-Biometric Data ____________________________________________________ 184
Chapter 9 Compliance _______________________________________________________________________ 186

9.1 Member Compliance Acquirer _________________________________________________________ 186
9.1.1 General Compliance ______________________________________________________________________________ 186
9.1.2 Transaction Wise Compliance ___________________________________________________________________ 186
9.1.3 Standards related to Compliance ________________________________________________________________ 188
9.2 Member Compliance Issuer ____________________________________________________________ 188

Table of Contents
9.2.1 General Compliance ______________________________________________________________________________ 188

9.2.2 Transaction Wise Compliance ___________________________________________________________________ 189
9.2.3 Standards related to Compliance ________________________________________________________________ 190
Annexure 1-Card to Card Fund Transfer ___________________________________________________ 191

Transaction Flow for Card To Card Funds Transfer ____________________________________________________ 191
Maximum Response Time _________________________________________________________________________________ 191
Annexure 2 -State Code ________________________________________________________________________ 192

Annexure 3 -Glossary __________________________________________________________________________ 193
Annexure 4 -Definition ________________________________________________________________________ 195

List of Figures
List of Figures
Figure 1 SMS Transaction Flow _______________________________________________________________________ 18
Figure 2 DMS Transaction Flow _______________________________________________________________________ 19
Figure 3 ISO 8583 Message Structure ________________________________________________________________ 21
Figure 4 Master Send a New Key ______________________________________________________________________ 30
Figure 5 Slave Sends a New Key_______________________________________________________________________ 31
Figure 6 Authorization Normal Completion__________________________________________________________ 35
Figure 7 Message Validation Failure – NPCI _________________________________________________________ 35
Figure 8 System Failure – Authorization Request/ Financial Request _____________________________ 36
Figure 9 System Failure – Authorization Response/ Financial Response _________________________ 37
Figure 10 Late response from issuer _________________________________________________________________ 38
Figure 11 Stand-in Processing, Late Response from Issuer _________________________________________ 39
Figure 12 Stand-in Processing, No Response from Issuer __________________________________________ 40
Figure 13 Stand-in Processing, Node Offline or Issuer Signed-off __________________________________ 41
Figure 14 Maximum Response Time for Acquirer ___________________________________________________ 43
Figure 15 Normal Completion of an Authorization Message/ Financial Message_________________ 43
Figure 16 System failure - Acquirer Aware - Authorization / Financial Request _________________ 44
Figure 17 System Failure - Acquirer Unaware - Authorization / Financial Request ______________ 45
Figure 18 Message Validity Failure at NPCI - Authorization / Financial Request _________________ 45
Figure 19 Incomplete Transactions in case of Terminal Failure ___________________________________ 46
Figure 20System Failure - NPCI Aware - Authorization / Financial Response ____________________ 47
Figure 21 System Failure - NPCI Unaware - Authorization / Financial Response _________________ 48
Figure 22 Advice Messages getting Completed Normally ___________________________________________ 49
Figure 23 Advice Delivery Crossing Time Limits ____________________________________________________ 49

List of Tables
List of Tables
Table 1 Version History ________________________________________________________________________________ 11
Table 2 Document Revision History __________________________________________________________________ 15
Table 3 Document Convention ________________________________________________________________________ 16
Table 4 Components of Message Structure___________________________________________________________ 21
Table 5 Version Number ISO 8583 Message _________________________________________________________ 21
Table 6 Message Class ISO 8583 Message ____________________________________________________________ 22
Table 7 Message Function ISO 8583 Message ________________________________________________________ 22
Table 8 Message Source ISO 8583 Message __________________________________________________________ 22
Table 9 RuPay Implementation of ISO 8583 _________________________________________________________ 24
Table 10 Private Fields Used in RuPay _______________________________________________________________ 24
Table 11 Message Supported by Issuer _______________________________________________________________ 34
Table 12 Message Supported by Acquirer____________________________________________________________ 42
Table 13 Key Data Elements ___________________________________________________________________________ 52
Table 14 Symbols used in Message Format __________________________________________________________ 53
Table 15 Purchase Message – Issuer __________________________________________________________________ 54
Table 16 Purchase with Cashback Message – Issuer ________________________________________________ 55
Table 17 RuPay E-Commerce Message – Issuer _____________________________________________________ 57
Table 18 E-Commerce 3D Message – Issuer__________________________________________________________ 58
Table 19 Cash at PoS– Issuer __________________________________________________________________________ 59
Table 20 Cash Withdrawal - ATM Message – Issuer _________________________________________________ 61
Table 21 Balance Inquiry Message – Issuer __________________________________________________________ 62
Table 22 Reversal Message – Issuer __________________________________________________________________ 63
Table 23 Decline Message _____________________________________________________________________________ 65
Table 24 Network Management Message – Issuer___________________________________________________ 65
Table 25 Pin Change Message – Issuer _______________________________________________________________ 66
Table 26 Mini Statement Message – Issuer ___________________________________________________________ 67
Table 27 Card to Card Fund Transfer-Debit leg to the issuer _______________________________________ 69
Table 28 Card to Card Fund transfer-Credit to the beneficiary _____________________________________ 70
Table 29 Mobile Number Update – Issuer ____________________________________________________________ 71
Table 30 Cheque Book Request – Issuer______________________________________________________________ 72
Table 31 Statement Request – Issuer _________________________________________________________________ 73
Table 32 Decline Advice Message (Quick EMV) – Issuer ____________________________________________ 74
Table 33 EMI Message – Issuer________________________________________________________________________ 76
Table 34 Loyalty Redemption Message – Issuer _____________________________________________________ 77
Table 35 Authorization Advice Message – Issuer ___________________________________________________ 78
Table 36 File Update Message – Issuer _______________________________________________________________ 79
Table 37 Loyalty Inquiry Message – Issuer___________________________________________________________ 80
Table 38 Refund Message – Issuer ____________________________________________________________________ 81
Table 39 Purchase Message – Acquirer_______________________________________________________________ 82
Table 40 Purchase with Cashback Message – Acquirer _____________________________________________ 84
Table 41 RuPay E-Commerce Purchase Message – Acquirer _______________________________________ 85
Table 42 E-Commerce 3D Purchase Message – Acquirer ___________________________________________ 86
Table 43 Cash at PoS / Cash Withdrawal Message – Acquirer ______________________________________ 88

List of Tables
Table 44 Cash Withdrawal - ATM Message – Acquirer ______________________________________________ 89

Table 45 Balance Inquiry – Acquirer _________________________________________________________________ 90
Table 46 Reversal Message – Acquirer _______________________________________________________________ 91
Table 47 Decline Message _____________________________________________________________________________ 92
Table 48 Network Management Message ____________________________________________________________ 93
Table 49 Pin Change Message – Acquirer ____________________________________________________________ 94
Table 50 Mini Statement Message – Acquirer ________________________________________________________ 95
Table 51 Card to Card Fund transfer _________________________________________________________________ 96
Table 52 Biometric Onus Authentication _____________________________________________________________ 97
Table 53 Mobile Number Update _____________________________________________________________________ 99
Table 54 Cheque Book Request _____________________________________________________________________ 100
Table 55 Statement Request_________________________________________________________________________ 101
Table 56 EMI Message – Acquirer___________________________________________________________________ 102
Table 57 Loyalty Redemption Message - Acquirer ________________________________________________ 103
Table 58 Loyalty Inquiry Message – Acquirer _____________________________________________________ 105
Table 59 Refund Message – Acquirer _______________________________________________________________ 106
Table 60 Abbreviation used in Data Element Description ________________________________________ 107
Table 61 Data and Time Attribute __________________________________________________________________ 107
Table 62 Data Element Information Components _________________________________________________ 107
Table 63 Response Code Table ______________________________________________________________________ 134
Table 64 Compliance Reject Response Code _______________________________________________________ 134
Table 65 Response Code for Advice Message ______________________________________________________ 134
Table 66 Response codes Supported for Reversal Response / Request Messages ______________ 135
Table 67 Response Code Supported for Reversal Response ______________________________________ 135
Table 68 Response Code Supported for Network Management Message________________________ 135
Table 69 Acquirer Compliance Reject Reason code _______________________________________________ 143
Table 70 Acquirer Compliance Reject Reason code _______________________________________________ 143
Table 71 Product Code _______________________________________________________________________________ 149
Table 72 DE 55 Presence Descriptions _____________________________________________________________ 160
Table 73 State Code __________________________________________________________________________________ 192
Table 74 Glossary and Description _________________________________________________________________ 194
Table 75 Definition ___________________________________________________________________________________ 197

Confidentiality and Copyright Notice
Confidentiality and Copyright Notice

© 2011 by National Payments Corporation of India.
This document is of restricted use. No part of this document may be reproduced in any form by
any means without prior written authorization of National Payment Corporation of India
(NPCI).

Document Control
Document Control
Document name: RuPay Online Switching Interface Specifications
Security classification: Confidential
Distribution list: Member banks
Version History:
Version Issue Date Effective Date

Draft 1.0 01-Sep-2011 01-Sep-2011
Version 1.1 01-Nov-2011 01-Nov-2011
Version 1.2 12-Dec-2011 12-Dec-2011
Version 1.3 19-Jan-2012 19-Jan-2012
Version 1.4 30-Jun-2012 30-Jun-2012
Version 1.5 12-Oct-2012 12-Oct-2012
Version 1.5.1 16-Oct-2012 16-Oct-2012
Version 1.5.2 22-Jul-2013 22-Jul-2013
Table 1 Version History
Document Revision History
Sr. Description Version

Section
No.
7.3.1.16,7.3.1.17, Card To Card Funds transfer message format added 1.5
1 7.2.1.17,7.2.1.18,
7.2.1.19
Partial early issuer for Chip Transaction ,Full chip 1.5
purchase, full early issuer purchase, reversal full chip,
2
reversal full chip early issuer, advice message for chip
transaction, fallback for issuer removed
3 8.3.33 Default risk score, Value 99999 changed to 00999 1.5
4 8.3.26.1,8.3.26.2 Explanation of response code ED added 1.5
5 8.3.26 Response code related to FRM added 1.5
8.3.42,8.3.53,8.3. DE 62, 126 and 127 defined for biometric 1.5
6
54 authentication
7 8.3.47 DE 95 updated for partial reversal 1.5
DE 54 updated for support of ledger and available 1.5
8 8.3.38
balance for ATM
9 8.3.44 DE 70 constraint modified 1.5
Value 6, 8, 9 removed from DE 48 tag 060. Tag 60 1.5
10 8.3.33
value 9 redefined with UID authentication
11 8.3.50 DE 120 Updated 1.5
12 8.3.41 DE 61 Updated with new values in subfield 8 1.5
13 8.3.17 New values added for DE 22 1.5
14 7.2,7.3 DE 62 added for all biometric transactions 1.5
DE 63 ,DE 126,DE 127 removed from all issuer 1.5
15 7.2
message formats
DE 126,127 added in acquirer message formats for all 1.5
16 7.3
biometric transactions

Document Control

Section
No.
Type changed from n to an for tag 067 (Income Tax 1.5
17 8.3.33
PAN) in DE 48
New values 99 added in PAN entry mode and 8 added 1.5
18 8.3.17
in Pin entry mode.
DE 61 subfield 1 and value 1 updated(unknown 1.5
19 8.3.41 added)
20 8.3.38 DE 54 description updated 1.5
21 8.3.39 DE 55 tags and description updated 1.5
22 8.3.33 Default value added for tag 071 in DE 48 1.5
23 8.3.33 New value has been added in tag 060-value 9 in DE 48 1.5
24 7.3.1.15 Biometric Onus Authentication added 1.5
08xx network management message is in scope of 1.5.1
25 3.1.2.2
RuPay implementation
26 7.1 Biometric Verification added as transaction type 1.5.1
For ATM transaction CVD/iCVD match result code 1.5.1
27
made conditional in response.
28 DE-23 Quick EMV and Full chip issuer constraint updated 1.5.1
29 DE-37 Format update, Trace Number replaced with STAN 1.5.1
Explanation added and scenario for Acquirer Time-out, 1.5.1
30 DE-38
Terminal Failure and Customer Cancellation added
31 DE-44 A044, I023, I055 added 1.5.1
Tag 60 Name changed from CHIP Transaction 1.5.1
32 DE-48 Authorization Indicator to Transaction Authorization
Indicator
Full Chip Issuer and Quick EMV issuer constraint 1.5.1
33 DE-55
added
34 Glossary New items added in glossary 1.5.1
Response Code ‘32’ moved from Table 58 to Table 61 1.6
35 8.3.26
as Table 61 is for reversal response codes.
In reversal message format, DE-44 is made conditional 1.6
36 7.2.1.9
DE 55 in response has been changed to '--'
DE – 48 Additional Data, Tag 057 description, ICS1 1.6
37 8.3.33 passed validation-authentication value changed to ‘02’
The following statement has been added: 1.6

“In case of Balance Enquiry, if acquirer is sending the
processing code as unspecified then issuer can
38 8.3.38 respond back with balance from either ‘Savings’ or
‘Current’ account. But the account type in Processing
code and Additional should be same”.
In section Cutover Message, 1st point has been 1.6

removed and the below point have been added:
39 4.5.3 “NPCI will issue cutover message (0800 message with
net code=201 in DE70) at 23:00 Hrs indicating a
business date change for bot SMS & DMS transactions.”
40 8.3.33 DE 48 Tag 055 Length changed from a1 to n2 1.6
DE 55 Tag 91 will not be present for 0430 and 0130. It 1.6
41 8.3.39 has been changed from C to “-“.

Document Control

Section
No.
In the Echo Message (point 4), Member banks and 1.6
NPCI will also generate Echo message (0800 message
42 4.5.4 type) to keep alive during no transaction time. Ideal
duration for the same changed from 10 minutes to 3
minutes.
In DE – 22 Point of Service Entry Mode- 1.6
43 8.3.17 95 Chip card with unreliable CVD “or iCVD”
(description changed)
44 5.9 More description added to LMM 1.6
In the card to card fund transfer, Inquiry transaction 1.6
has been removed.
45 Annexure 1
Transaction flow for Card to Card funds transfer
updated.
46 8.3.51 DE 120 updated for Card to Card funds transfer 1.6
Card to Card to funds transfer Inquiry has been 1.6
47 7.2.1.14 removed.
DE 120 Tag 045 (credit transaction to beneficiary) and 1.6

48 7.2.1.14 DE 120 Tag 046 (debit transaction to sender / issuer)
removed
In the message format Card to Card Fund Transfer 1.6
49 7.3.1.14
DE120 Tag 045 and Tag 046 removed
7.2.1.15,7.2.1.16, Mobile number update, Statement Request and Cheque 1.6
50
7.2.1.17 Book Request message format have been added
New message format added for Declined Advice (Quick 1.6
51 7.2.1.18
EMV)
New value introduced in DE 48 in Tag 060 value 6 and 1.6
52 8.3.33
Value 8
New value introduced in DE 48 in Tag 071 length has 1.6
53 8.3.33 been changed from 15 to 42. This has been done to
have provision for IPv6
New Tag introduced in DE 48 i.e. Tag 077. This tag is 1.6
54 8.3.33 used by Issuer to pass unique value for E-Comm
Registration transaction
New Tag introduced in DE 48 i.e. 078, 079, 080 and 1.6
55 8.3.33
081 as reserved for future use (RFU)
Definition changed for Tag 056 Value 21 1.6
56 8.3.33
Definition changed for Tag 060 value 6, 7, and 8
SF 7 description of values 3 and 4 modified 1.6
SF 8 New value introduced. ‘G’ – Offline PIN
57 8.3.41
SF 10 description of value 0 changed to unknown
SF 14 explanation changed
Para 2 changed to “NPCI cut off time indicates the new 1.6
58 4.5.3 settlement date is considered for transactions after
cutover for SMS transactions”
Description changed to “When an advice message is 1.6
forwarded from Acquirer/NPCI to any destination
then, forward the advice message to the destined
59 4.6.1
entity and if an advice message is not delivered
immediately due to some communication failure to the
receiving entity then the advice message is stored in

Document Control

Section
No.
their appropriate SAF and is delivered to the
destination when communication is re-established.”
Point 2 descriptions changed “The new key details 1.6
along with key check value will be sent in DE 48 and
the key is encrypted. The participant bank should
60 5.5.1 decrypt the new ZPK key using the ZMK and store into
their switch and should respond back to NPCI with
0810 message with response code as “00” along with
DE70=184”
Point 4 descriptions changed "The new key details will 1.6
be sent in DE48 and key be sentinDE48andkey
encrypted value under ZMK and key check value. The
61 5.5.2 participant bank should decrypt the new ZPK key
using the ZMK and store into their switch and should
respond back to 0810 message with response code as
“00” along with DE70=184”
Note updated "Note:-In this case acquirer will not 1.6
generate a reversal to NPCI. NPCI will respond to
acquirer with response code 91 (In case of message
validation failure in DE2, DE 11, DE 32, DE37, DE 41)
.NPCI will generate the reversal towards issuer with
response code-CI only if the authorization is successful
and populate DE 44 with reject reason code of
62 6.1.3.3 response message (In case Issuer not sending DE
38/DE 39 /Format error in DE 38 or DE 39/DE 39 not
from the table as defined in DE 39 description in
chapter “Data Elements Description”). It must be noted
by the issuer that it may get multiple reversal for the
transaction and it is issuer’s responsibility to verify the
reversal before posting the same into customer
account."
Point 5 updated "NPCI also creates an acquirer 1.6
reversal advice/ message with response code 91
63 6.1.3.6 indicating that no authorization response/ financial
response message was received This message is placed
in the SAF file for later delivery to the issuer."
Note updated "Note: Acquirer can generate reversal up 1.6
to next 3 cutover cycles. If a reversal is generated after
64 6.2.4.2
next 3 cutover cycles then NPCI will not validate the
same and send it to the issuer."
Track I description changed to "For UID based 1.6
transaction DE 45 is required excluding start and end
65 8.3.32
sentinel and LRC characters. For international
transactions track 1 may be present”.
DE 55 Chip Data handling of unexpected tag has been 1.6
added as "Unexpected EMV Tags: This field may
contain tags that the receiving issuer or acquirer does
66 8.3.39
not recognize or does not expect. The receiver must
ignore such tags and continue parsing the next tag in
DE 55"
67 8.3.49 DE 102 Account Identification 1 Type changed to 1.6

Document Control

Section
No.
ans..19 from ans..28
DE 103 Account Identification 1 Type changed to 1.6
68 8.3.50
ans..19 from ans..28
69 4.2.1 Note added 1.6
70 7.2.1.2 Note enhanced for clarity for DE 4, DE6 and DE49 1.6
71 7.2.1.7 Note enhanced for clarity on DE4, DE6 and DE 49 1.6
72 8.3.5 Compliance of Billing amount changed 1.6
New value added in Acquirer Reject Reason Code – 1.6
73 8.3.31
A090
Reversal message format revised and DE 44 made 1.6
74 7.3.1.9
conditional in reversal response 0430
75 7.2.1.3 DE 48 Tag 077 added in the message format 1.6
76 7.3.1.3 DE 48 Tag 077 added in the message format 1.6
Table 2 Document Revision History

About This Manual Audience
Chapter 1 About This Manual

This manual documents the technical details of RuPay transaction processing. The manual
contains detailed specifications for RuPay message formats, field descriptions, codes, and files.
1.1 Audience
This manual is intended for technical staff and managers and customer support personnel of the
member banks.
1.2 Organization of the Manual

Chapter 2, Introduction – This chapter provides basic overview of the authorization system.
Chapter 3, Message structure – This chapter contains message structure supported by NPCI
Chapter 4, Message definitions– This chapter contains various types of messages supported
by NPCI
Chapter 5, NPCI system functionalities – This chapter contains various functionalities of the
NPCI online authorization system.
Chapter 6, Member responsibilities - This chapter contains responsibilities of the issuing and
acquiring bank
Chapter 7, Message formats – This chapter contains NPCI message formats for various
transactions
Chapter 8, Data element description – This chapter defines the data element description for
NPCI online messages
Chapter 9, Compliance – This section defines the compliance requirements for members.
Glossary – Glossary of terms used in this manual.
Definition – Definition of terms used in this manual.
1.3 Exclusion
The current specification version excludes the following items:
 Micro ATM transactions

 Mobile based transactions
1.4 Document Convention

Document Convention Purpose in the Manual
Italics For writing note
Note Providing more information about the preceding topics
Table 3 Document Convention

About This Manual More Information
1.5 More Information

1.5.1 Related Publication
1.5.1.1 RuPay Global Clearing and Settlement (RGCS)
This document does not contain details about the RuPay Global Clearing and Settlement System
(RGCS). For information about this system, kindly refer Technical Specification – RuPay Clearing
and Settlement System
1.5.1.2 Operating Rule

For Operating Rule refer RuPay Operating Regulations.

Introduction RuPay Switching Service
Chapter 2 Introduction
As a part of the RuPay Switching Service, the ‘NPCI Network’ will collect transactions from a
trusted source (an acquirer) and deliver it to a trusted destination (an issuer). The trusted
destination will use this information to validate the transaction to the cardholder’s account and
further authenticate the transaction back to the trusted source through ‘NPCI Network’. ‘NPCI
Network’ further facilitates the process of clearing a valid authenticated transaction and
provides the settlement service. A settlement service is a facility within which funds are
exchanged between members and NPCI to settle transactions and fee amounts.
The RuPay Switching Service will facilitate POS and ATM transactions among all member banks
participating in the ‘NPCI network’. The RuPay Switching Service operates on a continuous
basis, ensuring that cardholders in India can use their card anytime and that Acquirers and
Issuers in India always have access to NPCI RuPay Switching Service facility.
2.1 RuPay Switching Service

NPCI Switching service supports routing of interbank POS and ATM transactions through NPCI
network. It supports both single message system (SMS) and dual Messaging Systems (DMS).
Transaction flow for SMS and DMS are described below.
2.2 Transaction Flow SMS

NPCI single message system will process full financial transactions. Full financial transactions
contain both authorization and clearing information in a single message.
Single message system environment uses a single exchange of messages between the acquirer
and the issuer to
 Authorize a financial transaction
 Post a financial transaction to a cardholder’s account
The NPCI SMS system will perform real time transaction processing as well as exception or
offline transaction processing offline. Transaction flow in SMS environment is as follows:
Merchant Central Switch
Acquirer Issuer
0200 0200
0210 0210
ATM and SMS

POS transaction
downloaded
from Central
 Offline and  Offline and
switch for
settlement settlement
processing after
files files
cutover
RGCS
Figure 1 SMS Transaction Flow
2.3 Transaction Flow DMS

A dual message system comprises of authorization, clearing and settlement.

Introduction Transaction Flow DMS
2.3.1 Authorization
Authorization is the process where the card issuing bank notifies the acquirer and the merchant
of the availability of funds for a cardholder, and issues an authorization code for the transaction
2.3.2 Clearing
The movement of transaction information from the member to NPCI network and NPCI network
to members is referred to as Clearing. In the clearing process, the funds are claimed from
member parties using the NPCI network by exchanging clearing files. Clearing activities
facilitate the settlement process.
2.3.3 Settlement
Settlement is the process used to exchange funds between members for the net value of the
monetary transactions cleared for the specific processing day.
Transaction flow in DMS environment is as follows:
Merchant Central Switch
Acquirer Issuer
0100 0100
0110 0110
POS transaction
downloaded
from Central
 Clearing  Clearing
Switch for
and and
processing after
settlement settlement
cutover
files files
RGCS
Figure 2 DMS Transaction Flow
This document defines the Host-to-Host RuPay online message specifications for both single
message system and dual message system. Messages to be used for the connection between the
NPCI host, issuer and acquirer will be based on the ISO-8583 standard. This document outlines
the detailed usages of theISO-8583 protocol between the two host systems and the data format
to be used in individual data elements.
Note: The word POS here encompasses all the transaction types other than ATM transactions like
POS/IVR/E-Comm.

Introduction Routing
2.4 Routing
Routing is the process of moving information across an inter-network from a source to a
destination. The NPCI RuPay Switching service supports routing of interbank POS and ATM
transactions through NPCI network.
 NPCI system will support the routing for authorization for both SMS and DMS system.
The clearing and settlement of DMS transaction is carried through RuPay Global
Clearing and settlement system (RGCS)
 The central switch of the NPCI system validates the request message from the acquirer
and prepares it for processing. This processing and validation include identifying the
message type, identifying the Issuing bank, checking of structural, format and value
validation, and Liquidity Management Module (LMM) checking.
If the central switch encounters an error condition at any point in the process then further
processing is halted. Messages rejected or declined by NPCI are sent back to the acquirer with a
proper response code indicating occurrence of an error condition wherever possible and the
message is not forwarded to the issuer. For e.g. if a message does not contain a mandatory field
in the request, or a field contains an alphabet in place of a number then that message would be
rejected at the NPCI’s end.

Message Structure Message Structure
Chapter 3 Message Structure

3.1 Message Structure
NPCI online messages are based on Bank Card Organizational Messages—Interchange Message
Specifications—Content for Financial Transactions, International Organization for
Standardization (ISO) 8583; 1987 (E). NPCI online messages have four basic components, as
shown below. The message structure is based on ISO 8583 standard as defined in the following
table.
Message Header MTI Bit Map Data Elements

Figure 3 ISO 8583 Message Structure
A message structure comprises of the following components:
Message Element Description

Message Header Contains the length of the message
MTI Message Type Identifier. Specifies general category of message
Bit Map Specifies which data elements are present
Data Element Concatenated data elements
Table 4 Components of Message Structure
3.1.1 Message Header

Message header consists of 2 bytes binary value which contains the length of message excluding
the header length.
3.1.2 Message Type Identifier

This is a 4 digit numeric field, whose each digit starting from the left indicates - ISO 8583
version, the message class, the message function, and the message origin.
3.1.2.1 Position 1- Version Number

1st position of the message type identifier (MTI) specifies the version of the ISO 8583 standard
used to transmit the message.
MTI Signifies RuPay Implementation

0xxx ISO 8583:1987 version 
1xxx ISO 8583:1993 version 
2xxx ISO 8583-1:2003 version 
9xxx Reserved for ISO use 
Table 5 Version Number ISO 8583 Message
3.1.2.2 Position 2 – Message Class

2nd position of the MTI specifies the class of the message.

01xx Authorization messages 
02xx Financial transaction messages 
03xx File update messages 
04xx Reversal messages 


08xx Network management messages 
Table 6 Message Class ISO 8583 Message
3.1.2.3 Position 3 – Message Function
3rd position of the MTI specifies the message function which defines how the message will flow
within the system.
xx00 Request 
xx10 Request response 
xx20 Advice 
xx30 Advice response 
xx40 Notification 
Table 7 Message Function ISO 8583 Message
3.1.2.4 Position 4 – Message Source

4th position of the MTI defines the location of the message source.

xxx0 Acquirer 
xxx1 Acquirer repeat 
xxx2 Issuer 
xxx3 Issuer repeat 
Table 8 Message Source ISO 8583 Message
Following are the valid message type identifiers for RuPay online specifications
 0100 - Authorization Request

 0110 - Authorization Response
 0200 - Financial Transaction Request
 0210 - Financial Transaction Response
 0120 - Authorization Advice Request
 0130 - Authorization Advice Response
 0220 – Financial advice request
 0230 – Financial advice response
 0302 - Issuer File Update Request
 0312 - Issuer File Update Response
 0420 - Acquirer Reversal Request
 0430 - Acquirer Reversal Response
 0800 - Network Management Request
 0810 - Network Management Response

3.1.3 Bitmap
Within an ISO 8583 message, a bitmap is a field or subfield that indicates which data elements
may be present elsewhere in a message. The message text segment of all messages transmitted
through NPCI Host is of variable length. For this segment, bit maps specify the fields that are
present and those that are missing.
The valid combinations of the bit maps are:
 Primary bitmap
 Primary and secondary bitmap
 Primary, secondary and third bitmap
3.1.3.1 Primary Bitmap

Each message includes the primary bitmap. It is a control field consisting of 64 bits (8 bytes)
located after the message type identifier. Except for the first bit, each bit in the bitmap relates to
the corresponding data field (fields 2–64) in the message. The value in the bit indicates whether
the data field is present in the message:
 If a bit is 0, the field related to that bit is not present in the message.
 If a bit is 1, the field related to that bit is present in the message.
Data field number 1 does not exist. The first bit of the primary map is used to indicate if another
bitmap called the second bitmap (see the next section) immediately follows this primary one.
3.1.3.2 Secondary Bitmap

The first bit of the first bitmap indicates the presence or absence of a second map called the
second bitmap. Like the primary map, the secondary map is a control field consisting of 64 bits
(8 bytes). It can be considered an extension of the primary map because it is associated with
fields 66 through 128. Data field 65 does not exist. This position, like that of field 1 in the
primary map, is used to indicate the presence of another bitmap. A 1 in this position indicates
the presence of a third bitmap.
The second bitmap is present only when the message contains information in any field from 66
through 128. When present, the secondary map immediately follows the primary bitmap and
precedes the data fields.
3.1.3.3 Third Bitmap

A tertiary, or third, bitmap can be used to indicate the presence or absence of fields 129 to 192.
A 1 in the first bit of the second bitmap (bit 65) indicates the presence of the third bitmap.
The third bitmap is aligned at the beginning of the message, directly following the first two
bitmaps. The data elements follow the bitmaps. The third bitmap is reserved for future use.
Note: The message exchanged between member switch and the NPCI switch will use ASCII
character set. Message header will be in binary.

Message Structure RuPay Implementation of ISO 8583
3.1.4 Data Elements

Data elements are fields carrying the information of the transaction itself. Each Data element
has a specified meaning and format. The detailed description of the data elements is described
in the Chapter 8.
For example: Bit value 2 is assigned to Primary Account Number, 3 is assigned to Processing
Code, 4 is for Transaction Amount similarly bit value 128 is for message authentication code
field and so on. For each data element there is specific data format, size, constraints and
description, which are been mentioned in Chapter 8.
3.2 RuPay Implementation of ISO 8583

The flowing table describes RuPay implementation of ISO 8583 messaging standard.
Variations Descriptions
Message Header NPCI uses 2 byte header which indicates the length of the
message minus header.
DE 22 – POS entry mode NPCI uses five private values 80, 81, 90, 91, 95 ,99 for PAN entry
mode and two private values 6, 9,8 for PIN entry mode of DE 22
DE 25 -POS Condition code NPCI defines three private values 51, 59, 71 for this field
DE 44 – Additional response NPCI defines additional response data to indicate the reject code
data in case if the message fails to comply with the rules
Table 9 RuPay Implementation of ISO 8583
3.3 Private Use Fields

The following table describes private fields used in RuPay implementation
Variations Descriptions
DE 48 -Additional data NPCI uses DE 48 which is reserved by ISO for “Private use”
DE 60 – Advice reason code NPCI uses DE 60 which is reserved by ISO for “Private use”
DE 61 – POS data code NPCI uses DE 61 which is reserved by ISO for “Private use”
DE 62 – Private data field 1 NPCI uses DE 62which is reserved by ISO for “Private use”
DE 63 – Encrypted biometric field
NPCI uses DE 63which is reserved by ISO for “Private use”
DE 120 – Private data field 3 NPCI uses DE 120which is reserved by ISO for “Private
use”
DE 121 to DE 123 – Private data NPCI uses DE 121 to DE 123which is reserved by ISO for
field 4 - 6 “Private use”
DE 127 – Private data field 7 NPCI uses DE 127which is reserved by ISO for “Private
use”
Table 10 Private Fields Used in RuPay

Message Definition Authorization Message
Chapter 4 Message Definition

NPCI system messages generally consist of a pair of messages: a request message followed by a
response message. This section provides an overview and defines various types of messages
supported by the NPCI system.
4.1 Authorization Message

4.1.1 Description of Authorization Message
This message authorizes a transaction before a final amount of the purchase is known. It
determines if funds are available, gets an approval and block the funds in the account. These
messages do not have a settlement impact hence, to clear and settle an approved transaction the
acquirer must submit the transaction to the clearing system.
4.1.2 Message Type Identifier for Authorization Message

Authorization request–0100
Authorization response–0110
Authorization advice request – 0120
Authorization advice response – 0130
4.2 Financial Message

4.2.1 Description of Financial Message
This message determines if funds are available, gets an approval and debits the account.
Financial messages have a settlement impact. No exchange of clearing file is done after this.
There should be an authentication parameter in the request.
Note: For financial request message PIN (DE 52) is mandatory as an authentication parameter.
Financial request message without PIN will be declined with acquirer compliance and will not
be forwarded to issuer. The exception to this is non-secure E-Commerce transaction.
4.2.2 Message Type Identifier for Financial Message

Financial Request – 0200
Financial Response – 0210
Financial Advice Request – 0220
Financial Advice Response – 0230
4.3 File Update Message

4.3.1 Description of File Update Message
File update message is an issuer generated message. File update message is used to update the
cardholder records in NPCI database for negative list. This message will enable performing a
STIP authentication on behalf of the issuer.

Message Definition Reversal Message
4.3.2 Message Type Identifier for File Update Message

File update message request – 0302
File updates message response – 0312
4.4 Reversal Message

4.4.1 Description of Reversal Message
This message reverses the action of a previous authorization. It notifies NPCI Host and/or the
issuer of an error condition regarding an earlier financial transaction if:
 An approved transaction is cancelled at the POS or ATM device.

 Acquirer does not receive a response to a financial request.
 Acquirer cannot send an approved response to the POS or ATM device.
If, for any reason, these messages cannot be immediately delivered to their intended
destination, acquirer or NPCI stores these messages in SAF and forwards them to the intended
destination when communication is re-established with the appropriate destination processor.
NPCI treats all reversal messages as reversal advice messages. Acquirer needs to send 0420
message to NPCI and NPCI will forward the same to the Issuer. Issuer needs to respond with a
0430 message. NPCI generates reversals only for time-out cases for issuer responses. NPCI will
also generate reversal, if the response from issuer fails for format validation or issuer fails to
respond within the allowed time limit. It is important to mention that a reversal always needs to
be acknowledged and the response code in the reversal response 0430 message is ignored at
NPCI. If any response comes for 0420 message from the Issuer, NPCI treats that the reversal is
completed and the same is not be forwarded again, removed from SAF and take the affect in
settlement.
Acquirer can generate reversal up to next 72 hours (3 cut over cycles). If a reversal is generated
after next 72 hours then NPCI will not validate the same will not be processed at NPCI.
4.4.2 Message Type Identifier

Reversal Message Advice – 0420
Reversal Message Advice Response – 0430
4.5 Network Management Message

4.5.1 Description of Network Management Message
This message is used to communicate with the NPCI. These messages can be initiated either by
members or by NPCI. These messages are used to communicate that the member is available for
processing transactions. They may also be used for other purposes such as validation of the
availability of the host session in case of low or no transaction traffic in the session, etc.
Network messages communicate with NPCI for the scenarios mentioned below.

Message Definition Network Management Message
4.5.2 System Sign-On and Sign-Off

 Either party (NPCI or Bank) can initiate a “sign-on” or “sign-off” message to establish or
close the host session.
 Once a session has been closed (signed-off), the session should be re-established (sign-
on) by the party that closed the session.
 Neither system shall attempt to automatically re-establish a session that has been
“signed-off” by the other party.
 Either party may “sign-off” a session regardless of who initially started (signed-on) the
session.
 Bank/NPCI can either originate or receive 0800 sign-on /sign-off message (bit 070 =
001 / 002).
 A 0810 request response message must acknowledge the 0800 request message.
It’s the member’s responsibility to generate sign-on (0800) message to establish connectivity to
NPCI. Member banks also have to support sign-on message sent by NPCI and respond accordingly.
4.5.3 Cutover Message

 NPCI will issue cutover message (0800 message with net code=201 in DE70) at 23:00
hour indicating a business date change for both SMS & DMS transactions NPCI cut off
time indicates the new settlement date is considered for transactions after cutover for
SMS transactions.
 The member needs to respond to the cutover message. In the event that a member does
not respond to the cutover message, NPCI will impose a forced cutover.
4.5.4 Echo Message

 Either party can send an echo message (0800 DE 70=301) to the other party.
 The receiving party will respond to the echo message (0810 DE 70=301).
 These echo messages are used to validate the availability of the host session in case of
low or no transaction traffic in the session.
 Member banks and NPCI will also generate Echo message (0800 message type) to keep
alive during no transaction time. Ideal duration for the same should be 3 minutes (180
seconds).
 NPCI will keep generating echo messages at regular intervals only if no transaction
processed on the node.
 Banks must generate the echo message every 3 minutes (180 seconds) if no transaction
is processed on the network during the duration.
4.5.5 Message Type Identifier for Network Management Message

 Network Management Request – 0800
 Network Management Response – 0810

Message Definition Advice Message
4.6 Advice Message

4.6.1 Description of Advice Message
 This is a message that is from point to point i.e. from terminal to acquirer, from acquirer
to network, from network to issuer, with transmission guaranteed over each link, but
not necessarily immediately.
 It is a message which cannot be rejected i.e. needs an acknowledgement at the
minimum.
 Queued and Stored in a SAF(Store And Forward)
 When an advice message is forwarded from Acquirer/NPCI to any destination and if an
advice message is not delivered immediately due to some communication failure to the
receiving entity then the advice message is stored in their appropriate SAF and is
delivered to the destination when communication is re-established.
4.6.2 Message Type Identifier for Advice Message

 Reversal advice request – 0420
 Reversal advice response – 0430
 Authorization advice request – 0120
 Authorization advice response – 0130
 Financial Advice Request – 0220
 Financial Advice Response – 0230

NPCI System Functionalities Data Communication
Chapter 5 NPCI System Functionalities

5.1 Data Communication
NPCI can only communicate with member banks using Transfer control protocol. Transfer
control protocol contains the message length of 2 bytes binary excluding header length.
Member Systems will connect to NPCI system using persistent socket connections.
Member will act as client and NPCI will act as server.
Member will be responsible to generate the sign-on (0800 message type) message after every
successful TCP socket connection.
Member must fine tune its timers so that every disconnection is followed by connect request
without any delay.
5.2 Message Logging at NPCI

NPCI can do message logging at TCP level, Host-to-Host level and all the internal core module
levels. NPCI can also enable logging at module.
5.3 Key Security and Management

Within the NPCI environment, security considerations include measures for ensuring message
security and integrity, as well as protection against disclosure of cardholder personal
identification number (PIN). The NPCI central switch uses secure PIN encryption to protect all
PINs.
In POS and ATM transactions, all PINs must be encrypted at the point of entry using the triple
DES (3DES) algorithm in the ANSI PIN block format 0 which is equivalent to ISO PIN block
format 0. The PIN will remain encrypted until the issuer receives it for verification. The NPCI
central switch must receive the PIN encrypted with the ANSI PIN block format 0 or ISO PIN
block format 0.
Members must execute all PIN encryption, translation, and decryption for the POS/ATM
transaction using hardware encryption through physically secure devices. Both the host and the
point of entry must use hardware security module.
Key exchange is a service that enables member banks to change working keys that are used to
protect cardholder PINs via online messages.
To utilize this service, members must obtain a Zone Master Key (ZMK). A ZMK is a key exchange
key. Members use a ZMK for encrypting the working key when they convey it in an online
message. A ZMK is used to protect a Zonal Pin Key (ZPK). ZPK is different for both an issuer and
an acquirer.
The key exchange service makes it practically convenient to change PIN encryption keys
frequently, thereby increasing the security of the payment system and reducing the chances of

NPCI System Functionalities Static Key Exchange
key compromise. There are two types of PIN encryption keys: Acquirer ZPKs and Issuer ZPKs.
NPCI and an acquirer would share one ZPK and NPCI and issuer would share another ZPK.
Acquirers use their ZPK to encrypt the PIN while sending a message to NPCI. NPCI uses the
issuer ZPK to encrypt the PIN when it sends the message to the issuer.
Key exchange messages are used to exchange ZPK between members. ZPK Key exchange can be
accomplished in two ways: i.e. static and dynamic modes as configured for respective members.
5.4 Static Key Exchange

In case of static mode, the Zonal PIN key is encrypted under Zonal Master Key and shall be sent
to bank nominated custodians and the bank is expected to enter those keys manually into their
system. These keys shall remain constant throughout the period for which the member bank is
connected to NPCI on static key mode.
5.5 Dynamic Key Exchange

In case of dynamic keys the ZPK shall be changed on a periodic basis through a message
exchange between Bank’s system and NPCI system automatically.
Two ways of dynamic Key exchange is envisaged. One is to have the master send the key update
message and slave updating the key directly. The other way is to have the slave request for a
new key and master shall send a new key in response which slave can update.
Note: In the current implementation NPCI will always send the key to members and members
cannot request for key exchange.
Two ways of key exchange are described below:
 Master directly sends the new key to the slave and the slave updates and responds back.
 Slave can request a new key and master will send a new key to the slave.
5.5.1 Master Sends a New Key

New Key
1 Sent
Master key Slave key

processor processor
New Key
2
Accept
Figure 4 Master Send a New Key
1. NPCI will act as a master and will send a new key message (0800 DE 70=184) which will
be the single key used for inbound and outbound messages.

NPCI System Functionalities Key Exchange Scenarios
2. The new key details along with key check value will be sent in DE 48 and the key is
encrypted. The participant bank should decrypt the new ZPK key using the ZMK and
store into their switch and should respond back to NPCI with 0810 message with
response code as “00” along with DE70=184.
Note: In the event of slave not responding successfully for the key change request, Master will keep
processing the transaction with the current key.
5.5.2 Slave Send a New Key
Key change request

from 1
slave
Key change respone

2 from
master
Master key Slave key

processor processor
New key
3 request
New key 4
response
Figure 5 Slave Sends a New Key
1. Participant bank can send a new key request message 0800 with DE70 = 164 to NPCI.
2. If the key request is accepted, NPCI will respond to the participant bank with 0810
response having the response code as “00” with DE70 = 164.
3. NPCI will generate the new key and send the new key in (0800 bit 70= 184) request
message which will be single key used for inbound and outbound messages.
4. The new key details will be sent in DE48 and key encrypted value under ZMK and key
check value. The participant bank should decrypt the new ZPK key using the ZMK and
store into their switch and should respond back to 0810 message with response code as
“00” along with DE70=184.
Note: In the current implementation NPCI will send the key change message to members who have
opted for the same. Members will not be allowed to ask for key change request.
5.6 Key Exchange Scenarios

NPCI will generate key exchange on the following scenarios:
 Key request from the member bank: Member bank can initiate key exchange either on
ad hoc basis or after a definite time interval. Once the request from the member bank is
accepted, NPCI will initiate new key exchange. This facility will not be provided to
members currently.
 Specific time interval: A new key can be generated after a specific time interval. The
suggested time interval is 24 hours. Only NPCI may initiate this key exchange.

NPCI System Functionalities PIN Encryption / Decryption Process
 Specified usage count of key: A new key can be generated on the basis of the specific
usage count of a particular key. Only NPCI may initiate this key exchange.
 On consecutive key sync errors: A new key can be generated after a specified number of
consecutive key synchronization errors. Only NPCI may initiate this key exchange
5.7 PIN Encryption / Decryption Process

 Cardholder enters PIN at point of entry.
 The terminal encrypts the PIN in hardware and sends it to the acquirer’s host.
 The acquirer’s host receives the encrypted PIN, which is then decrypted in hardware.
The acquirer host system then encrypts it in hardware under a different key (Acquirer’s
ZPK) that the acquirer and the NPCI share.
 The NPCI central switch then receives the newly encrypted PIN.
 The NPCI central switch performs PIN translation.
 The issuer decrypts the PIN using the issuer’s ZPK key and verifies that the PIN is valid.
5.8 Time-Out Management

There are different timeout scenarios in a transaction life cycle and as a central switch, NPCI is
expected to manage the timeout scenarios of the transaction in various stages.
 NPCI shall maintain the timer at the issuer end such that the timer will start ticking after
the transaction is sent to issuer node. This timer shall be applicable to all the messages
sent to issuer.
 Acquirer and NPCI are expected to generate reversal after the expiry of timeout as
mentioned in chapter 6 Member Responsibilities.
 In case the reversal or advice is originated by acquirer and acknowledgement is not
received from the issuer within the timeout period, NPCI shall store the advice in SAF
and the SAF shall be cleared from the system as and when the other host is online and is
ready to accept SAF advises. In case of SAF timing out, it will be retried for 3 times
before getting purged and the affect taken into settlement.
NPCI can set parameter in such a way that issuer member bank node can be set to offline on the
basis of consecutive number of messages timed out.
5.9 Liquidity Management Module

 To keep control on transactions from the Member bank, NPCI wants to keep upper limit
on the transaction received from the Member bank. Using this provision NPCI can keep
control on transactions from member bank. The upper limit is always total of
transaction amount. Member bank can allow transactions equal to or less than the total
of transaction amount i.e. upper limit maintain at NPCI end.
 The upper limit of member bank is always decided by banks.
 This upper limit is always for the issuer transactions and not for the acquirer
transactions.
 At NPCI end, NPCI always maintain cumulative amount and Upper limit amount of
member bank. At the beginning cumulative amount of member bank is always zero.

NPCI System Functionalities Matching Criteria – Key Data Fields
 When NPCI receives an authorization (DMS) or a financial transaction (SMS) from the
member bank as acquirer, and before routing the transaction to the issuer, LMM module
adds transaction amount to the cumulative amount of issuer and compare with upper
limit amount.
 If the cumulative amount is greater than upper limit of member bank, LMM module will
decline the transaction with specific response code decide by NPCI.
 If the cumulative amount is less than upper limit of member bank, LMM module will
allow the transaction for the member bank.
 If the cumulative amount is equal to upper limit of member bank, LMM module will
allow the transaction for the member bank.
 Product wise limit checking is carried out i.e. ATM, POS, AEPS, and IMPS separately.
 Limits for ATM, POS, AEPS, and IMPS are maintained separately. International
transactions are included.
 The limits for ATM, POS, AEPS, and IMPS are always reset at 23:00 hrs. The limit for POS
is always reset at 03:00 hrs.
5.10Matching Criteria – Key Data Fields

To achieve transaction matching of the response to the request, following data elements would
be used:
1. Primary account number (DE2)

2. STAN (DE 11)
3. Acquirer Id (DE 32)
4. Retrieval reference number (DE 37)
5. Terminal ID (DE 41)
Note: Any error in matching field will result in message reject. As per the MTI further action will be
initiated as mentioned below:
 For an advice messages (0x2x messages) NPCI will continue sending the repeat advice for
three times.
 For an authorization response message or financial response (0110/ 0210 message), a
reversal message (0420 message) would be sent to issuer and a declined message
(0110/0210) to acquirer after timeout.
 NPCI will not check duplicate transactions at its own end and will route the message.

Member Responsibility Issuer Responsibility
Chapter 6 Member Responsibility

6.1 Issuer Responsibility
response message. NPCI system compares information in key data fields to match messages in a
transaction set. Message matching is one of the most important concepts in NPCI transaction
processing.
This section defines identifies key data fields for message matching and various responsibilities
of the issuer.
Key data fields enable NPCI system to match a response to the message initiator’s request. They
also enable NPCI system to associate a subsequent request or advice (and its responses) with
the original request message.
6.1.1 Message Supported by Issuer

The below table describes message which needs to be supported by issuer for RuPay interface.
MTI Description Implemented by

Send Receive
0100 Authorization request  
0110 Authorization response  
0120 Authorization advice and repeat  
0130 Authorization advice response  
0200 Financial request  
0210 Financial response  
0220 Financial advice request  
0230 Financial advice response  
0302 File update message request  
0312 File update response  
0420 Reversal advice and repeat  
0430 Reversal advice response  
0800 Network management request  
0810 Network management response  
Table 11 Message Supported by Issuer
6.1.2 Maximum Response Time

After receiving transaction from NPCI issuer has to respond back within 15 seconds.
6.1.3 Authorization Cycle and Failure Condition Involving Issuer

6.1.3.1 Authorization normal completion
The below diagram depicts normal completion of a transaction.

0100/0200 0100/0200
1 2
NPCI
Acquirer Issuer
0110/0210 4 0110/0210 3
Figure 6 Authorization Normal Completion
 The acquirer initiates an authorization request/ financial request message to NPCI.

 NPCI forwards the authorization request/financial request to the issuer.
 The issuer performs the transaction validation set proper response code and generates
an authorization response/financial response and sends it to NPCI within NPCI’s time-
out period.
 NPCI forwards the authorization response/financial response message to the acquirer
within acquirer’s time-out period.
6.1.3.2 Failure Conditions

Following are the failure conditions involving Issuer:
A. Message validation failure at NPCI for an issuer response
B. System failure during issuer authorization request/ financial request
C. System failure during issuer authorization response/ financial response
D. Late response from issuer
6.1.3.3 Message Validation Failure at NPCI for an Issuer Response

0100/ 0200 0100/0200
1 2
NPCI
0110/0210
3
0110/0210
4
Message Validation
Failure 5 0420
Acquirer Issuer
0430 6
Figure 7 Message Validation Failure – NPCI
1. The acquirer initiates an authorization request/ financial request message to NPCI.

2. NPCI forwards the authorization request/ financial request to the issuer.

3. The issuer performs the validation set proper response code (DE39=00/approved) and
generates an authorization response/financial response and sends it to NPCI.
4. After receiving of authorization response/ financial response, NPCI will validate
response and if it fails then the transaction will be logged as compliance declined with
response code as ‘CI’ (Issuer compliance). If the issuer authorization was successful
(response code=00), then NPCI will initiate reversal and put it into SAF.
5. NPCI sends a response message to the acquirer indicating a request denial, if the issuer
transaction authorization response fails at NPCI due to message validation failure.
6. NPCI sends a reversal advice message to the issuer with response code `CI’.
7. And the issuer responds with a reversal advice response.
Note:-In this case acquirer will not generate a reversal to NPCI. NPCI will respond to acquirer with
response code 91 (In case of message validation failure in DE2, DE 11, DE 32, DE37, DE 41) .NPCI
will generate the reversal towards issuer with response code-CI only if the authorization is
successful and populate DE 44 with reject reason code of response message (In case Issuer not
sending DE 38/DE 39 /Format error in DE 38 or DE 39/DE 39 not from the table as defined in DE
39 description in chapter “Data Elements Description”). It must be noted by the issuer that it may
get multiple reversal for the transaction and it is issuer’s responsibility to verify the reversal before
posting the same into customer account.
6.1.3.4 System Failure during Authorization Request/ Financial Request to

Issuer
0100/ 0200
1
NPCI
0100/0200
2
Cannot be
forwarded Failure
0110/0210 3
Acquirer Issuer
Device
No Reversal
5
Generated
Figure 8 System Failure – Authorization Request/ Financial Request

2. NPCI attempts to forward the authorization request/ financial request message to the
issuer but is unable to complete the message transmission due to a failure or other
problem such as no connection with issuer or issuer station is signed off.
3. NPCI will generate an authorization request response/ financial response message to
the acquirer, indicating a request denial. Acquirer will not generate a reversal for this
transaction
Note: NPCI will respond to Acquirer with response code 91. Acquirer will not generate reversal for
the same.

6.1.3.5 System Failure during Authorization Response/ Financial Response

from Issuer
0100/0200 0100/0200
1 2
NPCI
4 0110/0210
Time-Out 3
Failure
0110/0210 5
6
Acquirer Issuer
7 0420
SAF
0430 8
Figure 9 System Failure – Authorization Response/ Financial Response
1. The acquirer initiates an authorization request/ financial request and sends this to NPCI.
2. NPCI forwards the authorization Request/ financial request message to the issuer.
3. The issuer cannot return the authorization response / financial response message to
NPCI due to a communication failure between the issuer and NPCI.
4. NPCI detects a timeout condition for the expected message i.e. authorization request
response / financial response.
5. NPCI generates an authorization response/ financial response message and sends it to
the acquirer indicating a request denial response code 91
6. NPCI creates a reversal advice message indicating that no authorization transaction
request response/ financial response message was received. This message is placed in
the SAF for later delivery to the issuer.
7. When connection is established NPCI sends a reversal advice message to the issuer.
8. The issuer responds with a reversal advice response message.
Note: NPCI will respond to acquirer with response code 91. Acquirer will not generate reversal for
the same. NPCI will send reversal to Issuer with response code 91. It must be noted by the issuer
that it may get multiple reversal for the transaction and it is Issuer’s responsibility to verify the
reversal before posting the same to customer account.

6.1.3.6 Late Response from Issuer

0100/0200 0100/0200
1 2
NPCI
3
Time-Out
0110/0210 4
5
Acquirer Issuer
0420
6
0110/0210
SAF 7
0430 8
Figure 10 Late response from issuer
1. The acquirer initiates an authorization request/ financial request and forwards this to
NPCI.
2. NPCI forwards the authorization request/ financial request message to the issuer.
3. NPCI detects a timeout condition on the authorization response/ financial response
message that are expected from the issuer.
4. NPCI generates an authorization request response/ financial response message to the
acquirer, indicating a request denial response code 91.
5. NPCI also creates an acquirer reversal advice/ message with response code 91
indicating that no authorization response/ financial response message was received.
This message is placed in the SAF file for later delivery to the issuer.
6. NPCI sends reversal advice message to the issuer.
7. NPCI receives a late response from the Issuer and NPCI will reject the same.
8. The issuer responds with a reversal advice response message.
Note: NPCI will respond to acquirer with response code 91. Acquirer will not generate reversal for
the same. NPCI will send reversal to Issuer with response code 91. It must be noted by the issuer
that it may get multiple reversal for the transaction and it is Issuer’s responsibility to verify the
reversal before posting the same to customer account.
6.1.4 Stand-in functionality

 NPCI network system can authorize the transactions on the behalf of issuer when
issuer’s system is not available due to hardware, software or communication failure
 Stand-in facility will not be available for PIN based product.
 Stand-in facility will not be available for e-commerce transaction.
 System shall be set up to support stand in functionality for BINs issued/allotted by NPCI.
NPCI will maintain negative file which contains hot listed cards.
 Transactions shall be authorized in stand in mode either in dynamic mode or static
mode with CVD checking. Member bank has to share CVD keys for opting STIP.
 NPCI will not perform actual expiry date validation in stand-in mode. The expiry date
received in Track II or Track I or in DE14 of ISO message will be checked with system
date of NPCI. If the received expiry date (YYMM) is greater than the system date

(YYMM), the card will be treated as non-expired otherwise the card will be treated as
expired and NPCI will reject the transaction as expired card in stand-in mode is not
allowed.
 Dynamic mode stand-in: In dynamic mode, the authorization transaction is timed out by
the issuer NPCI system would stand in for issuer and authorize the transaction based on
limit configured for the particular BIN with CVD checking.
 Static mode stand-in: In case of static mode, stand in functionality can be activated based
on the request made by the member bank as and when required however member bank
should have subscribed to this functionality at the time of BIN set up.
 The limit based Stand-In would be maintained bin wise in the system and before
authorizing a transaction, negative file (consisting of cards, MCC etc.) will be checked.
 Separate limits for purchase and cash in STIP.
 Support for MCC based limit within the overall limits in STIP.
 Count on number of transactions and transaction restriction in STIP.
 For Pin based transactions whether it is SMS or DMS STIP will not be carried out.
 Stand-in functionality can be activated under three conditions as follows:
 Stand in Processing, Late Response from issuer (NPCI Stand In). This is dynamic
mode stand-in.
 Stand-In Processing, No Response from Issuer (NPCI Stand In). This is dynamic
mode stand-in.
 Stand-In Processing, Node offline or member bank signed off. This is static mode
stand-in.
6.1.4.1 Stand in Processing, Late Response from Issuer (NPCI Stand In)
The following figure illustrates the Processing for a late Issuer Authorization Response message.
This example assumes that the Issuer has subscribed to NPCI Stand-In processing service.
0100/0200 0100/0200
1 2
NPCI
3
Time-Out
0110/0210 Stand
5
In
Acquirer Issuer
6 0110/0210
7
0120/0220
8
0130/0230 9
SAF
Figure 11 Stand-in Processing, Late Response from Issuer
1. Acquirer forwards the authorization request/ financial request to NPCI.

2. NPCI routes the authorization request/ financial request message to the issuer.
message that are expected from the issuer.

4. If the issuer processor is configured for stand-in processing at NPCI, then NPCI service
validates the request and formulates an internal response message.
5. NPCI uses the internal response to create an authorization response/ financial response
message and sends it to the acquirer.
6. A record of the authorization advice request/ financial advice request message is placed
in the SAF file of NPCI for later delivery to the issuer.
7. Now NPCI receives a late authorization response/ financial response from the issuer.
NPCI will decline the late response as the transaction is already processed in stand-in
mode.
8. When connection is established NPCI sends an authorization advice request/ financial
advice request message to the issuer. Now before taking any action on SAF message
issuer has to check whether original transaction is already processed. If it is already
processed then issuer can ignore SAF message.
9. The issuer responds with an authorization advice response/ financial advice response
message.
Note: NPCI will not generate a reversal where stand-in is applicable. NPCI will send successful
response code i.e. 00 to acquirer in a response message authorized in stand-in. For successfully
authorized transaction in stand-in, NPCI will send 0120/0220 with response code 00 and DE 60
populated with 1002 to issuer. For transaction not authorized in stand-in NPCI will send declined
response code to acquirer and no advice will be issued to issuer. At the cut-over NPCI will generate
SAF report (which will contain successful and failed transactions) and will be available to issuer.
6.1.4.2 Stand in Processing, No response from issuer (NPCI Stand In)

The following figure illustrates the stand-in processing for an authorization request for which
an issuer sends no response.
0100/0200 0100/0200
1 2
NPCI
3
Time-Out
0110/0210 Stand
5
In
Acquirer Issuer
6
0120/0220
7
0130/0230 8
SAF
Figure 12 Stand-in Processing, No Response from Issuer
1. Acquirer initiates an authorization request/ financial request message to NPCI.

2. NPCI forwards the authorization request/ financial request message to the issuer.
message that is expected from the issuer.
4. If the issuer processor is configured for stand-In processing at NPCI, then NPCI service

in the SAF file of NPCI for later delivery to the issuer.
7. When connection is established NPCI sends an authorization advice/ financial advice
message to the issuer. Now before taking any action on SAF message issuer has to check
whether original transaction is already processed. If it is already processed then issuer
can ignore SAF message.
8. The issuer responds with an authorization advice response/ financial advice response
message.
Note: NPCI will not generate reversal wherever stand-in is applicable. NPCI will send successful
response code i.e. 00 to acquirer in a response message authorized in stand-in. For successfully
authorized transaction in stand-in, NPCI will send 0120/0220 with response code 00 and DE 60
populated with 1002 to issuer. For transaction not authorized in stand-in NPCI will send declined
response code to acquirer and no advice will be issued to issuer. At the cut-over NPCI will generate
SAF report (which will contain successful and failed transactions) and will be available to issuer
6.1.4.3 Stand-in Processing, Node Offline or Issuer Signed-off

The following figure illustrates the stand-in processing for an authorization request for which
an issuer node is signed-off:
0100/0200
1
NPCI
0110/0210 Stand
4
In
Acquirer Issuer
5
0120/0220
6
0130/0230 7
SAF
Figure 13 Stand-in Processing, Node Offline or Issuer Signed-off
1. Acquirer initiates an authorization request/ financial request message to NPCI.

2. NPCI detects issuer member bank is signed off or the node is offline.
3. If the issuer processor is configured for stand-in processing at NPCI, then NPCI service
in the SAF file on the NPCI for later delivery to the issuer.
6. When issuer member bank is in signed-on or issuer bank node is in processing state,
NPCI sends an authorization advice/ financial advice message to the issuer.
7. The issuer responds with an authorization advice response/0130 message.

Member Responsibility Acquirer Responsibilities
Note: NPCI will not generate reversal wherever stand-in is applicable. NPCI will send successful
response code i.e. 00 to acquirer in a response 0110 message authorized successfully in stand-in.
For successfully authorized transaction in stand-in, NPCI will send 0120/ 0220 with response code
00 and DE 60 populated with 1001 /1002 to issuer. For transaction not authorized in stand-in
NPCI will send declined response code to acquirer and no advice will be issued to issuer. At the cut-
over NPCI will generate SAF report (which will contain of successful and failed transaction) and
will be available to issuer. Irrespective of node offline or member bank signed off or late response
from issuer, if issuer member bank receives 0120/ 0220 message it should always check for
duplicate processing before posting the same to customer account.
6.2 Acquirer Responsibilities

response message. NPCI system compares information in key data fields to match messages in a
transaction set. Message matching is one of the most important concepts in NPCI transaction
processing.
This section defines identifies key data fields for message matching and various responsibilities
of the acquirer.
Key data fields enable NPCI system to match a response to the message initiator’s request. They
also enable NPCI system to associate a subsequent request or advice (and its responses) with
the original request message.
6.2.1 Message Supported by Acquirer

MTI Description Implemented by
Send Receive
0100 Authorization request  
0110 Authorization response  
0200 Financial request  
0210 Financial response  
0420 Reversal advice and repeat  
0430 Reversal advice response  
0800 Network management request  
0810 Network management response  
Table 12 Message Supported by Acquirer

6.2.2 Maximum Response Time for Acquirer

Acq starts NPCI starts
1 Timer=20 sec
2 Timer=15 sec
NPCI
Acquirer NPCI to switch Issuer

Transaction
in<=1 sec
3
Device
Host
<=3 Seconds
5 4
Figure 14 Maximum Response Time for Acquirer
1. The acquirer system delivers an authorization transaction request to NPCI and acquirer
starts the timer for 20 sec.
2. NPCI delivers this transaction request to the issuer and NPCI starts the timer for 15 sec.
3. The issuer system does the validation and generates a response and sends this response
to NPCI in ≤ 15 seconds.
4. NPCI will send this response to the acquirer system.
5. The acquirer switch will deliver this transaction to the POS terminal in ≤ 3 seconds.
Note: The acquirer is expected to keep the time out of transactions as 20 sec, NPCI will keep the
issuer time out parameter as 15 sec and it is the responsibility of issuer to respond to all
transaction within 15 sec.
6.2.3 Authorization Cycle and Failure Conditions Involving Acquirer

6.2.3.1 Authorization Normal Completion
0100/0200 0100/0200
1 2
NPCI
Acquirer Issuer
0110/0210 4 0110/0210 3
Figure 15 Normal Completion of an Authorization Message/ Financial Message

2. NPCI forwards the authorization request/ financial request to the Issuer.

3. The issuer performs the transaction validation set proper response code and generates
an authorization response/ financial response and sends it to NPCI.
4. NPCI forwards the authorization response/ financial response message to the acquirer.
6.2.3.2 Failure Conditions

Following are the failure conditions involving acquirer:
1. System failure during acquirer authorization request/ financial request where acquirer
is aware of the failure.
2. System failure during acquirer authorization request/ financial request where acquirer
is unaware of the failure.
3. Validation failure at NPCI for acquirer message.
4. Acquirer is unable to complete a transaction due to the terminal failure.
5. System failure during NPCI (Unaware) authorization response/ financial response.
6. System failure during NPCI (Aware) authorization response/ financial response.
6.2.3.3 System Failure Acquirer Authorization / Financial Request (Acquirer

Aware)
1
NPCI
Failure
Acquirer Issuer
Device
Figure 16 System failure - Acquirer Aware - Authorization / Financial Request
1. The acquirer initiates an authorization request/ financial request but it cannot be

delivered to the NPCI because of the system failure at the acquirer’s end and acquirer is
aware of this failure.
2. The acquirer processing system therefore is not able to transmit the authorization
request/ financial request message to NPCI therefore the acquirer denies the
transaction request at the point-of-service.
Note: In this case acquirer does not need to generate a reversal to NPCI.

6.2.3.4 System Failure Acquirer Authorization / Financial Request (Acquirer

Unaware)
0100/0200
1
NPCI
Failure
Acquirer Issuer
Time-Out
2 SAF
Device 3 0420
0430 4
Figure 17 System Failure - Acquirer Unaware - Authorization / Financial Request
1. The acquirer initiates an authorization request/ financial request but it cannot be

delivered to the NPCI because of the system failure and acquirer is not aware of this
failure.
2. Acquirer detects a timeout condition for the authorization response/ financial response
that is expected from the issuer and denies the transaction request at the point-of-
service.
3. Acquirer generates a reversal advice message and sends it to NPCI. The reversal will be
full reversal.
4. NPCI sends the reversal advice response to the acquirer and does not forward the
reversal message to Issuer.
Note: Acquirer will send the reversal to NPCI with response code 68. NPCI will check the reversal
advice from the acquirer for matching with the original transaction, and in case if the original
transaction is not present; NPCI will not forward the reversal advice request to the issuer.
6.2.3.5 Validation Failure at NPCI for Acquirer Message

NPCI
1 0100/0200
Message
Validation
Failure
Acquirer Issuer
0110/0210
2
Figure 18 Message Validity Failure at NPCI - Authorization / Financial Request

2. NPCI validates the message and detects error in the message. In this case NPCI will
respond with a response message to the acquirer with declined response code
indicating format error as `CA’ (Acquirer Compliance)and DE44 will contain the reject
reason code
Note: The response code for his condition will be CA Acquirer will not generate reversal for this
case. In case NPCI is not able to make a response message because of the format error, in
mandatory data elements acquirer will generate a reversal with response code 68. This needs to be
handled by operations team.
6.2.3.6 Acquirer Unable to Complete a Transaction due to the Terminal

Failure (POS)
The following figure illustrates the failure condition that arises when an acquirer is unable to
complete a transaction due to the terminal failure.
0100/0200 NPCI
1 0100/0200
2
0110/0210 3
0110/0210
4 Issuer
Acquirer
SAF
5 Failure
Device 6 0420
7 0420
0430 8
0430 9
Figure 19 Incomplete Transactions in case of Terminal Failure

2. NPCI forwards the authorization request/ financial request to the issuer.
3. The issuer performs the validation, and generates an authorization response/ financial
response and sends it to NPCI.
4. NPCI forwards the authorization response/ financial response message to the acquirer
with response code 00.
5. The acquirer determines the transaction cannot be successfully completed due to some
problem at the POS.
6. Now acquirer generates a reversal advice message and sends it to NPCI. The reversal
amount will be entirely of the original transaction.
7. NPCI forwards the acquirer reversal advice message to the issuer.
8. The Issuer responds with an acquirer reversal advice response message. Now the issuer
updates the cardholder account.
9. NPCI responds with a reversal advice response message to acquirer.
Note: The acquirer will generate reversal with response code 22 indicating a full reversal. The
Issuer will respond with response code 00 in the reversal advice response. It must be noted by the
issuer that it may get multiple reversal for the transaction and it is issuer’s responsibility to verify

the reversal before posting the same into customer account. As mentioned in above if the
authorization response/ financial response is successful (`00’) then only acquirer should initiate a
reversal to NPCI.
6.2.3.7 System Failure NPCI (Aware) Authorization /Financial Response
0100/0200 NPCI
1 0100/0200
2
0110/0210 3
4 Issuer
Acquirer
Failure
Time-Out
Device 5 0420
6 0420
0430 7
0430 8
Figure 20System Failure - NPCI Aware - Authorization / Financial Response

3. The issuer performs the validation, set proper response code and generates an
authorization response/ financial response and sends it to NPCI.
4. NPCI forwards the authorization response/ financial response message to the acquirer,
but the message fails to reach the acquirer. It fails such that NPCI is aware of a delivery
problem.
5. The acquirer sends a reversal advice message to NPCI.
6. NPCI forwards the reversal advice to Issuer.
7. Issuer responds to the reversal advice with reversal advice response.
8. NPCI forwards the reversal advice response to acquirer.
Note: It is the responsibility of acquirer to generate the reversal for all acquirer time-out cases. In
the event of acquirer not generating the reversal the transaction may be settled as per the
response code. The acquirer will generate the reversal with response code 68 indicating acquirer
timeout. The issuer will respond with response code 00 in the reversal advice response. It must be
noted by the issuer that it may get multiple reversal for the transaction and it is issuer’s
responsibility to verify the reversal before posting the same into customer account.
6.2.3.8 System Failure NPCI (Unaware) Authorization / Financial Response

The following figure illustrates the failure condition that arises when NPCI is unable to complete
a transaction.

0100/0200 NPCI
1 0100/0200
2
0110/0210 3
0110/0210
4 Issuer
Acquirer
Failure
Time-Out
SAF
5
Device 6 0420
7 0420
0430 8
0430 9
Figure 21 System Failure - NPCI Unaware - Authorization / Financial Response

3. The issuer performs the validation, sets proper response code and generates an
authorization response/ financial response with response code 00 and sends it to NPCI.
4. NPCI forwards the authorization response/ financial response message to the acquirer,
but the message fails to reach acquirer. It fails such that NPCI is not aware of a delivery
problem.
5. The acquirer detects a timeout and acquirer generates a reversal advice message.
6. Acquirer sends the reversal advice message to NPCI.
7. NPCI forwards the reversal advice to issuer.
8. Issuer responds to the reversal advice with reversal advice response.
9. NPCI forwards the reversal advice response to acquirer.
Note: The acquirer will generate the reversal with response code 68 indicating acquirer-timeout.
The issuer will respond with response code 00 in the reversal advice response. It must be noted by
the issuer that it may get multiple reversal for the transaction and it is issuers’ responsibility to
verify the reversal before posting the same into customer account.

6.2.4 Advice message scenarios for acquirer

6.2.4.1 Advice message normal completion
1 0120/
0220/ 0420
0120/
2 0220/ 0420
NPCI
Acquirer 0130/ 0230 Issuer

3
0430
0130/ 4
0230/ 0430
Figure 22 Advice Messages getting Completed Normally
1. The acquirer initiates an advice/0120/0220/0420 message to the NPCI.

2. NPCI forwards the advice message to the destination.
3. The issuer returns an advice response/0130/0230 /0430 message to NPCI that it has
received the advice message.
4. NPCI forwards advice response /0130/0230 /0430 to the sender.
6.2.4.2 Advice Delivery from Acquirer following Timeout

0120/ 0220/ 0420
1
Time-Out NPCI
Issuer
0120/
0220/ 0420 0120/
2 0220/ 0420
3
SAF
0130/ 0230
0130/ 0430 4
Remove Advice
0230/ 0430
from 5
SAF
Figure 23 Advice Delivery Crossing Time Limits
1. An acquirer generates an advice/0120/0220 /0420 message. If it cannot be transmitted

within the acquirer’s timeout values, it is stored in the acquirer’s Store-and-Forward
(SAF) facility.
2. When communication is re-established, SAF of acquirer forwards the advice/0120/0220
/0420 message to NPCI.
3. NPCI forwards the advice request to the issuer.
4. Issuer responds to the advice with 0130/0230/0430 and sends the same to NPCI.
5. NPCI forwards the advice response to the acquirer.

6. Acquirer removes advice from its SAF.
Note: Acquirer can generate reversal up to next 3 cutover cycles. If a reversal is generated after
next 3 cutover cycles then NPCI will not send it to the issuer.

Message Format Transaction Identification
Chapter 7 Message Format

7.1 Transaction Identification
This section contains the Message Type Identifiers and specific field values that define the
various types of transactions supported by NPCI system.
Transactions Key Data Fields

POS purchase -Processing Code (DE 3) must indicate a purchase transaction.
Processing Code (DE 3) must be 00xxxx.
- Magnetic stripe data is required. Track 1 (DE 45) or Track 2
(DE 35) must be present.
POS purchase with PIN - Processing Code (DE 3) must indicate a purchase transaction.
- Magnetic stripe data is required. Track 1 (DE 45) or Track 2
(DE 35)
E-commerce purchase - Processing Code (DE 3) must indicate a purchase transaction.
-POS Entry Mode (DE 22) must indicate an E-commerce
Transaction. POS Entry Mode must be 81
- Tag 56 of Additional data (DE 48) must be present with
appropriate E-Commerce indicator value
- Tag 52 of Additional data (DE 48)must be present with CVD2
values in the request
- Tag 53 of Additional data (DE 48) must be present in the
response to indicate the CVD2 match result.
Loyalty Redemption - Processing Code (DE 3) must indicate a loyalty redemption
transaction. Processing Code (DE 3) must be 27xxxx.
- Tag 062 of Additional data (DE 48) should indicate loyalty
points for debit. The issuer is expected to debit the customer for
transaction amount and then credit the customer with the
amount equivalent to loyalty points redeemed.
Loyalty Inquiry - Processing Code (DE 3) must indicate a loyalty inquiry.
- Tag 063 of Additional data (DE 48) will be populated with
loyalty balance. Acquirer has to generate appropriate slip
showing loyalty points.
EMI - Processing Code (DE 3) must indicate an EMI transaction. Data
element 3 must be 14xxxx.
- Tag 059of Additional data (DE 48)will carry the details of
margin amount, number of instalments and EMI amount
Balance inquiry - Processing Code (DE 3) must indicate a POS or ATM balance
inquiry. Data element must be 31xxxx.
- The balance amount is returned in Additional amount (DE 54)
in the response.
Reversal - Processing Code (DE 3) must indicate a purchase or cash
transaction and it values must be 00xxxx, 01xxxx, 09xxxx,
14xxxx or 20xxxx
- Data element field 90 is required
- For reversal generating due to message reject by NPCI for
issuer, NPCI will generate reversal for issuer with response code

Message Format Transaction Identification
Transactions Key Data Fields

CI indicating data format error in the response code. Also, in the
reversal data element 44 will contain an appropriate reason
code for declining the authorization message
Purchase with Cashback - Processing Code (DE 3) must indicate Purchase with cashback.
- Amount transaction (DE 4) should contain the total amount of
the transaction i.e. the summation of cash amount and purchase
amount
- Additional amount (DE 54) should contain the cash component
of the transaction
Cash at POS -Processing Code (DE 3) must indicate Cash at POS. Processing
Code (DE 3) must be 01xxxx.
Refund Processing Code (DE 3) must indicate Refund. Processing Code
(DE 3) must be 20xxxx.
Mini Statement Processing code (DE 3) must indicate Mini statement. Processing
Code Code(DE 3) must be 90xxxx which is extended type
transaction and Private Data 3(DE 120) must have Transaction
Type (Tag 001) -07 (Mini Statement) which indicate the actual
processing code.
Pin Change Processing code (DE 3) must indicate Pin change. Processing
Code Code(DE 3) must be 90xxxx which is extended type
transaction and Private Data 3(DE 120) must have Transaction
Type (Tag 001) -08 (Pin change) which indicate the actual
processing code.
Cash Withdrawal Processing Code (DE 3) must indicate Cash Withdrawal.
Card To Card Funds Transfer Processing Code (DE 3) must indicate Card To Card Funds
Transfer i.e. 90XXXX and (DE 120) must have Transaction Type
(Tag 001-TC-credit to beneficiary, TD-Debit to beneficiary, and
Tag 001-FT-For inquiry about beneficiary) - which indicate the
actual processing code.
Biometric Verification Processing Code (DE 3) must indicate Biometric Verification.
Processing Code (DE 3) must be 100000.
Mobile Number Update Processing Code (DE 3) will have value 900000 and DE 120 Tag
001 as UR
Cheque Book Update Processing Code (DE 3) will have value 900000 and DE 120 Tag
001 as 36
Statement Request Processing Code (DE 3) will have value 900000 and DE 120 Tag
001 as 37
Table 13 Key Data Elements
7.1.1 Notations Used in Message Format

Following are the symbols used in different message formats.
Abbreviation Meaning
M Mandatory
M+ Mandatory, Echoed from the request
C Conditional
C+ Conditional, Echoed from request
C* Conditional, value changed by NPCI
O Optional

Message Format Message Format for Issuer
O+ Optional, Echoed from request
-- Not required
 Pass the data element (DE) and no change
A Alphabetical
B Binary data
N Numeric value
S Special character
X Character C / D to indicate credit / debit
Z Track data
an Alphanumeric
ans Alphanumeric with special characters
Table 14 Symbols used in Message Format
7.2 Message Format for Issuer

7.2.1 Current (Phase – I) Requirements
7.2.1.1 Purchase
The below table describes purchase message
DE Description 0100/0200 0110/0210

(NPCI  Issuer) (Issuer  NPCI)
1 Secondary bit map C C
2 Primary Account Number M M+
3 Processing Code M M+
4 Amount, Transaction M M+
5 Amount, Settlement C C+
6 Amount, card holder billing C C+
7 Date/time transmission M M+
9 Conversion rate, Settlement C C+
10 Conversion rate, card holder billing C C+
11 System trace audit number M M+
12 Time, local transaction M M+
13 Date, local transaction M M+
14 Date, expiry C --
15 Date, Settlement C C+
16 Date, conversion C C+
18 Merchant category code M --
19 Acquiring institution country code M M+
22 POS entry mode M --
23 Card sequence number C C+
25 POS condition code M --
28 Amount , Fee C C+
32 Acquiring institution code M M+
33 Forwarding institution code C C+
35 Track 2 data C --
37 Retrieval reference number M M+
38 Authorization code -- C
39 Response code -- M

DE Description 0100/0200 0110/0210

40 Service code C --
41 Card acceptor terminal ID M M+
42 Card acceptor ID M --
43 Card acceptor name / location M --
48 Additional data M M
48 Tag 051 Product code M M+
48 Tag 054 CVD/iCVD Match result code - M
48 Tag 058 Fraud Score M --
48 Tag 060 CHIP Transaction Authorization Indicator C --
48 Tag 066 UID Number (Aadhaar) O --
48 Tag 067 Income Tax PAN O --
48 Tag 074 Customer Telephone / Mobile Number O --
49 Currency code, transaction M M+
50 Currency code, settlement C C+
51 Currency code, card holder billing C C+
52 PIN data C --
55 Chip data C C
61 POS data code M --
62 Private data 1- Biometric Data C C+
102 Account Identification 1 -- O
120 Private data 3 C C
121 Private data 4 O O+
Table 15 Purchase Message – Issuer
For domestic transaction data element 4 will be in INR and it can be identified by DE 19 value
356 and DE 49 value 356..
For international transactions DE 4, DE 6, DE49 and DE 51 will be present. DE 4 will be in

respective international transaction currency (e.g. USD, GBP etc.) and DE 49 will carry
respective currency code (e.g. 840, XXX). Issuer need to block/ debit customer account by the
amount present in DE 6 which will be in INR. Issuer will identify international transaction from
DE 19 and DE 49 which will be other than 356.
Note: For SMS transactions which require surcharge and tips adjustments members can use SMS
Tip and Surcharge presentment in the clearing cycle.
7.2.1.2 Purchase with Cashback

The below table describes purchase with cash back message
DE Description 0100/0200 0110/0210

5 Amount, settlement C C+

DE Description 0100/0200 0110/0210

14 Data, expiry C --
28 Amount, fee C C+
52 PIN data C --
54 Additional amount M M+
55 Chip data C C
Table 16 Purchase with Cashback Message – Issuer
7.2.1.3 RuPay Implementation of E-Commerce Purchase (Secure / Non-

Secure)
E-Commerce transaction is a transaction that is originated at the merchant’s website. The table
below describes an e-commerce transaction.

DE Description 0100/0200 0110/0210

14 Date, expiry M --
28 Amount, fee C C+
48 Tag 052 CVD2 value M --
48 Tag 053 CVD2 match result -- C
48 Tag 056 ECI indicator M --
48 Tag 061 Transaction ID M --
48 Tag 071 IP address and Country Code/ International
Authorization Network Identifier O --
48 Tag 075 Image code M --
48 Tag 076 Personal Phrase O --
48 Tag 077 Issuer supplied ID / Unique ID O --
52 PIN data C --
102 Account Id 1 O O
120 Private data 3 -- O+

DE Description 0100/0200 0110/0210

Table 17 RuPay E-Commerce Message – Issuer
Note: STIP facility will not be available for E-commerce transaction.
7.2.1.4 E-Commerce 3D Purchase (Secure / Non-Secure)

DE Description 0100 (NPCI  0110 (Issuer 
Issuer) NPCI)
28 Amount, fee C C+
48 Tag 061 Transaction ID M --
48 Tag 057 ICS1 result code C C+
48 Tag064 ICS2 result code C C+
48 Tag 068 ICS1 value C --

DE Description 0100 (NPCI  0110 (Issuer 

Issuer) NPCI)
48 Tag 071 IP address and Country Code /International
Authorization Network Identifier / O --
102 Account Id 1 -- O
Table 18 E-Commerce 3D Message – Issuer
7.2.1.5 E-Commerce Refund

E-commerce Refund is a financial transaction originated at the merchant’s website that
instructs the issuer to credit the cardholders account for the return of goods, tickets etc. Refund
amount should be less than or equal to the amount of original purchase.
E-commerce refund is carried out as follows:
 E-commerce refund is carried out offline and not online. This essentially means that
refund transaction is to be processed only in clearing and settlement cycle.
 While a customer is doing an E-Commerce purchase, a Transaction Id is generated from
the merchant portal which gets stored in field 48. This transaction Id is unique to the
customer for the purchase made at the particular merchant portal.
 When a customer wants to do the Refund of the previous transaction, he needs to
request/select for refund.
 Once a customer initiates a refund, the merchant portal will provide the following
details to the Acquirer payment GW
 Transaction ID(mandatory)
 Original Transaction Date Time (Same as DE12 at acquirer end)
 Refund Amount
 Based on the above parameter acquirer will retrieve the original transaction and shall
ensure that the refund amount is less than original purchase amount. After all these
checks acquirer will generate a refund message for clearing cycle as described in NPCI
Clearing and Settlement manual.
 The issuer by seeing the presentment data will process the refund and credit the
customer’s account.
7.2.1.6 Cash at PoS

The flowing table describes Cash at PoS message
DE Description 0100/0200 0110/0210


DE Description 0100/0200 0110/0210

28 Amount, fee C C+
52 PIN data C --
55 Chip data C C
Table 19 Cash at PoS– Issuer
Note: NPCI will not support cash @ POS transactions with signature

7.2.1.7 Cash Withdrawal - ATM

The flowing table describes Cash Withdrawal message
DE Description 0200 0210

28 Amount, fee C C+
48 Tag 054 CVD/iCVD Match result code -- C
52 PIN data C --
54 Additional Amount - O
55 Chip data C C


Table 20 Cash Withdrawal - ATM Message – Issuer
For domestic transaction data element 4 will be in INR and it can be identified by DE 19 value
356 and DE 49 value 356.
For international transactions DE 4, DE 6, DE49 and DE 51 will be present. DE 4 will be in

respective international transaction currency (e.g. USD, GBP etc.) and DE 49 will carry
respective currency code (e.g. 840, XXX). Issuer need to block/ debit customer account by the
amount present in DE 6 which will be in INR. Issuer will identify international transaction from
DE 19 and DE 49 which will be other than 356.
Note: All ATM international transaction will be DMS.
7.2.1.8 Balance Inquiry

The following table describes Balance Inquiry message
DE Description 0100/0200 0110/0210

40 Service Code C --
48 Tag 054 CVD/iCVD Match result code - C

DE Description 0100/0200 0110/0210

52 PIN data C --
54 Additional amount -- M
55 Chip data C C
Table 21 Balance Inquiry Message – Issuer
Note: In case of absence of DE 54 in the response, NPCI will send CI to the acquirer and DE 44 will
get logged as I054.
7.2.1.9 Reversal Message

This message format reverses the action of a previous authorization / financial transaction. It
notifies NPCI Host and the issuer of an error condition regarding an earlier authorization /
financial transaction. The table below describes the reversal message.

1 Secondary bit map M M
28 Amount, fee C C+


38 Authorization code C C
39 Response code M M
44 Additional Response data C --
54 Additional amount C C+
55 Chip data C --
90 Original data element M M+
95 Replacement amount C C+
102 Account Identification 1 O O
Table 22 Reversal Message – Issuer
7.2.1.10 Decline Message

In this case, acquirer sends a 0100 message to NPCI, NPCI forwards the 0100 message to Issuer.
Issuer does the validation and sends a response 0110 message to NPCI. NPCI finds an error in
the message sent by the issuer; NPCI sends a 0110 message to acquirer with a request denial
and a reversal to the issuer with response code CI and DE 44 indicating the 1st data element in
error.
DE Description 0100 0110 NPCI Message 0110 / 0420

/0200 /0210 Edit 0210 (NPCI (NPCI 
Failure Acquirer) Issuer)
1 Secondary Bit map C C C C C
2 Primary Account M M+ M M M
Number
3 Processing Code M M+ M M M
4 Amount, Transaction M M+ M M M
5 Amount, settlement -- C+ C C C
6 Amount, card holder -- C+ C C C
billing
7 Date/time, M M+ M M M
Transmission
9 Conversion rate, -- C+ C C C
Settlement
10 Conversion rate, -- C+ C C C
Cardholder Billing
11 STAN M M+ M M M
12 Time, local transaction M M+ M M M
13 Date, local transaction M M+ M M M
14 Data, expiry C -- -- -- --
15 Date, Settlement -- C+ C C C
16 Date, conversion -- C+ C C C


/0200 /0210 Edit 0210 (NPCI (NPCI 
18 Merchant category code M -- -- -- M
19 Acquiring institution M M+ M M M
country code
22 POS entry mode M -- -- -- M
23 Card sequence number C C+ C C C
25 POS condition code M -- -- -- M
28 Amount, fee C C+ C C C
32 Acquiring institution M M+ M M M
code
33 Forwarding institution C C+ C C C
code
35 Track 2 Data C -- -- -- --
37 Retrieval reference M M+ M M M
number
38 Authorization code -- C C -- C
39 Response code -- M M M M
40 Service Code C - - - -
41 Card acceptor terminal M M+ M M M
ID
42 Card acceptor ID M -- -- -- M
43 Card acceptor name / M -- -- -- M
location
44 Additional Response -- -- -- -- M
data
45 Track 1 data C -- -- -- --
48 Additional data M M M M M
49 Currency code, M M+ M M M
transaction
50 Currency code, -- C+ C C C
settlement
51 Currency code, card -- C+ C C C
holder billing
52 PIN Data C -- -- -- --
54 Additional amount C C+ C C C
55 Chip data C C C C C
61 POS data code M -- -- -- --
62 Private data 1- -- C C C --
Biometric data
63 Private Data 2 - C -- -- -- --
Encrypted Biometric
data
90 Original data elements -- -- -- -- M
95 Replacement amount -- -- -- -- C
102 Account Identification 1 -- O+ O O C
120 Private data 3 C C C C C
121 Private data 4 O O+ O O O
126 Private data 8- C -- -- -- --


/0200 /0210 Edit 0210 (NPCI (NPCI 
Biometric data
127 Private data 7- C -- -- -- --
Biometric data
Table 23 Decline Message
Note: RuPay will respond to acquirer with response code CI indicating request declined. RuPay will
generate reversal for issuer with response code CI indicating data format error in the response. In
the reversal data element 44 will contain an appropriate reason code for declining the authorized
authorization. Acquirer need not generate reversal for the same.
7.2.1.11 Network Management

The following table describe Network Management message.

7 Transmission date/time M M
11 STAN M M+
48 Additional data(key exchange) C --
70 Network management information M M
code
Table 24 Network Management Message – Issuer
For key exchange message NPCI will act as a master (NPCI will send the new key for all
members)
7.2.1.12 Pin Change

The following table describe Pin Change message.
DE Description 0200 0210 (Issuer 

(NPCI  Issuer) NPCI)
35 Track 2 data M --


40 Service code M --
52 PIN data M --
55 Chip data C C
120 Private data 3 M M
120 Tag 001 Transaction type M M
120 Tag 002 Product Indicator M M
120 Tag 004 New Pin Block M --
Table 25 Pin Change Message – Issuer
7.2.1.13 Mini Statement

The following table describe Mini Statement message.
DE Description 0100/0200 0110/0210


DE Description 0100/0200 0110/0210

52 PIN data C --
55 Chip data C C
62 Private data 1-Biometric Data C C+
120 Tag 005 No. of lines in Mini Statement -- M
120 Tag 006 Mini Statement Data -- M
Table 26 Mini Statement Message – Issuer
7.2.1.14 Card to Card Fund Transfer

RuPay implementation of Card to Card Fund transfer is a split transaction. There are total 2
transactions which completes Card to Card Fund Transfer. These transactions are as follows:
1. Card to Card Fund Transaction Debit to Sender.

2. Card to Card Fund Transaction Credit to Beneficiary.
Refer Annexure 1 for transaction flow and detailed explanation of Card to Card Transfer.
 Card To Card Funds Transfer (Debit to the Sender)

(NPCI  Issuer) Issuer NPCI)


28 Amount, fee C C+
48 Tag 054 CVD/iCVD match result -- C
52 PIN data C --
55 Chip data C C
102 Account Id 1 -- M


103 Account Id 2 M --

Table 27 Card to Card Fund Transfer-Debit leg to the issuer
 Card to Card Funds Transfer (Credit to the beneficiary)

(NPCI  Beneficiary 
Beneficiary) NPCI)
2 Primary Account Number M M
3 Processing Code M M
4 Amount, Transaction M M
5 Amount, Settlement C C
6 Amount, card holder billing C C
7 Date/time transmission M M
9 Conversion rate, Settlement C C
10 Conversion rate, card holder billing C C
11 System trace audit number M M
12 Time, local transaction M M
13 Date, local transaction M M
15 Date, Settlement C C
16 Date, conversion C C
19 Acquiring institution country code M M
28 Amount, fee C C
32 Acquiring institution code M M
33 Forwarding institution code C C
37 Retrieval reference number M M
41 Card acceptor terminal ID M M
44 Additional, response data -- C
48 Tag 051 Product code M M


(NPCI  Beneficiary 
Beneficiary) NPCI)
49 Currency code, transaction M M
50 Currency code, settlement C C
51 Currency code, card holder billing C C
103 Account Id 2 -- M
121 Private data 4 O O
Table 28 Card to Card Fund transfer-Credit to the beneficiary
7.2.1.15 Mobile Number Update

The below table describes Mobile Number Update message
DE Description 0100/0200 0110/0210


DE Description 0100/0200 0110/0210

48 Tag 074 Customer Telephone / Mobile Number M --
52 PIN data C --
55 Chip data C C
120 Private data 3 M M+
Table 29 Mobile Number Update – Issuer
7.2.1.16 Cheque Book Request

The below table describes Cheque Book Request message
DE Description 0100/0200 0110/0210


DE Description 0100/0200 0110/0210

52 PIN data C --
55 Chip data C C
Table 30 Cheque Book Request – Issuer
7.2.1.17 Statement Request

The below table describes Statement Request message
DE Description 0100/0200 0110/0210


DE Description 0100/0200 0110/0210

52 PIN data C --
55 Chip data C C
Table 31 Statement Request – Issuer
7.2.1.18 Declined Advice (Quick EMV)

The following message describe declined Authorization Advice Message for quick EMV

DE Description 0120 / 0220 0130 / 0230

23 Card sequence number - -
28 Amount, fee C C+
38 Authorization code - -
55 Chip data - -
60 Advice reason code - --
Table 32 Decline Advice Message (Quick EMV) – Issuer

7.2.2 Future (Phase II) Requirements

7.2.2.1 Equated Monthly Instalment (EMI)
The table below describes EMI message format. EMI message is a domestic only message.
DE Description 0100/0200 0110/0210

28 Amount, fee C C+
48 Tag 054 CVD/iCVD Match result code -- M
48 Tag 059 EMI Amount M M
52 PIN data C --
55 Chip data C C

DE Description 0100/0200 0110/0210

Table 33 EMI Message – Issuer
Note: DE 48 will carry the details of margin amount, number of instalments and EMI amount. EMI
is domestic only transaction
7.2.2.2 Loyalty Redemption

The table below describes loyalty redemption transaction. Loyalty redemption transaction is
domestic only transaction
DE Description 0100/0200 0110/0210

28 Amount, fee C C+
48 Tag 062 Loyalty points for debit M --

DE Description 0100/0200 0110/0210

52 PIN data C --
55 Chip data C C
Table 34 Loyalty Redemption Message – Issuer
Note: Loyalty transaction is domestic only transaction. When a purchase transaction is done with
loyalty redemption, then DE 4 will contain the purchase amount and DE 48 will contain the points
to be redeemed. Once the purchase is done, customer’s loyalty points will be debited with the value
in DE 48. The customer’s account will be debited with DE4 value and credited back with the
equivalent of loyalty points.
7.2.2.3 Authorization Advice

The following message describe Authorization Advice message.

28 Amount, fee C C+


38 Authorization code M M+
39 Response code M M+
55 Chip data C C
60 Advice reason code M --
Table 35 Authorization Advice Message – Issuer
7.2.2.4 File Update

This message is used by the Issuer to update the customer account files such as Hot Cards. File
name is kept as optional as, at this stage only one file is in scope of updating negative list.
DE Description 0302 0312 Comments

(Issuer  (NPCI 
NPCI) Issuer)
2 Primary Account Number M M Used by issuer to list
the primary account
number referenced in
the message
7 Transmission date/time M M Transmission date and
time of the message
11 STAN M M Unique number
assigned by initiator
15 Date, Settlement - M This is the date on
which the file update is
registered. In case of
repeat, date of the first
request is picked
33 Forwarding institution ID M M Must contain the same
value from the original
transaction
37 Retrieval reference number M M Tracking number

DE Description 0302 0312 Comments

(Issuer  (NPCI 
NPCI) Issuer)
generated by issuer
39 Response code -- M Response code
generated by NPCI.
91 File Update Code M M Used to indicate the
action on the file
101 File Name O O+ File name of the file to
be updated
124 Action Code M M Used to indicate the
response for the
transaction when the
card transacts in the
STIP mode
Table 36 File Update Message – Issuer
7.2.2.5 Loyalty Inquiry

The following table describes Loyalty Inquiry message.
DE Description 0100/0200 0110/0210


DE Description 0100/0200 0110/0210

48 Tag 063 Loyalty balance -- M
52 PIN data C --
55 Chip data C C
62 Private data 1-Biometric data C C+
Table 37 Loyalty Inquiry Message – Issuer
7.2.2.6 Refund
The following table describes Refund message.
DE Description 0100/0200 0110/0210

28 Amount, fee C C+

Message Format Message Format for Acquirer
DE Description 0100/0200 0110/0210

55 Chip data C C
Table 38 Refund Message – Issuer
7.3 Message Format for Acquirer

7.3.1 Current (Phase I) Requirements
7.3.1.1 Purchase
The following table describes purchase message for acquirer.
DE Description 0100/0200 0110/0210

(Acquirer  NPCI) (NPCI  Acquirer)
5 Amount, Settlement -- C
6 Amount, card holder billing -- C
9 Conversion rate, Settlement -- C
10 Conversion rate, card holder billing -- C

DE Description 0100/0200 0110/0210

15 Date, Settlement -- C
16 Date, conversion -- C
23 Card sequence number C C
28 Amount, fee C C
50 Currency code, settlement -- C
51 Currency code, card holder billing -- C
52 PIN data C --
55 Chip data C C
62 Private data 1-Biometric Data -- C
63 Private data 2, Biometric data C --
126 Private data 8- Biometric Data C --
Table 39 Purchase Message – Acquirer
Note: For SMS transactions which require surcharge and tips adjustments members can use SMS
Tip and Surcharge presentment in the clearing cycle. Refer RGCS document.

7.3.1.2 Purchase with Cashback

The following table describes Purchase with Cashback message for acquirer.
DE Description 0100/0200 0110/0210

28 Amount, fee C C
52 PIN data C --
54 Additional amount M M
55 Chip data C C
62 Private data 1-, Biometric data -- C

DE Description 0100/0200 0110/0210

Table 40 Purchase with Cashback Message – Acquirer
7.3.1.3 RuPay E-Commerce Purchase (Secure / Non-Secure)

The following table describes RuPay E-Commerce purchase message for acquirer.
DE Description 0100/0200 0110/0210

1 Secondary Bit Map C C
5 Amount, settlement -- C
28 Amount, fee C C
48 Tag 061 Transaction Id M M
48 Tag 071 International Authorization Network Identifier --
/ IP address and Country Code O
48 Tag 075 Image code M --

DE Description 0100/0200 0110/0210

48 Tag 076 Personal Phrase O --
48 Tag 077 Issuer supplied ID / Unique ID O --
52 PIN data C --
Table 41 RuPay E-Commerce Purchase Message – Acquirer
7.3.1.4 E-Commerce 3D Purchase

The following table describes E-Commerce 3D Purchase message.

28 Amount, fee C C


48 Tag 057 ICS1 result code C C
48 Tag 061 Transaction Id M M
48 Tag 064 ICS2 result code C C
48 Tag 071 IP address and Country Code/ International --
Authorization Network Identifier O
61 POS data code M -
Table 42 E-Commerce 3D Purchase Message – Acquirer
7.3.1.5 E-Commerce Refund

E-commerce Refund is a financial transaction originated at the merchant’s website that
instructs the issuer to credit the cardholders account for the return of goods, tickets etc. Refund
amount should be less than or equal to the amount of original purchase.
E-commerce refund is carried out as follows:
 E-commerce refund is carried out offline and not online. This essentially means that
refund transaction is to be processed only in clearing and settlement cycle.
 While a customer is doing an E-Commerce purchase, a Transaction Id is generated from
the merchant portal which gets stored in field 48. This transaction Id is unique to the
customer for the purchase made at the particular merchant portal.
 When a customer wants to do the Refund of the previous transaction, he needs to
request/select for refund.
 Once a customer initiates a refund, the merchant portal will provide the following
details to the Acquirer payment Gateway
 Transaction ID (mandatory)
 Original Transaction Date Time (Same as DE12 at acquirer end)
 Refund Amount
 Based on the above parameter acquirer will retrieve the original transaction and shall
ensure that the refund amount is less than original purchase amount. After all these

checks acquirer will generate a refund message for clearing cycle as described in NPCI
Clearing and Settlement manual.
 The issuer by seeing the presentment data will process the refund and credit the
customer’s account.
7.3.1.6 Cash at PoS

The following table describes Cash at PoS message for acquirer.
DE Description 0100/0200 0110/0210

28 Amount, fee C C
52 PIN data C --
55 Chip data C C
62 Private data 1- Biometric Data -- C

DE Description 0100/0200 0110/0210

Table 43 Cash at PoS / Cash Withdrawal Message – Acquirer
Note: NPCI will not support cash @ POS transactions with signature
7.3.1.7 Cash Withdrawal - ATM

The following table describes Cash Withdrawal message for acquirer.

28 Amount, fee C C


52 PIN data C --
54 Additional Amount -- O
55 Chip data C C
126 Private data 8- Biometric Data C -
127 Private data 7- Biometric Data C -
Table 44 Cash Withdrawal - ATM Message – Acquirer
7.3.1.8 Balance Inquiry

The following table describes Balance Inquiry message for acquirer.
DE Description 0100/0200 0110/0210


DE Description 0100/0200 0110/0210

52 PIN data C --
54 Additional amount -- M
55 Chip data C C
62 Private data 1- Biometric Data - C
Table 45 Balance Inquiry – Acquirer
Note: In case of absence of DE 54 in the response, NPCI will send CI to the acquirer and DE 44 will
get logged as I054.
7.3.1.9 Reversal
This message format reverses the action of a previous authorization. It notifies NPCI Host and
the issuer of an error condition regarding an earlier financial transaction. The table below
describes the reversal message.



28 Amount, fee C C
38 Authorization code C C
44 Additional Response data -- C
54 Additional amount C C
55 Chip data C C
90 Original data element M M
95 Replacement amount C C
102 Account Identification 1 O O
Table 46 Reversal Message – Acquirer
7.3.1.10 Decline Message

In this case, when an acquirer sends a request and NPCI does the validation and detects a format
error, then NPCI will respond with 0110 response ‘CA’ (Compliance Acquirer) and populate DE
44 1st data element in error.
DE Description 0100/ Message NPCI 0110 /0210

0200 Edit (0110) (NPCI 
Failure Acquirer)
1 Secondary Bit map C C C
2 Primary Account Number M M M
3 Processing Code M M M
4 Amount, Transaction M M M
5 Amount, settlement -- C C
6 Amount, card holder billing -- C C
7 Date/time, Transmission M M M
9 Conversion Rate, Settlement -- C C
10 Conversion rate, Cardholder -- C C
Billing
11 System trace audit number M M M
12 Time, local transaction M M M
13 Date, local transaction M M M
14 Data, expiry C -- --
15 Date, Settlement -- C C
16 -- C C
Date, conversion
18 Merchant category code M -- --

DE Description 0100/ Message NPCI 0110 /0210

0200 Edit (0110) (NPCI 
Failure Acquirer)
19 Acquiring institution country M M M
code
22 POS entry mode M -- --
23 Card sequence number C C C
25 POS condition code M -- --
28 Amount, fee C C C
32 Acquiring institution code M M M
33 Forwarding institution code C C C
35 Track 2 Data C -- --
37 Retrieval reference number M M M
38 Authorization code -- -- --
39 Response code -- M M
40 Service Code C -- --
41 Card acceptor terminal ID M M M
42 Card acceptor ID M -- --
43 Card acceptor name / location M -- --
44 Additional Response data -- M M
45 Track 1 C -- --
48 Additional data M M M
49 Currency code, transaction M M M
50 Currency code, settlement -- C C
51 Currency code, card holder billing -- C C
52 PIN Data C -- --
54 Additional amount C C C
55 Chip data C C C
61 POS data code M -- --
62 Private data 1-Biometric Data - - -
63 Private Data 2 -Encrypted C -- --
Biometric data
102 Account Identification 1 -- O O
120 Private data 3 O O O
126 Private data 7 Biometric Data C -- --
127 Private data 7 Biometric Data C -- --
Table 47 Decline Message
Note: NPCI will respond to acquirer with response code CA indicating message format errors. Data
element 44 will contain the appropriate reason code for declining the transaction. Acquirer need
not generate reversal for the same. It may also happen that NPCI is not able to prepare the
response due to error in mandatory data element. In this case multiple reversal from acquirer is
expected, which has to be handled by the operations team.
7.3.1.11 Network Management

The following table describe Network Management message for acquirer.


7 Transmission date/time M M
11 STAN M M+
48 Additional data (key exchange) C --
70 Network management information M M
code
Table 48 Network Management Message
Note: For key exchange message either NPCI will act as a master (NPCI will send the new key for
all members).
7.3.1.12 Pin Change

The following table describes Pin Change message for acquirer.
DE Description /0200 /0210

35 Track 2 data M --
48 Tag 058 Fraud Score -- --

DE Description /0200 /0210

52 PIN data M --
55 Chip data C C
120 Tag 001 Transaction Type M M
120 Tag 004 New Pin Block M --
Table 49 Pin Change Message – Acquirer
7.3.1.13 Mini Statement

The following table describes Mini Statement message for acquirer.
DE Description 0100/0200 0110/0210

48 Tag 058 Fraud Score -- --

DE Description 0100/0200 0110/0210

52 PIN data C --
55 Chip data C C
120 Tag 001 Transaction Type M M+
120 Tag 002 Product Indicator M M+
120 Tag 005 No. of lines for mini statement -- M
120 Tag 006 Mini statement data -- M
Table 50 Mini Statement Message – Acquirer
7.3.1.14 Card to Card Funds Transfer

1. Card to Card Fund Transaction
Refer Annexure 1 for transaction flow and detailed explanation of Card to Card Transfer
 Card To Card Funds Transfer for acquirer

(Acquirer  (NPCI 
NPCI) Acquirer)


(Acquirer  (NPCI 
NPCI) Acquirer)
28 Amount, fee C C
44 Additional, response data -- C
48 Tag 054 CVD/iCVD match result -- C
52 PIN data C --
55 Chip data C C
62 Private data 1 Biometric data O C
102 Account Id 1 C C
103 Account Id 2 M --
126 Private data 8 Biometric data C --
127 Private data 7 Biometric data C --
Table 51 Card to Card Fund transfer
7.3.1.15 Biometric Onus Authentication

The following table describes Balance Inquiry message for acquirer.

DE Description 0100/0200 0110/0210

62 Private data 1- Biometric Data - C
Table 52 Biometric Onus Authentication

7.3.1.16 Mobile Number Update

The following table describes Mobile Number Update message for acquirer.
DE Description 0100/0200 0110/0210

28 Amount, fee C C
48 Tag 074 Customer Telephone / Mobile Number M --
52 PIN data C --
55 Chip data C C

DE Description 0100/0200 0110/0210

Table 53 Mobile Number Update
7.3.1.17 Cheque Book Request

The following table describes Cheque Book Request message for acquirer.
DE Description 0100/0200 0110/0210

28 Amount, fee C C

DE Description 0100/0200 0110/0210

52 PIN data C --
55 Chip data C C
Table 54 Cheque Book Request
7.3.1.18 Statement Request

The following table describes Statement Request message for acquirer.
DE Description 0100/0200 0110/0210

28 Amount, fee C C

DE Description 0100/0200 0110/0210

52 PIN data C --
55 Chip data C C
Table 55 Statement Request
7.3.2 Future (Phase II) Requirements

7.3.2.1 Equated Monthly Instalments (EMI)
The following table describes EMI message for acquirer.
DE Description 0100/0200 0110/0210

5 Amount, Settlement - C
9 Conversion rate, Settlement - C

DE Description 0100/0200 0110/0210

28 Amount, fee C C
48 Tag 059 EMI Amount M M
50 Currency code, settlement - C
52 PIN data C --
55 Chip data C C
62 Private data 1- Biometric data - C
126 Private data 8 Biometric data C -
Table 56 EMI Message – Acquirer
Note: DE 48 will carry the details of margin amount, number of instalments and EMI amount. EMI
is domestic only transaction.
7.3.2.2 Loyalty Redemption

The table below describes loyalty redemption transaction. Loyalty redemption transaction is
domestic only transaction.
DE Description 0100/0200 0110/0210


DE Description 0100/0200 0110/0210

15 Date, Settlement - C
28 Amount, fee C C
48 Tag 062 Loyalty points for debit M M
48 Tag 066 UID Number (Aadhaar) O -
48 Tag 067 Income Tax PAN O -
52 PIN data C --
55 Chip data C C
62 Private data 1 Biometric data - C
Table 57 Loyalty Redemption Message - Acquirer
Note: Loyalty transaction is domestic only transaction. When a purchase transaction is done with
loyalty redemption, then DE 4 will contain the purchase amount and DE 48 will contain the points
to be redeemed. Once the purchase is done, customer’s loyalty points will be debited with the value

in DE 48. The customer’s account will be debited with DE4 value and credited back with the
equivalent of loyalty points.
7.3.2.3 Loyalty Inquiry

The following table describes Loyalty Inquiry message for acquirer.
DE Description 0100/0200 0110/0210

48 Tag 063 Loyalty Balance -- M
52 PIN data C --
55 Chip data C C
62 Private data 1, Biometric data - C

DE Description 0100/0200 0110/0210

127 Private data 7, Biometric data C -
Table 58 Loyalty Inquiry Message – Acquirer
7.3.2.4 Refund
The following table describes Refund message for acquirer.
DE Description 0100/0200 0110/0210

10 Conversion rate, card holder billing - C
28 Amount, fee C C

DE Description 0100/0200 0110/0210

54 Additional amount C C
55 Chip data C C
Table 59 Refund Message – Acquirer

Data Element Description Annotation Convention for Attributes
Chapter 8 Data Element Description

8.1 Annotation Convention for Attributes
Each data element is described in a standard format which defines the permitted content of the
field.
A Alphabetical
B Binary data
N Numeric value
S Special character
X Character C / D to indicate credit / debit
Z Track data
an Alphanumeric
ans Alpha numeric with special characters
Field Type Meaning
Fixed No field length used
LLVAR or (..xx) Where LL<100, means 2 leading digits LL specify the length of field
VAR
LLLVAR or (…xxx) Where LLL<1000, means 3 leading digits LLL specify the length of
field VAR
Table 60 Abbreviation used in Data Element Description
Notation Description
MM month (two digits, 01–12)
DD day (two digits, 01–31)
YY year (last two digits of calendar year, 00–99)
HH hour (two digits, 00–23)
MM minute (two digits, 00–59)
SS second (two digits, 00–59)
Table 61 Data and Time Attribute
8.2 Data Elements Information Components

Each field description contains several information components and topics within those
components. Table below describes the main component labels.
Components Type of Information

Type Date element type and field length
Format Data element field format
Description Data element content and code definitions
when applicable.
Field Edits Data element content and presence rules
Constraints Defines when the data element is required to
be echoed in response
Validation Type of validation to be performed on data
element
Compliance Compliance rules applicable to the data
element
Table 62 Data Element Information Components

Data Element Description Detailed Description of Data Elements
8.3 Detailed Description of Data Elements

8.3.1 DE – 2 Primary Account Number
DE – 2 Primary Account Number
Type n..19
Format LLVAR
Description A series of digits used to identify customer account or
relationship. Identifies the cardholder PAN.
Field Edits This remains same for a particular transaction and cannot be
changed.
Constraints When present, it should be echoed in response and all
Subsequent messages.
Validation It should be a 12-19 digit PAN number and should not be less
than 12 and not more than 19.
Compliance Card number in request and response should always be same.
In reversal, the Card number should be the same as original
request message.
In File update message it should be a valid Card number.
Presence Mandatory-This field is mandatory across all messages except
for network management messages.
Conditional-None
Optional-None

8.3.2 DE – 3 Processing Code

DE – 3 Processing Code
Type n6
Format Fixed
Description A series of digits that describes the type of transaction and the
accounts affected by the transaction.
Digit 1 and 2 Transaction Code
00 Purchase
01 Cash withdrawal, Cash at POS / Cash
advance
09 Purchase with Cashback
10 Biometric Verification
14 EMI
20 Credit/Refund
21 Deposit
22 Credit Adjustment
27 Loyalty Redemption
31 Balance Enquiry
36 Loyalty Inquiry
40 Fund Transfer
90 Extended Transaction Type (used for
Mini Statement and Pin Change, Card to
Card Funds transfer)
Digit 3 and 4 From Account Type
00 Unspecified/Unknown
10 Savings
20 Checking
30 Credit card
Digit 5 and 6 To Account Type
10 Savings
20 Checking
30 Credit Card
This remains same for a particular transaction and cannot be
Field Edits
changed.
When present, it should be echoed in response and all
Constraint
Validation Processing code should be from the list above.
Transaction code in request and response should be same. In
reversal it should be the same as original request.
Compliance
For Mini Statement and Pin Change DE 3 should contain
900000
Presence Mandatory-This field is mandatory across all the messages
except Network management and file update message.
Conditional-None
Optional-None

8.3.3 DE – 4 Amount, Transaction

DE – 4 Amount, Transaction
Type n12
Format Fixed
Description Contains the transaction amount to be transferred i.e. specified
by the currency code in field 49.
This field contains the total amount carried for a transaction.
Field Edits This remains same for a particular transaction and cannot be
changed.
For balance enquiry amount will be zero in request and
response.
Amount, fee and cashback amount are included in field 4 in
case it is present.
Amount, Transaction is a fixed length field and a leading zero is
always required.
For Biometric verification (DE 3 is 100000) amount will be
zero in request and response.
Constraints When present, it should be echoed in response and all
Validation Amount should be only in numeric
Compliance Transaction amount should be same in request and response.
Also transaction currency code should be present in DE-49.
In reversal transaction amount should be same as original
request.
In balance inquiry transaction this field should be Zero.
For a purchase with cashback transaction this field should
contain the purchase amount + the cash amount
Amount, fee is included in field 4 in case it is present.
Presence Mandatory-This field is present across all the messages except
network management and file update messages.
Conditional-None
Optional-None

8.3.4 DE – 5 Amount, Settlement

DE – 5 Amount, Settlement
Type n12
Format Fixed
Description In a cross currency conversion, the settlement amount is
obtained by multiplying the Transaction amount (DE 4) with
the settlement conversion rate (DE-9).
For a domestic transaction settlement amount should be equal
to the transaction amount.
Field Edits This field can be changed for a particular transaction. But when
present this is to be echoed in response.
Constraints The field is required when field DE-50 is present
Compliance If this field is present, DE-9 and DE-50 should be mandatory.
Presence Mandatory – None
Conditional - For international transactions this field should be

present.
Optional-None

8.3.5 DE – 6 Amount, Cardholder Billing

DE – 6 Amount, Cardholder Billing
Type n12
Format Fixed
Description In a cross currency transaction, the transaction amount (field
4), is converted to the currency used to bill the cardholder’s
account.
For a domestic transaction cardholder billing amount is equal
to the transaction amount.
Field Edits This field can be changed for a particular transaction. When
present this is to be echoed in response.
Constraints The field is required when field DE-51 is present
Compliance If this field is present, and DE-51 should be mandatory.
Conditional-For international transactions this field should be

present
Optional-None

8.3.6 DE – 7 Date and Time Transmission

DE – 7 Date and Time Transmission
Type n10
Format Fixed. MMDDhhmmss
Description Date and time a message is entered into the data interchange
system. It is represented in GMT/UTC
Field Edits This field can be changed for a particular transaction.
The original date and time will be restored in the response.
Constraints This should be echoed back in response
Validation Date and Time, Transmission should be only in numeric
Compliance Transactions are allowed up to +/- 2 hours of the current date.
In reversal this value can differ from original request.
Presence Mandatory- This field is mandatory across all the messages
Conditional-None
Optional-None

8.3.7 DE – 9 Conversion Rate, Settlement

DE – 9 Conversion Rate, Settlement
Type n8
Format Fixed
Description Conversion rate for settlement amount. This field is in format
ABBBBBBB where A denotes decimal position from the right
and BBBBBBB denotes conversion factor. For example,
40012345 denotes 1.2345
Field Edits The factor used to convert transaction amount (DE-4) into
settlement amount (DE-5). Transaction amount is multiplied
by settlement conversion rate to determine settlement amount.
Constraints The field is required when field DE-50 is present.
Validation Conversion rate should be only in numeric
Compliance Only format validation. If the format is not correct then reject
the message with response code
Presence Mandatory-None
Conditional- For international transactions this field should be

present.
Optional-None

8.3.8 DE – 10 Conversion Rate, Cardholder Billing

DE – 10 Conversion Rate, Cardholder Billing
Type n8
Format Fixed.
Description This is the rate that is applied to the cardholder billing.
In a cross currency transaction, transaction amount (DE 4) is
multiplied by the conversion rate (DE 10) to get the cardholder
billing amount (DE 6).
This field is in format ABBBBBBB where A denotes decimal
position from the right and BBBBBBB denotes conversion
factor. For example,
40012345 denotes 1.2345
Field Edits This field can be changed for a particular transaction but when
present should be echoed in response.
Constraint The field is required when field DE-51 is present.
Validation Conversion rate should be numeric
Compliance Only format validation. If the format is not correct then reject
the message with response code
Conditional- For international transactions this field should be

present.
Optional-None

8.3.9 DE – 11 System Trace Audit Number

DE – 11 System Trace Audit Number
Type n6
Format Fixed.
Description This is assigned by the POS device that uniquely identifies a
cardholder transaction.
Remains unchanged for all messages throughout the life the
transaction.
Issuer has to respond back with the same STAN in their
response. It may happen that acquirer STAN and Issuer STAN
may be different for the same transaction.
Acquirer should send STAN & RRN of original transaction in
reversal messages.
Field Edits This field remains the same for a particular transaction.
Constraints The same is echoed in the response
Validation STAN should be a 6 digit numeric value.
Compliance System trace Audit Number should be same in request as well
as in response.
Presence Mandatory- Present across all the messages
Conditional-.None
Optional-None

8.3.10 DE – 12 Time, Local Transaction

DE – 12 Time, Local Transaction
Type n6
Format Fixed. hhmmss
Description Time entered by the POS device. Local time at which the
transaction began at the card acceptor location.
Constraints This is to be echoed in the response.
Validation Local time should be of this format
Compliance Local transaction time should be same in request as well as in
response. And this field remains same in complete transaction
cycle.
Conditional-None
Optional-None

8.3.11 DE – 13 Date, Local Transaction

DE – 13 Date, Local Transaction
Type n4
Format Fixed. MMDD
Description Date entered by the POS device. Local date at which the
transaction began at the card acceptor location
Constraints This is to be echoed in the response.
Validation Local date should be of this format
Compliance Local transaction date should be same in request as well as in
response. And this field remains same in complete transaction
cycle.
Conditional-None
Optional-None

8.3.12 DE – 14 Date, Expiry

DE – 14 Date, Expiry
Type n4
Format Fixed. YYMM
Description Contains the month and the year after which the card expires.
Field Edits This remains same for a particular transaction and is not
echoed back in a response.
Constraints Element is present if DE-35 (Track 2) is not present.
Validation This field should not be present when track 2 data is present.
For manual entry transaction this field should be mandatory.
Date, Expiry should be of this format
Compliance This field should be present in card not present transactions
such as E-commerce, manual entry.
Presence Mandatory- None
Conditional- For CNP transactions this field should be present
Optional- None

8.3.13 DE – 15 Date, Settlement

DE – 15 Date, Settlement
Type n4
Format Fixed. MMDD
Description Month and date on which NPCI Host will settle the transaction.
Field Edits NPCI can add settlement date as per the cases. But when
present should be echoed back in the response.
Constraints For a cross currency conversion, Field 50 should be present.
Validation Settlement Date should be of this format
Compliance NPCI can keep this field in request in Network management
message.
Presence Mandatory-For a file update this is present in response
Conditional-For international transactions this should be

present.
For network management message during cutover message

this should be present
Optional-None

8.3.14 DE – 16 Date, Conversion

DE -16 Date, Conversion
Type n4
Format Fixed. MMDD
Description In a cross currency conversion month and date on which NPCI
Host will calculate the cardholder billing amount.
Field Edits NPCI can add conversion date as per the cases. But when
present should be echoed back in the response.
Constraints For a cross currency conversion, Field 51 should be present.
Validation Settlement date should be of this format
Compliance NPCI can keep this field in request.

present
Optional-None

8.3.15 DE – 18 Merchant Category Code

DE – 18 Merchant Category Code
Type n4
Format Fixed.
Description Contains a 4 digit code describing a merchant’s type of
business. Refer to ISO 18245 for list of MCC’s
Field Edits This remains same for a transaction.
Constraints It is not to be echoed in response
Validation This field should be from the standard list.
Compliance This is mandatory field. The value should be present as per the
MCC code as per ISO 18245
Presence Mandatory-Should be present for all messages
Conditional-None
Optional-None

8.3.16 DE – 19 Acquiring Country Code

DE – 19 Acquiring Country Code
Type n3
Format Fixed.
Description Contains a code identifying the country of the acquiring
institution for the POS. Refer to ISO 3166 for country code list
Field Edits This remains same for a particular transaction.
Constraints If present is to be echoed back in response.
Validation This field should be from standard list
Compliance None
Conditional-None
Optional-None

8.3.17 DE – 22 Point of Service Entry Mode

DE – 22 Point of Service Entry Mode
Type n3
Format Fixed.
Description Contains a 3 digit code indicating the method used to enter the
account number.
Digit 1 & 2 PAN Entry Mode
00 PAN entry mode unknown
01 Manual
02 Magnetic Stripe Read
03 Barcode reader
04 Optical card reader
05 ICC
06 IVR
07 Contactless payment using chip card.
80 Fallback Transactions
81 E-commerce
90 Full and Unaltered magnetic stripe
read(enables CVD validation)
91 Contactless using CVD, iCVD checking
possible.
95 Chip card with unreliable CVD or iCVD
99 Reserved for RuPay
Digit 3 PIN Entry Capability
0 Unspecified
1 PIN Entry Capability
2 No PIN Entry Capability
6 PIN pad inoperative
8 Reserved for RuPay
9 Reserved for private use(Biometric entry
capability)
Constraints It is not echoed in response.
Validation This field should be from the standard list
Compliance The value should be from the table mentioned above.
Card present: This field should compare with DE-25, DE-
35/DE-45, DE-52, DE-55, DE-61, DE-63 and DE-23.
Card not present:-- This field should be compare with DE-
14,DE-25,DE-48, DE-52 and DE-61
Conditional-None
Optional-None

8.3.18 DE – 23 Card Sequence Number

DE – 23 Card Sequence Number
Type n3
Format Fixed.
Description (Applicable for Chip) If cards have the same PAN Number then
card sequence number is used to differentiate these cards
Constraints For quick EMV issuer and full chip issuer, DE 23 will be sent to
the issuer in request.
DE 23 may be echoed in quick EMV issuer in response.
For Full chip issuer DE 23 shall be echoed in response.

Validation It should be a 3 digit numeric code
Compliance This field should be present if it is a RuPay chip transaction and
should be consistent with DE-22 and DE-55.
Conditional-For all chip based cards this field should be

present
Optional-None

8.3.19 DE – 25 Point of Service Condition Code

DE – 25 Point of Service Condition Code
Type n2
Format Fixed.
Description 2 Digit code determining the transaction conditions at the POS.
Value Meaning
00 Normal
01 Customer Not present
02 Unattended Terminal
03 Merchant suspicious
05 Customer present, card not present
06 Preauthorization completion always
contains 06.
07 Telephone Request (IVR)
08 MO/TO request
51 Request for Account and CVD verification
without authorization.
59 E-Commerce Request
71 Card present, Magnetic stripe cannot be
read.
Constraints It is not to be echoed in response.
Validation This field should be from the standard list
Compliance The value should be same as mentioned above. This field
should compare with DE-22 and DE-61.
Conditional-None
Optional-None

8.3.20 DE – 28 Amount, Fees

DE – 28 Amount, Fees
Type x+n8
x=C/D
Format Fixed.
Description Fees applied to an online transaction; x-credit /debit, n8 is the
fee amount. This is the same currency as field 4.
Last two digits will represent the decimal places.
Amount, fee is included in field 4 in case it is present.
Constraints When present is to be echoed back in a response.
Validation None
Compliance None
Conditional-When fees is applied then this should be present
Optional-None

8.3.21 DE – 32 Acquiring Institution Code

DE -32 Acquiring Institution Code
Type n..11
Format LLVAR
Description Unique Code allotted by NPCI for determining the financial
institution acting as an acquirer.
Field Edits This remains same for a particular transaction
Constraints This is to be echoed back in response.
Validation This is allotted by NPCI and should be numeric
Compliance The value should present in table maintained by NPCI. The
values should remain same during the complete transaction
cycle.
Presence Mandatory-Present across all the messages
Conditional-None
Optional-None
Note: For Sponsor bank model, during settlement this field should come under the sponsor bank.

8.3.22 DE – 33 Forwarding Institution Code

DE – 33 Forwarding Institution Code
Type n..11
Format LLVAR
Description Code identifying the institution forwarding a request to the
NPCI. Code can be a prearranged institution id.
Field Edits This field can be changed for a particular transaction.
Constraints This is to be echoed back in response.
Validation This is allotted by NPCI and should be numeric
Compliance The value should present in table maintained by NPCI.

present
When a third party processor is involved in the transaction
routing then this should contain the Id of the third party
processor
Optional-None

8.3.23 DE – 35 Track 2 Data

DE – 35 Track 2 Data
Type z..37
Format LLVAR
Description The information encoded on Track 2 of the magnetic stripe of
the plastic card (per ISO 7813) used for the transaction,
excluding start and end sentinel and LRC characters.
Field Edits This remains same for a particular transaction. This is not used
in reversal.
Constraints This is not echoed in response.
Validation None
Compliance If a mobile or a UID transaction this field should not be present.
This field should be a permanent field for a card based
transaction.
When PAN entry capability is 05 or 95 then EMV tag 57 should
be captured in DE 35 by the acquirer and EMV tag 57 should
not be carried in DE 55.
When PAN entry capability is 91 i.e. for a contactless card, Tag
9F6B should be captured in DE 35 by the acquirer.
Conditional-For all card present transactions this should be

present
Optional-None

8.3.24 DE – 37 Retrieval Reference Number

DE – 37 Retrieval Reference Number
Type an 12
Format YDDDHHSSSSSS
Y-Year (Last digit of current year)
DDD-Julian Date
HH-Hour
SSSSSS-STAN
Description It is used to identify and track all messages related to a given
cardholder transaction.
‘HH’ should be derived from DE-12 Time, Local transaction.
Last 6 digits of RRN should be equal to the STAN.
Acquirer should send STAN & RRN of original transaction in
reversal messages.
Field Edits This field remains same for a particular transaction and is to be
echoed back in a response.
Constraints This field should be echoed back in a response
Validation This field should be of this format
Compliance The value should be same in request as well as response. And
this value should remain same during complete transaction
cycle.
Conditional-None
Optional-None

8.3.25 DE – 38 Authorization Identification Response

DE – 38 Authorization Identification Response
Type an 6
Format Fixed
Description A unique code assigned by the issuer/NPCI for a successful
transaction.
Field Edits This field should be present if transaction is successful.
Constraints Assigned by the issuer/NPCI.
Validation This is a 6 character authorization code generated by the
issuer / NPCI and should not be filled by the acquirer
In response this should not contain all zeros or all blank spaces
or special character.
Compliance This field should be present if transaction is successful.
Conditional-Should be present in response for successful

transactions
In reversal, if this is present in the original transactions, this

field is present
Optional-None

8.3.26 DE – 39 Response Code

DE – 39 Response Code
Type an 2
Format Fixed
Description This defines the response to a request /advice for a
transaction.
Field Edits This field is echoed back in a response for a successful and an
unsuccessful transaction.
This data element must be present in all response messages
Constraints Assigned by the issuer.
Validation This is field is assigned by the issuer. But for a reversal
transaction this can be filled by the acquirer from the original
transaction.
Compliance This value should be from the table mentioned below.
Presence Mandatory-For all transactions whether successful or
unsuccessful this field is present in response
Conditional-None
Optional-None
Code Description Action

00 Approved or completed A
Successfully.
03 Invalid merchant. D
04 Pick-up. C
05 Do not honour. In case of rejection of transaction due to D
CVD/CVD2/iCVD not matching, issuer should reject
transaction with this response code.
06 Error. D
12 Invalid transaction or if member is not able to find any D
appropriate response code
13 Invalid amount. D
14 Invalid card number (no such Number). D
15 No such issuer. D
17 Customer cancellation. D
20 Invalid response. D
21 No action taken. D
22 Suspected malfunction. D
30 Format error. D
31 Bank not supported by switch D
33 Expired card, capture C
34 Suspected fraud, capture. C
36 Restricted card, capture C
38 Allowable PIN tries exceeded, capture. C
39 No credit account. D
40 Requested function not supported. D
41 Lost card, capture. C
42 No universal account. D
43 Stolen card, capture. C
51 Not sufficient funds. D


52 No checking account D
53 No savings account. D
54 Expired card, decline D
55 Incorrect personal identification number. D
56 No card record. D
57 Transaction not permitted to Cardholder D
58 Transaction not permitted to terminal. D
59 Suspected fraud, decline / Transactions declined based D
on Risk Score
60 Card acceptor contact acquirer, decline. D
61 Exceeds withdrawal amount limit. D
62 Restricted card, decline. D
63 Security violation. D
65 Exceeds withdrawal frequency limit. D
66 Card acceptor calls acquirer’s. D
67 Hard capture (requires that card be picked up at ATM). C
68 Acquirer time-out D
74 Transactions declined by Issuer based on Risk Score D
75 Allowable number of PIN tries exceeded, decline D
90 Cut-off is in process. D
91 Issuer or switch is inoperative D
92 No routing available D
93 Transaction cannot be completed. Compliance violation. D
94 Duplicate transmission. D
95 Reconcile error D
96 System malfunction D
E3 ARQC validation failed by Issuer D
E4 TVR validation failed by Issuer D
E5 CVR validation failed by Issuer D
Table 63 Response Code Table
Code Description
CI Compliance error code for issuer
CA Compliance error code for acquirer
M6 Compliance error code for LMM
ED E-commerce decline
Table 64 Compliance Reject Response Code

00 Approved or Completed successfully. A
Table 65 Response Code for Advice Message

91 Timeout Full reversal
22 Acquirer received 0110 / 0210 with DE 38 Full Reversal
CI Message edit failure during response processing at Full Reversal
NPCI(To issuer)
68 Acquirer time-out Full Reversal
17 Customer cancellation(for void) D
E1 AAC GENERATED D
E2 Terminal does not receive AAC AND TC D


32 Partial Reversal D
Table 66 Response codes Supported for Reversal Response / Request Messages

00 Approved or completed successfully. A
Table 67 Response Code Supported for Reversal Response

00 Approved or Completed successfully. A
Table 68 Response Code Supported for Network Management Message
8.3.26.1 Response code scenarios

 Message edit error
When NPCI receives 0100/0200 request from Acquirer member bank and at the time of data
validation if NPCI detects an error, then NPCI would decline the transaction and respond back to
acquirer with response code ‘CA’ in 0110 / 0210 response message. For this response code
member acquirer bank should not send a reversal.
When NPCI receives 0110 / 0210 response from Issuer member bank and at the time of data
validation in response if NPCI detects an error, then NPCI would decline the transaction and
respond back to acquirer with response code ‘CI’ in 0110 / 0210 response message. At same
time NPCI would generate a reversal to member issuer bank with response code ‘CI’ with DE-44
specifying data element in error.
If NPCI receives 0420 reversal from Acquirer member bank and at the time of data validation if
NPCI detects error, then NPCI 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.
 Issuer response Timed Out/Late response (STIP not activated)
When NPCI sends 0100 / 0200 request to Issuer member bank and do not receive response
within the stipulated time, NPCI response back to acquirer with response code ‘91’and sends
reversal to issuing member bank with response code ‘91’ indicating a full reversal.
 Issuer offline/Signed off
If Issuer member bank is in offline/signed off and NPCI receives 0100 / 0200 request from the
acquirer and if issuer member bank is not a part of STIP, then NPCI will response back with ‘91’
response code to Acquirer member bank. Acquirer need not generate reversal for this
transaction.
 Acquirer Time-out
When an acquirer sends a 0100/ 0200 message to NPCI but do not receive the response within
the stipulated time, then acquirer sends a reversal 0420 message with response code ‘68’.

 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’.
 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 NPCI.
Response code for E-commerce non secure transactions:
8.3.26.2 E-commerce 3 D Implementation

Scenario 1:
If for an E-commerce 3 D transaction, acquirer is sending DE 48 Tag 056 as 06/07/08 in request

then NPCI will route the transaction to the issuer and issuer needs to reject this with decline
response code ‘ED’. NPCI will route the declined response to the acquirer.
Scenario 2:

then NPCI will route the transaction to the issuer and if issuer approves the transaction NPCI
will route the successful response to the acquirer.
Scenario 3:

then NPCI will route the transaction to the issuer and if issuer declines the transaction with
response code other than ‘ED’ transaction then NPCI will route the declined response code to
the acquirer.
Scenario 4:

response code other than ‘ED’ and that response is not from the table defined in DE 39 then
NPCI will route this to the acquirer with response code CI and NPCI will log this as issuer
compliance as I039. NPCI will also send reversal to the issuer for the same with response code
CI and DE 44 as I039.
8.3.26.3 RuPay Implementation of E-commerce

Scenario 1:
If for an E-commerce transaction if acquirer is sending DE 48 Tag as 056 -22/23/24/25

in request then NPCI will route the transaction to the issuer and issuer needs to reject
this with decline response code ‘ED’ and NPCI will route the response to the acquirer.
Scenario 2:

If for an E-commerce transaction, acquirer is sending DE 48 Tag 056 -22/23/24/25 in

request then NPCI will route the transaction to the issuer and if issuer approves the
transaction with response code as ‘00’ then NPCI will route this to the acquirer with
response code ‘ED’ and will send a reversal to the issuer with DE 39 as CI and DE 44 as –
I039
Scenario3:
If for an E-commerce, acquirer is sending DE 48 Tag 056-22/23/24/25 -in request then

NPCI will route the transaction to the issuer and if issuer declines the transaction with
response code other than ‘ED’, then NPCI will route this to the acquirer with response code
ED and NPCI will log this as issuer compliance I039
Scenario 4:
If for an E-commerce transaction, acquirer is sending DE 48 Tag 056- 22/23/24/25 in request

response code other than ED and that response is not from the table defined in DE 39 then NPCI
will route this to the acquirer with response code ED and NPCI will log this as issuer compliance
as I039. NPCI will also send a reversal to the issuer for the same.

8.3.27 DE – 40 Service Condition Code

DE – 40 Service Condition Code
Type an3
Format Fixed
Description It is used to indicate the issuer’s acceptance criteria for
magnetic stripe transactions and whether a related integrated
circuit supporting the equivalent application as identified by
the magnetic stripe.
This field is not present in case of reversal.
Constraints When present this is not to be echoed back in a response.
Validation None
Compliance This field should be a permanent field for a card based
transaction.
Conditional-For all CP based transactions this should be

present
Optional-None

8.3.28 DE – 41 Card Acceptor Terminal ID

DE – 41 Card Acceptor Terminal ID
Type ans8
Format Fixed
Description Contains a code that identifies a card acceptor terminal or a
POS.
Constraints When present this is to be echoed back in a response.
Validation None
Compliance The value should be same in request as well as response. The
values should remain same during the complete transaction
cycle.
Presence Mandatory-For all transactions this should be present
Conditional-None
Optional-None

8.3.29 DE – 42 Card Acceptor ID

DE – 42 Card Acceptor ID
Type ans15
Format Fixed
Description Contains the identifier of the card acceptor operating the POS.
Constraints When present this is not to be echoed back in a response.
Validation None
Compliance Format check
Conditional-None
Optional-None

8.3.30 DE – 43 Card Acceptor Name / Location

DE – 43 Card Acceptor Name / Location
Type ans40
Format Fixed
Description The name and location of the card acceptor i.e. POS
Terminal owner name and city to be right padded with spaces.
Sr. No. Terminal Description
1 POS 01-23-Terminal Owner name
24-36-Terminal City
37-38-Terminal State Code
39-40-Terminal country Code
Constraints When present this should not be echoed back in a response.
Validation This filed should be of this format.
Compliance Check Terminal country code for domestic transaction only.
Conditional-None
Optional-None

8.3.31 DE – 44 Additional Response Data

DE – 44 Additional Response Data
Type an..25
Format LLVAR
Description Data element number of the first field where error occurred for
which the rejection has happened.
Constraints This is to be populated by NPCI.
Validation None
Compliance --
Conditional-Should be present in response for all those

transactions which are rejected by NPCI
Optional-None
Acquirer Reject Error in Reject Reason

Reason Code DE
A002 2 Card number absent in transaction request.
A003 3 If transaction type does not match with standard values.
A004 4 Amount absent in financial transactions.
A005 5 For international transaction this should be present.
A007 7 Transmission data and time absent in request.
A011 11 IF DE-11 i.e. STAN is absent in Request.
A012 12 If Transaction time is absent or Time exceeds its max limit i.e.
DE-12.
A013 13 If Transaction date is absent or Date exceeds its max limit.
A014 14 If absent in CNP transaction.
A018 18 If it is absent or present in negative MCC list.
A019 19 If acquirer institution country code is absent.
A022 22 If Pan entry mode and pin entry Cap is absent or not as per
standard list.
A023 23 For an EMV based transaction this should be present
A025 25 If it is absent or not as per the standard list
A032 32 If Acquirer ID absent or not as per the value for the acquirer in
standard table.
A035 35 If absent in card present transaction.
A037 37 If RRN is absent.
A040 40 If it is a CP transaction then should be present.
A041 41 If DE-41 is absent.
A044 44 If DE-44 is present in request from acquirer
A045 45 If not present in card present UID transaction.
A049 49 IF DE-49 is absent.
A052 52 If not present in pin based transactions

Acquirer Reject Error in Reject Reason

Reason Code DE
A054 54 If in Cashback transaction value in DE-54 greater than DE-4 or
DE 54 is absent
A055 55 If absent in chip based transaction
A090 90 If DE is not present in reversal request / advice
A095 95 If DE-95 absent in partial request or partial amount is greater
than or equal to transaction amount
A195 22,25,35, If DE-22 validation failed while checking with DE-25, DE-35,
45,52,55 DE-45, DE-52, DE-55 and DE-61.
and 61
Table 69 Acquirer Compliance Reject Reason code
Issuer Reject Error in Reject Reason

Reason Code DE
I003 3 Transaction type does not match with request.
I004 4 Transaction Amount does not match with request.
I006 6 Cardholder Billing Amount does not match with request
I007 7 Transmission Date and Time does not match with the request
I012 12 Transaction time does not match with the request
I013 13 Transaction date does not match with the request
I014 14 If it is present in response.
I019 19 Acquiring institution country code does not match with the
request.
I022 22 If present in response
I023 23 If not present in response for full issuer chip based transaction
I038 38 Authorization code not present in successful response.
Transaction will be rejected.
I039 39 Response code not present in response or not from the valid
list. Transaction will be rejected
I048 48 If Tag 054 is absent in response or tag 054 is N and DE 39=00
in response or DE 48 absent
I049 49 Value does not match with the request or not present in
response
I051 51 Value does not match with the request or not present in
response
I054 54 Absent in balance inquiry reply and logging in cash based
transaction.
I055 55 If not present in response for full issuer chip based transaction
Table 70 Acquirer Compliance Reject Reason code

8.3.32 DE – 45 Track I Data

DE – 45 Track I Data
Type ans..76
Format LLVAR
Description For UID based transaction DE 45 is required excluding start
and end sentinel and LRC characters. For international
transactions track 1 may be present.
Field Edits This remains for same for a transaction.
Constraints This should not be echoed back in a response.
Validation None
Compliance This field should compare with DE-22, 25, 61. For UID based
transaction track structure should be complied with NPCI
standards.
Conditional-For UID based transaction DE 45 is required. For

international transactions track 1 may be present.
Optional-None

8.3.33 DE – 48 Additional Data

DE – 48 Additional Data
Type ans…999
Format LLLVAR
Description Tag Presence Length Description Values
051 M an5 Product Code For E-commerce and POS
product code will be POS01.
For ATM transaction it will be

ATM01
052 C n..4 CVD2 Value -
053 C a1 CVD2 Match result M – Match
N- Not matched
054 C a1 CVD/iCVD Match result M – Match
code
N – Not matched.
055 C n2 Payments Indicator 01—Recurring payment
02—Instalment payment.
056 C n2 ECI indicators 05—Secure Ecommerce with 3D
06—Not authenticated.
Merchant attempted to
authenticate using 3D secure
07—Non-secure transactions
with data encrypted.
08—Non secure transaction
15-Secure E-Commerce
transaction registration with
OTP
16-Secure E-commerce
Internet banking
17-Secure E- commerce
other method
21 – Secure E- commerce
transaction with valid Image
select or valid OTP (OTP is used
for high value transaction)
22 – Non - Secure E- commerce

transaction with invalid Image
select and one day lock
23 - Non - Secure E- commerce

transaction with invalid Image
select and permanent lock
24 - Non - Secure E- commerce

transaction with browser close
and one day lock

25- Non - Secure E- commerce

transaction with browser close
and permanent lock
057 C n2 ICS1 result code 16- ICS1 authentication results
invalid
17- ICS1 failed validation-

authentication
02- ICS1 passed validation-
authentication
058 C an5 Fraud Score To be populated by NPCI
NPCI will send 00999 to the
issuer. 00999 indicate that
online fraud checking is not
performed by NPCI
059 C n26 EMI AMOUNT 1- 12 EMI Amount.
13- 24 Margin Amount
25-26 No of Instalments
(EMI amount)* number of
instalments + margin amount
should be equal to the
transaction amount(DE 4)
060 C n1 Transaction 1- Value should be ‘1’ if it is
Authorization Indicator authorized SUCCESSFULLY in
STIP. Only available in STIP for
Populated by NPCI
EMV FULL CHIP Issuers in STIP
during request for chip
mode.
transactions in case
issuer has availed for
2--Value should be ‘2’ if it is
on-behalf or EMV STIP
authorized in STIP. Only
services with RuPay.
available for MAGNETIC STIP.
Also used to indicate
Magnetic Card STIP
transactions and UIDAI / 5- ARQC validation is done by
Aadhaar authenticated RuPay and is SUCCESSFUL.
transactions.
6 - NPCI will reject the
transaction based on CVR
validation in case of Quick EMV.
Issuer will receive authorization
advice with this value.
7- ARQC validation failed at

RuPay when issuer is
participating in quick EMV
issuance or EMV STIP. Issuer
will received authorization
advice message with this value.
8 - NPCI will reject the

transaction based on TVR
validation in case of Quick EMV.
Issuer will receive authorization
advice with this value.
9-Transaction has been

authenticated by UIDAI
061 C n30 Transaction Id Transaction Id-contains a
unique transaction id that is
used for E-Commerce
transaction

062 C n6 Loyalty Points for debit Number of points accumulated

for the card.
Max value is 999999. If a
transaction has loyalty indicator
set then the issuer is expected to
debit the customer for
transaction amount and then
credit the customer with the
amount equivalent to loyalty
points redeemed
063 C n6 Loyalty Balance As a result of loyalty balance this
field will be populated with
loyalty points. Acquirer has to
generate appropriate slip
showing loyalty points.
064 C a1 ICS2 result code I=Invalid cryptogram
U-Unable to process
V-Valid
066 O n12 UID number UID Number – Aadhaar
Mandatory for all biometric (DE

22 subfield 3 is 9)
authentication based
transaction.
067 O an10 Income tax PAN number This contains the income tax
PAN number
068 C n40 ICS1 value Contains the ICS1 value for an e-
commerce transaction
069 C ans32 ICS2 value Contains the ICS2 value for an e-
commerce transaction
070 C an5 Data required by ICS1 This information is required by
ICS in order to authorize each
transaction
071 C ans…42 IP address for RuPay E- IP address of Shopper and
42 Commerce or 3D E- country code associated with the
Commerce IP address
Format is The default value of this field
XXXX…..XXXCCC will be 999999999999999
XXX…XXX is IP address
And CCC is country code
The IP address is IPv6

compliant
072 C n15 Transaction identifier This variable contains a
transaction identifier provided
by ICS, in the form of a 15-digit
sequence.
073 O Network data This information includes a
an…12
reference number generated by
First subfield-an3 the authorization system.
network code
Second subfield an..9
Network reference
number
074 O n12 Customer mobile This tag captures the customer
/telephone number mobile number including
country code
075 C an5 Image code This will contain the image code
value and will be populated by
NPCI
076 O an5 Personal phrase This will contain the personal
phrase value and will be

populated by NPCI
077 O ans..40 Issuer supplied ID / This tag is used in E-Commerce.
Unique ID The value in this tag is returned
by the Issuer Authentication
Server for registering the
customer for E-Commerce or
reference for authenticating the
card holder for high value
transaction.
078 ans40 RFU RFU
079 ans40 RFU RFU
080 ans40 RFU RFU
081 ans40 RFU RFU
Tag length is always represented in 3 bytes.

For an E-commerce transaction this field should be mandatory.
For an EMI transaction this field should be mandatory.
Constraints When present this is to be echoed back in a response.
Validation None
Compliance This is mandatory for all the transactions. Tags should be present as per the
transactions. But product code is mandatory in all messages.
Presence Tag Explanation
Tag 051 Should be present for all transactions
Tag 052 Should be present for all card not present transaction in request
Tag 053 Should be present for all card not present transaction in response for
secure transactions
Tag 054 Should be present for all card present transactions in response but
not mandatory for ATM transactions
Tag 055 Should be present for all Recurring payment transactions
Tag 056 Should be present for all E-Commerce transaction in request
Tag 057 should be present in both request and response for ICS1 based
transactions
Tag 058 Should be populated by NPCI and will be sent to the issuer as per
issuer configuration. Issuer will not send this to NPCI in response
Tag 059 Should be present for all EMI based transactions both in request and
response
Tag 060 Should be present for all EMV based transactions and to be populated
by NPCI and issuer will not send this in response. It also indicate
magnetic card STIP and Aadhaar authentication
Tag 061 Should be present in all E-commerce transaction request and not to
be echoed in response from the issuer ,However NPCI will send
populate this field in response and send this to the acquirer
Tag 062 Should be present for loyalty based transactions both in request and

response
Tag 063 Should be present for all loyalty enquiry transactions in response
Tag 064 Should be present for all E-commerce ICS2 based transactions both
in request and response
Tag 066 Acquirer can populate UID number in request. For all biometric
transactions this field is mandatory.
Tag 067 Acquirer can populate Income Tax PAN number in request
Tag 068 Should be present for E-Commerce transaction for ICS1 in request
Tag 069 Should be present for E- Commerce transaction for ICS2 in request
Tag 070, Should be present for all international based transactions

Tag 072,
Tag 073
Tag 071 Should be present for all E-Commerce transactions
Tag 074 This is an optional tag
Tag 075 Should be present for all E-Commerce transactions in request
Tag 076 This is an optional tag
Tag 077 This should be present for E-Commerce Registration transaction.
Tag 078 RFU Not defined
Product Code Description

ATM01 Transaction originated from ATM
AEP01 Transaction originated from microATM
POS01 Transaction originated from POS
IMP01 Transaction originated from Mobile
Table 71 Product Code
Dynamic Key Exchange

Double Length
Position Length Field Name

01-32 an 32 Key
33-36 an 4 Check value
Triple Length
Position Length Field Name

01-48 an 48 Key
49-52 an 4 Check value

8.3.34 DE – 49 Currency Code, Transaction

DE – 49 Currency Code, Transaction
Type n3
Format Fixed
Description 3 digit code that identifies the currency for a particular
transaction amount. Refer to ISO 4217 for currency code. For
domestic transaction this field will contain value 356
Constraints It is echoed in response.
Validation The currency code should be from the standard list
Compliance Must be present if DE-4 is present. The values should be
remains same during the complete transaction cycle.
Presence Mandatory-This field is mandatory across all messages
Conditional-None
Optional-None

8.3.35 DE – 50 Currency Code, Settlement

DE -50 Currency Code, Settlement
Type n3
Format Fixed
settlement amount. Refer to ISO 4217 for currency code
Validation This should be from the standard list
Compliance Must be present if DE-5 is present. This field is present in case
of multicurrency transactions.

present.
Optional-None

8.3.36 DE – 51 Currency Code, Cardholder Billing

DE – 51 Currency Code, Cardholder Billing
Type n3
Format Fixed
cardholder billing amount. Refer to ISO 4217 for currency code
Validation This should be from the standard list
Compliance Must be present if DE-6 is present. This field present in case of
multicurrency transactions.

present.
Optional-None

8.3.37 DE – 52 PIN Data

DE – 52 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. Mandatory
for all pin based transactions. If not a PIN based transaction
and an UID based then field 63 is to be filled.
If it is OTP transaction, Encrypted OTP (like ANSI PIN block)
should be populated in DE-52.
For a reversal and advice message this field is not required.
Constraints This is not echoed in a response.
Validation For a UID transaction this field is not required, field 63 is to be
populated.
Compliance The values should be in Standard ANSI DES format.
Conditional-Should be present for all Pin based transactions

where pin is entered as an authentication method. For Cash at
PoS transaction where the channel is POS this field should be
mandatory
Optional-None

8.3.38 DE – 54 Additional Amount

DE – 54 Additional Amount
Type an…120
Format LLLVAR
Description Digit 01-02 Account type
10 Savings
20 Checking
30 Credit Card
90 Cash back
Digit 03-04 Amount type/ Balance
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
Digit 8 Amount, sign
C Positive balance
D Negative balance
Digit 9-20 Amount
For balance enquiry this field is populated in
response.
For purchase with cashback request message, this field is

populated.
For purchase with cashback processing value in DE 3 would be
09. The value in DE 54 would be:
Position Value
1-2 90
3-4 90
5-7 356
8 D
9-20 Cash back amount n12
For e.g. A purchase with cashback transaction with cashback
amount of 100 would be: 0209090356D000000010000
On ATM Balance Inquiry and Cash Withdrawal with Balance

would be :
0401001356C0000029282001002356C000002916191
Field Edits None

Constraints If present in a request this is to be echoed in a response.
In case of Balance Enquiry, if acquirer is sending the

processing code as unspecified then issuer can respond back
with balance from either ‘Savings’ or ‘Current’ account. But
the account type in Processing code and Additional should be
same.
Validation Additional amount should be of this format as given in the

description.
Compliance The values should be present for cashback transactions and
value should be less than the transaction amount in DE-4.
This field is mandatory in balance inquiry response.
Conditional-For all purchase with cashback transactions this
should contain the cash amount
Optional-None

8.3.39 DE – 55 Chip Data

DE – 55 Chip Data
Type b...255
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 the message layouts (see
below). Each element will consist of three sub components, a
“Tag”, a “Length” and a “Value”. The tag and the length are
hexadecimal values.
Name Length (Bytes)
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.
Unexpected EMV Tags: This field may contain tags that the
receiving issuer or acquirer does not recognize or does not expect.
The receiver must ignore such tags and continue parsing the next
tag in DE 55
Field Edits None
Constraints For full chip issuer transactions, DE 55 will be sent to the issuer in
request.
For full issuer, DE 55 may be sent by the issuer in the response.
Refer to RuPay EMV implementation guide for Acquirer and Issuer

for details.
Validation The tags that are mandatory as per RuPay EMV requirements
should be present for a chip based transaction.
Compliance Mandatory tags should be present in request mentioned in below
table.
Conditional – For all chip based transaction
Optional – None
8.3.39.1 Authorization Message DE – 55 Presence Descriptions

# EMV Tag Name Length Format Usage
0100 / 0200
0110 / 0210
0120 / 0220
0130 / 0230
Tag
0420
0430
1 9F02 Amount 6 n 12 M - M - M - Authorised amount of the

Authorized transaction (excluding
adjustments)
2 9F03 Amount Other 6 n 12 C - C - C - Mandatory if cash over (cash

back) transaction OR if input

0100 / 0200
0110 / 0210
0120 / 0220
0130 / 0230
Tag
0420
0430
to application cryptogram
(ARQC/TC/AAC) calculation.
3 9F26 Application 8 b M - M - M - Cryptogram returned by the

Cryptogram ICC in response of the
GENERATE AC command
4 9F06 Application 5-16 b O - O - O - Identifies the application as

Identifier (AID) described in ISO/IEC 7816-5
– Terminal
5 82 Application 2 b M - M - M - Indicates the capabilities of

Interchange the card to support specific
Profile (AIP) functions in the application
6 9F36 Application 2 b M - M - M - Counter maintained by the

Transaction application in the ICC
Counter (ATC) (incrementing the ATC is
managed by the ICC)
7 9F07 Application 2 b O - O - O - Indicates issuer‘s specified

Usage Control restrictions on the
geographic usage and
services allowed for the
application
8 9F27 Cryptogram 1 b M - M - M - Indicates the type of

Information cryptogram and the actions
Data (CID) to be performed by the
terminal
9 9F34 CVM Results 3 b O - O - O - Indicates the results of the

last CVM performed
10 84 Dedicated File 5-16 b O - O - O - Identifies the name of the DF

Name as described in ISO/IEC
7816-4
11 9F1E Interface 8 an 8 O - O - O - Unique and permanent serial

Device (IFD) number assigned to the IFD
Serial Number by the manufacturer
12 9F10 Issuer Var. b M - M - M - Contains proprietary

Application up application data for
Data (IAD) to 32 transmission to the issuer in
an online transaction
13 91 Issuer 8-16 b - C - - - - Data sent back to the ICC as

Authentication response data for online
Data issuer authentication.
Mandatory for online
successful transactions OR if
any script/s are sent to the

0100 / 0200
0110 / 0210
0120 / 0220
0130 / 0230
Tag
0420
0430
card by the issuer
14 9F5B Issuer Script Var. b - - C - C - Present if scripts were sent

Results Up by issuer in original
to 25 response
15 71 Issuer Script Var. b - C - - - - Contains proprietary issuer

Template 1 up data for transmission to the
to 127 ICC before issuing the second
GENERATE AC command.
Present if sent by Issuer
16 72 Issuer Script Var. b - C - - - - Contains proprietary issuer

Template 2 up data for transmission to the
to 127 ICC after completion of the
second GENERATE AC
command. Present if sent by
Issuer
17 9F09 Terminal 2 b O - O - O - Version number assigned for

Application the application
Version
Number
18 9F33 Terminal 3 b M - M - M - Indicates the capabilities of

Capabilities the terminal, like card data
input method, CVMs, security
functions etc.
19 9F1A Terminal 2 n3 M - M - M - Indicates the country of the

Country Code terminal, represented
according to ISO 3166
20 9F35 Terminal Type 1 n2 O - O - O - Indicates the environment of

the terminal, its
communications capability,
and its operational control
21 95 Terminal 5 b M - M - M - Status of the different

Verification functions as seen from the
Results (TVR) terminal
22 5F2A Transaction 2 n3 M - M - M - Indicates the currency code

Currency Code of the transaction according
to ISO 4217
23 9A Transaction 3 n6 M - M - M - Local date that the

Date YYMMD transaction was authorized
D
24 9F41 Transaction 2-4 n 4-8 O - O - O - Counter maintained by the

Sequence terminal that is incremented

0100 / 0200
0110 / 0210
0120 / 0220
0130 / 0230
Tag
0420
0430
Counter by one for each transaction
25 9C Transaction 1 n2 M - M - M - Indicates the type of

Type financial transaction,
represented by the first two
digits of the ISO 8583:1987
Processing Code.
26 9F37 Unpredictable 4 b M - M - M - Random number generated

Number by terminal unique for each
transaction.
27 4F ICC Application Var B O - O - O - ADF name (AID) returned by

ID (…16) ICC, as read from directory
file, in template 61
Table 72 DE 55 Presence Descriptions

8.3.40 DE – 60 Advice Reason Code

DE – 60 Advice Reason Code
Type an .7
Format LLVAR
Description This field gives the reason for which an advice is sent.
This is used in all advice messages.
1001 – Issuer signed off
1002 – Issuer Time out / not responding
Constraints If it is present it is to be echoed in response.
Validation This field should be present for all authorization advice
messages
Compliance If transaction is authorized in STIP, values should be same as
mentioned above while sending to Issuer.
Conditional-For all STIP based transactions this should be

present
Optional-None

8.3.41 DE – 61 PoS Data Code

DE – 61 PoS Data Code
Type ans...999
Format LLLVAR
Description This determines the data input capability
Subfield 1: Card Data Input Capability
Value Description
0 Unknown
1 Magnetic Stripe Read capability
2 ICC Capability
3 Magnetic stripe and key entry
capability
4 Magnetic stripe and ICC capability
5 Manual, no terminal
6 Key entered
Subfield 2: Cardholder Authentication Capability
Value Description
0 Unknown
1 No electronic authentication
2 PIN Entry
3 Biometric
Subfield 3: Card Capture Capability
Value Description
0 Unknown
1 No capture capability
2 Capture Capability
Subfield 4: Terminal Operating Environment
Value Description
0 Unknown
1 On premises of card acceptor,
attended
2 On premises of card acceptor,
unattended
3 Off premises of card acceptor,
attended
4 Off premises of card acceptor,
unattended
5 On premises of cardholder,
unattended
6 No terminal used
Subfield 5: Cardholder Present Data
Value Description
0 Unknown
1 Cardholder present
2 Cardholder not present, unspecified
reason
3 Cardholder not present, Mail
transaction
4 Cardholder not present, telephone
transaction
5 Cardholder not present, standing

instruction
6 E-Commerce transaction
7 IVR transaction
Subfield 6: Card Present Data
Value Description
0 Unknown
1 Card not present
2 Card Present
Subfield 7: Card Data Input Mode
Value Description
0 Unknown
1 Manual Input, no terminal
2 Magnetic Stripe read
3 Online Chip / Contact Chip
4 Offline chip / Contactless
5 Ecommerce
6 IVR
7 Key entered
Subfield 8: Cardholder Authentication method
Value Description
0 Unknown
1 Not authenticated
2 PIN
3 Signature
4 Biometric (FMR)
5 OTP
6 E-Commerce Type1 Pin
7 E- Commerce Type1 OTP
8 E-com Type 2
9 IVR Type 2
A Biometric(FIR)
B Biometric(IIR)
C Biometric PIN
D Biometric OTP
E Biometric (FIT/FMR/IIR) with PIN
F Biometric (FIT/FMR/IIR) with OTP
Subfield 9: Cardholder Authentication Entity
Value Description
0 Unknown
1 ICC
2 CAD
C Type 3 (3D if issuer opted for ICS 1
services)
D Type 4 (3D if issuer opted for ICS 2
services)
A Type 1 (RuPay E-Commerce
Implementation)
I Type 2 (3D if issuer opted for RuPay
services)
Subfield 10: Card Data Output Capability
Value Description
0 Unknown

1 Magnetic Stripe write

2 ICC Write
Subfield 11: Terminal Data Output Capability
Value Description
0 Unknown
1 Print capability
2 Display Capability
3 Print and Display Capability
Subfield 12: PIN Capture capability
Value Description
0 No PIN capture capability / Unknown
1 4 chars maximum
2 5 chars maximum
3 6 chars maximum
4 7 chars maximum
5 8 chars maximum
6 9 chars maximum
7 10 chars maximum
8 11 chars maximum
9 12 chars maximum
Subfield 13 position 13-21: Zip Code
Sr No. Zip Code
1 Merchant Postal Code : ans 9, Left
padded with zeroes
If zip code contains all zeroes/all

spaces then the transaction will get
rejected
Subfield 14 position 22-41:POS Additional Merchant Address
data
Sr No. Additional Address data
1 Address/merchant telephone/mobile
number
ans 20(recommended right padded
with spaces)
Field Edits/ Compliance This field remains the same for a particular transaction.
Constraints This is not to be echoed back in response.
Validations This field should be of the format as described in the above
description
Compliance This is mandatory field and acquirer has to populate values in
this field as per the values mentioned above.
Conditional-None
Optional-None

8.3.42 DE – 62 Private Data 1-Biometric Data

DE – 62 Private Data 1
Type ans…999
Format LLLVAR
Description UIDAI Authentication Code. This data element is used in
response message to send the authentication code received
from UIDAI server to the issuer. NPCI will send this
authentication code to the acquirer in response.
Constraints This value will only be populated by NPCI, if received from
UIDAI.
This message is used for biometric transaction
Validation None
Compliance None
Presence Optional

8.3.43 DE – 63 Private Data 2, Encrypted Biometric Data

DE – 63 Private Data 2, Encrypted Biometric Data
Type ans… 999
Format LLLVAR
Description It contains finger print minutiae collected at the device /
terminal. Either of DE 52 or DE 63 will be populated as per
transaction authentication
In reversal and advice message this field is not required.
Constraints It is not to be echoed in response.
Validation
Compliance For a UID based transaction with biometric authentication this
field is mandatory.
Conditional-For all UID based transactions this should be

present
Optional-None

8.3.44 DE – 70 Network Management Information Code

DE – 70 Network Management Information Code
Type n3
Format Fixed
Description These messages are used by the members and NPCI for sign in
and sign off.
Digit 1 – 3 Description
001 Log on
002 Log off
201 Cut over
301 Echo Test
164 Request new PEK. Single key used for
both acquirer and issuer
184 PEK key exchange
Field Edits This field is used in network management messages.
Constraints It is to be echoed in response.
Validation This field should be from the list described above.
Compliance None
Presence Mandatory-Should be present for all network management
messages
Conditional-None
Optional-None

8.3.45 DE – 90 Original Data Element

DE -90 Original Data Element
Type n 42
Format Fixed
Description Contains information for tracking the current message back to
prior messages for same cardholder transaction.
Position Description
1-4 Original message type
5-10 Original STAN number
11-20 Original Transmission date and time
21-31 Original acquirer ID
32-42 Original forwarding institution id
For reversal this field is required.
Constraints If present this is to be echoed in response as well.
Validation Original data elements should be of this format as described in
the description.
If DE 90 is absent in request /not matching with the original
transaction then the transaction will not be sent to the issuer
Compliance Values in this field should match with the original transaction
and use for matching purpose.
Presence Mandatory-Present in reversal messages
Conditional-None
Optional-None

8.3.46 DE – 91 File Update Code

DE – 91 File Update Code
Type an 1
Format Fixed
Description File update code contains a digit which specifies either to add a
record, delete a record, change an existing record, replace a
record or retrieve a copy of the existing record
Value Description
1 Add a new record if one does not exist
2 Change an existing record
3 Delete an existing record
4 Replace, Add is record does not exist
and replace in case record exists
For a file update message this field is required
Validation Original data elements should be of this format as described in
the description
Compliance For file update message this field should be present.
Presence Mandatory-For a file update message this should be present
Conditional-None
Optional-None

8.3.47 DE – 95 Replacement Amount

DE – 95 Replacement Amount
Type an 42
Format Fixed
Description This field contains the partial amount that is dispensed.
Position Description
1-12 Actual amount, transaction
13-24 Actual amount, settlement
25 Actual transaction fee sign
26-33 Actual transaction fee
34 Actual settlement fee sign
35-42 Actual settlement fee
(1-12) Actual amount, transaction contains the corrected

dispensed amount including the Actual transaction fee (26-33)
with indication of Actual transaction fee sign in (25).

For partial reversal this field is required.
Validation For an ATM transaction if DE 95 is greater than DE 4 then the
transaction should get rejected.
Compliance The amount should be less than transaction amount in DE-4.
Conditional- Present in partial reversal messages
Optional-None

8.3.48 DE – 101 File Name

DE – 101 File Name
Type ans..17
Format LLVAR
Description This field contains the name of the file to be updated
Constraints If present it is to be echoed in response.
Validation None
Compliance None
Conditional-None
Optional-Present for all file update message

8.3.49 DE – 102 Account Identification 1

DE – 102 Account Identification
Type ans..19
Format LLVAR
Description This field contains the cardholder account number.
In Card to Card fund transfer, for debit transaction ‘TD’ issuer

Bank must send the “From Account Number” from which will
be debited for transfer amount. i.e. the cardholder account
number.
Field Edits None
Constraints None
Validation None
Compliance None
Conditional-None
Optional-Present for all messages if present

8.3.50 DE – 103 Account Identification 2

DE – 102 Account Identification
Type ans..19
Format LLVAR
Description This field contains the cardholder account number.
In the Card to Card fund transfer transactions (FT), Acquirer
Bank must send the “To Card Number” which is to be credited
for the transfer amount.
In the transfer Credit transactions (TC), Beneficiary Bank must

send the “To Account Number” which is credited for the
transfer amount.
Field Edits None

Constraints None
Validation None
Compliance None
Conditional-None

8.3.51 DE – 120 Private Data 3

DE – 120 Private Data 3
Type ans… 999
Format LLLVAR
Description This contains additional data especially for ATM, UID and
IMPS.
Validation None
Compliance None
Conditional- None
Structure of DE – 120 for Mobile and UID based transaction
Tag Description Length Value Comments

Merchant Payment request
001 (Transaction Type) M 2 46
002 (Product Indicator) M 3 MOB
046 (Merchant Name) M 3 (max 20) ABCD
049 (MAS) M 3 Value
050 (Merchant MMID + M 17 (Max 20) MMID+10 digit
Mobile number) mobile
Number
051(Payment Reference) O 50(Max) Value
053 (Merchant location) O 18 Merchant city (13) +
Merchant state (3) +
Merchant country
(2)
055 (OTP Indicator) M 1 Y or N
056 (Originating M 3 (max 4) MOB (for mobile
channels) banking
application),
SMS (for SMS), WAP,
IVR, USSD, POS
057 (MCC) M 4 Value
Merchant Payment Response
045 (Customer Name) M 5 (max 20) WXYZ
Number
054 (Customer location) O 18 Merchant city (13) +
Merchant country
(2)


Merchant Payment Reversal Request
049 (MAS) M 3 Value
Number
053 (Merchant location) O 18 Merchant city (13) +
Merchant country
(2)
055 (OTP Indicator) M 1 Y or N
056 (Originating M 3 (max 4) MOB (for mobile
channels) banking
application),
SMS (for SMS), WAP,
IVR, USSD, POS
057 (MCC) M 4 Value
Merchant Payment Reversal Response
045 (Customer Name) M 5 (max 20) WXYZ
049 (MAS) M 3 Value
Number
054 (Customer location) O 18 Merchant city (13) +
Merchant country
(2)
P2P Mobile Transfer Request
001 (Transaction type) M 2 45
045 (Remitter’s Name) M 7 (Max 20) ABCD
049 (MAS) M 3 Value
050 (Remitter’s NBIN + M 17 (Max 20) NBIN+00+1+10 digit
Mobile Number) mobile number
P2P Mobile Transfer Response
046 (Beneficiary Name) M 7 (Max 20) WXYZ
P2P Mobile Transfer Verification Request


047 (Original Transaction M 14(Max 80) Populate MTI, DE 12,
data) 13,
049 (MAS) M 3 Value
P2P Mobile Transfer Verification Response
046 (Beneficiary Name) M 7 (Max 20) WXYZ
AEPS based Fund Transfer Request
002 (Product Indicator) M 3 UID
045 (Sender Name) M 20 ABCD
060 (Sender Aadhaar) M 20 Sender Aadhaar
AEPS based Fund Transfer Response
002 (Product Indicator) M 3 UID
045 (Sender Name) M 20 ABCD
046 (Beneficiary Name) M 20 WXYZ
060 (Sender Aadhaar) M 20 Sender Aadhaar
Structure of DE – 120 for ATM transaction (Pin change in request)

001 Transaction 2 08 Pin Change
Type
002 Product 3 GDN GDN (ATM based transaction)
Indicator
004 New PIN 16 New PIN Block
Block
Structure of DE – 120 for ATM transaction (Pin change in response)

001 Transaction 2 08 Pin Change
Type
Indicator
Structure of DE – 120 for ATM transaction (Mini statement in request)

001 Transaction 2 07 Mini Statement
Type
Indicator
Structure of DE – 120 for ATM transaction (Mini statement in response)


001 Transaction 2 07 Mini Statement
Type
Indicator
005 No. of lines 2 n No of lines for mini statement data is 10.
for mini VALUE-10
statement
006 Mini 350 ans Each statement will be of 35 character
statement and bank should send the trailing spaces
data of there is no any data
The mini statement data has of 35
characters in width and 10 rows should
be sent. The data will be 9+1 that is 9
statements and 1 balance data should
send.
For example the field 120 for 10
statements of mini statement transaction
is as follows:
38100100207002003GDN00500210006350040621DR
UMA 000001250100040621DR UMA
000002200000040621DR UMA
000004500000040619DR ATM
000001500000040619DR UMA
000004500000040619DR UMA
000001400000040619DR UMA
000001400000040618DR ATM
000001500000040617DR ATM
000000540000Balance 000014354303+
381 – is the length of the field 120.
001 - Tag 1
002 – Data length of tag 1
07 – Value of Tag 1. (Transaction type)
002 – Tag 2
GDN – Value of Tag 2. (Product type)
005 – Tag 5
10 – Value of tag 5 (This will be fix 10)
006 – Tag 6
350 – Data length of tag 6 ( 10 row of 35
characters each)
This tag contains mini statement data of
10 statements containing of 35
characters each. The data is as follows
040621DR UMA 000001250100
040621DR UMA 000002200000
040621DR UMA 000004500000
040619DR ATM 000001500000
040619DR UMA 000004500000
040619DR UMA 000001400000
040619DR UMA 000001400000
040618DR ATM 000001500000
040617DR ATM 000000540000
Balance 000014354303+

Structure of DE – 120 for Bill Pay

003 Bill payment presentment amount
005 Mobile voucher number, encrypted for
mobile voucher GSM Recharge transaction
006 Bill payment prompt codes
007 Bill payment vendor types
008 Bill payment relationship owner
009 Bill payment relationship ID codes
010 Mobile voucher serial number
011 BIN new PIN value encrypted
Card to Card Funds Transfer:
Fund Transfer from acquirer:
 0200 Request will contain the following details for Fund Transfer transaction.
Tag Mandatory/optional Length Value

001 (Transaction Type) M 2 FT
002 (Product Indicator) M 3 SPT
Fund Transfer to acquirer:
 0210 Response will contain the following details for Fund Transfer transaction.
TAG Mandatory/optional Length VALUE

001 (Transaction Type) M 2 FT
002 (Product Indicator) M 3 SPT
For Transfer Debit Transaction from NPCI to issuer and issuer to NPCI
 0200 Request will contain the following details for Fund Debit transaction.
Tag Mandatory/optional Length Value

001 (Transaction Type) M 2 TD
002 (Product Indicator) M 3 GFD
 0210 response will contain the following details for Fund Debit transaction:

001 (Transaction Type) M 2 TD
002 (Product Indicator) M 3 GFD
For Transfer Credit Transaction from NPCI to beneficiary and from beneficiary to NPCI
 0200 Request will contain the following details for Fund Credit transaction.

001 (Transaction Type) M 2 TC

002 (Product Indicator) M 3 GFC
 0210 response will contain the following details for Fund Credit transaction:

001 (Transaction Type) M 2 TC
002 (Product Indicator) M 3 GFC
Cheque Book Request Transaction
0200 will contain the following details for Cheque Book Request Transaction

002 (Product Indicator) M 3 GDN
0210 will contain the following details for Cheque Book Request Transaction

Statement Request Transaction
0200 will contain the following details for Statement Request Transaction

0210 will contain the following details for Statement Request Transaction

Mobile Number Update Transaction
0200 will contain the following details for Mobile Number Update Transaction

001 (Transaction Type) M 2 UR
0210 will contain the following details for Mobile Number Update Transaction

001 (Transaction Type) M 2 UR

8.3.52 DE – 121, 122, 123 Private Data 4 – 6

DE -121, 122, 123 and 127 Private Data 4 – 7
Type ans...999
Format LLLVAR
Description
Validation
Compliance
Conditional-None

8.3.53 DE – 124 File Action Record and Data

DE – 124 File Action Record and Data
Type n2/ b…255
Format LLLVAR
Description Position Message type field
1 and 2 Value should be file maintenance i.e. ‘03’
3 Message type function and value should be
‘0’
4 Message type transmission mode value
should be ‘0’
5 and 6 Action Code:
04 - Pick up card (no fraud)
05 - Do not honour
07 - Pick up card, special condition (fraud)
11 - Approval for NPCI
41 - Lost card, pick up (fraud)
43 -Stolen card, pick up (fraud)
For a file update message this field is required
Constraints If present in a request this is to be echoed in a response.
Validation
Compliance For a file update message this field should be mandatory

8.3.54 DE – 126 Additional Data-Biometric Data

Type ans…999;
Format LLLVAR
Description These fields are Tag-based. They will carry ‘Uses’, ‘fdc’, ‘idc’,
‘pip’, ‘lot’, ‘lov’, ‘ki’ and ‘type’ in tag 001, tag 002, tag 003, tag
004, tag 005 , tag 006, tag007 and tag 008 respectively
This message is used for biometric transaction.
Constraints If present this is not to be echoed in response
Validation None
Compliance None
Conditional-None
The below table list the tags used for DE 126:
Tag Lengt Type Format Description Valid Value

h
001 9 Fixed A Uses(authentication factors Please refer below
used by the request) table
002 10 Variable An Fdc (Finger print device Fingerprint device
code by UIDAI portal) code by UIDAI portal
003 10 Variable An idc (IRIS device code by IRIS device code by

UIDAI portal) UIDAI portal
004 15 Variable An pip (Public ip of terminal) Public ip of terminal
005 1 Fixed A lot (Location type) G/P
006 50 variable Ans lov (Pin code of place of txn (Pin code of place of
or geo coding in lat, long txn)
format)
007 32 Fixed An ki(Synchronized Session As per the process.

(optional) Key identifier) Only to be used
when using
synchronized
session key
mechanism
008 1 Fixed A type(Type of PID block X/P
format)
Note: All the tags except 007 are mandatory in the DE-126.

Description of Tag 001
1 2 3 4 5 6 7
Pi pa Pfa bio bt pin otp
y' or 'n' y' or 'n' y' or 'n' y' or 'n' FMR or FIR orIIR y' or 'n' y' or 'n'
Example for Tag001: ‘nnnyFMRnn’
For a KYC authentication transaction value of tag 001 can be as follows*

1. yyyyFMRnn
2. yyynFMRnn
*Assuming bt=FMR, otp & pin not being used. However, if the same is used the value of
tag 001 will change accordingly.
The generic description of DE126 is as follows:
<Tag number><Tag length><Tag data><Tag number><Tag length><Tag data>…

8.3.55 DE –127 Additional Data-Biometric Data

Type ans…999;
Format LLLVAR
Description These fields are Tag-based. They will carry ‘skey’, ‘ci’, ‘Hmac’,
‘ac’, ‘sa’ and ‘lk’ in tag 001, tag 002, tag 003, tag 004, tag 005
and tag 006 respectively
Constraints If present this is not to be echoed in response
This message is used for biometric transaction

Validation None
Compliance None
Conditional-None
Tag Length Type Format Description Valid Value

001 As per the Fixed an Skey(Value of this element is Digest value
process encrypted 256-bit AES session
key.)
002 8 Fixed YYYYMMDD ci (Public key certificate It is the expiry

identifier using which “skey” date of the UIDAI
was encrypted) public key, a
constant value.
003 As per the Fixed an Hmac(for description on Hmac SHA -256 Hash
process please refer to of PID XML and
http://uidai.gov.in/images/F then encrypted
rontPageUpdates/aadhaar_a
uthentication_api_1_5_rev1_1.
pdf)
004 010 Variable an ac (A unique code for the AUA An Alpha

which is assigned by UIDAI numeric value
during AUA registration up to 10
process) characters
005 010 Variable an sa (A unique “Sub-AUA” code, An Alpha

managed by AUA within their numeric value
system and ensure uniqueness. up to 10
If AUA and SA are same agency, characters
use value of “ac” for this
attribute.)
006 064 Variable an lk (A valid “License Key” An Alpha
assigned to the AUA through numeric value
administration portal of UIDAI. up to 64
These license keys have expiry characters
built into them and AUA

administrator need to ensure

that they generate new license
keys before current ones
expires through self-service
portal.)
DE 127 is structured as TLV (Tag, length and value) field. The details of tags and contents are
described below:
Example:
Let’s assume that skey length is 256 bytes, ci length is 8 bytes, Hmac is 48 bytes, ac is 10 bytes,
sa is 10 bytes and lk is 64 bytes. The structure of DE127 is shown below:
432001256<skey>002008<ci>003048<Hmac>004010<ac>005010<sa>006064<lk>
Parsing of field is done as follows:
432 is the total length of the string for DE 127.
1. Tag 001 represents skey which is of length 256 char.
2. Tag 002 represents ci which is of length 8 char.
3. Tag 003 represents Hmac which is of length 48 char
4. Tag 004 represents ac which is of length 10 char
5. Tag 005 represents sa which is of length 10 char
6. Tag 006 represents lk which is of length 64 char
Usage:
The generic description of DE127 is as follows:
<Tag number><Tag length><Tag data><Tag number><Tag length><Tag data>…

Compliance Member Compliance Acquirer
Chapter 9 Compliance
9.1 Member Compliance Acquirer
The following section describes various compliances for acquirers.
9.1.1 General Compliance

 Message sent to NPCI must be formatted as per the specification defined in this
document
 Acquirer must not store any sensitive information from the transaction like PIN/OTP,
Track, expiry date and CVD/ CVD2.
 Track 1 (DE 45) must be present in a transaction which is carried out using UID.
 Acquirer will take all care for configuring the POS devices correctly i.e. TID, MCC,
address, location, date and time setting etc. Country code in POS device should be
populated correctly.
 Acquirer has to generate reversal for the transaction for which response is not received
within the time-out parameter defined for acquirer.
 In a situation wherein NPCI system encounters a format error with the request message
sent by acquirer, NPCI will send a decline message to acquirer. No reversal needs to be
generated by the acquirer for such decline message on account of format error.
 For all transactions product code should be present (DE 48, Tag 051).
9.1.2 Transaction Wise Compliance

The following section describes transaction wise compliance for acquirers.
Purchase Message
 For an UID based transaction Track 1 data should be present.

 For all Card present transactions, track 2 data or track 1 data must be present.
 For all purchase with cash back transactions, cash amount should be present in DE 54
and DE 54 should be less than DE 4.
 For cash at POS transactions, DE 4 should contain the cash amount.
 For all CNP transactions, DE 14 and DE 48(tag 052) is mandatory.
 For all chip based transactions DE 55(all mandatory tags) and DE 23 should be
mandatory.
 Biometric data must be encrypted using encryption standards specified by UIDAI and
should be populated in DE 63.
E-Commerce Purchase
 For an Ecommerce transaction acquirer must ensure to populate E-Commerce indicator

and ICS DATA 1/ICS DATA 2 values (DE – 48 tags, 056,068,069).
 DE 14 should be mandatory for an e-commerce transaction.
 Transaction id should be mandatory (DE 48 tag 061).
 CVD2should be mandatory (DE 48 tag 052).
 OTP indicator must be present for transaction carried out by OTP. (DE 61 subfield 8)

Compliance Member Compliance Acquirer
 OTP password should be populated in DE 52.

 For an E-commerce transaction DE 22 should be 810.
 For an E-commerce transaction DE 25 should be 59.
Balance Inquiry
 For balance inquiry transaction the transaction amount (DE-4) must contain value 0.
 For all CNP transactions, DE 14 should be mandatory.
mandatory.
 Biometric data must be encrypted and put in DE 63 by the encryption standards
specified by UIDAI for UID transaction.
ATM Cash Withdrawal
 For ATM Cash Withdrawal transaction the transaction amount (DE-4) should NOT
contain value all zeros.
mandatory.
Balance Inquiry Loyalty
 For a balance enquiry loyalty, (DE 48 tag-063) should be mandatory as field will be
populated with loyalty points. Acquirer has to generate appropriate slip showing loyalty
points.
 .For all CNP transactions, DE 14 should be mandatory.
mandatory.
 It is only used for domestic transactions.
EMI Purchase
 For EMI transaction acquirer needs to populate custom data in DE 48 (tag – 059) like ,
margin amount, number of instalment and EMI amount.
mandatory.
Loyalty Redemption

Compliance Member Compliance Issuer
 For loyalty transaction acquirer must ensure to populate loyalty points for debit (DE 48
tag - 062).
 For all CNP transactions, DE 14 and DE 48(tag 052) should be mandatory.
mandatory.
Reversal
 For a reversal transaction acquirer should not populate DE 14, DE 35, DE 52, DE 45, DE
61, DE 63.
 A reversal transaction should always be send as an advice.
 A reversal must be generated within next 3 cutover from the date of transaction with the
original transaction detail like RRN, date, time, amount, PAN, currency code.
 Acquirer should send STAN & RRN of original transaction in reversal messages.
 For partial reversal Replacement Amount DE-95 should be less than DE-4 transaction
amount.
Authorization Advice
 An acquirer may generates an Advice (0420 message) for reversal. If it cannot be

transmitted within the acquirer’s timeout values, acquirer has to necessarily store this
as store-and-forward (SAF) message and must transmit this once the NPCI
communication is re-established. In case, acquirer system is aware that original message
cannot be delivered to NPCI for whatsoever reason, acquirer system to decline the
transaction and not generate any reversal.
 Authorization advices should not carry DE 35, DE 52, DE 14, DE 63, and DE 45.
9.1.3 Standards related to Compliance

 All messages should comply with ISO 8583:1987 standards with the deviation
mentioned as per NPCI Online message specification.
 PIN accepted on the terminal must be encrypted with TDES.
9.2 Member Compliance Issuer

The following section describes various compliances for acquirers.
9.2.1 General Compliance

 Message sent to NPCI must be formatted as per the specification defined in this
document.
 Issuer need to verify all authentication related data like PIN, OTP, ECI, ICS DATA 1,
CVD1, CVD2, ICS DATA 2, biometric etc.

 Issuer need to respond the request within the issuer time out parameter, failing which
NPCI will generate reversal towards issuer and decline response / STIP authorization
towards acquirer for the transaction.
 Issuer need to populate all the data elements in the response as per the message
specification.
 All advice messages need to be acknowledged.
 Customer and device sensitive data like PIN, expiry date, track, POS condition code, POS
Entry Mode must not be echoed back in the response
 Issuer may receive reversal up to next 3 cutover. Each cut-over cycle is of 24 hours.
 For all successful transactions Issuer needs to populate DE 38.
9.2.2 Transaction Wise Compliance

The following section describes transaction wise compliance for issuers.
Purchase Transaction
 Issuer need to populate approval code DE 38 for all approved transaction (DE 39 = 00);
failing which NPCI may reject the transaction.
 For cashback transaction or a purchase with cashback transaction the cash amount is to
be populated in DE 54.
 For all purchase transactions, DE 14, DE 18, DE 22, DE 23, DE 25, DE 35, DE 45, DE 52,
DE 61, DE 63 should not be sent in the response.
 For a CNP transaction DE 48 tag 053 should be present.
E-Commerce Purchase
 For all E-commerce transactions, DE 14, DE 18, DE 22, DE 23, DE 25, DE 35, DE 45, DE
52, DE 61, DE 63 should not be sent in the response.
Balance Inquiry
 For balance enquiry transaction DE 54 should be populated with balances.

 For balance enquiry transactions, DE 14, DE 18, DE 22, DE 23, DE 25, DE 35, DE 45, DE
52, DE 63 should not be sent in the response.
Balance Inquiry Loyalty
 If a transaction is a loyalty balance enquiry then DE 48 tag – 063 will be populated with
loyalty points.
 For all balance enquiry transactions, DE 14, DE 18, DE 22, DE 23, DE 25DE 35, DE 45, DE
52,DE 61, DE 63 should not be sent in the response.
EMI Purchase
 For all EMI purchase transactions, the issuer need to process taking into consideration
various tags in DE48 tag 059 like EMI amount, number of instalments etc.
Loyalty Redemption

 If a transaction has loyalty indicator set then the issuer is expected to debit the customer
for transaction amount and then credit the customer with the amount equivalent to
loyalty points redeemed DE 48 tag 062.
Reversal
 For all reversal transactions, DE 14, DE 18, DE 22, DE 23, DE 25, should not be sent in
the response.
 Issuer should always send a reversal advice response.
Authorization Advice
 Issuer need to check all the advice (authorization and reversal) before posting the same
to customer account to avoid duplicate posting.
 For all authorization advice transactions, DE 14, DE 18, DE 22, DE 23, DE 25, should not
be sent in the response.
 In case of an authorization advice message sent by RuPay to a FULL CHIP issuer (for
RuPay Chip transaction/s authorized by RuPay in STIP mode) the issuer, while building
the response, should check the CHIP Transaction Authorization Indicator (DE 48 tag
060). The value of this indicator must be equal to 1 for an approved transaction.
9.2.3 Standards related to Compliance

 All messages should comply with ISO 8583:1987 standards with the deviation
mentioned as per NPCI Online message specification.

Annexure 1-Card to Card Fund Transfer Member Compliance Issuer
Annexure 1-Card to Card Fund Transfer

Transaction Flow for Card To Card Funds Transfer
 The Cardholder inserts his card into the ATM.
 Cardholder will enter the ATM card PIN.
 Cardholder selects the card to card funds transfer at the ATM.
 The Cardholder is requested to enter the beneficiary’s card number.
 Once the cardholder enters proceed, a new fund transfer message will be initiated from
the ATM.
 The Acquirer switch will forward the fund transfer to NPCI irrespective of initiator or
remitter card is onus or off us.
 Depending on the cardholder bin NPCI will initiate a debit leg to the issuer bank.
 Issuer bank will debit the cardholder account for the transfer amount and respond to
NPCI with the successful response.
 On receiving a successful response from issuer NPCI will initiate a credit leg to the
beneficiary bank.
 Beneficiary bank will credit the beneficiary account with the transfer amount and
respond to NPCI with successful response.
 On receiving successful response from the beneficiary NPCI will respond to the acquirer
switch with successful response.
 Acquirer switch will respond to the ATM with successful response.
 Cardholder will be provided with the appropriate receipt at the ATM saying that the und
transfer transaction went successful.
Maximum Response Time

 Acquirer Timeout for card to card funds transfer=30 seconds
 NPCI Timeout for Issuer Bank is 20 seconds
 NPCI timeout for Beneficiary bank is 8 seconds.

Annexure 2 -State Code Member Compliance Issuer
Annexure 2 -State Code

State Code
Andaman & Nicobar AN
Andhra Pradesh AP
Arunachal Pradesh AR
Assam AS
Bihar BR
Chandigarh CH
Chhattisgarh CG
Dadra and Nagar Haveli DN
Daman & Diu DD
Delhi DL
Goa GA
Gujarat GJ
Haryana HR
Himachal Pradesh HP
Jammu & Kashmir JK
Jharkhand JH
Karnataka KA
Kerala KL
Lakshadweep LD
Madhya Pradesh MP
Maharashtra MH
Manipur MN
Meghalaya ML
Mizoram MZ
Nagaland NL
Orissa OR
Puducherry PY
Punjab PB
Rajasthan RJ
Sikkim SK
Tamil Nadu TN
Tripura TR
Uttar Pradesh UP
Uttarakhand (Uttranchal) UK
West Bengal WB
Table 73 State Code

Annexure 3 -Glossary Member Compliance Issuer
Annexure 3 -Glossary
Abbreviation Description
ACQID Acquirer Id
AEPS Aadhaar Enabled Payment System
AES Advance Encryption Standards
AID Application Identifier
AIP Application interchange Profile
ATC Application Transaction Counter
ANSI American National Standards Institute
ARPC Authorization Response Cryptogram
ARQC Authorization Request Cryptogram
ATC Application Transaction Counter
ATM Automated Teller Machine
AUA Authentication User Agency (used in Aadhaar authentication)
CAD Card Acceptor Device
CID Cryptogram Information Data
CNP Card Not Present
CP Card Present
CPS Custom Payment Service
CVM Card Verification Method
CVD Card Verification Data
CVD2 Card Verification Data 2
CVR Card Verification Result
DE Data Element
DES Data Encryption Standard
DMS Dual Messaging System
E-COMM Electronic Commerce
EMI Equated Monthly Instalment
EMV Euro- pay, MasterCard and VISA
FRM Fraud and Risk Management
GMT/UTC Greenwich Mean Time
GW Gateway
IAD Issuer Application Data
IFD Interface Device Serial Number
ICC Integrated Circuit Card
ICS International Card Scheme
iCVD Card Verification Data for integrated circuit cards
IMPS Interbank Mobile Payment Service
INT Internet banking
ISO International Organization for Standardization
IVR Interactive Voice Response
KIO Kiosk
LMM Liquidity Management Module
LRC Longitudinal Redundancy checking
MCC Merchant Category Code
MOTO Mail Order/Telephone Order
MTI Message Type Identifier
NBIN National Bank Identification number
NPCI National Payments Corporation Of India

Annexure 3 -Glossary Member Compliance Issuer
Abbreviation Description
NPCI host The master connection that will route or process transactions for
participants.
Off-Us Inter-bank transactions
On-Us Intra-bank transactions
OTP One time Password
PAN Primary Account Number
PCI DSS Payment Card Industry Data Security Standard
PIN Primary Identification Number
PVV PIN Verification Value
RRN Retrieval Reference Number
RQ Request
RS Response
SA Sub – AUA (used in Aadhaar authentication)
SAF Store and Forward
SMS Single Messaging System
STAN System Trace Audit Number
STIP Stand In Processing
TCP Transfer Control Protocol
TDES Triple DES
TID Terminal Id
TLV Tag-length-value
TVR Terminal Verification Results
TXN Transaction
UID Unique Identification
UIDAI Unique Identification Authority of India
UTC Coordinated Universal Time
ZPK Zone Pin Key
ZMK Zone Master Key
Table 74 Glossary and Description

Annexure 4 -Definition Member Compliance Issuer
Annexure 4 -Definition
Terms Meaning
Acquirer The Participant or a trusted source that originates the message
Approve Transaction is authorized. Issuer is authorized the transaction as
reported by the acquirer for purchase of goods or services.
Balance Enquiry It is a request from the POS terminal for the account balance.
Cardholder can initiate a balance inquiry at point of sale. In this case
issuer responds with the balance of the cardholder account.
Biometric The use of biometric technology significantly increases security level
of systems because it eliminates such problems as lost, stolen or
loaned ID cards, and forgotten or guessed PINs.
Barcode Reader A barcode reader (or barcode scanner) is an electronic device for
reading printed barcodes.
Bit Map A bitmap is a field or a subfield within a message which indicates
which data elements are present elsewhere in a message
Card Holder An individual to whom a card is issued or who is authorized to use
the card.
Cash at POS Cash at POS transaction is a variation of the purchase transaction
that permits the cardholder to get cash at POS terminal.
It is defined as Cash given to the cardholder at the point of sale.
Client Service requestors are called as clients
Compliance Compliance is a transaction processing requirements for routed
messages to contain certain key information to provide a more
complete picture of the POS conditions and help validate cardholder
authenticity.
Credit Card Credit card Is a small plastic card issued to users as a system of
payment. It allows its holder to buy goods and services based on the
holder's promise to pay for these goods and services
Credit Adjustment Acquirer credits the issuers account
Cutover message Cut over message indicates the business date change over
Debit card A debit card (also known as a bank card or check card) is a plastic
card that provides the cardholder electronic access to his or her bank
account/s at a financial institution. The card can be used as an
alternative
Decline Transaction is not authorized. Merchant is not allowed to proceed
with the transaction.
Domestic routing Routing done within a country
E-Commerce These are non-face to face online transactions that use the electronic
media over a network. Cardholder may initiate this transaction from
personal PC or Mobile etc. for purchasing the goods or services on
the internet.
For ECOM transactions, authentication system must support
authenticating the cardholder during online purchase.
Echo message Echo messages are used validate the availability of the host session in
case of low or no transaction traffic in the session
EMI amount Amount that is to be paid in instalments
E-Commerce indicator This indicates the security level of an electronic commerce
transaction.
Fallback For a chip based card, when the chip is not working then the card is
swiped using magnetic stripe.

Terms Meaning
Fraud Score Score populated by Risk and Fraud Management System. Value to be
used by issuer before issuer approves a transactions.
Instalment Payments No. of instalments decided for an EMI transaction
ISO 8583 International Standards Organization standards for messaging
supported by the host. Unless specified otherwise, it refers to ISO-
8583:1987 version.
Issuer The participant that receives and authenticates the message.
Julian Date Representing Date in YDDD format
Key Management The activities involving the handling of cryptographic keys and other
related security parameters during the entire life cycle of the keys,
including their generation, storage, distribution, loading and use,
deletion, destruction and archiving.
Loyalty Balance Loyalty Balance will show the number of loyalty points accumulated
Loyalty Points Number Of points accumulated while doing a purchase transaction
Manual Manual entry and no card required
Margin Amount Amount paid by the cardholder during the purchase
Member Bank or other institution connecting to NPCI central switch via HOST
to HOST connection
Merchant An entity that contracts with an acquirer to originate transactions
Message Header Contains the length of the message
Message Logging After the validation of the message, system will log the message.
Logging of the message is required for billing purpose, data files &
reports preparation, testing, troubleshooting, audits and research
purposes etc.
Micro-ATM transactions Transaction done
MTI Message Type Indicator – 4-digit field which classifies the high-level
function of the ISO 8583 message (consisting of Message Version,
Message Class, Message Function, Message Origin)
NPCI Central Switch The master connection that will route or process transaction for
participants
Onus Issuer and the acquirer are same
Off-Us Issuer and Acquirer are different
Optical Card Reader An optical card reader for reading marks made on the face of a pre-
printed card utilizes a video camera and a memory device to capture
and store an image of at least a portion of the card.
Pick up card On receiving the pickup response, merchant should try its best to
retain the card by peaceful means.
Pin (Personal Identification Number) A numeric personal identification
code that authenticates a cardholder in an authorization request that
originates at a terminal with authorization only or data capture only
capability. A PIN consists only of decimal digits.
POS Point-of-Sale/Point-of-Service. Physical location of terminal at the
merchant (‘card present’ transactions) – figuratively, any device
usable for e-commerce or other ‘card not present’ transactions (PC,
phone, etc).
Preauthorization Transactions which are used to authorize transactions in advance of
the actual purchase before the final amount of the purchase is known
Product code A code that identifies the channel of the transaction that whether it is
a POS,ATM,E-commerce transaction
Purchase A purchase transaction is a standard purchase request to authorize
post and settle a transaction for the sale of goods or services.

Terms Meaning
Purchase with cash back A purchase with cash back transaction is a variation of the purchase
transaction that permits the cardholder to get cash in addition to
goods or services. The cash-back amount will be identified separately
in online financial messages
Recurring Payments A pre-authorized recurring transaction charged to a cardholder’s
account
Reversal message The message reverses the action of a previous authorization.
Refund A refund is a financial transaction initiated at the point of sale that
instructs the issuer to credit the cardholder’s account for the return
of goods
Reject code A message will be rejected if due to error conditions, NPCI network is
not able to process it, then a reject code will be send to the acquirer
or to the issuer
Sign On message This message is used to re-establish a session or connectivity that
has been closed or signed off by the other party
Sign Off message This message is used to close a session or connectivity that has been
established or signed on by the other party
Server The server component provides a function or service to one or many
clients, which initiate requests for such services
Stand-In NPCI authorizes the transaction on behalf of the issuer host system
Telephone Request Transaction initiated using Telephone
Terminal A device/system that initiates a transaction
Time-Out Time required by the acquirer, NPCI or issuer to complete a
transaction
Track 1 The information encoded on Track 1 of the magnetic stripe of the
plastic card (per ISO 7813) used for the transaction, excluding start
and end sentinel and LRC characters. It also includes the cardholder
name which is not present in the track 2 data
Track 2 The information encoded on Track 2 of the magnetic stripe of the
plastic card (per ISO 7813) used for the transaction, excluding start
and end sentinel and LRC characters.
Transaction Id A unique Id used for e-commerce transaction
Unattended Terminal A terminal placed in an unattended environment. e.g. ATM
Table 75 Definition


RuPay - Online Switching Interface Specification

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

RuPay - Online Switching Interface Specification

Hochgeladen von

Copyright:

Verfügbare Formate

National Payments Corporation of India

Release Year 2013

Chapter 2 Introduction _______________________________________________________________________ 18

2.4 Routing _____________________________________________________________________________________ 20

3.2 RuPay Implementation of ISO 8583 ____________________________________________________ 24