IMPS Online Switching Specification Newv3 3docx

IMPS –Online Switching Message Specification
Version3.3 (May, 2014)

Documents Details
Author
DIPTIMAN CHAKRABORTY
Published Date
June 2013
Version
2.0
Total Page number
84
Document classification
Confidential
Document History
Version Change
Original Draft Nov, 2012
Final Version June, 2013
June 2013 2.0
Version 3.2 March,2014
Version 3.3 May,2014
Prepared By: Date

Diptiman Chakraborty 01 Dec 2012
Ankit Agrawal 15 June 2013
N Sailesh Kumar 05 May, 2014
Reviewed By: Date

Sumit Kashyap 13 May 2013
Dheeraj Bhardwaj
Sateesh Palagiri 15 May 2013
Approved By: Date

Ram Rastogi
Saiprasad Nabar
Bharat Panchal
Ram Sundaresan
CTO
COO
CEO
IMPS – Online Switching Message Specification

v2.0 Year 2013 [Confidential] Page 2 of 96
Table of Contents
IMPS –Online Switching Message Specification .......................................................................................1

Version3.0 (June, 2013) ............................................................................................................................1
1.0 Objective ................................................................................................................... 8
1.1 About Immediate Payment Service (IMPS) ................................................... 8
1.2. Background.............................................................................................................. 8
2.0 Introduction to ISO8583 ...................................................................................... 9
2.1 Introduction ............................................................................................................. 9
2.2 Message Structure .................................................................................................. 9
2.2.1 Message Header ................................................................................................... 9
2.2.2 Message Type Identifier .................................................................................... 9
2.2.3 Bit Map ..................................................................................................................10
2.2.4 Data Elements .....................................................................................................11
3.0 Remittance Architecture ..................................................................................12
3.1 Architecture Diagram .......................................................................................................... 12
3.1 Transaction flow:.................................................................................................13
4.0 Technical Specifications......................................................................................17
5.0 Standard Interface ..............................................................................................20
5.1 Transaction Flows (step by step) ....................................................................21
5.2 Billing (Switching and Interchange Fee) .........................................................22
5.3 Certification and Migration of banks ............................................................22
5.4 Application for Initiation ..................................................................................23
6 Changes Required .....................................................................................................23
6.1 IMPS End ...............................................................................................................23
6.2 Bank end................................................................................................................................. 24
6.2.1 Banks which have not implemented P2M Push ..................................................... 24
6.2.2 Banks which have implemented P2M Push ............................................................ 24
• They don’t need to make any changes in the application or SMS facility already provided. .... 24
6.2.3 Banks who have not yet implemented Remarks and originating channel .... 25
• As a remitter, the request shall be sent without these fields. ITM shall check if the beneficiary
bank has implemented these fields or not. If implemented, ITM shall include those fields and send
to beneficiary bank with blank values. If not, ITM shall send as it is. ................................................ 25
6.2.4 Banks who have implemented Remarks and originating channel ................... 25
6.2.5 Banks who have not yet implemented MCC............................................................ 25

6.2.6 Pricing model implementation at Banks (those that have or haven’t
implemented P2M PUSH)........................................................................................................... 26
7 DMS – Interchange and disputes ..........................................................................26
8 MIS 26
9 Annexure .....................................................................................................................27
9.1 Standard Interface for Push Transactions ......................................................27
10.0 Data Elements ......................................................................................................29
10.1 DE-2 Primary Account Number, PAN .............................................................30
10.2 DE-3 Processing code .........................................................................................31
10.3 DE-4 Amount, Transaction ...............................................................................32
10.4 DE 7 – Date and Time, Transmission ............................................................32
10.5 DE 11 – STAN ........................................................................................................33
10.6 DE 12- Time, Local Transaction .....................................................................33
10.7 DE 13- Date, Local Transaction ......................................................................34
10.8 DE 15 - Date, Settlement ..................................................................................34
10.9 DE 18- Merchant Category Code .....................................................................35
10.10 DE 22- POS Entry MODE.................................................................................36
10.11 DE 25- POS Condition Code ...........................................................................36
10.12 DE 32-Acquiring Institution Code................................................................37
10.13 DE 37-Retreival Reference Number .............................................................38
10.14 DE 38-Authorization Identification Response .........................................38
10.17 DE 39-Response Code ......................................................................................39
10.18 DE 41-Card Acceptor Terminal Id ................................................................42
10.19 DE 42-Card Acceptor Id ..................................................................................43
10.20 DE 43-Card Acceptor Name/Location .........................................................44
10.21 DE 48-Additional Data .....................................................................................45
10.22 DE 49-Currency Code, Transaction .............................................................46
10.23 DE 70 -Network management information code......................................46
10.24 DE 102 - Account Identification 1 ...............................................................47
10.25 DE 103 - Account Identification 2 ...............................................................47
10.26 DE 120-Private Field ........................................................................................48
For P2P & P2M (Original Message) ...........................................................................48
For P2P & P2M (Verification Message) ....................................................................49
For P2A (Original Message) .........................................................................................49
For P2A (Verification Message) .................................................................................50

11.0 SMS Confirmation to Customer ......................................................................51
11.1 For NORMALtransaction SMS to customer as follows:.............................51
11.2 For MERCHANT SMS to customer as follows: .............................................53
11.3 For P2A SMS to customer as follows: ............................................................56
11.4 MMID process through SMS .............................................................................57
12.0 Additional transaction flows ............................................................................60
13.0 Maximum Response Time .................................................................................74
14.0 Reports ...................................................................................................................75
14.1 Account statement of customer ................................................................................................ 75
14.2 Account statement of merchant ................................................................................................ 76
15.0 IMPS to AADHAAR Transfer (P2U) ..................................................................77
16.12 Remitter bank changes .......................................................................................................... 87
16.13 Beneficiary bank changes....................................................................................................... 87
16.14 DMS changes .......................................................................................................................... 88
16.15 Banks enabled for account number / IFSC code based funds transfer .................................. 88
16.16 SMS formats ........................................................................................................................... 88
17.0 IMPS Foreign Inward Remittance ...................................................................89
17.1 Scope ...................................................................................................................................... 89
17.2 Process ................................................................................................................................... 90
17.3 Change in IMPS Specification ................................................................................................. 91
18.0 Reports ...................................................................................................................95

This page is intentionally left blank]

1.0 Objective
The objective of the approach paper is to create a standard IMPS interface and application (on access
channels) for IMPS “Push” based transactions.
1.1 About Immediate Payment Service (IMPS)
Currently majority of interbank mobile fund transfer transactions are channelised through NEFT
mechanism. Under NEFT, the transactions are processed and settled in batches, hence are not real time.
Also, the transactions can be done only during the working hours of the RTGS system.
In the above context, NPCI has carried out a pilot on mobile payment system initially with 4 member
banks viz State Bank of India, Bank of India, Union Bank of India and ICICI Bank in August 2010. Yes Bank,
Axis Bank and HDFC Bank have joined this pilot in month of September, October and November 2010
respectively. Immediate Payment Service (IMPS) public launch happened on 22nd November 2010 by
Smt. Shyamala Gopinath, DG RBI at Mumbai and this service is now available to the Indian public.
IMPS offers an instant, 24X7, interbank electronic fund transfer service through mobile phones. IMPS
facilitate customers to use mobile instruments as a channel for accessing their bank accounts and put
high interbank fund transfers in a secured manner with immediate confirmation features.
1.2. Background
IMPS was launched in November 22, 2010 with 4 Pilot member banks and its basic service known as
Person to Person (P2P) which allows customers to initiate fund transactions essentially using their
mobile phones and entering the Mobile number and MMID of the beneficiary. The channel was further
extended to Internet and ATM banking channel for the convenience of the customers and increase in
transactions.
In order to increase the scope of the service the P2P service has been enhanced to facilitate commercial
transactions and known as Person to Merchant (P2M) with both Push and Pull Transaction flows and
Person to Account (P2A) using Account number and IFS Code. Prepaid Payment Issuer (PPI) transactions
have also been added to IMPS. Further AADHAAR based transactions (P2U) on IMPS are also being on
IMPS.

2.0 Introduction to ISO8583
2.1 Introduction
This document defines the Host-to-Host Message Specifications. It provides clear understanding of the
online message specifications and serves as a basic document for future enhancements. Host-to-Host
message specification is capable of supporting both remitter and beneficiary. Messages to be used for
the connection between the NPCI Central switch, remitter and beneficiary and will be based on ISO-
8583 standard. It provides a general overview of the underlying logic for all transaction flow scenarios.
2.2 Message Structure
The message structure is based on ISO 8583 standards as defined in the following figure:
A message comprises of the following components:
Message Element Description

Message Header Contains the length of message
Message type identifier. Specifies general message category like
MTI
authorization, administrative advice etc.
Specifies which data elements are present
Primary bit map indicates the presence of DE 1 to 64
Bit Map
Secondary bit map indicates the presence of DE 66 to 128
Data Concatenated data element

A message structure can be further described as:
2.2.1 Message Header
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.

2.2.2 Message Type Identifier
This is a 4 digit numeric field which includes ISO 8583 version, the message class, the message function,
and the message origin.
2.2.3 Bit Map
Within ISO 8583, a bitmap is a field or subfield within a message which indicates which data elements
may be present elsewhere in a message. The message text segment of all messages transmitted through
NPCI Central switch is of variable length, with bit maps that specify which fields are present and which
are not. The valid combinations of bit map are:
1. Primary bit map
2. Primary and secondary bit map
3. Primary, secondary and tertiary bit map
A message will contain at least one bit map, called the primary bit map, which indicates which of the
data elements from 2 to 64 are present.
Primary bit map: A message will contain at least one bit map, called the primary bit map, which
indicates which of the data elements from 2 to 64 are present.
 Every message includes the bit map, Primary.
 Except for the first bit, each bit is associated with the corresponding data field, that is, with data
fields from 2 through 64.
 Bit value -0- field associated with that bit is not present
 Bit value -1- field associated with that bit is present
Example of primary bit map is as follows:
In the above figure bit 2, 6 16, 17, 24, 25, 36, 40, 45, 55 and 57 are present.
Secondary bit map: The 1st bit within a bitmap, when set to 1, denotes the presence of an additional
contiguous 64 bit bitmap i.e. 65 to 128 fields is present.

 Secondary Bit map is an extension of a Primary Bit map because it is associated with fields 66
through 128.
 When no tertiary bit map is defined, the first bit of the secondary bit map must be 0.
 The secondary bit map is included only when the message contains information in any field
from 66 through 128.
 In the above example the first bit in the bitmap is 1 which indicates that a Secondary bitmap is
present
 Here, the message includes field 72, so position of bit 72 in the secondary bitmap is 1.
Note:
The message exchanged between the bank switch and the NPCI switch will use the ASCII character set.
2.2.4 Data Elements
Refer to chapter 10.0 for detailed description of data elements.

3.0 Remittance Architecture
3.1 Architecture Diagram
NPCI switch will be upgraded to support IMPS remittance transactions and settlement. Member banks
or service provider of member banks on behalf of member banks shall connect to NPCI switch based on
the interface specifications defined in this document.
Mobile Payment Service Provider (MPSP) of the member banks are expected to connect to NPCI central
switch either directly or through the existing switch interface supporting the enhanced specifications
mentioned in this document. This connectivity will be secure close loop connectivity as per existing
guidelines of connecting to NFS switch.

3.1 Transaction flow:
3.2.1 Remittance Transaction
Note – Above listed data elements are only indicative and the detail bitmap needs to be referred while
forming the request and response message. The transaction flow is depicted above for funds transfer
from account of customer of Bank 1 to Bank2 where the transaction is initiated by mobile banking
customer of Bank1.
Online Debit and Online credit is envisaged in this transaction and beneficiary bank is expected to
respond with beneficiary’s account number and name in the response message Remitter bank shall
debit the remitter account and send an authorized transaction to IMPS, which shall be routed to the
beneficiary bank based on the NBIN (which is part of MMID entered by customer) for online credit to
the beneficiary account.

3.2.2 Verification Transaction
Note – Above listed data elements are only indicative and the detail bitmap needs to be referred while
forming the request and response message.
The transaction flow is depicted above for verification of funds transfer request. This request is system
generated. Original data element will be populated in DE120 by the Remitter bank.
Beneficiary bank is expected to respond with the beneficiary name and response code
“00” for successful verification and credit transaction & “M0” for credit not successful but verification is
successful. The response of status for the verification transactions would be sent from the CBS of the
bank. Only in the case of M0 response auto reversal will be generated by remitting bank to their
customer. Timeout scenarios for verification request:
1. In case of timeout scenarios Remitting bank will send the Verification Request post timeout
period of Original Transaction (30 Sec)
2. The Verification request will carry the Original Transaction Elements. (Remitting Bank is
required to send max up to 3 Retrieval Requests for one transaction, if it does not get a
response)
3. In case remitting bank does not get the status of the 3 Verifications sent, it will initiate upto max
6 more verification request after interval of 10 min each.
4. Beneficiary bank will respond to this request as per status of the original transaction
5. Based on response to this request, Remitting Bank may reverse the earlier debit.
6. NPCI at the end of the day will ensure that status of the verification request transaction is
reflected in the settlement.

3.2.3 Guideline for Error Handling and Verification Request
Bank 1
Error Condition – Timeout Bank 2
Beneficiary’s Mobile Re mitte r’s na me ,

number, MMID a nd a mount
a mount
Bank 1/ NPCI Bank 2 /

MPSP 1 MPSP 2
2 3
4
1
Timeout Scenarios -
Timeout Scenarios -
Cus tomer Cus tomer
Accounts 3. After Debit between NPCI and Beneficiary
Accounts Bank
1. (CBS)Debit – Between Remitting Ba nk a nd its CBS
During 1. This transaction is responded(CBS)
by timeout response
code by NPCI and send to remitting bank. Upon
1. Revers a l will be genera ted by Remitting ba nk
receiving a timeout response. Remitting bank will send
s ys tem to CBS a nd the tra nsaction is not
1 proces s ed further. Cus tomer is a ppropriately 3 out a Verification Request giving the reference
number of the original transaction to NPCI and if the
informed. response of the verification request is “M0” then
2. After Debit between Remitting Bank and NPCI remitting bank will reverse the earlier debit.
1. Remitting Ba nk will treat this a s timeout 4. After Debit between Beneficiary Bank Switch and CBS
tra ns a ction ; Remitting ba nk will s end out a 1. This transaction is responded by timeout response
2 Verification Request giving the reference number code by Beneficiary bank to NPCI and NPCI passes it to
of the origina l tra ns action to NPCI a nd ba sed on remitting bank. Remitting bank will send out a
the verifica tion reques t res pons e will revers e the 4 Verification Request giving the reference number of
ea rlier debit. the original transaction to NPCI and if the response of
the verification request is “M0” then remitting bank
will reverse the earlier debit.
Bank 1
Error Condition – Timeout Bank 2
Beneficiary’s Mobile Remitter’s name,

number, MMID and amount
amount

MPSP 1 MPSP 2
2 3
4
1
Timeout Scenarios -
Timeout Scenarios -
Customer Customer
Accounts 3. Afte r De bi t be tween NPCI a nd Be neficiary
Accounts Ba nk
1. (CBS)Debit – Between Remitting Bank and its CBS
During 1. Thi s tra nsacti on i s re sponded by ti meout re sponse
(CBS)
code by NPCI a nd s e nd to re mi tting bank. Upon
1. Reversal will be generated by Remitting bank
re ce i vi ng a ti meout re sponse. Re mitting bank wi ll s end
system to CBS and the transaction is not
1 processed further. Customer is appropriately 3 out a Verification Request gi vi ng the re fere nce
numbe r of the ori ginal tra nsaction to NPCI a nd if the
informed. re s ponse of the ve ri fication re quest is “M0” the n
2. After Debit between Remitting Bank and NPCI remi tti ng ba nk will reverse the earlier debit.
1. Remitting Bank will treat this as timeout 4. Afte r De bi t be tween Be neficiary Ba nk Switch a nd CBS
transaction ; Remitting bank will send out a 1. Thi s tra nsacti on i s re sponded by ti meout re sponse
2 Verification Request giving the reference number code by Be ne ficiary ba nk to NPCI a nd NPCI pa sses i t to
of the original transaction to NPCI and based on re mi tti ng ba nk. Re mitting ba nk will se nd out a
the verification request response will reverse the 4 Verification Request gi vi ng the re fe rence number of
earlier debit. the ori gi nal tra nsaction to NPCI a nd i f the re sponse of
the veri fi cation request i s “M0” then remi tting bank
wi l l re ve rs e the e arlier de bit.

Bank 1
Declined Transaction Bank 2
Beneficiary’s Mobile Remitter’s name,

number, MMID and amount
amount

MPSP 1 MPSP 2
Negative Response from Credit Leg Or Beneficiary Bank X

Process Flow
X
Customer Customer
Accounts 1. Beneficiary Bank rejects the transaction with Accounts
(CBS) negative response code. (CBS)
2. NPCI will pass on the negative response (Non Zero
response code) with the specific reason code to the
remitting bank.
3. Remitting bank system is suppose to reverse (credit)
back the previous debit.
4. SMS or notification is sent to the remitting customer
with specific response code.
5. The decline from beneficiary bank can be due to
multiple reasons such as account validations, wrong
MMID/Mobile, other reasons etc.

4.0 Technical Specifications
The Push based transactions for P2P, P2A and P2M are similar in the Interface specification. Below table
shows the differences and similarities in the product specifications:
MTID TAG Data Element 200 210 P2P P2M P2A

Secondary bit
1 C- C Yes Yes Yes
map
Primary
2 Account M M+ Yes Yes Yes
Number
Processing
3 M M+ Yes Yes Yes
code
Amount,
4 M M+ Yes Yes Yes
transaction
Amount,
5 settlement C C+ Yes Yes Yes
Date/time,
7 M M+ Yes Yes Yes
transmission
Fee, card
8 holder billing R R Yes Yes Yes
Conversion
rate,
9 C C+ Yes Yes Yes
settlement
11 STAN M M+ Yes Yes Yes
Time, local
12 M M+ Yes Yes Yes
transaction
Date, local
13 M M+ Yes Yes Yes
transaction
Date,
15 C C+ Yes Yes Yes
settlement
18 Merchant type M - Yes Yes Yes
POS entry
22 M - Yes Yes Yes
mode
POS condition
25 M - Yes Yes Yes
code
POS PIN
26 capture code C - Yes Yes Yes
Acquirer
32 M M+ Yes Yes Yes
institution ID

Track2data
35 C - Yes Yes Yes
Retrieval
37 reference M M+ Yes Yes Yes
number
Authorization
38 - C Yes Yes Yes
number
39 Response code - M Yes Yes Yes
Card acceptor
41 M M+ Yes Yes Yes
terminal ID
Card acceptor
42 M - Yes Yes Yes
ID
Card acceptor
43* C - Yes Yes Yes
name/ location
Additional
48 M M Yes Yes Yes
Data
051 Product Code M M
058 Fraud Score C C
Currency code,
49 M M+ Yes Yes Yes
transaction
Currency code,
50 settlement C C+ Yes Yes Yes
PIN Block
52 C - Yes Yes Yes
Additional
54 amounts - C Yes Yes Yes
Account1
102 C C+ Yes Yes Yes
identification
Account2
103 C C Yes Yes Yes
identification
Additional
M M+ Yes Yes Yes
Data
Transaction
1 M M+ 45 47 48
Type
Product
120 2 M M+ Yes Yes Yes
Indicator
Remitter
45 M M+ Yes Yes Yes
Name
Beneficiary
46 M Yes Yes Yes
Name

Beneficiary
49 M - Yes Yes Yes
MAS
Remitter
50 MMID+ Mobile M M+ Yes Yes Yes
No
51 Remarks O O+ Yes Yes Yes
Merchant
53 O No Yes No
Location
Customer
54 O O+ No Yes No
Location
Originating
56 M M+ Yes Yes Yes
Channel
57 MCC - M No Yes No
58 Error Free text O No Yes No
59 IFSC M M+ No No Yes
62 Beneficiary A/c M M+ No
No Yes
121-
Private use C C*
123
128 MAC Code2 R R
*-DE 43 is mandatory for Merchant initiated transaction.
MTID Differences
The differences in the interface are observed in the below MTIDs and the Tag values therein:
Data
MTID TAG 200 210 P2P P2M P2A
Element
Additional
48 51 M M+ Yes Yes Yes
Data
Transaction
1 M M+ 45 47 48
Type
Beneficiary
49 M Yes Yes Yes
MAS
Merchant
53 O O+ No Yes No
Location
Customer
120 54 O O+ No Yes No
Location
57 MCC M No Yes No
Error Free
58 O No Yes No
text
59 IFSC M M+ No No Yes
Beneficiary
62 M M+ No No
A/c Yes

5.0 Standard Interface
The different products have different elements to be populated in the interface as per the account
types, transaction status and such validations to be done at the bank end. It is proposed to create a
single interface which can be integrated at the bank end.
Banks will have to build and manage only a standard interface and front end application w.r.t IMPS
Push transactions. This will help banks get live on all products (P2P,P2A, P2M, P2U and PPI) and
channels (Mobile, ATM, Internet, POS, WAP or USSD, BRC) with one integration, this will also require
only single certification to be done at NPCI and monitoring for all the products of the bank.
IMPS P2P and P2A form can be used for making payment to merchants as well with the below changes:
I. A new field ‘Remarks’ is required to be added to P2P/P2A form, and for many banks, this field
has been added, and for others, it is in the process of getting added. Even if ‘Remarks’ field is
not available at the Remitter Bank, the merchant transaction can still go through unless
Beneficiary Bank declines the transaction, for that particular merchant.
II. The identification of the transaction would be done from the values populated from 0210
message in DE 120 Tag 056. The beneficiary banks will prefix “M” in front of the channel
identifier sent by the remitter bank as value for merchant beneficiary accounts. Thus the Tag 56
values i.e MMOB, MATM, MNET, MSDC, MSDB, MPOS, MBRC will be identified in the IMPS
system as merchant transactions and will be updated in the report accordingly, rest of the
values shall be considered as individual transactions.
III. If Remitter Bank is not enabled, but Beneficiary Bank is enabled, Remarks and originating
channel (default value will be “MOB”) will be added as blank (by ITM) in the request and sent
to Beneficiary Bank. Beneficiary Bank shall send the Remarks (blank) and Originating channel
(depending on individual or merchant) in response, but will be dropped at ITM before sending
the response to Remitter Bank.
IV. If Remitter Bank is enabled, but Beneficiary Bank is not enabled, Remarks and Originating
channel shall be dropped at ITM before sending to Beneficiary Bank. In the response, ITM shall
add Remarks and Originating channel and send across to Remitter Bank. These transactions
shall be considered as individual transactions. For merchant transactions, the Beneficiary Bank
necessarily needs to be enabled for Remarks and originating channel, so proper values can be
populated.
V. If Remitter Bank and Beneficiary Bank both are enabled, Remarks and originating channel shall
be carried in request and response for the transaction.
VI. The value of Remarks and originating channel as available in the ITM shall be available in MIS
reports and DMS of IMPS.
VII. MCC:

Beneficiary bank will also populate the MCC codes specified as per the list provided in NPCI P2M
specification. The value could be used to compute the Interchange & Switching fee for the
settlement for the banks. We are not using MCC for doing any calculations in the current
proposal. This may be a future requirement, but not the current requirement. MCC is not
getting populated in the P2P and P2A system currently. Some banks may add this tag earlier
than others, so we shall need to devise a way of knowing which banks have implemented the
same or not, so that the tag in request/response can be added/dropped accordingly.
The MCC code in the interface will be optional in common interface.

A. If remitter Bank is not enabled, but beneficiary bank is enabled, MCC will be added as
blank (by ITM) in the request and sent to Beneficiary Bank. Beneficiary Bank shall send
the MCC in response, but will be dropped at ITM before sending the response to
Remitter Bank.
B. If Remitter Bank is enabled, but Beneficiary Bank is not enabled, MCC shall be dropped
at ITM before sending to Beneficiary Bank. In the response, ITM shall add MCC (blank)
and send across to Remitter Bank.
C. If Remitter Bank and Beneficiary Bank both are enabled, MCC shall be carried in request
and response for the transaction.
The value of MCC as available in the ITM shall be available in MIS reports and DMS of IMPS
MCC shall be populated as per P2M specifications. For individual transaction, it can be
populated as 1111.
5.1 Transaction Flows (step by step)
Case 1: Remitter & Beneficiary Bank are enabled on Standard Interface (merchant transaction)
 Remitter bank will send the transaction (0200 message) with type 45 or 48, populate value in
Tag 51 (as entered by user) and Tag 56 as MOB/INET/USDC etc,
 NPCI will pass the transaction to Beneficiary bank-NPCI may pass the relevant Tags to
beneficiary
 Beneficiary bank will identify the beneficiary account as merchant and credit the account after
verifying the reference details
 Beneficiary bank will pass success response to NPCI and will populate Tag 51 (echo of request
value), Tag 56 value as MMOB, MNET etc and Tag 57 value as specified (if enabled)
 NPCI will pass the transaction to remitter bank as successful
Case 2: Remitter Bank is not enabled and beneficiary bank is enabled on Standard Interface (Merchant
transaction)
 Remitter bank will send the transaction (0200 message) with type 45 or 48
 NPCI will pass the transaction to Beneficiary bank and add tags (Remarks, originating channel,)
as appropriate and enabled

 Beneficiary bank will identify the beneficiary account as merchant and credit the account after
verifying the reference details
 Beneficiary bank will pass success response to NPCI and will populate Tag 51 (echo of request
value), Tag 56 value as MMOB, MNET etc and Tag 57 value as specified (if enabled)
 NPCI will drop Tag 51, 56, 57 at its end and send the transaction to remitter bank as successful
Case 3: Remitter Bank is enabled and beneficiary bank is not enabled on Standard Interface (merchant
transaction)
 Remitter bank will send the transaction (0200 message) with type 45 or 48 populate value in
Tag 51 (as entered by user) and Tag 56 as MOB/INET/USDC etc,
 NPCI will drop the tags 51, 56 and pass the transaction to Beneficiary bank
 Beneficiary bank will respond to the request with proper response
 NPCI will add Tag 51, 56( & Tag 57 if provided by beneficiary) at its end and send the transaction
to remitter bank as successful
5.2 Billing (Switching and Interchange Fee)
The billing and settlement would be done from the values populated from DE 120 Tag 56. Following
scenarios would be there:
Switching Fee Interchange Fee

S.No Tag 56 Remitter Beneficiary Remitter Beneficiary
MMOB, MNET, MATM,MPOS,
MSDC,MSDB,
MSMS,MWAP,MIVR,MMAT,
1 MBRC No Yes No Yes
2 Other Yes No Yes No
In case of differential interchange is to be calculated based on the type of merchant, the provision of
MCC (Tag 57) can be used.
5.3 Certification and Migration of banks
The base of the common interface will be existing Product type 45 which will not require development
for new products and will bring existing banks on P2M automatically. All other banks would require
making only the development and migrate to product type 46 and the standard interface for type 45.
Once banks move into product type 45, the product 47 can be phased out at banks, if they wish.
The development for P2A will also help processing the transactions for P2U. The same will be ensured
during certification with the banks.

5.4 Application for Initiation
One application requires to be developed by bank for the customer to use on his mobile/ internet or
POS for capturing the details for the transaction.
Application screen can be as below:
5.4.1 IMPS
5.4.2 Using Mobile No and MMID
 Enter Mobile NO
 Enter MMID
 Amount
 Remarks Field
 MPIN
5.4.3 Using Account No and IFS Code
 Enter Account No
 Enter IFS Code Amount
 Remarks Field
 MPIN
5.4.4 Using SMS for transaction
5.4.2.1 SMS Syntax
<IMPS><Mobile No >< MMID><Amount><MPIN><Remarks>
<IMPS><Account No><IFSC><Amount><MPIN><Remarks>
6 Changes Required
6.1 IMPS End
• Changes in DMS to calculate interchange and switching fee on the basis of Tag 56
• If remitter customer uses P2M form for making remittance, NPCI shall check if beneficiary bank
is enabled on P2M or not. If not enabled, NPCI shall convert the request to P2P and send to
beneficiary bank. Beneficiary bank shall respond as usual. If originating channel is MMOB, MNET
etc interchange related to P2M shall be applicable. Else interchange for P2P shall be applicable.
Interchange can further be determined based on MCC value.

6.2 Bank end
• DE-102 needs to be populated with account number of remitter and sent across in 0200 request
• DE-102 shall be echoed in 0210 response

• Update DE 120 TAG 56 as per beneficiary account type
6.2.1 Banks which have not implemented P2M Push
• Banks who have not yet implemented P2M PUSH functionality don’t need to develop the same
• They can bring merchants on P2P/P2A itself
• If remitter customer uses P2P/P2A form for making remittance, the beneficiary Bank shall
respond as they shall enable merchant on P2P/P2A
is enabled on P2M or not. If not enabled, NPCI shall convert the request to P2P and send to
beneficiary bank. Beneficiary bank shall respond as usual. If originating channel is MMOB, MNET
etc interchange related to P2M shall be applicable, else interchange for P2P shall be applicable.
Interchange can further be determined based on MCC value.
• Add Remarks and originating channel field (prefix M in case of P2M transaction) in bank
application and request (0200) message.
• MCC population in response (0210) based on the beneficiary type (person or merchant).
• If Beneficiary Bank receives transaction with blank payment reference, they can reject the
transaction, if the merchant requires payment reference mandatorily. This can help in avoiding
any credits from Banks that have not yet implemented payment reference field and avoid
reconciliation issues
• Bank should implement the above change before on-boarding any merchant on IMPS platform.
• M1 text can be replaced with ‘Invalid / Unverified beneficiary credentials’ (to include both MA
and MF)
6.2.2 Banks which have implemented P2M Push
• They don’t need to make any changes in the application or SMS facility already provided.
• New merchants shall be enabled for P2M push as well as for P2P/P2A, bank to identify if
beneficiary is individual or merchant and update the Tag 56 value in 0210 accordingly.
• Any existing merchants shall be enabled for P2P as well, so customers can make payments using
P2P/P2A form too, and there are no declines.
is enabled on P2M or not. If enabled, NPCI shall send the request with transaction type ‘47’ to
Beneficiary bank, and beneficiary bank shall respond to the same as per current P2M
specifications. If Beneficiary is not merchant, Bank can reject transaction with current RC (MK).

If Beneficiary Bank is not enabled on P2M (but enabled on Standard Interface), NPCI shall
convert the request to P2P and send to beneficiary bank. Beneficiary bank shall respond as
usual. If originating channel is MMOB, MNET etc interchange related to P2M shall be applicable.
Else interchange for P2P shall be applicable. Interchange can further be determined based on
MCC value.
• Can phase out P2M PUSH functionality going forward, if they wish.
• M1 text can be replaced with ‘Invalid / Unverified beneficiary credentials’ (to include both MA
and MF).
6.2.3 Banks who have not yet implemented Remarks and originating
channel
• As a remitter, the request shall be sent without these fields. ITM shall check if the beneficiary
bank has implemented these fields or not. If implemented, ITM shall include those fields and
send to beneficiary bank with blank values. If not, ITM shall send as it is.
• As a beneficiary, bank should add merchant only if they have at least included the above two
fields. If “remarks” is blank, they shall check if merchant requires this and shall decline if this is
mandatory for merchant. They shall populate MMOB, etc in originating channel and send to
ITM.
• ITM shall send response to remitter bank in the format as accepted by remitter bank (without
remarks and originating channel)
6.2.4 Banks who have implemented Remarks and originating channel
• As a remitter, the request shall be sent with these fields. ITM shall check if the beneficiary bank
has implemented these fields or not. If implemented, ITM shall send as it is, otherwise, ITM shall
remove those fields and send to beneficiary bank.
• As a beneficiary, bank should add merchant only if they have at least included the above two
fields. If “remarks” is blank, they shall check if merchant requires this and shall decline if this is
mandatory for merchant. They shall populate MMOB, etc in originating channel and send to
ITM.
• ITM shall send response to remitter bank in the format as accepted by remitter bank (with
remarks, originating channel). Remitter bank can then take care of whether to charge customer
or not for the transaction.
6.2.5 Banks who have not yet implemented MCC
• As a remitter, the request shall be sent without this field. If it is sent by beneficiary bank, ITM
shall check if the remitter bank has implemented this field or not. If implemented, ITM shall
include this field and send to remitter bank. If not, ITM shall send as it is.
• As a beneficiary, bank will not send MCC if this field has not yet been enabled.

• ITM shall send response to remitter bank in the format as accepted by remitter bank
(enabled/not enabled for MCC)
6.2.6 Pricing model implementation at Banks (those that have or haven’t

implemented P2M PUSH)
• Remitter bank can know if transaction was P2P or P2M by the originating channel in the
response. If originating channel is MMOB, MNET etc interchange related to P2M shall be
applicable. Else interchange for P2P shall be applicable. Based on that, Remitter bank can
charge customer transaction fee, or not charge. Interchange can further be determined based
on MCC value.
• In case of time-out, the beneficiary type (individual or merchant) shall be provided by

beneficiary bank in debit adjustment or good-faith debit adjustment, so same rule could be
applied on whether to charge customer transaction fee or not.
7 DMS – Interchange and disputes

• In DMS, the system shall determine interchange based on the originating channel. If originating
channel is MMOB, MNET etc interchange related to P2M shall be applicable. Else interchange
for P2P shall be applicable. Interchange can be further determined by MCC in case of merchant
transaction. MCC shall be populated in DMS from ITM as well.
• Credit adjustment facility is already applicable for P2P
• Chargeback and other related disputes such as representment, etc are not available for P2P, we
shall need to apply the rules that are currently applicable for P2M PUSH for P2P as well. Specific
requirement regarding this needs to be arrived at in discussion with all, and procedural
guidelines to be updated, if required.
• On debit adjustment raise and good-faith debit adjustment, Beneficiary Bank shall specify if
beneficiary is individual or merchant, since DMS will not have this information in case of time-
out scenarios, and this is required for interchange settlement. MCC shall be entered by
Beneficiary bank too if merchant transaction at the time of raising debit adjustment and good-
faith debit adjustment
• During import from ITM to DMS, the transaction shall be marked as individual or merchant
transaction based on originating channel value. MCC shall be populated in DMS from ITM as
well (if available)
• In credit adjustment, different reason code for P2P and P2M. These can be merged.
8 MIS
Raw data files, settlement reports, verification files, daily settlement file, daily volume report,
decline transaction report, hourly report, service tax report, interchange service tax report need
to be updated appropriately based on individual or merchant transaction

9 Annexure
9.1 Standard Interface for Push Transactions
MTID Data Element 200 210
1 Secondary bit map C- C
2 Primary Account Number M M+
3 Processing code M M+
4 Amount, transaction M M+
Amount, settlement
5 C C+
7 Date/time, transmission M M+
Conversion rate , settlement

9 C C+
11 System Trace Audit Number M M+
12 Time, local transaction M M+
13 Date, local transaction M M+
15 Settlement Date M -
18 Merchant type M -
22 POS entry mode M -
25 POS condition code M -
26 POS PIN capture code C -
32 Acquirer institution ID M M+
Track2data
35 C -
37 Retrieval reference number M M+
38 Authorization number - C
39 Response code - M
41 Card acceptor terminal ID M M+

Card acceptor Identification
42 M -
code
43 Card acceptor name / location C -
48 TAG Additional Data M M
051 Product Code M M+
058 Fraud Score M -
49 Currency code, transaction M M+
Currency code, settlement

50 C C+
PIN Block
52 C -
Additional amounts
54 - C
102 Account1 identification C C+
103 Account2 identification C C
TAG Detail
001 Transaction Type M M+
002 Product Indicator M M
045 Remitter Name M M+
046 Beneficiary Name M
120 049 Beneficiary MAS M
050 Remitter MMID+ Mobile No M M+
051 Remarks O O+
053 Merchant Location O O+
054 Customer Location O O+
056 Originating Channel M M+

057 MCC - M
058 Error Free text O
059 IFSC C C+
062 Beneficiary A/c M M+
121-123 Private use C C*
128 MAC Code2 R R
10.0 Data Elements
Data elements are the individual fields carrying the transaction information. There are up to 128 data
elements specified in the original ISO 8583:1987 standard, and up to 192 data elements in later
releases. Each data element is described in a standard format which defines the permitted content of
the field.
Abbreviation used in data element description
Abbreviations Meaning
a Alpha
b Binary data for PIN and biometric
n Numeric value
s Special character
x Character C / D to indicate credit / debit
z Track data
an Alpha numeric
ans Alpha numeric and special
Data field components
Component Type of Information

Type Date element type and field length
Format Data element field format
Description Data element content and code
definitions when applicable.
Field Edits Data element content and presence rules
Constraints

10.1 DE-2 Primary Account Number, PAN
Type n..19
Format LLVAR
Description A series of digits used to identify customer account or
relationship. Identifies the cardholder PAN.
Field Edits This remains same for a particular transaction and cannot be
changed.
Constraints When present, it should be echoed in response and all
Subsequent messages.
Presence Mandatory-This field is mandatory across all messages
Conditional-None
Optional-None
Structure of PAN:
For P2P, PPI and P2M : <NBIN (4 Digits)><00100><Mobile No (10Digits)>
For P2A :< NBIN (4Digits)><00100><Last 10 digit of Account No>
B B B B BR BR I BR BR M M M M M M M M M M
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

10.2 DE-3 Processing code
Type n6
Format Fixed
Description A series of digits that describes the type of transaction and
the accounts affected by the transaction
Digit 1 and 2 Transaction Code
00 Purchase of goods/services
01 Cash withdrawal
20 Credit, refund
21 Deposit
22 Credit adjustment
31 Balance enquiry
90 Extended transaction type
Digit 3 and 4 From Account Type
00 Unspecified / Unknown
10 Savings
11 Current
12 Overdraft
13 Cash Credit
14 Loan Account
20 Checking
30 Credit card
31 Open system PPI
32 Bank semi-closed PPI
33 Non-bank semi-closed PPI
40 NRE
43# Foreign inward remittance
52 Card to Card Payments
Digit 5 and 6 To Account Type
10 Savings
11 Current
12 Overdraft
13 Cash Credit
14 Loan Account
20 Checking
30 Credit card
31 Open system PPI
32 Bank semi-closed PPI
33 Non-bank semi-closed PPI
40 NRE
52 Card to Card Payments
Field Edits This remains same for a particular transaction and cannot
be changed.

Remitter Bank to populate the value as 90XX00, wherein XX will be as per remitting account type.
Beneficiary Bank to update the value as 90XXYY, wherein YY will be the type of the beneficiary account.
#-If processing code is 904300 and the beneficiary account is NRE or CASA than beneficiary bank need
to give credit to beneficiary.
It is mandatory for all 02xx messages. Remitting bank to populate the details from its end.
Note: * Other values may be used for optional features.
10.3 DE-4 Amount, Transaction
Type n12
Format Fixed
Description Contains the transaction amount to be transferred i.e.
specified by the currency code in field 49.
This field contains the total amount carried for a transaction.
changed.
Amount, Transaction is a fixed length field and a leading zero
is always required.
10.4 DE 7 – Date and Time, Transmission
Type n10
Format Fixed. MMDDhhmmss

Description Date and time a message is entered into the data
interchange system. It is represented in GMT
Field Edits This field can be changed for a particular transaction.
This field should be different in
originating/verification/reversal legs of the transaction.
Constraints This should be echoed back in response

10.5 DE 11 – STAN
Type n6
Format Fixed.
Description STAN should be a 6 digit numeric value.
Remains unchanged for all messages throughout the
life the transaction.
Remitter and beneficiary have to respond back with the
same STAN in their response as well, for a transaction.
It may happen that remitter STAN and beneficiary STAN
may be different for the same transaction.
STAN should be different in
Field Edits This field remains the same for a particular transaction.
Constraints The same is echoed in the response
10.6 DE 12- Time, Local Transaction
Type n6
Format Fixed. HHmmss

Description Is the local time the transaction takes place.
It is represented in IST.
In verification request bank will populate the original
transaction local time in this DE
Constraints This is to be echoed in the response.

10.7 DE 13- Date, Local Transaction
Type n4
Format Fixed. MMDD

Description Local date at which the transaction began at the device.
In verification request bank will populate the original
transaction local date in this DE
Constraints This is to be echoed in the response.
10.8 DE 15 - Date, Settlement
Type n4
Format Fixed. MMDD

Description Month and date on which NPCI Host will settle the
transaction.
Field Edits NPCI can add settlement date as per the cases. But when
present should be echoed back in the response.
Constraints For a cross currency conversion, Field 50 should be present.

10.9 DE 18- Merchant Category Code
Type n4
Format Fixed.
Description MCC is four-digit code in accordance with the
Visa/Mastercard MCC definitions. The data element is
mandatory for 02xx request messages. It is never present in
response messages.
The proposed values are
4814 – Financial institutions providing mobile banking

service and transaction initiated from Branch.
4829 – Transaction initiated from Internet channel
6011 - Transaction initiated through ATM Channel
6012 – Transaction initiated through Micro ATM Channel
6010 - Transaction initiated through POS Channel
Field Edits This remains same for a transaction.

Constraints It is not to be echoed in response

10.10 DE 22- POS Entry MODE
Type n3
Format Fixed.
Description The code describing the way PAN (card number) and PIN are entered at a
touch point.
Digit 1 and 2 PAN Entry Mode
01 Manual
02 Magnetic Stripe Read
90 Full and Unaltered magnetic stripe read(enables
CVD validation)
Digit 3 PIN Entry Capability
0 Unspecified
1 PIN Entry Capability
2 No PIN Entry Capability
6 PIN pad inoperative
9 Reserved for private use
01 9 Transaction initiated through Mobile Phone

Transaction initiated through Internet
01 2 Channel/Branch
90 1 Transaction initiated through ATM Channel
Transaction initiated through Micro ATM/POS
01 1 Channel
Field Edits This remains same for a particular transaction.
Constraints It is not echoed in response.
10.11 DE 25- POS Condition Code
Type n2
Format Fixed
Description 2 Digit code determining the transaction conditions at the POS.
Value Meaning
00 Normal
01 Customer Not present
02 Unattended Terminal
03 Merchant suspicious
05 Customer present, card not
present
06 Preauthorization completion
always contains 06.
07 Telephone Request(IVR)
08 MO/TO request
05 Transaction initiated

through Mobile Phone
through Internet
Channel/Branch
through ATM/Micro
ATM/POS Channel

Constraints It is not to be echoed in response.
10.12 DE 32-Acquiring Institution Code
Type n..11
Format LLVAR
Description Identifies the acquiring institution for the transaction, or its
agent. The data element is mandatory for 02xx request
messages. It is optional for 08xx messages.
This is allotted by NPCI and should be numeric 6 digit. One

acquirer ID for one bank
Field Edits This remains same for a particular transaction

Constraints If present it should be echoed back in response and all
subsequent messages.
Member can choose whether to use DE-32 in 08xx messages or
not.

10.13 DE 37-Retreival Reference Number
Type an 12
Format YDDDHHSSSSSS
Y-Year
DDD-Julian Date
HH-Hour
SSSSSS-Trace Number
Description The reference, assigned by the remitter, 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.
HH should be derived from DE 12.

Last 6 digits should be matched with DE 11 of remitter.
Field Edits This field remains same for a particular transaction and
is to be echoed back in a response.
Constraints This field should be echoed back in a response
10.14 DE 38-Authorization Identification Response
Type an 6
Format Fixed
Description A unique code assigned by the beneficiary for a successful
transaction.
Field Edits This field is echoed back in a response for a successful
transaction.
Constraints Assigned by the beneficiary.
In verification if this is present in the original transactions then
this field is present.

10.17 DE 39-Response Code
Type an 2
Format Fixed
Description This defines the response to a request for a transaction.
Field Edits This field is sent by beneficiary in a response for a successful and
an unsuccessful transaction.
In reversal and store/forward requests, value identifies the reason
for reversal or store/forward message.
Constraints Assigned by the beneficiary and must be present in all response

messages. But for a verification transaction this can be filled by the
remitter from the original transaction.
Code Description Action
Action code definition:

Code Description
A Approve transaction
D Decline transaction
The following is the addendum covering different scenarios for IMPS funds transfer and appropriate
Response codes supported for successful as well as declined transactions in addition to the existing
response codes referred in the NPCI Host-to-Host specification document.
0210 Response Codes

ITM Description ISO-8583 Actio Description
Response Response n
code code
00 Remittance successful. 00 A Remittance transaction is successful
Applicable only if the
processing code in 200
is 45
00 Original transfer 00 A Verification transaction is successful and
successful. Applicable
only if the processing remittance transaction for which
code in 200 is 32 verification was raised is successful
M0 Verification successful M0 D If the verification request is successful

but original credit
transaction declined but the original transaction for which
verification was raised had declined due
to some reason
M1 ‘Invalid / Unverified beneficiary M1 D If the mobile number/MMID
credentials’ combination entered by the customer is
not registered or is mismatch

M2 Amount limit Exceeded M2 D Daily allowed amount limit for the
beneficiary is exceeded.
M3 Account blocked/Frozen M3 D Beneficiary account is frozen
M4 NRE Account M4 D Beneficiary account is NRE account
M5 Account closed M5 D Beneficiary account is closed
M6 Limit exceeded for member bank M6 D When the limit set for the member bank
as per Settlement guarantee fund has
been exceeded
M7 Transaction not permitted for M7 D Transaction is declined based on “From”
this account type account type and “To” account type
M8 Transaction not permitted for M8 D Transaction is declined based on

this account type transaction limit imposed on the “From”
account type and “To” account type
MM Transaction not allowed as this is MM D Transaction is declined as beneficiary PPI
non-reloadable card is ‘Gift prepaid’ and this is not the first
transaction
MP Transaction not allowed as Bank MP D Transaction is declined as Bank not yet
not enabled yet for P2A enabled for P2A functionality
MC functionality
Functionality not yet available for MC D NPCI declines the transaction as acquiring
merchant through the payee bank bank has not yet implement customer
initiated person-to-merchant
transaction
MX Transaction not allowed as MX D Transaction is decline as Aadhaar
Aadhaar Number belongs to Number belongs to Remitter bank.
Remitter Bank.
MV Transaction not allowed as Bank is MV D Transaction not allowed as Bank is not

not enabled for IMPS P2U enabled for IMPS P2U
MU Transaction not allowed as Aadhar MU D Transaction not allowed as Aadhar number
number is not in NPCI database is not in NPCI database
22 Transaction not allowed as Amount 04 D Transaction not allowed as Amount is

is greater than 2 Lakhs (Applicable greater than 2 Lakhs (Applicable for Bank
for Bank where NDC is greater than where NDC is greater than 2 Lakhs).
2 Lakhs).
MN Transaction not allowed as MN D Transaction not allowed as Beneficiary bank

Beneficiary bank is not enable for is not enable for Foreign Inward Remittance.
Foreign Inward Remittance. To be To be Decline by NPCI
Decline by NPCI

MW Transaction not allowed as MW D Transaction not allowed as beneficiary is PPI
beneficiary is PPI and DE 3 is and DE 3 is 904300 and applicable for P2P
904300 and applicable for P2P Transaction only. To be decline by NPCI
Transaction only. To be decline by
NPCI
MQ Transaction not allowed as MQ D Transaction is declined as invalid
invalid payment reference payment reference
MR Transaction not allowed as MR D Transaction is declined as invalid amount
invalid amount
MS Transaction not allowed as MS D Transaction is declined as invalid account
invalid remitter account number number
MT Transaction not allowed as MT D Transaction is declined as general error
general error
CU Host (CBS) offline 08 D
IU Beneficiary node offline 08 D
08 Issuing bank CBS or node offline 91 D

86 Invalid NBIN 92 D
01 Invalid transaction 12 D
05 Invalid transaction type 12 D
07 Invalid response code 20 D
39 Unable to process 96 D
24 Insufficient balance in pool A/c 51 D
20 Blocked/Lost/Hotlisted card 41 D
03 Expired card 33 D

10.18 DE 41-Card Acceptor Terminal Id
Type ans 8
Format Fixed
Description A unique code identifying the terminal at the merchant location.
Special characters (including national character support
characters) are not allowed since some networks and / or back-
office systems may have problems accepting these characters.
The data element is mandatory for 01xx, 02xx, and 04xx request
messages. The first 3 digits of the terminal ID should be institution
name.

Constraints When present this is to be echoed back in a response & all
subsequent messages.
Transaction initiated through Mobile Phone & Internet Banking Channel
Position Description
01-03 Bank Code (Example - For ICICI transactions code can be ICI assigned by NPCI)
04-08 NNNNN (Last 5 digit of Remitter Mobile Number)
Transaction initiated through ATM Channel - A unique code identifying the terminal at the card acceptor
location.
 ATM terminal ID to be passed (length ans 8). Same as per NFS.

10.19 DE 42-Card Acceptor Id
Type ans 15
Format Fixed
Description Identifies the merchant in a transaction if the merchant is different
from the acquiring institution. Special characters (including national
character support characters) are not allowed since some networks or
back-office systems may have problems accepting these characters.
The data element is mandatory for 02xx request messages. The first 3
digits of the terminal ID should be institution name.

Constraints It is not to be echoed back in a response.
01-03 Bank Code (Example - For ICICI transactions code can be ICI assigned by NPCI)
04-15 NNN****NNN (Mobile Number of Remitter)
Transaction initiated through ATM Channel - Identifies the card acceptor in a transaction if the card
acceptor is different from the acquiring institution.
 Full ATM terminal ID to be passed (length ans 15). Same as per NFS.

10.20 DE 43-Card Acceptor Name/Location
Type ans 40
Format Fixed
Description The name and location of the card acceptor, 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 04xx request messages.

Constraints It is not echoed back in a response.
01-25 Bank Name
26-38 MOB NNN****NNN
39-40 IN
Transaction initiated through ATM Channel
01-23 Terminal Owner name
24-36 Terminal City
37-38 Terminal State code
39-40 Terminal country code

10.21 DE 48-Additional Data
Type ans…256
Format LLLVAR
Description This field is tag based
TAG Mandatory/ Length VALUE
optional
051 (Product M 5 IMP00 - transfer

Code) including mobile, ATM
and internet (DE 120
product code
45/47/48)
IMP01 – For merchant

payment pull type
(DE120 product code
46)
058 (Fraud Score) M 5 ‘NNNNN’
‘NNNNN’ – can either be 00999 (default fraud score) or it can be a

real-time score generated by FRM server.
Note: NPCI will send the Fraud score in tag058, in 0200 message to
beneficiary and will not be echoed by beneficiary and fraud score
will be sent to remitter in 0210 message.

Constraints If present it is echoed back in a response (only Tag051)

10.22 DE 49-Currency Code, Transaction
Type n3
Format Fixed
Description 3 digit code that identifies the currency for a particular
transaction amount. Refer to ISO 4217 for currency
code. For domestic transaction this field will contain
value 356
Constraints It is echoed in response.
10.23 DE 70 -Network management information code
Type n3
Format Fixed
Description These messages are used by the members and NPCI for sign in and sign
off.
Digit 1,2,3 Description
001 Log on
002 Log off
201 Cut over
301 Echo Test
Echo Message – System must generate echo message in every 3 minutes.
Auto Logon – System must generate auto logon whenever there is a

disconnection between NPCI & member bank.
Field Edits This field is used in network management messages.

Constraints It is not to be echoed in response.

10.24 DE 102 - Account Identification 1
Type ans..28
Format LLVAR
Description A series of digits used to identify a customer account. It denotes the
“From” account number involved in the transaction (e.g. the Debit
account in withdrawal or transfer transaction. The account number in the
Account Identification 1 field must be right justified with leading zeros.
Usage:
In IMPS transactions, Remitter bank must send the “from account

number” which is debited for the transfer amount. The bank requires
populating length of DE# 102 (max 19) instead of 28 in which the first two
numbers will denote the length of the account number followed by the
actual account number.
It denotes the “From” account number.

Constraints C: The data element is used in 02xx messages, whenever account
information must be transferred.
10.25 DE 103 - Account Identification 2
Type ans..28;
Format LLVAR
Description A series of digits used to identify a customer account. It denotes the “to”
account number involved in the transaction (e.g. the credit
account in deposit or transfer transaction. The account number in the

Account Identification 1 field must be right justified with leading zeros.
Usage:
In IMPS transactions, Beneficiary bank can send the “to account number”
which is credited for the transfer amount. The bank requires populating
length of DE# 103 (max 19) instead of 28 in which the first two numbers
will denote the length of the account number followed by the actual

account number.
It denotes the “To” account number.

Constraints C: The data element is used in 02xx messages, whenever account
information must be transferred.
10.26 DE 120-Private Field
Type ans… 999
Format LLLVAR
Description These fields are Tag-based.
The value in TAG 001 can be used identify the type

of the transaction as P2P, P2M, or P2M transaction
and populate the values accordingly in the
interface.
Values: Beneficiary Bank will identify and populate

the value from the type of beneficiary account
mapped to the remitter’s mobile no and MMID.

Constraints If present this is to be echoed in response as well.
For declined transactions Tag 001 & Tag 002 will be
present in response & all subsequent messages.
For P2P & P2M (Original Message)

TAG Description 200 210 Length Value
1 Transaction Type M M+ 2 45/47
2 Product Indicator M M+ 3 MOB
45 Remitter Name M M+ 7(Max 20) Shivaji
46 Beneficiary Name M 3(Max 20) Ram
49 Beneficiary MAS* C C 3 Value
Remitter MMID+10-digit
120 mobile number (remitter MMID
Remitter MMID + 17(Max +Default mobile no
50 M M+
Mobile No 20) “00000000000”) if Remitter
mobile no is not registered with
Bank.)
51 Remarks M M+ 50 Max Value (ans…)
City (1-14), State Code (15-16),
53 Merchant Location - O 18 Max
Country Code (17-18)

54 Customer Location O O+ 18 Max
Originating ATM/POS/INET/USDC/USDB/M
56 M M+ MAX 4
Channel** OB/SMS/WAP/IVR/MAT/BRC
57 MCC - C 4 Value (only for P2M txn)
58 Error Text - O 50 Value (ans...) (only for P2M txn)
Note:
For P2P & P2M (Verification Message)

1 Transaction Type M M+ 2 32/33
Populate DE12 & DE13 of
47 Original Txn Data M - 80 Max
original transaction.
49 Beneficiary MAS* C C 3 Value
mobile number (remitter MMID
Remitter MMID + 17(Max +Default mobile no
50 M M+
120 Mobile No 20) “00000000000”) if Remitter
mobile no is not registered with
Bank.)
Originating ATM/POS/INET/USDC/USDB/M
56 M M+ MAX 4
Channel** OB/SMS/WAP/IVR/MAT/BRC
57 MCC - C 4 Value (only for P2M txn)
58 Text - O 50 Max Value (ans...) (only for P2M txn)
For P2A (Original Message)

1 Transaction Type M M+ 2 48
120 45 Remitter Name M M+ 7(Max 20) Shivaji
49 Beneficiary MAS* C C 3 Value (Default value “000”)

mobile
17 (Max Number (remitter MMID
Remitter MMID +
50 M M+ 20) +Default mobile no
Mobile No
“00000000000”) if Remitter
mobile no is not registered
with Bank.)
ATM/POS/INET/USDC/USDB/
Originating
56 M M+ 3 (Max 4) MOB/SMS/WAP/IVR/MAT/BR
Channel**
C
57 MCC C 4 Value
59 Beneficiary IFSC M M+ 11 Value
11(Max
62 Beneficiary A/c M M+
30) Value (E.g 12345678901)
For P2A (Verification Message)

1 Transaction Type M M+ 2 34
Populate DE12 & DE13 of
47 Original Txn Data M - 80 Max
original transaction.
49 Beneficiary MAS* C C 3 Value ( default value “000”)
mobile number (remitter
Remitter MMID + 17 (Max 20) MMID +Default mobile no
50 M M+
120 Mobile No “00000000000”) if Remitter
with Bank.)
City (1-14), State Code (15-
16), Country Code (17-18)
City (1-14), State Code (15-
16), Country Code (17-18)
ATM/POS/INET/USDC/USDB/
Originating
56 M M+ 3 (Max 4) MOB/SMS/WAP/IVR/MAT/B
Channel**
RC
57 MCC C 4 Value
59 Beneficiary IFSC M M+ 11 Value

62 Beneficiary A/c M M+ 11(Max 30) Value (E.g 12345678901)
ATM - From ATM channel POS - From Point of Sale Device
INET - From Internet Banking Channel MOB - From Mobile Banking Application
SMS - From SMS modeWAP - From Internet on Mobile Phone
IVR - From IVR channel MAT - From Micro- ATM
USDC - From NUUP (on *99#)
USDB - From bank provided USSD channel (bank’s own USSD code)
BRC-Branch
* For DE 120 TAG 49(Beneficiary MAS) : In P2P & P2A: value is populated by remitter in 0200 and in
0210 this Tag is not present. But in P2M, this value is populated in both 0200/0210. This is conditional
Data element. It will be handled accordingly internally by NPCI.
** In 0210, DE-120 Tag 56 (Originating Channel): In case of merchant payment Beneficiary bank to
update the same and send MMOB, MNET, MATM,MPOS, MSDC,MSDB,
MSMS,MWAP,MIVR,MMAT,MBRC
11.0 SMS Confirmation to Customer
11.1 For NORMALtransaction SMS to customer as follows:

S.No. Response code Suggested message Msg length Sent to
(char)
1 00 Your a/c no. XXXXXXXX5124 is debited 138 Remitter

for Rs.50000.00 on dd-mm-yy and a/c
linked to mobile 9999999999 credited
(IMPS Ref no 123456789012).
2 00 Your a/c no. XXXXXXXX5155 is credited 128 Beneficiary
by Rs.50000.00 on dd-mm-yy by a/c
linked to mobile 9xxxxxx999 (IMPS Ref
no 123456789012).
3 Reversal on a later Your a/c no. XXXXXXXX5124 is credited 122 Remitter
date for Rs.50000.00 on dd-mm-yy for
reversal of transaction (IMPS Ref no
123456789012).
4 M1 Your fund transfer for Rs. 50000.00 on 134 Remitter
dd-mm-yy is declined as the
beneficiary mobile no. or MMID is
invalid (IMPS Ref no. 123456789012).

dd-mm-yy is declined. Please refer to
the beneficiary (IMPS Ref no.
123456789012).
123456789012).
123456789012).
123456789012).
dd-mm-yy could not be processed.
Please try later. (IMPS Ref no.
123456789012).
10 M7 Your fund transfer request for Rs. 119 Remitter
50000.00 on dd-mm-yy is declined as
transaction not permitted for this
account type. (IMPS Ref no.
123456789012).
transaction limit exceeded for this
account type. (IMPS Ref no.
123456789012).
12 MM Your fund transfer request for Rs. 136 Remitter
beneficiary is non-reloadable card.
(IMPS Ref no. 123456789012).
13 MP Your fund transfer request for Rs. 196 Remitter
functionality is not available through
Beneficiary.(IMPS Ref no.
123456789012).
14 MQ Your fund transfer request for Rs. 127 Remitter
invalid payment reference. (IMPS Ref
no. 123456789012).
15 MR Your fund transfer request for Rs. 116 Remitter
invalid amount. (IMPS Ref no.
123456789012).
16 MS Your fund transfer request for Rs. 133 Remitter
invalid remitter account number.

(IMPS Ref no. 123456789012).
17 MT Your fund transfer request for Rs. 114 Remitter

general error. (IMPS Ref no.
123456789012)
18 91 Your fund transfer for Rs 50000.00 on 118 Remitter

dd-mm-yy is timed out. Please check
with your bank (IMPS Ref No
123456789012)
19 08 Your fund transfer for Rs. 50000.00 on 119 Remitter

dd-mmyy could not be processed.
123456789012).
20 Remitter Your fund transfer for Rs. 50000.00 on 120 Remitter
transaction limit dd-mmyy could not be processed as
exceeds for the your per day limit for remitting is
day exceeded.
21 Insufficient Your fund transfer for Rs. 50000.00 on 116 Remitter
balance in dd-mmyy could not be processed due
Remitter a/c to insufficient balance in your account.
No connectivity Your fund transfer for Rs. 50000.00 on 119 Remitter
between Remitting dd-mmyy could not be processed.
22 bank and NPCI Please try
before credit. later. (IMPS Ref no. 123456789012).
23 92 (invalid NBIN) Your fund transfer request for Rs. 136 Remitter
50000.00 on dd-mm-yy has been
declined as the beneficiary MMID is
invalid (IMPS Ref no. 123456789012).
declined. Please refer to the
beneficiary (IMPS Ref no.
123456789012).
25 07 Your fund transfer request for Rs. 134 Remitter

declined. Please check with
Beneficiary. (IMPS Ref no.
123456789012).
11.2 For MERCHANT SMS to customer as follows:

(char)
1 00 Your a/c no. XXXXXXXX5124 is 137 Remitter

debited for Rs.50000.00 on dd-mm-yy
and a/c of <merchant name> has
been credited (IMPS
Ref no 123456789012)
2 00 Your a/c no. XXXXXXXX5124 is 128 Merchant

credited for Rs.50000.00 on dd-mm- (depends on
yy by a/c linked to mobile xxxxxxx999 the
(IMPS Ref no 123456789012) integration
between
Banks and
Merchant)
3 Reversal on a later Your a/c no. XXXXXXXX5124 is 156 Remitter

date credited for Rs.50000.00 on dd-mm-
yy for reversal of transaction (Original
IMPS Ref no 123456789012 to a/c of
<merchant name>)
4 Reversal Message Your a/c no. XXXXXXXXXXXX is 156 Remitter

credited for Rs.X amount on dd-mm-
yy for reversal of transaction (Original
IMPS Ref no 123456789012 to a/c of
<merchant name>)

declined as the merchant mobile no.
or MMID is invalid (IMPS Ref no.
123456789012)

merchant (IMPS Ref no.
123456789012).

123456789012)

123456789012).

123456789012)

50000.00 on dd-mm-yy could not be
processed. Please try later (IMPS Ref
no. 123456789012)
11 MQ Your fund transfer request for Rs.

invalid payment reference. (IMPS Ref
no. 123456789012).
12 MR Your fund transfer request for Rs.

invalid amount. (IMPS Ref no.
123456789012).
13 MS Your fund transfer request for Rs.

invalid remitter account number.
(IMPS Ref no. 123456789012).
14 MT Your fund transfer request for Rs.

123456789012)
15 91 Your fund transfer for Rs 50000.00 on 116 Remitter

dd-mm-yy is timed out. Please check
with your bank (IMPS Ref No
123456789012)
16 08 Your fund transfer for Rs. 50000.00 118 Remitter

on dd-mmyy could not be processed.
123456789012).

17 Remitter Your fund transfer for Rs. 50000.00 120 Remitter
transaction limit on dd-mmyy could not be processed
exceeds for the as your per day limit for remitting is
day exceeded.
18 Insufficient Your fund transfer for Rs. 50000.00 116 Remitter

balance in on dd-mm-yy could not be processed
Remitter a/c due to insufficient balance in your
account.
19 No connectivity Your fund transfer for Rs. 50000.00 118 Remitter

between on dd-mmyy could not be processed.
Remitting bank Please try later. (IMPS Ref no.
and NPCI before 123456789012).
credit.
20 92 (invalid NBIN) Your fund transfer request for Rs. 136 Remitter
declined as the Merchant MMID is
invalid (IMPS Ref no.
123456789012).

declined. Please refer to the Bank.
(IMPS Ref no. 123456789012).
22 07 Your fund transfer request for Rs. 128 Remitter

declined. Please check with Bank.
(IMPS Ref no. 123456789012).
23 MK Your fund transfer request for Rs. Remitter

declined as payee is an individual and
not a merchant. Please use IMPS
funds transfer form for making
payment. (IMPS Ref no.
123456789012).
11.3 For P2A SMS to customer as follows:

(char)
1 00 Your a/c no. XXXXXXXX5124 is debited 138 Remitter

for Rs.50000.00 on dd-mm-yy and a/c

XXXXXXXX999 credited (IMPS Ref no
123456789012).
2 00 Your a/c no. XXXXXXXX5155 is credited 128 Beneficiary
by Rs.50000.00 on dd-mm-yy by a/c
linked to mobile 9xxxxxx999 (IMPS Ref
no 123456789012).
3 92 Your fund transfer for Rs. 50000.00 on 128 Remitter
dd-mmyy is declined as beneficiary IFSC
code is invalid (IMPS Ref no.
123456789012).
dd-mm-yy is declined as the beneficiary
Account no or IFS Code is invalid (IMPS
Ref no. 123456789012).
5 MP Your fund transfer request for Rs. 150 Remitter
functionality is not available through
Beneficiary.(IMPS Ref no.
123456789012).
6 MT Your fund transfer request for Rs. 114 Remitter
123456789012)
Note: Other SMS confirmation to Customer for P2A is same as the normal transaction.
11.4 MMID process through SMS
1. Customer who is enrolled for Mobile Banking Service (Remitter) – If this customer sends SMS as
‘MMID’ or ‘MMID NNNN….’ to the respective bank then,
SMS will go as “Your MMID allotted for the A/C No. XXXXXX1234 is XXXXXXX. You can Send and
Receive Money through IMPS option in Mobile Banking.”
If the MMID is already there then system can just retrieve and send it in SMS. If MMID is not there
then, system should generate new MMID and send it in SMS to customer’s mobile number.
2. Customer who is not enroll for the Mobile Banking Service and only having mobile number
linked to their account (Beneficiary) – If this customer sends SMS as ‘MMID’ or ‘MMID NNNN….’ to
the respective bank then,
SMS will go as “Your MMID allotted for the A/C No. XXXXXX1234 is XXXXXXX to Receive Money only.
Please inform your Remitter to use the MMID along with your mobile number.”
If the MMID is already there then system can just retrieve and send it in SMS. If MMID is not there
then, system should generate new MMID and send it in SMS to customer’s mobile number.
3. Customer who has not linked the mobile number to their accounts – If this customer sends SMS
as ‘MMID’ or ‘MMID NNNN….’ to the respective bank then, SMS will go as “Your mobile number is

not linked to your bank account so far. Please visit our website www.xyz.com or visit nearest bank
branch” The last line can be decided by the individual banks as per their convenience.
4. Customer who wants to cancel his/her current MMID – This will disable the customer from
sending and receiving money for that particular account. The customer sends SMS as
‘MMIDCANCEL’ or ‘MMIDCANCEL NNNN….’ to respective bank’s short/long code. Bank should
disable for IMPS for that particular account. Then customer will follow the above steps to get the
new MMID for sending/receiving money for that particular account.
‘NNNN….” in MMID generation/Retrieval refers to few digits of MMID, Account no., Card No. or
customer ID as per bank’s decision.
‘NNNN….” In MMID Cancellation refers to few digits of MMID, Account no., Card No. or customer ID
as per bank’s decision.
Syntax for MMID process through SMS for Sponsored Banks, multiple accounts in same bank:
For Sponsor Banks: The sponsor bank may ask for short names for the sponsored banks for
generation, retrieval or cancellation of the MMID. The keywords entered by the customers of the
sponsored banks would hence be “MMID ABC” or “MMID ABC NNNN” for MMID generation and
“MMIDCANCEL ABC” OR “MMIDCANCEL ABC NNNN” for MMID cancel, wherein ‘ABC’ refers to short
code of bank & ‘NNNN….” refers to few digits of MMID, Account no., Card No. and customer ID as
per bank’s decision.

11.5 Application Process Flow for P2P, P2A and P2M
1. Main Screen 2. IMPS Home Screen

1.
ABC Bank ABC Bank
IMPS
• Fund Transfer- To Mobile Number
• Immediate Payment • Fund Transfer- To Account Number
Service(IMPS) • IMPS Merchant Payment
• Generate OTP
• Generate MMID
• Retrieve MMID
• Cancel MMID
3. Screen Flow for P2P 4.Screen Flow for P2A
ABC Bank
ABC Bank Fund Transfer-To Account Number
Fund Transfer-To Mobile Number Beneficiary Account Number
Beneficiary Mobile Number
Beneficiary IFS Code

Beneficiary MMID Number
Amount
Amount
Remarks
Remarks

12.0 Additional transaction flows
12.1 Online interface with merchant with verification of payment reference step, and update of
merchant back-end system
1. Customer initiates transaction through Issuing bank mobile application, enters merchant mobile
number, merchant MMID, amount, M-PIN and payment reference
2. The information is received by the Issuing Bank, Issuing Bank verifies customer account and
debits the account
3. Issuing Bank forwards information to NPCI
4. NPCI forwards to Acquiring Bank, based on merchant MMID and mobile number
5. Acquiring Bank verifies merchant MMID and mobile number
6. Acquiring Bank sends the ‘Payment Reference’ information viz. policy number and amount to
the merchant back-end system
7. Merchant verifies the payment reference and amount and reverts with status
8. Acquiring bank credits the merchant account, and sends SMS to merchant
9. Acquiring bank sends the transaction response to NPCI, with response code ‘00’
10. NPCI forwards the transaction response to Issuing Bank
11. Issuing Bank sends confirmation SMS to customer, and sends response to customer in Issuing
bank application
12. Acquiring bank updates merchant back-end system

12.2 Online interface with merchant with verification of payment reference step, Merchant
error (invalid payment reference), update of merchant back-end system
debits the account
7. Merchant verifies the policy number and amount and reverts with error status (invalid payment
reference)
8. Acquiring bank does not credit the merchant account
9. Acquiring bank sends the transaction response to NPCI, with response code ‘MQ’ (Invalid
payment reference) 0210 response with error message
11. Issuing bank reverses the customer debit, sends confirmation SMS to customer, and sends
response to customer in Issuing bank application

12.3 Online interface with merchant with verification of payment reference step, Merchant
error (invalid amount), update of merchant back-end system
debits the account
7. Merchant verifies the policy number and amount and reverts with error status (invalid amount)
9. Acquiring bank sends the transaction response to NPCI, with response code ‘MR’ (Invalid
amount) 0210 response with error message

12.4 Online interface with merchant with verification of payment reference step, Merchant error
(invalid remitter account number), update of merchant back-end system
debits the account
6. Acquiring Bank sends the ‘Payment Reference’ information viz. policy number and amount,
remitter account number to the merchant back-end system
7. Merchant verifies the policy number and amount and remitter account number and reverts with
error status (invalid remitter account number)
9. Acquiring bank sends the transaction response to NPCI, with response code ‘MS’ (Invalid
remitter account number) 0210 response with error message

12.5 Online interface with merchant with verification of payment reference step, Merchant error
(general error), update of merchant back-end system
debits the account
7. Merchant verifies the policy number and amount and reverts with error status (general error)
9. Acquiring bank sends the transaction response to NPCI, with response code ‘MT’ (general error)
0210 response with error message

12.6 Acquiring Bank not able to send payment reference verification request to merchant
1. Customer initiates transaction through Issuing Bank mobile banking application, enters
merchant MMID, mobile number, Amount, M-PIN, Payment reference
debits the account
6. Acquiring Bank is not able to send ‘verification of payment reference’ request to merchant due
to communication failure
7. Acquiring bank generates ‘Transaction Denied’ message – 0210 response message with
response code ‘MF’ (Merchant system not available)
8. Acquiring bank sends response to NPCI
10. Issuing Bank reverses the customer debit, and sends confirmation SMS to customer, and sends
11. Acquiring bank updates merchant back-end system (if required)

12.7 No response from merchant to the verification request of acquiring bank to merchant
debits the account
6. Acquiring Bank sends ‘verification of payment reference’ request to merchant
7. Merchant not able to respond to verification request
8. Acquiring bank generates ‘Transaction Denied’ message – 0210 response message with
response code ‘MF’ (Merchant system not available)
9. Acquiring bank sends response to NPCI
11. Issuing Bank reverses the customer debit, and sends confirmation SMS to customer, and sends
12. Acquiring bank updates the merchant back-end system (if required)

12.8 Online interface with merchant with verification of payment reference step, and update of
merchant back-end system, but unable to update merchant back-end system
debits the account
7. Merchant verifies the policy number and amount and reverts with status
8. Acquiring bank credits the merchant account, and sends SMS to merchant
bank application
12. Acquiring bank updates merchant back-end system, but unable to do so. This will not affect the
transaction processing. The acquiring bank system will know the status of merchant back-end
system updation step, and can intimate the merchant regarding the transactions where the step
did not get executed properly. Merchant can do the reconciliation with the back-end system,
can update the system manually or can do refund of the transactions through the acquiring
bank platform

12.9 Transaction message flow – online interface with merchant without verification of payment
reference step, but update of merchant back-end system
1) Customer initiates transaction through Issuing bank mobile application, enters merchant mobile
2) The information is received by the Issuing Bank, Issuing Bank verifies customer account and
debits the account
3) Issuing Bank forwards information to NPCI
4) NPCI forwards to Acquiring Bank, based on merchant MMID and mobile number
5) Acquiring Bank verifies merchant MMID and mobile number, credits the merchant account and
sends SMS to merchant
6) Acquiring bank sends the transaction response to NPCI, with response code ‘00’
7) NPCI forwards the transaction response to Issuing Bank
8) Issuing Bank sends confirmation SMS to customer, and sends response to customer in Issuing
bank application
9) Acquiring bank updates merchant back-end system

12.10 Transaction message flow – online interface with merchant without verification of payment
reference step, but update of merchant back-end system, and unable to update merchant
back-end system
debits the account
5) Acquiring Bank verifies merchant MMID and mobile number, credits the merchant account and
sends SMS to merchant
6) Acquiring bank sends the transaction response to NPCI, with response code ‘00’
bank application
9) Acquiring bank updates merchant back-end system, but unable to do so. This will not affect the
transaction processing. The acquiring bank system will know the status of merchant back-end
system updation step, and can intimate the merchant regarding the transactions where the step
did not get executed properly. Merchant can do the reconciliation with the back-end system,
can update the system manually or can do refund of the transactions through the acquiring
bank platform

12.11 Transaction message flow – no online interface with merchant
debits the account
5) Acquiring Bank verifies merchant MMID and mobile number, and credits the merchant account
6) Acquiring bank sends confirmation SMS to merchant regarding the transaction
7) Acquiring bank sends the transaction response with response code ‘00’ to NPCI
bank application

12.12 Transaction message flow – Acquiring Bank has not implemented person-to-merchant
payment
debits the account
4. NPCI checks if the acquiring bank has implemented person-to-merchant transaction type ‘47’
transaction or not. If not enabled, NPCI shall convert the request to P2P and send to beneficiary
bank
bank application

12.13 Transaction message flow – Customer wants to make payment to individual beneficiary, but
uses person-to-merchant form on mobile application by mistake
merchant MMID, mobile number, Amount, M-PIN, Payment reference in the person-to-
merchant form
debits the account
4. NPCI forwards to acquiring bank based on merchant MMID
5. Acquiring bank checks if the merchant mobile number and merchant MMID belong to the
merchant or an individual. If individual, but transaction type is ‘47’ and not ‘45’, then acquiring
bank will decline the transaction with response code ‘MK’ – ‘Payee is an individual and not a
merchant. Please use person-to-person form for making payment’, and advises the customer to
use person-to-person form for making payment instead. Response is sent by acquiring bank to
NPCI
6. NPCI forwards the response to Issuing bank
7. Issuing Bank reverses the customer debit
bank application

12.14 Transaction message flow – Customer wants to make payment to merchant, but uses person-
to-person form on mobile application by mistake
1. Customer initiates transaction through Remitter Bank mobile banking application, enters
beneficiary MMID, beneficiary mobile number, Amount, M-PIN on the person-to-person form
on mobile banking application
2. The information is received by the Remitter Bank, Remitter Bank verifies customer account and
debits the account
3. Remitter Bank forwards information to NPCI
4. NPCI forwards to beneficiary bank based on beneficiary MMID
5. Beneficiary bank checks if the beneficiary mobile number and beneficiary MMID belong to the
merchant or an individual and respond as appropriate (originating channel MMOB, MNET etc. in
case of merchant , and original value otherwise). Response is sent by acquiring bank to NPCI
6. NPCI forwards the response to Remitter bank
7. Remitter Bank sends confirmation SMS to customer, and sends response to customer in
Remitter bank application

13.0 Maximum Response Time
Beneficiary timeout - 20 seconds

If NPCI not receive any response from beneficiary bank within 20 Second then NPCI will generate
the Time out response (ITM – 08/ ISO -91) and send it to Remitter bank. Remitter bank will send the
VR (Verification) request (0200) to NPCI instantly.
Remitter timeout - 30 seconds
If Remitter bank not receive the response from NPCI within 30 seconds then remitter bank will
send the VR (Verification) request (0200) to NPCI instantly
CBS timeout - 15 seconds

If beneficiary bank server not receive any response from beneficiary CBS then beneficiary bank
server will generate the Time out response (ITM – 08/ ISO -91) and send it to Remitter bank.
Remitter bank will send the VR (Verification) request (0200) to NPCI instantly.

14.0 Reports
Currently raw data files or reports are provided through DMS.

P2P & P2A (retail transaction) details are provided in one file/report and P2M & M2P (merchant
transaction) details are provided in merchant files/reports.
After implementation of standard interface, P2P, P2A transactions for retail shall be available in one
file, and transactions which are identified as merchant transactions based on originating channel, as
well transactions initiated as merchant transactions shall be available in the merchant file
Merchant transaction details will be present in merchant files/reports.
If beneficiary updates and send the originating channel (Tag056) in DE120 with M (MMOB, MNET,
MATM, MPOS, MSDC,MSDB, MSMS,MWAP,MIVR,MMAT,MBRC) transaction will be present in
merchant files/reports.
P2A transactions details will vary and will be present in file depending on the response from
beneficiary.
If beneficiary updates and send the originating channel (Tag056) in DE120 with M, then transactions
details are present along with merchant files/reports and if beneficiary sends originating channel as
normal then transaction details will be present along with P2P & P2M in retail file.
Note: Banks require ensuring that they update the Tag 56 value in response appropriately. This will
also affect the interchange value which will be computed as per the updated Tag value.
14.1 Account statement of customer
For PUSH transaction, the customer will see the following in his account statement: IMPS / <txn type> /
<RRN number> / <merchant mobile number + MMID> / <payment reference>
For PULL transaction, the customer will see the following in his account statement: IMPS / <txn type> /
<RRN number> / <merchant name> / <payment reference>
Transaction type can be shown as follows:
 Transaction type ‘45’ – ‘MRT’

 Transaction type ‘47’ – ‘P2M’
 Transaction type ‘46’ – ‘PUL’

14.2 Account statement of merchant
The merchant will see following in his account statement: IMPS / <txn type> / <RRN number> /
<customer mobile number in masked format xxxxxxx999> / <payment reference>
 Transaction type ‘45’ – ‘MRT’

 Transaction type ‘47’ – ‘P2M’

15.0 IMPS to AADHAAR Transfer (P2U)
A new transaction type called ‘IMPS to AADHAAR number’ will be added to IMPS set-up. After selecting
this new transaction, instead of beneficiary’s mobile number and MMID, customer will enter
beneficiary’s AAADHAAR number. Transaction will be sent to NPCI wherein NPCI will use the MAPPER to
update the request transaction and route the transaction on the on the basis of NBIN. This will require
minimum changes at bank end for processing the AADHAAR based transactions at its end by using the
existing P2A interface already available.
The mapper created for APBS/NACH would be utilized for routing the transactions to beneficiary bank
for credit. There will be a separate form in the mobile application for the remitter to initiate the P2U
transactions. It is proposed to utilize the current specification for P2A developed by the banks to
process P2U transactions.
The beneficiary bank will credit the respective account on real-time basis, mapped on the basis of
AAADHAAR number.
NPCI will support On-us & Off-us transactions for P2U.
Architecture Diagram for IMPS P2U
Process Flow:-
1. Customer initiates transaction by entering Beneficiary AADHAAR Number, Amount, Remarks,

MPIN and its lands on Remitter bank Mobile Server. Remitting bank identifies the transaction as
P2U and inputs default values in request message and sends to NPCI

2. On the basis of transaction type NPCI will update the data elements and will route the
transaction to beneficiary bank for credit.
3. The beneficiary bank will identify the transaction as P2U and will credit the customer account
using AADHAAR no and response back to NPCI with the response.
4. NPCI will update the response message again with original values sent by remitter bank and will
send it to the Remitter bank.
5. Both the bank will send the message confirmation to the customer.
15.1 Data Elements
The changes in the DE w.r.t P2A will be only the below DEs
15.1.1 DE-2 Primary Account Number, PAN

Format: LLVAR
Type: n..19
Description: The primary account number (PAN) of the beneficiary account involved in the transaction.
The PAN number is the combination of 4 digit NBIN number, Last 10 Digit of AADHAAR number of
customer, 1 digit Indicator (value 1-Mobile, P2U – ‘3’ ) 4 digits reserved for future use. It is mandatory
for all 02xx and 04xx messages.
Field Edits: If present, it should be echoed in response and all subsequent messages.
Constraints: C: Element is present if DE-35 (Track2) is not present.
Structure:
B B B B BR BR I BR BR U U U U U U U U U U
1 2 3 4 5 6 0 8 9 10 11 12 13 14 15 16 17 18 19
B – NBIN (National Bank Identification Number)
The Remitter Bank will populate default NBIN i.e. “9000” in DE 2 in 0200 message.
Actual NBIN will be populated from Mapper. E.g 9002 in case of SBI.
BR – Reserved (To be filled with zeros)
U – AADHAAR number – can be truncated depending on available space. Last 10 digits of AADHAAR
number should be taken.
I – Indicator (value ‘1’ – Mobile , P2U – ‘3’ ,)
Note – All Banks 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. Beneficiary bank to
check on the “I”, if the value is “3” then it will be a P2U transaction.

Mapper will update the default NBIN with value as available in the Mapper
15.1.2. DE-120
For Person-to-AADHAAR payment, the tag 001 (transaction type) contains value ‘48’
The updated DE-120 will be as follows:
Format: LLLVAR
Type: an999
Description: These fields are tag-based
0200 request will contain the following details from Remitter bank.
TAG Mandatory / Length Value

Optional
001 (Transaction type) M 2 48
002 (Product indicator) M 3 MOB
045 (Remitter’s name) M 7 (Max 20) Shivaji
049 (MAS*) M 3 Value
050 (Remitter MMID + Mobile M 17 (Max 20) Value (default remitter MMID
number) +Default mobile no
“000000000000000000”) if
Remitter mobile no is not
registered with Bank.
051 (Remarks) O 50 (Max) Value
056 (Originating channel) M 3 (Max 4) MOB (for mobile

banking application),
SMS (for SMS), WAP,
IVR, USDC( NPCI Common
USSD),USDB(Banks own
USSD) POS,INET,BRC
059 (IFSC) M 11 Value (Bank will populate
Default IFSC i.e. IFSC999999)
062 (Beneficiary AADHAAR M 12 (30 max) Value

number)
057 (MCC) C 4 Value
NOTE:-

 If Customer is mobile banking registered then Tag 050 needs to be populate according to the
actual values by Remitter Bank. Otherwise remitter bank need to populate default values.
 Mapper at NPCI end will not update Tag 050.
 Mapper will update only IFS Code. Tag 059.
 MAS*- For IMPS P2U 049 tag can be ‘000’
0200 request that will be send to Beneficiary Bank from ITM.

Optional
049 (MAS) M 3 Value
050 (Remitter MMID + Mobile M 17 (Max 20) Value (remitter MMID

“00000000000”) if Remitter
with Bank.
SMS (for SMS), WAP,

USSD) POS,INET,BRC
059 (IFSC) M 11 Value ( IFSC from Mapper e.g.

SBIN0000000)

number)
057 (MCC) C 4 Value
 NPCI will update 0200 message with IFS code in tag 059 from the mapper
0210 response that ITM will receive from Beneficiary Bank

TAG Mandatory / Optional Length Value
046 (Beneficiary name) M 5 (Max 20) Akbar
050 (Remitter MMID + M 17 (Max 20) Value (remitter MMID

Mobile number) +Default mobile no
“00000000000”) if
Remitter mobile no is
not registered with
Bank.
056 (Originating M 3 (Max 4) MOB (for mobile

channel)
SMS (for SMS), WAP,
IVR, USDC( NPCI

Common
USSD) POS,INET,BRC
059 (IFSC) M 11 Value (actual value

“SBIN0000000”)
062 (AADHAAR M 12 Value

Number)
057 (MCC) C 4 Value
0210 response that ITM will send to Remitter Bank

“00000000000”) if
not registered with
Bank.

channel)
SMS (for SMS), WAP,
IVR, USDC( NPCI

Common
USSD) POS,INET,BRC
059 (IFSC) M 11 Value (actual value

“SBIN0000000”

Number)
057 (MCC) C 4 Value
0200 Request will contain the following details for verification transaction from Remitter

Optional
047 (Original Txn Data) M 80 Populate the following DE of

original transaction: DE-12,
DE-13
049 (MAS) M 3 Value (Populate default value

“000” )
050 (Remitter MMID + Mobile M 17 (Max 20) Value (remitter MMID

“00000000000”) if Remitter

with Bank.
SMS (for SMS), WAP,

USSD) POS,INET,BRC
059 (IFSC) M 11 Default Value ( IFSC999999)

number)
0200 Verification request that will be send to Beneficiary Bank.
047 (Original Txn Data) M 80 Populate the following

DE of original
transaction: DE-12, DE-
13
049 (MAS) M 3 Value

“00000000000”) if
not registered with
Bank.

channel) banking application),
SMS (for SMS), WAP,
IVR, USDC( NPCI

Common
USSD) POS,INET,BRC
059 (IFSC) M 11 Value(IFSC from Mapper

e.g SBIN0000000)
062 (Beneficiary M 12 Value

AADHAAR number)
In case of IMPS to AADHAAR number transaction, 049 tag can have value ‘000’.
0210 Verification response that will be received from Beneficiary Bank

“00000000000”) if
not registered with
Bank. )

channel)
SMS (for SMS), WAP,
IVR, USDC( NPCI

Common
USSD) POS,INET,BRC

059 (IFSC) M 11 Value
062 (Beneficiary M 12 Value

AADHAAR number)
0210 Verification response that will be send to Remitter Bank

“00000000000”) if
Remitter mobile no is not
registered with Bank.

channel)
SMS (for SMS), WAP,
IVR, USDC( NPCI

Common
USSD) POS,INET,BRC
059 (IFSC) M 11 Value (SBIN0000000)

Number)
In 0210, DE-120 Tag 56 (Originating Channel): In case of merchant payment Beneficiary bank to update
the same and send MMOB, MNET, MATM,MPOS, MSDC,MSDB, MSMS,MWAP,MIVR,MMAT,MBRC

16.0 Changes in Files for P 2 U Transactions
16.1 Changes in Raw data file
1. Column PAN no shall contain value for AADHAAR based transaction

2. Column ‘Account number’ shall contain value for AADHAAR number
16.2 Changes in settlement report.
1. Column ‘Account number’ shall contain value for AADHAAR number. Column heading may
change correspondingly
16.3 Changes in verification files.
16.4 Changes in SHT file
16.5 Changes required in DMS
2. Change in transaction type in all dispute types (similar to tran type ‘48’)
16.6 Changes required in daily volume report, response code wise report
New transaction type ‘P2U’ to be added to these reports
16.7 Changes in daily settlement report
New transaction type ‘P2U’ to be added to this report
16.8 Account statement of remitter
The remitter will see following in his account statement: IMPS/<txn type>/<RRN number>/<beneficiary
AADHAAR number in masked format><Remarks>
 Transaction type ‘48’ – ‘P2U’
16.9 Account statement of beneficiary
The beneficiary will see following in his account statement: IMPS/<txn type>/<RRN number>/<remitter
account in masked format xxxxxxx999><Remarks>
 Transaction type ‘48’ – ‘P2U’

16.10 Changes in IMPS mobile application screen flow:
1. In the IMPS menu, a transaction type ‘IMPS funds transfer – To AADHAAR number’ will be
available. Following fields are available:
a. Beneficiary AADHAAR number
b. Beneficiary account type (drop down containing values ‘Savings’, ‘Current’, ‘Overdraft’,
‘Cash Credit’, ‘Loan account’, ‘NRE’, ‘Card to card payments’) – This is optional field
c. Amount
d. Remarks
e. M-PIN
2. The remaining process of the transaction remains the same as current

3. Functionality to ‘Add Beneficiary’ using the AADHAAR number can also be incorporated
16.11 Changes in SMS application
Customer sends SMS with following parameters:
<IMPS> <Beneficiary AADHAAR number><UID> <account type> <Amount> <SMS PIN/MPIN> <Remarks>
<account type> to contain codes as defined (in section 1.1 DE-3) for ‘Savings’, ‘Current’, ‘Overdraft’,
‘Cash Credit’, ‘Loan account’, ‘NRE’, ‘Card to card payments’. Please note that this is optional field
Remitter bank to identify that this transaction is ‘IMPS funds transfer –To AADHAAR number’ and act
accordingly
16.12 Remitter bank changes
1. Bank needs to populate the DE2 values to identify the transaction is P2U or P2A
2. Bank requires to populate default NBIN “9000” and default IFS Code “IFSC9999999___” in 0200
when sending request (original & VR) to NPCI
3. Bank requires creating a new page in for P2U in application.
4. For Intra bank transaction: - In case transactions on P2U are “On-Us” i.e if remitter and
beneficiary bank is same, NPCI will reject the transaction with Response Code “MX”. Such
transactions require being processed by remitter bank as IMPS Intra Bank transactions only.
5. In response banks will update the actual IFS code in their system
16.13 Beneficiary bank changes

1. Bank needs to check account identifier in DE2 (Indicator value for P2U – 3)to identify it as P2U
transactions
2. Bank to check on NBIN in DE2 to identify if its own or sub-member transaction and handle
accordingly
3. Bank shall use tag 062 (beneficiary AADHAAR number) to credit into the beneficiary account,
and not the mobile number / MMID of the beneficiary. If AADHAAR number is not correct,
beneficiary bank should decline the transaction with response code ‘M1’ (invalid beneficiary
account details)
4. Beneficiary bank will maintain the list of AADHAAR nos and corresponding account number at
its end.
16.14 DMS changes
Changes required in DMS
1. Column ‘IFSC code’ shall contain value the actual IFS code value. Column ‘Account number’ shall
contain value for AADHAAR number. Column heading may change correspondingly
2. Change in transaction type in all dispute types (similar to tran type ‘48’)
16.15 Banks enabled for account number / IFSC code based funds transfer
There shall be some banks who are enabled for funds transfer based on AADHAAR number and other
that are not. If bank is enabled, transaction with additional tags shall be sent to the Beneficiary,
otherwise transaction shall be declined with response code ‘MV’ – ”Bank not yet enabled for
functionality”
16.16 SMS formats
SMS to remitter - Your a/c no. XXXXXXXX5124 is debited for Rs.50000.00 on dd-mm-yy and a/c linked to
AADHAAR XXXXXXX999 credited (IMPS Ref no 123456789012).
SMS to beneficiary - Your a/c no. XXXXXXXX5155 is credited by Rs.50000.00 on dd-mm-yy by a/c linked
to mobile XXXXXXX999 (IMPS Ref no 123456789012).
M1 (SMS to remitter) - Your fund transfer for Rs. 50000.00 on dd-mmyy is declined as beneficiary
AADHAAR number is wrong or not linked to any account no. (IMPS Ref no. 123456789012).
92 (SMS to remitter) - Your fund transfer for Rs. 50000.00 on dd-mmyy is declined as beneficiary details
are invalid (IMPS Ref no. 123456789012).
MV (SMS to remitter) – Your fund transfer for Rs 50000.00 on dd-mmyy is declined as functionality not
yet available for funds transfer based on AADHAAR number through beneficiary bank (IMPS Ref no.
123456789012).

MU (SMS to remitter) - Your fund transfer for Rs 50000.00 on dd-mmyy is declined as beneficiary
AADHAAR number is not found. Please ask beneficiary to add with his/her bank (IMPS Ref no.
123456789012).
16.18 Application Process Flow for P2U
1. Main Screen 2. IMPS Home Screen

1.
ABC Bank
ABC Bank
IMPS
• Fund Transfer- To Mobile Number
• Immediate Payment
• Fund Transfer- To Account Number
Service(IMPS)
• Fund Transfer – To AADHAAR number
• IMPS Merchant Payment
• Generate OTP
• Generate MMID
• Retrieve MMID
• Cancel MMID
3. IMPS Screen
ABC Bank
Fund Transfer-To AADHAAR Number
Beneficiary AADHAAR Number
Amount
Remarks
17.0 IMPS Foreign Inward Remittance
In reference to the latest RBI Circular No. RBI/2009-10/122 / DPSS (CO) EPPD
No.327/04.03.02/2009-10 of August 14, 2009, FEMA Regulations specify the nature of credits that
are permitted to NRE accounts which, inter-alia include foreign inward remittances and transfers
from other NRE accounts. Further, the Wire Transfer Guidelines issued by DBOD, RBI, vide
DBOD.AML.BC.No. 77 / 14.01.001 / 2006-07 dated April 13, 2007 necessitates member banks to

provide certain minimum information in the message formats while originating electronic payment
instructions.
To facilitate these transactions, changes were made in the message formats for RTGS (field tag
7495 in R-41) and NEFT (field 7002 under transaction code 40) for identifying transactions where
the remittance has been received by an intermediary bank representing foreign inward
remittances. The onus of ensuring that credits to NRE accounts comply with the extant FEMA
Regulations and the Wire Transfer Guidelines thus rests with the originating bank.
17.1 Scope
Like NEFT, IMPS is also a credit push system and similar changes can be made in IMPS format as well
and IMPS can be used by Intermediary Bank as an alternate to NEFT to provide the benefit of instant
credit and 24*7 availability. Credits from such foreign inward remittance transactions can be made into
CASA / NRE accounts of the beneficiaries and current RBI/FEMA/FIU guidelines and practices applicable
for NEFT as complied by intermediary bank at present shall be applicable in case of IMPS also. For IMPS,
these transactions shall be identified through the ‘From Account Type’ of DE-3 Processing Code.
Foreign Inward Remittances can be done from Money Transfer Organizations (MTO) or Foreign Banks to
Beneficiary Customer’ Bank account through an Intermediary Bank. The intermediary bank in India is
the bank which shall initiate the domestic leg of the foreign inward transaction. The mode of operation
uses the IMPS system, where the MTO’s partner Bank/Intermediary Bank (in India) does a fund transfer
to the beneficiary’s bank account through Beneficiary Bank using IMPS payment system.
We have now received the approval from RBI for processing domestic leg of foreign inward remittances
into bank accounts using IMPS and for allowing credit into beneficiary’s bank account subject to having
audit trail for the entire chain of the remittance and that such transfers take place only to the KYC
compliant accounts. Further, it shall be incumbent upon the Banks, at both ends, to abide by the FEMA
guidelines issued from time to time in the matter.
IMPS offers the following advantages:

i) In IMPS, the credit is instant. Further confirmation is also received instantaneously by
Beneficiary customer and MTO.
ii) IMPS works 24 x 7, allowing beneficiaries to get credit at any time of the day even after
banking hours. It is channel independent and therefore transactions can be initiated from
Internet also.
iii) IMPS works even on Bank Holidays, thus allowing the beneficiary customer access to funds
faster.
iv) MTO/Foreign Bank has the advantage of transferring the funds from its partner
bank/intermediary bank in India to any other Beneficiary Bank present on IMPS platform.
v) IMPS is fast, inexpensive and easy to use. Also it does not require Beneficiary customer to
be a registered customer to receive payments
17.2 Process
Architecture –Transaction is initiated from Customer outside India via MTO/Foreign Bank, MTO
Partner Bank
Intermediary Bank in India routes the transaction to Beneficiary Bank via NPCI

Money transferred to beneficiary account through MTO’s partner Bank/ Intermediary Bank
using IMPS
 Customer (outside India) will visit the MTO/Foreign Bank for initiating Remittances to
India, for a credit to a Beneficiary’s account in India having a CASA/NRE account.
 MTO/Foreign Bank will fund its own account with Partner Bank/Intermediary Bank in
India and instruct Intermediary Bank to transfer to Beneficiary Bank using IMPS
P2A/P2P/ABRS (P2U) services
 MTO’s Partner Bank/Intermediary Bank in India will initiate IMPS transaction using
Beneficiary account number & IFS Code OR Mobile No. & MMID OR Aadhaar Number of the
Beneficiary customer
 After authentication MTO’s Partner Bank shall debit the MTO’s corresponding account held
in INR and transaction is forwarded to NPCI for credit to Beneficiary.
 NPCI routes the transaction to respective Beneficiary Bank, and Beneficiary Bank credits
the Beneficiary account
 MTO’s Partner Bank/Intermediary Bank will receive the transaction status and sends the
status back to MTO
 MTO confirms to remitter/customer about transaction processed successfully.
The delivery of remittance into bank Accounts using IMPS will be a 3 Stage Process as described
below:
Stage Funds Movement From To Geography

I Sender funds the remittance Sender MTO Source Country
MTO/Foreign Bank transfers funds from Source Country
MTO’s A/c
to INDIA into the Nostro account of the correspondent MTO in Sender
II /Intermediary Cross Border
/Intermediary Bank. The funds are liquidated and the Country
Bank in INDIA
converted account (in INR) parked in the Vostro account
MTO
Funds are transferred to Beneficiary Account through Beneficiary
III A/c/Intermediary INDIA
IMPS A/c
Bank in INDIA
NOTE:

 Transaction limit per transaction is Rs. 2 lakhs as per the IMPS circular NPCI/IMPS/OC No.
30/2013-14.
 IMPS is channel agnostic and the Intermediary Bank/MTO’s partner bank should be able to
initiate transaction through all channels.
 Transaction would be in Indian Rupees between the Intermediary Bank, NPCI and Beneficiary
Bank.
 Credit to PPI beneficiary customer is not included in this scope of work and hence the
transaction to PPI should not be allowed and needs to be declined by NPCI when NPCI
receives the transaction from Intermediary Bank/MTO’s partner Bank.
 Credit to Beneficiary’s account through IMPS P2A (using Account No and IFSC), through IMPS
P2P (using Mobile No. and MMID) and through IMPS ABRS(P2U-Using Aadhaar number) is
covered in the scope of work.
17.3 Changes in IMPS specifications required for this

implementation
17.3.1 Changes at Remitter Bank

In case of IMPS, Inward remittances transactions shall be identified through DE-3 Processing Code. The
MTO’s Partner Bank/Intermediary Bank in India that initiates IMPS transaction for credit into the
beneficiary account shall populate value Digit 3 and 4: From Account Type of DE-3 shall contain the
value – 43: Foreign inward remittance. This shall identify the transaction has been received by an
Intermediary Bank representing Foreign inward remittance.
 Data elements which would be playing important role for Foreign Inward
Remittance
DE-3 Processing code

Format:
Type: n6
Description: A series of digits that describes the type of transaction and the accounts affected by the
transaction. It consists of three, two-digit subfields:
Digit 1 and 2 Transaction code
00 Purchase of goods/services
01 Cash withdrawal
20 Credit, refund
21 Deposit
22 Credit adjustment
31 Balance enquiry

90 Extended transaction type
Digit 3 and 4 From Account Type*
10 Savings account
11 Current account
12 Overdraft
13 Cash credit
14 Loan account
40 NRE
43# Foreign inward remittance
52 Card to card payments
Digit 5 and 6 To Account number*
00 Unspecified / unknown
10 Savings account
11 Current account
12 Overdraft
13 Cash credit
14 Loan account
40 NRE
52 Card to card payments
#-If processing code is 904300 and the beneficiary account is NRE or CASA than beneficiary bank need
to give credit to beneficiary.
Note: * Other values may be used for optional features.

DE-4 Amount, Transaction
Type n12
Format Fixed
Description Contains the transaction amount to be transferred i.e.
specified by the currency code in field 49.
This field contains the total amount carried for a transaction.
changed.
Amount, Transaction is a fixed length field and a leading zero
is always required.
DE 7 – Date and Time, Transmission
Type n10
Format Fixed. MMDDhhmmss

Description Date and time a message is entered into the data
interchange system. It is represented in GMT
Field Edits This field can be changed for a particular transaction.
This field should be different in
Constraints This should be echoed back in response

DE 37-Retreival Reference Number
Type an 12
Format YDDDHHSSSSSS
Y-Year
DDD-Julian Date
HH-Hour
SSSSSS-Trace Number
Description The reference, assigned by the remitter, 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.
HH should be derived from DE 12.

Last 6 digits should be matched with DE 11 of remitter.
Field Edits This field remains same for a particular transaction and
is to be echoed back in a response.
Constraints This field should be echoed back in a response
DE-39 Response Code

Two New Response codes have been introduced for Foreign Inward Remittance viz. MN and MW.
 MN:-Transaction not allowed as Beneficiary bank is not enable for Foreign Inward Remittance.
To be decline by NPCI.
 MW:-Transaction not allowed as beneficiary is PPI and DE 3 is 904300 and applicable for P2P
transaction. To be declined by NPCI.
17.3.2Changes at Beneficiary Bank

Beneficiary Bank can credit the amount as per current practice.
The beneficiary account can be CASA / NRE account as long as ‘From account type’ value is ‘43’.
If the ‘From account type’ value is not ‘43’, then beneficiary bank should decline credit into the NRE
account as per current practice.

17.3.3Additional Tags to be developed in DE-120

Sending(Intermedia
70 M M+ 11 Value (ans…)
ry's branch IFSC)
Foreign
71 Institution/Exchang M M+ 35 Value (ans…)
e Account Number
Name of the
Foreign
Institution/Exchang
e
73 Originator's Name M M+ 50 Value (ans…)
120
Originator's Bank
Account
No./Originator's
Unique Reference
No./Identification
Number
Originator's
75 M M+ 100
Address Value (ans…)
Beneficiary
76 M M+ 50
Customer's Name Value (ans…)
77 Purpose code M M+ 50 Value (ans…)
The above additional tags will be sent by Remitter bank but the tags will not send to beneficiary bank.
The additional tags will be stored at NPCI and populate it in ESHTRN0P file for DMS use. The details
will be available in DMS for Remitter and beneficiary bank.
18 Reports:
1. A separate MIS for Foreign Inward Remittance transactions
2. Intermediary Bank/MTO’s partner Bank and the Beneficiary Bank should be able to identify
foreign inward remittance transactions in all IMPS reports
[End of Document]


IMPS Online Switching Specification Newv3 3docx

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

IMPS Online Switching Specification Newv3 3docx

Uploaded by

Copyright:

Available Formats

IMPS –Online Switching Message Specification

Version3.3 (May, 2014)

Prepared By: Date

Reviewed By: Date

Approved By: Date

IMPS – Online Switching Message Specification

IMPS –Online Switching Message Specification .......................................................................................1

IMPS – Online Switching Message Specification

IMPS – Online Switching Message Specification

IMPS – Online Switching Message Specification

IMPS – Online Switching Message Specification

1.1 About Immediate Payment Service (IMPS)

IMPS – Online Switching Message Specification

2.2 Message Structure

A message comprises of the following components:

Message Element Description

Data Concatenated data element

2.2.1 Message Header

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.

IMPS – Online Switching Message Specification

2.2.3 Bit Map

1. Primary bit map

2. Primary and secondary bit map

3. Primary, secondary and tertiary bit map

 Every message includes the bit map, Primary.

 Bit value -1- field associated with that bit is present

Example of primary bit map is as follows:

IMPS – Online Switching Message Specification

2.2.4 Data Elements

Refer to chapter 10.0 for detailed description of data elements.

IMPS – Online Switching Message Specification

3.1 Architecture Diagram

IMPS – Online Switching Message Specification

3.2.1 Remittance Transaction

IMPS – Online Switching Message Specification

IMPS – Online Switching Message Specification

Beneficiary’s Mobile Re mitte r’s na me ,

Bank 1/ NPCI Bank 2 /

Beneficiary’s Mobile Remitter’s name,

Bank 1/ NPCI Bank 2 /

IMPS – Online Switching Message Specification

Beneficiary’s Mobile Remitter’s name,

Bank 1/ NPCI Bank 2 /

Negative Response from Credit Leg Or Beneficiary Bank X

IMPS – Online Switching Message Specification

MTID TAG Data Element 200 210 P2P P2M P2A

11 STAN M M+ Yes Yes Yes

IMPS – Online Switching Message Specification

058 Fraud Score C C

IMPS – Online Switching Message Specification

*-DE 43 is mandatory for Merchant initiated transaction.

IMPS – Online Switching Message Specification

IMPS – Online Switching Message Specification

The MCC code in the interface will be optional in common interface.

5.1 Transaction Flows (step by step)

IMPS – Online Switching Message Specification

5.2 Billing (Switching and Interchange Fee)

Switching Fee Interchange Fee

5.3 Certification and Migration of banks

IMPS – Online Switching Message Specification

Application screen can be as below:

5.4.2 Using Mobile No and MMID