AEPS Interface Specification v2.7 PDF

AADHAAR ENABLED
PAYMENT SYSTEM
INTERFACE SPECIFICATION
[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION]
Documents Details
Author
Ruchir Asthana
Published Date
26-01-12
Version
2.7
Total Page number
55
Document classification
Confidential
Document History
Date
26-01-12
Version
2.7
Change
OFFUS ready Message dump & Receipt Format
Updated
Description of all required Data Element introduced
Updated
Settlement and reconciliation changes as per AEPS

DMS guidelines
Updated
Changes recommended for MicroATM Application

User Interface
Introduced
Prepared By:
Date
Ruchir Asthana
26-01-12
Reviewed By:
Mr. Ragavan Venkatesan
Mr. Mukesh Ranjan
Mr. Sateesh Palagiri
Mr. S M Nabar
Date
27-01-12
14-02-12
02-02-12
02-03-12
Approved By:
Mr. Dilip Asbe
National Payments Corporation of India
[Type of Document: Confidential]
Date
02-03-12
Page 2 of 55
Table Of Contents
1.0 Introduction ..................................................................................................................... 4
2.0 AADHAAR Implementation for FI Architecture .................................................................. 5
3.0 Changes for Member Banks as Acquirer and Issuers ........................................................ 34
4.0 Settlement and Reconciliation ........................................................................................ 35
5.0 Risk Management .......................................................................................................... 37
6.0 Exception Conditions ...................................................................................................... 38
7.0 Message Dump .............................................................................................................. 40
8.0 Transaction Receipt Format ............................................................................................ 52
9.0 Changes in v2.7 from v2.6.1 ............................................................................................ 55
Page 3 of 55
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.
Page 4 of 55
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 5 of 55
Page 6 of 55
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 7 of 55
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 8 of 55
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 9 of 55
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 10 of 55

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 11 of 55
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 12 of 55
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 13 of 55
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+
Primary Account Number
M+
Processing code
M+
Amount, transaction
M+
Amount, settlement
C+
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+
22
POS entry mode
25
POS condition code
26
POS PIN capture code
32
M+
35
Track2data
37
Retrieval reference number
M+
38
Authorization number
C+
39
Response code
41
Card acceptor terminal ID
Page 14 of 55
Reversal Messages
MTID
42
Data Element
Card acceptor ID
0420
M
0421*
M
0430
-
43
Card acceptor name/location
49
Currency code, transaction
M+
50
Currency code, settlement
C+
54
Additional amounts
64
MAC code
90
Original data element
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 15 of 55
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 16 of 55
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 17 of 55
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 18 of 55
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 19 of 55
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 20 of 55
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 21 of 55
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 22 of 55
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 23 of 55
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 24 of 55
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 25 of 55
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 26 of 55
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 27 of 55
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 28 of 55
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 29 of 55
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 30 of 55
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.
DE-103 Account Identification 2
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.
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.
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 31 of 55
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.
DE-127 Additional Data
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 32 of 55
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
Elements Description:
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>
Parsing of field is done as follows:
432 is the total length of the string for DE 127.
1. Tag 001 represents skey which is of length 256 char.
2. Tag 002 represents ci which is of length 8 char.
3. Tag 003 represents Hmac which is of length 48 char
4. Tag 004 represents ac which is of length 10 char
5. Tag 005 represents sa which is of length 10 char
6. Tag 006 represents lk which is of length 64 char
Usage:
The generic description of DE127 is as follows:
<Tag number><Tag length><Tag data><Tag number><Tag length><Tag data>
Page 33 of 55
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 34 of 55
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 35 of 55
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 36 of 55
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 37 of 55
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 38 of 55
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 39 of 55
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 40 of 55
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 41 of 55
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 42 of 55
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 43 of 55
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 44 of 55
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 45 of 55
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 Auth Code (Max. 40 Characters) Unique Authentication Code generated by
UIDAI
Value
Comment

Deposit amount
Time
Date
Y Year (last digit)
DDD Julian Date
Page 46 of 55
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 47 of 55
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
Manual (01) Reserved for private use (9)
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 48 of 55
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
Sender Account detail
00100245002003UID045020<Sender
Name>046020<Beneficiary
Account Balance
Optional
(optional)
Tag 046 Length 020 - <Beneficiary Name>
(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 49 of 55
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 50 of 55
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 51 of 55
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 52 of 55
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 53 of 55
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 54 of 55
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 55 of 55

AEPS Interface Specification v2.7 PDF

Uploaded by

Copyright:

Available Formats

AEPS Interface Specification v2.7 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AEPS Interface Specification v2.7 PDF

Uploaded by

Copyright:

Available Formats

What is the document about?

What is the document about?

What changes were introduced in version 2.7?

What changes were introduced in version 2.7?

AADHAAR ENABLED

[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION]

Total Page number

Description of all required Data Element introduced

Settlement and reconciliation changes as per AEPS

Changes recommended for MicroATM Application

National Payments Corporation of India

[Type of Document: Confidential]

[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION]

National Payments Corporation of India

[Type of Document: Confidential]

[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION]

1.2 Scope of this document

National Payments Corporation of India

[Type of Document: Confidential]

[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION]

2.0 AADHAAR Implementation for FI Architecture

National Payments Corporation of India

[Type of Document: Confidential]

[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION]

National Payments Corporation of India

[Type of Document: Confidential]

[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION]

Details Onus Flow (only authentication)

MicroATM Application Requirement:

National Payments Corporation of India

[Type of Document: Confidential]

[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION]

Details - Off us flow for Funds Transfer:

MicroATM Application Requirement:

National Payments Corporation of India

[Type of Document: Confidential]

[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION]

Flow diagram of AEPS fund transfer transaction:

National Payments Corporation of India

[Type of Document: Confidential]

[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION]

National Payments Corporation of India

[Type of Document: Confidential]

[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION]

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]

[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION]

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]

[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION]