SOP BC Interoperability - Interface Specifications

8/9/2019 SOP BC Interoperability - Interface Specifications

1/90

INTERFACE SPECIFICATIONFOR BC INTEROPERABILITY


2/90

[INTERFACE SPECIFICATION for BC INTEROPERABILITY]

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

AADHAAR ENABLED PAYMENT SYSTEM

1.0 Introduction

1.1 Executive Summary

National Payments Corporation of India (NPCI) is formed as an umbrella institution for all the retailpayments systems in the country. The core objective is to consolidate and integrate the multiple systemswith varying service levels into nation-wide uniform and standard business process for all retail paymentsystems. The other objective was to facilitate an affordable payment mechanism to benefit the commonman across the country and help financial inclusion. Vision and formation of NPCI is backed by theregulator and Indian Banks Association (IBA). NPCI has defined business lines to process in countryinterbank transactions for ATM, POS, 24*7 Remittance, ACH and CTS.

Government of India has initiated Unique Identification Project for citizens of India. It is envisaged to use

the UID schema and infrastructure for the financial inclusion in India. To enable the customers to use

AADHAAR for the financial transaction across the payment networks in the country, NPCI proposes to

facilitate routing of transactions to the central id repository of UIDAI for user authentication through a

single interface.

This interface document is targeted to achieve inter-operability between banks for AADHAAR enabled

financial inclusion transactions.

NPCI shall allow banks to connect using this interface. It is also possible that banks may position their

respective financial inclusion service provider to connect on their behalf to NPCI central infrastructure

with the complete onus with the respective member bank.

1.2 Scope of this document

This document covers detailed description of the data elements in the ISO 8583 standard paymentmessage specifications specific to Aadhaar Enabled Payment System (AEPS)

1.3 Audience

This document is a property of NPCI and should be not be circulated to external party without priorapprovals of NPCI management team.


3/90



2.0 AADHAAR Implementation for FI Architecture

2.1 Architecture Diagram and Brief

NPCI switch will be enhanced to support Interbank Transactions. For Onus Transactions, only theauthentication support will be provided based on the request from the issuer bank.

Following is the Transaction Set,

1. Cash Withdrawal

2. Balance Enquiry

3. Cash Deposit

4. Funds Transfer

The following diagrams present a snapshot of these transactions:


4/90




5/90



Details – Onus Flow (only authentication)

In case Bank desires to leverage NPCI AEPS interface for UIDAI authentication, the transaction flow givenabove where the transaction for biometric verification will be sent for requisite fields and verificationresult from UIDAI will be forwarded to the bank.

MicroATM Application Requirement:

1. MicroATM application on PoS must ensure that a 12 digit AADHAAR number is entered as a block of4 digits in one block. Hence there would be three blocks of 4 digit number each. This is to

improve the business correspondent readability in case of manual entry.

2. The last digit of Aadhaar number is a check digit. Therefore, Verhoeff algorithm must be applied

for checking that the AADHAAR number entered at any textbox is valid or not.


6/90



Details - Off us flow for Funds Transfer:

The transaction flow is depicted above for funds transfer from account of customer of Remitter Bank toBeneficiary Bank where the transaction is initiated on Remitter bank‟s terminal. In fund transfertransaction, remitter bank is the same as Issuer & Acquirer bank.

Online Debit and Online credit is envisaged in this transaction and beneficiary bank is expected to respond

with beneficiary‟s Aadhaar number and name in the response message.

Interchange fees as and when decided will be highlighted by NPCI along with Bio Metric verification from

UID system. It is assumed for fund transfer that only pre authorized transaction (credit leg) will come to

NPCI.


1. MicroATM application on PoS must ensure that a 12 digit AADHAAR number is entered as a block of4 digits in one block. Hence there would be three blocks of 4 digit number each. This is toimprove the business correspondent readability in case of manual entry.

2.

The last digit of Aadhaar number is a check digit. Therefore, Verhoeff algorithm must be applied

for checking that the AADHAAR number entered at any textbox is valid or not.

3. The MicroATM application MUST necessitate that the R eceiver‘s Aadhaar number is entered twice

by the sender on the fund transfer screen. There can be 2 textboxes for the same and a

comparison of the digits entered should be made before proceeding to the next text box or

screen. This will ensure that the receiver‟s Aadhaar number is entered correct as is the practice

while making online payments.

A Fund transfer transaction needs to be initiated on the home bank BC terminal only and thus the

IIN/Bank name selected for remitter bank needs to be prefixed to avoid manual entry selecting mistake.


7/90



Flow diagram of AEPS fund transfer transaction:

It is necessary that for fund transfer transaction remitter will use its own bank MicroATMs / POS /

Infrastructure (i.e. Acquirer bank and Issuer bank is same in this case as is referred as Remitter Bank)

Fund transfer explained:

1. Fund transfer transaction consists of 2 legs i.e. debit leg and credit leg. It is important to notethat debit leg has to be processed locally and credit message to be sent to NPCI.

2.

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

3. Once a fund transfer transaction is initiated from a terminal, acquirer switch has to split the samein two parts i.e. debit leg and credit leg. After processing the debit leg, credit leg is sent to NPCI.For processing debit leg, NPCI provides authentication service where in only authenticationtransaction has to be sent to NPCI and after the response of the same and debiting the senderaccount; credit leg should be sent to NPCI. (Refer to message dump for authentication transactionand fund transfer credit leg).

4. All fund transfer transactions will pre-authorized by the issuer i.e. after debiting the senderaccount credit transaction will be sent to NPCI for processing.

If any member bank is taking authentication service from NPCI, then the fund transfer transactions willbe two-step process as explained below:

1. As shown in the above diagram (dotted line) authentication transaction will be initiated by theacquirer for authentication and subsequent debit to the sender account. Please note thatauthentication transaction is a non-financial transaction.

2.

Once the debit to sender account is successful a remittance transaction is sent to NPCI.

3. The context of both authentication and fund transfer transaction will be maintained by the acquirer.


8/90



NOTE:

1.

In case of authentication request, DE2 should carry the remitter‟s AADHAAR number (Sender AADHAARno.).

2.

For credit leg data element DE2 will contain the beneficiary AADHAAR no., DE120 will contain thesender AADHAAR No. and DE63 contains the biometric data of sender. It is the responsibility of issuerto debit the sender‟s account and send a fund transfer message to NPCI. The description of DE120 isdetailed in Data Element Definition section.

3. In case, acquirer receives any other Response Code than ‗00‘ or ‗91‘; the debit should be

reversed internally. In all other cases, disputes will be handled through Dispute ManagementSystem (DMS) provided by NPCI.

4. As explained earlier fund transfer option is available to customer only at their home terminal. It isonly for those participants who are both acquirer and issuer.

Details - Off us flow – Other transactions (Cash Withdrawal, Cash Deposit, BalanceEnquiry)

The transaction flow depicted above is for Balance Enquiry, Cash Withdrawal and Cash Deposittransactions acquired on Acquirer bank terminal for Issuer bank customers. Interchange fees will be

highlighted by NPCI along with Bio Metric verification from UIDAI system after only the decision beingmutually taken between the banks and concerned regulatory bodies.


9/90




1. MicroATM application on PoS must ensure that a 12 digit AADHAAR number is entered as a block of4 digits in one block . Hence there would be three blocks of 4 digit number each. This is toimprove 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 appliedfor checking that the AADHAAR number entered at any textbox is valid or not.

2.2 Interface Specification

This document provides clear understanding of online interfaces, protocols and messages used, to enableimplementation 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 transactionmessages.

2.2.1 System Definitions

Following points should be noted while developing the interface,

1. Bank Systems and NPCI-UID systems will be connecting to each other using socket connections.

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

3.

Banks will be responsible to generate the Logon (0800 message type) message after every

successful TCP socket connection. Banks should also generate Logon messages at the interval

of every 5 minutes only

4. NFS will generate cut over message (0800 message type) at 23:00 indicating business date

change over.

5. Both Banks and NFS can generate Logon (800 message type) messages and they should be

responded with 810 messages by the recipient.

6. Banks and NFS will also generate Echo message (0800 message type) for keep alive during no

transaction time. Ideal duration for the same is 3 minutes interval only

7. Message Header – 2 bytes binary (value containing length of the message including header

length i.e. 2 byte)

8. Bank needs to send auto logon (network) message when there is a disruption or disconnectionin network before sending the financial transaction message.

2.2.2 Data element processing rules

Originator:

The originator of the request message must be able to:

Correctly populate DE-2 comprising of IIN (6 digits ISOIIN), 0 as identifier and 12 digit AADHAARnumber

Correctly populate DE-18 and DE-22 based on the data supplied by Acquiring touch point(MicroATM)

Correctly populate DE-63 with UID Bio metric data.

Populate DE-120 with Sender‘s name for Fund transfer transactions only


10/90



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

NPCI

NPCI must be able to receive and process message containing DE-2, DE-63, DE120 and DE 127

Recipient

The Recipient must be able to receive and process messages containing DE-2, DE-22, DE-62 andDE120.

It is up to the recipient how to interpret and use the values transferred in DE-22 & DE-120.

It must send current account balance of customer in DE 54 for all transactions. Data Receivedin DE-62 is the Unique Authentication Code generated by UIDAI for each AuthenticationRequest. This should be printed on receipt in all the cases.

In fund transfer transactions, Recipient must populate DE-103 with ―To account number‖ andDE-120 with Beneficiary‘s name in the response message.

2.2.3 Message format

Message formats specified below contain UID related information. The changes in the messagestructure and/or data element content are indicated by bold characters. These formats supersedethe Host-to-Host message specification provided by NPCI.

All message format definition tables use the symbols defined in the following table:

2

.

2

.

2

.

1

A

2.2.3.1 Administrative Messages

Network Management Messages

MTID Data Element 0800 0810

1 Secondary bitmap M M+

7 Transmission date/time M M+

11 STAN M M+

15 Date, settlement C C+

32 Acquirer institution ID - -39 Response code - M

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.


11/90



48 Key Data (Optional– DynamicKey Exchange)

C* -

64 MAC Code(Optional– MACin

R R

70 NMIC M M+

128 MACCode2(Optional– MACing)

R R

* DE 48 as per NPCI standards should be Conditional. Since, NPCI does not use dynamic key exchange

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

2.2.3.2 Financial Messages

Financial Messages

MTID Data Element 200 210

1 Secondary bitmap M M+

2 Primary Account Number M M+

3 Processing code M M+

4 Amount, transaction C C+

5 Amount, settlement C C+

7 Date/time, transmission M M+

8 Fee, card holder billing R R

9 Conversion rate, settlement C C+

11 STAN M M+

12 Time, local transaction M M+

13 Date, local transaction M M+

14 Date, expiration C -

15 Date, settlement C C+

18 Merchant type M M+

22 POS entry mode M M+

25 POS condition code M M+

26 POS PIN capture code C -

32 Acquirer institution ID M M+

35 Track2data C -

37 Retrieval Reference Number M M+

38 Authorization number - C

39 Response code - M

41 Card acceptor terminal ID M M+

42 Card acceptor ID M M+

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


12/90



49 Currency code, transaction C C+

50 Currency code, settlement C C+

52 PIN Block C -

54 Additional amounts - C

62UIDAI Authentication Code C M

63 UID Authentication data M -

64 MAC code R R

90 Original data element - -

102 Account 1 identification C C

103 Account 2 identification C C

120 Additional Data C C

121-123 Private use C C*

127 Additional Data(skey, ci, Hmac, ac, sa ,lk) M -

128 MACCode2 R R

2.2.3.3 Reversal Messages

Reversal Messages

MTID Data Element 0420 0421* 0430

1 Secondary bitmap M M M+

2 Primary Account Number M M M+

3 Processing code M M M+

4 Amount, transaction M M M+

5 Amount, settlement C C C+

7 Date/time, transmission M M M

8 Fee, card holder billing R R R

9 Conversion rate, settlement C C C+

11 STAN M M M+

12 Time, local transaction M M M+

13 Date, local transaction M M M+

14 Date, expiration C C -

15 Date, settlement C C C+

22 POS entry mode M M -

25 POS condition code M M -

26 POS PIN capture code C C -

32 Acquirer institution ID M M M+

35 Track2data O O -

37 Retrieval reference number M M M+

38 Authorization number C C C+

39 Response code M M M

41 Card acceptor terminal ID M M


13/90



Reversal Messages

MTID Data Element 0420 0421* 0430

42 Card acceptor ID M M -

43 Card acceptor name/location M M -

49 Currency code, transaction M M M+

50 Currency code, settlement C C C+

54 Additional amounts - - C

64 MAC code R R R

90 Original data element M M M

102 Account 1 identification C C C

103 Account 2 identification C C C

120 Additional Data C C C+

121-123 Private use C C C*

128 MACCode2 R R R

*Reversal 421 messages will be send 3 times after logon message is received from bank if NPCI

fails to get response of 420 message.

2.2.4 Data Element Definitions

DE 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 eachbit signifies presence (1) or absence (0) in the message of the data element (DE-65 to DE-128)associated with that particular bit.

Field Edits None.

Constraints C: Element is present only if message contains any of data elements from range DE-65to 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 AADHAARnumber. It is mandatory for all 02xx and 04xxmessages. Normal length of this field is 19 digits.

Field Edits: If present, it should be echoed in response and all subsequent messages. For all othertransactions (including authentication transaction) except FT transaction, this field should haveinitiator‟s AADHAAR number. But for FT transaction, this field should have beneficiary‟s AADHAARnumber.

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

Structure:


14/90



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 thatwhenever NPCI sends addendums or circular without any changes in the systems it can beincorporated.

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 bythe transaction. It consists of three, two-digit sub fields:

Digit 1 and 2: Transaction Code:

00 Purchase of goods/services01 Cash withdrawal10 Biometric Verification (UID Biometric data verification/Authentication) for ONUS20 Credit, refund

21 Deposit22 Credit adjustment31 Balance inquiry45 Transfer90 Extended transaction type**

Digit 3 and 4: From Account Type*00 Unspecified/unknown10 Savings20 Checking30 Credit card

Digit 5 and 6: To Account Number*

00 Unspecified/unknown10 Savings20 Checking30 Credit card

Summary of processing code used for AADHAAR based transactions:

Cash withdrawal – 010000Balance inquiry – 310000Deposit – 210000Finger print authentication – 100000Fund Transfer – 900000

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


15/90



NOTE:*Other values may be used for optional features.

Field Edits: If present, it should be echoed in response and all subsequent messages.

Constraints: None

DE 4—Amount, Transaction

Format: Fixed

Type: n12

Description: It is the amount of funds requested by the customer in the local currency of theacquirer.

Field Edits: It should be echoed in response and all subsequent messages. For a balance enquirytransaction, 0200 message should carry all zeros in DE 4. For all request with processing code100000 bit corresponding to DE 4 must be off.

Constraints: None

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

Field Edits: It should be echoed in response and all subsequent messages.

Constraints: None

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. Itmust be different for every transaction even for multiple set of transactions originated at the sametime.

Field Edits: STAN is set by a message sender and echoed by the message receiver.

NOTE: It should not be date or time or similar to DE 7

DE 12—Local Transaction Time

Format: Fixed

Type: n-6; hhmmss

Description: Time, Local Transaction (DE 12) is the local time the transaction takes place at thepoint of service. It is the same to be printed on receipt.


Constraints: None

DE 13—Local Transaction Date

Format: Fixed


16/90



Type: n-4; MMDD

Description: Date, Local Transaction (DE 13) is the local month and day on which the

Transaction takes place at the point of service. It is the same to be printed on receipt.


Constraints: None

DE 15—Settlement Date

Format: Fixed

Type: n-4; MMDD

Description: Settlement Date (DE 15) is the date (month and day) that funds will beTransferred between an acquirer and an issuer.


Constraints: C: Field is present if a) Field DE-50 is present or b)MTID is 0800 and DE-70=201(cutover message).

DE-18 Merchant Category Code (MCC)

Format: Fixed

Type: n4

Description: MCC is four-digit code. The data element is mandatory for 02xx request messages. Itis never present in response messages.

The proposed values are:

6012 – Micro ATM AADHAAR transactions (If member banks want to support AADHAAR transactionsthrough their biometric ATMs then it will be 6011).

6010 – for regular POS device.


Constraints: None

DE-22 Point of Service Entry Mode

Format: Fixed

Type: n3

Description: The code describing the way PAN and PIN are entered at a touch point.

Data element consists of two sub-fields:

PAN Entry Mode01 Manual02 Magnetic stripe read.05 ICC.90 Full and unaltered magnetic stripe read (enables CVV validation).

PIN Entry Mode0 Unspecified.1 PIN entry capability.2 No PIN entry capability.


17/90



6 PIN pad inoperative.9 Reserved for private use

The data element is mandatory for 02xx, and 04xx request messages. It is never present in

response messages.


Constraints: None

DE-25 Point of Service Condition Code

Format: Fixed

Type: n2

Description: Two-digit code indicating conditions at touch point:

00 Normal01 Customer not present.

02 Unattended terminal (CAT, ADM)03 Merchant suspicious.05 Customer present, card not present.07 Telephone request.08 MO/TO request.

Field Edits: it should be echoed in response and all subsequent messages.

Constraints: None

DE-32 Acquiring Institution Identification Code

Format: LLVAR

Type: n…11

Description: Identifies the acquiring institution for the transaction, or its agent. The value will bedefined by the host. The data element is mandatory for 02xx and 04xx request messages. It isoptional for 08xx messages.


Constraints: O: Member can choose whether to use DE-32in 08xx messages or not.

Note - NPCI shall assign appropriate codes to the participating banks to be used in this field.

DE-37 Retrieval Reference Number

Format: Fixed

Type: an12

Description: The reference, assigned by the acquirer, to identify a transaction uniquely. It remainsunchanged for all messages throughout the life of a transaction and is used for matching original

message with reversal and/or store/forward messages. The standard format of RRN is as follows:

YDDDHHSSSSSS

Y – Year (last digit of current year)

DDD – Julian date of transaction

HH – Hour of transaction

SSSSSS – STAN of transaction (Same as in DE -11)


18/90



The data element is mandatory for 02xx, and 04xx request messages. The RRN can be used for theentire dispute management of the transaction lifecycle.In verification request value of DE-37 should be same as original remittance transaction RRN

Edit Field: It must be echo back in response message

Constraint: None

DE-39 Response Code

Format: Fixed

Type: an2

Description: This code indicates the disposition of a message as detailed tables below.

Each code is associated with specification code that is to be taken:

A Approve transactionD Decline transaction

Field Edits: In reversal and store/forward requests, value identifies there as on for reversal orstore/forward message.

Constraints:The following is the addendum covering different scenarios for UID specific situations andappropriate Response codes supported for declined UID transactions in addition to the existingresponse codes referred in the NPCI Host-to-Host specification document. Message to be printedon Receipt is also specified.

0210 Response Code

NPCIerror

Code

UIDAIError

Code

Description Action Message to bedisplayed at

AcquirerMicroATM

Message tobe displayed

on MicroATM

Receipt to beprinted by

MicroATM

00 - SuccessfulTransaction

Approved SuccessfulTransaction

Yes Yes

91 - NPCI doesn‟t get anyresponse from Issuerafter sending therequest

Decline Transactiondeclined. Pleasetry again (91)

Yes Yes

08 - NPCI is not able tosend the request atall to issuer

Decline Transactiondeclined. Pleasetry again(08)

Yes Yes

92 - Invalid IIN entered atTerminal (IIN notpresent in routingtable)

Decline Invalid IIN(92) Yes No

52 - Correct Aadhaar No.and correct IINentered at terminal(IIN present in routingtable). Accountnumber is not present

in CBS. Transactiondeclined by NPCI.

Decline InvalidAccount(52)

Yes Yes

51 - Insufficient Fundavailable in

Decline InsufficientFunds(51)

Yes Yes


19/90



Resident‟s account.Transaction declinedby Issuer.

57 - Account blocked byIssuer/Regulator forAML or any other

appropriate reasons

Decline Account blocked(57)

Yes Yes

AY - Aggregate of allcredits in a financialyear exceed Rs 1 Lakh

Decline Total annualcredits exceedlimit(AY)

Yes Yes

AM - Aggregate of allwithdrawals andtransfers in a monthexceeds Rs. 10,000

Decline Monthly limitexceeded fortransactions(AM)

Yes Yes

AB - Account Balanceexceeds rupees fiftythousand

Decline Account Balanceexceeds limit(AB)

Yes Yes

M4 - Remittance from/toForeign/NRE Accounts

Decline ForeignRemittance notallowed(M4)

Yes Yes

UW - Transaction amountexceeded limit,transaction isdeclined by Issuer.

Decline Transaction

amount

exceeded

limit(UW)

Yes Yes

M6 - Net Debit Cap limit isexhausted formember bank.Transaction is

declined by NPCI.

Decline Limit exceededfor memberbank(M6)

No No

U1 100 Identity attribute ofdemographic detailsdoes not match

Decline Identity attributeof demographicdetails does notmatch(U1)

No No

U2 200 Address attribute ofdemographic detailsdoes not match

Decline Address attribute

of demographic

details does not

match(U2)

No No

U3 300 Biometric data did

not match

Decline Biometric data

did notmatch(U3)

Yes No

U4 500 Encryption of sessionkey is invalid

Decline Transaction

declined. Please

try again(U4)

Yes No

U5 510 Invalid XML format Decline Transaction

declined. Please

try again(U5)

Yes No

U6 520 Invalid device Decline Wrong Terminal

ID (U6)

Yes Yes


20/90



U7 530 Invalid authenticatorcode

Decline Invalid

authenticator

code(U7)

Yes No

U8 540 Invalid version Decline Invalid version

(U8)

Yes No

U9 550 Invalid “Uses”element attribute

Decline Invalid “Uses”

element

attribute(U9)

No No

UA 700 Invalid demographicdata

Decline Invalid

demographic

data(UA)

No No

UB 710 Missing “Pi” data asspecified in “Uses”

Decline Missing “Pi” dataas specified in“Uses” (UB)

No No

UC 720 Missing “Pa” data asspecified in “Uses

Decline Missing “Pa” dataas specified in“Uses” (UC)

No No

UD 730 Missing PIN data asspecified in “Uses”

Decline Missing PIN dataas specified in“Uses” (UD)

No No

UE 999 Unknown error Decline Transactiondeclined. Please

try again(UE)

Yes No

UF 740 Missing OTP data asspecified in “Uses”

Decline Missing OTP data

as specified in

“Uses” (UF)

No No

UG 800 Invalid biometric data Decline Invalid biometric

data(UG)

Yes No

UH 810 Missing biometric

data as specified in“Uses”

Decline Missing biometric

data as specifiedin “Uses” (UH)

No No

UI - Time Out for therequest sent to UIDAIfrom NPCI beyond 10seconds (likeresponse not receivedfor AuthenticationRequest

Decline Transaction

Declined. Please

try again(UI)

Yes No

UJ 721 Missing "Pfa" data asspecified in "Uses"element

Decline Missing "Pfa" data

as specified in

"Uses"element(UJ)

No No


21/90



UK 820 Missing or emptyvalue for "bt"attribute in "Uses"element

Decline Missing or empty

value for "bt"

attribute in

"Uses"

element(UK)

No No

UL 821 Invalid value in the"bt" attribute of"Uses" element

Decline Invalid value in

the "bt" attribute

of "Uses"

element(UL)

No No

UM 901 No auth factors found

in auth request. This

corresponds to

scenario wherein all

the 3 factors - Pin,

Demo and Bios - are

not present in Authrequest

Decline No auth factors

found in auth

request(UM)

No No

UN 902 Invalid "dob" value in

"Pi" element. Invalid

dates are one which

are not of the format

YYYY or YYYY-MM-DD,

or have a year value

such that residents

age is less than 0 or

more than 150 years,or contains value

which cannot be

parsed e.g.

alphabetic strings,

invalid dates such as

31-Feb, etc

Decline Invalid "dob"

value in "Pi"

element. (UN)

No No

UO 910 Invalid "mv" value in

"Pi" element. This

error is returned if

mv value is not a

numeric value or is

not in the allowed

range.

Decline Invalid "mv"

value in "Pi"

element. (UO)

No No

UP 911 Invalid "mv" value in

"Pfa" element .This

error is returned if

mv value is not a

numeric value or is

not in the allowed

range.

Decline Invalid "mv"

value in "Pfa"

element(UP)

No No

UQ 912 Invalid "ms" value in"Pa" (If matchstrategy other than E

Decline Invalid "ms" value No No


22/90



is used) in "Pa"(UQ)

UR 913 Both Pa and Pfa arepresent (Pa and Pfaare mutuallyexclusive)

Decline Both Pa and Pfa

are present(UR)

No No

US 930 Technical errorcategory 1 (Relatedto ABIS interactions)

Decline Transactiondeclined. Pleasetry again(US)

Yes No

UT 931 Technical errorcategory 2 (Internalto auth server such asDatabase serverdown, etc.)

Decline Transactiondeclined. Pleasetry again(UT)

Yes No

UU 932 Technical errorcategory 3 (Error if

audit XML could notbe published to auditqueue, or if auditXML could not beconstructed)

Decline Transactiondeclined. Please

try again(UU)

Yes No

UV 980 Unsupported option(At present, this erroris returned if OTP isused which is yet tobe implemented)

Decline Unsupported

option(UV)

No No

UX 933 Request delayed formore than 24 hrs. Decline Transactionrequest older

than 24 hrs. (UX)

Yes No

UY 511 Invalid PID XMLformat

Decline Invalid PID XML

format(UY)

No No

UZ 940 Unauthorized ASAchannel

Decline Unauthorized

ASA channel(UZ)

No No

U0 941 Unspecified ASAchannel

Decline Unspecified ASA

channel(U0)

No No

V0 561 Request expired(“Pid->ts” value isolder than N hourswhere N is aconfigured thresholdin authenticationserver)

Decline Please correct

your terminal

date & time and

then try again.

(V0)

Yes No

V1 562 Timestamp value isfuture time (valuespecified “Pid->ts” isahead of

authentication servertime beyondacceptable threshold)

Decline Please correct

your terminal

date & time and

then try again.

(V1)

Yes No


23/90



V2 563 Duplicate request(this error occurswhen exactly sameauthenticationrequest was re-sentby AUA)

Decline Transaction

Declined;

Please re-enter

all details

again(V2)

Yes No

V3 564 HMAC Validationfailed

Decline Transactiondeclined. Pleasetry again(V3)

Yes No

V4 565 License key hasexpired

Decline Transactiondeclined. Pleasetry again(V4)

Yes No

V5 566 Invalid license key Decline Transactiondeclined. Pleasetry again(V5)

Yes No

V6 567 Invalid input (thiserror occurs when

some unsupportedcharacters werefound in Indianlanguage values,“lname” or “lav”)

Decline Invalid input(V6) No No

V7 568 Unsupportedlanguage

Decline Unsupportedlanguage(V7)

No No

V8 569 Digital signatureverification failed(this means thatauthentication

request XML wasmodified after it wassigned)

DeclineDigital signatureverificationfailed (V8)

No No

V9 570 Invalid key info indigital signature (thismeans thatcertificate used forsigning theAuthenticationrequest is not valid – it is either expired,or does not belong to

the AUA or is notcreated by a well-known CertificationAuthority)

Decline Invalid key info

in digital

signature(V9)

No No

VA 571 PIN Requires reset(this error will bereturned if resident isusing the default PINwhich needs to bereset before usage)

Decline PIN Requires

reset(VA)

No No

VB 572 Invalid biometricposition (This error isreturned if biometricposition value - “pos”

Decline Invalid biometricposition(VB) Yes No


24/90



attribute in “Bio”element - is notapplicable for a givenbiometric type -“type” attribute in“Bio” element.)

VC 573 Pi usage not allowedas per license

Decline Pi usage notallowed as perlicense (VC)

No No

VD 574 Pa usage not allowedas per license

Decline Pa usage notallowed as perlicense (VD)

No No

VE 575 Pfa usage not allowedas per license

Decline Pfa usage notallowed as perlicense (VE)

No No

VF 576 FMR usage not

allowed as per license

Decline FMR usage not

allowed as perlicense (VF)

No No

VG 577 FIR usage not allowedas per license

Decline FIR usage notallowed as perlicense (VG)

No No

VH 578 IIR usage not allowedas per license

Decline IIR usage notallowed as perlicense (VH)

No No

VI 579 OTP usage not

allowed as per license

Decline OTP usage not

allowed as perlicense(VI)

No No

VJ 580 PIN usage not allowedas per license

Decline PIN usage notallowed as perlicense (VJ)

No No

VK 581 Fuzzy Matching usagenot allowed as perlicense

Decline Fuzzy Matchingusage notallowed as perlicense(VK)

No No

VL 582 Local language usage

not allowed as perlicense

Decline Local language

usage notallowed as perlicense (VL)

No No

VM 934 Technical errorcategory 4

Decline Transactiondeclined. Pleasetry again(VM)

Yes No

VN 935 Technical errorcategory 5

Decline Transactiondeclined. Pleasetry again(VN)

Yes No

VO 936 Technical errorcategory 6

Decline Transactiondeclined. Pleasetry again(VO)

Yes No

VP 937 Technical errorcategory 7

Decline Transactiondeclined. Pleasetry again(VP)

Yes No


25/90



VQ 938 Technical errorcategory 8

Decline Transactiondeclined. Pleasetry again(VQ)

Yes No

VR 939 Technical errorcategory 9

Decline Transactiondeclined. Pleasetry again(VR)

Yes No

VS 811 Missing biometricdata in CIDR for givenAADHAAR

Decline Contact Aadhaarcentre18001801947 (VS)

Yes yes

VT 501 Invalid certificateidentifier in “ci”attribute of “Skey”.

Decline Transactiondeclined. Pleasetry again(VT)

Yes No

VU 502 Invalid encryption ofPid

Decline Transactiondeclined. Pleasetry again(VU)

Yes No

VV 503 Invalid encryption ofHmac

Decline Transactiondeclined. Pleasetry again(VV)

Yes No

VW 542 AUA not authorizedfor ASA.

Decline Transactiondeclined. Pleasetry again(VW)

Yes No

VX 543 Sub-AUA notassociated with“AUA”

Decline Transactiondeclined. Pleasetry again(VX)

Yes No

DE-41 Card Acceptor Terminal Identification

Format: Fixed

Type: an8

Description: It should carry value “ public” in the 0200 request for all transactions originated froma device unregistered at UIDAI data base. For devices recognized by UIDAI, this code will beallotted by UIDAI the data element is mandatory for 02xx and 04xx request messages.

NOTE: ― public‖ must be left padded with 2 spaces making it a 8 digit value only.


DE-42 Card Acceptor Identification Code

Format: Fixed

Type: an15

Description: Identifies the acceptor in a transaction and if they accept or is different from theacquiring institution. Special characters (including national character support characters) are notallowed since some networks or back-office systems may have problems accepting thesecharacters. The data element is mandatory for 02xx and 04xx request messages.


Character 1-15 Merchant Name / Bank Correspondent Name

DE-43 Card Acceptor Name/Location


26/90



Format: Fixed

Type: an40

Description: The name and location of the acceptor (Touch Point), which defines the point ofservice in both local and interchange environments. Special characters (including national

character support characters) are not allowed since some networks or back-office systems mayhave problems accepting these characters. Data element consists of the sub-fields detailed in thetable below. The data element is mandatory for 02xx and 04xx request messages.


Character 1-23 Merchant Address / Bank Correspondent Address

Character 24-36 City Name

Character 37-38 State

Character 39-40 Country Code (IN)

DE-45 Track 1 Data

Format: Fixed

Type: ans…76

Description: Track 1 data as encoded by Issuer. The standard track structure is as follows:

Card Magnetic Stripe Personalization data

Track 1 Structure Symbol Description Character code / No. of Characters

STX Start Sentinel %FC Format Code BCard No Card number Up to 19 digitsFS Separator ^NM Name 2 to 26 charactersFS Separator ^ED Expiration Date Four digitsSC Service Code Three digitsDD Discretionary Data In discretionary Data first three

characters should be CVD1. The12 digit AADHAAR number of thecustomer should start from the

4th digit with character ‗A‘ asprefix.ETX End Sentinel ?LRC Longitudinal Redundancy 1 character

For card present transactions track 1 data is mandatory.

DE 49—Transaction Currency Code

Format: LLLVAR

Type: n-3

Description: The Currency Code, Transaction (DE 49) is the code defining the local currency of theacquirer bank. For all request with processing code 100000 bit corresponding to DE 49 must be off.

Field Edits: None


27/90



Constraints: Data element is present for UID based 02xx response messages.

DE 54—Additional Amounts

Format: Fixed

Type: an...120; LLLVAR

Description: It provides information for a maximum of six amounts. It must be populated in 0210message for all transaction type with account balance.

Field Edits: It must be populated in 0210 message for all transaction type with account balance.

Constraints: None

DE-62 Private Use Field 62 – UIDAI Authentication Code

Format: LLLVAR

Type: an999

Description: This Element is used in the response message to send the Authentication Codereceived from the UIDAI server; NPCI will send the authentication code to the acquirer in response.

Field Edits: It should be sent back to acquirer bank in response to be displayed in response for allONUS transactions, For all offus transactions, NPCI must pass it on to issuer bank to carry the samein their 210 response.

Constraints: C: Data element is present for UID based 02xx response messages.

DE-63 Private Use Field 63 – UID Biometric Authentication Data

Format: LLLVAR

Type: an999

Description: This Element is encrypted containing finger print minutiae collected at the Micro ATM.Data will contain single minutiae or other UID authentication payload.

Field Edits: None

Constraints: C: Data element is present for UID based 02xx request messages.

Elements Description:

DE63 is structured as TLV (Tag, length and value) field. The details of tags and contents aredescribed below:

Tag Length Description Valid Value

001 Up to 999 characters Encrypted Biometric Data only Encrypted Biometric Data only

Example:

Let‟s assume XML tags along with Biometric are 430 bytes. The structure of DE63 is shownbelow:

436001430

Parsing of field is done as follows:

436 is the length of the string for DE63.


28/90



Tag 001 represents biometric which is of length 430.

DE 70—Network Management Information Code

Format: Fixed

Type: n-3

Description: This data element indicates the specific classification and purpose of networkmanagement (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 2014 handshake 002 002

Response code for 0810 message must be carried in DE 39 as 00 for successful request.

Constraints: None

DE-90 Original Data Element

Format: Fixed

Type: n42

Description: This data element contains parts of the original message being reversed or adjustedand is used to match reversal/adjustment to previous authorization or financial transactionmessage(s). This data element consists of sub-elements which are described below:

Sub-elements description:

Position Length Field Name Description

01-04 4 Original MTID MTID of original request

05-10 6 Original STAN DE11 of original request

11-14 4 Original Local Date DE12 of original Request

15-20 6 Original Local Time DE13 of original request

21-31 11 Original Acquiring Institution ID DE32 of original request

32-42 11 Not used (to be filled with zero) --

DE-102 Account Identification 1

Format: LLVAR

Type: ans28

Description: A series of digits used to identify a customer account. It denotes the “From” accountnumber involved in the transaction (e.g. the Debit account in withdrawal or transfer transaction.The account number in the Account Identification1 field must be right justified with leading zeros.

Usage:

In AADHAAR based Fund transfer transactions, issuer bank must send “from account number” whichis debited for the transfer amount. The account number should be asked as per banks policy.


29/90



Field Edits: If present, should be echoed in all subsequent messages.

Constraints: C: The data element is used in 02xx and 04xx messages, whenever account

information must be transferred.

DE-103 Account Identification 2

Format: LLVAR

Type: ans28

Description: A series of digits used to identify a customer account. It denotes “to” account numberinvolved in the transaction (e.g. the credit account in deposit or transfer transaction. The accountnumber in the Account Identification1 field must be right justified with leading zeros.

Usage:

In the AADHAAR based Fund transfer transactions, beneficiary bank must send the Beneficiary‟saccount number to which the amount was credited.

Field Edits: If present, should be echoed in all subsequent messages.

Constraints: C: The data element is used in 02xx and 04xx messages, whenever accountinformation must be transferred.

DE-120 Additional Data

Format: LLLVAR

Type: an999

Description: These fields are Tag-based.

Usage:

The generic description of DE120 is as follows:

…

Tag number size is 3, Tag length is represented as LLL and Tag data is as per requirement

DE2 will contain sender AADHAAR no for fund transfer.

0200 message from acquirer / Issuer to NPCI (for FT acquirer and issuer are same)

Tag Description Length Value

001 Transaction type 2 45(for fund transfer) or 07(for mini statement)

002 Product indicator 3 UID(for fund transfer) or GDN(for mini statement)

005 No. of entries in themini statement data

002 06 (variable, used only for mini statement)

006 Actual Ministatement data

210 Each statement will be of 35 character (used only for mini statement)

045 Sender Name 20 Sender Name

060 Sender AADHAAR no. 19 Sender AADHAAR no. with IIN. FormatBBBBBB0UUUUUUUUUUUU (refer DE2 structure)

0200 message from NPCI to beneficiary bank









30/90




0210 message from beneficiary to NPCI



005 No. of entries in the

mini statement data





046 Beneficiary Name 20 Beneficiary Name


0210 message from NPCI to acquirer / issuer





006 Actual Ministatement data 210 Each statement will be of 35 character (used only for mini statement)


046 Beneficiary Name 20 Beneficiary Name


The sender and beneficiary name will be carried as a part of message but only sender andbeneficiary AADHAAR no. will be stored at NFS system for record purpose.

Field Edits: The contents of field may change in responses depending on result of transaction.

Constraints: C: Must be present in AADHAAR based Fund transfer transaction based Fund transfer.

DE-127 Additional Data

Format: LLLVAR

Type: an999

Description: These fields are Tag-based. They will carry „skey‟, „ci‟, „Hmac‟, „ac‟, „sa‟ and „lk‟ intag 001, tag 002, tag 003, tag 004, tag 005 and tag 006 respectively

Constraints: C: Data element is present for UID based 02xx request message

Tag Length Type Format Description Valid Value001 As per

theprocess

Variable an Skey(Value of this elementis encrypted 256-bit AESsession key.)

Digest value

002 8 Fixed YYYYMMDD ci (Public key certificateidentifier using which “skey”was encrypted)

It is the expiry dateof the UIDAI publickey, a constantvalue.

003 As pertheprocess

Variable an Hmac (for description on

Hmac please refer to

http://uidai.gov.in/images/

FrontPageUpdates/aadhaar_

authentication_api_1_5_rev

1_1.pdf )

SHA -256 Hash of PIDXML and thenencrypted

004 010 Fixed an ac (A unique code for the An Alpha numeric

http://uidai.gov.in/images/FrontPageUpdates/aadhaar_authentication_api_1_5_rev1_1.pdfhttp://uidai.gov.in/images/FrontPageUpdates/aadhaar_authentication_api_1_5_rev1_1.pdfhttp://uidai.gov.in/images/FrontPageUpdates/aadhaar_authentication_api_1_5_rev1_1.pdfhttp://uidai.gov.in/images/FrontPageUpdates/aadhaar_authentication_api_1_5_rev1_1.pdfhttp://uidai.gov.in/images/FrontPageUpdates/aadhaar_authentication_api_1_5_rev1_1.pdfhttp://uidai.gov.in/images/FrontPageUpdates/aadhaar_authentication_api_1_5_rev1_1.pdfhttp://uidai.gov.in/images/FrontPageUpdates/aadhaar_authentication_api_1_5_rev1_1.pdfhttp://uidai.gov.in/images/FrontPageUpdates/aadhaar_authentication_api_1_5_rev1_1.pdfhttp://uidai.gov.in/images/FrontPageUpdates/aadhaar_authentication_api_1_5_rev1_1.pdf


31/90



Elements Description:

DE 127 is structured as TLV (Tag, length and value) field. The details of tags and contents aredescribed below:

Example:Let‟s assume that skey length is 256 bytes, ci length is 8 bytes, Hmac is 48 bytes, ac is 10bytes, sa is 10 bytes and lk is 64 bytes. The structure of DE127 is shown below:432001256002008003048004010005010006064

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 char4. Tag 004 represents ac which is of length 10 char5. Tag 005 represents sa which is of length 10 char6. Tag 006 represents lk which is of length 64 char

Usage:

The generic description of DE127 is as follows:

…

AUA which is assigned byUIDAI during AUAregistration process)

value up to 10characters

005 010 Fixed an sa (A unique “Sub-AUA”code, managed by AUA

within their system andensure uniqueness. If AUAand SA are same agency, usevalue of “ac” for thisattribute.)

An Alpha numericvalue up to 10

characters

006 064 Fixed an lk (A valid “License Key”assigned to the AUA throughadministration portal ofUIDAI. These license keyshave expiry built into themand AUA administrator needto ensure that they generate

new license keys beforecurrent ones expires throughself-service portal.)

An Alpha numericvalue up to 64characters


32/90



3.0 Changes for Member Banks as Acquirer and Issuers

3.1 Changes for Acquirer Members

a. Establish connection with Micro ATM and switch.

b.

Addition of new transaction in the interface to existing NFS Switch

c. Changes in the current reconciliation system to reconcile the interchange and switching fees forAADHAAR based transactions.

d. Acquirer switch to generate and process reversal request.

e. MicroATM must be capable to generate Last Transaction Status (LTS) request and acquirerswitch should response the status back to the MicroATM.

f. Changes to generate and process reversal messages.

g. MicroATM application must be able to store all request originating from the device in anelectronic log. These logs will include details of original transaction request, LTS request &reversal requests and will act as proofs while settling disputes for any transaction.

h.

MicroATM application must be capable to push the “Electronic Log” to acquirer bank switch, atthe end of Business day.

3.2 Changes for Issuer Members

a.

Addition of new transaction in the interface to existing NFS Switch

b.

Changes in the current recon system to reconcile the interchange and switching fees forAADHAAR based transactions.

c. Changes to generate and process reversal messages.

3.3 Changes in NPCI systems

a. Addition of new transaction in existing NFS switch

b. Changes in online dispute management system for new rules

c.

Changes in billing system for these new transaction types.

d.

Changes to develop new reports and raw data files.

e. Changes to generate and process reversal messages.


33/90



4.0 Settlement and Reconciliation

4.1 Settlement and Reconciliation

Following are the changes in the settlement and reconciliation process,

1. Addition of these transaction in the existing acquirer raw data file and issuer raw data file circulatedby NPCI AEPS operation team to member banks.

2.

Addition of this transaction in the existing acquirer activity report and issuer activity report circulatedby NPCI AEPS operation team to member banks.

4.2 Dispute Management Cycle

Following are the changes in the settlement and reconciliation process,

1. NPCI will also form an arbitration committee with nominated members of member banks to decide onmember banks.

2.

Dispute Cycle - The various possible dispute scenarios have been given here to enable member banksto refer to and resolve Interbank settlement issues:

a. Aadhaar to Aadhaar Funds Transfer:

Scenario: The Remitting Bank has debited the Remitting customer‟s Account. The BeneficiaryBank has made the Credit to the Beneficiary‟s Account too. The status of the remittancetransaction in the NPCI switch, however, is timed-out.

Solution: Beneficiary Bank is advised to raise a Debit Adjustment on the Remitting Bank. Theresulting interbank settlement will resolve the problem.

All time out scenarios in Aadhaar to Aadhaar Funds Transfers will be handled as per AEPS DMSguidelines.

b. Aadhaar Initiated Cash Withdrawals:

For all Cash Withdrawal transactions, dispute management will be in the same manner as in NFS.

Case i) Issuer Bank has debited the customer‟s Account. But due to a time -out, Cash was notdispensed by the acquirer– Interbank settlement also failed.

Issuer to reverse the debit made to the customer account by passing internal transfertransactions.

Case ii) Issuer Bank has debited the customer‟s account. But due to a time-out between the NPCIswitch and the acquirer switch, cash was not dispensed by the acquirer. Interbank settlementhowever, was successful.

There are two options as under:

a. A Chargeback may be raised by Issuer (Representment to be raised by Acquirer if the chargeback is disputed)

b. A pro-active Credit Adjustment by the Acquirer. (If an Acquirer sends a proactive creditadjustment, it should be ensured that a charge back by the issuer is also not allowed. i.e.

Either Acquirer or Issuer will originate an interbank adjustment and not both.)

c. Aadhaar Initiated Cash Deposit Transactions:


34/90



Case i) the customer‟s account was credited with the cash deposit at the Issuer bank. Due to timeout, the Cash was returned to the customer by the acquirer. Interbank settlement also failed dueto time out status in the NPCI switch.

Issuer bank will simply reverse the credit by passing internal transfer transactions.

Case ii) the customer‟s account was credited with the cash deposit at the Issuer bank. Due totime out received by the Acquirer, the Cash was returned to the customer. However, interbanksettlement was successful.

The Acquirer will raise a Debit Adjustment with a request to the issuer to reverse the creditmade.

3. This transaction cycle will following timelines:a. 1st chargeback - Issuer needs to raise this within 60 days from the transaction date.

b. Representment – Within 5 days of the receipt of the chargeback for acquirer needs torepresent.

c.

Credit Adjustment – Acquirer can raise this within 60 days from the transaction date.

d. Debit Adjustment – Acquirer can raise this within 17 days from the transaction date.

e. Chargeback on Debit Adjustment- Chargeback on Debit Adjustment will be 17 days from thenext day of Debit Adjustment raised.

f.

Pre-Arbitration-Pre-arbitration will be 30 days after the Representment date

g. Arbitration- Arbitration will be 30 days from the pre-arbitration rejection date.

h. Good faith-The time frame for raising Good Faith would be 60 days from the expiry of theregular TAT

4. Separate additional report for only AADHAAR based transactions for acquirer and issuer banks.

5. Settlement cycle for all these transactions will be 23:00 to 23:00 for all days as per the current NFSsettlement windows.

NOTE: Please refer to AEPS DMS guidelines for more information on handling disputes.


35/90



5.0 Risk Management

Following will be the risk management done by all the member banks:

1.

Issuer Bank will be responsible to do all the following checking,

a. Balance authorization

b. Account Validations/Verifications.

c.

Number of Transactions in a day for the specific Account product

d. Maximum limit in a day for the specific card product

e. Issuer banks will either not store the UID authentication data or store it in encrypted formats asper PCI guidelines.

f. AML related validations for Funds Transfer transaction.

g.

Fraud Check

h. Duplicate (Multiple) reversals and original transactions.

i. All other validations

j. Issuer bank will connect to NPCI network on NPCINET.

2. Acquirer Bank will be responsible for following checking,

a.

Acquirer shall not log the Biometric data on the switch.

b. Transaction and incoming message validation coming from Micro ATM.

c.

Ensure card entry mode and pin entry mode to be present in the request.

d. Unique key management for the terminals.

e. Acquirer banks will either not store the UID authentication data or store it in encrypted formats asper PCI guidelines.

f. Issuer bank will connect to NPCI network on NPCINET.


36/90



6.0 Exception Conditions

Exception conditions for which reversals would be generated:

In case, NPCI doesn‟t receive the response for a 200 Request message from Issuer, NPCI would send 210Response to Acquirer with Response Code „91‟ and generate a Reversal Request (420) message withResponse Code „91‟ to Issuer Bank, which should reverse the transaction in CBS and respond with ResponseCode „00‟ in 430 Reversal Response message to NPCI.

If NPCI does not get 0430 response from Issuer within 20 seconds it will generate 0421 message thrice

after a logon is received from bank.

In case, Acquirer Bank switch doesn‟t receive a 210 Response message for the request due to time out, itshould generate a 420 Reversal Request Message with Response Code „68‟, NPCI will send the message to


37/90



Issuer Bank and Issuer needs to reverse the transaction in CBS and respond with 430 message containingResponse Code „00‟.

If NPCI does not get 0430 response from Issuer within 20 seconds it will generate 0421 message thriceafter a logon is received from bank.

Please refer AEPS reversal cases for complete information on reversals.


38/90


39/90


40/90



(BBBBBB0UUUUUUUUUUUU)

3 310000 Processing code fixed for Balance Inquiry

4 000000000000 Amount Fixed value – Zero

7 MMDDhhmmss Transmission date and time

11 SSSSSS System Trace Audit Number

12 HHMMSS Time

13 MMDD Date

15 MMDD Settlement Date (conditional)

18 6012 6012 for Micro ATM

22 01 9 or 02 9 Manual (01), Card Reader present (02)Reserved for private use (9)

25 05 Customer present card not present

32 ACQ Inst ID ID already allotted by NPCI

37 YDDDHHSSSSSS Y – Year (last digit)DDD – Julian DateHH- HourSSSSSS – System Trace Audit Number

41 Card Acceptor Terminal Identification Public

42 Card Acceptor Identification code Merchant Name43 Card Acceptor Name / Location Address of BC

45 Track 1 data As encoded in Card for card presenttransaction

49 356 Currency Code

62 UIDAI Auth Code (Max. 40 Characters) Unique Authentication Code generated byUIDAI

0210 message (from Issuer to NPCI) Data

elementValue Comment

2 IIN + AADHAAR(BBBBBB0UUUUUUUUUUUU)

Customer details

3 310000 Processing code fixed for Balance Inquiry

4 000000000000 Amount Fixed value – Zero



12 HHMMSS Time

13 MMDD Date

15 MMDD Settlement Date (optional)


37 YDDDHHSSSSSS Y – Year (last digit)DDD – Julian DateHH-HourSSSSSS – System Trace Audit Number

39 00 Success response code

41 Card Acceptor Terminal Identification Public42 Card Acceptor Identification code Merchant Name

43 Card Acceptor Name / Location Address of BC


54 Amount Account Balance


0210 message (from NPCI to Acquirer) Data



Customer details

3 310000 Processing code fixed for Balance Inquiry4 000000000000 Amount Fixed value – Zero




41/90



12 HHMMSS Time

13 MMDD Date



37 YDDDHHSSSSSS Y – Year (last digit)DDD – Julian Date

HH-HourSSSSSS – System Trace Audit Number


41 Card Acceptor Terminal Identification public

42 Card Acceptor Identification code Merchant Name





7.4 Message dump for Interbank Cash Withdrawal

0200 message (from Acquirer to NPCI)Data

ElementValue Comment

1 Valid value Secondary Bitmap


Customer details

3 010000 Processing code fixed for CW

4 Amount Withdrawal amount



12 HHMMSS Time13 MMDD Date












63 Biometric Data(PID XML) Bio metric data from finger print scanner

127 Skey, ci, Hmac and ac, sa, lk Captured from terminal and fed by AUAserver, respectively

0200 message (from NPCI to Issuer)Data


2 IIN + AADHAAR

(BBBBBB0UUUUUUUUUUUU)

Customer details




42/90





12 HHMMSS Time

13 MMDD Date










45 Track 1 data As encoded in Card for card present

transaction49 356 Currency Code


0210 message (from Issuer to NPCI) Data



Customer details





12 HHMMSS Time13 MMDD Date








49 356 Currency Code54 Amount Account Balance


0210 message (from NPCI to Acquirer) Data



Beneficiary details




11 SSSSSS System Trace Audit Number12 HHMMSS Time

13 MMDD Date



43/90






41 Card Acceptor Terminal Identification Public42 Card Acceptor Identification code Merchant Name





7.5 Message dump for Interbank Cash Deposit

0200 message (from Acquirer to NPCI)

DataElement

Value Comment



Customer details

3 210000 Processing code fixed for CD

4 Amount Deposit amount



12 HHMMSS Time

13 MMDD Date


18 6012 6012 for Micro ATM22 01 9 or 02 9 Manual (01), Card Reader present (02)

Reserved for private use (9)









63 Biometric Data(PID XML) Bio metric data from finger print scanner

127 Skey, ci, Hmac and ac, sa, lk Captured from terminal and fed by AUAserver, respectively

0200 message (from NPCI to Issuer)Data



Customer details



7 MMDDhhmmss Transmission date and time11 SSSSSS System Trace Audit Number

12 HHMMSS Time


44/90



13 MMDD Date





32 ACQ Inst ID ID already allotted by NPCI37 YDDDHHSSSSSS Y – Year (last digit)

DDD – Julian DateHH- HourSSSSSS – System Trace Audit Number






62 UIDAI Auth Code (Max. 40 Characters) Unique Authentication Code generated by

UIDAI0210 message (from Issuer to NPCI) Data



Beneficiary details





12 HHMMSS Time

13 MMDD Date


32 ACQ Inst ID ID already allotted by NPCI37 YDDDHHSSSSSS Y – Year (last digit)

DDD – Julian DateHH-HourSSSSSS – System Trace Audit Number







62 UIDAI Auth Code (Max. 40 Characters) Unique Authentication Code generated by

UIDAI0210 message (from NPCI to Acquirer)

Dataelement

Value Comment


Beneficiary details





12 HHMMSS Time

13 MMDD Date

15 MMDD Settlement Date (optional)32 ACQ Inst ID ID already allotted by NPCI

37 YDDDHHSSSSSS Y – Year (last digit)DDD – Julian Date


45/90



HH-HourSSSSSS – System Trace Audit Number








7.6 Message dump for Interbank Fund Transfer Transaction

0200 message (from Remitter Bank to NPCI)Data




Beneficiary details

3 900000 Processing code fixed for FT

4 Amount Transfer amount



12 HHMMSS Time

13 MMDD Date



22 019 Manual (01) Reserved for private use (9)


32 ACQ Inst ID Temporary ID already allotted by NPCI37 YDDDHHSSSSSS Y – Year (last digit)

DDD – Julian DateHH-HourSSSSSS – System Trace Audit Number






102 Sender Account Detail Optional

120 00100245002003UID045020060019IIN+ AADHAAR no.

Tag 001 – Length 002 – 45Tag 002 – Length 003 – UIDTag 045 – Length 020 - (optional)Tag 060 – Length -019 – IIN + AADHAAR(BBBBBB0UUUUUUUUUUUU)

0200 message (from NPCI to Beneficiary) Data



Beneficiary details

3 900000 Processing code fixed for FT




12 HHMMSS Time


46/90


47/90






12 HHMMSS Time

13 MMDD Date


32 ACQ Inst ID Temporary ID already allotted by NPCI








102 Sender Account detail Optional120 00100245002003UID045020046020060019IIN+ AADHAAR no.

Tag 001 – Length 002 – 45Tag 002 – Length 003 – UIDTag 045 – Length 020 - (optional)Tag 046 – Length 020 - (optional)Tag 060 – Length -019 – IIN + AADHAAR(BBBBBB0UUUUUUUUUUUU)

7.7 Message dump for Reversal request

0420 message (From Acquirer to NPCI)Data



2 IIN + AADHAAR no. Sender „s AADHAAR no.

3 Processing Code Processing code for original transaction

4 Amount Original transaction amount



12 HHMMSS Time

13 DDMM Date





32 AcqInst ID ID already allotted by NPCI

37 YDDDHHSSSSSS Y – Year (last digit)DDD – Julian DateHH - HourSSSSSS – System Trace Audit Number

39 00 Response code



43 Card Acceptor Name / Location Address of BC49 Track 1 data As encoded in Card for card present

transaction

90 Valid values Original transaction data


48/90



102 Valid values FROM Account

0420 message (From NPCI to Issuer) Data



2 IIN + AADHAAR no. Sender „s AADHAAR no.

3 Processing Code Processing code for original transaction4 Amount Transfer amount



12 HHMMSS Time

13 DDMM Date







39 00 Response code







0430 message (From Acquirer to NPCI)Data



2 IIN + AADHAAR no. Customer „s AADHAAR no.

3 Processing Code Processing code for original transaction




12 HHMMSS Time

13 DDMM Date







39 00 Response code








49/90



0430 message (From NPCI to Issuer) Data



2 IIN + AADHAAR

SOP BC Interoperability - Interface Specifications

Documents

Transcript of SOP BC Interoperability - Interface Specifications