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 Version Change
OFFUS ready Message dump & Receipt Format Updated
Description of all required Data Element introduced Updated

26-01-12 2.7
Settlement and reconciliation changes as per AEPS Updated
DMS guidelines
Changes recommended for MicroATM Application Introduced

User Interface
Prepared By: Date
Ruchir Asthana 26-01-12
Reviewed By: Date

Mr. Ragavan Venkatesan 27-01-12
Mr. Mukesh Ranjan 14-02-12
Mr. Sateesh Palagiri 02-02-12
Mr. S M Nabar 02-03-12
Approved By: Date

Mr. Dilip Asbe 02-03-12
National Payments Corporation of India [Type of Document: Confidential] 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

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.

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:


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.

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.

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.

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.


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

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 Meaning
2
M Mandatory.
.
M+ Mandatory, echoed from request.
2C Conditional.
. C+ Conditional, echoed from request.
C* Conditional, value may change.
2
O Optional.
. O+ Optional, echoed from request.
1R Reserved for future use.
Not used.
A-
2.2.3.1 Administrative Messages
Network Management Messages
MTID Data Element 0800 0810

1 Secondary bitmap M M+
7 Transmission date/time M M+
11 STAN M M+
15 Date, settlement C C+
32 Acquirer institution ID - -
39 Response code - M

48 Key Data (Optional Dynamic C* -

Key Exchange)
64 MAC Code(Optional R R
MACing)
70 NMIC M M+
128 MACCode2(Optional R R
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
1 Secondary bitmap M M+
2 Primary Account Number M M+

3 Processing code M M+
4 Amount, transaction C C+
5 Amount, settlement C C+
7 Date/time, transmission M M+
8 Fee, card holder billing R R
9 Conversion rate, settlement C C+
11 STAN M M+
12 Time, local transaction M M+
13 Date, local transaction M M+
14 Date, expiration C -
15 Date, settlement C C+
18 Merchant type M M+
22 POS entry mode M M+
25 POS condition code M M+
26 POS PIN capture code C -
32 Acquirer institution ID M M+
35 Track2data C -
37 Retrieval Reference Number M M+
38 Authorization number - C
39 Response code - M
41 Card acceptor terminal ID M M+

42 Card acceptor ID M M+
43 Card acceptor name/location M M+
45 Track 1 C -

49 Currency code, transaction C C+

50 Currency code, settlement C C+
52 PIN Block C -
54 Additional amounts - C
62 UIDAI Authentication Code C M
63 UID Authentication data M -
64 MAC code R R
90 Original data element - -
102 Account 1 identification C C
103 Account 2 identification C C
120 Additional Data C C
121-123 Private use C C*
127 Additional Data(skey, ci, Hmac, ac, sa ,lk) M -
128 MACCode2 R R
2.2.3.3 Reversal Messages
Reversal Messages
MTID Data Element 0420 0421* 0430
1 Secondary bitmap M M M+
2 Primary Account Number M M M+
3 Processing code M M M+
4 Amount, transaction M M M+
5 Amount, settlement C C C+
7 Date/time, transmission M M M
8 Fee, card holder billing R R R
9 Conversion rate, settlement C C C+
11 STAN M M M+
12 Time, local transaction M M M+
13 Date, local transaction M M M+
14 Date, expiration C C -
15 Date, settlement C C C+
22 POS entry mode M M -
25 POS condition code M M -
26 POS PIN capture code C C -
32 Acquirer institution ID M M M+
35 Track2data O O -
37 Retrieval reference number M M M+
38 Authorization number C C C+
39 Response code M M M
41 Card acceptor terminal ID M M

Reversal Messages
MTID Data Element 0420 0421* 0430
42 Card acceptor ID M M -
43 Card acceptor name/location M M -
49 Currency code, transaction M M M+
50 Currency code, settlement C C C+
54 Additional amounts - - C
64 MAC code R R R
90 Original data element M M M
102 Account 1 identification C C C
103 Account 2 identification C C C
120 Additional Data C C C+
121-123 Private use C C C*
128 MACCode2 R R R
*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:

B B B B B B I U U U U U U U U U U U U
1 2 3 4 5 6 7 8 9 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 Purchase of goods/services
01 Cash withdrawal
10 Biometric Verification (UID Biometric data verification/Authentication) for ONUS
20 Credit, refund
21 Deposit
22 Credit adjustment
31 Balance inquiry
45 Transfer
90 Extended transaction type**
Digit 3 and 4: From Account Type*

00 Unspecified/unknown
10 Savings
20 Checking
30 Credit card
Digit 5 and 6: To Account Number*

00 Unspecified/unknown
10 Savings
20 Checking
30 Credit card
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.

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

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:
PAN Entry Mode

01 Manual
02 Magnetic stripe read.
05 ICC.
90 Full and unaltered magnetic stripe read (enables CVV validation).
PIN Entry Mode

0 Unspecified.
1 PIN entry capability.
2 No PIN entry capability.

6 PIN pad inoperative.

9 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 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.
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: 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 Approve transaction
D 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.
0210 Response Code

NPCI UIDAI Description Action Message to be Message to Receipt to be
error Error displayed at be displayed printed by
Code Code Acquirer on MicroATM MicroATM
MicroATM
00 - Successful Approved Successful Yes Yes
Transaction Transaction
91 - NPCI doesnt get any Decline Transaction Yes Yes

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

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

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

and correct IIN Account(52)
entered at terminal
(IIN present in routing
table). Account
number is not present
in CBS. Transaction
declined by NPCI.
51 - Insufficient Fund Decline Insufficient Yes Yes
available in Funds(51)

Residents account.
Transaction declined
by Issuer.
57 - Account blocked by Decline Account blocked Yes Yes
Issuer/Regulator for (57)
AML or any other
appropriate reasons
AY - Aggregate of all Decline Total annual Yes Yes
credits in a financial credits exceed
year exceed Rs 1 Lakh limit(AY)
AM - Aggregate of all Decline Monthly limit Yes Yes
withdrawals and exceeded for
transfers in a month transactions(AM)
exceeds Rs. 10,000
AB - Account Balance Decline Account Balance Yes Yes

exceeds rupees fifty exceeds limit(AB)
thousand
M4 - Remittance from/to Decline Foreign Yes Yes

Foreign/NRE Accounts Remittance not
allowed(M4)
UW - Transaction amount Decline Transaction Yes Yes
exceeded limit, amount
transaction is exceeded
declined by Issuer.
limit(UW)
M6 - Net Debit Cap limit is Decline Limit exceeded No No

exhausted for for member
member bank. bank(M6)
Transaction is
declined by NPCI.
U1 100 Identity attribute of Decline Identity attribute No No

demographic details of demographic
does not match details does not
match(U1)
U2 200 Address attribute of Decline Address attribute No No
demographic details of demographic
does not match details does not
match(U2)
U3 300 Biometric data did Decline Biometric data Yes No

not match did not
match(U3)
U4 500 Encryption of session Decline Transaction Yes No

key is invalid declined. Please
try again(U4)
U5 510 Invalid XML format Decline Transaction Yes No

declined. Please
try again(U5)
U6 520 Invalid device Decline Wrong Terminal Yes Yes

ID (U6)

U7 530 Invalid authenticator Decline Invalid Yes No

code authenticator
code(U7)
U8 540 Invalid version Decline Invalid version Yes No

(U8)
U9 550 Invalid Uses Decline Invalid Uses No No

element attribute element
attribute(U9)
UA 700 Invalid demographic Decline Invalid No No

data demographic
data(UA)
UB 710 Missing Pi data as Decline Missing Pi data No No

specified in Uses as specified in
Uses (UB)
UC 720 Missing Pa data as Decline Missing Pa data No No

Uses (UC)
UD 730 Missing PIN data as Decline Missing PIN data No No

Uses (UD)
UE 999 Unknown error Decline Transaction Yes No

declined. Please
try again(UE)
UF 740 Missing OTP data as Decline Missing OTP data No No

Uses (UF)
UG 800 Invalid biometric data Decline Invalid biometric Yes No

data(UG)
UH 810 Missing biometric Decline Missing biometric No No

data as specified in data as specified
Uses in Uses (UH)
UI - Time Out for the Decline Transaction Yes No

request sent to UIDAI Declined. Please
from NPCI beyond 10 try again(UI)
seconds (like
response not received
for Authentication
Request
UJ 721 Missing "Pfa" data as Decline Missing "Pfa" data No No
specified in "Uses" as specified in
element "Uses"
element(UJ)

UK 820 Missing or empty Decline Missing or empty No No

value for "bt" value for "bt"
attribute in "Uses" attribute in
element
"Uses"
element(UK)
UL 821 Invalid value in the Decline Invalid value in No No

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

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

"Pi" element. Invalid value in "Pi"
dates are one which element. (UN)
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
UO 910 Invalid "mv" value in Decline Invalid "mv" No No

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

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

"Pa" (If match
strategy other than E

is used) in "Pa"(UQ)
UR 913 Both Pa and Pfa are Decline Both Pa and Pfa No No

present (Pa and Pfa are present(UR)
are mutually
exclusive)
US 930 Technical error Decline Transaction Yes No

category 1 (Related declined. Please
to ABIS interactions) try again(US)
UT 931 Technical error Decline Transaction Yes No

category 2 (Internal declined. Please
to auth server such as try again(UT)
Database server
down, etc.)
UU 932 Technical error Decline Transaction Yes No

category 3 (Error if declined. Please
audit XML could not try again(UU)
be published to audit
queue, or if audit
XML could not be
constructed)
UV 980 Unsupported option Decline Unsupported No No

(At present, this error option(UV)
is returned if OTP is
used which is yet to
be implemented)
UX 933 Request delayed for Decline Transaction Yes No

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

format format(UY)
UZ 940 Unauthorized ASA Decline Unauthorized No No

channel ASA channel(UZ)
U0 941 Unspecified ASA Decline Unspecified ASA No No

channel channel(U0)
V0 561 Request expired Decline Please correct Yes No

(Pid->ts value is your terminal
older than N hours date & time and
where N is a
then try again.
configured threshold
in authentication (V0)
server)
V1 562 Timestamp value is Decline Please correct Yes No

future time (value your terminal
specified Pid->ts is date & time and
ahead of
then try again.
authentication server
time beyond (V1)
acceptable threshold)

V2 563 Duplicate request Decline Transaction Yes No

(this error occurs Declined;
when exactly same
authentication Please re-enter
request was re-sent all details
by AUA)
again(V2)
V3 564 HMAC Validation Decline Transaction Yes No

failed declined. Please
try again(V3)
V4 565 License key has Decline Transaction Yes No
expired declined. Please
try again(V4)
V5 566 Invalid license key Decline Transaction Yes No
declined. Please
try again(V5)
V6 567 Invalid input (this Decline Invalid input(V6) No No
error occurs when
some unsupported
characters were
found in Indian
language values,
lname or lav)
V7 568 Unsupported Decline Unsupported No No

language language(V7)
V8 569 Digital signature Decline No No

verification failed Digital signature
(this means that verification
authentication failed (V8)
request XML was
modified after it was
signed)
V9 570 Invalid key info in Decline Invalid key info No No

digital signature (this in digital
means that signature(V9)
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 well-
known Certification
Authority)
VA 571 PIN Requires reset Decline PIN Requires No No

(this error will be reset(VA)
returned if resident is
using the default PIN
which needs to be
reset before usage)
VB 572 Invalid biometric Decline Invalid biometric Yes No

position (This error is position(VB)
returned if biometric
position value - pos

attribute in Bio
element - is not
applicable for a given
biometric type -
type attribute in
Bio element.)
VC 573 Pi usage not allowed Decline Pi usage not No No

as per license allowed as per
license (VC)
VD 574 Pa usage not allowed Decline Pa usage not No No
license (VD)
VE 575 Pfa usage not allowed Decline Pfa usage not No No

license (VE)
VF 576 FMR usage not Decline FMR usage not No No

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

license (VG)
VH 578 IIR usage not allowed Decline IIR usage not No No

license (VH)
VI 579 OTP usage not Decline OTP usage not No No

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

license (VJ)
VK 581 Fuzzy Matching usage Decline Fuzzy Matching No No

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

not allowed as per usage not
license allowed as per
license (VL)
VM 934 Technical error Decline Transaction Yes No

category 4 declined. Please
try again(VM)
VN 935 Technical error Decline Transaction Yes No
try again(VN)
VO 936 Technical error Decline Transaction Yes No
try again(VO)
VP 937 Technical error Decline Transaction Yes No
try again(VP)

VQ 938 Technical error Decline Transaction Yes No

try again(VQ)
VR 939 Technical error Decline Transaction Yes No
try again(VR)
VS 811 Missing biometric Decline Contact Aadhaar Yes yes
data in CIDR for given centre
AADHAAR 18001801947 (VS)
VT 501 Invalid certificate Decline Transaction Yes No
identifier in ci declined. Please
attribute of Skey. try again(VT)
VU 502 Invalid encryption of Decline Transaction Yes No

Pid declined. Please
try again(VU)
VV 503 Invalid encryption of Decline Transaction Yes No
Hmac declined. Please
try again(VV)
VW 542 AUA not authorized Decline Transaction Yes No
for ASA. declined. Please
try again(VW)
VX 543 Sub-AUA not Decline Transaction Yes No
associated with declined. Please
AUA try again(VX)
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

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 Description Character code / No. of Characters

STX Start Sentinel %
FC Format Code B
Card No Card number Up to 19 digits
FS Separator ^
NM Name 2 to 26 characters
FS Separator ^
ED Expiration Date Four digits
SC Service Code Three digits
DD Discretionary Data 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.
ETX End Sentinel ?
LRC Longitudinal Redundancy 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

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.

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. Message Type 0800 0810

No.
1 logon 001 001
2 echo 301 301
3 cutover 201 201
4 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 Length Field Name Description

01-04 4 Original MTID MTID of original request
05-10 6 Original STAN DE11 of original request
11-14 4 Original Local Date DE12 of original Request
15-20 6 Original Local Time DE13 of original request
21-31 11 Original Acquiring Institution ID DE32 of original request
32-42 11 Not used (to be filled with zero) --
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.

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.
0200 message from acquirer / Issuer to NPCI (for FT acquirer and issuer are same)
Tag Description Length Value
001 Transaction type 2 45(for fund transfer) or 07(for mini statement)
002 Product indicator 3 UID(for fund transfer) or GDN(for mini statement)
005 No. of entries in the 002 06 (variable, used only for mini statement)
mini statement data
006 Actual Mini 210 Each statement will be of 35 character (used only
statement data for mini statement)
045 Sender Name 20 Sender Name
060 Sender AADHAAR no. 19 Sender AADHAAR no. with IIN. Format
BBBBBB0UUUUUUUUUUUU (refer DE2 structure)
0200 message from NPCI to beneficiary bank
mini statement data

0210 message from beneficiary to NPCI
mini statement data
046 Beneficiary Name 20 Beneficiary Name
0210 message from NPCI to acquirer / issuer
mini statement data
046 Beneficiary Name 20 Beneficiary Name
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 Length Type Format Description Valid Value

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

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

AUA which is assigned by value up to 10

UIDAI during AUA characters
registration process)
005 010 Fixed an sa (A unique Sub-AUA An Alpha numeric

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

assigned to the AUA through value up to 64
administration portal of characters
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.)
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>

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.

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 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.)
c. Aadhaar 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. 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.

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.

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

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.

7.0 Message Dump
7.1 Message dump for Network Messages
0800 message
Data Value Comment
element
1 Valid value Secondary Bitmap
7 MMDDhhmmss Transmission date and time
11 SSSSSS System Trace Audit Number
70 Valid value as per request type Network Management Information Code
0810 message
Data Value Comment
element
7 MMDDhhmmss Date/time, transmission
39 Valid response code 00as per Network Management Information Code
request type
70 Original request code as per request Network Management Information Code
7.2 Message dump for Authentication Transaction
0200 message (From Acquirer/Issuer Bank to NPCI)

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

Data Value Comment

element
3 100000 Processing code for Bio metric
authentication
12 HHMMSS Time
13 DDMM Date
32 ACQ Inst ID ID already allotted by NPCI
DDD Julian Date
HH - Hour
39 00 Response code
41 Card Acceptor Terminal Identification Public
62 UIDAI Auth Code (Max. 40 Characters) Unique Authentication Code generated by
UIDAI
7.3 Message dump for Interbank Balance Enquiry
0200 message (from Acquirer to NPCI)

Data Value Comment
Element
2 IIN + AADHAAR Customer details
(BBBBBB0UUUUUUUUUUUU)
3 310000 Processing code fixed for Balance Inquiry
4 000000000000 Amount Fixed value Zero
12 HHMMSS Time
13 MMDD Date
15 MMDD Settlement Date (conditional)
DDD Julian Date
HH- Hour
transaction
49 356 Currency Code
0200 message (from NPCI to Issuer)
Data Value Comment
Element

12 HHMMSS Time
13 MMDD Date
DDD Julian Date
HH- Hour
transaction
UIDAI
0210 message (from Issuer to NPCI)
Data Value Comment
element
12 HHMMSS Time
13 MMDD Date
15 MMDD Settlement Date (optional)
DDD Julian Date
HH-Hour
39 00 Success response code
54 Amount Account Balance
UIDAI
0210 message (from NPCI to Acquirer)
Data Value Comment
element

12 HHMMSS Time
13 MMDD Date
DDD Julian Date
HH-Hour
UIDAI
7.4 Message dump for Interbank Cash Withdrawal

Data Value Comment
Element
3 010000 Processing code fixed for CW
4 Amount Withdrawal amount
12 HHMMSS Time
13 MMDD Date
DDD Julian Date
HH- Hour
transaction
Data Value Comment
Element


12 HHMMSS Time
13 MMDD Date
DDD Julian Date
HH- Hour
transaction
UIDAI
Data Value Comment
Element
12 HHMMSS Time
13 MMDD Date
DDD Julian Date
HH-Hour
UIDAI
Data Value Comment
element
2 IIN + AADHAAR Beneficiary details
12 HHMMSS Time
13 MMDD Date


DDD Julian Date
HH-Hour
UIDAI
7.5 Message dump for Interbank Cash Deposit

Data Value Comment
Element
3 210000 Processing code fixed for CD
4 Amount Deposit amount
12 HHMMSS Time
13 MMDD Date
DDD Julian Date
HH- Hour
transaction
Data Value Comment
Element
12 HHMMSS Time

13 MMDD Date
DDD Julian Date
HH- Hour
transaction
UIDAI
Data Value Comment
element
12 HHMMSS Time
13 MMDD Date
DDD Julian Date
HH-Hour
UIDAI
Data Value Comment
element
12 HHMMSS Time
13 MMDD Date
DDD Julian Date

HH-Hour
UIDAI
7.6 Message dump for Interbank Fund Transfer Transaction
0200 message (from Remitter Bank to NPCI)

Data Value Comment
element
3 900000 Processing code fixed for FT
4 Amount Transfer amount
12 HHMMSS Time
13 MMDD Date
22 019 Manual (01) Reserved for private use (9)
32 ACQ Inst ID Temporary ID already allotted by NPCI
DDD Julian Date
HH-Hour
transaction
102 Sender Account Detail Optional
120 00100245002003UID045020<Sender Tag 001 Length 002 45
Name>060019IIN+ AADHAAR no. Tag 002 Length 003 UID
Tag 045 Length 020 - <Sender Name>
(optional)
Tag 060 Length -019 IIN + AADHAAR
0200 message (from NPCI to Beneficiary)
Data Value Comment
element
12 HHMMSS Time

13 MMDD Date
18 6012/6010 6012 for Micro ATM and 6010 for POS
22 019 Manual (01) Reserved for private use (9)
DDD Julian Date
HH- Hour
transaction
102 Sender Account detail Optional
Name>060019IIN+ AADHAAR no. Tag 002 Length 003 UID
Tag 045 Length 020 - <Sender Name>
(optional)
0210 message (from Beneficiary to NPCI)
Data Value Comment
element
12 HHMMSS Time
13 MMDD Date
DDD Julian Date
HH- Hour
102 Sender Account Detail Optional
103 Beneficiary Account Detail Optional
Name>046020<Beneficiary Tag 002 Length 003 UID
Name>060019IIN+ AADHAAR no. Tag 045 Length 020 - <Sender Name>
(optional)
Tag 046 Length 020 - <Beneficiary Name>
(optional)
0210 message (from NPCI to Remitter)
Data Value Comment
element


12 HHMMSS Time
13 MMDD Date
DDD Julian Date
HH- Hour
102 Sender Account detail Optional
Name>046020<Beneficiary Tag 002 Length 003 UID
Name>060019IIN+ AADHAAR no. Tag 045 Length 020 - <Sender Name>
(optional)
Tag 046 Length 020 - <Beneficiary Name>
(optional)
7.7 Message dump for Reversal request
0420 message (From Acquirer to NPCI)

Data Value Comment
element
3 Processing Code Processing code for original transaction
4 Amount Original transaction amount
12 HHMMSS Time
13 DDMM Date
DDD Julian Date
HH - Hour
39 00 Response code
transaction
90 Valid values Original transaction data

102 Valid values FROM Account

0420 message (From NPCI to Issuer)
Data Value Comment
element
12 HHMMSS Time
13 DDMM Date
DDD Julian Date
HH - Hour
39 00 Response code
transaction
0430 message (From Acquirer to NPCI)
Data Value Comment
element
2 IIN + AADHAAR no. Customer s AADHAAR no.
12 HHMMSS Time
13 DDMM Date
DDD Julian Date
HH - Hour
39 00 Response code
transaction

0430 message (From NPCI to Issuer)

Data Value Comment
element
2 IIN + AADHAAR no. Customers AADHAAR no.
12 HHMMSS Time
13 DDMM Date
DDD Julian Date
HH - Hour
39 00 Response code
transaction

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

BC Name: Agent Id:
Customer Name:
STAN:
RRN:
UIDAI Auth. Code:
Transaction Amount:
A/C Balance:

3. Receipt format for Fund Transfer
Bank Name and Logo
Fund Transfer

BC Name: Agent 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

BC Name: Agent 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

BC Name: Agent Id: This block must be filled by
BC Location: Terminal Id: MicroATM values
Customer Name:
STAN:
RRN:
UIDAI Auth. Code: This block must be filled by
Transaction Status: Successful(00)/Decline(response code) Acquirer bank switch values
Transaction Amount:
A/C Balance:

6. Format for LTS Request Electronic log
Bank Name
LTS Electronic Log

BC Name: Agent Id: This block must be filled by
BC Location: Terminal Id: MicroATM values
Customer Name:
STAN:
RRN:
UIDAI Auth. Code: This block must be filled by
Transaction Status: Successful(00)/Decline(response code) Acquirer bank switch values
Transaction Amount:
A/C Balance:
7. Format for Reversal Electronic log
Bank Name
Reversal Electronic Log

BC Name: Agent Id:
BC Location: Terminal Id: This block must be filled by
Customer Aadhaar No: MicroATM values
Customer Name:
STAN:
This block must be filled by
RRN:
Acquirer bank switch values

9.0 Changes in v2.7 from v2.6.1
Version 2.7 Version 2.6.1

MicroATM user interface changes suggested to MicroATM user interface carries 12 digit
carry 12 digit AADHAAR number in three text AADHAAR number in 1 text box for all transaction
boxes for all transaction types types
MicroATM user interface changes suggested to Customer had to select in MicroATM while filling
pre-select Remitter bank name in fund transfer transaction details
transaction
MicroATM to generate receipt for selective Receipt was generated only for successful
decline transactions along with response code transactions
received from acquirer switch.
Implementation of Verhoeff algorithm Implementation of Verhoeff algorithm was not

recommended to check AADHAAR number is valid specified
or not
Addition of DE-54 in Message dumps. In an DE-54 was not present in message dumps
interbank transaction issuer bank must send
account balance in DE 54
DE-4 and DE-49 made Conditional. These need to DE-4 and DE-49 were mandatory all type of
be send only if processing code in DE-3 is other transaction.
than 10 00 00
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 Description of DE 11 was not updated

unique for every transactions
Description of DE-1, DE-4, DE-7, DE-11, DE-12, Not Available

DE-13, DE-15, DE-41, DE-90 added
Revised the description of DE-39, DE-43, DE-49, As per then available information
DE-54, DE-70 and DE-120
Revised the settlement and reconciliation table As per then available guidelines
Introduced message dump for reversal messages Not Available

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

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

Message on MicroATM will now also display error Message on MicroATM did not had error codes
code in brackets displayed
Added new error codes introduced by UIDAI Not Available

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

AADHAAR ENABLED

Date Version Change

OFFUS ready Message dump & Receipt Format Updated

Description of all required Data Element introduced Updated

Changes recommended for MicroATM Application Introduced

Prepared By: Date

Ruchir Asthana 26-01-12

Reviewed By: Date

Approved By: Date

National Payments Corporation of India [Type of Document: Confidential] Page 2 of 55

1.0 Introduction ..................................................................................................................... 4

National Payments Corporation of India [Type of Document: Confidential] Page 3 of 55

1.1 Executive Summary

1.2 Scope of this document

National Payments Corporation of India [Type of Document: Confidential] Page 4 of 55

2.0 AADHAAR Implementation for FI Architecture

2.1 Architecture Diagram and Brief

Following is the Transaction Set,

The following diagrams present a snapshot of these transactions:

National Payments Corporation of India [Type of Document: Confidential] Page 5 of 55

National Payments Corporation of India [Type of Document: Confidential] Page 6 of 55

Details Onus Flow (only authentication)

MicroATM Application Requirement:

National Payments Corporation of India [Type of Document: Confidential] Page 7 of 55

Details - Off us flow for Funds Transfer:

MicroATM Application Requirement:

National Payments Corporation of India [Type of Document: Confidential] Page 8 of 55

Flow diagram of AEPS fund transfer transaction:

Fund transfer explained:

2. In order to facilitate debit leg, NPCI provides biometric authentication service.

National Payments Corporation of India [Type of Document: Confidential] Page 9 of 55

National Payments Corporation of India [Type of Document: Confidential] Page 10 of 55

MicroATM Application Requirement:

2.2 Interface Specification

2.2.1 System Definitions

2. Bank will act as client and NFS will act as server.

2.2.2 Data element processing rules

Correctly populate DE-63 with UID Bio metric data.

National Payments Corporation of India [Type of Document: Confidential] Page 11 of 55

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

2.2.3 Message format

Message Types and Corresponding Data Elements

2.2.3.1 Administrative Messages

Network Management Messages

MTID Data Element 0800 0810

National Payments Corporation of India [Type of Document: Confidential] Page 12 of 55

48 Key Data (Optional Dynamic C* -

so bank should off the bit corresponding to DE 48 in the bitmap.

2.2.3.2 Financial Messages

2 Primary Account Number M M+

41 Card acceptor terminal ID M M+

National Payments Corporation of India [Type of Document: Confidential] Page 13 of 55

49 Currency code, transaction C C+

2.2.3.3 Reversal Messages

National Payments Corporation of India [Type of Document: Confidential] Page 14 of 55

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

Field Edits None.

DE-2 Primary Account Number, PAN

Usage: It is mandatory for all 02xx, 04xx messages.

Constraints: C: Element is present if DE-35 (Track2) is not present.