SOP BC Interoperability - Interface Specifications

INTERFACE SPECIFICATION
FOR BC INTEROPERABILITY
[INTERFACE SPECIFICATION for BC INTEROPERABILITY]
AADHAAR ENABLED PAYMENT SYSTEM

1.0 Introduction
1.1 Executive Summary
National Payments Corporation of India (NPCI) is formed as an umbrella institution for all the retail
payments systems in the country. The core objective is to consolidate and integrate the multiple systems
with varying service levels into nation-wide uniform and standard business process for all retail payment
systems. The other objective was to facilitate an affordable payment mechanism to benefit the common
man across the country and help financial inclusion. Vision and formation of NPCI is backed by the
regulator and Indian Banks Association (IBA). NPCI has defined business lines to process in country
interbank transactions for ATM, POS, 24*7 Remittance, ACH and CTS.
Government of India has initiated Unique Identification Project for citizens of India. It is envisaged to use
the UID schema and infrastructure for the financial inclusion in India. To enable the customers to use
AADHAAR for the financial transaction across the payment networks in the country, NPCI proposes to
facilitate routing of transactions to the central id repository of UIDAI for user authentication through a
single interface.
This interface document is targeted to achieve inter-operability between banks for AADHAAR enabled
financial inclusion transactions.
NPCI shall allow banks to connect using this interface. It is also possible that banks may position their
respective financial inclusion service provider to connect on their behalf to NPCI central infrastructure
with the complete onus with the respective member bank.
1.2 Scope of this document

This document covers detailed description of the data elements in the ISO 8583 standard payment
message specifications specific to Aadhaar Enabled Payment System (AEPS)
1.3 Audience
This document is a property of NPCI and should be not be circulated to external party without prior
approvals of NPCI management team.
National Payments Corporation of India
[Type of Document: Confidential]
Page 2 of 90
2.0 AADHAAR Implementation for FI Architecture

2.1 Architecture Diagram and Brief
NPCI switch will be enhanced to support Interbank Transactions. For Onus Transactions, only the
authentication support will be provided based on the request from the issuer bank.
Following is the Transaction Set,
1. Cash Withdrawal
2. Balance Enquiry
3. Cash Deposit
4. Funds Transfer
The following diagrams present a snapshot of these transactions:
Page 3 of 90
Page 4 of 90
Details Onus Flow (only authentication)
In case Bank desires to leverage NPCI AEPS interface for UIDAI authentication, the transaction flow given
above where the transaction for biometric verification will be sent for requisite fields and verification
result from UIDAI will be forwarded to the bank.
MicroATM Application Requirement:

1. MicroATM application on PoS must ensure that a 12 digit AADHAAR number is entered as a block of
4 digits in one block. Hence there would be three blocks of 4 digit number each. This is to
improve the business correspondent readability in case of manual entry.
2. The last digit of Aadhaar number is a check digit. Therefore, Verhoeff algorithm must be applied
for checking that the AADHAAR number entered at any textbox is valid or not.
Page 5 of 90
Details - Off us flow for Funds Transfer:
The transaction flow is depicted above for funds transfer from account of customer of Remitter Bank to
Beneficiary Bank where the transaction is initiated on Remitter banks terminal. In fund transfer
transaction, remitter bank is the same as Issuer & Acquirer bank.
Online Debit and Online credit is envisaged in this transaction and beneficiary bank is expected to respond
with beneficiarys Aadhaar number and name in the response message.
Interchange fees as and when decided will be highlighted by NPCI along with Bio Metric verification from
UID system. It is assumed for fund transfer that only pre authorized transaction (credit leg) will come to
NPCI.

4 digits in one block. Hence there would be three blocks of 4 digit number each. This is to
3. The MicroATM application MUST necessitate that the Receivers Aadhaar number is entered twice
by the sender on the fund transfer screen. There can be 2 textboxes for the same and a
comparison of the digits entered should be made before proceeding to the next text box or
screen. This will ensure that the receivers Aadhaar number is entered correct as is the practice
while making online payments.
A Fund transfer transaction needs to be initiated on the home bank BC terminal only and thus the
IIN/Bank name selected for remitter bank needs to be prefixed to avoid manual entry selecting mistake.
Page 6 of 90
Flow diagram of AEPS fund transfer transaction:
It is necessary that for fund transfer transaction remitter will use its own bank MicroATMs / POS /
Infrastructure (i.e. Acquirer bank and Issuer bank is same in this case as is referred as Remitter Bank)
Fund transfer explained:
1. Fund transfer transaction consists of 2 legs i.e. debit leg and credit leg. It is important to note
that debit leg has to be processed locally and credit message to be sent to NPCI.
2. In order to facilitate debit leg, NPCI provides biometric authentication service.
3. Once a fund transfer transaction is initiated from a terminal, acquirer switch has to split the same
in two parts i.e. debit leg and credit leg. After processing the debit leg, credit leg is sent to NPCI.
For processing debit leg, NPCI provides authentication service where in only authentication
transaction has to be sent to NPCI and after the response of the same and debiting the sender
account; credit leg should be sent to NPCI. (Refer to message dump for authentication transaction
and fund transfer credit leg).
4. All fund transfer transactions will pre-authorized by the issuer i.e. after debiting the sender
account credit transaction will be sent to NPCI for processing.
If any member bank is taking authentication service from NPCI, then the fund transfer transactions will
be two-step process as explained below:
1. As shown in the above diagram (dotted line) authentication transaction will be initiated by the
acquirer for authentication and subsequent debit to the sender account. Please note that
authentication transaction is a non-financial transaction.
2. Once the debit to sender account is successful a remittance transaction is sent to NPCI.
3. The context of both authentication and fund transfer transaction will be maintained by the acquirer.
Page 7 of 90
NOTE:
1. In case of authentication request, DE2 should carry the remitters AADHAAR number (Sender AADHAAR
no.).
2. For credit leg data element DE2 will contain the beneficiary AADHAAR no., DE120 will contain the
sender AADHAAR No. and DE63 contains the biometric data of sender. It is the responsibility of issuer
to debit the senders account and send a fund transfer message to NPCI. The description of DE120 is
detailed in Data Element Definition section.
3. In case, acquirer receives any other Response Code than 00 or 91; the debit should be
reversed internally. In all other cases, disputes will be handled through Dispute Management
System (DMS) provided by NPCI.
4. As explained earlier fund transfer option is available to customer only at their home terminal. It is
only for those participants who are both acquirer and issuer.
Details - Off us flow Other transactions (Cash Withdrawal, Cash Deposit, Balance
Enquiry)
The transaction flow depicted above is for Balance Enquiry, Cash Withdrawal and Cash Deposit
transactions acquired on Acquirer bank terminal for Issuer bank customers. Interchange fees will be
highlighted by NPCI along with Bio Metric verification from UIDAI system after only the decision being
mutually taken between the banks and concerned regulatory bodies.
Page 8 of 90

4 digits in one block . Hence there would be three blocks of 4 digit number each. This is to
2.2 Interface Specification

This document provides clear understanding of online interfaces, protocols and messages used, to enable
implementation of the interface connection, and to serve as a basic document for future enhancements.
Unless indicated otherwise, this document addresses ISO-8583:1987 standard for financial transaction
messages.
2.2.1 System Definitions

Following points should be noted while developing the interface,
1. Bank Systems and NPCI-UID systems will be connecting to each other using socket connections.
2. Bank will act as client and NFS will act as server.
3. Banks will be responsible to generate the Logon (0800 message type) message after every
successful TCP socket connection. Banks should also generate Logon messages at the interval
of every 5 minutes only
4. NFS will generate cut over message (0800 message type) at 23:00 indicating business date
change over.
5. Both Banks and NFS can generate Logon (800 message type) messages and they should be
responded with 810 messages by the recipient.
6. Banks and NFS will also generate Echo message (0800 message type) for keep alive during no
transaction time. Ideal duration for the same is 3 minutes interval only
7. Message Header 2 bytes binary (value containing length of the message including header
length i.e. 2 byte)
8.
Bank needs to send auto logon (network) message when there is a disruption or disconnection
in network before sending the financial transaction message.
2.2.2 Data element processing rules

Originator:
The originator of the request message must be able to:
Correctly populate DE-2 comprising of IIN (6 digits ISOIIN), 0 as identifier and 12 digit AADHAAR
number
Correctly populate DE-18 and DE-22 based on the data supplied by Acquiring touch point
(MicroATM)
Correctly populate DE-63 with UID Bio metric data.
Populate DE-120 with Senders name for Fund transfer transactions only
Page 9 of 90
Populate DE-127 with Skey, ci, Hmac, ac, sa and lk.
NPCI
NPCI must be able to receive and process message containing DE-2, DE-63, DE120 and DE 127
Recipient
The Recipient must be able to receive and process messages containing DE-2, DE-22, DE-62 and
DE120.
It is up to the recipient how to interpret and use the values transferred in DE-22 & DE-120.
It must send current account balance of customer in DE 54 for all transactions. Data Received
in DE-62 is the Unique Authentication Code generated by UIDAI for each Authentication
Request. This should be printed on receipt in all the cases.
In fund transfer transactions, Recipient must populate DE-103 with To account number and
DE-120 with Beneficiarys name in the response message.
2.2.3 Message format

Message formats specified below contain UID related information. The changes in the message
structure and/or data element content are indicated by bold characters. These formats supersede
the Host-to-Host message specification provided by NPCI.
All message format definition tables use the symbols defined in the following table:
Message Types and Corresponding Data Elements
Symbol
2
M
.
M+
2C
Meaning
. C+
C*
2
O
. O+
Conditional, echoed from request.
1R
Reserved for future use.
A-
Not used.
Mandatory.
Mandatory, echoed from request.
Conditional.
Conditional, value may change.
Optional.
Optional, echoed from request.
2.2.3.1 Administrative Messages

Network Management Messages
MTID
Data Element
0800
0810
1
7
Secondary bitmap
Transmission date/time
M
M
M+
M+
11
STAN
M+
15
Date, settlement
C+
32
Acquirer institution ID
39
Response code
Page 10 of 90
48
64
70
128
Key Data (Optional Dynamic

Key Exchange)
MAC
Code(Optional
MACing)
NMIC
C*
M+
MACCode2(Optional
MACing)
* DE 48 as per NPCI standards should be Conditional. Since, NPCI does not use dynamic key exchange
so bank should off the bit corresponding to DE 48 in the bitmap.
2.2.3.2 Financial Messages

Financial Messages
MTID
Data Element
200
210
Secondary bitmap
M+
Primary Account Number
M+
Processing code
M+
Amount, transaction
C+
Amount, settlement
C+
Date/time, transmission
M+
Fee, card holder billing
Conversion rate, settlement
C+
11
STAN
M+
12
Time, local transaction
M+
13
Date, local transaction
M+
14
Date, expiration
15
Date, settlement
C+
18
Merchant type
M+
22
POS entry mode
M+
25
POS condition code
M+
26
POS PIN capture code
32
35
Track2data
M
C
M+
-
37
Retrieval Reference Number
M+
38
Authorization number
39
Response code
41
Card acceptor terminal ID
M+
42
Card acceptor ID
M+
43
Card acceptor name/location
M+
45
Track 1
Page 11 of 90
49
Currency code, transaction
C+
50
Currency code, settlement
C+
52
PIN Block
54
62
Additional amounts
UIDAI Authentication Code
C
M
63
UID Authentication data
64
MAC code
90
102
103
Original data element

Account 1 identification
C
C
C
C
120
Additional Data
121-123
Private use
C*
127
Additional Data(skey, ci, Hmac, ac, sa ,lk)
128
MACCode2
2.2.3.3 Reversal Messages

Reversal Messages
MTID
1
Data Element
Secondary bitmap
0420
M
0421*
M
0430
M+
M+
Processing code
M+
Amount, transaction
M+
Amount, settlement
C+
C+
11
STAN
M+
12
M+
13
M+
14
Date, expiration
15
Date, settlement
C+
22
POS entry mode
25
POS condition code
26
32
M+
35
Track2data
37
Retrieval reference number
M+
38
C+
39
Response code
41
Page 12 of 90
Reversal Messages
MTID
42
Data Element
Card acceptor ID
0420
M
0421*
M
0430
-
43
49
M+
50
C+
54
Additional amounts
64
MAC code
90
102
103
120
Additional Data
C+
121-123
Private use
C*
128
MACCode2
*Reversal 421 messages will be send 3 times after logon message is received from bank if NPCI
fails to get response of 420 message.
2.2.4 Data Element Definitions

DE 1Secondary Bit Map
Type: b..64 - transferred as 16 bytes (EBCDIC or ASCII characters).
Description Bitmap consists of 64 bits numbered from the left starting with 1. The value of each
bit signifies presence (1) or absence (0) in the message of the data element (DE-65 to DE-128)
associated with that particular bit.
Field Edits None.
Constraints C: Element is present only if message contains any of data elements from range DE-65
to DE-128.
DE-2 Primary Account Number, PAN
Format: LLVAR
Type: n...19
Usage: It is mandatory for all 02xx, 04xx messages.
Description: The PAN number is the combination of IIN (6 digits ISO IIN) and the 12 digit AADHAAR
number. It is mandatory for all 02xx and 04xxmessages. Normal length of this field is 19 digits.
Field Edits: If present, it should be echoed in response and all subsequent messages. For all other
transactions (including authentication transaction) except FT transaction, this field should have
initiators AADHAAR number. But for FT transaction, this field should have beneficiarys AADHAAR
number.
Constraints: C: Element is present if DE-35 (Track2) is not present.
Structure:
Page 13 of 90
10
11
12
13
14
15
16
17
18
19
B IIN (Issuer Identification Number)

I Indicator for UID valid value 0 for AEPS.
U Unique Identification Number of customer issued by UIDAI
Note All Acquirers and Issuers will have to incorporate reserved digits for future use so that
whenever NPCI sends addendums or circular without any changes in the systems it can be
incorporated.
DE-3 Processing Code
Format: Fixed
Type: n6
Usage: It is mandatory for all 02xx, 04xx messages.
Description: A series of digits that describes the type of transaction and the accounts affected by
the transaction. It consists of three, two-digit sub fields:
Digit 1 and 2: Transaction Code:
00
01
10
20
21
22
31
45
90
Purchase of goods/services
Cash withdrawal
Biometric Verification (UID Biometric data verification/Authentication) for ONUS
Credit, refund
Deposit
Credit adjustment
Balance inquiry
Transfer
Extended transaction type**
00
10
20
30
Unspecified/unknown
Savings
Checking
Credit card
00
10
20
30
Unspecified/unknown
Savings
Checking
Credit card
Digit 3 and 4: From Account Type*
Digit 5 and 6: To Account Number*
Summary of processing code used for AADHAAR based transactions:

Cash withdrawal 010000
Balance inquiry 310000
Deposit 210000
Finger print authentication 100000
Fund Transfer 900000
It is mandatory for all 02xx, 04xx messages.
Page 14 of 90
NOTE:*Other values may be used for optional features.

Field Edits: If present, it should be echoed in response and all subsequent messages.
Constraints: None
DE 4Amount, Transaction
Format: Fixed
Type: n12
Description: It is the amount of funds requested by the customer in the local currency of the
acquirer.
Field Edits: It should be echoed in response and all subsequent messages. For a balance enquiry
transaction, 0200 message should carry all zeros in DE 4. For all request with processing code
100000 bit corresponding to DE 4 must be off.
Constraints: None
DE 7Transmission Date and Time
Format: Fixed
Type: n10: MMDDhhmmss
Description: It is the date and time when a transaction request was transmitted by a processing
entity.
Field Edits: It should be echoed in response and all subsequent messages.
Constraints: None
DE 11System Trace Audit Number (STAN)
Format: Fixed
Type: n6
Description: It is the unique identifier assigned to each transaction by the acquirer bank switch. It
must be different for every transaction even for multiple set of transactions originated at the same
time.
Field Edits: STAN is set by a message sender and echoed by the message receiver.
NOTE: It should not be date or time or similar to DE 7
DE 12Local Transaction Time
Format: Fixed
Type: n-6; hhmmss
Description: Time, Local Transaction (DE 12) is the local time the transaction takes place at the
point of service. It is the same to be printed on receipt.
Constraints: None
DE 13Local Transaction Date
Format: Fixed
Page 15 of 90
Type: n-4; MMDD

Description: Date, Local Transaction (DE 13) is the local month and day on which the
Transaction takes place at the point of service. It is the same to be printed on receipt.
Constraints: None
DE 15Settlement Date
Format: Fixed
Type: n-4; MMDD
Description: Settlement Date (DE 15) is the date (month and day) that funds will be
Transferred between an acquirer and an issuer.
Constraints: C: Field is present if a) Field DE-50 is present or b)MTID is 0800 and DE-70=201
(cutover message).
DE-18 Merchant Category Code (MCC)
Format: Fixed
Type: n4
Description: MCC is four-digit code. The data element is mandatory for 02xx request messages. It
is never present in response messages.
The proposed values are:
6012 Micro ATM AADHAAR transactions (If member banks want to support AADHAAR transactions
through their biometric ATMs then it will be 6011).
6010 for regular POS device.
Constraints: None
DE-22 Point of Service Entry Mode
Format: Fixed
Type: n3
Description: The code describing the way PAN and PIN are entered at a touch point.
Data element consists of two sub-fields:
01
02
05
90
PAN Entry Mode

Manual
Magnetic stripe read.
ICC.
Full and unaltered magnetic stripe read (enables CVV validation).
0
1
2
Unspecified.
PIN entry capability.
No PIN entry capability.
PIN Entry Mode
Page 16 of 90
6
9
PIN pad inoperative.

Reserved for private use
The data element is mandatory for 02xx, and 04xx request messages. It is never present in
response messages.
Constraints: None
DE-25 Point of Service Condition Code
Format: Fixed
Type: n2
Description: Two-digit code indicating conditions at touch point:
00
01
02
03
05
07
08
Normal
Customer not present.
Unattended terminal (CAT, ADM)
Merchant suspicious.
Customer present, card not present.
Telephone request.
MO/TO request.
Field Edits: it should be echoed in response and all subsequent messages.

Constraints: None
DE-32 Acquiring Institution Identification Code
Format: LLVAR
Type: n11
Description: Identifies the acquiring institution for the transaction, or its agent. The value will be
defined by the host. The data element is mandatory for 02xx and 04xx request messages. It is
optional for 08xx messages.
Constraints: O: Member can choose whether to use DE-32in 08xx messages or not.
Note - NPCI shall assign appropriate codes to the participating banks to be used in this field.
DE-37 Retrieval Reference Number
Format: Fixed
Type: an12
Description: The reference, assigned by the acquirer, to identify a transaction uniquely. It remains
unchanged for all messages throughout the life of a transaction and is used for matching original
message with reversal and/or store/forward messages. The standard format of RRN is as follows:
YDDDHHSSSSSS
Y Year (last digit of current year)
DDD Julian date of transaction
HH Hour of transaction
SSSSSS STAN of transaction (Same as in DE -11)
Page 17 of 90
The data element is mandatory for 02xx, and 04xx request messages. The RRN can be used for the
entire dispute management of the transaction lifecycle.
In verification request value of DE-37 should be same as original remittance transaction RRN
Edit Field: It must be echo back in response message
Constraint: None
DE-39 Response Code
Format: Fixed
Type: an2
Description: This code indicates the disposition of a message as detailed tables below.
Each code is associated with specification code that is to be taken:
A
D
Approve transaction
Decline transaction
Field Edits: In reversal and store/forward requests, value identifies there as on for reversal or
store/forward message.
Constraints:
The following is the addendum covering different scenarios for UID specific situations and
appropriate Response codes supported for declined UID transactions in addition to the existing
response codes referred in the NPCI Host-to-Host specification document. Message to be printed
on Receipt is also specified.
NPCI
error
Code
UIDAI
Error
Code
Description
0210 Response Code

Action
Message to be
displayed at
Acquirer
MicroATM
Approved
Successful
Transaction
Message to
be displayed
on MicroATM
Receipt to be
printed by
MicroATM
Yes
Yes
00
Successful
Transaction
91
NPCI doesnt get any

response from Issuer
after sending the
request
Decline
Transaction
declined. Please
try again (91)
Yes
Yes
08
NPCI is not able to

send the request at
all to issuer
Decline
Transaction
declined. Please
try again(08)
Yes
Yes
92
Invalid IIN entered at

Terminal (IIN not
present in routing
table)
Decline
Invalid IIN(92)
Yes
No
52
Decline
Invalid
Account(52)
Yes
Yes
51
Correct Aadhaar No.

and correct IIN
entered at terminal
(IIN present in routing
table). Account
number is not present
in CBS. Transaction
declined by NPCI.
Insufficient Fund
available in
Decline
Insufficient
Funds(51)
Yes
Yes
Page 18 of 90
Residents account.
Transaction declined
by Issuer.
Account blocked by
Issuer/Regulator for
AML or any other
appropriate reasons
Aggregate of all
credits in a financial
year exceed Rs 1 Lakh
Aggregate of all
withdrawals and
transfers in a month
exceeds Rs. 10,000
57
Decline
Account blocked
(57)
Yes
Yes
AY
Decline
Total annual
credits exceed
limit(AY)
Monthly limit
exceeded for
transactions(AM)
Yes
Yes
AM
Yes
Yes
AB
Account Balance
exceeds rupees fifty
thousand
Decline
Account Balance
exceeds limit(AB)
Yes
Yes
M4
Remittance from/to
Foreign/NRE Accounts
Decline
Yes
Yes
Transaction amount
exceeded limit,
transaction is
declined by Issuer.
Decline
Foreign
Remittance not
allowed(M4)
Transaction
amount
exceeded
limit(UW)
UW
Yes
Yes
M6
Net Debit Cap limit is

exhausted for
member bank.
Transaction is
declined by NPCI.
Decline
Limit exceeded
for member
bank(M6)
No
No
U1
100
Identity attribute of
demographic details
does not match
Decline
No
No
U2
200
Address attribute of
demographic details
does not match
Decline
Identity attribute
of demographic
details does not
match(U1)
Address attribute
of demographic
details does not
match(U2)
No
No
U3
300
Biometric data did

not match
Decline
Biometric data
did not
match(U3)
Yes
No
U4
500
Encryption of session
key is invalid
Decline
Transaction
declined. Please
try again(U4)
Yes
No
U5
510
Invalid XML format
Decline
Transaction
declined. Please
try again(U5)
Yes
No
U6
520
Invalid device
Decline
Wrong Terminal
ID (U6)
Yes
Yes
Decline
Page 19 of 90
U7
530
Invalid authenticator
code
Decline
Invalid
authenticator
code(U7)
Yes
No
U8
540
Invalid version
Decline
Invalid version
(U8)
Yes
No
U9
550
Invalid Uses
element attribute
Decline
Invalid Uses
element
attribute(U9)
No
No
UA
700
Invalid demographic
data
Decline
Invalid
demographic
data(UA)
No
No
UB
710
Missing Pi data as
specified in Uses
Decline
Missing Pi data
as specified in
Uses (UB)
No
No
UC
720
Missing Pa data as
specified in Uses
Decline
Missing Pa data
as specified in
Uses (UC)
No
No
UD
730
Missing PIN data as

specified in Uses
Decline
Missing PIN data

as specified in
Uses (UD)
No
No
UE
999
Unknown error
Decline
Transaction
declined. Please
try again(UE)
Yes
No
UF
740
Missing OTP data as

specified in Uses
Decline
Missing OTP data

as specified in
Uses (UF)
No
No
UG
800
Invalid biometric data
Decline
Invalid biometric
data(UG)
Yes
No
UH
810
Missing biometric
data as specified in
Uses
Decline
Missing biometric
data as specified
in Uses (UH)
No
No
UI
Decline
Transaction
Declined. Please
try again(UI)
Yes
No
UJ
721
Time Out for the

request sent to UIDAI
from NPCI beyond 10
seconds (like
response not received
for Authentication
Request
Missing "Pfa" data as
specified in "Uses"
element
Decline
Missing "Pfa" data

as specified in
"Uses"
element(UJ)
No
No
Page 20 of 90
UK
820
Missing or empty
value for "bt"
attribute in "Uses"
element
Decline
Missing or empty
value for "bt"
attribute in
"Uses"
element(UK)
No
No
UL
821
Invalid value in the

"bt" attribute of
"Uses" element
Decline
Invalid value in
the "bt" attribute
of "Uses"
element(UL)
No
No
UM
901
No auth factors found

in auth request. This
corresponds to
scenario wherein all
the 3 factors - Pin,
Demo and Bios - are
not present in Auth
request
Decline
No auth factors
found in auth
request(UM)
No
No
UN
902
Invalid "dob" value in

"Pi" element. Invalid
dates are one which
are not of the format
YYYY or YYYY-MM-DD,
or have a year value
such that residents
age is less than 0 or
more than 150 years,
or contains value
which cannot be
parsed e.g.
alphabetic strings,
invalid dates such as
31-Feb, etc
Decline
Invalid "dob"
value in "Pi"
element. (UN)
No
No
UO
910
Invalid "mv" value in

"Pi" element. This
error is returned if
mv value is not a
numeric value or is
not in the allowed
range.
Decline
Invalid "mv"
value in "Pi"
element. (UO)
No
No
UP
911
Invalid "mv" value in

"Pfa" element .This
error is returned if
mv value is not a
numeric value or is
not in the allowed
range.
Decline
Invalid "mv"
value in "Pfa"
element(UP)
No
No
UQ
912
Invalid "ms" value in

"Pa" (If match
strategy other than E
Decline
Invalid "ms" value
No
No
Page 21 of 90
is used)
in "Pa"(UQ)
UR
913
Both Pa and Pfa are

present (Pa and Pfa
are mutually
exclusive)
Decline
Both Pa and Pfa

are present(UR)
No
No
US
930
Technical error
category 1 (Related
to ABIS interactions)
Decline
Transaction
declined. Please
try again(US)
Yes
No
UT
931
Technical error
category 2 (Internal
to auth server such as
Database server
down, etc.)
Decline
Transaction
declined. Please
try again(UT)
Yes
No
UU
932
Technical error
category 3 (Error if
audit XML could not
be published to audit
queue, or if audit
XML could not be
constructed)
Decline
Transaction
declined. Please
try again(UU)
Yes
No
UV
980
Unsupported option
(At present, this error
is returned if OTP is
used which is yet to
be implemented)
Decline
Unsupported
option(UV)
No
No
UX
933
Request delayed for

more than 24 hrs.
Decline
Transaction
request older
than 24 hrs. (UX)
Yes
No
UY
511
Invalid PID XML

format
Decline
Invalid PID XML

format(UY)
No
No
UZ
940
Unauthorized ASA
channel
Decline
Unauthorized
ASA channel(UZ)
No
No
U0
941
Unspecified ASA
channel
Decline
Unspecified ASA
channel(U0)
No
No
V0
561
Request expired
(Pid->ts value is
older than N hours
where N is a
configured threshold
in authentication
server)
Decline
Please correct
your terminal
date & time and
then try again.
(V0)
Yes
No
V1
562
Timestamp value is
future time (value
specified Pid->ts is
ahead of
authentication server
time beyond
acceptable threshold)
Decline
Please correct
your terminal
date & time and
then try again.
(V1)
Yes
No
Page 22 of 90
V2
563
Duplicate request
(this error occurs
when exactly same
authentication
request was re-sent
by AUA)
Decline
Transaction
Declined;
Yes
No
Transaction
declined. Please
try again(V3)
Transaction
declined. Please
try again(V4)
Transaction
declined. Please
try again(V5)
Invalid input(V6)
Yes
No
Yes
No
Yes
No
No
No
Unsupported
language(V7)
No
No
No
No
Please re-enter
all details
again(V2)
V3
564
HMAC Validation
failed
Decline
V4
565
License key has

expired
Decline
V5
566
Invalid license key
Decline
V6
567
Invalid input (this

error occurs when
some unsupported
characters were
found in Indian
language values,
lname or lav)
Decline
V7
568
Unsupported
language
Decline
V8
569
Digital signature
verification failed
(this means that
authentication
request XML was
modified after it was
signed)
Decline
Digital signature
verification
failed (V8)
V9
570
Invalid key info in

digital signature (this
means that
certificate used for
signing the
Authentication
request is not valid
it is either expired,
or does not belong to
the AUA or is not
created by a wellknown Certification
Authority)
Decline
Invalid key info

in digital
signature(V9)
No
No
VA
571
PIN Requires reset

(this error will be
returned if resident is
using the default PIN
which needs to be
reset before usage)
Decline
PIN Requires
reset(VA)
No
No
VB
572
Invalid biometric
position (This error is
returned if biometric
position value - pos
Decline
Invalid biometric
position(VB)
Yes
No
Page 23 of 90
attribute in Bio
element - is not
applicable for a given
biometric type type attribute in
Bio element.)
VC
573
Pi usage not allowed

as per license
Decline
Pi usage not
allowed as per
license (VC)
Pa usage not
allowed as per
license (VD)
No
No
VD
574
Pa usage not allowed

as per license
Decline
No
No
VE
575
Pfa usage not allowed

as per license
Decline
Pfa usage not

allowed as per
license (VE)
No
No
VF
576
FMR usage not

allowed as per license
Decline
FMR usage not

allowed as per
license (VF)
No
No
VG
577
FIR usage not allowed

as per license
Decline
FIR usage not

allowed as per
license (VG)
No
No
VH
578
IIR usage not allowed

as per license
Decline
IIR usage not

allowed as per
license (VH)
No
No
VI
579
OTP usage not

allowed as per license
Decline
OTP usage not

allowed as per
license(VI)
No
No
VJ
580
PIN usage not allowed

as per license
Decline
PIN usage not

allowed as per
license (VJ)
No
No
VK
581
Fuzzy Matching usage

not allowed as per
license
Decline
Fuzzy Matching
usage not
allowed as per
license(VK)
No
No
VL
582
Local language usage

not allowed as per
license
Decline
Local language
usage not
allowed as per
license (VL)
No
No
VM
934
Technical error
category 4
Decline
Yes
No
VN
935
Technical error
category 5
Decline
Yes
No
VO
936
Technical error
category 6
Decline
Yes
No
VP
937
Technical error
category 7
Decline
Transaction
declined. Please
try again(VM)
Transaction
declined. Please
try again(VN)
Transaction
declined. Please
try again(VO)
Transaction
declined. Please
try again(VP)
Yes
No
Page 24 of 90
VQ
938
Technical error
category 8
Decline
VR
939
Technical error
category 9
Decline
VS
811
Decline
VT
501
Missing biometric
data in CIDR for given
AADHAAR
Invalid certificate
identifier in ci
attribute of Skey.
VU
502
Invalid encryption of
Pid
Decline
VV
503
Invalid encryption of
Hmac
Decline
VW
542
AUA not authorized

for ASA.
Decline
VX
543
Sub-AUA not
associated with
AUA
Decline
Decline
Transaction
declined. Please
try again(VQ)
Transaction
declined. Please
try again(VR)
Contact Aadhaar
centre
18001801947 (VS)
Transaction
declined. Please
try again(VT)
Yes
No
Yes
No
Yes
yes
Yes
No
Transaction
declined. Please
try again(VU)
Transaction
declined. Please
try again(VV)
Transaction
declined. Please
try again(VW)
Transaction
declined. Please
try again(VX)
Yes
No
Yes
No
Yes
No
Yes
No
DE-41 Card Acceptor Terminal Identification

Format: Fixed
Type: an8
Description: It should carry value public in the 0200 request for all transactions originated from
a device unregistered at UIDAI data base. For devices recognized by UIDAI, this code will be
allotted by UIDAI the data element is mandatory for 02xx and 04xx request messages.
NOTE: public must be left padded with 2 spaces making it a 8 digit value only.
DE-42 Card Acceptor Identification Code
Format: Fixed
Type: an15
Description: Identifies the acceptor in a transaction and if they accept or is different from the
acquiring institution. Special characters (including national character support characters) are not
allowed since some networks or back-office systems may have problems accepting these
characters. The data element is mandatory for 02xx and 04xx request messages.
Character 1-15 Merchant Name / Bank Correspondent Name
DE-43 Card Acceptor Name/Location
Page 25 of 90
Format: Fixed
Type: an40
Description: The name and location of the acceptor (Touch Point), which defines the point of
service in both local and interchange environments. Special characters (including national
character support characters) are not allowed since some networks or back-office systems may
have problems accepting these characters. Data element consists of the sub-fields detailed in the
table below. The data element is mandatory for 02xx and 04xx request messages.
Character 1-23 Merchant Address / Bank Correspondent Address
Character 24-36 City Name
Character 37-38 State
Character 39-40 Country Code (IN)
DE-45 Track 1 Data
Format: Fixed
Type: ans76
Description: Track 1 data as encoded by Issuer. The standard track structure is as follows:
Card Magnetic Stripe Personalization data
Track 1 Structure Symbol
STX
FC
Card No
FS
NM
FS
ED
SC
DD
Description
Start Sentinel
Format Code
Card number
Separator
Name
Separator
Expiration Date
Service Code
Discretionary Data
ETX
LRC
End Sentinel
Longitudinal Redundancy
Character code / No. of Characters

%
B
Up to 19 digits
^
2 to 26 characters
^
Four digits
Three digits
In discretionary Data first three
characters should be CVD1. The
12 digit AADHAAR number of the
customer should start from the
4th digit with character A as
prefix.
?
1 character
For card present transactions track 1 data is mandatory.

DE 49Transaction Currency Code
Format: LLLVAR
Type: n-3
Description: The Currency Code, Transaction (DE 49) is the code defining the local currency of the
acquirer bank. For all request with processing code 100000 bit corresponding to DE 49 must be off.
Field Edits: None
Page 26 of 90
Constraints: Data element is present for UID based 02xx response messages.
DE 54Additional Amounts
Format: Fixed
Type: an...120; LLLVAR
Description: It provides information for a maximum of six amounts. It must be populated in 0210
message for all transaction type with account balance.
Field Edits: It must be populated in 0210 message for all transaction type with account balance.
Constraints: None
DE-62 Private Use Field 62 UIDAI Authentication Code
Format: LLLVAR
Type: an999
Description: This Element is used in the response message to send the Authentication Code
received from the UIDAI server; NPCI will send the authentication code to the acquirer in response.
Field Edits: It should be sent back to acquirer bank in response to be displayed in response for all
ONUS transactions, For all offus transactions, NPCI must pass it on to issuer bank to carry the same
in their 210 response.
Constraints: C: Data element is present for UID based 02xx response messages.
DE-63 Private Use Field 63 UID Biometric Authentication Data
Format: LLLVAR
Type: an999
Description: This Element is encrypted containing finger print minutiae collected at the Micro ATM.
Data will contain single minutiae or other UID authentication payload.
Field Edits: None
Constraints: C: Data element is present for UID based 02xx request messages.
Elements Description:
DE63 is structured as TLV (Tag, length and value) field. The details of tags and contents are
described below:
Tag
Length
Description
Valid Value
001
Up to 999 characters
Encrypted Biometric Data only
Encrypted Biometric Data only
Example:
Lets assume XML tags along with Biometric are 430 bytes. The structure of DE63 is shown
below:
436001430<Encrypted biometric data>
Parsing of field is done as follows:
436 is the length of the string for DE63.
Page 27 of 90
Tag 001 represents biometric which is of length 430.

DE 70Network Management Information Code
Format: Fixed
Type: n-3
Description: This data element indicates the specific classification and purpose of network
management (08xx) messages. It must be present in all network management
(08xx) messages.
Field Edits: Valid values of DE 70 are as:
Sr.
No.
1
2
3
4
Message Type
0800
0810
logon
echo
cutover
handshake
001
301
201
002
001
301
201
002
Response code for 0810 message must be carried in DE 39 as 00 for successful request.
Constraints: None
DE-90 Original Data Element
Format: Fixed
Type: n42
Description: This data element contains parts of the original message being reversed or adjusted
and is used to match reversal/adjustment to previous authorization or financial transaction
message(s). This data element consists of sub-elements which are described below:
Sub-elements description:
Position
01-04
05-10
11-14
15-20
21-31
32-42
Length
4
6
4
6
11
11
Field Name
Original MTID
Original STAN
Original Local Date
Original Local Time
Original Acquiring Institution ID
Not used (to be filled with zero)
Description
MTID of original request
DE11 of original request
DE12 of original Request
--
DE-102 Account Identification 1

Format: LLVAR
Type: ans28
Description: A series of digits used to identify a customer account. It denotes the From account
number involved in the transaction (e.g. the Debit account in withdrawal or transfer transaction.
The account number in the Account Identification1 field must be right justified with leading zeros.
Usage:
In AADHAAR based Fund transfer transactions, issuer bank must send from account number which
is debited for the transfer amount. The account number should be asked as per banks policy.
Page 28 of 90
Field Edits: If present, should be echoed in all subsequent messages.

Constraints: C: The data element is used in 02xx and 04xx messages, whenever account
information must be transferred.
Format: LLVAR
Type: ans28
Description: A series of digits used to identify a customer account. It denotes to account number
involved in the transaction (e.g. the credit account in deposit or transfer transaction. The account
number in the Account Identification1 field must be right justified with leading zeros.
Usage:
In the AADHAAR based Fund transfer transactions, beneficiary bank must send the Beneficiarys
account number to which the amount was credited.
DE-120 Additional Data
Format: LLLVAR
Type: an999
Description: These fields are Tag-based.
Usage:
The generic description of DE120 is as follows:
<Tag number><Tag length><Tag data><Tag number><Tag length><Tag data>
Tag number size is 3, Tag length is represented as LLL and Tag data is as per requirement
DE2 will contain sender AADHAAR no for fund transfer.
Tag
001
002
005
006
045
060
001
002
005
006
045
0200 message from acquirer / Issuer to NPCI (for FT acquirer and issuer are same)
Description
Length
Value
Transaction type
2
45(for fund transfer) or 07(for mini statement)
Product indicator
3
UID(for fund transfer) or GDN(for mini statement)
No. of entries in the
002
06 (variable, used only for mini statement)
mini statement data
Actual Mini
210
Each statement will be of 35 character (used only
statement data
for mini statement)
Sender Name
20
Sender Name
Sender AADHAAR no.
19
Sender AADHAAR no. with IIN. Format
BBBBBB0UUUUUUUUUUUU (refer DE2 structure)
0200 message from NPCI to beneficiary bank
Transaction type
2
Product indicator
3
002
mini statement data
Actual Mini
210
statement data
for mini statement)
Sender Name
20
Sender Name
Page 29 of 90
060
Sender AADHAAR no.
19

0210 message from beneficiary to NPCI
001
Transaction type
2
002
Product indicator
3
005
002
mini statement data
006
Actual Mini
210
statement data
for mini statement)
045
Sender Name
20
Sender Name
046
Beneficiary Name
20
Beneficiary Name
060
Sender AADHAAR no.
19
0210 message from NPCI to acquirer / issuer
001
Transaction type
2
002
Product indicator
3
005
002
mini statement data
006
Actual Mini
210
statement data
for mini statement)
045
Sender Name
20
Sender Name
046
Beneficiary Name
20
Beneficiary Name
060
Sender AADHAAR no.
19
The sender and beneficiary name will be carried as a part of message but only sender and
beneficiary AADHAAR no. will be stored at NFS system for record purpose.
Field Edits: The contents of field may change in responses depending on result of transaction.
Constraints: C: Must be present in AADHAAR based Fund transfer transaction based Fund transfer.
Format: LLLVAR
Type: an999
Description: These fields are Tag-based. They will carry skey, ci, Hmac, ac, sa and lk in
tag 001, tag 002, tag 003, tag 004, tag 005 and tag 006 respectively
Constraints: C: Data element is present for UID based 02xx request message
Tag
001
Length
As per
the
process
Type
Variable
Format
an
Description
Skey(Value of this element
is encrypted 256-bit AES
session key.)
Valid Value
Digest value
002
Fixed
YYYYMMDD
ci (Public key certificate

identifier using which skey
was encrypted)
It is the expiry date

of the UIDAI public
key,
a
constant
value.
003
As per
the
process
Variable
an
Hmac (for description on

Hmac please refer to
http://uidai.gov.in/images/
FrontPageUpdates/aadhaar_
authentication_api_1_5_rev
1_1.pdf)
SHA -256 Hash of PID

XML
and
then
encrypted
004
010
Fixed
an
ac (A unique code for the
An
Alpha
numeric
Page 30 of 90
AUA which is assigned by

UIDAI
during
AUA
registration process)
value up
characters
to
10
005
010
Fixed
an
sa (A unique Sub-AUA
code, managed by AUA
within their system and
ensure uniqueness. If AUA
and SA are same agency, use
value of ac for this
attribute.)
An Alpha
value up
characters
numeric
to 10
006
064
Fixed
an
lk (A valid License Key

assigned to the AUA through
administration portal of
UIDAI. These license keys
have expiry built into them
and AUA administrator need
to ensure that they generate
new license keys before
current ones expires through
self-service portal.)
An Alpha
value up
characters
numeric
to 64
DE 127 is structured as TLV (Tag, length and value) field. The details of tags and contents are
described below:
Example:
Lets 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>
432 is the total length of the string for DE 127.
1. Tag 001 represents skey which is of length 256 char.
2. Tag 002 represents ci which is of length 8 char.
3. Tag 003 represents Hmac which is of length 48 char
4. Tag 004 represents ac which is of length 10 char
5. Tag 005 represents sa which is of length 10 char
6. Tag 006 represents lk which is of length 64 char
Usage:
Page 31 of 90
3.0 Changes for Member Banks as Acquirer and Issuers

3.1 Changes for Acquirer Members
a. Establish connection with Micro ATM and switch.
b. Addition of new transaction in the interface to existing NFS Switch
c. Changes in the current reconciliation system to reconcile the interchange and switching fees for
AADHAAR based transactions.
d. Acquirer switch to generate and process reversal request.
e. MicroATM must be capable to generate Last Transaction Status (LTS) request and acquirer
switch should response the status back to the MicroATM.
f.
Changes to generate and process reversal messages.
g. MicroATM application must be able to store all request originating from the device in an
electronic log. These logs will include details of original transaction request, LTS request &
reversal requests and will act as proofs while settling disputes for any transaction.
h. MicroATM application must be capable to push the Electronic Log to acquirer bank switch, at
the end of Business day.
3.2 Changes for Issuer Members

a. Addition of new transaction in the interface to existing NFS Switch
b. Changes in the current recon system to reconcile the interchange and switching fees for
AADHAAR based transactions.
c. Changes to generate and process reversal messages.
3.3 Changes in NPCI systems

a. Addition of new transaction in existing NFS switch
b. Changes in online dispute management system for new rules
c. Changes in billing system for these new transaction types.
d. Changes to develop new reports and raw data files.
e. Changes to generate and process reversal messages.
Page 32 of 90
4.0 Settlement and Reconciliation

4.1 Settlement and Reconciliation
Following are the changes in the settlement and reconciliation process,
1. Addition of these transaction in the existing acquirer raw data file and issuer raw data file circulated
by NPCI AEPS operation team to member banks.
2. Addition of this transaction in the existing acquirer activity report and issuer activity report circulated
by NPCI AEPS operation team to member banks.
4.2 Dispute Management Cycle

Following are the changes in the settlement and reconciliation process,
1. NPCI will also form an arbitration committee with nominated members of member banks to decide on
member banks.
2. Dispute Cycle - The various possible dispute scenarios have been given here to enable member banks
to refer to and resolve Interbank settlement issues:
a. Aadhaar to Aadhaar Funds Transfer:
Scenario: The Remitting Bank has debited the Remitting customers Account. The Beneficiary
Bank has made the Credit to the Beneficiarys Account too. The status of the remittance
transaction in the NPCI switch, however, is timed-out.
Solution: Beneficiary Bank is advised to raise a Debit Adjustment on the Remitting Bank. The
resulting interbank settlement will resolve the problem.
All time out scenarios in Aadhaar to Aadhaar Funds Transfers will be handled as per AEPS DMS
guidelines.
b. Aadhaar Initiated Cash Withdrawals:
For all Cash Withdrawal transactions, dispute management will be in the same manner as in NFS.
Case i) Issuer Bank has debited the customers Account. But due to a time-out, Cash was not
dispensed by the acquirer Interbank settlement also failed.
Issuer to reverse the debit made to the customer account by passing internal transfer
transactions.
Case ii) Issuer Bank has debited the customers account. But due to a time-out between the NPCI
switch and the acquirer switch, cash was not dispensed by the acquirer. Interbank settlement
however, was successful.
There are two options as under:
a. A Chargeback may be raised by Issuer (Representment to be raised by Acquirer if
back is disputed)
the charge
b. A pro-active Credit Adjustment by the Acquirer. (If an Acquirer sends a proactive credit
adjustment, it should be ensured that a charge back by the issuer is also not allowed. i.e.
Either Acquirer or Issuer will originate an interbank adjustment and not both.)
c. Aadhaar Initiated Cash Deposit Transactions:
Page 33 of 90
Case i) the customers account was credited with the cash deposit at the Issuer bank. Due to time
out, the Cash was returned to the customer by the acquirer. Interbank settlement also failed due
to time out status in the NPCI switch.
Issuer bank will simply reverse the credit by passing internal transfer transactions.
Case ii) the customers account was credited with the cash deposit at the Issuer bank. Due to
time out received by the Acquirer, the Cash was returned to the customer. However, interbank
settlement was successful.
The Acquirer will raise a Debit Adjustment with a request to the issuer to reverse the credit
made.
3. This transaction cycle will following timelines:
a. 1st chargeback - Issuer needs to raise this within 60 days from the transaction date.
b. Representment Within 5 days of the receipt of the chargeback for acquirer needs to
represent.
c. Credit Adjustment Acquirer can raise this within 60 days from the transaction date.
d. Debit Adjustment Acquirer can raise this within 17 days from the transaction date.
e. Chargeback on Debit Adjustment- Chargeback on Debit Adjustment will be 17 days from the
next day of Debit Adjustment raised.
f.
Pre-Arbitration-Pre-arbitration will be 30 days after the Representment date
g. Arbitration- Arbitration will be 30 days from the pre-arbitration rejection date.

h. Good faith-The time frame for raising Good Faith would be 60 days from the expiry of the
regular TAT
4. Separate additional report for only AADHAAR based transactions for acquirer and issuer banks.
5. Settlement cycle for all these transactions will be 23:00 to 23:00 for all days as per the current NFS
settlement windows.
NOTE: Please refer to AEPS DMS guidelines for more information on handling disputes.
Page 34 of 90
5.0 Risk Management

Following will be the risk management done by all the member banks:
1. Issuer Bank will be responsible to do all the following checking,
a. Balance authorization
b. Account Validations/Verifications.
c. Number of Transactions in a day for the specific Account product
d. Maximum limit in a day for the specific card product
e. Issuer banks will either not store the UID authentication data or store it in encrypted formats as
per PCI guidelines.
f.
AML related validations for Funds Transfer transaction.
g. Fraud Check
h. Duplicate (Multiple) reversals and original transactions.
i.
All other validations
j.
Issuer bank will connect to NPCI network on NPCINET.
2. Acquirer Bank will be responsible for following checking,

a. Acquirer shall not log the Biometric data on the switch.
b. Transaction and incoming message validation coming from Micro ATM.
c. Ensure card entry mode and pin entry mode to be present in the request.
d. Unique key management for the terminals.
e. Acquirer banks will either not store the UID authentication data or store it in encrypted formats as
per PCI guidelines.
f.
Issuer bank will connect to NPCI network on NPCINET.
Page 35 of 90
6.0 Exception Conditions

Exception conditions for which reversals would be generated:
In case, NPCI doesnt receive the response for a 200 Request message from Issuer, NPCI would send 210
Response to Acquirer with Response Code 91 and generate a Reversal Request (420) message with
Response Code 91 to Issuer Bank, which should reverse the transaction in CBS and respond with Response
Code 00 in 430 Reversal Response message to NPCI.
If NPCI does not get 0430 response from Issuer within 20 seconds it will generate 0421 message thrice
after a logon is received from bank.
In case, Acquirer Bank switch doesnt receive a 210 Response message for the request due to time out, it
should generate a 420 Reversal Request Message with Response Code 68, NPCI will send the message to
Page 36 of 90
Issuer Bank and Issuer needs to reverse the transaction in CBS and respond with 430 message containing
Response Code 00.
If NPCI does not get 0430 response from Issuer within 20 seconds it will generate 0421 message thrice
after a logon is received from bank.
Please refer AEPS reversal cases for complete information on reversals.
Page 37 of 90
7.0 Message Dump

7.1 Message dump for Network Messages
0800 message
Data
element
1
7
11
70
Value
Comment
Valid value
MMDDhhmmss
SSSSSS
Valid value as per request type
Secondary Bitmap
Transmission date and time
System Trace Audit Number
Network Management Information Code
0810 message
Data
element
1
7
11
39
70
Value
Comment
Valid value
MMDDhhmmss
SSSSSS
Valid response code 00as per
request type
Original request code as per request
Secondary Bitmap
7.2 Message dump for Authentication Transaction

Data
element
1
2
3
7
11
12
13
18
22
25
32
37
41
42
43
45
63
127
0200 message (From Acquirer/Issuer Bank to NPCI)

Value
Comment
Valid value
IIN + AADHAAR no.
100000
Secondary Bitmap
Sender s AADHAAR no.
Processing code for Bio metric
authentication
MMDDhhmmss
SSSSSS
HHMMSS
Time
DDMM
Date
6012
6012 for Micro ATM
01 9 or 02 9
Manual (01), Card Reader present (02)
Reserved for private use (9)
05
Customer present card not present
AcqInst ID
ID already allotted by NPCI
YDDDHHSSSSSS
Y Year (last digit)
DDD Julian Date
HH - Hour
SSSSSS System Trace Audit Number
Card Acceptor Terminal Identification
public
Card Acceptor Identification code
Merchant Name
Card Acceptor Name / Location
Address of BC
Track 1 data
As encoded in Card for card present
transaction
Biometric Data(PID XML)
Bio metric data from finger print scanner
Skey, ci, Hmac and ac, sa, lk
Captured from terminal and fed by AUA
server, respectively
0210 message (From NPCI to Issuer/Acquirer Bank)
Page 38 of 90
Data
element
2
3
Value
Comment
IIN + AADHAAR no.

100000
7
11
12
13
32
37
MMDDhhmmss
SSSSSS
HHMMSS
DDMM
ACQ Inst ID
YDDDHHSSSSSS
39
41
42
43
62
00
UIDAI Auth Code (Max. 40 Characters)

Processing code for Bio metric
authentication
Time
Date
Y Year (last digit)
DDD Julian Date
HH - Hour
Response code
Public
Merchant Name
Address of BC
Unique Authentication Code generated by
UIDAI
7.3 Message dump for Interbank Balance Enquiry

Data
Element
1
2
3
4
7
11
12
13
15
18
22
25
32
37
41
42
43
45
49
63
127
Data
Element
2
0200 message (from Acquirer to NPCI)

Value
Comment
Valid value
IIN + AADHAAR
(BBBBBB0UUUUUUUUUUUU)
310000
000000000000
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
6012
01 9 or 02 9
Secondary Bitmap
Customer details
IIN + AADHAAR
Customer details
Processing code fixed for Balance Inquiry

Amount Fixed value Zero
Time
Date
Settlement Date (conditional)
6012 for Micro ATM
05
ACQ Inst ID
YDDDHHSSSSSS
Y Year (last digit)
DDD Julian Date
HH- Hour
Public
Merchant Name
Address of BC
Track 1 data
transaction
356
Currency Code
0200 message (from NPCI to Issuer)
Value
Comment
Page 39 of 90
3
4
7
11
12
13
15
18
22
25
32
37
41
42
43
45
49
62
Data
element
2
3
4
7
11
12
13
15
32
37
39
41
42
43
49
54
62
Data
element
2
3
4
7
11
310000
000000000000
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
6012
01 9 or 02 9

Time
Date
6012 for Micro ATM
05
ACQ Inst ID
YDDDHHSSSSSS
Y Year (last digit)
DDD Julian Date
HH- Hour
Public
Merchant Name
Address of BC
Track 1 data
transaction
356
Currency Code
UIDAI
0210 message (from Issuer to NPCI)
Value
Comment
IIN + AADHAAR
310000
000000000000
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
ACQ Inst ID
YDDDHHSSSSSS
Customer details
IIN + AADHAAR
310000
000000000000
MMDDhhmmss
SSSSSS
Customer details

Time
Date
Settlement Date (optional)
Y Year (last digit)
DDD Julian Date
HH-Hour
00
Success response code
Public
Merchant Name
Address of BC
356
Currency Code
Amount
Account Balance
UIDAI
0210 message (from NPCI to Acquirer)
Value
Comment

Page 40 of 90
12
13
15
32
37
HHMMSS
MMDD
MMDD
ACQ Inst ID
YDDDHHSSSSSS
39
41
42
43
49
54
62
00
356
Amount
Time
Date
Y Year (last digit)
DDD Julian Date
HH-Hour
public
Merchant Name
Address of BC
Currency Code
Account Balance
UIDAI
7.4 Message dump for Interbank Cash Withdrawal

Data
Element
1
2
3
4
7
11
12
13
15
18
22
25
32
37
41
42
43
45
49
63
127
Data
Element
2
3
4

Value
Comment
Valid value
IIN + AADHAAR
010000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
6012
01 9 or 02 9
Secondary Bitmap
Customer details
IIN + AADHAAR
010000
Amount
Customer details
Processing code fixed for CW

Withdrawal amount
Time
Date
6012 for Micro ATM
05
ACQ Inst ID
YDDDHHSSSSSS
Y Year (last digit)
DDD Julian Date
HH- Hour
Public
Merchant Name
Address of BC
Track 1 data
transaction
356
Currency Code
Value
Comment

Withdrawal amount
Page 41 of 90
7
11
12
13
15
18
22
25
32
37
41
42
43
45
49
62
Data
Element
2
3
4
7
11
12
13
15
32
37
39
41
42
43
49
54
62
Data
element
2
3
4
7
11
12
13
15
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
6012
01 9 or 02 9

Time
Date
6012 for Micro ATM
05
ACQ Inst ID
YDDDHHSSSSSS
Y Year (last digit)
DDD Julian Date
HH- Hour
Public
Merchant Name
Address of BC
Track 1 data
transaction
356
Currency Code
UIDAI
Value
Comment
IIN + AADHAAR
010000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
ACQ Inst ID
YDDDHHSSSSSS
Customer details
IIN + AADHAAR
010000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
Beneficiary details

Withdrawal amount
Time
Date
Y Year (last digit)
DDD Julian Date
HH-Hour
00
Public
Merchant Name
Address of BC
356
Currency Code
Amount
Account Balance
UIDAI
Value
Comment

Withdrawal amount
Time
Date
Page 42 of 90
32
37
ACQ Inst ID
YDDDHHSSSSSS
39
41
42
43
49
54
62
00
356
Amount

Y Year (last digit)
DDD Julian Date
HH-Hour
Public
Merchant Name
Address of BC
Currency Code
Account Balance
UIDAI
7.5 Message dump for Interbank Cash Deposit

Data
Element
1
2
3
4
7
11
12
13
15
18
22
25
32
37
41
42
43
45
49
63
127
Data
Element
2
3
4
7
11
12

Value
Comment
Valid value
IIN + AADHAAR
210000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
6012
01 9 or 02 9
Secondary Bitmap
Customer details
IIN + AADHAAR
210000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
Customer details
Processing code fixed for CD

Deposit amount
Time
Date
6012 for Micro ATM
05
ACQ Inst ID
YDDDHHSSSSSS
Y Year (last digit)
DDD Julian Date
HH- Hour
Public
Merchant Name
Address of BC
Track 1 data
transaction
356
Currency Code
Value
Comment

Deposit amount
Time
Page 43 of 90
13
15
18
22
25
32
37
41
42
43
45
49
62
Data
element
2
3
4
7
11
12
13
15
32
37
39
41
42
43
49
54
62
Data
element
2
3
4
7
11
12
13
15
32
37
MMDD
MMDD
6012
01 9 or 02 9
Date
6012 for Micro ATM
05
ACQ Inst ID
YDDDHHSSSSSS
Y Year (last digit)
DDD Julian Date
HH- Hour
Public
Merchant Name
Address of BC
Track 1 data
transaction
356
Currency Code
UIDAI
Value
Comment
IIN + AADHAAR
210000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
ACQ Inst ID
YDDDHHSSSSSS
Beneficiary details
IIN + AADHAAR
210000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
ACQ Inst ID
YDDDHHSSSSSS
Beneficiary details

Deposit amount
Time
Date
Y Year (last digit)
DDD Julian Date
HH-Hour
00
Public
Merchant Name
Address of BC
356
Currency Code
Amount
Account Balance
UIDAI
Value
Comment

Deposit amount
Time
Date
Y Year (last digit)
DDD Julian Date
Page 44 of 90
39
41
42
43
49
54
62
00
356
Amount
HH-Hour
public
Merchant Name
Address of BC
Currency Code
Account Balance
UIDAI
7.6 Message dump for Interbank Fund Transfer Transaction

0200 message (from Remitter Bank to NPCI)
Value
Comment
Data
element
1
2
3
4
7
11
12
13
15
18
22
25
32
37
Valid value
IIN + AADHAAR
900000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
6012
019
05
ACQ Inst ID
YDDDHHSSSSSS
41
42
43
45

Track 1 data
49
102
356
Sender Account Detail
120
00100245002003UID045020<Sender
Name>060019IIN+ AADHAAR no.
Data
element
2
3
4
7
11
12
Secondary Bitmap
Beneficiary details
Processing code fixed for FT
Transfer amount
Time
Date
6012 for Micro ATM
Manual (01) Reserved for private use (9)
Temporary ID already allotted by NPCI
Y Year (last digit)
DDD Julian Date
HH-Hour
public
Merchant Name
Address of BC
transaction
Currency Code
Optional
Tag 001 Length 002 45

Tag 002 Length 003 UID
Tag 045 Length 020 - <Sender Name>
(optional)
Tag 060 Length -019 IIN + AADHAAR
0200 message (from NPCI to Beneficiary)
Value
Comment
IIN + AADHAAR
900000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
Beneficiary details
Transfer amount
Time
Page 45 of 90
13
15
18
22
25
32
37
MMDD
MMDD
6012/6010
019
05
ACQ Inst ID
YDDDHHSSSSSS
41
42
43
45

Track 1 data
49
356
102
120
Sender Account detail

00100245002003UID045020<Sender
Data
element
2
Date
6012 for Micro ATM and 6010 for POS
Y Year (last digit)
DDD Julian Date
HH- Hour
public
Merchant Name
Address of BC
transaction
Currency Code
Optional
(optional)
0210 message (from Beneficiary to NPCI)
Value
Comment
Beneficiary details
3
4
IIN + AADHAAR
900000
Amount
7
11
12
13
15
32
37
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
ACQ Inst ID
YDDDHHSSSSSS
39
41
00

Time
Date
Y Year (last digit)
DDD Julian Date
HH- Hour
public
54
102
103
120
Amount
Sender Account Detail
Beneficiary Account Detail
00100245002003UID045020<Sender
Name>046020<Beneficiary
Data
element
2
3

Transfer amount
Account Balance
Optional
Optional
(optional)
Tag 046 Length 020 - <Beneficiary Name>
(optional)
0210 message (from NPCI to Remitter)
Value
Comment
IIN + AADHAAR
900000
Beneficiary details
Page 46 of 90
Amount
Transfer amount
7
11
12
13
15
32
37
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
ACQ Inst ID
YDDDHHSSSSSS
39
41
42
43
00

Time
Date
Y Year (last digit)
DDD Julian Date
HH- Hour
public
Merchant Name
Address of BC
49
356
Currency Code
54
102
120
Amount
00100245002003UID045020<Sender
Account Balance
Optional
(optional)
(optional)
7.7 Message dump for Reversal request

0420 message (From Acquirer to NPCI)
Value
Comment
Data
element
1
2
3
4
7
11
12
13
15
18
22
Valid value
IIN + AADHAAR no.
Processing Code
Amount
MMDDhhmmss
SSSSSS
HHMMSS
DDMM
MMDD
6012
01 9 or 02 9
25
32
37
05
AcqInst ID
YDDDHHSSSSSS
39
41
42
43
49
00
Track 1 data
90
Valid values
Secondary Bitmap
Processing code for original transaction
Original transaction amount
Time
Date
6012 for Micro ATM
Y Year (last digit)
DDD Julian Date
HH - Hour
Response code
public
Merchant Name
Address of BC
transaction
Original transaction data
Page 47 of 90
102
Data
element
1
2
3
4
7
11
12
13
15
18
22
25
32
37
39
41
42
43
49
90
102
Data
element
1
2
3
4
7
11
12
13
15
18
22
Valid values
FROM Account
0420 message (From NPCI to Issuer)
Value
Comment
Valid value
IIN + AADHAAR no.
Processing Code
Amount
MMDDhhmmss
SSSSSS
HHMMSS
DDMM
MMDD
6012
01 9 or 02 9
Secondary Bitmap
Transfer amount
Time
Date
6012 for Micro ATM
05
AcqInst ID
YDDDHHSSSSSS
Y Year (last digit)
DDD Julian Date
HH - Hour
00
Response code
public
Merchant Name
Address of BC
Track 1 data
transaction
Valid values
Valid values
FROM Account
0430 message (From Acquirer to NPCI)
Value
Comment
Valid value
IIN + AADHAAR no.
Processing Code
Amount
MMDDhhmmss
SSSSSS
HHMMSS
DDMM
MMDD
6012
01 9 or 02 9
25
32
37
05
AcqInst ID
YDDDHHSSSSSS
39
41
42
43
49
00
Track 1 data
90
102
Valid values
Valid values
Secondary Bitmap
Customer s AADHAAR no.
Transfer amount
Time
Date
6012 for Micro ATM
Y Year (last digit)
DDD Julian Date
HH - Hour
Response code
public
Merchant Name
Address of BC
transaction
FROM Account
Page 48 of 90
Data
element
1
2
3
4
7
11
12
13
15
18
22
0430 message (From NPCI to Issuer)

Value
Valid value
IIN + AADHAAR no.
Processing Code
Amount
MMDDhhmmss
SSSSSS
HHMMSS
DDMM
MMDD
6012
01 9 or 02 9
25
32
37
05
AcqInst ID
YDDDHHSSSSSS
39
41
42
43
49
00
Track 1 data
90
102
Valid values
Valid values
Comment
Secondary Bitmap
Customers AADHAAR no.
Transfer amount
Time
Date
6012 for Micro ATM
Y Year (last digit)
DDD Julian Date
HH - Hour
Response code
public
Merchant Name
Address of BC
transaction
FROM Account
Page 49 of 90
8.0 Transaction Receipt Format

A receipt has to be given to a customer for every successful transaction. Receipt must also be printed for
selected decline transactions as well. This will help customer & business correspondent to prove in case of
a dispute. In order to standardize Receipt format across all the MicroATMs, NPCI proposes following
receipt format to be used as a template for all the transactions:
1. Receipt format for Cash Withdrawal

Bank Name and Logo
Cash Withdrawal
Date: (dd/mm/yy)
Time: (hh:mm:ss)
BC Name:
Agent Id:
BC Location:
Terminal Id:
Customer Aadhaar No:
Customer Name:
STAN:
RRN:
UIDAI Auth. Code:
Transaction Status: Successful(00)/Decline(response code)
Transaction Amount:
A/C Balance:
2. Receipt format for Cash Deposit

Bank Name and Logo
Cash Deposit
Date: (dd/mm/yy)
Time: (hh:mm:ss)
BC Name:
Agent Id:
BC Location:
Terminal Id:
Customer Name:
STAN:
RRN:
UIDAI Auth. Code:
Transaction Amount:
A/C Balance:
Page 50 of 90
3. Receipt format for Fund Transfer

Bank Name and Logo
Fund Transfer
Date: (dd/mm/yy)
Time: (hh:mm:ss)
BC Name:
Agent Id:
BC Location:
Terminal Id:
Remitter Aadhaar No:
Remitter Name:
Beneficiary Aadhaar No:
STAN:
RRN:
UIDAI Auth. Code:
Transaction Amount:
A/C Balance:
4. Receipt format for Balance Enquiry

Bank Name and Logo
Balance Enquiry
Date: (dd/mm/yy)
Time: (hh:mm:ss)
BC Name:
Agent Id:
BC Location:
Terminal Id:
Customer Name:
STAN:
RRN:
UIDAI Auth. Code:
Transaction Amount:
A/C Balance:
--------------------------------Format for Electronic logs-------------------------------------5. Format for Original Transaction Electronic log
Bank Name
Original Electronic Log
Date: (dd/mm/yy)
Time: (hh:mm:ss)
BC Name:
Agent Id:
BC Location:
Terminal Id:
Customer Name:
STAN:
RRN:
UIDAI Auth. Code:
Transaction Amount:
A/C Balance:
This block must be filled by

MicroATM values

Acquirer bank switch values
Page 51 of 90
6. Format for LTS Request Electronic log

Bank Name
LTS Electronic Log
Date: (dd/mm/yy)
Time: (hh:mm:ss)
BC Name:
Agent Id:
BC Location:
Terminal Id:
Customer Name:
STAN:
RRN:
UIDAI Auth. Code:
Transaction Amount:
A/C Balance:

MicroATM values

7. Format for Reversal Electronic log

Bank Name
Reversal Electronic Log
Date: (dd/mm/yy)
Time: (hh:mm:ss)
BC Name:
Agent Id:
BC Location:
Terminal Id:
Customer Name:
STAN:
RRN:

MicroATM values
Page 52 of 90
9.0 Changes in v2.7 from v2.6.1

Version 2.7
Version 2.6.1
MicroATM user interface changes suggested to

carry 12 digit AADHAAR number in three text
boxes for all transaction types
MicroATM user interface carries 12 digit

AADHAAR number in 1 text box for all transaction
types
MicroATM user interface changes suggested to

pre-select Remitter bank name in fund transfer
transaction
Customer had to select in MicroATM while filling

transaction details
MicroATM to generate receipt for selective

decline transactions along with response code
received from acquirer switch.
Receipt was generated only for successful

transactions
Implementation of Verhoeff algorithm

recommended to check AADHAAR number is valid
or not
Implementation of Verhoeff algorithm was not

specified
Addition of DE-54 in Message dumps. In an

interbank transaction issuer bank must send
account balance in DE 54
DE-54 was not present in message dumps
DE-4 and DE-49 made Conditional. These need to

be send only if processing code in DE-3 is other
than 10 00 00
DE-4 and DE-49 were mandatory all type of

transaction.
Value of DE-41 made specific to public
Value of DE-41 was not specified
Value of STAN to be passed in DE-11 should be

unique for every transactions
Description of DE 11 was not updated
Description of DE-1, DE-4, DE-7, DE-11, DE-12,

DE-13, DE-15, DE-41, DE-90 added
Not Available
Revised the description of DE-39, DE-43, DE-49,

DE-54, DE-70 and DE-120
As per then available information
Revised the settlement and reconciliation table
As per then available guidelines
Introduced message dump for reversal messages

& format for electronic logs
Not Available
Introduced message dump for 0200 & 0210

messages sent by NPCI to Issuer and vice-versa.
Not Available
MicroATM application to generate Electronic logs

Message on MicroATM will now also display error
code in brackets
Not Available
Message on MicroATM did not had error codes
displayed
Added new error codes introduced by UIDAI
Not Available
Page 53 of 90
Page 54 of 90
Interoperable Financial Inclusion

System
Chapter 1
Introduction
1.1 Executive Summary

National Payments Corporation of India (NPCI) is formed as an umbrella institution for all the retail
payments systems in the country. The core objective is to consolidate and integrate the multiple systems
with varying service levels into nation-wide uniform and standard business process for all retail payment
systems. The other objective was to facilitate an affordable payment mechanism to benefit the common
man across the country and help financial inclusion. Vision and formation of NPCI is backed by the
regulator and Indian Banks Association (IBA). NPCI has defined business lines to process in country
interbank transactions for ATM, POS, 24*7 Remittance, ACH and CTS.
Government of India has initiated Interoperable financial inclusion Project for citizens of India. To enable
the customers to use account number for the financial transaction across the payment networks in the
country, NPCI proposes to facilitate routing of transactions to the destination bank for user authentication
through a single interface. Banks have to use account number as unique identifier.
This interface document is targeted to achieve inter-operability between banks for financial inclusion
transactions.
NPCI shall allow banks to connect using this interface. It is also possible that banks may position their
respective financial inclusion service provider to connect on their behalf to NPCI central infrastructure with
the complete onus with the respective member bank.
1.2 Scope of this document

This document covers detailed description of the data elements in the ISO 8583 standard payment
message specifications.
1.3 Audience
This document is a property of NPCI and should be not be circulated to external party without prior
approvals of NPCI management team.
This document will be circulated to NPCI management team, NPCI Technical Advisor Committee, Business
user group (to be formed) from member banks, different working groups established as directed by RBI and
IBA.
Page 55 of 90
Chapter 2
Implementation for
Interoperable FI Architecture
2.1 Architecture Diagram and Brief

As per the NPCIs Interoperable Financial Inclusion System (IFIS) Specification, Customers account number
is used as a basic identifier to initiate a financial transactions and the authentication happens at finger print
database maintained with issuer bank.
The encryption logic is based on the PKI mechanism wherein the biometric necessitates the use of
respective banks public key which will be loaded across all the terminals of all the banks. The issuer bank
will decrypt the biometric packet by using its own private key for necessary authentication and
authorization.
The encryption logic, public key definition, encryption & encoding at terminal level, exchange of financial
information using appropriate message format etc. are all clearly outlined and handled by respective
acquirer & issuer bank as a part of their authentication process.
NPCI would only provide the switching service based upon the respective banks request wherein the
switch will be enhanced to support Interbank Transactions based upon the customer inputs to be treated
as unique identifier. Following are the Transaction Set,
1) Cash Withdrawal
2) Balance Enquiry
3) Cash Deposit
4) Funds Transfer
The following diagrams present a snapshot of these transactions:
Page 56 of 90
Guiding principles for the above architecture:

1. All Authentication & Transaction requests will be routed through the FI Gateway of the home
bank to NPCI
2.
Fingerprint data, customers account number and Transaction particulars constitute the
Transaction data packet
3. NPCI to act as agency for switching & settlement of all interbank transaction requests
Transaction Flows:
Cash Withdrawal Transaction Flow
Transaction flow description

1. Customer of Bank2 approaches Bank1 agent at Bank1 POS and requests for a Cash Withdrawal
transaction
Bank1 agent selects customers Bank (from list of participating banks), enters customers
account number, transaction amount, obtains customers fingerprint for authentication and
submits the transaction
2. The request on reaching Bank1 FI Gateway (if required through TSP server) initiates the
following transactions at Bank1 CBS
3. Routes transaction request containing FP template data and transaction packet to NPCI
4. NPCI routes the transaction request:
a. complete authentication and transaction request is sent to Bank 2 FI Gateway
Page 57 of 90
5. At Bank 2 FI Gateway, the FP data is sent to Bank2 FAS for FP authentication

6. After successful authentication, Bank 2 routes cash withdrawal request to Bank2 CBS.
7. Bank 2 responds success/ failure to NPCI
8. NPCI responds status of transaction to Bank 1 FI Gateway
9. Bank 1 FI Gateway responds status of transaction to Bank 1 POS (if required through TSP
server)
10. Depending on the status of transaction, if successful, Bank1 agent pays cash to customer.
Cash Desposit & Other Transactions Flow
Similar flows will be incorporated for Cash Deposit, Fund Transfer and other transactions
The transaction flow depicted above is for Balance Enquiry, Cash Withdrawal, Cash Deposit and FT
transactions acquired on bank 1 terminal for bank2 customers.
A Fund transfer transaction needs to be initiated on the home bank BC terminal only and thus the
IIN/Bank name selected for remitter bank needs to be prefixed to avoid manual entry selecting
mistake.
2.2 MicroATM Application Requirement:

1. MicroATM application on PoS must ensure that account number is entered as a block of 4 digits in
multiple blocks. This is to improve the business correspondent readability in case of manual entry.
2. The MicroATM application MUST necessitate that the Receivers account number is entered twice
by the sender on the fund transfer screen. There can be 2 textboxes for the same and a comparison
Page 58 of 90
of the digits entered should be made before proceeding to the next text box or screen. This will
ensure that the receivers account number is entered correct as is the practice while making online
payments.
2.3 Interface Specification

This document provides clear understanding of online interfaces, protocols and messages used, to enable
implementation of the interface connection, and to serve as a basic document for future enhancements.
Unless indicated otherwise, this document addresses ISO-8583:1987 standard for financial transaction
messages.
2.3.1 System Definitions

Following points should be noted while developing the interface,
1. Bank Systems and NPCI systems will be connecting to each other using persistent socket
connections.
2. Bank will act as client and NFS will act as server.
3. Banks will be responsible to generate the Logon (0800 message type) message after every
successful TCP socket connection. Banks should also generate Logon messages at the interval
of every 5 minutes.
4. NFS will generate cut over message (0800 message type) at 23:00 indicating business date
change over.
5. Both Banks and NFS can generate Logon (800 message type) messages and they should be
responded with 810 messages by the recipient.
6. Banks and NFS will also generate Echo message (0800 message type) for keep alive during no
transaction time. Ideal duration for the same should be 3 minutes.
7. Message Header 2 bytes binary (value containing length of the message including header
length i.e. 2 byte)
8. Bank needs to send auto logon (network) message when there is a disruption or disconnection
in network before sending the financial transaction message.
2.3.2 Data element processing rules

Originator
The originator of the request message must be able to:
Correctly populate DE-2 comprising of NBIN (6 digits ISO BIN) and last 12 digit of account number.
Correctly populate DE-18 and DE-22 based on the data supplied by Acquiring touch point.
Correctly populate DE-63 with Bio metric data.
Populate DE-120 with Senders name for Fund transfer transactions.
Populate DE- 102 with customer account number.
Page 59 of 90
Populate DE-127 with Skey and expiry date of public key.
NPCI
NPCI must be able to receive and process message containing DE-2, DE-63, DE -102, DE-120 and
DE- 127
Recipient
The Recipient must be able to receive & process messages containing DE-2, DE-22, DE -102 DE-120
and DE-127.
It is up to the recipient how to interpret and use the values transferred in DE-22, DE -102,DE-120
and DE-127
It must send current account balance of customer in DE -54 for all transactions.
In fund transfer transactions, Recipient must populate DE-103 with To account number and DE120 with Beneficiarys name in the response message.
2.3.3 Message format

Message formats specified below contain the changes in the message structure and/or data
element content are indicated by bold characters. These formats supersede the Host-to-Host
message specification provided by NPCI.
All message format definition tables use the symbols defined in the following table:
Message Types and Corresponding Data Elements
Symbol
Meaning
Mandatory.
M+
Mandatory, echoed from request.
A
C
Conditional.
C+
d
Conditional, echoed from request.
C*
Conditional, value may change.
Optional.
i
O+
Optional, echoed from request.
R
n
Reserved for future use.
Not used.
i
strative Messages
Network Management Messages

MTID
Data Element
0800
0810
Secondary bitmap
M+
Transmission date/time
M+
11
STAN
M+
15
Date, settlement
C+
Page 60 of 90

32
39
Response code
48
64
Key Data (Optional Dynamic Key

Exchange)
MAC Code(Optional MACing)
70
NMIC
M+
128
MACCode2(Optional MACing)
* DE 48 should be Conditional. Since, NPCI does not use dynamic key exchange so bank should off the bit
corresponding to DE 48 in the bitmap.
Financial Messages
MTID
Financial Messages
Data Element
0200
Secondary bitmap
M+
M+
Processing code
M+
Amount, transaction
C+
Amount, settlement
C+
M+
C+
11
STAN
M+
12
M+
13
M+
14
Date, expiration
15
Date, settlement
C+
18
Merchant type
22
POS entry mode
25
POS condition code
26
32
M+
35
Track2 data
37
-M+
38
39
Response code
41
-M
M+
42
Card acceptor ID
M+
43
M+
49
M+
50
C+
52
PIN Block
54
Additional amounts
0210
Page 61 of 90
MTID
Financial Messages
Data Element
0200
0210
63
Biometric data
64
MAC code
90
102
Customer account number
M+
103
Beneficiary account number
C+
120
Additional Data
121-123
Private use
C*
127
128
Additional Data
MACCode2
Reversal Messages
MTID
Reversal Messages
Data Element
0420
0430
1
2
3
4
5
7
8
Secondary bitmap
Processing code
Amount, transaction
Amount, settlement
M
M
M
M
C
M
R
M+
M+
M+
M+
C+
M
R
C+
11
STAN
M+
12
M+
13
M+
14
Date, expiration
15
Date, settlement
C+
22
POS entry mode
25
POS condition code
26
32
M+
35
Track2 data
37
M+
38
C+
39
Response code
41
M+
42
Card acceptor ID
43
49
M+
50
C+
54
Additional amounts
64
MAC code
Page 62 of 90
MTID
Reversal Messages
Data Element
0420
0430
90
102
103
120
Additional Data
C+
121-123
Private use
C*
128
MACCode2
2.3.4 Data Element Definitions

DE 1Secondary Bit Map
Type: b...64 - Transferred as 16 bytes (EBCDIC or ASCII characters).
Description Bitmap consists of 64 bits numbered from the left starting with 1. The value of each bit
signifies presence (1) or absence (0) in the message of the data element (DE-65 to DE-128)
associated with that particular bit.
Field Edits None.
Constraints C: Element is present only if message contains any of data elements from range DE-65
to DE-128.
DE-2 Primary Account Number, PAN
Format: LLVAR
Type: n...19
Description: The PAN number is the combination of NBIN (6 digits ISO BIN) and the last 12 digit of
account number. Since, account number varies from bank to bank thus DE 2 alone is not sufficient
to locate customer account in CBS as it will not allow more that 12 digit account number.
Now, DE 2 will be used by NPCI to route the request to issuer bank. However, acquirer bank is
expected to populate last 12 digits of the customer account number in DE 2.
It is mandatory for all 02xx and 04xxmessages.
Constraints:
Structure:
B
10
11
12
13
14
15
16
17
18
19
B NBIN (National Bank Identification Number)
Page 63 of 90
I Indicator for Interoperable transaction -2

A- Last 12 digits of the account number. If the account number is less than 12 digits then equal
number of zeros needs to be padded after 7th digit.
Note All Acquirers and Issuers will have to incorporate reserved digits for future use so that
whenever NPCI sends addendums or circular without any changes in the systems it can be
incorporated.
DE-3 Processing Code
Format: Fixed
Type: n6
Description: A series of digits that describes the type of transaction and the accounts affected by
the transaction. It consists of three, two-digit sub fields:
00
01
10
20
21
22
31
45
90
Digit1and2: Transaction Code:

Purchase of goods/services
Cash withdrawal
Biometric Verification (Biometric data verification/Authentication)
Credit, refund
Deposit
Credit adjustment
Balance inquiry
Fund Transfer
Extended transaction type**
Digit3and 4: From Account Type*
00
10
20
30
Unspecified/unknown
Savings
Checking
Credit card
00
10
20
30
Unspecified/unknown
Savings
Checking
Credit card
Digit5and6: To Account Number*
Summary of processing code used for IFIS transactions:

Cash withdrawal 010000
Balance inquiry 310000
Deposit 210000
Fund Transfer 9000001.
For FT the customer has to approach its bank infrastructure.
It is mandatory for all 02xx, 04xx messages.
Notes:*Other values may be used for optional features.
1
See also DE120 description for actual processing code
Page 64 of 90
Constraints: None
DE 4Amount, Transaction
Format: Fixed
Type: n12
Description: It is the amount of funds requested by the customer in the local currency of the
acquirer.
Field Edits: It should be echoed in response and all subsequent messages. For a balance enquiry
transaction, 0200 message should carry all zeros in DE 4.
Constraints: None
DE 7Transmission Date and Time

Format: Fixed
Type: n10: MMDDhhmmss
Description: It is the date and time when a transaction request was transmitted by a processing
entity.
Constraints: None
DE 11System Trace Audit Number (STAN)
Format: Fixed
Type: n6
Description: It is the unique identifier assigned to each transaction by the acquirer bank switch. It
must be different for every transaction even for multiple set of transactions originated at the same
time.
Field Edits: STAN is set by a message sender and echoed by the message receiver.
NOTE: It should not be date or time or similar to DE 7
DE 12Local Transaction Time
Format: Fixed
Type: n-6; hhmmss
Description: Time, Local Transaction (DE 12) is the local time the transaction takes place at the point
of service. It is the same to be printed on receipt.
Constraints: None
Page 65 of 90
DE 13Local Transaction Date

Format: Fixed
Type: n-4; MMDD
Description: Date, Local Transaction (DE 13) is the local month and day on which the transaction
takes place at the point of service. It is the same to be printed on receipt.
Constraints: None
DE 15Settlement Date
Format: Fixed
Type: n-4; MMDD
Description: Settlement Date (DE 15) is the date (month and day) that funds will be transferred
between an acquirer and an issuer.
Constraints: C: Field is present if a) Field DE-50 is present or b) MTID is 0800 and DE-70=201
(cutover message).
DE-18 Merchant Category Code (MCC)
Format: Fixed
Type: n4
Description: MCC is four-digit code. The data element is mandatory for 02xx request messages. It
is never present in response messages.
The proposed values are:
6012 Micro ATM transactions (If member banks want to support AADHAAR transactions through
their biometric ATMs then it will be 6011).
6010 for regular POS device.
Constraints: None
DE-22 Point of Service Entry Mode
Format: Fixed
Type: n3
Description: The code describing the way PAN and PIN are entered at a touch point.
Data element consists of two sub-fields:
PAN Entry Mode
01
Manual
Page 66 of 90
02
05
90
Magnetic stripe read.

ICC.
Full and unaltered magnetic stripe read (enables CVV validation).
0
1
2
6
9
Unspecified.
PIN entry capability.
No PIN entry capability.
PIN pad inoperative.
Reserved for private use
PIN Entry Mode
The data element is mandatory for 02xx, and 04xx request messages. It is never present in response
messages.
Constraints: None
DE-25 Point of Service Condition Code
Format: Fixed
Type: n2
Description: Two-digit code indicating conditions at touch point:
00
Normal
01
Customer not present.
02
Unattended terminal (CAT, ADM)
03
Merchant suspicious.
05
Customer present, card not present.
07
Telephone request.
08
MO/TO request.
Field Edits: it should be echoed in response and all subsequent messages.

Constraints: None
DE-32 Acquiring Institution Identification Code
Format: LLVAR
Type: n11
Description: Identifies the acquiring institution for the transaction, or its agent. The value will be
defined by the host. The data element is mandatory for 02xx and 04xx request messages. It is
optional for 08xx messages.
Constraints: O: Member can choose whether to use DE-32in 08xx messages or not.
Page 67 of 90
Note - NPCI shall assign appropriate codes to the participating banks to be

used in this field.
DE-37 Retrieval Reference Number

Format: Fixed
Type: an12
Description: The reference, assigned by the acquirer, to identify a transaction uniquely. It remains
unchanged for all messages throughout the life of a transaction and is used for matching original
message with reversal and/or store/forward messages. The standard format of RRN is as follows:
YDDDHHSSSSSS
Y Year (last digit of current year)
DDD Julian date of transaction
HH Hour of transaction
SSSSSS STAN of transaction (Same as in DE -11)
The data element is mandatory for 02xx, and 04xx request messages. The RRN can be used for the
entire dispute management of the transaction lifecycle.
In verification request value of DE-37 should be same as original remittance transaction RRN
Edit Field: It must be echo back in response message
Constraint: None
DE-39 Response Code
Format:
Type: an2
Description: This code indicates the disposition of a message as detailed tables below.
Each code is associated with specification code that is to be taken:
A
Approve transaction
Decline transaction
Field Edits: In reversal and store/forward requests, value identifies there as on for reversal or
store/forward message.
Constraints:
The following is the addendum covering different scenarios for Interoperable specific situations
and appropriate Response codes supported for declined biometric transactions in addition to the
existing response codes referred in the NPCI Host-to-Host specification document. Message to be
printed on Receipt is also specified.
Code
00
Description
Successful Transaction
0210 Response Code

Action
Approved
Message to be printed on Receipt

Successful Transaction
Page 68 of 90
91
NPCI doesnt get any response from Issuer

after sending the request
Decline
Service temporarily not available
08
NPCI is not able to send the request at all to

issuer
Decline
Issuer not available
92
Invalid NBIN entered at Terminal (NBIN not

present in routing table)
Decline
Invalid NBIN
52
Correct account number and Incorrect NBIN

entered at terminal (NBIN present in routing
table). Transaction declined by NPCI.
Insufficient Fund available in Residents
account. Transaction declined by Issuer.
Account blocked by Issuer/Regulator for
AML or any other appropriate reasons
Aggregate of all credits in a financial year
exceed Rs 1 Lakh for Small Accounts
Aggregate of all withdrawals and transfers in
a month exceeds Rs. 10,000 for Small
Accounts
Decline
Invalid Account
Decline
Insufficient Funds
Decline
Account blocked
Decline
Total annual credits exceed limit
Decline
Monthly limit exceeded for

transactions
AB
Account Balance exceeds rupees fifty

thousand for Small Accounts
Decline
Account Balance exceeds limit
M4
Remittance from/to Foreign/NRE Accounts
Decline
Foreign Remittance not allowed
UW
Transaction amount exceeded limit,

transaction is declined by Issuer.
Decline
Transaction amount exceeded limit
M6
Net Debit Cap limit is exhausted for member

bank. Transaction is declined by NPCI.
Decline
Limit exceeded for member bank
U3
Biometric data did not match
Decline
Biometric data did not match
U6
Invalid device
Decline
Invalid device
51
57
AY
AM
DE-41 Card Acceptor Terminal Identification

Format: Fixed
Type: an8
Description: A unique code identifying the terminal at the acceptor location. Special characters
(including national character support characters) are not allowed since some networks and/or
back-office systems may have problems accepting these characters. The data element is
mandatory for 02xx and 04xx request messages.
Character 1-3 Bank code / FI code - e.g. For SBI transactions, code can be SBI, for ICICI it can be
ICI
Character 4-8 Unique Terminals ID
Page 69 of 90
The first 3 digits of the terminal ID should be institution name.

DE-42 Card Acceptor Identification Code
Format: Fixed
Type: an15
Description: Identifies the acceptor in a transaction and if they accept or is different from the
acquiring institution. Special characters (including national character support characters) are not
allowed since some networks or back-office systems may have problems accepting these
characters. The data element is mandatory for 02xx and 04xx request messages.
Character 1-15 Merchant Name / Bank Correspondent Name/BC ID
DE-43 Card Acceptor Name/Location
Format: Fixed
Type: an40
Description: The name and location of the acceptor (Touch Point), which defines the point of
service in both local and interchange environments. Special characters (including national
character support characters) are not allowed since some networks or back-office systems may
have problems accepting these characters. Data element consists of the sub-fields detailed in the
table below. The data element is mandatory for 02xx and 04xx request messages.
Character 1-23 Merchant Address / Bank Correspondent Address
Character 24-36 City Name
Character 37-38 State
Character 39-40 Country Code (IN)
DE 49Transaction Currency Code
Format: LLLVAR
Type: n-3
Description: The Currency Code, Transaction (DE 49) is the code defining the local currency of the
acquirer bank.
Field Edits: None
Constraints: Data element is present for IFIS based 02xx response messages.
DE 54Additional Amounts
Format: Fixed
Page 70 of 90
Type: an...120; LLLVAR

Description: It provides information for a maximum of six amounts. It must be populated in 0210
message for all transaction type with account balance.
Field Edits: It must be populated in 0210 message for all transaction type with account balance.
Constraints: None
DE-63 Private Use Field 63 Bank Biometric Authentication Data
Format: LLLVAR
Type: an999
Description: This Element is encrypted containing finger print minutiae collected at the Micro ATM.
Data will contain single minutiae or other authentication payload.
Field Edits:
Constraints: C: Data element is present for account number based 02xx request messages.
DE63 is structured as TLV (Tag, length and value) field. The details of tags and contents are
described below:
Tag
Length
Description
Valid Value
001
Up to 999 characters
Biometric Data
Biometric Data in data type of

DE63
Example:
Lets assume Biometric data is 430 bytes. The structure of DE63 is shown below:
436001430<Encoded and encrypted biometric data >
436 is the length of the string for DE63.
Note: Encryption of biometric data shall take place by using 256 bit AES one time usage Session
Key and this Session key must be encrypted by 2048 bit public key of issuer bank.
DE 70Network Management Information Code
Format: Fixed
Type: n-3
Description: This data element indicates the specific classification and purpose of network
management (08xx) messages. It must be present in all network management (08xx) messages.
Field Edits: Valid values of DE 70 are as:
Page 71 of 90
Sr.
No.
Message
Type
0800
0810
logon
001
001
echo
301
301
cutover
201
201
handshake
002
002
Response code for 0810 message must be carried in DE 39 as 00 for successful request.
Constraints: None
DE-90 Original Data Element
Format: Fixed
Type: n42
Description: This data element contains parts of the original message being reversed or adjusted
and is used to match reversal/adjustment to previous authorization or financial transaction
message(s). This data element consists of sub-elements which are described below:
Sub-elements description:
Position
01-04
05-10
11-14
15-20
21-31
32-42
Length
4
6
4
6
11
11
Field Name
Original MTID
Original STAN
Original Local Date
Original Local Time
Original Acquiring Institution ID
Not used (to be filled with zero)
Description
MTID of original request
DE12 of original Request
--

Format: LLVAR
Type: ans28
Description: A series of digits used to identify a customer account. It denotes the From account
number involved in the transaction (e.g. the Debit account in withdrawal or transfer transaction.
The account number in the Account Identification1 field must be right justified with leading zeros.
Usage:
In IFIS based Fund transfer transactions, issuer bank must send from account number which is
debited for the transfer amount. The account number should be masked as per banks policy.
Page 72 of 90
Format: LLVAR
Type: ans28
Description: A series of digits used to identify a customer account. It denotes to account
number involved in the transaction (e.g. the credit account in deposit or transfer transaction. The
account number in the Account Identification1 field must be right justified with leading zeros.
Usage:
In the IFIS based Fund transfer transactions, beneficiary bank must send the Beneficiarys
account number to which the amount was credited.
Constraints: C: The data element is used in 02xx and 04xx messages , whenever account

Format: LLLVAR
Type: an999
Description: These fields are Tag-based.
Usage:
Tag number size is 3, Tag length is represented as LLL and Tag data is as per requirement
Account number to Account number fund transfer request:
DE2 will contain sender Unique no.
Tag
001
002
045
060
001
0200 message from acquirer / Issuer to NPCI (for FT acquirer and issuer are same)
Description
Length
Value
Transaction type
2
45
Product indicator
3
NUD
Sender Name
20
Sender Name
Sender account number 19
Sender account number with
NBIN. Format
BBBBBB2AAAAAAAAAAAA
(refer DE2 structure)
0200 message from NPCI to beneficiary bank
Transaction type
2
45
Page 73 of 90
002
045
060
Product indicator
Sender Name
Sender account number
3
20
19
001
002
045
046
060
0210 message from beneficiary to NPCI

Transaction type
2
Product indicator
3
Sender Name
20
Beneficiary Name
20
NUD
Sender Name
NBIN. Format
BBBBBB2AAAAAAAAAAAA
45
NUD
Sender Name
Beneficiary Name
NBIN. Format BBBBBB2
AAAAAAAAAAAA (refer DE2
structure)
0210 message from NPCI to acquirer / issuer

Transaction Code
2
45
Product indicator
3
NUD
Sender Name
20
Sender Name
Beneficiary Name
20
Beneficiary Name
NBIN. Format
BBBBBB2AAAAAAAAAAAA
001
002
045
046
060
The sender and beneficiary name will be carried as a part of message but only sender and beneficiary
account number will be stored at NFS system for record purpose.
Field Edits: The contents of field may change in responses depending on result of transaction.
Constraints: C: Must be present in Interoperable Fund transfer transaction based Fund transfer.
Format: LLLVAR
Type: an999
Description: These fields are Tag-based. They will carry skey, Expiry date of public key respectively.
Constraints: C: Data element is present for IFIS based 02xx request message
Ta
g
Lengt
h
Type
001
As per
the
process
Variabl
e
002
Fixed
Format
Description
Valid Value
an
Skey(Value of this element is

encrypted
256-bit
AES
session key.)
Digest value
YYYYMMD
D
Public
key
certificate
identifier using which skey
It is the expiry date of

the Issuer banks
Page 74 of 90
was encrypted
public key issued by

IDRBT, a constant
value.
DE 127 is structured as TLV (Tag, length and value) field. The details of tags and contents are
described below:
Example:
Lets assume that skey length is 256 bytes, ci length is 8 bytes. The structure of DE127 is
shown below:
276001256<skey>002008<ci>
276 is the total length of the string for DE 127.
7. Tag 001 represents skey which is of length 256 char.
8. Tag 002 represents ci which is of length 8 char.
Usage:
Page 75 of 90
Chapter 3 Changes for Member Banks

as Acquirer and Issuers
3.1 Changes for Acquirer Members
a) Establish connection with Micro ATM and switch.
b) Addition of new transaction in the interface to existing NFS Switch
c) Changes in the current reconciliation system to reconcile the interchange and switching fees for IFIS
based transactions.
d) Acquirer switches to generate and process reversal request.
e) MicroATM must be capable to generate Last Transaction Status (LTS) request and acquirer switch
should response the status back to the MicroATM.
f)
Changes to generate and process reversal messages.
g) MicroATM application must be able to store all request originating from the device in an electronic
log. These logs will include details of original transaction request, LTS request & reversal requests and
will act as proofs while settling disputes for any transaction.
h) MicroATM application must be capable to push the Electronic Log to acquirer bank switch, at the
end of Business day.
3.2 Changes for Issuer Members

a) Addition of new transaction in the interface to existing NFS Switch
b) Changes in the current recon system to reconcile the interchange and switching fees for IFIS based
transactions.
c) Changes to generate and process reversal messages.
d) Change to read customer account number from
3.3 Changes in NPCI systems

a) Addition of new transaction in existing NFS switch
b) Changes in online dispute management system for new rules
c) Changes in billing system for these new transaction types.
d) Changes to develop new reports and raw data files.
Page 76 of 90
Chapter 4 Settlement and Recon

4.1 Settlement and Recon
Following are the changes in the settlement and recon process,
1. Addition of these transaction in the existing acquirer raw data file and issuer raw data file
circulated by NFS operations team to member banks.
2. Addition of this transaction in the existing acquirer activity report and issuer activity report
circulated by NFS operations team to member banks.
4.2 Dispute Management Cycle

Following are the changes in the settlement and recon process,
1. NPCI will also form an arbitration committee with nominated members of member banks to decide
on member banks.
2. Dispute Cycle - The various possible dispute scenarios have been given here to enable member
banks to refer to and resolve Interbank settlement issues:
a. Account to Account Funds Transfer:
Scenario: The Remitting Bank has debited the Remitting customers Account. The
Beneficiary Bank has made the Credit to the Beneficiarys Account too. The status of the
remittance transaction in the NPCI switch, however, is timed-out.
Solution: Beneficiary Bank is advised to raise a Debit Adjustment on the Remitting Bank.
The resulting interbank settlement will resolve the problem.
b. Account number initiated Cash Withdrawals:
For all Cash Withdrawal transactions, dispute management will be in the same manner as
in NFS.
Case i) Issuer Bank has debited the customers Account. But due to a time-out, Cash was
not dispensed by the acquirer Interbank settlement also failed.
Issuer to reverse the debit made to the customer account by passing internal transfer
transactions.
Case ii) Issuer Bank has debited the customers account. But due to a time-out between
the NPCI switch and the acquirer switch, cash was not dispensed by the acquirer.
Interbank settlement however, was successful.
There are two options as under:
a. A Chargeback may be raised by Issuer (Representment to be raised by Acquirer if
the charge back is disputed)
b. A pro-active Credit Adjustment by the Acquirer. (If an Acquirer sends a proactive
credit adjustment, it should be ensured that a charge back by the issuer is also not allowed.
i.e. Either Acquirer or Issuer will originate an interbank adjustment and not both.)
Page 77 of 90
c. Account number initiated Cash Deposit Transactions:

Case i) the customers account was credited with the cash deposit at the Issuer bank. Due
to time out, the Cash was returned to the customer by the acquirer. Interbank settlement
also failed due to time out status in the NPCI switch.
Issuer bank will simply reverse the credit by passing internal transfer transactions.
Case ii) the customers account was credited with the cash deposit at the Issuer bank. Due
to time out received by the Acquirer, the Cash was returned to the customer. However,
interbank settlement was successful.
The Acquirer will raise a Debit Adjustment with a request to the issuer to reverse the credit
made.
3. This transaction cycle will following timelines:
a. 1st chargeback - Issuer needs to raise this within 60 days from the transaction date.
b. Re-presentment Within 5 days of the receipt of the chargeback for acquirer needs to
represent.
c. Credit Adjustment Acquirer can raise this within 60 days from the transaction date.
d. Debit Adjustment Acquirer can raise this within 17 days from the transaction date.
e. Chargeback on Debit Adjustment- Chargeback on Debit Adjustment will be 17 days from the
next day of Debit Adjustment raised.
f.
Pre-Arbitration-Pre-arbitration will be 30 days after the Representment date
g. Arbitration- Arbitration will be 30 days from the pre-arbitration rejection date.

h. Good faith-The time frame for raising Good Faith would be 60 days from the expiry of the
regular TAT
4. Separate additional report for only IFIS based transactions for acquirer and issuer banks.
5.
Settlement cycle for all these transactions will be 23:00 to 23:00 for all days as per the current NFS
settlement windows.
NOTE: Please refer to DMS guidelines for more information on handling disputes.
Page 78 of 90
Chapter 5 Risk Management

Following will be the risk management done by all the member banks,
1. Issuer Bank will be responsible to do all the following checking,
a. Balance authorization
b. Account Validations/Verifications.
c. Number of Transactions in a day for the specific Account product
d. Maximum limit in a day for the specific card product
e. Issuer banks will either not store the authentication data or store it in encrypted formats as
per PCI guidelines.
f.
AML related validations for Funds Transfer transaction.
g. Fraud Check
h. Duplicate (Multiple) reversals and original transactions.
i.
All other validations
j.
Issuer bank will connect to NPCI network on IPSEC/VPN.
2. Acquirer Bank will be responsible for following checking,

a. Acquirer shall not log the Biometric data on the switch.
b. Transaction and incoming message validation coming from Micro ATM.
c. Ensure card entry mode and pin entry mode to be present in the request.
d. Unique key management for the terminals.
e. Acquirer banks will either not store the authentication data or store it in encrypted formats
as per PCI guidelines.
f.
Issuer bank will connect to NPCI network on IPSEC/VPN
g. As different banks are following different standards for capturing fingerprints, template
and scanner of different qualities and resolution with a different matching logic, NPCI
would not hold any liabilities on the above parameters and not even prescribe any
standards.
h. Encryption mechanism needs to be defined & standardized across the device level .NPCI
wont be responsible for encryption and decryption rather only will act as a switching
agency to route the transaction to issuing bank . Matching Success: FAR/FRR does not lie
with the NPCI as respective bank has to take the ownership of the same.
Page 79 of 90
Chapter 6 Exception Conditions

Exception conditions for which reversals would be generated:
In case, NPCI doesnt receive the response for a 200 Request message from Issuer, NPCI would send 210
Response to Acquirer with Response Code 91 and generate a Reversal Request (420) message with
Response Code 91 to Issuer Bank, which should reverse the transaction in CBS and respond with Response
Code 00 in 430 Reversal Response message to NPCI.
If NPCI does not get 0430 response from Issuer within 20 seconds it will generate 0421 message thrice after
a logon is received from bank.
Page 80 of 90
In case, Acquirer Bank switch doesnt receive a 210 Response message for the request due to time out, it
should generate a 420 Reversal Request Message with Response Code 68, NPCI will send the message to
Issuer Bank and Issuer needs to reverse the transaction in CBS and respond with 430 message containing
Response Code 00.
If NPCI does not get 0430 response from Issuer within 20 seconds it will generate 0421 message thrice after
a logon is received from bank.
Please refer IFIS reversal cases for complete information on reversals.
Page 81 of 90
Chapter 7 Message Dump

This chapter shows various message dumps.
7.1 Message dump for Balance Enquiry

200 message
Comment
Data
element
1
2
3
4
7
11
12
13
15
18
22
Value
25
32
37
05
AcqInst ID
YDDDHHSSSSSS
41
42
43
49
63
102

356
Biometric Data
Customer Account
127
Additional Data( encrypted session key &

expiry date of issuer bank public key)
210 message
Value
Comment
Data
element
2
3
4
7
11
12
13
15
32
37
39
Valid Value
NBIN +2+ last 12 digit of account number
310000
000000000000
MMDDhhmmss
SSSSSS
HHMMSS
DDMM
MMDD
6011
01 9 or 02 9
NBIN + last 12 digit of account number

310000
000000000000
MMDDhhmmss
SSSSSS
HHMMSS
DDMM
MMDD
ACQ Inst ID
YDDDHHSSSSSS
00
Secondary bit map

Customers details
Processing code for balance enquiry
Amount Fixed value - Zero
Time
Date
6011 for Micro ATM
Manual (01), Card Reader present (02) Reserved for
private use (9)
Y Year (last digit)
DDD Julian Date
HH-Hour
SSSSSS Trace Number
Terminal ID
Merchant Name
Address of BC
Currency Code
Right justified account number, left padded with
zeros
Captured from the terminal
Customers details
Time
Date
Y Year (last digit)
DDD Julian Date
HH-Hour
SSSSSS Trace Number
Successful Response code
Page 82 of 90
41
42
43
49
54
102

356
Amount
Customer Account
Terminal ID
Merchant Name
Address of BC
Currency Code
Account Balance
zeros
7.2 Message dump for Cash Deposit

200 message
Comment
Data
element
1
2
3
4
7
11
12
13
15
18
22
Value
25
32
37
05
AcqInst ID
YDDDHHSSSSSS
41
42
43
49
63
102

356
Biometric Data
Customer Account
127

210 message
Value
Comment
Data
element
2
3
4
7
11
12
13
15
32
37
Valid Value
210000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
DDMM
MMDD
6011
01 9 or 02 9
NBIN + 2+ last 12 digit of account number

310000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
DDMM
MMDD
ACQ Inst ID
YDDDHHSSSSSS
Secondary bit map

Customers details
Processing code for cash deposit
Deposit Amount
Time
Date
6011 for Micro ATM
private use (9)
Y Year (last digit)
DDD Julian Date
HH-Hour
SSSSSS Trace Number
Terminal ID
Merchant Name
Address of BC
Currency Code
zeros
Customers details
Processing code for cash deposit
Deposit Amount
Time
Date
Y Year (last digit)
DDD Julian Date
HH-Hour
SSSSSS Trace Number
Page 83 of 90
39
41
42
43
49
54
102
00
356
Amount
Customer Account

Terminal ID
Merchant Name
Address of BC
Currency Code
Account Balance
zeros
7.3 Message dump for Cash Withdrawal

200 message
Comment
Data
element
1
2
3
4
7
11
12
13
15
18
22
Value
25
32
37
05
AcqInst ID
YDDDHHSSSSSS
41
42
43
49
63
102

356
Biometric Data
Customer Account
127

210 message
Value
Comment
Data
element
2
3
4
7
11
12
13
15
32
37
Valid Value
010000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
DDMM
MMDD
6011
01 9 or 02 9

310000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
DDMM
MMDD
ACQ Inst ID
YDDDHHSSSSSS
Secondary bit map

Customers details
Processing code for cash withdrawal
Withdrawal Amount
Time
Date
6011 for Micro ATM
private use (9)
Y Year (last digit)
DDD Julian Date
HH-Hour
SSSSSS Trace Number
Terminal ID
Merchant Name
Address of BC
Currency Code
zeros
Customers details
Withdrawal Amount
Time
Date
Y Year (last digit)
DDD Julian Date
HH-Hour
Page 84 of 90
39
41
42
43
49
54
102
00
356
Amount
Customer Account
SSSSSS Trace Number

Terminal ID
Merchant Name
Address of BC
Currency Code
Account Balance
zeros
7.4 Message dump for Fund Transfer Transaction

Comment
Date
Element
1
2
3
4
7
11
12
13
15
18
22
Value
25
32
37
05
ACQ Inst ID
YDDDHHSSSSSS
41
42
43
49
102
103
120

356
Beneficiary Account Detail
00100245002003NUD045020<Sender
Name>060019NBIN+ account number
Valid Value
900000
Amount
MMDDhhmmss
SSSSSS
HHMMSS
MMDD
MMDD
6011
01 9 or 02 9
Secondary bit map

Beneficiary details
Transfer amount
Time
Date
Settlement Date (Conditional)
6011 for Micro ATM
Y Year (last digit)
DDD Julian Date
HH-Hour
SSSSSS Trace Number
Terminal ID
Merchant Name
Address of BC
Currency Code
mandatory
mandatory
Tag 002 Length 003 NUD
(optional)
Tag 060 Length -019 NBIN + account
number
127
Additional Data( encrypted session key & expiry

date of issuer bank public key)
Date
Element
2
3
Value
200 message (from NPCI to Beneficiary)

Comment

900000
(BBBBBB2UIUIUIUIUIUIUIUIUIUIUIUI)
Beneficiary details
Page 85 of 90
4
11
12
13
15
18
22
25
32
37
Amount
SSSSSS
HHMMSS
MMDD
MMDD
6011
019
05
ACQ Inst ID
YDDDHHSSSSSS
41
42
43
49
102
103
120

356
Beneficiary Account Details
00100245002003NUD045020<Sender
Name>060019NBIN+account number
127
Additional Data( encrypted session key & expiry

date of issuer bank public key)
Date
Element
2
3
4
11
12
13
15
32
37
Value
39
41
42
43
49
54
102
103
120
00
356
Amount
Beneficiary Account detail
00100245002003NUD045020<Sender
210 message (from Beneficiary to NPCI)

Comment

900000
Amount
SSSSSS
HHMMSS
MMDD
MMDD
ACQ Inst ID
YDDDHHSSSSSS
Transfer amount
Time
Date
6011 for Micro ATM
Y Year (last digit)
DDD Julian Date
HH-Hour
SSSSSS Trace Number
Terminal ID
Merchant Name
Address of BC
Currency Code
Optional
mandatory
(optional)
number(BBBBBB2UIUIUIUIUIUIUIUIUIUIUIUI)
Beneficiary details
Transfer amount
Time
Date
Y Year (last digit)
DDD Julian Date
HH- Hour
SSSSSS Trace Number
Successful response code
Terminal ID
Merchant Name
Address of BC
Currency Code
Account Balance
Optional
Mandatory
(optional)
Page 86 of 90

(optional)
number

Comment
Date
Element
2
3
4
11
12
13
15
32
37
Value
39
41
42
43
49
54
102
103
120
00
356
Amount
Beneficiary Account detail
00100245002003NUD045020<Sender
NBIN + 2+last 12 digit of account number

900000
Amount
SSSSSS
HHMMSS
MMDD
MMDD
ACQ Inst ID
YDDDHHSSSSSS
Beneficiary details
Transfer amount
Trace number
Time
Date
Y Year (last digit)
DDD Julian Date
HH-Hour
SSSSSS Trace Number
Successful response code
Terminal ID
Merchant Name
Address of BC
Currency Code
Account Balance
Optional
Mandatory
(optional)
(optional)
Tag 060 Length -019 NBIN + Last 12 digit
of account number
Page 87 of 90
Chapter 8 Transaction Receipt Format

In order to standardize Receipt format across all the MicroATMs, NPCI proposes following receipt format to
be used as a template for all the transactions:
1. Receipt format for Cash Withdrawal
Bank Name and Logo
Cash Withdrawal
Date: (dd/mm/yy)
Time: (hh:mm:ss)
BC Name:
Agent Id:
BC Location:
Terminal Id:
Customer account number:
Customer Name:
STAN:
RRN:
Transaction Status:
Transaction Amount:
A/C Balance:
2.
Receipt format for Cash Deposit
Bank Name and Logo

Cash Deposit
Date: (dd/mm/yy)
BC Name:
BC Location:
Customer Name:
STAN:
RRN:
Transaction Status:
Transaction Amount:
A/C Balance:
Time: (hh:mm:ss)
Agent Id:
Terminal Id:
3. Receipt format for Fund Transfer
Bank Name and Logo

Fund Transfer
Date: (dd/mm/yy)
BC Name:
BC Location:
Remitter account number
Remitter Name:
Time: (hh:mm:ss)
Agent Id:
Terminal Id:
Page 88 of 90
Beneficiary account number STAN:

RRN:
Transaction Status:
Transaction Amount:
A/C Balance:
4. Receipt format for Balance Enquiry
Bank Name and Logo

Balance Enquiry
Date: (dd/mm/yy)
Time: (hh:mm:ss)
BC Name:
Agent Id:
BC Location:
Terminal Id:
Customer Name:
STAN:
RRN:
Transaction Status:
Transaction Amount:
A/C Balance:
--------------------------------Format for Electronic logs-------------------------------------8. Format for Original Transaction Electronic log
Bank Name
Original Electronic Log
Date: (dd/mm/yy)
Time: (hh:mm:ss)
BC Name:
Agent Id:
BC Location:
Terminal Id:
Customer account number No:
Customer Name:
STAN:
RRN:
Transaction Amount:
A/C Balance:

MicroATM values

9. Format for LTS Request Electronic log

Bank Name
LTS Electronic Log
Date: (dd/mm/yy)
Time: (hh:mm:ss)
BC Name:
Agent Id:
BC Location:
Terminal Id:
Customer Name:

MicroATM values
Page 89 of 90
STAN:
RRN:
Transaction Status: Successful (00)/Decline (response code)
Transaction Amount:
A/C Balance:

10. Format for Reversal Electronic log

Bank Name
Reversal Electronic Log
Date: (dd/mm/yy)
Time: (hh:mm:ss)
BC Name:
Agent Id:
BC Location:
Terminal Id:
Customer Name:
STAN:
RRN:
Transaction Status: Successful (00)/Decline(response code)

MicroATM values
Page 90 of 90

SOP BC Interoperability - Interface Specifications

Uploaded by

Document Information

Original Description:

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

SOP BC Interoperability - Interface Specifications

Uploaded by

Copyright:

Available Formats

INTERFACE SPECIFICATION

[INTERFACE SPECIFICATION for BC INTEROPERABILITY]

AADHAAR ENABLED PAYMENT SYSTEM

1.2 Scope of this document

National Payments Corporation of India

[Type of Document: Confidential]

[INTERFACE SPECIFICATION for BC INTEROPERABILITY]

2.0 AADHAAR Implementation for FI Architecture

National Payments Corporation of India

[Type of Document: Confidential]

[INTERFACE SPECIFICATION for BC INTEROPERABILITY]

National Payments Corporation of India

[Type of Document: Confidential]

[INTERFACE SPECIFICATION for BC INTEROPERABILITY]

Details Onus Flow (only authentication)

MicroATM Application Requirement:

National Payments Corporation of India

[Type of Document: Confidential]

[INTERFACE SPECIFICATION for BC INTEROPERABILITY]

Details - Off us flow for Funds Transfer:

MicroATM Application Requirement:

National Payments Corporation of India

[Type of Document: Confidential]

[INTERFACE SPECIFICATION for BC INTEROPERABILITY]

Flow diagram of AEPS fund transfer transaction:

National Payments Corporation of India

[Type of Document: Confidential]

[INTERFACE SPECIFICATION for BC INTEROPERABILITY]

National Payments Corporation of India

[Type of Document: Confidential]

[INTERFACE SPECIFICATION for BC INTEROPERABILITY]

MicroATM Application Requirement:

2.2 Interface Specification

2.2.1 System Definitions

2.2.2 Data element processing rules

National Payments Corporation of India

[Type of Document: Confidential]

[INTERFACE SPECIFICATION for BC INTEROPERABILITY]

Populate DE-127 with Skey, ci, Hmac, ac, sa and lk.

2.2.3 Message format

Conditional, echoed from request.

Reserved for future use.

2.2.3.1 Administrative Messages

National Payments Corporation of India

[Type of Document: Confidential]

[INTERFACE SPECIFICATION for BC INTEROPERABILITY]

Key Data (Optional Dynamic

2.2.3.2 Financial Messages

Primary Account Number

Fee, card holder billing

Conversion rate, settlement

Time, local transaction

Date, local transaction

POS entry mode

POS condition code

POS PIN capture code

Retrieval Reference Number

Card acceptor terminal ID

Card acceptor name/location

National Payments Corporation of India

[Type of Document: Confidential]

[INTERFACE SPECIFICATION for BC INTEROPERABILITY]

Currency code, transaction