RuPay-Online Switching Interface Specification - V1.8.3

National Payments Corporation of India
RuPay - Online
Switching Interface
Specification
Version 1.8.3 Year 2018
Release Year 2018

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

2.1 RuPay Switching Service _________________________________________________________________ 22
2.2 Transaction Flow SMS ____________________________________________________________________ 22
2.3 Transaction Flow DMS ___________________________________________________________________ 23
2.3.1 Authorization ______________________________________________________________________________________ 23
2.3.2 Clearing _____________________________________________________________________________________________ 23
2.3.3 Settlement __________________________________________________________________________________________ 23
2.4 Transaction flow for Aadhaar Based Biometric Authentication for Card Present
Transactions _______________________________________________________________________________________ 24
2.5 Routing _____________________________________________________________________________________ 25
Chapter 3 Message Structure ________________________________________________________________ 27
3.1 Message Structure ________________________________________________________________________ 27
3.1.1 Message Header ____________________________________________________________________________________ 27
3.1.2 Message Type Identifier ___________________________________________________________________________ 27
3.1.2.1 Position 1- Version Number_________________________________________________________________ 27
3.1.2.2 Position 2 – Message Class __________________________________________________________________ 27
RuPay - Online Switching Interface Specification

Version 1.8.3 Year 2018 NPCI © 2011 Confidential Page 1 of 244
Table of Contents
3.1.2.3 Position 3 – Message Function ______________________________________________________________ 28

3.1.2.4 Position 4 – Message Source ________________________________________________________________ 28
3.1.3 Bitmap ______________________________________________________________________________________________ 29
3.1.3.1 Primary Bitmap ______________________________________________________________________________ 29
3.1.3.2 Secondary Bitmap ___________________________________________________________________________ 29
3.1.3.3 Third Bitmap _________________________________________________________________________________ 29
3.1.4 Data Elements ______________________________________________________________________________________ 30
3.2 RuPay Implementation of ISO 8583 ____________________________________________________ 30

3.3 Private Use Fields _________________________________________________________________________ 30
Chapter 4 Message Definition _______________________________________________________________ 31
4.1 Authorization Message ___________________________________________________________________ 31
4.1.1 Description of Authorization Message ___________________________________________________________ 31
4.1.2 Message Type Identifier for Authorization Message ____________________________________________ 31
4.2 Financial Message_________________________________________________________________________ 31

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

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

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

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

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

5.1 Data Communication _____________________________________________________________________ 35
5.2 Message Logging at NPCI _________________________________________________________________ 35
5.3 Key Security and Management __________________________________________________________ 35
5.4 Static Key Exchange_______________________________________________________________________ 36
5.5 Dynamic Key Exchange___________________________________________________________________ 36
5.5.1 NPCI Automated – Master sends the new key ___________________________________________________ 36
5.5.2 On Member Request: Slave (Member bank) Requests for a key change _______________________ 37
5.5.3 Key Exchange Scenarios ___________________________________________________________________________ 37
5.6 PIN Encryption / Decryption Process __________________________________________________ 38

5.7 Time-Out Management ___________________________________________________________________ 38

Table of Contents
5.8 Liquidity Management Module _________________________________________________________ 38

5.9 Matching Criteria – Key Data Fields ____________________________________________________ 39
Chapter 6 Member Responsibility __________________________________________________________ 40
6.1 Issuer Responsibility _____________________________________________________________________ 40
6.1.1 Message Supported by Issuer _____________________________________________________________________ 40
6.1.2 Maximum Response Time _________________________________________________________________________ 40
6.1.3 Authorization Cycle and Failure Condition Involving Issuer ___________________________________ 40
6.1.3.1 Authorization normal completion __________________________________________________________ 40
6.1.3.2 Failure Conditions ___________________________________________________________________________ 41
6.1.3.3 Message Validation Failure at NPCI for an Issuer Response ______________________________ 41
6.1.3.4 System Failure during Authorization Request/ Financial Request to Issuer ____________ 42
6.1.3.5 System Failure during Authorization Response/ Financial Response from Issuer _____ 43
6.1.3.6 Late Response from Issuer __________________________________________________________________ 44
6.1.4 Stand-In functionality and Credit Card Authorization __________________________________________ 45
6.1.4.1 Scenarios for Stand-In Processing __________________________________________________________ 47
6.1.4.2 Small Ticket Size STIP Option _______________________________________________________________ 51
6.1.4.3 Ceiling and Channel wise Limits ____________________________________________________________ 51
6.1.4.4 SAF Processing _______________________________________________________________________________ 52
6.1.4.5 PIN Validation during STIP __________________________________________________________________ 52
6.1.4.6 VIP Card Management _______________________________________________________________________ 52
6.2 Acquirer Responsibilities________________________________________________________________ 53

6.2.1 Message Supported by Acquirer __________________________________________________________________ 53
6.2.2 Authorization Cycle and Failure Conditions Involving Acquirer _______________________________ 54
6.2.2.1 Authorization Normal Completion _________________________________________________________ 54
6.2.2.2 Failure Conditions ___________________________________________________________________________ 55
6.2.2.3 System Failure Acquirer Authorization / Financial Request (Acquirer Aware) ________ 55
6.2.2.4 System Failure Acquirer Authorization / Financial Request (Acquirer Unaware) ______ 56
6.2.2.5 Validation Failure at NPCI for Acquirer Message __________________________________________ 56
6.2.2.6 Acquirer Unable to Complete a Transaction due to the Terminal Failure (POS) ________ 57
6.2.2.7 System Failure NPCI (Aware) Authorization /Financial Response ______________________ 58
6.2.2.8 System Failure NPCI (Unaware) Authorization / Financial Response ___________________ 58
6.2.3 Advice message scenarios for acquirer __________________________________________________________ 60
6.2.3.1 Advice message normal completion ________________________________________________________ 60
6.2.3.2 Advice Delivery from Acquirer following Timeout ________________________________________ 60
Chapter 7 Message Format___________________________________________________________________ 62

7.1 Transaction Identification _______________________________________________________________ 62
7.1.1 Notations Used in Message Format _______________________________________________________________ 64
7.2 Message Format for Issuer ______________________________________________________________ 64

7.2.1 Current (Phase – I) Requirements ________________________________________________________________ 64
7.2.1.1 Purchase ______________________________________________________________________________________ 64
7.2.1.2 Purchase with Cashback _____________________________________________________________________ 66
7.2.1.3 RuPay Implementation of E-Commerce Purchase (Secure / Non-Secure) ______________ 68
7.2.1.4 E-Commerce 3D Purchase (Secure / Non-Secure) ________________________________________ 69
7.2.1.5 E-Commerce Refund _________________________________________________________________________ 70
7.2.1.6 IVR Request (from PaySecure) - NPCI to Issuer ___________________________________________ 71
7.2.1.7 Cash at PoS ___________________________________________________________________________________ 72
7.2.1.8 Cash Withdrawal - ATM _____________________________________________________________________ 74

Table of Contents
7.2.1.9 Balance Inquiry ______________________________________________________________________________ 75

7.2.1.10 Reversal Message ____________________________________________________________________________ 76
7.2.1.11 Decline Message______________________________________________________________________________ 77
7.2.1.12 Network Management _______________________________________________________________________ 79
7.2.1.13 Pin Change ____________________________________________________________________________________ 79
7.2.1.14 Mini Statement _______________________________________________________________________________ 80
7.2.1.15 Card to Card Fund Transfer _________________________________________________________________ 81
7.2.1.16 Mobile Number Update ______________________________________________________________________ 84
7.2.1.17 Cheque Book Request _______________________________________________________________________ 85
7.2.1.18 Statement Request ___________________________________________________________________________ 86
7.2.1.19 Declined Advice ______________________________________________________________________________ 87
7.2.1.20 International Non-Secure e-Commerce transaction to Issuer ____________________________ 90
7.2.1.21 STIP Advice Request to Issuer ______________________________________________________________ 91
7.2.1.22 File Update/ Enquiry Message ______________________________________________________________ 92
7.2.1.23 Original Credit Transaction _________________________________________________________________ 93
7.2.1.24 Money Load Transaction ____________________________________________________________________ 94
7.2.1.25 Service Creation Request ____________________________________________________________________ 95
7.2.1.26 Aadhar Number Inquiry _____________________________________________________________________ 96
7.2.1.27 ARQC Validation and ARPC Generation – Onus Scenario _________________________________ 97
7.3 Message Format for Acquirer __________________________________________________________ 100

7.3.1 Current (Phase I) Requirements _________________________________________________________________ 100
7.3.1.1 Purchase _____________________________________________________________________________________ 100
7.3.1.2 Purchase with Cashback ____________________________________________________________________ 102
7.3.1.3 RuPay E-Commerce Purchase (Secure / Non-Secure) ___________________________________ 103
7.3.1.4 IVR Request (from PaySecure) to NPCI ___________________________________________________ 105
7.3.1.5 E-Commerce 3D Purchase __________________________________________________________________ 106
7.3.1.6 E-Commerce Refund ________________________________________________________________________ 107
7.3.1.7 Cash at PoS __________________________________________________________________________________ 108
7.3.1.8 Cash Withdrawal - ATM ____________________________________________________________________ 110
7.3.1.9 Balance Inquiry _____________________________________________________________________________ 111
7.3.1.10 Reversal _____________________________________________________________________________________ 113
7.3.1.11 Decline Message_____________________________________________________________________________ 114
7.3.1.12 Network Management ______________________________________________________________________ 116
7.3.1.13 Pin Change ___________________________________________________________________________________ 116
7.3.1.14 Mini Statement ______________________________________________________________________________ 117
7.3.1.15 Card to Card Funds Transfer _______________________________________________________________ 119
7.3.1.16 Biometric Onus Authentication ____________________________________________________________ 121
7.3.1.17 Mobile Number Update _____________________________________________________________________ 122
7.3.1.18 Cheque Book Request ______________________________________________________________________ 124
7.3.1.19 Statement Request __________________________________________________________________________ 125
7.3.1.20 OCT Transaction ____________________________________________________________________________ 127
7.3.1.21 Money Load Transaction ___________________________________________________________________ 128
7.3.1.22 Service Creation Request ___________________________________________________________________ 129
Chapter 8 Data Element Description _____________________________________________________ 131

8.1 Annotation Convention for Attributes ________________________________________________ 131
8.2 Data Elements Information Components ____________________________________________ 131
8.3 Detailed Description of Data Elements _______________________________________________ 132
8.3.1 DE – 2 Primary Account Number ________________________________________________________________ 132
8.3.2 DE – 3 Processing Code ___________________________________________________________________________ 133

Table of Contents
8.3.3 DE – 4 Amount, Transaction _____________________________________________________________________ 135

8.3.4 DE – 5 Amount, Settlement _______________________________________________________________________ 136
8.3.5 DE – 6 Amount, Cardholder Billing ______________________________________________________________ 137
8.3.6 DE – 7 Date and Time Transmission_____________________________________________________________ 138
8.3.7 DE – 9 Conversion Rate, Settlement _____________________________________________________________ 139
8.3.8 DE – 10 Conversion Rate, Cardholder Billing ___________________________________________________ 140
8.3.9 DE – 11 System Trace Audit Number ____________________________________________________________ 141
8.3.10 DE – 12 Time, Local Transaction______________________________________________________________ 142
8.3.11 DE – 13 Date, Local Transaction ______________________________________________________________ 143
8.3.12 DE – 14 Date, Expiry ___________________________________________________________________________ 144
8.3.13 DE – 15 Date, Settlement ______________________________________________________________________ 145
8.3.14 DE – 16 Date, Conversion _____________________________________________________________________ 146
8.3.15 DE – 18 Merchant Category Code _____________________________________________________________ 147
8.3.16 DE – 19 Acquiring Country Code______________________________________________________________ 148
8.3.17 DE – 22 Point of Service Entry Mode _________________________________________________________ 149
8.3.18 DE – 23 Card Sequence Number ______________________________________________________________ 150
8.3.19 DE – 25 Point of Service Condition Code _____________________________________________________ 151
8.3.20 DE – 28 Amount, Fees _________________________________________________________________________ 152
8.3.21 DE – 32 Acquiring Institution Code ___________________________________________________________ 153
8.3.22 DE – 33 Forwarding Institution Code ________________________________________________________ 154
8.3.23 DE – 35 Track 2 Data __________________________________________________________________________ 155
8.3.24 DE – 37 Retrieval Reference Number ________________________________________________________ 156
8.3.25 DE – 38 Authorization Identification Response _____________________________________________ 157
8.3.26 DE – 39 Response Code ________________________________________________________________________ 158
8.3.26.1 Response code scenarios ___________________________________________________________________ 160
8.3.26.2 E-commerce 3 D Implementation _________________________________________________________ 161
8.3.26.3 RuPay Implementation of E-commerce ___________________________________________________ 162
8.3.26.4 International e-Commerce Non-Secure Transactions to RuPay Issuer _________________ 163
8.3.26.5 Original Credit Transaction (OCT) Message ______________________________________________ 163
8.3.26.6 Biometric Authentication __________________________________________________________________ 163
8.3.27 DE – 40 Service Condition Code ______________________________________________________________ 164
8.3.28 DE – 41 Card Acceptor Terminal ID __________________________________________________________ 165
8.3.29 DE – 42 Card Acceptor ID _____________________________________________________________________ 166
8.3.30 DE – 43 Card Acceptor Name / Location _____________________________________________________ 167
8.3.31 DE – 44 Additional Response Data ___________________________________________________________ 168
8.3.32 DE – 45 Track I Data ___________________________________________________________________________ 173
8.3.33 DE – 48 Additional Data _______________________________________________________________________ 174
8.3.33.1 Usage in Dynamic Key Exchange ___________________________________________________________ 182
8.3.34 DE – 49 Currency Code, Transaction _________________________________________________________ 184
8.3.35 DE – 50 Currency Code, Settlement __________________________________________________________ 185
8.3.36 DE – 51 Currency Code, Cardholder Billing __________________________________________________ 186
8.3.37 DE – 52 PIN Data _______________________________________________________________________________ 187
8.3.38 DE – 54 Additional Amount ___________________________________________________________________ 188
8.3.39 DE – 55 Chip Data ______________________________________________________________________________ 190
8.3.39.1 Authorization Message DE – 55 Presence Descriptions __________________________________ 190
8.3.40 DE – 60 Advice Reason Code __________________________________________________________________ 194
8.3.41 DE – 61 PoS Data Code ________________________________________________________________________ 195
8.3.42 DE – 62 Private Data 1-Biometric Data _______________________________________________________ 199
8.3.43 DE – 63 Private Data 2 _________________________________________________________________________ 200
8.3.44 DE – 70 Network Management Information Code ___________________________________________ 201
8.3.45 DE – 90 Original Data Element ________________________________________________________________ 202

Table of Contents
8.3.46 DE – 91 File Update Code ______________________________________________________________________ 203

8.3.47 DE – 95 Replacement Amount ________________________________________________________________ 204
8.3.48 DE – 101 File Name ____________________________________________________________________________ 205
8.3.49 DE – 102 Account Identification 1 ____________________________________________________________ 206
8.3.50 DE – 103 Account Identification 2 ____________________________________________________________ 207
8.3.51 DE - 104 OCT Data _____________________________________________________________________________ 208
8.3.52 DE - 105 Token Data ___________________________________________________________________________ 211
8.3.53 DE – 111 to DE --119 Encrypted Personal Identity Data(FP/IRIS) _________________________ 213
8.3.54 DE – 120 Private Data 3 _______________________________________________________________________ 214
8.3.55 DE – 121, 122, Private Data 4 – 5 _____________________________________________________________ 221
8.3.56 DE – 123 mc attribute Data ___________________________________________________________________ 222
8.3.57 DE – 124 File Action Record / mc attribute Data ____________________________________________ 223
8.3.58 DE – 125 mc attribute Data ___________________________________________________________________ 225
8.3.59 DE – 126 Additional Data-Biometric Data ___________________________________________________ 226
8.3.60 DE –127 Additional Data-Biometric Data ____________________________________________________ 227
Chapter 9 Compliance _______________________________________________________________________ 229

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

9.2.1 General Compliance ______________________________________________________________________________ 232
9.2.2 Transaction Wise Compliance ___________________________________________________________________ 232
9.2.3 Standards related to Compliance ________________________________________________________________ 233
Annexure 1-Card to Card Fund Transfer ___________________________________________________ 234

Transaction Flow for Card To Card Funds Transfer ____________________________________________________ 234
Maximum Response Time _________________________________________________________________________________ 234
Annexure 2- Original Credit Transaction for Merchant Payment ____________________ 235

Successful Transaction Flow for OCT ____________________________________________________________________ 235
Exception Handling ________________________________________________________________________________________ 236
Annexure 3 -State Code ________________________________________________________________________ 239

Annexure 4 -Glossary __________________________________________________________________________ 240
Annexure 5 -Definition ________________________________________________________________________ 242

List of Figures
List of Figures
Figure 1 SMS Transaction Flow _______________________________________________________________________ 22
Figure 2 DMS Transaction Flow _______________________________________________________________________ 23
Figure 3 Biometric Transaction Flow _________________________________________________________________ 24
Figure 4: Master Initiated Key Exchange _____________________________________________________________ 36
Figure 5: On Member Request Key Exchange ________________________________________________________ 37
Figure 6 Authorization Normal Completion__________________________________________________________ 41
Figure 7 Message Validation Failure – NPCI _________________________________________________________ 41
Figure 8 System Failure – Authorization Request/ Financial Request _____________________________ 42
Figure 9 System Failure – Authorization Response/ Financial Response _________________________ 43
Figure 10 Late response from issuer _________________________________________________________________ 44
Figure 11 Stand-in Processing, Late Response from Issuer _________________________________________ 47
Figure 12 Stand-in Processing, No Response from Issuer __________________________________________ 48
Figure 13 Stand-in Processing, Node Offline or Issuer Signed-off __________________________________ 49
Figure 14 Stand-In processing, for Small Ticket size ________________________________________________ 50
Figure 15 Maximum Response Time for Acquirer ___________________________________________________ 54
Figure 16 Normal Completion of an Authorization Message/ Financial Message_________________ 54
Figure 17 System failure - Acquirer Aware - Authorization / Financial Request _________________ 55
Figure 18 System Failure - Acquirer Unaware - Authorization / Financial Request ______________ 56
Figure 19 Message Validity Failure at NPCI - Authorization / Financial Request _________________ 56
Figure 20 Incomplete Transactions in case of Terminal Failure ___________________________________ 57
Figure 21 System Failure - NPCI Aware - Authorization / Financial Response ___________________ 58
Figure 22 System Failure - NPCI Unaware - Authorization / Financial Response_________________ 59
Figure 23 Advice Messages getting Completed Normally ___________________________________________ 60
Figure 24 Advice Delivery Crossing Time Limits ____________________________________________________ 60

List of Tables
List of Tables
Table 1 Version History ________________________________________________________________________________ 12
Table 2 Document Revision History __________________________________________________________________ 19
Table 3 Document Convention ________________________________________________________________________ 20
Table 4 Components of Message Structure___________________________________________________________ 27
Table 5 Version Number ISO 8583 Message _________________________________________________________ 27
Table 6 Message Class ISO 8583 Message ____________________________________________________________ 28
Table 7 Message Function ISO 8583 Message ________________________________________________________ 28
Table 8 Message Source ISO 8583 Message __________________________________________________________ 28
Table 9 RuPay Implementation of ISO 8583 _________________________________________________________ 30
Table 10 Private Fields Used in RuPay _______________________________________________________________ 30
Table 11 Message Supported by Issuer _______________________________________________________________ 40
Table 12 Message Supported by Acquirer____________________________________________________________ 53
Table 13 Key Data Elements ___________________________________________________________________________ 63
Table 14 Symbols used in Message Format __________________________________________________________ 64
Table 15 Purchase Message – Issuer __________________________________________________________________ 66
Table 16 Purchase with Cashback Message – Issuer ________________________________________________ 68
Table 17 RuPay E-Commerce Message – Issuer _____________________________________________________ 69
Table 18 E-Commerce 3D Message – Issuer__________________________________________________________ 70
Table 19 IVR Request (from PaySecure) to Issuer ___________________________________________________ 72
Table 20 Cash at PoS– Issuer __________________________________________________________________________ 73
Table 21 Cash Withdrawal - ATM Message – Issuer _________________________________________________ 75
Table 22 Balance Inquiry Message – Issuer __________________________________________________________ 76
Table 23 Reversal Message – Issuer __________________________________________________________________ 77
Table 24 Decline Message _____________________________________________________________________________ 79
Table 25 Network Management Message – Issuer___________________________________________________ 79
Table 26 Pin Change Message – Issuer _______________________________________________________________ 80
Table 27 Mini Statement Message – Issuer ___________________________________________________________ 81
Table 28 Card to Card Fund Transfer-Debit leg to the issuer _______________________________________ 83
Table 29 Card to Card Fund transfer-Credit to the beneficiary _____________________________________ 84
Table 30 Mobile Number Update – Issuer ____________________________________________________________ 85
Table 31 Cheque Book Request – Issuer______________________________________________________________ 86
Table 32 Statement Request – Issuer _________________________________________________________________ 87
Table 33 Decline Advice Message (Quick EMV) – Issuer ____________________________________________ 89
Table 34: International e-Commerce to Issuer_______________________________________________________ 91
Table 35: STIP Advice Request to Issuer _____________________________________________________________ 92
Table 36 File Update Message – Issuer _______________________________________________________________ 93
Table 37 OCT Message To Issuer ______________________________________________________________________ 94
Table 38 Money Load Transaction Message – Issuer ________________________________________________ 95
Table 39 Service Creation Message – Issuer _________________________________________________________ 96
Table 40 Aadhar Number Inquiry Message – Issuer_________________________________________________ 97
Table 41 ARQC Validation and ARPC Generation- Onus ____________________________________________ 99
Table 42 Purchase Message – Acquirer_____________________________________________________________ 101
Table 43 Purchase with Cashback Message – Acquirer ___________________________________________ 103

List of Tables
Table 44 RuPay E-Commerce Purchase Message – Acquirer _____________________________________ 105

Table 45 RuPay E-Commerce Purchase Message – Acquirer _____________________________________ 106
Table 46 E-Commerce 3D Purchase Message – Acquirer _________________________________________ 107
Table 47 Cash at PoS / Cash Withdrawal Message – Acquirer ____________________________________ 109
Table 48 Cash Withdrawal - ATM Message – Acquirer ____________________________________________ 111
Table 49 Balance Inquiry – Acquirer _______________________________________________________________ 113
Table 50 Reversal Message – Acquirer _____________________________________________________________ 114
Table 51 Decline Message ___________________________________________________________________________ 116
Table 52 Network Management Message __________________________________________________________ 116
Table 53 Pin Change Message – Acquirer __________________________________________________________ 117
Table 54 Mini Statement Message – Acquirer ______________________________________________________ 119
Table 55 Card to Card Fund transfer _______________________________________________________________ 121
Table 56 Biometric Onus Authentication ___________________________________________________________ 122
Table 57 Mobile Number Update ___________________________________________________________________ 124
Table 58 Cheque Book Request _____________________________________________________________________ 125
Table 59 Statement Request_________________________________________________________________________ 127
Table 60 OCT Message To Acquirer _________________________________________________________________ 128
Table 61 Money Load Transaction Message – Acquirer ___________________________________________ 129
Table 62 Service Creation Message – Acquirer ____________________________________________________ 130
Table 63 Abbreviation used in Data Element Description ________________________________________ 131
Table 64 Date and Time Attribute __________________________________________________________________ 131
Table 65 Data Element Information Components _________________________________________________ 132
Table 66 Response Code Table ______________________________________________________________________ 159
Table 67 Compliance Reject Response Code _______________________________________________________ 160
Table 68 Response Code for Advice Message ______________________________________________________ 160
Table 69 Response codes Supported for Reversal Response / Request Messages ______________ 160
Table 70 Response Code Supported for Reversal Response ______________________________________ 160
Table 71 Response Code Supported for Network Management Message________________________ 160
Table 72 Acquirer Compliance Reject Reason code _______________________________________________ 169
Table 73 Issuer Compliance Reject Reason code __________________________________________________ 170
Table 74: DE-48 Tags and descriptions_____________________________________________________________ 180
Table 75 Product Code _______________________________________________________________________________ 180
Table 76: Tag078 (Encryption Technique Indicator) Description _______________________________ 181
Table 77: Bit representation for Encryption Indicator ____________________________________________ 181
Table 78: Meaning of Bit Value in Byte map _______________________________________________________ 181
Table 79: Scenario - TLE and UKPT compliant _____________________________________________________ 181
Table 80: ETI value - TLE and UKPT compliant ____________________________________________________ 181
Table 81: Scenario - TLE and DUKPT compliant ___________________________________________________ 182
Table 82: ETI value - TLE and DUKPT compliant __________________________________________________ 182
Table 83 Double Length _____________________________________________________________________________ 182
Table 84 Triple Length _______________________________________________________________________________ 183
Table 85: DE-55 Tags ________________________________________________________________________________ 193
Table 86 Mobile and UID DE-120 Details___________________________________________________________ 216
Table 87 ATM transaction Pin Change request ____________________________________________________ 216
Table 88 ATM transaction Pin Change Response __________________________________________________ 216
Table 89 ATM transaction Mini Statement request________________________________________________ 217
Table 90 ATM transaction Mini Statement Response _____________________________________________ 218

List of Tables
Table 91 ATM transaction Bill Pay __________________________________________________________________ 218

Table 92 DE – 120 Fund Transfer from Acquirer __________________________________________________ 218
Table 93 DE – 120 Fund Transfer to Acquirer _____________________________________________________ 218
Table 94 Fund Transfer Fund debit request _______________________________________________________ 219
Table 95 Fund Transfer Fund debit response ______________________________________________________ 219
Table 96 Fund Transfer Fund Credit request ______________________________________________________ 219
Table 97 Fund Transfer Fund debit response ______________________________________________________ 219
Table 98 Cheque Book Request _____________________________________________________________________ 219
Table 99 Cheque Book Response ___________________________________________________________________ 219
Table 100 Statement Request _______________________________________________________________________ 219
Table 101 Statement Response _____________________________________________________________________ 220
Table 102 Mobile Number Update request_________________________________________________________ 220
Table 103 Mobile Number Update response _______________________________________________________ 220
Table 104 DE-127 Field Details _____________________________________________________________________ 227
Table 105: State Codes _______________________________________________________________________________ 239
Table 106: Glossary __________________________________________________________________________________ 241
Table 107: Definitions _______________________________________________________________________________ 244

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 Interim Release
Version 1.6 01-Aug-2013 01-Aug-2013
Version 1.6.1 17-April-2015 17-April-2015
Version 1.6.1.1 22-Jan-2016 22-Jan-2016
Version 1.6.1.2 05-Feb-2016 05-Feb-2016
Version 1.6.2 13-April-2016 13-April-2016
Version 1.6.2.1 30- June – 2016 01-July-2016
Version 1.6.5 01-August-2016 08-August – 2016
Version 1.6.6 08-December-2016 09-December-2016
Version 1.6.6.1 29-December-2016 30-December-2016
Version 1.6.6.2 06-January-2017 07-January-2017
Version 1.6.6.3 16-February-2017 01-March-2017
Version 1.7 24-March-2017 31-March-2017
Version 1.7.1 24-May-2017 25-May-2017
Version 1.7.3 17-July-2017 01-Dec-2017
Version 1.7.4 18-Dec-2017 20-Dec-2017
Version 1.7.5 02-Jan-2018 03-Jan-2018
Version 1.7.6 09-Jan-2018 15-Jan-2018
Version 1.7.7 12-Feb-2018 25-Feb-2018
Version 1.8 23-Feb-2018 01-Mar-2018
Version 1.8.1 27-Mar-2018 27-Mar-2018
Version 1.8.2 04-Apr-2018 10-Apr-2018
Version 1.8.3 13-Aug-2018 14-Aug-2018
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

Document Control

Section
No.
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, fall back 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.55,8.3. DE 62, 126 and 127 defined for biometric 1.5
6
56 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 value 1.5
10 8.3.33
9 redefined with UID authentication
11 8.3.52 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
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.18 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 7.2.1.8
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- 1.5.1
30 DE-38 out, 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

Document Control

Section
No.
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.10
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:
“NPCI will issue cutover message (0800 message with
39 4.5.3
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. 1.6
41 8.3.39 It has been changed from C to “-“.
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.8 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.52 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.15 removed.
DE 120 Tag 045 (credit transaction to beneficiary) and 1.6

48 7.2.1.15 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.17
DE120 Tag 045 and Tag 046 removed
Mobile number update, Statement Request and 1.6
7.2.1.16,7.2.1.17,
50 Cheque Book Request message format have been
7.2.1.18
added

Document Control

Section
No.
New message format added for Declined Advice 1.6
51 7.2.1.19
(Quick 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-Com
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
entity and if an advice message is not delivered
59 4.6.1
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.”
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)
62 6.1.3.3
.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

Document Control

Section
No.
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 1.6
up to next 3 cutover cycles. If a reversal is generated
64 6.2.3.2
after 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"
DE 102 Account Identification 1 Type changed to 1.6
67 8.3.49
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.1 Note enhanced for clarity for DE 4, DE6 and DE49 1.6
71 7.2.1.8 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.12
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
77 5.5, 5.6 Sections regarding Dynamic Key Exchange- removed 1.6.1
78 8.3.33 Description added regarding Tag053 and Tag054 1.6.1
79 8.3.31 Values added in DE-44 1.6.1
80 1.5.1.3 Added reference for RuPay VAS addendum 1.6.1
81 6.1, 6.2 Corrected Message Formats 1.6.1
82 8.3.41 Added new value ‘G’ in SF-8 of DE-61 1.6.1.1
83 8.3.33 Added new values for ECI in Tag056 in DE-48 1.6.1.1
84 7.2.1.3 Change (in Tag075) e-Commerce message format 1.6.1.1
85 8.3.26.3.1 Added section for ‘Card + OTP’ Method 1.6.1.1
86 8.3.41 Changed description of value ‘1’ in SF-2 DE-61 1.6.1.1
87 7.2.1.6 IVR Request (from PaySecure) - NPCI to Issuer 1.6.1.2

Document Control

Section
No.
88 7.3.1.4 IVR Request (from PaySecure) to NPCI 1.6.1.2
89 8.3.26 Added response code '81' 1.6.1.2
90 8.3.26.4 4 Added the section for International e-Commerce 1.6.1.2
91 8.3.31 Added value AMTI for MTI compliance 1.6.1.2
92 8.3.33 Update DE-48 for ECI value '41' 1.6.1.2
93 8.3.33 Update DE-48 updated tag077, added tag078-ETI 1.6.1.2
Added info on Tag078 (Encryption Technique 1.6.1.2
94 8.3.33
Indicator)
95 8.3.37 Updated for 'Card + OTP' and IVR 1.6.1.2
96 8.3.41 Updated for mPoS indicator and IVR 1.6.1.2
97 Annexure 3 Updated Glossary 1.6.1.2
7.2.1.1, 7.2.1.2, Updated message formats for ETI Tag078 in DE-48 1.6.1.2
98
7.2.1.7, 7.2.1.9
7.3.1.1, 7.3.1.2, Updated message formats for ETI Tag078 in DE-48 1.6.1.2
99
7.3.1.7. 7.3.1.9
Added Message format for International non-secure e- 1.6.1.2
100 7.2.1.20
commerce transaction to RuPay Issuer
101 7.2.1.21 Added STIP Advice Request to Issuer 1.6.2
102 6.1.4 Chapter revised and updated for Credit Card 1.6.2
103 8.3.33 DE-48 Tag060 updated and revised for STIP indicators 1.6.2
Updated for RRN format in transactions acquired 1.6.2
104 8.3.24
outside of India (JCB scenario)
105 7.2.1.22 Updated File Update for File Enquiry 1.6.2
106 8.3.46 Updated File Update Code 1.6.2
107 8.3.26 Added response codes for File update messages 1.6.2
108 8.3.33 Added Tag080 and related information 1.6.2.1
7.2.1.1, 7.2.1.2, Updated message formats for support for Tag080 1.6.2.1
109 7.2.1.7, 7.3.1.1,
7.3.1.2, 7.3.1.7
110 5.5 Introduced the Section for Dynamic Key Exchange 1.6.5
111 7.2.1.12, 7.3.1.14 Changes in Network Management Message for DKE 1.6.5
112 8.3.44 Changes made in DE-70 for DKE 1.6.5
113 8.3.33.1 DE-48 changes for DKE 1.6.5
Added Message Format for below transaction types 1.6.5
7.3.1.10, 81 ARQC Validation and ARPC Generation – Onus
114
7.3.1.11 Scenario
82 Only ARPC Generation – Onus Scenario
7.1 Added Message Formats for OCT Transaction 1.6.6
7.2.1.23
7.3.1.22
8.3.1
8.3.2
8.3.17
115
8.3.26
8.3.29
8.3.31
8.3.51
9.1
9.2

Document Control

Section
No.
8.3.31 Changes to support Card + Pin E-commerce 1.6.6.1
116
8.3.33 transaction.
8.3.33 Changes to Baseline SI / MOTO / RP requirements 1.6.6.2
117
8.3.41
1.5.1.4 Changes to Support Contactless Chip (qSPARC) based 1.6.6.3
7.1 Transactions
7.2.1.1
7.2.1.24
7.2.1.25
118 7.3.1.1
7.3.1.21
7.3.1.22
8.3.2
8.3.33
8.3.39
2.4 Changes to support Biometric Authentication from 1.7
7.2 ATM and POS EMV Authentication Changes for ON Us
7.3 Transactions.
8.3.2
8.3.26
119
8.3.31
8.3.42
8.3.43
8.3.55
8.3.56
7.3 Changes to Support Auth 2.0 Changes. 1.7.1
8.3.43
8.3.52
120
8.3.55
8.3.56
8.3.57
Changes to support DE-14,23 as an optional field to 1.7.3
121 7.2.1.21
issuer
Changes in DE-55 Tag 9C, Removed validation on 9C 1.7.4
122 8.3.39
against processing code first 2 bytes.
Changes to support Merchant Business Type based on 1.7.5
7.2
the Turn Over.
123 7.3
Changes to support MAC for all Authorization And
8.3.33
Transaction messages.
8.3.33 Added New Tag in DE-48 to support Quick EMV for Q- 1.7.6
124 7.2.1.24 Sparc Service Creation Transaction
7.2.1.25
Added New ECI values to Support Quick Checkout and 1.7.6
125 8.3.33
Connected Checkout
8.3.33 Changes to Support Secure International E-Commerce 1.7.7
126
7.2.1.4 Transaction
7.2.2 Changes to Support Token Bin in all Transactions 1.8
127 8.3.39
8.3.52
Updated Merchant ID with the Values accepted for 1.8.1
128 8.3.29
International Lounge Transaction

Document Control

Section
No.
7.2.1.24 Updated DE-14 as conditional for Money Add & 1.8.2
7.2.1.25 Service creation transaction.
129 7.3.1.21 Update DE-48 Tag 082 (Source Of Fund) with Balance
7.3.1.22 Update option at Card for Money Load. transaction
8.3.33
Updated 7.2.1.19 Advice to issuer for Fraud Score 1.8.3
130 7.2.1.19
Rejection
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.
1.5.1.3 RuPay VAS Addendum

For Card to Card Fund Transfer refer to document “RuPay Interface Specification VAS Addendum
Version 1.1”
1.5.1.4 RuPay qSPARC

For contactless card related specification, and Terminal integration please refer to qSPARC
Specifications Manual.

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

Introduction Transaction
Flow DMS
2.3 Transaction Flow DMS

A dual message system comprises of authorization, clearing and settlement.
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 the ISO-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 Transaction flow for Aadhaar Based Biometric
Authentication for Card Present Transactions
2.4 Transaction flow for Aadhaar Based Biometric

Authentication for Card Present Transactions
Aadhaar Based Biometric authentication is a new method of authenticating the customer using
biometric data for card present transactions on ATM / POS.
NFS will send the txn to

Cardholder swipes/ FRM Issuer Bank based on the
inserts his card and card number (BIN) to
selects biometric as fetch the Aadhaar no.
mode of authentication
Acquiring Bank
NFS Switch Issuing Bank Switch
Switch
Figure 3 Biometric Transaction Flow
Process Flow:
1. Card Holder inserts the card for ATM / POS Transactions. Card holder to be
prompted with the following two options to select the mode of Authentication
a. PIN
b. Biometrics
 If the cardholder selects ‘PIN’ as the mode of authentication, current
transaction flow shall continue.
 If the cardholder selects ‘Biometric’ as the mode of authentication,
customer will be prompted to provide his/her biometrics. Once the
transaction details are entered and biometrics is provided by the
cardholder the transaction is sent by the ATM / POS to Acquirer switch.
2. Acquirer Switch will send the transaction request to NPCI with the authentication
indicator for routing the transaction to the respective Issuing bank.
3. NPCI will send the transaction request to the Issuing Bank switch for fetching the
Aadhaar number mapped against the card number.

Introduction Routing
4. Issuing bank to respond to NPCI with the Aadhaar number of the cardholder for
authentication.
5. On successful receipt of Aadhaar number from the Issuing Bank switch, NPCI will
send the authentication request to UIDAI along with Aadhaar number and the
encrypted biometrics as per UIDAI specifications.
6. Once the authentication response is received by NPCI from UIDAI.
7. For successful authentication response from UIDAI, NPCI will send the transaction
request to FRM for rule evaluation.
8. FRM will respond with “Fraud score”
9. Based on the certification, the fraud score or the default score along with
approved authentication response will be sent to the Issuing Bank Switch for
processing the transaction.
10. Issuing bank switch will send the request to CBS.
11. The response will be sent by CBS to Issuer Bank Switch.
12. Issuer Bank Switch will send the response to NPCI.
13. NPCI will send the response received from Issuing Bank switch to Acquirer
Switch.
14. Acquirer switch will send the response to the ATM / POS. Device shall process the
transaction request based on the response received and display it on the screen
to the cardholder.
Timeout for the transaction will be as follows:

 Issuer Timeout for fetching the Aadhaar number is 10 sec.
 UIDAI timeout for authentication is 10 sec.
 Issuer time out after validation is done is 20 sec.
 Acquirer timeout is 45 sec.
Decline advice for Issuers

Issuers will be given an option to opt for an advice messages in case of biometric authentication
failure. If issuer opts for the same, Issuer will get declined advice if the authentication failed at
UIDAI end Also the declined advice will be sent in RAW data file to issuer.
2.5 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

Introduction Routing
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
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 

Message Structure Message Structure
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

Message Structure Message
Structure
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
data code 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 104 – OCT data NPCI uses DE 104which is reserved by ISO for “Private
use”
DE 111- to DE 119 Encrypted NPCI uses DE 111 to DE 119 which is reserved by ISO for
Personal Identity Data( “Private use”
FP/BFD/IRIS)
DE 120 – Private data field 3 NPCI uses DE 120which is reserved by ISO for “Private
use”
DE 121 to DE 122 – Private data NPCI uses DE 121 to DE 123which is reserved by ISO for
field 4 - 5 “Private use”
DE 123 to DE 125 mc attribute NPCI uses DE 123 to DE 125 which is reserved by ISO for
Data “Private use”
DE#126 Additional Data NPCI uses DE 126 which is reserved by ISO for “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 Authorizatio
n 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

Message Definition File Update Message
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.
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

Message Definition Network
Management Message
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.
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

Message Definition Advice Message
 Network Management Response – 0810
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 X9.8 Format (with PAN) PIN block format 1 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 X9.8 Format (with PAN)
PIN block format 1 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 methods of Dynamic Key Exchange are envisaged.
 NPCI Automated - One is to have the master (NPCI) send the key update message and
slave updating the key directly.
 On Member Request - The other way is to have the slave (bank) request for a new key and
master shall send a new key in response which slave can update after validating it.
Two ways of key exchanges are described below:
5.5.1 NPCI Automated – Master sends the new key

New Key
1 Sent
Master key Slave key

processor processor
New Key
2
Accept
Figure 4: Master Initiated Key Exchange
1. NPCI will act as a master and will send a new key message (0800 DE-70=184) with a
Triple DES double length key along with its 6 digit key check value which member bank
should use for encryption or decryption of PIN.
2. The new key (ZPK) 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

NPCI System Functionalities Dynamic
Key Exchange
(exchanged separately) and should respond back to NPCI with 0810 message with
response code as “00” along with DE-70=184.
5.5.2 On Member Request: Slave (Member bank) Requests

for a key change
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: On Member Request Key Exchange
1. Participant bank can send a new key request message 0800 with DE-70 = 164 to NPCI.
2. NPCI will respond to the participant bank with 0810 response having the response
code as “00” with DE-70 = 164.
3. NPCI will generate the new key and (0800 DE-70=184) with a Triple DES double
length key along with its 6 digit key check value which member bank should use for
encryption or decryption of PIN.
4. The new key (ZPK) 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
(exchanged separately) and should respond back to NPCI with 0810 message with
response code as “00” along with DE-70=184.
Note: In the event of slave (bank) not responding successfully for the key exchange request (DE-
70=184) Master (NPCI) will keep on processing the transactions with the old key. Also in this
case NPCI will keep on initiating (re-trying) the key exchange request (each time with a newly
generated key and check value) until it receives a successful response.
5.5.3 Key Exchange Scenarios

NPCI will generate key exchange in the following scenarios:
1. Key exchange request from the member bank: Member bank can initiate key exchange
request 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.
2. Pre-configured time interval: A new key can be generated after a specific time interval.
The time interval is 24 hours during non-peak hours. Only NPCI may initiate this key
exchange.

NPCI System Functionalities PIN Encryption / Decryption Process
3. On detection of cryptographic error: A new key will be generated in case NPCI detects a
cryptographic error. Only NPCI may initiate this key exchange.
Note: Response code ‘81’ should be used for identifying a cryptographic error both by member banks
and NPCI.
5.6 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.7 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.8 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.9 Matching 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.

Member Responsibility Issuer
Responsibility
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.

Responsibility
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.

Responsibility
6.1.4 Stand-In functionality and Credit Card Authorization

 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 Authorisation (STIP) functionality should get active (or take over) when there is no
connectivity between NPCI and Issuing Banks or there is a fluctuation in connectivity. Along
with this, NPCI will also support handling the network traffic and act on behalf of Issuer
members for small ticket volume transactions (if opted by members)
 All authorizations, above the small ticket volume amount, will be routed to respective issuer
members for authorization approval (as per normal flow of transaction). In case Issuer node
is not available, then normal STIP will happen through NPCI.
 For any authorisation request sent by NPCI to Issuers, if there is no response received to NPCI,
NPCI will wait for the response for 15 seconds. After 15 seconds, authorisation request will
be routed to STIP. The STIP provides authorisation response to Acquiring Banks subject to
the transaction amount being less than or equal to the lower of available Ceiling Limit
prescribed by the Bank for BINs in specific.
 Such timed out reversal and advice (for the auth) messages should be generated and stored
in NPCI switch and delivered to Issuing Banks as and when the connectivity comes up, by
means of Store and Forward (SAF) mechanism.
 At the time of on boarding, the STIP option will be available to bank in a BIN specific manner
along with the small ticket volume amount for that particular BIN (if bank has opted for small
ticket volume).
 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.
 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 or equal to 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...
 The authorization transaction is timed out by the issuer NPCI system would stand in for issuer
and authorize the transaction based on limits and parameters configured for the particular
BIN with CVD checking along with PIN validation
 STIP functionality is supported both for card present as well as card not present transactions.
 NPCI will support the STIP for ONUS transactions as well, if bank opts for STIP and decides to
route the same. However, as per the set process of ONUS reporting, Issuer members need to
consider these transactions as well.
 STIP indicators will be sent to acquirers also (in authorization response) along with Issuers
(in authorization advice).
 STIP will be supported for both Quick and Full EMV transactions as well as for the fall back
transactions.
 For domestic transactions, only PIN based transactions will be supported in STIP
 STIP will be available for international transactions, both for PIN based transactions as well
as without PIN.
 Support for MCC based limit within the overall limits in STIP.
 Count on number of transactions will be maintained in STIP and transaction restrictions in
STIP will be applicable based on amount (small ticket/ ceiling limit) and other configured
parameters for a bank in BIN specific manner.
 In case of IVR transactions OTP based IVR will not be handled under STIP.
 For credit card portfolio, only DMS (dual message system) transactions are supported.

 Stand-in functionality can be activated under the following conditions :

a) Stand in Processing, Late Response from issuer (NPCI Stand In).
b) Stand-In Processing, No Response from Issuer (NPCI Stand In).
c) Stand-In Processing, Node offline or member bank signed off. .
d) Stand-In Processing, for Small Ticket Volume (if opted by a bank)

Responsibility
6.1.4.1 Scenarios for Stand-In Processing

6.1.4.1.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 detects that the transaction amount is above the small ticket size and hence 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.1.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 detects that the transaction amount is above the small ticket size and hence
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

Responsibility
6.1.4.1.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 that the transaction amount is above the small ticket size and also 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.
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.1.4.1.4 Stand-In processing, for Small Ticket Volume (if opted by a bank)
The following figure illustrates the stand-in processing for an authorization request for which the
transaction amount is below the small ticket size irrespective of whether the issuer node is
signed-off or in processing:
0100/0200
1
NPCI
0110/0210 Stand
4
In
Acquirer Issuer
5
0120/0220
6
0130/0230 7
SAF
Figure 14 Stand-In processing, for Small Ticket size
a) Acquirer initiates an authorization request/ financial request message to NPCI.

b) NPCI checks the amount and detects that the transaction is applicable for small ticket STIP
irrespective of issuer’s node status.
c) NPCI checks the issuer processor is configured for stand-in processing at NPCI for small
volume transaction.
d) NPCI checks all the parameters and configurations and then formulates an internal
response message by validating the request
e) NPCI uses the internal response to create an authorization response/ financial response
f) If issuer member bank is signed-on or issuer bank node is in processing state, NPCI
immediately sends an authorization advice/ financial advice message to the issuer.
g) Else a record of the authorization advice request/ financial advice request message is
placed in the SAF file on the NPCI for later delivery to the issuer.
h) The issuer responds with an authorization advice response/ 0130 message.
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 1003 to issuer in case of small ticket size. 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.

Responsibility
6.1.4.2 Small Ticket Size STIP Option

1. NPCI will support the option of handling the authorization of small ticket volume on behalf of
the Issuing members.
2. At the time of on boarding, the option needs to be selected and the option will be available
bank wise BIN specific manner along with the small ticket volume amount specified for that
particular BIN.
3. Members can also opt out of this option, in case the traffic needs to be handled at Issuer
members’ level.
4. The small ticket functionality will be available at NPCI level at part of the STIP offerings.
5. All authorizations transactions will be handled at NPCI end and will not be sent to issuers
6. The amount will be transaction wise small ticket volume amount for each and every
transaction happening for that particular BIN, and the STIP related Ceiling limit will be
reduced accordingly.
7. All such small ticket volume transactions liability and financial impact (if any) will be issuer’s
responsibility.
8. At the time of on boarding for STIP, the bank needs to specify the amount for small ticket size.
9. The small ticket size will be common irrespective of the channel type (ATM, PoS, e-Commerce
etc.) i.e. there will be no channel wise small ticket option available to bank.
10. For ONUS transactions also NPCI will authorize the transactions in case the same is below the
small ticket volume set by the members and the transactions are routed through NPCI.
However, as per the set process of ONUS reporting, Issuer members need to consider these
transactions as well.
11. For the small ticket traffic routing facility, NPCI will support all transaction types like POS,
ATM, E-COM, IVR, MOTO etc.
12. All the checking of parameters & BIN wise configurations shall stand applicable for small
ticket volume transactions as well.
6.1.4.3 Ceiling and Channel wise Limits

 Banks will have the option of selecting a BIN wise ceiling limit at the on barding.
 Banks will also have the option of segregating the ceiling limit by selecting the channel
wise limits.
 Ceiling limit either consolidative or as channel wise, will keep on decreasing after every
transaction happening in STIP including small ticket transactions.
 Ceiling Limit including channel wise limits will get refreshed daily as EOD activity
 After on-boarding, Issuer member can modify the STIP related parameters (along with
Ceiling limit modifications) as per the business requirements. Accordingly the parameters
will get implemented at NPCI end.

6.1.4.4 SAF Processing

 SAF (Store and Forward) will be available as bank wise configurable parameter for a
particular BIN at the time of on boarding.
 SAF mechanism will be followed for the members, who have opted for the same. The
advice messages will not be forwarded to the banks who have opted for not to receive the
SAF mechanism.
 SAF messages will work as per the existing set-up described in earlier sections of the
document.
6.1.4.5 PIN Validation during STIP

 As an enhanced security feature, NPCI will have the option to support all STIP transactions
(including small ticket volume) that have PIN as an authentication parameter.
 To support PIN based STIP, PIN offset value will be stored at NPCI end and will be
validated during all STIP authorization approval.
 All Issuing members need to pass the value to NPCI as part of EOD activity.
 A Web-UI should be given to members to upload the batch file and the same will be
processed as part of EOD activity at NPCI end. Thus PIN offset value update at NPCI end
will have time gap and will not be a real time online activity.
 After update of the offset value, all subsequent STIP authorization should be verified with
stored offset value on card wise manner for approving or declining authorizations.
 System log should be generated after update of values for identification of successful and
rejected cases.
 NPCI system will store the card wise PIN offset and will support the following options:
1. Set PIN to store appropriate PIN offset values
2. Change PIN to update appropriate PIN offset values
 Issuer Banks should be able to provide PIN offset as batch file upload mode as part of EOD
activity for all newly created/updated PINs so that the same can be stored in NPCI system
post generation of PIN.
6.1.4.6 VIP Card Management

 A VIP Card List File (VCLF) should be maintained in NPCI switch per Bank. Initial update
to VCLF parameters should be done based on inputs of Issuing Banks, to be captured at
the time of on boarding (if there is any list at that time). Subsequent update request to
VCLF should be possible through Web UI in RGCS by file upload done by the issuer bank
Issuing Banks.
 Following validations should be performed on VCLF at minimum;
1. Duplicate file name
2. File format
3. Sequence number of the file for missing sequence and repeated sequence tracking
4. File naming convention
5. PID specific checks
6. BIN specific checks
7. Open BIN range check

Member Responsibility Acquirer
Responsibilities
1. In case where file validation is unsuccessful due to checks mentioned above then RGCS
Web-UI system should reject the entire file. The rejection log should be available with
information of ‘file name’ and ‘reason of rejection’.
2. In case of file rejections, previously updated VCLF parameters should prevail during STIP
approvals.
3. For VIP card activity, links will be given to RGCS (and not in IRGCS) for the members.
4. For VIP card holders, all the checks which are to be executed or by-passed; will be based
on card wise file updating only.
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

Member Responsibility Acquirer Responsibilities
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 15 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.2 Authorization Cycle and Failure Conditions Involving

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

Responsibilities

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.2.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.2.3 System Failure Acquirer Authorization / Financial Request (Acquirer

Aware)
1
NPCI
Failure
Acquirer Issuer
Device
Figure 17 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.2.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 18 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.2.5 Validation Failure at NPCI for Acquirer Message

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

Responsibilities
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 this 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.2.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 20 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.2.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 21 System 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.2.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.

Responsibilities
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 22 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.3 Advice message scenarios for acquirer

6.2.3.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 23 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.3.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 24 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.

Responsibilities
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

Message Format Transaction
Identification
Transactions Key Data Fields

code 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 Processing Code (DE 3) must indicate Card To Card Funds
Transfer 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
OCT Processing Code (DE 3) must indicate OCT Transaction.
Money Load Processing Code (DE-3) must indicate Money Load Transaction
Processing Code (DE-3) must be 28XXXX
Service Creation Processing Code (DE-3) must indicate Service Creation
Aadhar Inquiry Processing Code (DE-3) must indicate Aadhar Inquiry
Table 13 Key Data Elements

Message Format Message Format for Issuer
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
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+

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

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
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 - C
48 Tag 058 Fraud Score M --
48 Tag 060 CHIP Transaction Authorization Indicator C --
48 Tag 066 UID Number (Aadhaar) C --
48 Tag 067 Income Tax PAN O --
48 Tag 074 Customer Telephone / Mobile Number O --
48 Tag 078 Encryption Technique Indicator C --
48 Tag 079 Transaction Identifier C C+
48 Tag 080 Additional Acquiring Information C --
48 Tag 083 Merchant Business Type C --
48 Tag 099 MAC value C C
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
105 Token data C C
105 Tag 001 Token ID M --
105 Tag 002 Token Expiration Date M --
105 Tag 003 Token Reference ID M --
105 Tag 004 Wallet ID M --
105 Tag 005 Token Type M --
105 Tag 006 Token Status O --
105 Tag 007 Payment Account Reference (PAR) O --
105 Tag 008 Token Requestor ID O --
105 Tag 009 TSP Validation Result M --
105 Tag 010 Device Type O --
105 Tag 011 Device ID O --
105 Tag 012 Device Number O --
105 Tag 013 Number of Active Tokens O --
105 Tag 014 Number of Inactive Tokens O --
105 Tag 015 Number of Suspended Tokens O --

DE Description 0100/0200 0110/0210

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.
For a Purchase transaction initiated from service based application using contactless chip cards,
DE_48 Tag 079 should have a valid Service Identifier ID. The issuer has to validate the service ID
against the service marked for the card number before authentication. Service based transactions
are only allowed for chip cards.
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+
6 Amount, Cardholder Billing C C+
10 Conversion Rate, Cardholder Billing C C+
14 Date, Expiry C --
16 Date, Conversion C C+

Format for Issuer
DE Description 0100/0200 0110/0210

28 Amount, fee C C+
51 Currency Code, Cardholder Billing C C+
52 PIN data C --
54 Additional amount M M+
55 Chip data C C
105 Token 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 066 UID Number (Aadhaar) O --
48 Tag 071 IP address and Country Code/ International
Authorization Network Identifier M --
48 Tag 075 Image code C --
48 Tag 076 Personal Phrase O --
48 Tag 077 Issuer supplied ID / Unique ID C --

Format for Issuer
DE Description 0100/0200 0110/0210

52 PIN data C --
102 Account Id 1 -- O
120 Private data 3 -- O+
Table 17 RuPay E-Commerce Message – Issuer
The above message format also stands applicable for ‘Card + OTP’ method of RuPay e-Commerce
Implementation using PaySecure where in customer PIN is not captured by PaySecure. For ‘Card
+ OTP’ method, registration at PaySecure is not performed. OTP is continued to be generated,
captured and validated by Issuer’s Authentication system (in case ECI is ‘31’).
7.2.1.4 E-Commerce 3D Purchase (Secure / Non-Secure)

DE Description 0100 (NPCI  0110 (Issuer 
Issuer) NPCI)
28 Amount, fee C C+

DE Description 0100 (NPCI  0110 (Issuer 

Issuer) NPCI)
48 Tag 055 CAVV Match Result Code M M
48 Tag 057 Authentication Result Code M --
48 Tag 064 Second Factor Authentication Result Code M --
48 Tag 065 Unpredictable Number
48 Tag 068 CAVV Key Indicator M --
48 Tag 069 CAVV value M --
48 Tag 071 IP address and Country Code /International
Authorization Network Identifier / O --
48 Tag 072 Authentication Tracking Number M --
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

Format for Issuer
 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 IVR Request (from PaySecure) - NPCI to Issuer

The following table describes format of ISO message forwarded by NPCI to issuer for the IVR
request coming from PaySecure.
DE Description 0100/0200 0110/0210

28 Amount, fee C C+

DE Description 0100/0200 0110/0210

48 Tag 077 Issuer supplied ID / Unique ID C --
52 PIN data C --
120 Private data 3 -- O+
Table 19 IVR Request (from PaySecure) to Issuer
7.2.1.7 Cash at PoS

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

28 Amount, fee C C+

Format for Issuer
DE Description 0100/0200 0110/0210

52 PIN data C --
55 Chip data C C
105 Token data C C
Table 20 Cash at PoS– Issuer
Note: NPCI will not support cash @ POS transactions with signature

7.2.1.8 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

Format for Issuer

Table 21 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.
7.2.1.9 Balance Inquiry

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

40 Service Code C --

DE Description 0100/0200 0110/0210

52 PIN data C --
54 Additional amount -- M
55 Chip data C C
Table 22 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.10 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

Format for Issuer

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 23 Reversal Message – Issuer
7.2.1.11 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


/0200 /0210 Edit 0210 (NPCI (NPCI 
13 Date, local transaction M M+ M M M
14 Date, Expiry C -- -- -- --
15 Date, Settlement -- C+ C C C
16 Date, conversion -- C+ C C C
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
105 Token Data C C C C C

Format for Issuer

/0200 /0210 Edit 0210 (NPCI (NPCI 
120 Private data 3 C C C C C
121 Private data 4 O O+ O O O
126 Private data 8- C -- -- -- --
Biometric data
127 Private data 7- C -- -- -- --
Biometric data
Table 24 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.12 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 25 Network Management Message – Issuer
Note: DE-48 will be present in Key Exchange message when DE-70 value will be ‘184’.
7.2.1.13 Pin Change

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

(NPCI  Issuer) NPCI)

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 26 Pin Change Message – Issuer
7.2.1.14 Mini Statement

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


Format for Issuer
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 001 Transaction type M M
120 Tag 002 Product Indicator M M
120 Tag 005 No. of lines in Mini Statement -- M
120 Tag 006 Mini Statement Data -- M
Table 27 Mini Statement Message – Issuer
7.2.1.15 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.
Note: For detailed explanation, it is requested to refer a separate specific document for card to card
fund transfer – “RuPay Interface Specification VAS Addendum Version 1.1.pdf”

 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

Format for Issuer

(NPCI  Issuer) Issuer NPCI)
102 Account Id 1 -- M
103 Account Id 2 M M+
Table 28 Card to Card Fund Transfer-Debit leg to the issuer
 Card to Card Funds Transfer (Credit to the beneficiary)

(NPCI  Beneficiary 
Beneficiary) NPCI)
28 Amount, fee C C+


(NPCI  Beneficiary 
Beneficiary) NPCI)
102 Account Id 1 O O+
103 Account Id 2 M O
121 Private data 4 O O
Table 29 Card to Card Fund transfer-Credit to the beneficiary
7.2.1.16 Mobile Number Update

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


Format for Issuer
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 30 Mobile Number Update – Issuer
7.2.1.17 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 31 Cheque Book Request – Issuer
7.2.1.18 Statement Request

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


Format for Issuer
DE Description 0100/0200 0110/0210

52 PIN data C --
55 Chip data C C
Table 32 Statement Request – Issuer
7.2.1.19 Declined Advice

The following message describe declined Authorization Advice Message to issuer in case of
transaction declined at NPCI Switch because of quick EMV validation, the Fraud score reject and
UIDAI rejected in case of failed biometric authentication.

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 - --
105 Token data C C

Format for Issuer
DE Description 0120 / 0220 0130 / 0230

Table 33 Decline Advice Message (Quick EMV) – Issuer
Value in DE-39 shall show the reason of decline for the particular transaction.

7.2.1.20 International Non-Secure e-Commerce transaction to Issuer

DE Description 0100/0200 0110/0210
48 Tag 052 CVD2 Value C -
48 Tag 053 CVD2 Match result - C
48 Tag 056 ECI indicators M -
48 Tag 060 Transaction Authorization Indicator C --

Format for Issuer
Table 34: International e-Commerce to Issuer
7.2.1.21 STIP Advice Request to Issuer

DE Description 0120 / 0220 0130 / 0230
14 Date, expiry O --
23 Card sequence number O O+
28 Amount, fee C C+
48 Tag 060 Transaction Authorization Indicator M --
48 Tag 066 UID Number (Aadhaar) C C+
60 Advice reason code M --
105 Token data C C

DE Description 0120 / 0220 0130 / 0230

Table 35: STIP Advice Request to Issuer
7.2.1.22 File Update/ Enquiry Message

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.
The same message format with a specific action and file update codes will be applicable for File
Enquiry message.
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
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

Format for Issuer
DE Description 0302 0312 Comments

(Issuer  (NPCI 
NPCI) Issuer)
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.1.23 Original Credit Transaction

The below table describes the fields required in Original Credit Transaction
DE Description 0200 0210 (Merchant

(NPCI  Merchant Acquirer  NPCI)
Acquirer)
42 Card acceptor ID M M
43 Card acceptor name / location M M
48 Tag 083 Merchant Business Type -- C
104 OCT Data M M+
104 Tag 001 Bill number O O+
104 Tag 002 Mobile number O O+
104 Tag 003 Store ID O O+
104 Tag 004 Loyalty number O O+
104 Tag 005 Reference ID O O+
104 Tag 006 Consumer ID O O+
104 Tag 007 Purpose O O+

DE Description 0200 0210 (Merchant

(NPCI  Merchant Acquirer  NPCI)
Acquirer)
104 Tag 008 Remitter instrument type M M+
104 Tag 009 Remitter instrument ID M M+
104 Tag 010 Remitter name O O+
104 Tag 011 Merchant IFSC code O O+
104 Tag 012 Merchant account number O O+
104 Tag 013 Payload format indicator M M+
104 Tag 014 Point of initiation method M M+
104 Tag 015 Tip or Convenience fee indicator O O+
104 Tag 016 Tip or Convenience fee – amount O O+
104 Tag 017 Convenience fee percentage O O+
104 Tag 018 NPCI reserved field 1 O O+
Table 37 OCT Message To Issuer
7.2.1.24 Money Load Transaction

DE Description 0200 / 0100 0210 / 0110
(NPCI  Issuer) (Issuer NPCI)
14 Date Expiry C -
23 Card Sequence Number M M+
42 Card acceptor ID M -
43 Card acceptor name / location M -

Format for Issuer
DE Description 0200 / 0100 0210 / 0110

48 Tag 079 Transaction Identifier M M+
48 Tag 082 Source Of Funds M M+
48 Tag 084 Service ID C --
55 Chip Data M M
105 Token data C C
Table 38 Money Load Transaction Message – Issuer
This transaction is only allowed from service based terminals. The transaction has to be chip
based. This transaction should have DE-48 tag 079, also DE-55 should have DF15 as a mandatory
tag.
7.2.1.25 Service Creation Request

DE Description 0200 / 0100 0210 / 0110
14 Date Expiry C -

DE Description 0200 / 0100 0210 / 0110

48 Tag 084 Service ID C --
55 Chip Data M M
105 Token data C C
Table 39 Service Creation Message – Issuer
tag.
7.2.1.26 Aadhar Number Inquiry

DE Description 0200 / 0100 0210 / 0110

Format for Issuer
DE Description 0200 / 0100 0210 / 0110

14 Date Expiry M -
48 Tag 066 UID Number (Aadhaar) - C
55 Chip Data M M
Table 40 Aadhar Number Inquiry Message – Issuer
This transaction type is only allowed for Biometric Based Authentication. In case of a successful
response, issuer should Populate DE-48 Tag 066 with Aadhar Number linked to that Card.
7.2.1.27 ARQC Validation and ARPC Generation – Onus Scenario
DE Description 0100/0200 0110/0210

(Issuer  NPCI) (NPCI  Issuer)
5 Amount, Settlement -- C
6 Amount, card holder billing -- C

DE Description 0100/0200 0110/0210

9 Conversion rate, Settlement -- C
10 Conversion rate, card holder billing -- C
15 Date, Settlement -- C
16 Date, conversion -- C
28 Amount, fee C C+
44 Additional Response Data -- C
48 Tag 054 CVD/iCVD Match result code O --
48 Tag 060 CHIP Transaction Authorization Indicator -- M
48 Tag 078 Encryption Technique Indicator M --
48 Tag 080 Additional Acquiring Information O --
48 Tag 081 Authorization Response Code M --
50 Currency code, settlement -- C
51 Currency code, card holder billing -- C
55 Chip data M M
62 Private data 1-Biometric Data -- C
63 Private data 2, Biometric data C --
105 Token data -- C
105 Tag 001 Token ID -- M
105 Tag 002 Token Expiration Date -- M
105 Tag 003 Token Reference ID -- M
105 Tag 004 Wallet ID -- M
105 Tag 005 Token Type -- M
105 Tag 006 Token Status -- O

Format for Issuer
DE Description 0100/0200 0110/0210

105 Tag 007 Payment Account Reference (PAR) -- O
105 Tag 008 Token Requestor ID -- O
105 Tag 009 TSP Validation Result -- M
105 Tag 010 Device Type -- O
105 Tag 011 Device ID -- O
105 Tag 012 Device Number -- O
105 Tag 013 Number of Active Tokens -- O
105 Tag 014 Number of Inactive Tokens -- O
105 Tag 015 Number of Suspended Tokens -- O
126 Private data 8- Biometric Data C --
127 Private data 7- Biometric Data C --
Table 41 ARQC Validation and ARPC Generation- Onus
Note: In case of onus quick EMV scenario, the transaction type in DE-3 Processing Code ‘81xxxx’
will indicate issuer’s request for ARQC validation and ARPC generation. NPCI will respond back
with ARQC validation result in DE-48 Tag060 and ARPC in DE-55 Tag091. ARPC will be generated
basis the response code received in DE-48 Tag 081.
1. Issuer switch may choose to perform ARQC validation first and then proceed with
the authorization processing. In that case, issuer switch can send request with DE-
48 Tag 081 as 00.
1. If the authorization processing is successful (response code 00), issuer
switch can complete the transaction with terminal with ARPC received in
the earlier request.
2. If the authorization processing fails, issuer switch has to send another
request with DE-48 Tag 081 with respective response code (that will be
sent to terminal in DE-55 Tag 91). Issuer switch will have to complete the
transaction with terminal with ARPC received in this request.
Issuer switch may choose to perform authorization processing first. In that case, after
authorization processing, issuer switch can send request with DE-48 Tag 081 with respective
response code (that will be sent to terminal in DE-55 Tag 91). Issuer switch will have to complete
the transaction with terminal with ARPC received in this request.
Note: In case of onus Token Validation scenario, the transaction type in DE-3 Processing Code
‘81xxxx. NPCI switch will validate the Token details and send the response to issuer in DE-105.

Message Format Message Format for Acquirer
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)
28 Amount, fee C C+
48 Tag 079 Transaction Identifier C C+

Format for Acquirer
DE Description 0100/0200 0110/0210

52 PIN data C --
55 Chip data C C
111 Encrypted Personal Identity Data( C --
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
123 mc attribute Data C --
126 Additional Data (Uses, fdc, idc , ki , C --
type, cdc, fpmi, fpmc, irmi, irmc, fdmi,
fdmc)
127 Additional Data(skey, ci, Hmac, ac, sa C --

,lk, rc="")
Table 42 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.
Acquirer must populate conversion rate in DE-48 Tag080 in case of transactions originating at
Dollar Terminals.
For a Purchase transaction initiated from service based application using contactless chip cards,
DE_48 Tag 079 should have a valid Service Identifier ID. The Acquire has to validate the service

ID against the merchant before sending the authentication to NPCI. Service based transactions
are only allowed for chip cards.
7.3.1.2 Purchase with Cashback

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

16 Date, Conversion -- C
28 Amount, fee C C+

Format for Acquirer
DE Description 0100/0200 0110/0210

51 Currency code, cardholder billing -- C
52 PIN data C --
54 Additional amount M M
55 Chip data C C
62 Private data 1-, Biometric data -- C
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
type, cdc, fpmi, fpmc, irmi, irmc,
fdmi, fdmc)
127 Additional Data(skey, ci, Hmac, ac, C --

sa ,lk, rc="")
Table 43 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

DE Description 0100/0200 0110/0210

5 Amount, settlement -- C
14 Date, expiry M --
28 Amount, fee C C+
48 Tag 061 Transaction Id M M+
48 Tag 071 International Authorization Network Identifier --
/ IP address and Country Code M
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 --

Format for Acquirer
DE Description 0100/0200 0110/0210

Table 44 RuPay E-Commerce Purchase Message – Acquirer
7.3.1.4 IVR Request (from PaySecure) to NPCI

The following table describes format of ISO message to NPCI for the IVR request coming from
PaySecure.
DE Description 0100/0200 0110/0210

1 Secondary Bit Map C C
28 Amount, fee C C+

DE Description 0100/0200 0110/0210

48 Tag 077 Issuer supplied ID / Unique ID O --
52 PIN data C --
Table 45 RuPay E-Commerce Purchase Message – Acquirer
7.3.1.5 E-Commerce 3D Purchase

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

28 Amount, fee C C+

Format for Acquirer

48 Tag 057 ICS1 result code C C
48 Tag 064 ICS2 result code C C
48 Tag 068 ICS1 value C --
48 Tag 069 ICS2 value C --
48 Tag 071 IP address and Country Code/ International --
Authorization Network Identifier O
61 POS data code M -
Table 46 E-Commerce 3D Purchase Message – Acquirer
7.3.1.6 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.7 Cash at PoS

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

28 Amount, fee C C+

Format for Acquirer
DE Description 0100/0200 0110/0210

52 PIN data C --
55 Chip data C C
62 Private data 1- Biometric Data -- C
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
fdmc)

,lk, rc="")
Table 47 Cash at PoS / Cash Withdrawal Message – Acquirer
Note: NPCI will not support cash @ POS transactions with signature
Acquirer must populate conversion rate in DE-48 Tag080 in case of transactions originating at
Dollar Terminals.

7.3.1.8 Cash Withdrawal - ATM

The following table describes Cash Withdrawal message for acquirer.

23 Card sequence number C C
28 Amount, fee C C
33 Forwarding institution code C C
48 Additional data M M+
52 PIN data C --
54 Additional Amount -- O
55 Chip data C C

Format for Acquirer

FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
fdmc)

,lk, rc="")
Table 48 Cash Withdrawal - ATM Message – Acquirer
7.3.1.9 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
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)

Format for Acquirer
DE Description 0100/0200 0110/0210

fdmc)
,lk, rc="")
Table 49 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.10 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+


44 Additional Response data -- C
55 Chip data C C
90 Original data element M M+
95 Replacement amount C C+
102 Account Identification 1 O O+
Table 50 Reversal Message – Acquirer
7.3.1.11 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 Date, Expiry C -- --
15 Date, Settlement -- C C
16 -- C C
Date, conversion
18 Merchant category code M -- --
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 -- --

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

0200 Edit (0110) (NPCI 
Failure Acquirer)
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 -- C C
billing
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 - - -
102 Account Identification 1 -- O O
111 Encrypted Personal Identity C -- --
Data( FP/BFD/IRIS)
Data( FP/BFD/IRIS)
Data( FP/BFD/IRIS)
Data( FP/BFD/IRIS)
Data( FP/BFD/IRIS)
Data( FP/BFD/IRIS)
Data( FP/BFD/IRIS)
Data( FP/BFD/IRIS)
Data( FP/BFD/IRIS)
120 Private data 3 O O O
123 mc attribute Data C -- --
126 Additional Data (Uses, fdc, idc , C -- --
ki , type, cdc, fpmi, fpmc, irmi,
irmc, fdmi, fdmc)
127 Additional Data(skey, ci, Hmac, C -- --
ac, sa ,lk, rc="")

Table 51 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.12 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 52 Network Management Message
Note: DE-48 will be present in Key Exchange message when DE-70 value will be ‘184’.
7.3.1.13 Pin Change

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


Format for Acquirer
DE Description /0200 /0210

48 Tag 058 Fraud Score -- --
52 PIN data M --
55 Chip data C C+
120 Tag 001 Transaction Type M M+
120 Tag 004 New Pin Block M --
Table 53 Pin Change Message – Acquirer
7.3.1.14 Mini Statement

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


DE Description 0100/0200 0110/0210

48 Tag 058 Fraud Score -- --
52 PIN data C --
55 Chip data C C
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
120 Tag 001 Transaction Type M M+
120 Tag 005 No. of lines for mini statement -- M
120 Tag 006 Mini statement data -- M

Format for Acquirer
DE Description 0100/0200 0110/0210

fdmc)

,lk, rc="")
Table 54 Mini Statement Message – Acquirer
7.3.1.15 Card to Card Funds Transfer

 Card to Card Fund Transaction
Refer Annexure 1 for transaction flow and detailed explanation of Card to Card Transfer
Note: For detailed explanation, it is requested to refer a separate specific document for card to card
fund transfer – “RuPay Interface Specification VAS Addendum Version 1.1.pdf”
Card to Card Funds Transfer for acquirer

(Acquirer  (NPCI 
NPCI) Acquirer)
28 Amount, fee C C+


NPCI) Acquirer)
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 -- C
103 Account Id 2 M M+
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)

Format for Acquirer

NPCI) Acquirer)
126 Additional Data (Uses, fdc, idc , ki , type, C --
cdc, fpmi, fpmc, irmi, irmc, fdmi, fdmc)
127 Additional Data(skey, ci, Hmac, ac, sa ,lk, C --
rc="")
Table 55 Card to Card Fund transfer
7.3.1.16 Biometric Onus Authentication

The following table describes Biometric Authentication message for acquirer.
DE Description 0100/0200 0110/0210

2 Primary Account Number M M
3 Processing Code M M
4 Amount, Transaction M M
7 Date/time transmission M M
11 System trace audit number M M
12 Time, local transaction M M
13 Date, local transaction M M
14 Data, expiry C --
19 Acquiring institution country code M M
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
48 Tag 051 Product code M M
48 Tag 066 UID Number (Aadhaar) M --
49 Currency code, transaction M M
62 Private data 1- Biometric Data - C

DE Description 0100/0200 0110/0210

FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
fdmc)

,lk, rc="")
Table 56 Biometric Onus Authentication
7.3.1.17 Mobile Number Update

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


Format for Acquirer
DE Description 0100/0200 0110/0210

28 Amount, fee C C+
48 Tag 054 CVD/iCVD Match result code -- M
48 Tag 074 Customer Telephone / Mobile Number M --
52 PIN data C --
55 Chip data C C
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)

DE Description 0100/0200 0110/0210

fdmc)

,lk, rc="")
Table 57 Mobile Number Update
7.3.1.18 Cheque Book Request

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

28 Amount, fee C C+

Format for Acquirer
DE Description 0100/0200 0110/0210

52 PIN data C --
55 Chip data C C
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
fdmc)

,lk, rc="")
Table 58 Cheque Book Request
7.3.1.19 Statement Request

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


DE Description 0100/0200 0110/0210

14 Data, expiry C --
28 Amount, fee C C+
48 Tag 054 CVD/iCVD Match result code -- M
52 PIN data C --
55 Chip data C C
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)

Format for Acquirer
DE Description 0100/0200 0110/0210

FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
FP/BFD/IRIS)
fdmc)

,lk, rc="")
Table 59 Statement Request
7.3.1.20 OCT Transaction

The following table describes OCT message for Originator.

(Originator  (NPCI 
NPCI) Originator)


(Originator  (NPCI 
NPCI) Originator)
42 Card acceptor ID M M
48 Tag 083 Merchant Business Type -- C
104 OCT Data M M+
104 Tag 001 Bill number O O+
104 Tag 002 Mobile number O O+
104 Tag 003 Store ID O O+
104 Tag 004 Loyalty number O O+
104 Tag 005 Reference ID O O+
104 Tag 006 Consumer ID O O+
104 Tag 007 Purpose O O+
104 Tag 008 Remitter instrument type M M+
104 Tag 009 Remitter instrument ID M M+
104 Tag 010 Remitter name O O+
104 Tag 011 Merchant IFSC code O O+
104 Tag 012 Merchant account number O O+
104 Tag 013 Payload format indicator M M+
104 Tag 014 Point of initiation method M M+
104 Tag 015 Tip or Convenience fee indicator O O+
104 Tag 016 Tip or Convenience fee – amount O O+
104 Tag 017 Convenience fee percentage O O+
Table 60 OCT Message To Acquirer
7.3.1.21 Money Load Transaction

DE Description 0200 / 0100 0210 / 0110
(Acquirer  NPCI) (NPCIAcquirer)
14 Date Expiry C --

Format for Acquirer
DE Description 0200 / 0100 0210 / 0110

(Acquirer  NPCI) (NPCIAcquirer)
48 Tag 067 Income Tax PAN O -
48 Tag 074 Customer Telephone / Mobile Number O -
48 Tag 078 Encryption Technique Indicator M -
48 Tag 082 Source Of Fund M M+
55 Chip Data M M
61 POS data code M -
Table 61 Money Load Transaction Message – Acquirer
based. This transaction should have DE-48, tag 079 and tag 082, also DE-55 should have DF15 as
a mandatory tag.
7.3.1.22 Service Creation Request

DE Description 0200 / 0100 0210 / 0110
(Acquirer  NPCI) NPCIAcquirer
14 Date Expiry C -

DE Description 0200 / 0100 0210 / 0110

(Acquirer  NPCI) NPCIAcquirer
55 Chip Data M M
Table 62 Service Creation Message – Acquirer
tag.

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.
Abbreviation Meaning
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 63 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 64 Date 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

Data Element Description Detailed Description of Data Elements
Compliance Compliance rules applicable to the data

element
Table 65 Data Element Information Components
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.
In Original Credit Transaction (OCT) message for Merchant

credit, this field will contain Merchant PAN.
Presence Mandatory-This field is mandatory across all messages except
for network management messages.
Conditional-None
Optional-None

Data Element Description Detailed
Description of Data Elements
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
26 Original Credit Transaction (OCT)
27 Loyalty Redemption
28 Money Load Transaction (qSPARC)
31 Balance Enquiry
36 Loyalty Inquiry
37 Aadhar Inquiry
40 Fund Transfer
81 ARQC Validation and ARPC Generation –
Onus Scenario
83 Service Creation (qSPARC)
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 may 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.
08 QR code
09 NFC
10 Bluetooth low energy (BLE)
80 Fall-back 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
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 N12
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.
For International transactions (acquiring outside India),
RuPay issuer may receive a RRN in a format other than
RuPay’s i.e. 12 digit numeric but not in YDDDHHSSSSSS
format.
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 AN6
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
For domestic transactions, this field should not contain all
zeroes or all blank spaces or special character in response.
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 AN2
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
Action Meaning
A Approved
D Decline
C Capture
Code Description Action

00 Approved or completed A
Successfully.
03 Invalid merchant. D
04 Pick-up. C
05 Do not honour. In case CVD, CVD2, iCVD verification D
fails, Inactive or Dormant account
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
25 Unable to locate record D
27 File Update field edit error D
28 Record already exist in the file D
29 File Update not successful 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
69 Mobile number record not found/ mis-match D
71 Deemed Acceptance A
74 Transactions declined by Issuer based on Risk Score D
75 Allowable number of PIN tries exceeded, decline D
81 Cryptographic Error 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 D
violation.
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
MU No Aadhar linked to Card D
UG INVALID BIOMETRIC DATA D
U3 BIOMETRIC DATA DID NOT MATCH D
WZ Technical Decline UIDAI D
Table 66 Response Code Table
Code Description
CI Compliance error code for issuer
CA Compliance error code for acquirer

Code Description
M6 Compliance error code for LMM
ED E-commerce decline
Table 67 Compliance Reject Response Code

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

91 Timeout Full reversal
21 Acquirer received 0110/0210 with DE38 (ATM Full Reversal
only)
22 Acquirer received 0110/0210 with DE38 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 69 Response codes Supported for Reversal Response / Request Messages

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

00 Approved or Completed successfully. A
Table 71 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 and DE-44 specifying data
element in error.. 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’. For ATM transactions response code may be ’21.
 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:

then NPCI will route the transaction to the issuer and if issuer declines the transaction with
response code other than ‘ED’ and that response is not from the table defined in DE 39 then 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 then NPCI will route the transaction to the issuer and if issuer declines the
transaction with response code other than ED and that response is not from the table
defined in DE 39 then 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.26.3.1 Card + OTP Method

For ‘Card + OTP’ method, PaySecure will not prompt for PIN and customer need not register at
PaySecure (Image selection). Hence both PIN (DE-52) and Image Code (DE-48 Tag075) will not
be present in e-Commerce request (ISO) to Issuer switch.
Issuer can use the ECI (DE-48 Tag056) with value ‘31’ or ‘32’ to identify the ‘Card + OTP’ method.
The ‘Card Authentication Method’ i.e. DE-61 SF-8 for ‘Card + OTP’ method will be ‘G’.
OTP is continued to be generated, captured and validated by Issuer’s Authentication system (in
case ECI is ‘31’).

8.3.26.4 International e-Commerce Non-Secure Transactions to RuPay

Issuer
In case of International e-Commerce Non-Secure transactions, NPCI will populate e-Commerce
Indicator Tag056 in DE-48 as ‘07’ when CVD2 is present, or
‘08’ when CVD2 is absent in request along with ‘Cardholder Authentication method’
Issuer may also receive e-Commerce Indicator Tag056 in DE-48 as ‘06’ in case the same is
received by NPCI in request from acquirer (international).
Issuer can identify an e-commerce transaction from value ‘810’ in ‘PoS Entry Mode’ DE-22 and
value ’59’ in ‘PoS Condition Code’ DE-25.
Issuer from values in data fields, like DE-6 ‘Card Holder Billing Amount’, DE-51 ‘Card Holder
Billing Currency’, DE-19 ‘Acquiring Country Code’, Merchant Country Code in DE-43, can identify
the transaction as International.
Note: BIN based routing is supported for this functionality, by NPCI
8.3.26.5 Original Credit Transaction (OCT) Message
In case of OCT transaction, the merchant acquirer bank will reject the transaction with response
code 03 in case of incorrect merchant PAN or merchant (merchant account) status. Merchant
acquirer bank shall not populate response code 71 (deemed acceptance) in any case. In case the
originator is receiving response code 71 from NPCI, originator bank shall not reverse the debit to
the consumer. In case the originator bank times out with NPCI, originator should mark the
transaction with response code 71. Originator has to reconcile the OCT messages having response
code 71 with the raw data file / settlement report received from NPCI.
8.3.26.6 Biometric Authentication
In case of transaction initiated with biometric Data and if response code is sent as WZ. To
acquirer then DE-44 will have the exact reason code by which the same was rejected from UIDAI.

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.
For OCT message, this field will have a system generated value
from the originator in the request. In the response Acquiring
bank populates this field with the Original Merchant ID
allocated for the Merchant.
For International Lounge Transactions, Transaction shall only

be allowed from any of the below merchant ID with the
Transaction Currency code as EUR,GBP,USD
 2100549098
 2100549087
 2100548944
Constraints When present this is not to be echoed back in a response.
OCT message will contain these fields in both request and
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.
In case transaction rejected with response code WZ. This field

will describe the exact response code received from UIDAI.
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
AMTI MTI If MTI is 0200 when BIN/ IIN is DMS (PIN/ SIGN) type
If MTI is 0100 when BIN/ IIN is SMS type
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 date 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.
A038 38 If DE38 is present in Request from acquirer.
A040 40 If it is a CP transaction then should be present.
A041 41 If DE-41 is absent.

Acquirer Reject Error in Reject Reason

Reason Code DE
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
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
A061 61 If DE-61 is absent or for Biometric Transactions if subfield2
value is not ‘3’ but DE 63,126,127 are populated
A063 63 If DE-63 is absent for Biometric Transactions.
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
A104 104 If DE 104 is absent in OCT Message received from originator
A195 22,25,35, If DE-22 validation failed while checking with DE-25, DE-35, DE-
45,52,55 45, DE-52, DE-55 and DE-61.
and 61
A196 104 If mandatory tags are missing in OCT message received from
originator
A197 52 If DE-52 is missing when DE-48 Tag 056 value is 035 and DE-61
SF 8 value is 6.
A198 48 If DE-48 Tag 082 have invalid values for qSPARC based Money
Load transactions.
A199 55 If tag DF15 is missing for qSPARC based service transactions.
Table 72 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

Issuer Reject Error in Reject Reason

Reason Code DE
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
I090 90 If present in 0110/ 0210 response or absent in 0430 response
I104 104 Field Missing in Response message from merchant acquirer in
OCT message
I196 104 Mandatory tags missing in OCT message from merchant
acquirer.
I197 48 If Tag 079 present in Request and not present in response.
I198 48 If Tag 082 present in Request and not present in response.
I199 48 If DE-39=00 and Tag 066 is missing in biometric based
authentication response.
Table 73 Issuer Compliance Reject Reason code
UIDAI Response
Description
Code
UB MISSING PI DATA AS SPECIFIED IN USES

UC MISSING PA DATA AS SPECIFIED IN USES
UD MISSING PIN DATA AS SPECIFIED IN USES
UE UNKNOWN ERROR
UF MISSING OTP DATA AS SPECIFIED IN USES
UG INVALID BIOMETRIC DATA
UH MISSING BIOMETRIC DATA SPECIFIED IN USES
UI UIDAI TIME OUT
UJ Missing PFA data specified in USES
UK MISSING VALUE FOR BT ATT IN USES ELEMENT
UL INVALID VALUE IN BT ATT IN USES ELEMENT
UM NO AUTH FACTORS FOUND IN AUTH REQUEST
UN INVALID DOB VALUE IN PI ELEMENT
UO INVALID MV VALUE IN PI ELEMENT
UP INVALID MV VALUE IN PFA ELEMENT
UQ INVALID MS VALUE
UR BOTH PA AND PFA ARE PRESENT

US TECH ERROR 1-RELATED TO ABIS INTERACTION

UT TECH ERROR 2- UID DB SERVER DOWN
UU TECH ERROR 3 - XML ERROR
UV UNSUPPORTED OPTION
UY INVALID PID XML FORMAT
UZ UNAUTHORIZED ASA CHANNEL
U0 UNSPECIFIED ASA CHANNEL
U1 PI BASIC ATTR DEMOGRAPHIC DID NOT MATCH
U2 PI ADDRESS ATTR DEMOGRAPHIC NOT MATCH
U3 BIOMETRIC DATA DID NOT MATCH
U4 INVALID ENCRYPTION
U5 INVALID XML FORMAT
U6 INVALID DEVICE
U7 INVALID AUTHENTICATOR CODE
U8 INVALID Auth XML VERSION
U9 INVALID USES ELEMENT ATTRIBUTES
VA PIN RETRIES RESET
VB INVALID BIOMETRIC POSITION
VC PI USAGE NOT ALLOWED AS PER LICENSE
VD PA USAGE NOT ALLOWED AS PER LICENSE
VE PFA USAGE NOT ALLOWED AS PER LICENSE
VF FMR USAGE NOT ALLOWED AS PER LICENSE
VG FIR USAGE NOT ALLOWED AS PER LICENSE
VH IIR USAGE NOT ALLOWED AS PER LICENSE
VI OTP USAGE NOT ALLOWED AS PER LICENSE
VJ PIN USAGE NOT ALLOWED AS PER LICENSE
VK FUZZY USAGE NOT ALLOWED AS PER LICENSE
VL LOCAL LANGUAGE USAGE NOT ALLOWED AS PER
VM TECHNICAL ERROR
VN TECHNICAL ERROR
VO TECHNICAL ERROR
VP TECHNICAL ERROR
VQ TECHNICAL ERROR
VR TECHNICAL ERROR
VS Missing Biometric data in UIDAI CIDR
VT Invalid certificate identifier in “ci” attribute of “Skey”
VU INVALID ENCRYPTION OF PID
VV INVALID ENCRYPTION OF HMAC
VW AUA NOT AUTHORIZED FOR ASA
VX SUB-AUA NOT ASSOCIATED WITH "AUA"
VY INVALID PID XML VERSION

VZ Duplicate Irises used

V0 REQUEST EXPIRED
V1 INVALID TIME STAMP
V2 Duplicate Request
V3 HMAC VALIDATION FAILED
V4 AUA licence key expired
V5 ASA licence key expired
V6 INVALID INPUT
V7 UNSUPPORTD LANGUAGE
V8 DIGITAL SIGNATURE VERIFICATION FAILED
V9 INVALID KEY INFO IN DIGITAL SIGNATURE
W0 FMR & FIR IN 1 TXN
W1 MORE THAN ONE FINGER IN SINGLE FIR
W2 FMR/FIR EXCEED 10
W3 IIR SHDNT EXCD 2
W4 SESSION KEY EXPIRE
W5 BEST FNGR DTCTN NOT DONE
W6 DUPLICATE FING USED
W7 INVALD PIN CODE
W8 INVALID GEO CODE
W9 OTP VALIDATION FAILD
WA Biometrics Locked
X0 TKN VALDTN FAILED
X1 SYNC KEY USE NOT ALLOWED
X2 INVALID FINGER DEVICE
X3 INVALID IRIS DEVICE
X4 INVALID DEMOGRAPHIC DATA
X5 BFD not allowed as per license
X6 TECHNICAL ERROR CATEGORY 3
X7 AADHAR NO STST LOST/DECEASED/NOT ACT
X8 AADHAR NO DOSENT EXIST IN CIDR
X9 Aadhaar Cancelled due to various reasons
UX REQUEST OLDER THAN 24 hours
UW TRANSACTION AMOUNT EXCEED LIMIT
M4 NRE ACCOUNT
M6 LIMIT EXCEEDED

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 CAVV Match Result Code 01=CAVV passed verification-
authentication
02=CAVV failed verification -
authentication
03=CAVV passed validation—
attempt
04=CAVV failed validation—
attempt
05=CAVV not validated, issuer
not participating in CAVV
validation
06=CAVV Unable to perform
authentication
056 C n2 ECI indicators 05—Secure Ecommerce with 3D
Secure
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
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
31 - e-Commerce (Card + OTP) -

OTP Authentication by IAS
32 - e-Commerce (Card + OTP) -

OTP Authentication by NPCI
33 - e-Commerce (with only card

details)
35-e-Commerce with Card and

Online Pin
41 – IVR request from

PaySecure– Authenticated by
Issuer (IAS)
50 – Quick Checkout,
Authenticated by Issuer IAS
(Card + OTP)
51 – Quick Checkout
Authenticated by Issuer (Card +
Online Pin)
52 – Quick Checkout
Authenticated by NPCI
(Username + Password)
53- Connected Checkout

Authenticated by NPCI
(Merchant Credentials)
54- Quick Checkout Registration

(Card + Online Pin)
057 C n2 Authentication Result
Code
00 - Authentication successful
05 - Authentication could not be
performed
07 - Acquirer attempt, proof of
authentication attempt
generated for non-participating
issuer or cardholder )
08 - Acquirer attempt, issuer
ACS not available proof of
authentication attempt
generated for participating
issuer with server unavailable

09 - Authentication failed
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- If it is authorized
Authorization Indicator SUCCESSFULLY in STIP. Only
available in STIP for EMV FULL
Populated by NPCI
CHIP Issuers in STIP mode.
during request for chip
transactions in case
2-- If it is authorized in STIP.
issuer has availed for on-
behalf or EMV STIP Only available for MAGNETIC/
Fall-back STIP.
services with RuPay.
Also used to indicate
Magnetic Card STIP 3-- If it is authorized successfully
transactions and UIDAI / in STIP. Only available in STIP
Aadhaar authenticated for Quick EMV Issuance.
transactions.
4—Decline in STIP
5- ARQC validation is done by

RuPay and is SUCCESSFUL.
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 n2 Second Factor
Authentication Result
Code:
00 No second factor
authentication
11 Reserved for future use.
12 Reserved for future use.

065 C N4 Unpredictable Number This is a 4-digit code that
contains the four least
significant digits for the
authentication tracking
number (Tag 072)
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 n2 CAVV Key Indicator 01 - CAVV key set 1
02 - CAVV key set 2
(Certification/Test)
03–99 – Reserved
069 C n3 CAVV This is a 3-digit code generated
by the issuer that may be used
by the issuer to validate the
authentication response during
authorization.
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 n16 Authentication Tracking This is a 16-digit code generated
Number by the issuer’s ACS or Attempt
ACS to identify the transaction.
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. Default Value is ‘NOVAL’
076 O an5 Personal phrase This will contain the personal
phrase value and will be
populated by NPCI
077 C 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.
Will be present in IVR (using

PaySecure) ISO request. Is
returned by Issuer
Authentication Server
078 C an2 Encryption Technique *The value of this tag is based on
Indicator the Byte map, whose first three
bits denote the encryption
indicators.
079 C an 4 Transaction Identifier This Tag is only for RuPay
qSPARC Card Acquirers & Issuers
who support Service Area
functionality.
080 C n8 Additional Acquiring In case of a transaction

Information originating at Dollar Terminal,
RuPay acquirers must populate
the conversion rate used to
calculate the dollar amount.
Type - n8; Format: Fixed
This field should be in format

ABBBBBBB where A denotes
decimal position from the right
and BBBBBBB denotes
conversion factor. For example,
50123456 denotes 1.23456
081 C n4 Authorization Response Acquirer must send this field by
Code populating the response code in
the following transaction for
NPCI to generate ARPC.
Only ARPC Generation – Onus

Scenario
082 C n2 Source Of Fund 01 – Using Debit to account

linked to the Card.
02 – User payment by cash.
03- Balance Update at Card.

083 C An 1 Merchant Business Type S – Small Scale Merchants

084 C AN 4 Service ID ID allocated by NPCI for the a
particular service
099 C An 16 MAC Value The MAC value generated for the
Online request / response
message.
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.
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' scenarios and value should
be 'M' in response, after successful CVD2 verification by Issuer
Should be present for all 'Card Not Present' scenarios and value should
be 'N' in response, in case of a failed CVD2 verification by Issuer
It is strongly recommended that for every transaction issuer must

perform CVD2 verification
Tag 054 Should be present for all 'Card Present' scenarios and value should be
'M' in response, after successful CVD/iCVD verification by Issuer
Should be present for all 'Card Present' scenarios and value should be
'N' in response, in case of a failed CVD/iCVD verification by Issuer
It is strongly recommended that for every transaction issuer must

perform CVD/iCVD verification
Tag 055 Shall be Present for all 3D – Secure Ecommerce transaction. Issuer shall
populate this field in case of CAVV validation is done by the issuer. NPCI
will populate this field in case On behalf validation of CAVV is done for
issuer.
Tag 056 Should be present for all E-Commerce transaction in request
Tag 057 Shall be Present for all 3D – Secure Ecommerce transaction
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 (PaySecure)
Should be present for IVR request coming from PaySecure for
authorizations. Not to be echoed in response from the issuer switch,
however NPCI will populate this field in response and send this to the
acquirer (PaySecure).
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 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 070, Should be present for all international based transactions
Tag 073
Tag 071 Should be present for all E-Commerce transactions
Should be absent in IVR request (ISO from PaySecure)
Tag 074 This is an optional tag
Tag 075 Should be present for all E-Commerce transactions in request except
for ‘Card + OTP’ method (where registration is not performed for
transacting customer)
Should be absent in IVR request (ISO from PaySecure)
Tag 076 This is an optional tag
Tag 077 This should be present for E-Commerce Registration transaction.
Tag 078 Should be present for all Card Present transactions originating at PoS
terminals and mPoS devices in India.
Tag 079 Transaction identifier This Tag is only for RuPay qSPARC Card Acquirers &
Issuers who support Service Area functionality.
Tag 080 Acquirer can populate additional information i.e. the conversion rate
of dollar terminal used to charge the customer in dollars. The field
should be populated by acquirers only when the transaction has
originated from the dollar terminal.
Tag 081 Should contain the response code sent by acquirer for ARPC generation
in ONUS scenario.
Tag 082 Source Of Fund for Money Loaf transaction.
Tag 083 Merchant Business Type indicator which shows the Merchant Categorization
based on the Turn Over. If enabled this should have valid values. Acquirer
needs to populate this tag for SMS transactions in case the transaction are
initiated from Small scale Merchants. For OCT transaction Merchant bank has
to populate this tag in the OCT response.
Tag 084 Service ID value will be Re-populated in this Tag from DE-55 Tag 9F10 in case
of Quick EMV Q-Sparc Issuer.
Tag 099 Tag contains the MAC value generated for the particular request / response
message. This tag will contain the Message Authentication code, generated as
per the RuPay specifications. This tag is used to make sure the Authentication
of the message source.
Table 74: DE-48 Tags and descriptions
Product Code Description

ATM01 Transaction originated from ATM
AEP01 Transaction originated from microATM
POS01 Transaction originated from POS
IMP01 Transaction originated from Mobile
Table 75 Product Code
The product code Tag051 value should be ‘POS01’ for the following transactions:
1. POS transactions (including transactions originating both at PoS and mPoS terminals)
2. All e-Commerce variants (including International non-secure transactions)IVR
transactions (using PaySecure)
* Format of Tag078 (Encryption Technique Indicator)

RuPay provides Tag078 (Encryption Technique Indicator) as an option for its acquirers to
populate and indicate the support of following encryption and security techniques
1. TLE (Terminal Line Encryption)
2. UKPT (Unique Key per Terminal)
3. DUKPT (Derived Unique Key per Transaction)
Format of Tag078 is described below:

Tag Presence Format Length Description Values/ Notes Example in
TLV
078 Mandatory Fixed an 2 Encryption The value of this tag is 07800207
Technique based on the Byte
Indicator map.
Table 76: Tag078 (Encryption Technique Indicator) Description
Tag078 uses a byte map whose first three bits denote the encryption indicators as mentioned
below:
Bit Indicator
Bit 1 TLE
Bit 2 UKPT
Bit 3 DUKPT
Table 77: Bit representation for Encryption Indicator
Value ‘1’ for a bit would imply ‘Compliant’ whereas ‘0’ would imply ‘Non-compliant’
Value Meaning
1 Compliant
0 Non-compliant
Table 78: Meaning of Bit Value in Byte map
Below are the two possible scenarios depicting values of Encryption Technique Indicator that will
be forwarded by the acquirer and will be forwarded by NPCI to issuer? The following scenarios
will comply with the condition – TLE and (DUKPT or UKPT) compliant.
Case 1: TLE, UKPT indicators are present and DUKPT is absent.
Byte
B8 B7 B6 B5 B4 B3 B2 B1 Meaning
0 0 0 0 0 - - - RFU
- - - - - 0 - - DUKPT
- - - - - - 1 - UKPT
- - - - - - - 1 TLE
Table 79: Scenario - TLE and UKPT compliant
Value of Tag078:
Tag Value TLV in DE-48
078 03 07800203
Table 80: ETI value - TLE and UKPT compliant
Inference: Acquirer has indicated that it is certified and compliant for TLE and
UKPT indicators.
Case 2: TLE, DUKPT indicators are present and UKPT is absent.
Byte

B8 B7 B6 B5 B4 B3 B2 B1 Meaning
0 0 0 0 0 - - - RFU
- - - - - 1 - - DUKPT
- - - - - - 0 - UKPT
- - - - - - - 1 TLE
Table 81: Scenario - TLE and DUKPT compliant
Value of Tag078:
Tag Value TLV in DE-48
078 05 07800205
Table 82: ETI value - TLE and DUKPT compliant
Inference: Acquirer has indicated that it is certified and compliant for TLE and DUKPT
indicators
Note: NPCI will not validate the value of ETI indicator sent by the acquirer and will forward the
value in DE-48 Tag078 to issuer in ISO request message 0100/ 0200
Note: NPCI will not populate and send any default value of ETI indicator to issuer in case NPCI has
not received it from its acquirer in DE-48 in0100/ 0200 message
Note: Presence of ETI indicator is applicable for domestic transactions. Both acquirer and issuer
need to get certified for the presence of this field in 0100/ 0200 messages For international
transactions(acquired at RuPay affiliate’s territory), NPCI will not populate this field in request
0100/ 0200 to RuPay Issuers.
Note: It is entirely issuer’s responsibility to validate the ETI value in DE-48 Tag078. Issuer can use
the response code ‘93’ in case it decides to decline a transaction based on ETI validation.
8.3.33.1 Usage in Dynamic Key Exchange

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

Position Length Field Name
01-03 n3 DE-48 Length
04-35 an 32 Key
36-41 an 6 Check value
Table 83 Double Length
e.g. - 0387783FEC8903C445237078FAE0AD4B166731EF7
In above example Length of DE-48:-038 (Position 01-03)
‘7783FEC8903C445237078FAE0AD4B166’ is encrypted ZPK of length 32 hexadecimal characters

and ‘731EF7’ is check value.
8.3.33.1.2 Triple Length

Position Length Field Name
01-03 n3 DE-48 Length

04-52 an 48 Key
53-58 an 6 Check value
Table 84 Triple Length
Note: Currently only Double Length ZPKs are exchanged with member banks.

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.

be 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.

be present.
Optional-None

8.3.37 DE – 52 PIN Data

DE – 52 PIN Data
Type B16
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 if issuer decides to use OTP
instead of static PIN
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.
Should be absent for e-Commerce ‘Card + OTP’ method,
Should be absent for IVR transaction (from PaySecure).
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 Lengt Format Usage
0100 / 0200
Tag h
0130 / 0230
0110 / 0210
0120 / 0220
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 to application
cryptogram

0100 / 0200
Tag h
0130 / 0230
0110 / 0210
0120 / 0220
0420
0430
(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 described in ISO/IEC 7816-
(AID) – 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
Name DF as described in ISO/IEC
7816-4
11 9F1E Interface 8 an 8 O - O - O - Unique and permanent
Device (IFD) serial number assigned to
Serial Number the IFD 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
Authenticatio response data for online
n Data issuer authentication.
Mandatory for online
successful transactions OR if
any script/s are sent to the
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 ICC before issuing the
127 second GENERATE AC
command. Present if sent by
Issuer

0100 / 0200
Tag h
0130 / 0230
0110 / 0210
0120 / 0220
0420
0430
16 72 Issuer Script Var. b - C - - - - Contains proprietary issuer
Template 2 up data for transmission to the
to ICC after completion of the
127 second GENERATE AC
command. Present if sent by
Issuer
17 9F09 Terminal 2 b O - O - O - Version number assigned
Application for 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 1 n2 O - O - O - Indicates the environment
Type 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 of the transaction according
Code to ISO 4217
23 9A Transaction 3 n6 M - M - M - Local date that the
Date YYMM transaction was authorized
DD
24 9F41 Transaction 2-4 n 4-8 O - O - O - Counter maintained by the
Sequence terminal that is incremented
Counter by one for each transaction
25 9C Transaction 1 n2 M - M - M - Indicates the type of
Type transaction,
26 9F37 Unpredictable 4 b M - M - M - Random number generated
Number by terminal unique for each
transaction.
27 4F ICC Var B O - O - O - ADF name (AID) returned
Application ID (…16) by ICC, as read from
directory file, in template 61

0100 / 0200
Tag h
0130 / 0230
0110 / 0210
0120 / 0220
0420
0430
28 DF15 Service 2 B C - C - C - Terminal uses this data
Management element in service based
info. transaction in order to
advice the card on the
request for service i.e.
update service data, create a
new service area etc.
29 DF7C LUC ID 4 B C -- -- -- -- -- To be used by transaction

manager for cryptogram
verification.
Note: It will not be present

in request message to
issuer. It will be dropped by
transaction manager after
cryptogram validation
30 9F24 PAR 16 B C C C -- C C To be present if

personalized by Issuer
Table 85: DE-55 Tags

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
1003- Small Ticket STIP
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
7 Contactless Only
8 Magstripe & contact ICC & Contactless
Capability
Subfield 2: Cardholder Authentication Capability
Value Description
0 Unknown
1 Authentication method other than
PIN/ Biometric **
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
unattended
3 Off premises of card acceptor,
attended
unattended
5 On premises of cardholder,
unattended
6 No terminal used
attended M-POS
unattended M-POS
attended M-POS

A Off premises of card acceptor,

unattended M-POS
B On premises of cardholder,
unattended M-POS
C Dollar Terminal
D Dollar mPoS Terminal
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
8 Recurring Payment
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 1
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
G Authenticated using only 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
For Domestic transactions, If zip code

contains all zeroes/all spaces then the
transaction will get rejected. For
international transactions zipcode can
contain all zeroes / spaces.
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
** Note:
 SF-2 value ‘1’ is also present (applicable) for Non-secure PaySecure e-commerce transaction.
 Acquirer must populate conversion rate in DE-48 Tag080 in case of transactions originating at
Dollar Terminals.

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
Conditional-In case of Biometric authentication for a
transaction with successful response from UIDAI, DE 62 will
be populated and the same will be forwarded in all legs
thereafter.
Optional- None

8.3.43 DE – 63 Private Data 2

Type ANS… 999
Format LLLVAR
Description
Constraints If present this is to be echoed in response as well.
Validation None
Compliance None
Conditional- None
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 ZPK.
184 ZPK 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
Please note that currently double length key shall be applicable for static and dynamic key
exchange of ZPKs.

8.3.45 DE – 90 Original Data Element

DE -90 Original Data Element
Type N42
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.
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 AN1
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
5 Inquiry Message
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 AN42
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 - 104 OCT Data

DE – 104 OCT Data
Type ANS…999
Format LLLVAR
Description Tag Presence Length Description Description
001 C ANS30 Bill number Invoice number or bill
number
002 C ANS15 Mobile number Mobile number for top-up
or bill payment
003 C ANS30 Store ID A distinctive number
associated to a Store
004 C ANS30 Loyalty number Loyalty card number as

provided by store or
airline
005 C ANS30 Reference ID Any value as defined by

merchant or acquirer in
order to identify the
transaction
006 C ANS30 Consumer ID À subscriber ID given by
the merchant for
subscription services
007 C ANS100 Purpose Remarks for the Purchase
008 M ANS1 Remitter This will contain the

instrument type instrument type by which
the Debit was processed.
C- Card
I – IMPS
U- UPI
009 M ANS50 Remitter This will contain the ID of
instrument ID the Instrument used for
Debit (Card Number,
Account Number, VPA
handler etc. ...)
010 C ANS30 Remitter Name This field will contain
remitter name, if remitter
name is greater than 30
characters, use first 30
characters
011 C AN11 Merchant IFSC Code IFSC Code of Merchant
Account.
012 C N25 Merchant Bank Merchant Account
Account Number Number
013 M N2 Payload Format Defines the version
Indicator release as agreed between
NPCI, Visa and

MasterCard. Any
increment to the version
number would be jointly
agreed between the
participants. The first
version should be
numbered “01”.
014 M N2 Point of initiation In this two digit field, first
method character indicates the
method by which the data
is presented by the
merchant. The second
character indicates if the
data is static or dynamic.
1st character :
1 = QR
2 = BLE
3 = NFC
4-9:Reserved for future
use
2nd character :
1=static,
2=dynamic
3-9:Reserved for future
use
015 C N2 Tip or Convenience 01 : Indicates Consumer
fee indicator should be prompted to
enter tip
02 : Indicates that
merchant would
mandatorily charge a flat
convenience fee
03 : Indicates that merchant
would charge a percentage
convenience fee
016 C N12 Tip or Convenience Tip OR Convenience fee
fee – amount amount
017 C ANS5 Convenience fee The Convenience Fee
percentage Percentage is specified as
whole integers between
000 (for 0%) to 100 (100%).
E.g. “11.95”
Note: 0 or 100 is not a valid
value.
018 C ANS100 NPCI reserved field 1

For an OCT transaction this field should be mandatory. For all other
transactions this field will not be present.
Validation None

Compliance This is mandatory for all OCT transactions..

Presence Tag -008 Should be Present in all OCT message
Tag-009 Should be present in all OCT message.
Tag-013 Should be present in all OCT message.
Tag-014 Should be present to all OCT message.

8.3.52 DE - 105 Token Data

DE – 105 Token Data
Type ANS…999
Format LLLVAR
Description Tag Presence Length Description Description
001 M AN19 Token ID Token Value
corresponding to the PAN
002 M N4 Token Expiration Expiry Date for the Token.
Date The date is in yymm
format, where yy = year
(00–99) and mm = month
(01–12).
003 M ANS30 Token Reference ID Reference ID
corresponding to the
Token.
004 M N4 Wallet ID ID allocated for the
Particular Waller
005 M AN2 Token Type EC - ECOM/COF (e-

commerce/ card on file)
SE - SE (secure element)
HC - CBP (cloud-based
payment)
006 C AN1 Token Status A - Active for payment
I - Inactive for
payment(not yet active)
S - Temporarily
suspended for payments
D - Permanently
deactivated for payments
007 C ANS32 Payment Account This will have data if
Reference (PAR) provided by the issuer.
The value needs to be
Populated from Tag 9F24
008 C ANS12 Token Requestor ID Contains the assigned
Token Requestor ID
009 M AN2 TSP Validation 01 –Token / Cryptogram
Result Validation Successful
02 – Token / Cryptogram
Validation Failed
03 – Token Validation
Successful
04 – Token Validation
Failed
010 C AN2 Device Type Device from which the
transaction was initiated.
U - Unknown
M - Mobile phone
T – Tablet
W – Watch
O- Mobile Or Tablet

011 C ANS48 Device ID Contains Device ID

012 C N15 Device Number This tag contains the full
or partial phone number
when available.
013 C N2 Number of Active Number of Tokens
Tokens Currently Active for this
PAN
014 C N2 Number of Inactive Number of Token
Tokens currently Inactive for this
PAN
015 C N2 Number of Number of Token
Suspended Tokens currently Suspended for
this PAN
016 C N2 NPCI reserved field 1

For any Token based transaction this field should be mandatory. For all other
transactions this field will not be present.
Constraints None
Validation None
Compliance This is mandatory for all Token Based transactions.
Presence Tag -001 Should be Present in all Token Based request message
Tag-002 Should be Present in all Token Based request message.

8.3.53 DE – 111 to DE --119 Encrypted Personal Identity

Data(FP/IRIS)
DE -109, 110 and 111 mc attribute Data
Type ANS...999
Format LLLVAR
Description This Element is encrypted containing finger print minutiae
collected at the Micro ATM. Data will contain minutiae Single/
Dual finger for Authentication.
Data will contain IRIS image of resident for Authentication.
DE is structured as TLV (Tag, length and value) field.
The details of tags and contents are described below:
Field Edits This message is used for biometric transaction.
Constraints If present this is not to be echoed in response
Validation
Compliance
Conditional-This is present in all the transactions with

Aadhaar based biometric authentication. Message from
acquirer will have this data
Tag Length Description Valid Value

FP/IRIS Up to 999 char’s in Encrypted RBD only Encrypted RBD only
each Data element
Example:
In Case of PID in Protobuff format having data is of 3760 bytes, below defined is the
sample structure for this field.
IRIS
DE#111- IRS3760<Encrypted biometric data of total length 992>
DE#112 till DE#119- <Encrypted biometric data of total length 999>
Note: 999 is the maximum data length which can be passed.
FP
DE#111- FPD1760<Encrypted biometric data of total length 992>
DE#112 till DE#119- <Encrypted biometric data of total length 999>
Note: 999 is the maximum data length which can be passed.
Note: FP authentication packet will max fit in to 3 data elements, FIG has to populate
the data accordingly in above format.

8.3.54 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 O 50(Max) Value
Reference)
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
Reference)


054 (Customer location) O 18 Merchant city (13) +
Merchant country
(2)
Merchant Payment Reversal Request
049 (MAS) M 3 Value
Number
Reference)
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
Reference)
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
Mobile Number) digit mobile number
P2P Mobile Transfer Response


046 (Beneficiary Name) M 7 (Max 20) WXYZ
P2P Mobile Transfer Verification Request
047 (Original M 14(Max 80) Populate MTI, DE
Transaction data) 12, 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
Table 86 Mobile and UID DE-120 Details
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
Table 87 ATM transaction Pin Change request
Structure of DE – 120 for ATM transaction (Pin change in response)

001 Transaction 2 08 Pin Change
Type
Indicator
Table 88 ATM transaction Pin Change Response

Structure of DE – 120 for ATM transaction (Mini statement in request)

001 Transaction 2 07 Mini Statement
Type
Indicator
Table 89 ATM transaction Mini Statement request
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 and
statement bank should send the trailing spaces of
data 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+
Table 90 ATM transaction Mini Statement Response
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
Table 91 ATM transaction Bill Pay
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
Table 92 DE – 120 Fund Transfer from Acquirer
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
Table 93 DE – 120 Fund Transfer to Acquirer
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
Table 94 Fund Transfer Fund debit request
 0210 response will contain the following details for Fund Debit transaction:

001 (Transaction Type) M 2 TD
002 (Product Indicator) M 3 GFD
Table 95 Fund Transfer Fund debit response
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
Table 96 Fund Transfer Fund Credit request
 0210 response will contain the following details for Fund Credit transaction:

001 (Transaction Type) M 2 TC
002 (Product Indicator) M 3 GFC
Table 97 Fund Transfer Fund debit response
Cheque Book Request Transaction
0200 will contain the following details for Cheque Book Request Transaction

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

Table 99 Cheque Book Response
Statement Request Transaction
0200 will contain the following details for Statement Request Transaction

Table 100 Statement Request
0210 will contain the following details for Statement Request Transaction


Table 101 Statement Response
Mobile Number Update Transaction
0200 will contain the following details for Mobile Number Update Transaction

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

001 (Transaction Type) M 2 UR
Table 103 Mobile Number Update response

8.3.55 DE – 121, 122, Private Data 4 – 5

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

8.3.56 DE – 123 mc attribute Data

DE -123 mc attribute Data
Type ANS...999
Format LLLVAR
Description This Element is encrypted registered device public key
certificate DE is structured as TLV (Tag, length and value)
field. The details of tags and contents are described below
This message is used for biometric transaction.
Validation
Compliance


8.3.57 DE – 124 File Action Record / mc attribute Data

In Case of File Update Message below is the data element definition for this field
DE – 124 File Action Record and Data

Type ANS...999
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:
IQ – Inquiry Message
DL – Delete the Record
CN Cancelled Card
CX Skimming/Counterfeit
FR Fraudulent Use
LO Lost Card, Decline
SD Stolen Card, Decline
WM Warm Card
OH Online Hot Card
CS Card Surrendered
DD Damaged Card, Decline
OT Others

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
Note: De-hot listing functionality will be available for all the action codes
Note: NPCI will respond back with the action code in DE-124 associated with the existing (current)
status of the card in NPCI switch in case a file update is declined for an inquiry request or for a
request for adding a card
In Case of Authorization with biometric data below is the data element definition for this field

Type ans...999
Format LLLVAR
Validation
Compliance



8.3.58 DE – 125 mc attribute Data

Type ANS...999
Format LLLVAR
Validation
Compliance


8.3.59 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
Validation None
Compliance None
Conditional- This is present in all the transactions with

Aadhaar based biometric authentication. 0200 message from
The below table list the tags used for DE 126:
Tag Length Type Format Description Valid Value

001 9 Fixed A uses(authentication factors used Please refer below table
by the request)
008 1 Fixed A type(Type of PID block format) X?P
009 20 Variable An udc(unique host device code) unique code for the host device
assigned within the AUA domain
010 48 Variable Varchar dpId(Unique code assigned to Returned by RD Service when
registered device provider) using biometric authentication
011 48 Variable Varchar rdsId(Unique ID of the certified Returned by RD Service when
registered device service) using biometric authentication
012 15 Variable Varchar rdsVer(Registered devices Returned by RD Service when
service version) using biometric authentication
013 40 Variable 128 Bit dc(Unique Registered Device Returned by RD Service when
UUID in Code) using biometric authentication
HEX
Format
014 48 Variable Varchar mi(Registered device model ID) Returned by RD Service when
using biometric authentication
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 y' or 'n' y' or 'n'
or IIR

8.3.60 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
This message is used for biometric transaction

Validation None
Compliance None
Conditional- Present in all the Aadhaar based biometric

transactions .message from acquirer will have this data
element.
Table 104 DE-127 Field Details
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
was encrypted) UIDAI 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/ then encrypted
FrontPageUpdates/aadhaar_
authentication_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.

If AUA and SA are same up to 10

agency, use value of “ac” for characters
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.)
007 001 Fixed A rc( resident consent) Only allowed

value is “Y”
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.
Tag 001 represents skey which is of length 256 char.
Tag 002 represents ci which is of length 8 char.
Tag 003 represents Hmac which is of length 48 char
Tag 004 represents ac which is of length 10 char
Tag 005 represents sa which is of length 10 char
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).
 For all biometric based authentication transactions DE-63, DE-126, DE-127 is mandatory
from Acquirer.
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) for 3D secure and E-
Commerce indicator in DE-48 Tag056 for PaySecure
 DE 14 should be mandatory for an e-commerce transaction.
 Transaction id should be mandatory (DE 48 tag 061).

Compliance Member Compliance Acquirer
 CVD2should be mandatory (DE 48 tag 052).

 Cardholder Authentication Method (DE-61 SF-8) must indicate authentication method
used for carrying out the transaction like OTP, PIN etc.

 In case DE-61 SF-8 indicates OTP, then OTP 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.

Compliance Member
Compliance Acquirer
Loyalty Redemption
 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, and 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.OCT Message
 For OCT, originator should send DE-104.

 It is only used for domestic transactions and the transaction currency is INR only.
 Track details will not be present for this transaction.
 Transaction initiation device will be Mobile.
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.

Compliance Member Compliance Issuer
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.

Compliance Member
Compliance Issuer
 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 point’s 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.
OCT Message
 Merchant Acquirer Bank should send DE-104 in the response

 All Tags in DE-104 request should be echoed back in the response.
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 is 30 seconds.
 NPCI Timeout for Issuer Bank is 20 seconds.
 NPCI timeout for Beneficiary bank is 8 seconds.

Annexure 2- Original Credit Transaction for Merchant
Payment Member
Compliance Issuer
Annexure 2- Original Credit Transaction

for Merchant Payment
Successful Transaction Flow for OCT
Step Description
1 Consumer initiates the merchant payment transaction using QR code from the
Mobile device. Mobile device sends the request to the originator system.
2 Originator MBS/switch system sends the debit request to Remitter Bank (either
directly with remitter system OR via NPCI Paysecure as Ecom purchase [with card +
OTP] for auth processing via RuPay Switch).
3 Remitter Bank debits the consumer account and passes the confirmation to the
originator system.
4 On successful debit processing, the originating processing system initiates the SMS
OCT (0200) message to the RuPay Switch.
5 Based on the BIN that Merchant PAN belongs to, RuPay routes the SMS OCT (0200)
to the merchant acquirer’s switch.
5 a/b The Acquirer’s switch receives OCT request and processes it. The acquirer system
approves the transaction successfully and notifies the merchant.
6 The Acquirer’s switch responds with a 0210 approval and sends it to RuPay.
7 RuPay routes the response to the originator system using 0210 message.
8 Originating system notifies the Consumer over the mobile device indicating
successful transaction.

Payment Member Compliance Issuer
Exception Handling
Transaction Flow for Decline
Step Description
directly with remitter system OR via NPCI Paysecure as Ecom purchase [with card
+ OTP] for auth processing via RuPay Switch).
originator system.
5 a/b The Acquirer’s switch receives OCT messages and processes it. The acquirer
system declines the transaction. Acquirer may notify the merchant.
6 The Acquirer’s switch responds with a 0210 decline and sends it to RuPay.
7 RuPay routes the response to the originator system using 0210 message.
Originator system should reverse the customer for any decline response code
except 71 (deemed acceptance).
8 Originator sends the reversal request for the debit to the Remitter Bank.
9 Remitter Bank will process the reversal transaction, will credit the customer
account and send the response to the originator.
10 Originating system notifies the Consumer over the mobile device indicating the
transaction is declined.

Payment Member
Compliance Issuer
RuPay Time Out / No Response with Merchant Acquirer
Step Description
originator system.
5 a/b The Acquirer’s switch receives OCT messages and processes it. The acquirer system
6 The Acquirer’s switch responds with a 0210 to RuPay. But the transactions times
out at RuPay Switch because of Network Disconnect / Latency.
7 RuPay routes the response to the originator system using 0210 message with
deemed acceptance response code (71). Originator system should not reverse to the
remitter. Originator has to reconcile these transactions basis the raw data file /
settlement reports from RuPay.
8 Originating system notifies the Consumer over the mobile device indicating deemed
acceptance.

Payment Member Compliance Issuer
Originator Time Out / No Response with RuPay Switch
Step Description
originator system.
5 a/b The Acquirer’s switch receives OCT messages and processes it. The acquirer system
6 The Acquirer’s switch responds with a 0210 approval and sends it to RuPay.
7 RuPay routes the response to the originator system using 0210 message, but the
transactions times out at Originator system because of Network Disconnect /
Latency. Originator system should treat the transaction as deemed acceptance.
Originator system should not pass the reversal to the consumer. Originator has to
reconcile these transactions basis the raw data file / settlement reports from RuPay.
8 Originating system notifies the Consumer over the mobile device indicating deemed
acceptance.

Annexure 3 -State Code Member
Compliance Issuer
Annexure 3 -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
Telangana TG
Tripura TR
Uttar Pradesh UP
Uttarakhand (Uttranchal) UK
West Bengal WB
Table 105: State Codes

Annexure 4 -Glossary Member Compliance Issuer
Annexure 4 -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
DUKPT Derived Unique Key per Transaction
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
JCB Japan Credit Bureau
KIO Kiosk
LMM Liquidity Management Module
LRC Longitudinal Redundancy checking
MCC Merchant Category Code
MOTO Mail Order/Telephone Order
MTI Message Type Identifier

Annexure 4 -Glossary Member
Compliance Issuer
Abbreviation Description
NBIN National Bank Identification number
NPCI National Payments Corporation Of India
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
RFU Reserved for future use
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
TLE Terminal Line Encryption
TLV Tag-length-value
TVR Terminal Verification Results
TXN Transaction
UID Unique Identification
UIDAI Unique Identification Authority of India
UKPT Unique Key Per Terminal
UTC Coordinated Universal Time
ZPK Zone Pin Key
ZMK Zone Master Key
Table 106: Glossary

Annexure 5 -Definition Member Compliance Issuer
Annexure 5 -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.
Fall-back For a chip based card, when the chip is not working then the card is
swiped using magnetic stripe.

Annexure 5 -Definition Member
Compliance Issuer
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.

Annexure 5 -Definition Member Compliance Issuer
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
Originator The Bank Switch which initiates the Transaction for SMS OCT
OCT Original Credit Transaction
MBS Mobile Banking System
Table 107: Definitions


RuPay-Online Switching Interface Specification - V1.8.3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RuPay-Online Switching Interface Specification - V1.8.3

Uploaded by

Copyright:

Available Formats

National Payments Corporation of India

Release Year 2018

Chapter 2 Introduction _______________________________________________________________________ 22

RuPay - Online Switching Interface Specification

3.1.2.3 Position 3 – Message Function ______________________________________________________________ 28

3.2 RuPay Implementation of ISO 8583 ____________________________________________________ 30

4.2 Financial Message_________________________________________________________________________ 31

4.3 File Update Message ______________________________________________________________________ 32

4.4 Reversal Message _________________________________________________________________________ 32

4.5 Network Management Message_________________________________________________________ 32

4.6 Advice Message ____________________________________________________________________________ 34

Chapter 5 NPCI System Functionalities ____________________________________________________ 35

5.6 PIN Encryption / Decryption Process __________________________________________________ 38

RuPay - Online Switching Interface Specification

5.8 Liquidity Management Module _________________________________________________________ 38

6.2 Acquirer Responsibilities________________________________________________________________ 53

Chapter 7 Message Format___________________________________________________________________ 62

7.2 Message Format for Issuer ______________________________________________________________ 64

RuPay - Online Switching Interface Specification

7.2.1.9 Balance Inquiry ______________________________________________________________________________ 75

7.3 Message Format for Acquirer __________________________________________________________ 100

Chapter 8 Data Element Description _____________________________________________________ 131

RuPay - Online Switching Interface Specification

8.3.3 DE – 4 Amount, Transaction _____________________________________________________________________ 135

RuPay - Online Switching Interface Specification

8.3.46 DE – 91 File Update Code ______________________________________________________________________ 203

Chapter 9 Compliance _______________________________________________________________________ 229

9.2 Member Compliance Issuer ____________________________________________________________ 232

Annexure 1-Card to Card Fund Transfer ___________________________________________________ 234

Annexure 2- Original Credit Transaction for Merchant Payment ____________________ 235

Annexure 3 -State Code ________________________________________________________________________ 239

RuPay - Online Switching Interface Specification

RuPay - Online Switching Interface Specification

RuPay - Online Switching Interface Specification

Table 44 RuPay E-Commerce Purchase Message – Acquirer _____________________________________ 105

RuPay - Online Switching Interface Specification

Table 91 ATM transaction Bill Pay __________________________________________________________________ 218

RuPay - Online Switching Interface Specification

Confidentiality and Copyright Notice

RuPay - Online Switching Interface Specification

Security classification: Confidential

Distribution list: Member banks

Version Issue Date Effective Date

Document Revision History

Sr. Description Version

RuPay - Online Switching Interface Specification

Sr. Description Version

RuPay - Online Switching Interface Specification

Sr. Description Version

The following statement has been added: 1.6

In section Cutover Message, 1st point has been 1.6

In the Echo Message (point 4), Member banks and 1.6

DE 120 Tag 045 (credit transaction to beneficiary) and 1.6

RuPay - Online Switching Interface Specification

Sr. Description Version

RuPay - Online Switching Interface Specification

Sr. Description Version

RuPay - Online Switching Interface Specification

Sr. Description Version

RuPay - Online Switching Interface Specification

Sr. Description Version

RuPay - Online Switching Interface Specification

Sr. Description Version