AEPS Interface Specifications Version 5.2 - 20042018 PDF

AADHAAR ENABLED PAYMENT SYSTEM
(AEPS) INTERFACE SPECIFICATION

[AADHAAR ENABLED PAYMENT SYSTEM INTERFACE SPECIFICATION 5.0]
Document Details
Author AEPS Technology
Published Date 02-10-13
Version 5.2
Total Page number 100
Document classification Confidential
Document History
Date Version Changes

Changes in DE#62 format as all BFD transactions will be
routed to NPCI Middleware server where bank will be directly
02/10/2013 4.0 connected. BFD receipt formats added.
03/06/2014 4.1 Internal release

23/06/2014 4.2 Internal release
24/07/2014 4.3 Minor corrections.
Added architecture diagram for direct Middleware connection.
Details on Micro ATM generated reversal added.
Message dump for FT transaction further clarified.
09/04/2015 4.4 Changes in DE#62 format to allow sending action code from
UIDAI to both acquirer and issuer bank.
NPCI host to host error codes added.
Minor corrections made.
28/08/2015 4.5 Minor corrections
29/07/2016 4.6 IRIS authentication for ISO and Revised Cash deposit
transaction flow
10/01/2017 4.7 New Transaction type “Purchase” introduced as part of AEPS
Merchant transaction
24/01/2017 4.7.1 Cash Deposit 2 legs solution removed and Cash Deposit
Interim solution incorporated
30/01/2017 5.0 Authentication 2.0 changes incorporated
20/04/2017 5.0 Authentication 2.0.1 changes incorporated
16/05/2017 5.0.1 Additional data elements added to accommodate the increased

PID size post Auth 2.0 changes
10/07/2017 5.1 With changes in DE 41 tid & Auth 2.0 changes for Demographic
authentication
21/03/2018 5.2 Revised cash deposit transaction flow in AePS Offus and
adding verification leg for cash withdrawal & Merchant pay
National Payments Corporation of India [Type of Document: Confidential] Page 2 of 100


Table of Contents
CHAPTER 1. INTRODUCTION ........................................................................................................... 6
SECTION 1.01 EXECUTIVE SUMMARY .......................................................................................................6
SECTION 1.02 SCOPE & AUDIENCE OF THIS DOCUMENT .........................................................................6
CHAPTER 2. AADHAAR IMPLEMENTATION FOR FI ARCHITECTURE ....................................... 7
SECTION 2.01 ARCHITECTURE DIAGRAM AND BRIEF ...............................................................................7
SECTION 2.02 DETAILS OF INTRA-BANK TRANSACTION ...........................................................................7
SECTION 2.03 DETAILS OF INTER-BANK TRANSACTIONS.........................................................................8
SECTION 2.04 AADHAAR TO AADHAAR FUND TRANSFER TRANSACTION ................................................9
SECTION 2.05 DETAILS OF INTERBANK CASH DEPOSIT TRANSACTION .................................................12

LEG 1 - ACCOUNT VALIDATION LEG PROCESS ...........................................................................................................13
LEG 2 – CASH DEPOSIT ADVICE TRANSACTION – CDA PROCESS FLOW ............................................................15
SECTION 2.06 DETAILS OF MINI STATEMENT .........................................................................................17
SECTION 2.07 DETAILS OF DEMOGRAPHIC AUTHENTICATION ...............................................................17
SECTION 2.08 BEST FINGER DETECTION ...............................................................................................17
CHAPTER 3. INTERFACE SPECIFICATION .................................................................................. 18
SECTION 3.01 SYSTEM DEFINITIONS ......................................................................................................18
SECTION 3.02 DATA ELEMENT PROCESSING RULES...............................................................................18
SECTION 3.03 MESSAGE FORMAT ..........................................................................................................20
SECTION 3.04 ADMINISTRATIVE MESSAGES...........................................................................................20
SECTION 3.05 FINANCIAL MESSAGES.....................................................................................................21
SECTION 3.06 ADVICE MESSAGE ...........................................................................................................22
SECTION 3.07 REVERSAL MESSAGES ....................................................................................................23
SECTION 3.08 DATA ELEMENT DEFINITIONS ..........................................................................................24
CHAPTER 4. CHANGES FOR MEMBER BANKS ........................................................................... 53
SECTION 4.01 CHANGES FOR ACQUIRER MEMBERS .............................................................................53

SECTION 4.02 CHANGES FOR ISSUER MEMBERS ...................................................................................54
SECTION 4.03 CHANGES IN NPCI SYSTEMS ..........................................................................................54
CHAPTER 5. SETTLEMENT AND RECONCILIATION ................................................................... 55
CHAPTER 6. RISK MANAGEMENT ................................................................................................. 55
SECTION 6.01 CHECKS BY ISSUER BANKS: ............................................................................................55
SECTION 6.02 CHECKS BY ACQUIRER BANKS: .......................................................................................56

CHAPTER 7. EXCEPTION CONDITIONS ....................................................................................... 57
CHAPTER 8. MESSAGE DUMP ....................................................................................................... 58
SECTION 8.01 MESSAGE DUMP FOR NETWORK MESSAGES ..................................................................58
SECTION 8.02 MESSAGE DUMP FOR BIOMETRIC AUTHENTICATION.......................................................59
SECTION 8.03 MESSAGE DUMP FOR DEMOGRAPHIC AUTHENTICATION ................................................61
SECTION 8.04 MESSAGE DUMP FOR INTERBANK BALANCE ENQUIRY....................................................63
SECTION 8.05 MESSAGE DUMP FOR INTERBANK CASH WITHDRAWAL ..................................................66
SECTION 8.06 MESSAGE DUMP FOR INTERBANK PURCHASE.................................................................70
SECTION 8.07 MESSAGE DUMP FOR INTERBANK CASH DEPOSIT ..........................................................74
SECTION 8.07.01 MESSAGE DUMP FOR BENEFICIARY ACCOUNT VALIDATION ..........................................74
SECTION 8.07.02 MESSAGE DUMP FOR CASH DEPOSIT ADVICE ...............................................................77
NOTE: ...........................................................................................................................................................79
SECTION 8.08 MESSAGE DUMP FOR INTERBANK FUND TRANSFER .......................................................80
SECTION 8.09 MESSAGE DUMP FOR INTERBANK MINI STATEMENT .......................................................84
SECTION 8.10 MESSAGE DUMP FOR REVERSAL MESSAGE...................................................................89
SECTION 8.11 MESSAGE DUMP FOR BFD TRANSACTION .....................................................................92
CHAPTER 9. RECEIPTS AND LOGS FORMATS ........................................................................... 94
SECTION 9.01 BFD .................................................................................................................................94
SECTION 9.02 CASH WITHDRAWAL ........................................................................................................95
SECTION 9.03 PURCHASE OF GOODS ....................................................................................................96
SECTION 9.04 CASH DEPOSIT ................................................................................................................96
SECTION 9.05 FUND TRANSFER .............................................................................................................97
SECTION 9.06 BALANCE ENQUIRY ..........................................................................................................97
SECTION 9.07 DEMOGRAPHIC AUTHENTICATION ...................................................................................98
SECTION 9.08 MINI STATEMENT .............................................................................................................98
SECTION 9.09 FORMAT FOR ORIGINAL TRANSACTION ELECTRONIC LOG .............................................99
SECTION 9.10 FORMAT FOR LTS REQUEST ELECTRONIC LOG .............................................................99
SECTION 9.11 FORMAT FOR REVERSAL ELECTRONIC LOG ..................................................................100
CHAPTER 10. TRACK OF CHANGES ..............................................................................................100

Chapter 1. Introduction
Section 1.01 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 UIDAI 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 based
payment 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.
Section 1.02 Scope & Audience 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), it also captures details
of message dumps for various transactions supported in the AEPS product. Sample receipt formats
are also part of the scope of this document to help the MicroATM application vendors.
This document is a property of NPCI and should be not be circulated to external party without prior
approvals of NPCI management team.

Chapter 2. AADHAAR Implementation for FI Architecture
Section 2.01 Architecture Diagram and Brief

NPCI switch is enhanced to support Interbank AEPS Transactions. For On-Us Transactions, only the
authentication support will be provided based on the request from the originator bank.
Following is the Transaction Set:
1. Cash Withdrawal
2. Balance Enquiry
3. Cash Deposit
4. Funds Transfer
5. Demographic Authentication
6. Biometric Authentication
7. Best Finger Detection
8. Mini Statement
9. Purchase
Section 2.02 Details of Intra-Bank Transaction

In case bank desires to leverage NPCI AEPS interface for UIDAI authentication, the transaction flow
is given below. The transaction for biometric verification will be sent with required fields to UIDAI and
verification result from UIDAI will be sent back to the bank.

Summary of 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 is valid or not.
3. Micro ATM application must support Dual Finger functionality (Fusion finger). This is a
mandatory requirement on the Micro ATM application.
4. Micro ATM Application must support Magnetic stripe Card based transactions. Customer
Aadhaar number and IIN number must be read from the Track I on the card for card based
transactions.
Section 2.03 Details of Inter-Bank Transactions
The transaction flow depicted above is for Balance Enquiry, Cash Withdrawal, Mini Statement
and Purchase transactions acquired on Acquirer bank terminal for Issuer bank customers.

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.
applied for checking that the AADHAAR number is valid or not.
3. Micro ATM application must support Dual Finger functionality (Fusion finger). This is a
mandatory requirement on the Micro ATM application.
transactions.
Section 2.04 Aadhaar to Aadhaar Fund Transfer Transaction
1. The transaction flow depicted above is for funds transfer from customer account of Remitter
Bank to customer account of Beneficiary Bank where the transaction is initiated on Remitter
bank’s terminal. In fund transfer transaction, customer has to visit his/her home bank BC.
Thus, remitter bank is the same as Issuer and Acquirer bank.

2. If a member bank is taking authentication service from NPCI, then the fund transfer
transactions will be a two-step process consisting of 2 legs i.e. authentication leg and credit
leg.
i. For processing authentication leg, NPCI provides authentication service where in only
authentication transaction is sent to NPCI and after the response of the same
remitter’s account is debited.
ii. Credit leg should be sent to NPCI. (Refer to message dump for authentication
transaction and fund transfer credit leg transaction).
3. Online Authentication and Online credit is envisaged in this transaction and beneficiary
bank is expected to respond with beneficiary’s Aadhaar number and name in the response
message.
4. Once the debit to sender account is successful a remittance transaction is sent to NPCI.
The context of both authentication and fund transfer transaction will be maintained by the
acquirer.
5. In case of authentication request, DE#2 should carry the remitter’s AADHAAR number
(Sender AADHAAR number)
6. For credit leg, DE#2 will contain the beneficiary AADHAAR number; DE#120 will contain
the sender AADHAAR Number. The description of DE#120 is detailed in Data Element
Definition section.
7. In case, remitter bank receives Response Code ‘91’ or there is no response from NPCI,
the debit should be put on hold or parked in pooling account till reconciliation is done with
beneficiary bank. For all other decline scenarios the debit should be reversed. In case of
any dispute, the same will be handled through Dispute Management System (DMS)
provided by NPCI.
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 and customer readability in case of manual
entry.
applied for checking that the AADHAAR number entered is valid or not.
3. The MicroATM application MUST ensure that the Beneficiary’s Aadhaar number is entered
twice by the remitter 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 receiver’s Aadhaar number is entered correct as is
the practice while making online payments.
4. A Fund transfer transaction needs to be initiated on the home bank BC terminal only and
thus the remitter bank name or IIN should be pre-populated avoid manual entry/selection
mistake.
transactions.

Section 2.05 Details of Interbank Cash Deposit Transaction

Current Solution:
1. Micro ATM will send the request message to Acquiring Bank switch
2. Acquiring switch will Post the debit leg to acquirer bank CBS
3. CBS will respond with success/decline status to acquirer switch
4. Acquirer switch will send Cash deposit request to NPCI if transaction is success/ acquirer
switch will send the response back to terminal if CBS decline the transaction.
5. NPCI will send authentication request to UIDAI with required details received in request from
acquirer.
6. UIDAI will send the response to NPCI
7. NPCI will forward the request to issuer bank switch based on the success response /
transaction will returned to acquirer if UIDAI declines the authentication.
8. Issuing bank switch will post the credit leg to customer account in issuing bank CBS
9. CBS will respond with success/decline status to issuer switch.
10. Issuing Switch will send the response back to NPCI
11. NPCI will forward the response message to Acquiring switch
12. Acquiring switch send the response to Terminal if transaction is successful/ acquiring switch
will post the reversal if transaction is declined and send the response to terminal

Note:
1) If transaction is failed in 7th leg due to decline from UIDAI, acquirer has to follow the
process from 12th leg. i.e acquiring switch will post the reversal if transaction is declined
and send the response to terminal
2) Reversal will remain same.
Revised Cash deposit Solution:
LEG 1 - Account Validation Leg Process
1. BC collect the cash from the customer and initiates the Cash Deposit Request
Message through Micro ATM with Aadhaar , Bank Name, Amount & Biometric
details.
2. Micro ATM will send the request message to Acquiring Bank switch
3. Acquiring switch will send Beneficiaries Account Validation Request (BAV) message
to NPCI Switch.
4. NPCI Switch will send the request message to UIDAI for biometric authentication.
5. Upon receiving success response from UIDAI, NPCI will generate Deposit ID for the
purpose of Leg 1 & Leg 2 matching.
6. NPCI will send the beneficiaries account validation request message (Which
includes the Deposit ID) to Issuing bank switch.
7. Issuing bank switch sends the validation request message to CBS.

8. CBS validates all the parameters including the amount and sends the response
message to Issuing Bank Switch. CBS will ensure all the account level validations are
done and the account is in good state to accept the deposit amount.
8.1 If the validations are successful, CBS will send successful response along with
Beneficiary Name and authorization identification code.
8.2 If validations are not successful, decline response will be sent indicating that
the deposit is not to be accepted.
9. Issuing Bank Switch will send the response back to NPCI.
10. NPCI switch will forward the response message to Acquiring switch (along with
Deposit ID & Beneficiary Name).
11. Acquiring switch send debit request message to BC account in acquirer CBS.
12. BC account will be debited and response comes back to acquiring switch.
13. Acquiring switch sends the APPROVED response to Micro ATM, MICRO ATM prints
the charge slip which will be handed over to the customer for reference. BC should
retain the cash with him post leg 13 success.
NOTE:
 If BAV response code indicates unsuccessful, BC terminal will not initiate ‘Cash
Deposit Advice’ CDA. CDA should be initiated, If BAV response code is successful.
Beneficiary Name may be printed on charge slip.
 If acquirer switch times out with NPCI switch OR receives decline response from
NPCI switch for BAV, BC account should not be debited and the response code sent
back to terminal will have appropriate response code to indicate the ‘Beneficiary
Account Validation’ (BAV) has failed so that BC returns the cash to customer.
 If BC terminal times out/Disconnect (90 Secs is time out) with acquirer switch after
sending the ‘Beneficiary Account Validation’ request, it may send ‘Verify BAV’
request containing key elements that were part of BAV request to acquirer switch.
Acquirer switch will check the status of BAV (within acquirer switch and this does
not involve NPCI switch) and respond back to terminal with the response of BAV. If
BAV status indicates decline/not-processed, BC must return the cash to customer
else BC terminal can initiate ‘Cash Deposit Advice’ (CDA) to acquirer switch.
 Terminal can attempt up to three times the ‘Verify BAV’ repeats to acquirer switch
and all are times out, BC agent should return the cash to customer.

Leg 2 – CASH DEPOSIT ADVICE TRANSACTION – CDA PROCESS

FLOW
14. Micro ATM sends Cash Deposit Advice (CDA) message (0220 MTI containing key
matching fields which include Aadhaar number, deposit amount, Deposit ID and
authorization identification code as received in BAV response) to acquiring switch.
Acquiring switch will validate the CDA advice against the corresponding BAV in its
database and ensures there is a successful BAV present and immediately respond
with 0230(Success) to Micro ATM. If there is no valid BAV present in acquiring switch,
it will decline the CDA and the transaction should be settled in DMS.
15. If there is valid BAV present in acquiring switch, acquiring switch will send the CDA
advice (0220 MTI) to NPCI switch. NPCI switch will validate the CDA advice, apart
from mandatory/conditional data elements presence, against the corresponding
BAV in it’s database and ensure that there is a successful BAV present (within the
same business day) for the combination of Acquirer ID, Terminal ID, Aadhaar -
number, deposit amount, Deposit ID and authorization identification code. If there is

no valid BAV present in NPCI switch, NPCI switch will decline the CDA to acquiring
switch.
Note: In case acquiring switch to NPCI switch connection is down/signed off while
processing the CDA advice (0220 MTI), acquiring switch will play it as store and forward
(SAF) whenever the connection is up and acquirer gets signed on with NPCI switch.
16. In case of successful CDA acceptance by NPCI switch, NPCI switch will forward the
CDA advice (0220 MTI) to issuing switch as a SAF advice.
17. Issuing switch validates the CDA against BAV and sends the cash deposit request
message to CBS and sends advice response to NPCI.
Exception Scenarios:
 Terminal time out for CDA advice processing – When BC terminal does not receive
the response within time from acquirer switch for CDA advice (0220 MTI), it will
initiate the CDA advice repeat (0221 MTI). Terminal will not allow next transaction
and it will keep posting CDA advice (piggy back), till 0230 received from acquirer
switch.
 Acquirer time out for advice processing - When acquirer switch does not receive the
response within time from NPCI switch for CDA advice (0220 MTI), it will initiate the
CDA advice repeat (0221 MTI). Repeats will be initiated by the acquirer switch for a
maximum of three times.
Note: If acquirer switch does not receive response for CDA advice and repeats and if
the cash deposit is not settled by NPCI in the subsequent settlement cycles, acquirer
bank can initiate ‘Credit Adjustment’ in NPCI DMS (back office system) and the
dispute lifecycle associated with credit adjustment will apply in such cases.
 NPCI switch time out for CDA advice processing - When NPCI switch does not receive
the response within time from issuer switch for CDA advice (0220 MTI), it will initiate
the CDA advice repeat (0221 MTI). Repeats will be initiated by the NPCI switch for a
maximum of three times.

Note : Successfully accepted cash deposits by NPCI switch will be settled by NPCI in
the next settlement cycle. In case issuer has not processed the cash deposit
advice/repeat received from NPCI during online, issuer will post the transaction to
customer account basis the raw data and settlement from NPCI.
 Issuer decline for CDA advice processing - Even if issuer switch sends decline
response for CDA advice, NPCI will settle the cash deposit as part of settlement cycle.
Issuer may raise a debit adjustment in DMS in case of disputes.
Section 2.06 Details of Mini Statement

A mini statement transaction will help a customer track his previous transactions. It is expected
from banks to also display customer actual balance on the receipt. Intra-bank mini statement
transaction will be same as other transaction wherein only authentication request shall come to
NPCI with transaction code 10.
Section 2.07 Details of Demographic Authentication

A Demographic Authentication helps bank to verify the name, gender, date of birth & Address
details of its customer. In this regard, transaction code will be 12. The MicroATM application must
ask for above details when Demographic Authentication transaction is being selected. The data
can be fetched by reading bar code or QR code printed on Aadhaar letter through a reader or by
manually entering the same. However, manually entering the data may be avoided as it may lead
to errors. The MicroATM application should place customer details in respective fields of PID as
per UIDAI Authentication API released from time to time.
Section 2.08 Best Finger Detection

UIDAI has come up with the BFD service by using which the resident will be apprised of the finger
providing the best accuracy and successful matching results. We shall refer to this finger with
best accuracy as the best finger. Resident may possess one or more best fingers. This knowledge
allows the resident to provide his/her best finger(s) during authentication thereby increasing the
chances of successful match.
This interface specification supports BFD transaction. Bank must send 10 finger data within data
element 111 to 119. The transaction type for BFD transaction is 11.
Please refer data element definition for more details.

Chapter 3. Interface Specification

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

Following points should be noted while developing the interface,
1. Bank Systems and NPCI-UIDAI systems will be connecting to each other using socket
connections.
2. Bank will act as client and NPCI will act as server.
3. Banks will be responsible to generate the Logon (0800 message type) message after every
successful TCP socket connection. Banks should also generate Logon messages at the
interval of every 5 minutes.
4. NPCI will generate cut over message (0800 message type) at 23:00 indicating business
date change over.
5. Both Banks and NPCI can generate Logon (800 message type) messages and they should
be responded with 810 messages by the recipient.
6. Banks and NPCI will also generate Echo message (0800 message type) for keep alive
during no transaction time. Ideal interval for the same is 3 minutes.
7. Message Header – 2 bytes binary (value containing length of the message excluding
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.
Section 3.02 Data element processing rules

1. Acquirer/Remitter
i. Correctly populate DE#2 comprising of IIN (6 digits IIN), 0 as identifier and 12 digit
AADHAAR number
ii. Correctly populate DE#18, DE#22, DE#42, DE#43 and DE#126 based on the data
supplied by Acquiring touch point (MicroATM)
iii. Correctly populate DE#111 to DE#119 with Personal Identity data (Biometrics or
demographics or both) of customer.

iv. Populate DE#120 with Sender’s name for Fund transfer transactions only
v. Populate DE# 126& 127 .
vi. For BFD transaction, The bank which is originator of the request must be able to:
a. Populate the Finger Print data in the data elements from DE#111 to DE#119.
vii. Populate attribute mc value in DE# 123 to DE# 125.
viii. Echo back Deposit ID, Beneficiary Name in DE #120 only for Cash Deposit
transaction.
2. NPCI
i. NPCI must be able to receive and process message containing DE#2, DE#111 to
DE 119, DE#120, DE#126 and DE#127.
ii. For BFD transactions, NPCI must be able to receive and process messages
containing DE#3, DE#111 to DE#119.
iii. Populate DE#120 with Deposit ID for Cash Deposit transactions only
iv. Process attribute mc value in DE# 123 to DE# 125 received from acquirer bank.
3. UIDAI
UIDAI must validate Biometric data and respond with appropriate reason code. For BFD
transaction UIDAI must Validate Biometric data and respond with ranking of each finger.
4. Issuer/Beneficiary
i. The Recipient must be able to receive and process messages containing DE#2,
DE#22, DE#62 and DE#120.
ii. For all successful transactions, account balance of customer must be present in
DE#54.
iii. 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.
iv. In fund transfer transactions, Recipient must populate DE#103 with Beneficiary
account number and DE#120 with Beneficiary’s name in the response message.
v. Echo back Deposit ID in DE#120

Section 3.03 Message format

TCP header should be in Hex with a length of two bytes. Bitmap should be Hex representation
of binary value with a length of 16 bytes.
All message format definition tables use the symbols defined in the following table:
Message Types and Corresponding Data Elements
Symbol Meaning
M Mandatory.
M+ Mandatory, echoed from request.
C Conditional.
C+ Conditional, echoed from request.
C* Conditional, value may change.
O Optional.
O+ Optional, echoed from request.
R Reserved for future use.
- Not used.
Section 3.04 Administrative Messages
Network Management Messages
MTID Data Element 0800 0810

1 Secondary bitmap M M+
7 Transmission date/time (GMT) M M+
11 STAN M M+
39 Response code - M
48 Key Data (Optional– Dynamic Key Exchange) C* -
64 MAC Code(Optional– MACing) R R
70 NMIC M M+
128 MACCode2(Optional– MACing) R R
 DE 48 as per NPCI standards should be Conditional. Since, AEPS does not use dynamic key
exchange so bank should off the bit corresponding to DE 48 in the bitmap.

Section 3.05 Financial Messages
Financial Messages
MTID Data Element 200 210
1 Secondary bitmap M C
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 (GMT) M M+
11 STAN M M+
12 Time, local transaction (IST) M M+
13 Date, local transaction (IST) M M+
15 Date, settlement C C+
18 Merchant type M -
22 POS entry mode M -
25 POS condition code M -
32 Acquirer institution ID M M+
37 Retrieval Reference Number M M+

38 Authorization identification code - C
41 Card acceptor terminal ID M M+
42 Card acceptor ID M M+
43 Card acceptor name/location M M+
49 Currency code, transaction C C+
54 Additional amounts - C
62 UIDAI Authentication Code& finger rank data C C
90 Original data element - -
102 Account 1 identification C C+
111-119 Finger print, Demographic, BFD or IRIS Data C -
120 Additional Data C C+
123-125 mc attribute value C -
126 Additional Data (Uses,udc, type, rdsid, rdsver, dpid, dc, C -
mi, mc)
127 Additional Data(skey, ci, Hmac, ac, sa ,lk, rc="") C -

Section 3.06 Advice Message
Financial Messages
MTID Data Element 0220/0221 0230
1 Secondary bitmap M C
2 Primary Account Number M M+
3 Processing code M M+
4 Amount, transaction M M+
5 Amount, settlement C C+
7 Date/time, transmission (GMT) M M+
11 STAN M M+
12 Time, local transaction (IST) M M+
13 Date, local transaction (IST) M M+
15 Date, settlement C C+
18 Merchant type M -
22 POS entry mode M -
25 POS condition code M -
32 Acquirer institution ID M M+
37 Retrieval Reference Number M M+

38 Authorization identification code M M+
41 Card acceptor terminal ID M M+
42 Card acceptor ID M M+
43 Card acceptor name/location M M+
49 Currency code, transaction C C+
54 Additional amounts - C
120 Additional Data C C+

Section 3.07 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 (GMT) 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 (IST) M M M+
13 Date, local transaction (IST) M M M+
14 Date, expiration - - -
15 Date, settlement C C C+
18 Merchant Category Code M M -
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+
37 Retrieval reference number M M M+
38 Authorization identification code C C C
39 Response code M M M
41 Card acceptor terminal ID M M -
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 - - -
64 MAC code R R R
90 Original data element M M M+

Reversal Messages
MTID Data Element 0420 0421* 0430

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 0421 messages will be sent 3 times after logon message is received from issuer
bank if NPCI fails to get response of 0420 messages.
 Acquirer switch has to send Repeat Reversal 0421 messages 3 times after successful logon
message is exchanged with NPCI if Acquirer switch fails to get response of 0420 messages.
Section 3.08 Data Element Definitions
DE#1 Secondary 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.
Constraints: Conditional ‘C’. It is present only if message contains any of the 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. Length of this field is 19

digits. In a card present scenario, DE#2 should be formed by picking IIN & Aadhaar number from
track 1 data present in magnetic stripe.
Field Edits: For all other transactions (including authentication transaction) except FT transaction,
this field should have initiator’s AADHAAR number. But for FT transaction, this field should have
beneficiary’s AADHAAR number.
Constraints: It should be echoed in response.
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 Cash Deposit
22 Credit adjustment
31 Balance inquiry
32 Beneficiary Account Validation
90 Fund Transfer with DE#120 tag value 001 as 45
90 Mini Statement with DE#120 tag value 001 as 07
11 Best Finger Detection
12 Demographic Authentication
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
* Other values may be used for optional features.
* Revised Cash Deposit advice message for Cash Deposit Advice also populates 21 as Pcode.
Field Edits: None

DE#4 Amount, Transaction
Format: Fixed
Type: n12
Description: It is the amount of funds requested by the customer in the local currency of the
acquirer.
Note: The last 2 digits of the transaction amount denotes paisa
Field Edits: For a balance enquiry transaction, 0200 message should carry all zeroes in DE#4.
For all request with processing code 100000 bit corresponding to DE#4 must be off.
Ex: 000000000100 this means the transaction amount is Re 1/-
DE#7 Transmission 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. The value is transmitted in GMT/UTC.
Field Edits: The original date and time will be restored in the response.
Constraints: It should be echoed in response
DE#11 System 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 and it should not be all zeroes.
Field Edits: STAN is set by a message sender and echoed by the message receiver. It should not
be date or time or similar to DE7

DE#12 Local Transaction Time
Format: Fixed
Type: n6: 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.
Field Edits: This field remains the same for a particular transaction.
DE#13 Local Transaction Date
Format: Fixed
Type: n4: 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.
DE#15 Settlement Date
Format: Fixed
Type: n4: MMDD
Description: Settlement Date (DE#15) is the date (month and day) that funds will be transferred
between an acquirer and an issuer.
Field Edits: If present then it may be echoed in response.
Constraints: Conditional ‘C’. Field is present if:
a) Field DE#50 is present or
b) MTID is 0800 and DE#70 is 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
6011 – AADHAAR based ATM transaction
6010 – for regular POS device.
9399 – Government Services (Proposed for fair price shops in future) .
Field Edits: None
Constraints: It should not be echoed in response.
DE#22 Point of Service Entry Mode
Format: Fixed
Type: n3
Description: The code describes the way how 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.
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.

DE#32 Acquiring Institution Identification Code
Format: LLVAR
Type: n..11
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.
Field Edits: 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
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.
Field Edit: Value of HH should be derived from DE 12, value of DDD from DE 13, value of STAN
from DE 11. This field remains the same for a particular transaction.
Constraint: It should be echoed in response.

DE#38 Authorization Identification Response
Format: an6
This is a response identification number assigned by the authorizing institution. The number
should be unique for each transaction. Authorization Identification Response is mandatory for
approved transactions. For declined transactions DE#38 not required.
Field Edits: Only for approved transactions.
Constraint: None
DE#39 Response Code
Format: Fixed
Type: an2
Description: This code indicates the response 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: This value must be present for all response messages. In reversal messages,
appropriate code need to be populated.
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 defined under NPCI host to host specification.
Receipt
Response UIDAI
Description Status Required
Code Error Code
(Yes/No)
00 - APPROVED A Yes
M4 - NRE ACCOUNT D Yes
M6 - LIMIT EXCEEDED D Yes
UB 710 MISSING PI DATA AS SPECIFIED IN USES D No
UC 720 MISSING PA DATA AS SPECIFIED IN USES D No

UD 730 MISSING PIN DATA AS SPECIFIED IN USES D No
UE 999 UNKNOWN ERROR D No
UF 740 MISSING OTP DATA AS SPECIFIED IN USES D No
UG 800 INVALID BIOMETRIC DATA D Yes
UH 810 MISSING BIOMETRIC DATA SPECIFIED IN USES D No
UI - UIDAI TIME OUT D Yes
UJ 721 Missing PFA data specified in USES D No
UK 820 MISSING VALUE FOR BT ATT IN USES ELEMENT D No
UL 821 INVALID VALUE IN BT ATT IN USES ELEMENT D No
UM 901 NO AUTH FACTORS FOUND IN AUTH REQUEST D No
UN 902 INVALID DOB VALUE IN PI ELEMENT D No
UO 910 INVALID MV VALUE IN PI ELEMENT D No
UP 911 INVALID MV VALUE IN PFA ELEMENT D No
UQ 912 INVALID MS VALUE D No
UR 913 BOTH PA AND PFA ARE PRESENT D No
US 930 TECH ERROR 1-RELATED TO ABIS INTERACTION D No
UT 931 TECH ERROR 2- UID DB SERVER DOWN D Yes
UU 932 TECH ERROR 3 - XML ERROR D No
UV 980 UNSUPPORTED OPTION D No
UW - TRANSACTION AMOUNT EXCEED LIMIT D Yes
UY 511 INVALID PID XML FORMAT D No
UX - REQUEST OLDER THAN 24 hours D No
UZ 940 UNAUTHORIZED ASA CHANNEL D Yes
U0 941 UNSPECIFIED ASA CHANNEL D Yes
U1 100 PI BASIC ATTR DEMOGRAPHIC DID NOT MATCH D No
U2 200 PI ADDRESS ATTR DEMOGRAPHIC NOT MATCH D Yes
U3 300 BIOMETRIC DATA DID NOT MATCH D Yes
WA 330 BIOMETRICS LOCKED D Yes
U4 500 INVALID ENCRYPTION D No
U5 510 INVALID XML FORMAT D No
U6 520 INVALID DEVICE D Yes
U7 530 INVALID AUTHENTICATOR CODE D Yes
U8 540 INVALID Auth XML VERSION D No
U9 550 INVALID USES ELEMENT ATTRIBUTES D No
VA 571 PIN RETRIES RESET D Yes
VB 572 INVALID BIOMETRIC POSITION D Yes
VC 573 PI USAGE NOT ALLOWED AS PER LICENSE D No
VD 574 PA USAGE NOT ALLOWED AS PER LICENSE D No
VE 575 PFA USAGE NOT ALLOWED AS PER LICENSE D No

VF 576 FMR USAGE NOT ALLOWED AS PER LICENSE D No
VG 577 FIR USAGE NOT ALLOWED AS PER LICENSE D No
VH 578 IIR USAGE NOT ALLOWED AS PER LICENSE D No
VI 579 OTP USAGE NOT ALLOWED AS PER LICENSE D No
VJ 580 PIN USAGE NOT ALLOWED AS PER LICENSE D No
VK 581 FUZZY USAGE NOT ALLOWED AS PER LICENSE D No
VL 582 LOCAL LANGUAGE USAGE NOT ALLOWED AS PER D No
VM 934 TECHNICAL ERROR D No
VN 935 TECHNICAL ERROR D No
VO 936 TECHNICAL ERROR D No
VP 937 TECHNICAL ERROR D No
VQ 938 TECHNICAL ERROR D No
VR 939 TECHNICAL ERROR D No
VS 811 Missing Biometric data in UIDAI CIDR D Yes
VT 501 Invalid certificate identifier in “ci” attribute of “Skey” D No
VU 502 INVALID ENCRYPTION OF PID D No
VV 503 INVALID ENCRYPTION OF HMAC D No
VW 542 AUA NOT AUTHORIZED FOR ASA D Yes
VX 543 SUB-AUA NOT ASSOCIATED WITH "AUA" D Yes
VY 541 INVALID PID XML VERSION D No
VZ 311 Duplicate Irises used D No
V0 561 REQUEST EXPIRED D Yes
V1 562 INVALID TIME STAMP D No
V2 563 Duplicate Request D No
V3 564 HMAC VALIDATION FAILED D No
V4 565 AUA licence key expired D Yes
V5 566 ASA licence key expired D Yes
V6 567 INVALID INPUT D No
V7 568 UNSUPPORTD LANGUAGE D No
V8 569 DIGITAL SIGNATURE VERIFICATION FAILED D No
V9 570 INVALID KEY INFO IN DIGITAL SIGNATURE D No
W0 312 FMR & FIR IN 1 TXN D No
W1 313 MORE THAN ONE FINGER IN SINGLE FIR D No
W2 314 FMR/FIR EXCEED 10 D No
W3 315 IIR SHDNT EXCD 2 D No
W4 504 SESSION KEY EXPIRE D No
W5 812 BEST FNGR DTCTN NOT DONE D No
W6 310 DUPLICATE FING USED D No
W9 400 OTP VALIDATION FAILD D Yes

X1 505 SYNC KEY USE NOT ALLOWED D No
X2 521 INVALID FNGR DEVICE D Yes
X7 997 AADHAR NO STST LOST/DECEASED/NOT ACT D Yes
X8 998 AADHAR NO DOSENT EXIST IN CIDR D Yes
X9 996 Aadhaar Cancelled due to various reasons D Yes
WB 316 Number of FID should not exceed 1 D Yes
“txn” value did not match with “txn” value used in Request OTP
WC 402 D
API Yes
WD 512 Invalid resident consent in “rc” attribute of “Auth” D Yes
WF 524 Invalid mi code under Meta tag D Yes
WI 527 Invalid mc code under Meta tag D Yes
WL 586 FID usage not allowed as per license D Yes
WM 587 Name space not allowed D Yes
WN 588 Registered device not allowed as per license D Yes
WO 590 Public device not allowed as per license D Yes
WP 822 Invalid value in the “bs” attribute of “Bio” element within “Pid” D Yes
WQ 950 OTP store related technical error D Yes
WR 951 Biometric lock related technical error D Yes
WS 995 Aadhaar suspended by competent authority D Yes
WT 996 Aadhaar cancelled D Yes
WE 551 Invalid “tid” value. D Yes
WJ 553 Registered devices currently not supported D Yes
WK 554 Public devices are not allowed to be used D Yes
WG 555 rdsId is invalid and not part of certification registry D Yes
WH 556 rdsVer is invalid and not part of certification registry D Yes
WU 557 dpId is invalid and not part of certification registry D Yes
WV 558 Invalid dih D Yes
WX 559 Device Certificate has expired D Yes
WY 560 DP Master Certificate has expired D Yes
WZ 933 Technical error D Yes
01 - Refer to card issuer D Yes
02 - Refer to card issuer special D Yes
03 - Invalid merchant D Yes
04 - Pick-up D Yes
05 - Do not honor D Yes
06 - Error D Yes
07 - Pick-up card, special condition D Yes
08 - Issuer un-available D Yes
09 - Request in progress D Yes

10 - Approved for partial amount D No
11 - Approved (VIP) D No
12 - Invalid transaction D Yes
13 - Invalid amount D Yes
14 - Invalid card number D No
15 - No such issuer D Yes
16 - Approved, update track III D No
17 - Customer cancel D No
18 - Customer dispute D No
19 - Re-enter transaction D No
20 - Invalid Request/Response D No
21 - No action taken D No
22 - Suspected malfunction D No
23 - Unacceptable transaction fee D No
24 - File update not supported by receiver D No
25 - Unable to locate record on file D No
26 - Duplicate update, old record replaced D No
27 - File update field edit error D No
28 - File update file locked out D No
29 - File update failed D No
30 - Format Error D No
31 - Bank not supported by switch D No
32 - Completed partially D No
33 - Expired card, capture D Yes
34 - Suspected fraud, capture D Yes
35 - Card acceptor contact acquirer D Yes
36 - Restricted Card D Yes
37 - Card acceptor call acquirer security D Yes
38 - Allowable pin tries exceeded D Yes
39 - No credit account D Yes
40 - Requested function not supported D Yes
41 - Lost card, capture D Yes
42 - No universal account D Yes
43 - Stolen card, capture D Yes
44 - No investment account D No
51 - Insufficient funds D Yes
52 - No checking account D Yes
53 - No savings account D Yes
54 - Expired card D Yes

55 - Invalid PIN D Yes
56 - No card record D Yes
57 - Transaction not permitted to cardholder D Yes
58 - Transaction not permitted to terminal D Yes
59 - Suspected fraud D Yes
60 - Card acceptor contact acquirer D Yes
61 - Exceeds withdrawal amount limit D Yes
62 - Restricted card D Yes
63 - Security violation D Yes
64 - Original amount incorrect D Yes
65 - Exceeds withdrawal frequency limit D Yes
66 - Card acceptor call acquirer security D Yes
68 - Response received too late D Yes
71 - Deemed Acceptance A Yes
75 - PIN tries exceeded D Yes
76 - Unable to locate BAV for CDA D Yes
90 - Cut-off in process D Yes
91 - Issuer is inoperative D Yes
92 - Unable to route transaction D Yes
93 - Txn not completed due to absence of txnID D No
94 - Duplicate transmission D No
95 - Reconcile error D No
96 - System malfunction D No
99 - DECLINED D Yes
DE#41 Card Acceptor Terminal Identification
Format: Fixed
Type: an8
Description: It should carry value “register” in the 0200 request for all transactions originated from
a device registered at UIDAI data base. the data element is mandatory for 02xx and 04xx request
messages.
Field Edits: It should be echoed in all subsequent messages.

DE#42 Card Acceptor Identification Code
Format: Fixed
Type: an15
Description: This is a unique code for the device assigned within the Bank domain.
This is an alpha-numeric string of maximum length 15. 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.
Field Edits: It should be echoed in response.
Character 1-15 Unique Device Code, first 3 digits should have Bank code and last 12 digits should
be unique terminal code allotted to every device by the bank
If the terminal code is less than 12 digits, the terminal code should be left padded with zeros to
make it 12 digits.
Ex: ABC000123456789
Constraint: It should be echoed in response.
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.
Field Edits: If present, it should be echoed in response and all subsequent messages.
Character 1-23 Merchant Name &Address / Bank Correspondent Name &Address

Character 24-36 City Name
Character 37-38 State
Character 39-40 Country Code (IN)
DE#49 Transaction Currency Code
Format: Fixed
Type: n3
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.
Constraints: If present, it should be echoed in response and all subsequent messages
DE#54 Additional Amounts
Format: LLLVAR
Type: an..120
Description: It provides information for a maximum of six amounts. It must be populated in 0210
message for all transaction type with account balance.
Position Length Field Name Description
00-Unspecified, 10-Savings, 20-Checking, 30-

01-02 2 Account Type
Credit, 90-cash back
01-Ledger Balance
03-04 2 Balance Type 02-Actual Balance
00-Default
Currency code in which the balance is given e.g.

05-07 3 Currency Code
356 for Indian rupees

08-08 1 Balance Indicator C-Credit D-Debit
The balance amount for the respective balance type

09-21 12 Balance Amount
in the currency of the issuer
Field Edits: It must be populated for all successful transactions. In Fund transfer, DE#54 must not
be present.
Constraints: It must be populated in 0210 message for all transaction type with account balance.
Example - for a Cash Withdrawal transaction, balance could be send as
0201002356C000005000000, where
020- Length of total digits present in balance
10- Savings account
02- Actual balance
356- Indian currency code
C- Credit
000005000000- INR 50, 000 present in account
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 for all authentication response from UIDAI, the same data element
will also carry the action code if present in the response from UIDAI. For BFD transaction ranking
of individual finger is also sent in addition to the authentication code.
Field Edits: It should be sent back to acquirer bank in response to be displayed for all ONUS
transactions, additionally for all off-us transactions, NPCI must pass it on to issuer bank as well.
ONUS - It should be sent back to acquirer bank with proper values in the response message.
OFFUS - For all off-us transactions, NPCI must pass the proper values to issuer bank and issuer
bank must echo back the same in their 210 response which in-turn is passed back to the acquiring
bank.

A: For On-Us and Off-Us the structure of DE#62 is as stated below, Tag001 carries UIDAI
authentication code and Tag002 carries action code if it is present in the response from UIDAI.
048001032a0e3c5c0a6ab48e9a8206d5a8930ca7d002004A001
The length of Tag002 may vary based on the size of the data sent by UIDAI. If action code is not
present in the response from UIDAI, DE#62 will be as shown below:
038001032a0e3c5c0a6ab48e9a8206d5a8930ca7d
Note: This change in DE#62 (other than BFD transaction) is configurable at NPCI for an acquirer.
Till the time the bank is not certified for this change both acquiring and respective issuer will get
only the authentication code in DE#62 as stated below.
032a0e3c5c0a6ab48e9a8206d5a8930ca7d
B: For BFD the structure of DE#62 is as stated below, Tag001 carries UIDAI authentication code
and Tag002 carries rank of all fingers and action code.
172001032a0e3c5c0a6ab48e9a8206d5a8930ca7d002128<Ranks><Rankpos="LEFT_MIDDLE
"val="5"/><Rank pos="LEFT_THUMB" val="4"/><Rank pos="RIGHT_MIDDLE" val="2"/><Rank
pos="LEFT_INDEX" val="1"/><Rank pos="RIGHT_INDEX" val="8"/><Rank pos="LEFT_RING"
val="6"/><Rank pos="RIGHT_RING" val="-1"/><Rank pos="LEFT_LITTLE" val="7"/><Rank
pos="RIGHT_THUMB" val="3"/><Rank pos="RIGHT_LITTLE" val="9"/></Ranks><actn="01">
The details of tags and contents are described below:
Tag Max Length Description Valid Value
001 40 Authentication Code Authentication Code or NA
002 400 Action Code/Finger Ranking Action Code/Finger Ranking
Parsing of field is done as follows:

In example for BFD 172 is the length of the string for DE62.
Tag 001 represents Authentication Code which is of maximum length 40 in the above case it is
of length 032.
Tag 002 represents the Rankings of the fingers is of maximum length 400 in the above BFD case
it is of length 128.
Constraints: These values will only be populated by NPCI, if received from UIDAI.
NOTE: DE 62 will be Mandatorily TLV format from Auth 2.0 implementation at NPCI to maintain
uniformity across all the member banks.
DE#70 Network Management Information Code
Format: Fixed
Type: n3
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. Message Type 0800 0810
1 Logon 001 001
2 Echo 301 301
3 Cutover 201 201
4 Log off 002 002
Response code for 0810 message must be carried in DE 39 as 00 for successful processing of
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 transmission Date DE 7 of original Request
15-20 6 Original transmission Time DE 7 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: ans19
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).
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.
Constraints: The data element is used in 02xx and 04xx messages, whenever account information
must be transferred.

DE#103 Account Identification 2
Format: LLVAR
Type: ans19
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.
Usage: In the AADHAAR based Fund transfer transactions, beneficiary bank must send the
Beneficiary’s account number to which the amount was credited.
Field Edits: If present, should be echoed.
Constraints: C: The data element is used in 02xx and 04xx messages, whenever account
information must be transferred.
DE#111 to DE#119 Encrypted Personal Identity Data( FP/BFD/IRIS)
Format: LLLVAR
Type: an999
Description: This Element is encrypted containing finger print minutiae collected at the Micro
ATM/Demographic data collected.
Data will contain minutiae Single/ Dual finger or/and Demographic data for Authentication.
Data will contain minutiae of 10 Fingers for BFD.
Data will contain IRIS image of resident for Authentication.
Field Edits: None
Constraints: Data element is present for Authentication/BFD based 02xx request messages.
Field Edits: It should not be echoed in response messages.
Elements Description: DE is structured as TLV (Tag, length and value) field. The details of tags
and contents are described below:
Tag Length Description Valid Value
FP/BFD/IRIS Up to 999 char’s in Encrypted RBD only Encrypted RBD only
each Data element

Example:
Let’s assume PID in Protobuff format having data is of 3760 bytes.
Sample structure:
BFD-
DE#111- BFD3760<Encrypted biometric data of total length 992>
DE#112 till DE#119- <Encrypted biometric data of total length 999>
Note: 999 is the maximum data length which can be passed.
IRIS-
DE#111- IRS3760<Encrypted biometric data of total length 992>
FP-
DE#111- FPD1760<Encrypted biometric data of total length 992>
Note: FP authentication packet will max fit in to 3 data elements, FIG has to populate the data
accordingly in above format.
Note: Demoauth transactions initiated from other than RD machine should follow the same encryption
mechanism of auth 1.6.
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 number for fund transfer.

AEPS Fund Transfer Transaction
0200 message from Remitter bank to NPCI
Tag Description Length Value

Tag value to be populated for
1 Transaction type 2 45 Request
2 Product indicator 3 UID Request
45 Sender Name 20 Sender Name Request
Sender AADHAAR Sender AADHAAR no.

60 19
no. with IIN in DE 2 format Request
0200 message from NPCI to Beneficiary bank
1 Transaction type 2 45 Request
2 Product indicator 3 UID Request
45 Sender Name 20 Sender Name Request

60 19
no. with IIN in DE 2 format Request
0210 message from Beneficiary Bank to NPCI
1 Transaction type 2 45 Response
2 Product indicator 3 UID Response
45 Sender Name 20 Sender Name Only for success txn
46 Beneficiary Name 20 Beneficiary Name

Only for success txn

60 19
no. with IIN in DE 2 format Only for success txn
0210 message from NPCI to Remitter Bank
1 Transaction type 2 45 Response
2 Product indicator 3 UID Response
45 Sender Name 20 Sender Name Only for success txn
46 Beneficiary Name 20 Beneficiary Name Only for success txn

60 19
no. with IIN in DE 2 format Only for success txn

AEPS Mini Statement Transaction
0200 message from Acquirer bank to NPCI
Tag Description Length Value

Tag value to be populated for
1 Transaction Type 2 07 Request
2 Product Indicator 3 UID Request
0200 message from NPCI to Issuer bank
001 Transaction Type 2 07 Request
0210 message from Issuer bank to NPCI
1 Transaction Type 2 07 Response
2 Product Indicator 3 UID Response
No. of lines for mini

005 2 10
statement Response
006 Mini Statement data 350 Ans

Only for success
0210 message from NPCI to Acquirer Bank
1 Transaction Type 2 07 Response
No. of lines for mini

005 2 10
statement Response
006 Mini Statement data 350 Ans Only for success
AEPS Cash Deposit Transaction(BAV)
0200 message from Acquirer bank to NPCI
Tag Description Length Value Tag value to be populated for
0200 message from NPCI to Issuer bank
080 Deposit ID 12 Numeric value Request
046 Beneficiary’s Name 20 Alpha

Response

080 Deposit ID 12 Numeric value Response
046 Beneficiary’s Name 20 Alpha

Response
080 Deposit ID 12 Numeric value

Response
AEPS Cash Deposit Transaction(CDA)
0220/0221 message from Acquirer bank to NPCI
Tag Description Length Value Tag value to be populated for
046 Beneficiary’s Name 20 Alpha Response
0220/0221 message from NPCI to Issuer bank
080 Deposit ID 12 Numeric value

Response
Field Edits: The contents of field may change in the response depending on result of the
transaction.

Constraints: Conditional ‘C’
Sample DE#120 for Mini-Statement with 10 lines (9 lines for last 9 transactions and 10th line for
balance, each line is fixed 35 bytes). The length of tag-006 will vary based on the number of
transactions available in the customer account (a new account may have less than 10 transactions)
38100100207002003UID00500210006350
040621DR UMA 000001250100
040621DR UMA 000002200000
040621DR UMA 000004500000
040619DR ATM 000001500000
040619DR UMA 000004500000
040619DR UMA 000001400000
040619DR UMA 000001400000
040618DR ATM 000001500000
040617DR ATM 000000540000
Balance 000014354303
DE#123 to DE#125 mc attribute Data
Format: LLLVAR
Type: an999
Description: This Element is encrypted registered device public key certificate.
Field Edits: None
Constraints: Data element is present for auth 2.0 transactions.
Field Edits: It should not be echoed in response messages.
Elements Description: DE is structured as TLV (Tag, length and value) field. The details of tags
and contents are described below:
Tag Length Description Valid Value
mc Up to 999 Encrypted registered device Encrypted registered
characters in each public key certificate only device public key certificate
Data element only
Example:
Let’s assume registered device public key certificate data is 2000 bytes.

Sample structure:
DE#123- mc2000<Encrypted registered device public key certificate of length 993>
DE#124 till DE#125- <Encrypted registered device public key certificate length 999>
Note: Demo auth transactions not initiated from registered device will carry the value “FIG”
Format: LLLVAR
Type: an999
Description: These fields are Tag-based. They will carry ‘Uses’, ‘type’, ‘udc’, ‘dpid’, ‘rdsid’, ‘rdsver’,
‘dc’, ‘mi’, ‘bav’
Constraints: Conditional ‘C’. Data element is present for UID based 02xx request message
Tag Length Type Format Description Valid Value
001 9 Fixed A uses(authentication factors Please refer below
used by the request) table
008 1 Fixed A type(Type of PID block X/P
format)
009 20 Variable An udc(unique host device unique code for the host
code) device assigned within
the AUA domain
010 48 Variable Varchar dpId(Unique code Returned by RD
assigned to registered Service when using
device provider) biometric
authentication
011 48 Variable Varchar rdsId(Unique ID of the Returned by RD
certified registered device Service when using
service) biometric
authentication
012 15 Variable Varchar rdsVer(Registered Returned by RD
devices service version) Service when using
biometric
authentication
013 40 Variable 128 Bit dc(Unique Registered Returned by RD
UUID in Device Code) Service when using
HEX biometric
Format authentication
014 48 Variable Varchar mi(Registered device Returned by RD
model ID) Service when using

biometric
authentication
015 3 Fixed A bav(biometric FP authentication
authentication value) value will be FPD and
IRIS authentication
value will be IRS.
Usage:
Tag 001
1 2 3 4 5 6 7
Pi pa Pfa bio Bt pin otp
y' or 'n' y' or 'n' y' or 'n' y' or 'n' FMR or FIR or IIR y' or 'n' y' or 'n'
Example for Tag001: ‘nnnyFMRnn’
The generic description of DE126 is as follows:

Note: For demoauth transaction not initiated from registered devices the tag 010,011,012,013,014 will carry
the value “FIG”.
Format: LLLVAR
Type: an999
Description: These fields are Tag-based. They will carry ‘skey’, ‘ci’, ‘Hmac’, ‘ac’, ‘sa’ and ‘lk’, ‘rc’
in tag 001, tag 002, tag 003, tag 004, tag 005, tag 006 and tag 007 respectively
Constraints: C: Data element is present for UID based 02xx request message
Tag Length Type Format Description Valid Value

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

identifier using which “skey” the UIDAI public key, a
was encrypted) constant value.
003 As per Fixed An Hmac(for description on SHA -256 Hash of PID

the Hmac please refer to XML and then
process aadhaar_authentication_api encrypted
document published by
UIDAI)

004 010 Variable An ac (A unique code for the AUA An Alpha numeric value
which is assigned by UIDAI up to 10 characters
during AUA registration
process)
005 010 Variable An sa(A unique “Sub-AUA” code, An Alpha numeric value
managed by AUA within their up to 10 characters
system and ensure uniqueness.
If AUA and SA are same agency,
use value of “ac” for this
attribute.)
006 064 Variable An lk(A valid “License Key” An Alpha numeric value
assigned to the AUA through up to 64 characters
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.)
007 1 Fixed A rc( resident consent) Only allowed value
is “Y”
Note: The above tags in DE#127 are all mandatory. DE#127 is structured as TLV (Tag, length
and value) field. The details of tags and contents are described below:
Example: Let’s assume that skey length is 256 bytes, ci length is 8 bytes, Hmac is 48 bytes,
ac is 10 bytes, sa is 10 bytes and lk is 64 bytes. The structure of DE#127 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
7. Tag 007 represents rc which is of length 1 char
Usage:
The generic description of DE127 is as follows:

Chapter 4. Changes for Member Banks
Section 4.01 Changes for Acquirer Members

1. Establish connection with Micro ATM and switch.
2. Addition of new transaction in the interface to existing NFS Switch
3. Changes in the current reconciliation system to reconcile the interchange and switching
fees for AADHAAR based transactions.
4. Acquirer switch to generate and process reversal request.
5. MicroATM may be capable to generate Last Transaction Status (LTS) request and acquirer
switch shall response the status back to the MicroATM.
6. Changes to generate and process reversal messages.
7. 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.
8. MicroATM application must be capable to push the “Electronic Log” to acquirer bank
switch, at the end of Business day.
9. Addition of BFD processing in the interface to existing AEPS Switch.
10. Populate DE#111 to DE#119 in the transaction request.
11. Changes in the Micro ATM terminal application to accept 10 Finger prints and print the
BFD receipt.
12. Accept the Rank details in the response and process to Micro ATM.
13. Changes to process Cash deposit transaction in 2 legs( BAV & CDA).
14. Changes to process Deposit ID in BAV & CDA.
15. Changes to process advice message.
16. New Pcode 32 introduced for BAV.

NOTE: MicroATM terminal should ensure to generate verification if response not received to original
request of cash withdrawal and Merchant pay transactions after the TAT i.e 90 Secs completed.
 MicroATM can use the data elements like PAN, Processing code, Amount, STAN, Local
transaction Time and RRN for matching the verification and Original request in acquirer
switch.
 MicroATM can generate total 3 VR with a time interval of 10 Secs each if 1 st and 2nd VR didn’t
get the response.
 The VR is between MicroATM and acquirer switch only, the same should not be forwarded to
NPCI.
 MicroATM can generate reversal of all the 3 VR request timed out.
 MicroATM can decline the transaction if other than RC-‘00’ received as response to any VR.
Section 4.02 Changes for Issuer Members

1. Addition of new transaction in the interface to existing NFS Switch
2. Changes in the current recon system to reconcile the interchange and switching fees for
AADHAAR based transactions.
4. Changes to process Cash deposit transaction in 2 legs( BAV & CDA)
5. Changes to process Deposit ID in BAV & CDA
6. Changes to process advice message & New Pcode 32 introduced for BAV.
Section 4.03 Changes in NPCI systems

1. Addition of new transaction in existing NFS switch
2. Changes in online dispute management system for new rules
3. Changes in billing system for these new transaction types.
4. Changes to develop new reports and raw data files.

6. Addition of BFD processing on the AEPS interface with Banks
7. Routing transaction to UIDAI with the Biometric data received from the Acquirer bank.
8. Accept the Rank details in the response from UIDAI and process to Acquirer switch.
9. Changes to process Cash deposit transaction in 2 legs( BAV & CDA)
10. Changes to process Deposit ID in BAV & CDA
11. Changes to process advice message
Chapter 5. Settlement and Reconciliation

Please refer to AEPS Dispute & Settlement Handling Guidelines for detailed information on settlement
& Reconciliation.
Chapter 6. Risk Management

Following will be the risk management done by all the member banks:
Section 6.01 Checks by Issuer Banks:

1. Balance authorization
2. Account Validations/Verifications.
3. Number of Transactions in a day for the specific Account product
4. Maximum limit in a day for the specific card product
5. Issuer banks will either not store the UID authentication data or store it in encrypted formats
as per PCI guidelines.
6. AML related validations for Funds Transfer transaction.
7. Fraud Check
8. Duplicate (Multiple) reversals and original transactions.
9. All other validations
10. Issuer bank will connect to NPCI network on NPCINET.
11. Issuer has to check Deposit ID in BAV request.

12. Issuer has to check successful BAV for CDA (matching should be done with authorization
code, Deposit ID, RRN, Amount and Card no).
Section 6.02 Checks by Acquirer Banks:

1. Acquirer shall not log the Biometric data on the switch or at any hop.
2. Transaction and incoming message validation coming from Micro ATM.
3. Ensure card entry mode and pin entry mode to be present in the request.
4. Unique key management for the terminals.
5. Acquirer banks will either not store the UID authentication data or store it in encrypted
formats as per PCI guidelines.
6. All other validations
7. Acquirer bank will connect to NPCI network on NPCINET.
8. Acquirer Bank will be responsible for constructing and transmitting biometrics data of the
resident.
9. Acquirer has to check Deposit id in BAV response.
10. Acquirer has to check successful BAV for CDA (matching should be done with
authorization code, deposit id, RRN, Amount and Card no).

Chapter 7. Exception Conditions
Exception conditions for which reversals would be generated:
In case, NPCI doesn’t receive the response for a 0200 Request message from Issuer in 25 seconds,
NPCI would send 0210 Response to Acquirer with Response Code ‘91’ and generate a Reversal
Request (0420) message with Response Code ‘91’ to Issuer Bank, which should reverse the
transaction in CBS and respond with Response Code ‘00’ in 0430 Reversal Response message to
NPCI.
If NPCI does not get 0430 response from Issuer within 25 seconds, NPCI switch will generate 0421
message thrice after logon is exchanged with Issuer bank.

In case, Acquirer Bank switch doesn’t receive a 0210 Response message for the request due to time
out, it should generate a 0420 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
0430 message containing Response Code ‘00’.
If Acquirer bank switch does not receive 0430 response from NPCI within 45 seconds (min timeout to
be configured at acquirer switch), Acquirer bank switch will generate 0421 repeat Reversal message
after a successful logon message is exchanged. Maximum of 3 such Repeat Reversals can be sent
to NPCI.
Chapter 8. Message Dump
Section 8.01 Message dump for Network Messages

0800 message
Data Value Comment

Element
1 Valid value Secondary Bitmap
7 MMDDhhmmss Transmission date and time (GMT)
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 (GMT)
39 Valid response code “00”as per Network Management Information Code
request type
70 Original request code as per request Network Management Information Code
Section 8.02 Message dump for Biometric Authentication

0200 message (From Acquirer/Issuer Bank to NPCI)
Data Value Comment

Element
2 IIN +0+ AADHAAR no. Customer’s detail
3 Processing Code Processing code for Bio metric
authentication
12 HHMMSS Local Time
13 MMDD Local Date
18 6012 6012 for Micro ATM
22 019 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 Register
Identification
42 Card Acceptor Identification code Bank Code, unique terminal code
43 Card Acceptor Name / Location Address of Merchant/BC
111 to Personal Identity Data Bio metric data from finger print scanner or
119 demographic data or otp or pin
123 to Mc Encrypted registered device public key
125 certificate.
126 Uses, udc, type, rdsId, rdsver, dpId, Additional data
dc,mi, bav.
127 Skey, ci, Hmac, ac, sa, lk, rc Captured from terminal and fed by AUA
server, respectively
0210 message (From NPCI to Issuer/Acquirer Bank)
Data Value Comment

Element
2 IIN + 0+ AADHAAR no. Customer’s detail
authentication
13 MMDD Local Date
32 ACQ Inst ID ID already allotted by NPCI
DDD – Julian Date
HH - Hour
39 00 Response code
Identification

62 UIDAI Authentication Code, Action Field with tag values, tag001 for
Code authentication code and tag002 with
action code if it is available in response
from UIDAI
Section 8.03 Message dump for Demographic Authentication

0200 message (From Bank to NPCI)
Data Value Comment

Element
2 IIN + 0 +AADHAAR no. Customer’s detail
3 Processing Code Processing code for Demographic
authentication
13 MMDD Local Date
DDD – Julian Date
HH - Hour
Identification
111 to Personal Identity Data demographic data or otp or pin
119

123 to Mc FIG
125
126 Uses, udc, type, rdsId, rdsver, dpId, Additional data rdsId, rdsver, dpId, dc will
dc,mi. carry the value ”FIG”
127 Skey, ci, Hmac , ac, sa, lk, rc Captured from terminal and fed by AUA
0210 message (Response From NPCI to Bank)
Data Value Comment

Element
3 Processing Code Processing code for Demographic
authentication
13 MMDD Local Date
DDD – Julian Date
HH - Hour
39 00 Response code
Identification
from UIDAI

Section 8.04 Message dump for Interbank Balance Enquiry
0200 message (from Acquirer to NPCI)
Data Value Comment

Element
2 IIN +0+ AADHAAR Customer’s detail
3 Processing Code Processing code for Balance Enquiry
4 000000000000 Amount Fixed value – Zero
13 MMDD Local Date
15 MMDD Settlement Date (conditional)
22 01 9 or 02 9 Manual (01), Card Reader present (02)
DDD – Julian Date
HH- Hour
Identification
49 356 Currency Code
111 to Personal Identity Data Bio metric data from finger print scanner
119 or demographic data or otp or pin
125 certificate.
dc,mi, bav.

127 Skey, ci, Hmac, ac, sa, lk,rc Captured from terminal and fed by AUA
0200 message (from NPCI to Issuer)
Data Value Comment

Element
2 IIN + AADHAAR Customer’s detail
3 Processing Code Processing code fixed for Balance Enquiry
13 MMDD Local Date
35 Track 2 data As encoded in Card for card present
transaction
DDD – Julian Date
HH- Hour
Identification
code authentication code and tag002 with
from UIDAI

0210 message (from Issuer to NPCI)
Data Value Comment

Element
2 IIN + 0+ AADHAAR Customer’s detail
13 MMDD Local Date
15 MMDD Settlement Date (optional)
DDD – Julian Date
HH-Hour
38 Valid value Authorization identification code
39 00 Success response code
Identification
54 Amount Account Balance
from UIDAI
0210 message (from NPCI to Acquirer)
Data Value Comment

Element

13 MMDD Local Date
DDD – Julian Date
HH-Hour
Identification
from UIDAI
Section 8.05 Message dump for Interbank Cash Withdrawal
Data Value Comment

Element
3 Processing Code Processing code fixed for Cash
Withdrawal

4 Amount Withdrawal amount
13 MMDD Local Date
DDD – Julian Date
HH- Hour
Identification
125 certificate.
dc,mi, bav.
127 Skey, ci, Hmac ,ac, sa, lk, rc Captured from terminal and fed by AUA
Data Value Comment

Element

Withdrawal
13 MMDD Local Date
DDD – Julian Date
HH- Hour
Identification
from UIDAI
Data Value Comment

Element
Withdrawal

13 MMDD Local Date
DDD – Julian Date
HH-Hour
Identification
from UIDAI
Data Value Comment

Element
Withdrawal
13 MMDD Local Date

DDD – Julian Date

HH-Hour
38 Valid value Authorization Identification Code
Identification
from UIDAI
Section 8.06 Message dump for Interbank Purchase
Data Value Comment

Element
3 Processing Code Processing code fixed for Purchase
4 Amount Purchase amount
13 MMDD Local Date

DDD – Julian Date
HH- Hour
Identification
125 certificate.
dc,mi.
Data Value Comment

Element
13 MMDD Local Date

DDD – Julian Date
HH- Hour
Identification
from UIDAI
Data Value Comment

Element
13 MMDD Local Date
DDD – Julian Date

HH-Hour
Identification
from UIDAI
Data Value Comment

Element
13 MMDD Local Date
DDD – Julian Date
HH-Hour

Identification
from UIDAI
Section 8.07 Message dump for Interbank Cash Deposit
Section 8.07.01 Message dump for Beneficiary Account Validation

Data Value Comment
Element
2 IIN + 0 + AADHAAR Customer’s detail
3 Processing Code(320000) Processing code for Cash Deposit BAV
4 Amount Deposit amount
13 MMDD Local Date
DDD – Julian Date
HH- Hour
Identification

119
or demographic data or otp or pin
120 002003UID Tag 002 – Length 003 – UID
125
certificate.
dc,mi, bav.
127 Skey, ci, Hmac,ac, sa, lk, rc Captured from terminal and fed by AUA
Data Value Comment
Element
13 MMDD Local Date
DDD – Julian Date
HH- Hour
Identification
from UIDAI
120 002003UID080012<Deposit ID> Tag 002 – Length 003 – UID
Tag 080 – Length 012 – Deposit ID

Data Value Comment
Element

13 MMDD Local Date
DDD – Julian Date
HH-Hour
Identification
from UIDAI
120 002003UID046020< Beneficiary Tag 002 – Length 003 – UID
Name>080012<Deposit ID> Tag 046 – Length 020- Beneficiary Name

Data Value Comment
Element
13 MMDD Local Date
DDD – Julian Date
HH-Hour
Identification

from UIDAI
Section 8.07.02 Message dump for Cash Deposit Advice

Data Value Comment
Element
3 Processing Code(210000) Processing code for Cash Deposit CDA
13 MMDD Local Date
DDD – Julian Date
HH- Hour
38 Valid value Authorization identification code (echo
back)
Identification

Data Value Comment
Element

13 MMDD Local Date
DDD – Julian Date
HH- Hour
back)
Identification

Data Value Comment
Element
13 MMDD Local Date
DDD – Julian Date
HH-Hour
back)
Identification


Data Value Comment
Element
13 MMDD Local Date
DDD – Julian Date
HH-Hour
back)
Identification
NOTE: Authorization identification code, RRN, Deposit ID of CDA should be same of BAV

Section 8.08 Message dump for Interbank Fund Transfer
0200 message (from Remitter Bank to NPCI)
Data Value Comment

Element
2 IIN + 0 + AADHAAR Beneficiary detail
3 Processing Code Processing code fixed for Fund
Transfer
4 Amount Transfer amount
13 MMDD Local 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
SSSSSS – System Trace Audit
Number
41 Card Acceptor Terminal Identification Register
102 Sender Account Detail Mandatory
120 00100245002003UID045020<Sender Tag 001 – Length 002 – 45
Name>060019IIN+ AADHAAR no. Tag 002 – Length 003 – UID

Tag 045 – Length 020 - <Sender
Name>
Tag 060 – Length -019 – IIN + 0+
AADHAAR
(BBBBBB0UUUUUUUUUUUU)
0200 message (from NPCI to Beneficiary)
Data Value Comment

Element
2 IIN + 0 + AADHAAR Beneficiary detail
Transfer
13 MMDD Local 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
Number
102 Sender Account detail Mandatory

Name>060019IIN+ AADHAAR no. Tag 002 – Length 003 – UID
Tag 045 – Length 020 - <Sender
Name>
Tag 060 – Length -019 – IIN + 0+
AADHAAR
0210 message (from Beneficiary to NPCI)
Data Value Comment

element
Transfer
13 MMDD Local Date
DDD – Julian Date
HH- Hour

Number
42 Card Acceptor Identification code Bank Name, unique terminal code
43 Card Acceptor Name / Location Address of BC
102 Sender Account Detail Mandatory
103 Beneficiary Account Detail Mandatory for success transaction

Name>046020<Beneficiary Tag 002 – Length 003 – UID
Name>060019IIN+ AADHAAR no. Tag 045 – Length 020 - <Sender
Name>
Tag 046 – Length 020 - <Beneficiary
Name>
Tag 060 – Length -019 – IIN + 0+
AADHAAR
0210 message (from NPCI to Remitter)
Data Value Comment

element
Transfer
13 MMDD Local Date
DDD – Julian Date

HH- Hour
Number

102 Sender Account detail Mandatory
103 Beneficiary Account Detail Mandatory for success transaction
Name>046020<Beneficiary Tag 002 – Length 003 – UID

Name>060019IIN+ AADHAAR no. Tag 045 – Length 020 - <Sender
Name>
Tag 046 – Length 020 - <Beneficiary
Name>
Tag 060 – Length -019 – IIN +0 +
AADHAAR
Section 8.09 Message dump for Interbank Mini Statement
Data Value Comment

Element
2 IIN + 0 + AADHAAR Customer’s details
3 Processing Code Processing code fixed for Mini
Statement
13 MMDD Local Date
22 01 9 or 02 9 Manual (01), Card Reader present
(02) Reserved for private use (9)

transaction
DDD – Julian Date
HH- Hour
Number
111 to Personal Identity Data Bio metric data from finger print
119 scanner or demographic data or otp
or pin
120 00100207002003UID Tag 001 – Length 002 – 07
Tag 002 – Length 003 – UID
123 to mc Encrypted registered device public
125 key certificate.
126 Uses, udc, type,rdsId, rdsver, dpId, Additional data
dc,mi,bav.
127 Skey, ci, Hmac, ac, sa, lk, rc Captured from terminal and fed by
AUA server, respectively
Data Value Comment

Element
2 IIN + 0+ AADHAAR Customer’s details
Statement

13 MMDD Local Date
22 01 9 or 02 9 Manual (01), Card Reader present
(02) Reserved for private use (9)
transaction
DDD – Julian Date
HH- Hour
Number
62 UIDAI Authentication Code, Action Code Field with tag values, tag001 for
authentication code and tag002 with
action code if it is available in
response from UIDAI
120 00100207002003UID Tag 001 – Length 002 – 07
Tag 002 – Length 003 – UID
Data Value Comment

element
2 IIN + 0+ AADHAAR Customer’s details

Statement
13 MMDD Local Date
DDD – Julian Date
HH-Hour
Number
41 Card Acceptor Terminal Identification register
response from UIDAI
120 00100207002003UID00500210006350<M Tag 001 – Length 002 – 07
ini Statement> Tag 002 – Length 003 – UID
Tag 005 – Length 002 - 10
Tag 006 – Length 350 – last 9
transaction details & actual balance
in 10th entry for successful
transactions
Data Value Comment

element

2 IIN + 0 + AADHAAR Customer’s details

Statement
13 MMDD Local Date
DDD – Julian Date
HH-Hour
Number
42 Card Acceptor Identification code Bank code, unique device code
43 Card Acceptor Name / Location Bank Code, unique terminal code
response from UIDAI
120 00100207002003UID00500210006350<M Tag 001 – Length 002 – 07
ini Statement> Tag 002 – Length 003 – UID
Tag 005 – Length 002 - 10
Tag 006 – Length 350 – last 9
transaction details & actual balance
in 10th entry for successful
transactions

Section 8.10 Message Dump for Reversal Message

0420 message (From Acquirer to NPCI)
Data Value Comment

element
3 Processing Code Processing code for original transaction
4 Amount Original transaction amount
13 MMDD Local Date
DDD – Julian Date
HH - Hour
(*conditional)
*In case of MicroATM timeout this DE

should be sent to NPCI from the Acquirer
39 68 Response code for Acquirer timeout
Identification
42 Card Acceptor Identification code Merchant Name

90 Valid values Original transaction data
0420 message (From NPCI to Issuer)
Data Value Comment

element
13 MMDD Local Date
DDD – Julian Date
HH - Hour
(conditional)
39 91 or 68 Response code for Issuer or acquirer
timeout
Identification
42 Card Acceptor Identification code Merchant Name
0430 message (From Issuer to NPCI)
Data Value Comment

Element
13 MMDD Local Date
DDD – Julian Date
HH - Hour
39 00 Response code
0430 message (From NPCI to Acquirer)
Data Value Comment

element
13 MMDD Local Date
DDD – Julian Date
HH - Hour

(conditional)
39 00 Response code
Section 8.11 Message Dump for BFD Transaction

0200 message (From Acquirer Bank to NPCI)
Data Value Comment

element
2 IIN +0+ AADHAAR no. Customer’s detail
3 Processing Code Processing code for BFD authentication
13 MMDD Local Date
DDD – Julian Date
HH - Hour
Identification

112-117 Finger data encrypted containing finger print minutiae
collected at the Micro ATM. Data will
contain minutiae of 6 or 10 fingers
125 certificate.
dc,mi.
0210 message (From NPCI to Acquirer Bank)
Data Value Comment

Element
authentication
13 MMDD Local Date
DDD – Julian Date
HH - Hour
39 00 Response code
Identification
62 UIDAI Authentication Code Field with tag values, tag001 for
authentication code and tag002 with data
of finger ranking

Chapter 9. Receipts and Logs Formats
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. While printing customer’s Aadhaar number on receipt the first 6 digits must be
masked. In order to standardize Receipt format across all the MicroATM, NPCI proposes following
receipt format to be used as a template for all the transactions.
Section 9.01 BFD

Bank Need to follow any of the below Receipt Formats for BFD services.
 Print Transaction status as success only when BFD response is been received. Since BFD is
considered as success.
 Do not print auth code length in receipt, just print its value.
 Message field on receipt- Bank need to print the action code message which will be available
in AEPS MicroATM Guide/ Best Finger Detection Process Development.

Section 9.02 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:

Section 9.03 Purchase of Goods

Bank Name and Logo
Purchase of Goods
BC Name: Agent Id:
Issuer Bank:
Customer Name:
STAN:
RRN:
UIDAI Auth. Code:
Transaction Status: Successful(00)/Decline(response code)
Transaction Amount:
A/C Balance:
Section 9.04 Cash Deposit

Bank Name and Logo
Cash Deposit
BC Name: Agent Id:
Customer Name:
Deposit ID:
Approval ID:
STAN:
RRN:
UIDAI Auth. Code:
Transaction Status: Successful(00)/Decline(Response code)
Transaction Amount:
A/C Balance:

Section 9.05 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:
Section 9.06 Balance Enquiry

Bank Name and Logo
Balance Enquiry
BC Name: Agent Id:
Customer Name:
STAN:
RRN:
UIDAI Auth. Code:
A/C Balance:

Section 9.07 Demographic Authentication

Bank Name and Logo
Demographic Authentication
BC Name: Agent Id:
Customer Name:
STAN:
RRN:
UIDAI Auth. Code:
Transaction Status: Demographic authentication successful/ unsuccessful
Section 9.08 Mini Statement

Banks may refer to below Mini Statement format for printing on receipt.
Bank Name and Logo
Mini Statement

BC Name: Agent Id:
Customer Name:
STAN:
RRN:
UIDAI Auth. Code:
Transaction Status: successful/Decline (Response Code)

----------------------------Format for Electronic logs----------------------------------
Section 9.09 Format for Original Transaction Electronic log

Bank Name
Original Electronic Log

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

Bank Name
LTS Electronic Log
Date: (dd/mm/yy) Time: (hh:mm:ss) This block must be filled by

BC Name: Agent Id: MicroATM values
Customer Name:
STAN:
RRN:
UIDAI Auth. Code: Acquirer bank switch values
Transaction Status: Successful(00)/Decline (response code)
Transaction Amount:
A/C Balance:

Section 9.11 Format for Reversal Electronic log

Bank Name
Reversal Electronic Log
BC Name: Agent Id:

BC Location: Terminal Id: MicroATM values
Customer Name:
STAN: This block must be filled by

Acquirer bank switch values
RRN:
Transaction Status: Successful (00)/Decline (response code)
Chapter 10. TRACK OF CHANGES

Change in Version 5.2 from 5. 1
Page no Value Description

13 Flow Revised cash Deposit flow
22 Advice message structure Advice Message
26 DE#3 Processing code changes
37 DE#39 RC-76 introduction
46 DE#120 Changes for BAV & CDA
53 Changes Changes for all stake holders & VR introduction
for CW & Merchant Pay transaction
55 Checks Checks by all stake holders
74 Message dump Dump for BAV and CDA
96 Charge slip format Charge slip format changed

AEPS Interface Specifications Version 5.2 - 20042018 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 Specifications Version 5.2 - 20042018 PDF

Uploaded by

Copyright:

Available Formats

AADHAAR ENABLED PAYMENT SYSTEM

(AEPS) INTERFACE SPECIFICATION

Author AEPS Technology

Published Date 02-10-13

Total Page number 100

Document classification Confidential

Date Version Changes

02/10/2013 4.0 connected. BFD receipt formats added.

03/06/2014 4.1 Internal release

20/04/2017 5.0 Authentication 2.0.1 changes incorporated

16/05/2017 5.0.1 Additional data elements added to accommodate the increased

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

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

CHAPTER 1. INTRODUCTION ........................................................................................................... 6

SECTION 1.01 EXECUTIVE SUMMARY .......................................................................................................6

SECTION 1.02 SCOPE & AUDIENCE OF THIS DOCUMENT .........................................................................6

CHAPTER 2. AADHAAR IMPLEMENTATION FOR FI ARCHITECTURE ....................................... 7

SECTION 2.01 ARCHITECTURE DIAGRAM AND BRIEF ...............................................................................7

SECTION 2.02 DETAILS OF INTRA-BANK TRANSACTION ...........................................................................7

SECTION 2.03 DETAILS OF INTER-BANK TRANSACTIONS.........................................................................8

SECTION 2.04 AADHAAR TO AADHAAR FUND TRANSFER TRANSACTION ................................................9

SECTION 2.05 DETAILS OF INTERBANK CASH DEPOSIT TRANSACTION .................................................12

SECTION 2.07 DETAILS OF DEMOGRAPHIC AUTHENTICATION ...............................................................17

SECTION 2.08 BEST FINGER DETECTION ...............................................................................................17

CHAPTER 3. INTERFACE SPECIFICATION .................................................................................. 18

SECTION 3.01 SYSTEM DEFINITIONS ......................................................................................................18

SECTION 3.02 DATA ELEMENT PROCESSING RULES...............................................................................18

SECTION 3.03 MESSAGE FORMAT ..........................................................................................................20

SECTION 3.04 ADMINISTRATIVE MESSAGES...........................................................................................20

SECTION 3.05 FINANCIAL MESSAGES.....................................................................................................21

SECTION 3.06 ADVICE MESSAGE ...........................................................................................................22

SECTION 3.07 REVERSAL MESSAGES ....................................................................................................23

SECTION 3.08 DATA ELEMENT DEFINITIONS ..........................................................................................24

CHAPTER 4. CHANGES FOR MEMBER BANKS ........................................................................... 53

SECTION 4.01 CHANGES FOR ACQUIRER MEMBERS .............................................................................53

SECTION 4.03 CHANGES IN NPCI SYSTEMS ..........................................................................................54

CHAPTER 5. SETTLEMENT AND RECONCILIATION ................................................................... 55

CHAPTER 6. RISK MANAGEMENT ................................................................................................. 55

SECTION 6.01 CHECKS BY ISSUER BANKS: ............................................................................................55

SECTION 6.02 CHECKS BY ACQUIRER BANKS: .......................................................................................56

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

CHAPTER 8. MESSAGE DUMP ....................................................................................................... 58

SECTION 8.01 MESSAGE DUMP FOR NETWORK MESSAGES ..................................................................58

SECTION 8.02 MESSAGE DUMP FOR BIOMETRIC AUTHENTICATION.......................................................59

SECTION 8.03 MESSAGE DUMP FOR DEMOGRAPHIC AUTHENTICATION ................................................61

SECTION 8.04 MESSAGE DUMP FOR INTERBANK BALANCE ENQUIRY....................................................63

SECTION 8.05 MESSAGE DUMP FOR INTERBANK CASH WITHDRAWAL ..................................................66

SECTION 8.06 MESSAGE DUMP FOR INTERBANK PURCHASE.................................................................70

SECTION 8.07 MESSAGE DUMP FOR INTERBANK CASH DEPOSIT ..........................................................74

SECTION 8.07.01 MESSAGE DUMP FOR BENEFICIARY ACCOUNT VALIDATION ..........................................74

SECTION 8.07.02 MESSAGE DUMP FOR CASH DEPOSIT ADVICE ...............................................................77

SECTION 8.08 MESSAGE DUMP FOR INTERBANK FUND TRANSFER .......................................................80

SECTION 8.09 MESSAGE DUMP FOR INTERBANK MINI STATEMENT .......................................................84

SECTION 8.10 MESSAGE DUMP FOR REVERSAL MESSAGE...................................................................89

SECTION 8.11 MESSAGE DUMP FOR BFD TRANSACTION .....................................................................92

CHAPTER 9. RECEIPTS AND LOGS FORMATS ........................................................................... 94

SECTION 9.01 BFD .................................................................................................................................94

SECTION 9.02 CASH WITHDRAWAL ........................................................................................................95

SECTION 9.03 PURCHASE OF GOODS ....................................................................................................96

SECTION 9.04 CASH DEPOSIT ................................................................................................................96

SECTION 9.05 FUND TRANSFER .............................................................................................................97

SECTION 9.06 BALANCE ENQUIRY ..........................................................................................................97

SECTION 9.07 DEMOGRAPHIC AUTHENTICATION ...................................................................................98