IMPS Merchant Payments For Banks and Merchants. Version 1.0

Transcription

1 IMPS Merchant Payments For Banks and Merchants Version 1.0 June, 2012

2 Contents 1. What is IMPS merchant payments service? What are the pre-requisites for availing the service? How does it work? Customer initiated transaction (P2M PUSH) Merchant initiated transaction (P2M PULL) What are the use cases for P2M PUSH transactions? How does customer make face-to-face payment using IMPS P2M PUSH? What are the use cases for P2M PULL transactions? What is Mobile POS application? What are the advantages for payment via IMPS? What are the amount limits for transactions through IMPS merchant payments? How can the merchant get on-boarded on IMPS merchant payments? Who are the contact persons in the Banks to get on-boarded on IMPS merchant payments? What are the merchant on-boarding process guidelines for Acquirer Bank? For Customer initiated transaction (P2M PUSH), what is the transaction message flow? What if there is an error in payment reference and amount entered by customer? What if acquiring bank is not able to send payment reference verification request to merchant? What if there is no response from merchant to payment reference verification request? What if payment reference online verification is successful, but merchant back-end system is not updated successfully? What if there is no online interface with merchant? What if acquiring bank rejects transaction? What if customer wants to make payment to individual beneficiary, but uses person-to-merchant form on mobile banking application? What if customer wants to make payment to merchant, but uses person-to-person form on mobile application by mistake? What if there is time-out in the transaction flow? For Merchant initiated transaction (P2M PULL), what is the transaction message flow? What if there is rejection at Issuing Bank? What if there is rejection at NPCI? What if Acquiring Bank cannot forward message to NPCI due to communication failure? What if NPCI cannot forward the financial message to Issuing Bank due to communication failure? What if Issuing Bank cannot forward the financial message to its CBS due to communication failure? What if Issuing Bank does not receive response from its CBS after sending the financial message due to communication failure? What if Issuing Bank does not respond to NPCI after sending the financial message due to communication failure? What if NPCI does not forward response to Acquiring Bank after receiving the financial message from Issuing Bank, due to communication failure? What if Acquiring bank is not able to forward message to its CBS, after receiving the financial message from Issuing Bank, due to communication failure? What if acquiring bank does not receive response from CBS, after sending message to CBS for merchant credit, due to communication failure? What if Acquiring Bank is not able to respond to merchant due to communication failure? What if there is time-out to the reversal advice message? What is the dispute management process for IMPS merchant payments? Page 2

3 15.1 Debit adjustment Credit adjustment (Refund) Chargeback Re-presentment Pre-arbitration Pre-arbitration decline Pre-arbitration Accept Arbitration What are the procedures for handling arbitration in the IMPS network? What is the Penalty for non-compliance of Settlement Guidelines What are the Good-faith guidelines for IMPS transactions? What are the guidelines for handling customer complaints in IMPS network? What are the features required in merchant acquiring platform? How does merchant get integrated with Acquiring Bank? For push transactions For pull transactions What are the various interfaces through which merchant can receive payment via IMPS merchant payments PULL transaction? Web application for integration with merchant web site WAP application for integration with merchant WAP site IVR application Merchant mobile handset application SMS based application for customer SMS based application for merchant Reminder SMS based application Merchant server application USSD based application STK based application WAP based application Internet based application What is the merchant configuration required at the acquiring bank platform? Merchant set-up Merchant configuration Financial configuration What facility is required for transaction status verification for merchant? What MIS facility may be provided by Acquiring Bank to the merchant? What is the reconciliation procedure between Bank and Merchant? What is the refund procedure between Bank and Merchant? What are the security guidelines for acquiring Bank and merchants? What are the guidelines for settlement of payments for electronic payment transactions involving intermediaries? What are the risk management guidelines at Acquiring Bank? What are the risk management guidelines at Issuing Bank? What is the list of response codes in the IMPS system? What are the reconciliation files and reports that IMPS provides to the member banks? Page 3

4 Page 4

5 1. What is IMPS merchant payments service? IMPS Merchant Payments For Banks and Merchants IMPS Merchant Payments (P2M Person-to-merchant) service allows customers to make instant, 24*7, interbank payments to merchants or enterprises via mobile phone. IMPS enables mobile banking users a facility to make payment to merchants and enterprises, through various access channels such as Internet, mobile phone, IVR, SMS, USSD. Customer can make payment to any kind of merchant using IMPS merchant payments service: 1. Mobile top-up / DTH top-up 2. Insurance premium payment 3. Online shopping 4. Over-the-counter payments 5. Fees payments to schools / colleges / universities 6. Utility Bill payments 7. Travel & Ticketing The key features of IMPS merchant payments service are as follows: 1. Instant confirmation to sender and receiver 2. Convenient and time-saving 3. Anytime, anywhere service 4. Safe & secure 5. 24*7*365 availability 6. Merchant needs to get on-board IMPS network with one Bank. Customer of any Bank in the IMPS merchant network can make payment to merchant through IMPS This service is brought to you by National Payments Corporation of India (NPCI) in collaboration with Member Banks. 2. What are the pre-requisites for availing the service? Customer needs to be a mobile banking user of their respective Bank. Customer needs to do the following in order to get started: 1. Register mobile number with the account in the respective Bank 2. Get MMID. MMID stands for Mobile Money Identifier and is 7-digit number that is provided by Bank to customer. This number is used to identify customer Bank and is linked to the account number. The combination of mobile number and MMID is unique for the particular account, and customer can link same mobile number with multiple accounts in the same Bank, and get separate MMID for each account 3. Get M-PIN. M-PIN is Mobile PIN, a secret password that is provided by Bank to customer. Customer needs to authenticate transaction using M-PIN 4. Download mobile banking application or use SMS / USSD facility provided by the Bank. In order to perform IMPS transactions, customer needs to download mobile banking application or use SMS / USSD facility provided by the Bank 5. Perform transaction using mobile banking application or SMS / USSD facility Merchant needs to do the following to receive payments via IMPS: 1. Open merchant account with the Acquiring Bank 2. Register mobile number with the bank account and get MMID from respective Bank 3. Integrate with the Acquiring Bank. Page 5

6 3. How does it work? There are two ways in which IMPS merchant payments (P2M Person-to-Merchant) transaction can be performed: 1. Customer Initiated Transaction (P2M PUSH) 2. Merchant Initiated Transaction (P2M PULL) 3.1 Customer initiated transaction (P2M PUSH) In the customer initiated transaction (P2M PUSH), customer initiates transaction through the Bank s mobile banking application or SMS facility provided by the Bank. The Bank offers IMPS merchant payments form in the mobile banking application (this form is available in IMPS menu on the main menu of mobile application) or SMS syntax for performing P2M PUSH transaction. Customer needs to enter the following parameters: 1. Merchant mobile number 2. Merchant MMID 3. Amount 4. M-PIN 5. Payment Reference Payment Reference is an optional 50 characters field provided. This field will be used to enter the unique reference for the payment, and identifies the transaction to the merchant. The merchant decides what customer will enter in this field. For e.g. for insurance premium payment, customer may need to enter policy number in the payment reference field; for electricity bill payment, it may be consumer number. The syntax and information to be input in the payment reference field will be decided by merchant, and communication of the same will be merchant ownership. The SMS syntax for making P2M PUSH transaction through SMS is as follows: MIMPS <Merchant mobile number> <Merchant MMID> <Amount> <M-PIN> <Payment Reference> to Bank s long code or short code number. On initiating transaction as above, customer receives the confirmation SMS with status of transaction shortly. For IMPS P2M PUSH transaction initiated through SMS, transaction limit is Rs 5,000/- per day (for most banks), and for transactions initiated through mobile banking application, transaction limit is as decided by the Bank (Rs 50,000/- for most banks) 3.2 Merchant initiated transaction (P2M PULL) In Merchant Initiated transaction (P2M PULL), the transaction is initiated through Merchant application (such as Merchant website, WAP site, IVR, mobile application). The typical steps to follow for making transaction through P2M PULL are as follows: a. Visit merchant application such as web site, mobile application, or WAP site Page 6

7 b. Select product / service for which payment is to be made c. In the payment options available, choose IMPS d. Enter credentials as follows: i. Customer mobile number ii. Customer MMID iii. OTP (One-Time Password) e. The transaction status is displayed on the screen The customer needs to enter the credentials Customer mobile number (as registered with the Bank), customer MMID (as generated by Bank) and OTP (One-Time Password, as generated by customer). OTP needs to be generated by customer for each transaction. OTP can be generated by customer by using mobile banking application or SMS facility as provided by the Bank. The Bank offers Generate OTP form in the mobile banking application (this form is available in IMPS menu within main menu of mobile banking application) or SMS syntax for Generate OTP transaction. Customer needs to enter the following parameters: 1. M-PIN The SMS syntax for Generate OTP through SMS is as follows: OTP <M-PIN> to Bank s long code or short code number. On initiating transaction as above, customer receives the confirmation SMS with status of transaction shortly. The OTP generated as above has following characteristics: 1. OTP is valid for 1 hour from time of generation 2. If OTP is generated through SMS, the transaction limit is Rs 5,000/- and if OTP is generated through mobile banking application, the transaction limit is as decided by the Bank (Rs 50,000/- for most banks) 3. OTP is valid only for one transaction Successful or Failure 4. Only one OTP (latest generated OTP) is valid at a time 4. What are the use cases for P2M PUSH transactions? Following are the use cases for P2M PUSH transactions: 1. Insurance premium payment 2. Mobile / DTH Recharge 3. Fee payments 4. Credit card payments 5. Utility Bill payments 6. Over-the-counter payments 7. Face-to-face payments Pizza delivery, Courier, Cabs, Retail 5. How does customer make face-to-face payment using IMPS P2M PUSH? Customer can make P2M PUSH payment to the enterprise using enterprise mobile number, MMID, and enter amount, payment reference, and M-PIN, in the mobile banking application or SMS / USSD facility provided by the Bank. The customer as well as enterprise shall receive confirmation SMS. Page 7

8 In case of face-to-face payments, the customer may be paying to the agent of enterprise (such as pizza delivery person, or courier agent), and it is important for the receiving agent to get an SMS confirming the transaction. So even if enterprise receives an SMS, the agent in front of customer doesn t know about the transaction status. To take care of this issue, enterprise can register multiple mobile numbers (mobile numbers belonging to enterprise agents) with their respective Bank. Customer initiates payment using agents mobile number and MMID, and the payment is received into the enterprise account (since agent mobile number / MMID is linked with enterprise account). The customer as well as agent shall receive confirmation SMS. 6. What are the use cases for P2M PULL transactions? The use cases for P2M PULL transactions are as follows: 1. Mobile POS 2. Merchant aggregators 3. Retailers, FMCG, Food chains 4. E-commerce, movies, classified, courier 5. Travel & Ticketing, Radio Taxi 6. Mutual Funds 7. Insurance 8. Utility Bill Payments 9. Mobile / DTH recharge 10. Trading / NBFC 11. Credit Cards 12. Fees payments 13. Donation 7. What is Mobile POS application? Mobile POS is the mobile application that can be downloaded by merchant on their phone. Merchant can receive payment from customer via IMPS using the mobile POS application. Enterprise may comprise of multiple agents that receive payments on behalf of enterprise (such as agents at cash counters, pizza delivery agents, courier agents, taxi drivers, etc). The agents mobile number can be linked to the enterprise bank account at the Bank end, and the agent can receive payment from customer on behalf of enterprise, by using application on their mobile phone. The process is as follows: 1. Enterprise agent has mobile POS application on the phone 2. Opens up form Receive payment from customer 3. Enters payment reference, amount 4. Asks customer to enter mobile number, MMID and OTP 5. Agents mobile number (through which payment is initiated) is linked with merchant account 6. Merchant account is credited and customer account is debited 7. Customer and agent get confirmation SMS 8. Facility to link multiple mobile numbers and MMID with one account, so payments can be received in single account of merchant / aggregator Mobile POS application can be given by retail organizations at their cash counters. Virtual POS can be deployed at the cash counters as well, in which customer can make payment by providing their mobile number, MMID and OTP, and the cash counter person shall enter this information in the virtual POS application on their PC. This can be integrated with billing system of the retailer as well. Page 8

9 The mobile POS can be used by courier agents and receive payments via IMPS. Cash on delivery can be replaced with payment via IMPS. This can help reduce cost and settlement cycle can be reduced. Insurance agents can carry mobile POS application as well and collect payment from customers using mobile POS instead of cash and cheque. There is no investment required for the POS machines and no need for agents to visit insurance company branch office to submit cash and cheque. In Mutual Funds, customers can pay to distributors via Mobile POS. 8. What are the advantages for payment via IMPS? The advantages of payment via IMPS are as follows: 1. Number of mobile users is lot more. Mobile number can be linked to bank account for everyone 2. Replacement of cash 3. Remote payments via website, IVR, mobile application 4. Mobile POS 5. No investment on POS machine for receiving payment via IMPS 6. Convenience, anytime, anywhere payments 9. What are the amount limits for transactions through IMPS merchant payments? The amount limits for transactions with end-to-end encryption is as follows: Banks are free to set their own limits, based on bank discretion (Refer RBI circular RBI / / 312 DPSS.CO.PD.No / / dated December 23, 2011) The amount limits for transactions without end-to-end encryption is as follows: Transactions up to Rs 5,000/- can be facilitated (As per RBI circular RBI / / 511 DPSS.CO.No / / dated May 04, 2011) Regarding OTP transaction limits, If OTP is generated through unencrypted channels, the transaction limit is Rs 5,000/- and if OTP is generated through encrypted channels, the transaction limit is as decided by the Bank (Rs 50,000/- for most banks, as of now) 10. How can the merchant get on-boarded on IMPS merchant payments? The merchant can get on-boarded on IMPS merchant payments through any of the following: 1. Participating Bank 2. Participating Merchant aggregator For list of participating Banks, please visit For list of services available on IMPS merchant payments, please visit This includes services available through merchant aggregators. Page 9

10 11. Who are the contact persons in the Banks to get on-boarded on IMPS merchant payments? The following officials can be contacted in the Banks to get on-boarded on IMPS merchant payments: Bank Contact Designation Phone person Axis Bank Shri Vinay AVP Internet Vasudev Banking Canara Bank Shri Vishal Sr Manager Corporation Shri K DGM , [email protected] Bank Ramachandran Dombivli Nagari Shri Milind Varerkar DGM IT Officer IT [email protected] [email protected] Sahakari Bank Shri Pratik Gadgil Greater Bombay Bank Shri Milind Mahadik Sr Manager [email protected] HSBC ICICI Bank Kotak Mahindra Bank Standard Chartered Bank State Bank of India Union Bank of India Yes Bank Shri Vijay Lulla Shri Devendra Verma Shri Salil Chugh Shri Saurabh Jain Shri Yogesh Verma Shri Sachin Tiwari New Business Department, State Bank Bhavan, Madame Cama Road, Nariman Point, Mumbai Shri Gyan S Narayan Shri Anand Bajaj Sr Vice President Vice President DGM Chief Manager Product Manager Associate Director, Transaction Banking [email protected] [email protected] [email protected] [email protected] [email protected] , , [email protected] Sr Manager [email protected] (Marketing) EVP [email protected] 12. What are the merchant on-boarding process guidelines for Acquirer Bank? The merchant on-boarding process is as follows: An Acquiring bank should ensure to carry out due diligence before on boarding any merchant to ensure that Page 10

11 the fraudulent merchant set-ups, fly by night operators are not boarded An Acquiring bank must have a defined merchant on-boarding policy duly approved by the senior management of the bank which should outline the process, policy and guidelines to be followed before boarding any merchant on acquiring bank system. If the acquiring bank is acquiring the merchants through third party processors (TPP), they should ensure that the TPP should follow the acquiring bank guidelines. The liability for the merchant on-boarding through TPP rests with the acquiring bank An Acquiring bank should enter into an agreement with the merchant An Acquiring bank must ensure that the payment to the merchant if enrolled through TPP should follow the RBI guidelines (RBI/ /231) 1.4. An acquiring bank should perform the following checks on a merchant before enrolling that merchant as a participant in IMPS. 1. Merchant Business model check 1.1. Verify the physical location of merchant office site inspections of merchant office / place of business and file a visit report by the acquiring bank or the TPP 1.2. Check if actual product/service matches with their claim 1.3. Check the duration of operation for the merchant Conduct Neighbour check for merchants in existence for less than 1 year. 2. Acquiring bank should obtain the proof of business existence for the merchant 3. Manage exposure to risk by choosing merchants based on a strict set of parameters. Recommend to check for the following: 3.1. Previous merchant processing relationship with a foreign/offshore acquirer 3.2. Usage of multiple acquirers 3.3. E-commerce business less than one year old 3.4. New merchant without proof to show acceptable charge-back/fraud records 3.5. Accounts that have quickly exceeded approved processing volumes 3.6. Arrangements with third-party processers with suspicious activity 3.7. User of small value transactions to artificially increase transaction counts Ensure requests for multiple merchant accounts are thoroughly scrutinized Merchant with large number of shell companies 1.5. The following measures are recommended to be taken during the process of ecommerce merchant acquisition to prevent fraud: 1.1. Website Inspection including: Content Products Privacy policy Refund policy Cancellation policy Terms & conditions Website data security Data storage SSL payment options over the internet Links to other sites 1.2. Ensure that the merchant does not process any illegal transaction (e.g.: pornography, rape, terrorism, gambling in goods or services, illegal goods or services) 1.6. It is imperative for acquirers to make sure that mobile payments are as secure as possible. NPCI recommends following guidelines for acquirers so as to ensure the safety of mobile payments. Acquirers should: 1. Check if vendor is able to provide assurance that the code within a payment application has not Page 11

12 been tampered with or altered without authorization. 2. Ensure that the ability to disable mobile payment solution is provided 3. Check for functionality to track usage and key activities within the mobile payment acceptance solution 4. Ensure the transaction and customer data is stored/accessed/transmitted in secure form and according to the secure industry practices. Acquiring Bank has to ensure that the all transaction, customer and merchant related data should be secure and acquiring bank would be held liable for the data compromise resulting in the financial loss to the payment Industry. Liability would be there even if acquiring bank or merchant takes the services of Third Party processors. 5. Provide guidelines to merchants regarding mobile payment best practices 5.1. Any software downloaded onto the consumer mobile device comes from a trusted source 5.2. Ensure that only authorized users (i.e., designated employees) have physical / logical access to the payment functionality 5.3. Report loss/theft of merchant mobile device or other system 5.4. Protect the payment device from malware 6. Ensure that manual intervention in the process is kept to a minimum. 7. Ensure that sensitive data can be accessed only by a few authorized personnel during the entire process 1.7. Third Party Processors: Acquiring Bank 1. Many acquirers use Third Party processors to outsource few activities like transaction processing & customer support. However, it is the responsibility of the acquirer to ensure that the Third Party Processors do not pose any risk to the payment system 2. An Acquirer that uses any Third Party Processor must comply with all requirements as specified by NPCI 3. The acquirer has the overall responsibility for the check & controls to monitor the activities of the Third Party Processors. This includes: 3.1. Control of the approval and review of merchants, and the establishment of merchant fees 3.2. Maintain a file on the TPP that includes all applicable documentation, and retain this file for a minimum of two years following termination of the relationship Identify each Processor and designate the activities that it is authorized to perform on the Acquirer s behalf Guarantee that the Acquirer and its Processors will comply with the NPCI requirements for the use of Agents Accept responsibility for any and all losses caused by its Processor. 4. A third party processor agreement or contract must have a clause that allows the acquirers to terminate the contract if the Third Party processor is involved in any prohibitive or illegal activity that may harm NPCI reputation or if the TPP becomes insolvent 5. The Acquirer or NPCI may conduct an audit of the TPP at any given point of time 1.8. Third Party Processors: Merchant 1. Since Merchants are responsible for the customer data that they provide any Service Provider access to, they should ensure that their Service Providers have validated compliance to secure industry practices for the services provided. Extra scrutiny must be placed on the Service Provider s controls as it raises additional risks to customer data, few steps the merchant must take are as follows: 2. Ensure that the Service Provider furnishes a written document, ensuring that it will appropriately protect customer data in accordance with the industry best practices for the duration of the relationship. This agreement should clearly distinguish between merchant and service provider control. Page 12

13 3. All Service Providers who have an access to the customer data must be listed and monitored by the merchant. 4. Check whether Service Provider comply to secure industry best practices when it comes to protect confidential / business critical information / data 5. Shared Hosting Provider 5.1. A Shared Hosting Provider generally provides Information Technology (IT) services like web hosting, hosting and data center services to multiple customers. Due to economies of scale, Shared Hosting Providers are often able to provide these services at lower rates than if the merchant were to manage these in-house. However, due to the shared nature of these environments, additional risks arise A significant risk is the possibility that a compromise of the data storage environment can result in the breach of many customers data. This risk is particularly notable for shared web hosting environments where virtualization technology is used 5.3. It is thus imperative that a merchant question and evaluate the controls that a Shared Hosting Provider has in place Ensure that a compromise of one of the Shared Hosting Provider s customers will not pose a risk to the data of other customers Merchants should ask their Shared Hosting Provider about the specific controls that they use to assure proper segmentation between customer environments Extra scrutiny should be placed on shared resources including, but not limited to, the management network, disk storage systems, and virtual environment hypervisors The merchant should also address risks that arise if there is a network connection between the merchant s local network and the environment provided by the Shared Hosting Provider 5.8. Ensure that security controls, such as firewalls and intrusion detection/prevention, between the Shared Hosting Provider s environment and the merchant s own local network are implemented 5.9. It is the merchant s responsibility to have a clear understanding with the Shared Hosting Provider as to exactly which controls are to be provided by them and which are to be provided by the merchant. 13. For Customer initiated transaction (P2M PUSH), what is the transaction message flow? Page 13

14 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 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 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 Note: The interface between acquiring bank and merchant / aggregator is up to the acquiring bank to implement. The following situations may be possible, and it is up to the Bank to decide: 1) The integration between acquiring bank and merchant could be through a merchant aggregator 2) The credit to the merchant account may or may not be instant, and bank may decide to settle funds instantly or on offline basis 3) The merchant system may not be updated real-time online, and may be done offline, in a batch process 4) The verification step may or may not be used 5) The online verification and merchant system update step may be clubbed together 13.1 What if there is an error in payment reference and amount entered by customer? The transaction flow in this case is as follows: Page 14

15 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 and amount to the merchant back-end system 7) Merchant verifies the payment reference and amount and reverts with error status 8) Acquiring bank does not credit the merchant account 9) Acquiring bank sends the transaction response to NPCI, with response code MA along with error message description 10) NPCI forwards the transaction response to Issuing Bank 11) Issuing bank reverses the customer debit, sends confirmation SMS to customer, and sends response to customer in Issuing bank application 12) Acquiring bank updates merchant back-end system 13.2 What if acquiring bank is not able to send payment reference verification request to merchant? The transaction flow in this case is as follows: Page 15

16 1. Customer initiates transaction through Issuing Bank mobile banking application, enters merchant MMID, mobile number, Amount, M-PIN, 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 is not able to send verification of payment reference request to merchant due to communication failure 7. Acquiring bank generates Transaction Denied message with response code MF (Merchant system not available, please try again) 8. Acquiring bank sends response to NPCI 9. NPCI forwards the transaction response to Issuing Bank 10. Issuing Bank reverses the customer debit, and sends confirmation SMS to customer, and sends response to customer in Issuing bank application 11. Acquiring bank updates merchant back-end system (if required) 13.3 What if there is no response from merchant to payment reference verification request? The transaction flow in this case is as follows: Page 16

17 1. Customer initiates transaction through Issuing Bank mobile banking application, enters merchant MMID, mobile number, Amount, M-PIN, 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 verification of payment reference request to merchant 7. Merchant not able to respond to verification request 8. Acquiring bank generates Transaction Denied message with response code MF (Merchant system not available, please try again) 9. Acquiring bank sends response to NPCI 10. NPCI forwards the transaction response to Issuing Bank 11. Issuing Bank reverses the customer debit, and sends confirmation SMS to customer, and sends response to customer in Issuing bank application 12. Acquiring bank updates the merchant back-end system (if required) 13.4 What if payment reference online verification is successful, but merchant back-end system is not updated successfully? The transaction flow in this case is as follows: 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 policy number and amount and reverts with status Page 17

18 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, 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 13.5 What if there is no online interface with merchant? The transaction flow in this case is as follows: 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, 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 8) NPCI forwards the transaction response to Issuing Bank 9) Issuing Bank sends confirmation SMS to customer, and sends response to customer in Issuing bank application 13.6 What if acquiring bank rejects transaction? The transaction flow in this case is as follows: Page 18

19 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, and rejects the transaction with negative response code 6) Acquiring bank sends the transaction response with negative response code to NPCI 7) NPCI forwards the transaction response to Issuing Bank 8) Issuing Bank reverses the customer debit, and sends confirmation SMS to customer, and sends response to customer in Issuing bank application The decline from acquiring bank can be due to multiple reasons such as account validations, wrong MMID / Mobile number of merchant, other reasons, etc 13.7 What if customer wants to make payment to individual beneficiary, but uses person-to-merchant form on mobile banking application? The transaction flow in this case is as follows: Page 19

20 1. Customer initiates transaction through Issuing Bank mobile banking application, enters merchant MMID, mobile number, Amount, M-PIN, Payment reference in the person-to-merchant form 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 5. Acquiring bank checks if the merchant mobile number and merchant MMID belong to the merchant or an individual. If individual, 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 8. Issuing Bank sends confirmation SMS to customer, and sends response to customer in Issuing bank application 13.8 What if customer wants to make payment to merchant, but uses personto-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. If merchant, then beneficiary bank will decline the transaction with response code ML - Payee is a merchant and not an individual. Please use person-to-merchant form for making payment, and advises the customer to use person-to-merchant form for making payment instead. Response is sent by acquiring bank to NPCI 6. NPCI forwards the response to Remitter bank 7. Remitter Bank reverses the customer debit Page 20

21 8. Remitter Bank sends confirmation SMS to customer, and sends response to customer in Remitter bank application 13.9 What if there is time-out in the transaction flow? Timeout scenarios to 1 During Debit Between Issuing Bank and its CBS. Reversal will be generated by Issuing Bank system CBS and the transaction is not processed further. Customer is appropriately informed After Debit Between Issuing Bank and NPCI Issuing Bank will treat this as time-out transaction. 2 Issuing Bank will send out Verification Request giving the reference number of the original transaction to NPCI. Verification request is sent post time-out period of original transaction (30 seconds). Issuing Bank may send max up to 3 verification requests for one transaction, if it does not receive a response. Acquiring Bank will respond to this request as per status of original transaction ( 00 for successful verification and credit transaction and M0 for credit not successful but verification is successful). Based on response to this request, Issuing Bank shall reverse the earlier debit (if response code is M0 ). After Debit between NPCI and Acquiring Bank This transaction is responded by time-out response 3 Code by NPCI and send to Issuing Bank. Upon receiving a time-out response, Issuing Bank will send out a verification request giving the reference number of the original transaction to NPCI. Verification request is sent post time-out period of original transaction (30 seconds). Issuing Bank may send max up to 3 verification requests for one transaction, if it does not receive a response. Acquiring Bank will respond to this request as per status of original transaction ( 00 for successful verification and credit transaction and M0 for credit not successful but verification is successful). Based on response to this request, Issuing Bank shall reverse the earlier debit (if response code is M0 ). 4 After Debit between Acquiring Bank switch and CBS This transaction is responded by time-out Page 21

22 Response code by Acquiring bank to NPCI and NPCI passes it to Issuing Bank. Issuing Bank will send out a verification request giving the reference number of the original transaction to NPCI. Verification request is sent post time-out period of original transaction (30 seconds). Issuing Bank may send max up to 3 verification requests for one transaction, if it does not receive a response. Acquiring Bank will respond to this request as per status of original transaction ( 00 for successful verification and credit transaction and M0 for credit not successful but verification is successful). Based on response to this request, Issuing Bank shall reverse the earlier debit (if response code is M0 ). 14. For Merchant initiated transaction (P2M PULL), what is the transaction message flow? The transaction flow is as follows: 1. The customer can initiate the transaction through merchant application. Merchant application could be based on Web, IVR, or mobile handheld application. Customer enters following information for payment a. Customer mobile number b. Customer MMID c. Amount d. OTP 2. The transaction is forwarded by merchant application to acquiring bank switch. The information sent by merchant application includes above payment information by customer, as well as merchant mobile number and MMID 3. The Acquiring Bank validates merchant credentials (this includes merchant mobile number, MMID, and may be IP address, username, password, etc as may be provided by acquiring bank to merchant for authentication of merchant) and sends the transaction to NPCI 4. NPCI validates the request, and based on the NBIN (part of MMID), NPCI identifies the issuing bank and sends the transaction to the same for debit from the customer account 5. The issuing bank verifies the customer details, fetches the account number and debits the customer account (based on customer mobile number, customer MMID, amount, and OTP) 6. The issuing bank sends the transaction response to NPCI 7. The issuing bank sends an SMS confirmation to the customer informing him of the debit 8. NPCI sends this response to the acquiring bank 9. Acquiring bank based on the response received, credits the merchant account 10. Acquiring bank sends the transaction response to merchant application 11. Merchant application sends the transaction response to customer via SMS Page 22

23 14.1 What if there is rejection at Issuing Bank? 1. Merchant application sends request to acquiring bank. This information includes customer mobile number, customer MMID, amount, OTP, merchant mobile number, merchant MMID. 2. The acquiring bank validates merchant credentials (this includes merchant mobile number, merchant MMID, IP address, username, password, etc, as may be provided by acquiring bank to merchant for authentication of merchant) and originates a financial request 3. The acquiring bank sends this financial request to NPCI 4. NPCI validates the request and forwards this financial request to issuing bank 5. The issuing bank rejects transaction due to some error, and generates an appropriate financial response 6. The issuing bank sends this financial response to NPCI 7. NPCI forwards this financial response to the acquiring bank 8. Acquiring bank sends response to merchant application, and may send SMS to merchant mobile number 14.2 What if there is rejection at NPCI? 1. Merchant application sends request to acquiring bank. This information includes customer mobile number, customer MMID, amount, OTP, merchant mobile number, merchant MMID. 2. The acquiring bank validates merchant credentials (this includes merchant mobile number, merchant MMID, IP address, username, password, etc, as may be provided by acquiring bank to merchant for authentication of merchant) and originates a financial request 3. The acquiring bank sends this financial request to NPCI Page 23

24 4. NPCI validates the request and rejects because of NBIN of customer is not in the list of valid NBINs in the repository of NPCI, or member bank limit is exceeded or the issuing bank is not yet enabled for IMPS merchant payments 5. NPCI sends response to acquiring bank with response code 86 or M6 or MG respectively 6. Acquiring bank sends response to merchant application, and may send SMS to merchant mobile number 14.3 What if Acquiring Bank cannot forward message to NPCI due to communication failure? 1. Merchant application sends request to acquiring bank. This information includes customer mobile number, customer MMID, amount, OTP, merchant mobile number, merchant MMID. 2. The acquiring bank validates merchant credentials (this includes merchant mobile number, merchant MMID, IP address, username, password, etc, as may be provided by acquiring bank to merchant for authentication of merchant) and originates a financial request 3. Acquiring Bank is not able to forward the request to NPCI. 4. Acquiring bank generates 08 (Transaction declined) response and sends to merchant application, and may send SMS to merchant mobile number 14.4 What if NPCI cannot forward the financial message to Issuing Bank due to communication failure? 1. Merchant application sends request to acquiring bank. This information includes customer mobile number, customer MMID, amount, OTP, merchant mobile number, merchant MMID. 2. The acquiring bank validates merchant credentials (this includes merchant mobile number, merchant MMID, IP address, username, password, etc, as may be provided by acquiring bank to merchant for authentication of merchant) and originates a financial request 3. The acquiring bank sends this financial request to NPCI Page 24

25 4. NPCI validates the request and is not able to forward this financial request to the issuing bank 5. Since NPCI does not provide the stand-in processing on behalf of the issuing bank, it generates and sends a response with response code 08 to the acquiring bank 6. Acquiring bank sends the response to merchant application with Transaction Declined message, and may send SMS to merchant mobile number 14.5 What if Issuing Bank cannot forward the financial message to its CBS due to communication failure? 1. Merchant application sends request to acquiring bank. This information includes customer mobile number, customer MMID, amount, OTP, merchant mobile number, merchant MMID. 2. The acquiring bank validates merchant credentials (this includes merchant mobile number, merchant MMID, IP address, username, password, etc, as may be provided by acquiring bank to merchant for authentication of merchant) and originates a financial request 3. The acquiring bank sends this financial request to NPCI 4. NPCI validates the request and forwards this financial request to the Issuing bank 5. The issuing bank is not able to forward this financial message to its CBS 6. The issuing bank generates a response financial message with the response code The issuing bank sends this financial response to NPCI 8. NPCI forwards this financial response to the acquiring bank 9. Acquiring bank sends response to merchant application with Transaction Declined message, and may send SMS to merchant mobile number 14.6 What if Issuing Bank does not receive response from its CBS after sending the financial message due to communication failure? Page 25

26 1. Merchant application sends request to acquiring bank. This information includes customer mobile number, customer MMID, amount, OTP, merchant mobile number, merchant MMID. 2. The acquiring bank validates merchant credentials (this includes merchant mobile number, merchant MMID, IP address, username, password, etc, as may be provided by acquiring bank to merchant for authentication of merchant) and originates a financial request 3. The acquiring bank sends this financial request to NPCI 4. NPCI validates the request and forwards this financial request to the Issuing bank 5. The issuing bank forwards this financial message to its CBS 6. The issuing bank CBS does not respond to the issuing bank 7. Issuing Bank reverses the entry, and sends a response financial message with response code The issuing bank sends this financial response to NPCI 9. NPCI forwards the financial response to the acquiring bank 10. Acquiring bank sends the response to merchant application with Transaction Denied message, and may send SMS to merchant mobile number 14.7 What if Issuing Bank does not respond to NPCI after sending the financial message due to communication failure? 1. Merchant application sends request to acquiring bank. This information includes customer mobile number, customer MMID, amount, OTP, merchant mobile number, merchant MMID. 2. The acquiring bank validates merchant credentials (this includes merchant mobile number, merchant MMID, IP address, username, password, etc, as may be provided by acquiring bank to merchant for authentication of merchant) and originates a financial request 3. The acquiring bank sends this financial request to NPCI Page 26

27 4. NPCI validates the request and forwards this financial request to the Issuing bank 5. The issuing bank forwards this financial message to its CBS 6. The issuing bank CBS debits the customer account (based on customer mobile number, MMID, amount, and OTP) and responds to issuing bank 7. The issuing bank either does not generate a response financial message or is not able to send this financial response message to NPCI 8. Since NPCI does not provide the stand-in processing on behalf of the issuing bank, it generates and sends a time out response with response code 91 to the acquiring bank 9. NPCI initiates a 0420 reversal advice and forwards this message to Issuing Bank (response code 91 ) 10. The Issuing Bank responds with the appropriate 0430 Reversal Advice Response and forwards this message to NPCI 11. Acquiring bank sends the response to merchant application with Transaction Denied message, and may send SMS to merchant mobile number 14.8 What if NPCI does not forward response to Acquiring Bank after receiving the financial message from Issuing Bank, due to communication failure? 1. Merchant application sends request to acquiring bank. This information includes customer mobile number, customer MMID, amount, OTP, merchant mobile number, merchant MMID. 2. The acquiring bank validates merchant credentials (this includes merchant mobile number, merchant MMID, IP address, username, password, etc, as may be provided by acquiring bank to merchant for authentication of merchant) and originates a financial request 3. The acquiring bank sends this financial request to NPCI 4. NPCI validates the request and forwards this financial request to the Issuing bank 5. The issuing bank debits the customer account (based on customer mobile number, MMID, amount, and OTP) and generates a response financial message 6. Issuing bank sends response message to NPCI 7. Issuing bank sends SMS to customer about debit 8. NPCI is not able to send response message to acquiring bank due to communication failure 9. Acquiring bank initiates a 0420 reversal advice and forwards this message to NPCI (response code 68 ) 10. NPCI forwards the 0420 message to Issuing Bank 11. Issuing bank credits the customer account and generates a response 0430 message 12. Issuing bank sends 0430 response message to NPCI 13. Issuing bank sends SMS to customer about credit 14. NPCI forwards 0430 message to Acquiring Bank 15. Acquiring bank sends the response to merchant application with Transaction Denied message, and may send SMS to merchant mobile number Page 27

28 14.9 What if Acquiring bank is not able to forward message to its CBS, after receiving the financial message from Issuing Bank, due to communication failure? 1. Merchant application sends request to acquiring bank. This information includes customer mobile number, customer MMID, amount, OTP, merchant mobile number, merchant MMID. 2. The acquiring bank validates merchant credentials (this includes merchant mobile number, merchant MMID, IP address, username, password, etc, as may be provided by acquiring bank to merchant for authentication of merchant) and originates a financial request 3. The acquiring bank sends this financial request to NPCI 4. NPCI validates the request and forwards this financial request to the Issuing bank 5. The issuing bank debits the customer account (based on customer mobile number, customer MMID, amount, and OTP) and generates a response financial message 6. Issuing bank sends response message to NPCI 7. Issuing bank sends SMS to customer about debit 8. NPCI forwards response message to acquiring bank 9. Acquiring bank not able to forward message to its CBS 10. Acquiring bank sends 0420 reversal advice to NPCI (response code 21 ) 11. NPCI forwards the 0420 message to Issuing Bank 12. Issuing bank credits the customer account and generates a response 0430 message 13. Issuing bank sends 0430 response message to NPCI 14. Issuing bank sends SMS to customer about credit 15. NPCI forwards 0430 message to Acquiring Bank 16. Acquiring bank sends the response to merchant application with Transaction Denied message, and may send SMS to merchant mobile number What if acquiring bank does not receive response from CBS, after sending message to CBS for merchant credit, due to communication failure? Page 28

29 1. Merchant application sends request to acquiring bank. This information includes customer mobile number, customer MMID, amount, OTP, merchant mobile number, merchant MMID. 2. The acquiring bank validates merchant credentials (this includes merchant mobile number, merchant MMID, IP address, username, password, etc, as may be provided by acquiring bank to merchant for authentication of merchant) and originates a financial request 3. The acquiring bank sends this financial request to NPCI 4. NPCI validates the request and forwards this financial request to the Issuing bank 5. The issuing bank debits the customer account (based on customer mobile number, MMID, amount, and OTP) and generates a response financial message 6. Issuing bank sends response message to NPCI 7. Issuing bank sends SMS to customer about debit 8. NPCI forwards response message to acquiring bank 9. Acquiring bank forwards message to its CBS 10. CBS not able to respond back to Acquiring Bank 11. Acquiring bank reverses transaction at its end, and forwards reversal advice 0420 message to NPCI (response code 21 ) 12. NPCI forwards the 0420 message to Issuing Bank 13. Issuing bank credits the customer account and generates a response 0430 message 14. Issuing bank sends 0430 response message to NPCI 15. Issuing bank sends SMS to customer about credit 16. NPCI forwards 0430 message to Acquiring Bank 17. Acquiring bank sends the response to merchant application with Transaction Denied message, and may send SMS to merchant mobile number What if Acquiring Bank is not able to respond to merchant due to communication failure? Page 29

30 1. Merchant application sends request to acquiring bank. This information includes customer mobile number, customer MMID, amount, OTP, merchant mobile number, merchant MMID. 2. The acquiring bank validates merchant credentials (this includes merchant mobile number, merchant MMID, IP address, username, password, etc, as may be provided by acquiring bank to merchant for authentication of merchant) and originates a financial request 3. The acquiring bank sends this financial request to NPCI 4. NPCI validates the request and forwards this financial request to issuing bank 5. The issuing bank debits the customer account (based on customer mobile number, customer MMID, amount, and OTP) and generates an appropriate financial response 6. The issuing bank sends this financial response to NPCI 7. Issuing bank sends SMS to customer with transaction status 8. NPCI forwards this financial response to the acquiring bank 9. Acquiring bank credits the merchant account 10. Acquiring bank sends SMS to merchant mobile number. Acquiring bank is not able to send the response to merchant application 11. Merchant application should be able to pull the transaction status from acquiring bank via API. Acquiring bank should provide appropriate API to merchant for the same, and this should be part of the integration between merchant and acquiring bank What if there is time-out to the reversal advice message? 1. If timeout appears, the acquirer or NPCI will create and repeat a 0421 reversal request in regular intervals until the number of repetitions reaches a pre-defined value (3 excluding first 0420) or the 0430 response is received 2. Upon receipt of 042x request, the NPCI or issuer will match this message to possible previous messages and perform the appropriate action based on matching result 15. What is the dispute management process for IMPS merchant payments? Page 30

31 IMPS offers Dispute Management System (DMS) to member banks for handling disputes in the transactions. Following facilities are available through DMS system: 1. Debit adjustment 2. Credit adjustment (Refund) 3. Chargeback 4. Re-presentment 5. Pre-arbitration 6. Pre-arbitration accept / decline 7. Arbitration 8. Good-faith 15.1 Debit adjustment Debit adjustment is applicable to P2M Push transactions which are timed-out. The merchant account is credited by acquiring bank, but the status is not known to NPCI or to Issuing Bank because of connectivity failure. Issuing bank initiated 3 verification requests as well, but not able to get the status because of time-out issue. In this particular situation, the debit to customer account is not reversed by the Issuing Bank. The interbank settlement is also not done for this transaction by NPCI. If merchant account is credited by acquiring bank, but they have not received the credit by NPCI, they shall incur shortfall for this transaction. Therefore, Acquiring bank can raise debit adjustment for this transaction through DMS system. Debit adjustment can be raised only in following situations: 1. The transaction is time-out 2. Acquiring bank can raise debit adjustment 3. Debit adjustment can be raised within 7 days of transaction date Once the debit adjustment is raised, acquiring bank shall be credited and issuing bank shall be debited. This shall happen automatically next day by NPCI. Acquiring bank shall identify such transactions through their reconciliation process. If merchant account is not credited, acquiring bank shall not take any action. Issuing bank can then reverse the customer debit after 7 days Credit adjustment (Refund) There are instances in which the Acquiring Bank or the merchant needs to issue refund to the Issuing Bank. The situations in which refund could be raised are as follows: 1. Non-receipt of goods/services 2. Not as described or defective merchandise 3. Cancelled / Returned goods/services 4. Incorrect transaction amount 5. Duplicate processing 6. Incorrect payment reference Page 31

32 7. Customer account is debited, but merchant account not credited, and reversal of customer debit not processed Facility for raising credit adjustment (Refund) is available in the DMS system. Credit adjustment can be raised in following conditions: 1. Acquiring bank can raise credit adjustment 2. Credit adjustment can be raised for successful transactions 3. Credit adjustment can be raised within 60 days of transaction date 4. Credit adjustment cannot be raised if chargeback is already raised for this record 5. Facility to provide partial credit adjustment shall be available in the system. Multiple partial credit adjustments can be raised as well as long as sum total of credit adjustments does not exceed the original transaction amount. Credit adjustment can be raised as single record, or as bulk upload. The credit adjustment records shall be picked up in the settlement cycle. Acquiring bank shall be debited and Issuing Bank shall be credited. This shall happen automatically next day by NPCI. Acquiring Bank can upload bulk file with following fields to raise credit adjustments: 1. Bank adjustment reference 2. Transaction date 3. Adjustment amount 4. RRN 5. Reason code 15.3 Chargeback Chargeback can be raised by Issuing Bank, within 60 days of transaction date. Chargeback can be raised for the reasons as shown below. Please note that chargeback can be raised only for technical reasons currently, and not for business reasons. Issuing bank should provide documentation for the chargeback as shown below. When chargeback is raised, acquiring bank shall be debited and Issuing bank shall be credited. This will happen next day automatically by NPCI. Reason code Reason description Documentation required 102 Customer account is debited, merchant Issuing bank CBS and mobile payment switch logs to demonstrate customer account was debited account is not credited, Customer account information to demonstrate debit and reversal of Customer complaint regarding merchant account not credited customer debit is not NPCI record containing transaction status processed Settlement records demonstrating transaction was settled Documentation to prove there was no credit adjustment raised by the acquiring bank Page 32

33 107 Duplicate processing RRN number of first transaction must be provided. The merchant name and location, transaction amount, payment reference (if provided), and the transaction date must be the same. Issuers must review transactions presented with ticket numbers closely. If the ticket numbers are different, the transactions are not considered duplicates, although the merchant locations, transaction amounts, and transaction dates may be the same 15.4 Re-presentment 1. Acquiring bank can re-present the charge to NPCI, for the chargeback dispute case, within 30 days of chargeback date 2. Acquiring bank can upload the evidence copies via online DMS system. 3. When re-presentment is raised, issuing bank will be debited, and acquiring bank will be credited. This will happen the next day automatically by NPCI 4. The reason code to be used for re-presentment and documentation to be provided is as depicted below Chargeback reason Customer account is debited, merchant account is not credited, and reversal of customer debit is not processed 107 Duplicate processing Re-presentment reason See corresponding documentation / chargeback remedied 204 Credit previously issued See corresponding documentation / chargeback remedied 204 Credit previously issued Documentation required The acquirer needs to substantiate that merchant account was credited, and need to provide following supporting documentation a. Acquiring bank CBS and mobile payment logs that indicate that merchant account was credited b. Merchant account information The acquirer needs to provide the date that it processed the credit to the customer s account The acquirer can provide documentation to support two separate transactions by providing two different TIDs with the same customer account number The acquirer needs to provide the date that it processed the credit to customer s account 15.5 Pre-arbitration 1. If the chargeback was valid and acquirer failed to remedy the dispute properly, the issuer may continue the chargeback through pre-arbitration procedure. Pre-arbitration can be raised within 30 days of representment 2. A progressive documentation is required with the pre-arbitration in response to new information or rebutting any acquirer explanation provided with the re-presentment. The progressive documentation Page 33

34 must be dated after the re-presentment and specifically address the rebuttal provided with the representment 3. Disputes satisfying the validation process will be processed by DMS Online system 4. Acquiring Bank has to respond to the pre-arbitration raised by Issuing Bank within 15 days from the prearbitration date 15.6 Pre-arbitration decline 1. Acquiring Bank can decline the pre-arbitration along with reasons and attachments. A progressive documentation is required with the pre-arbitration decline in response to new information or rebutting any issuing bank explanation provided with the pre-arbitration. The progressive documentation must be dated after the pre-arbitration and specifically address the rebuttal provided with the pre-arbitration Pre-arbitration Accept 1. Acquiring bank can accept the pre-arbitration within 15 days, and the amount of re-presentment will be reversed to the Issuing bank. 2. In the absence of response from the Acquiring Bank within 15 days, the pre-arbitration submitted by the Issuing Bank would be considered as accepted (by default) and the amount of re-presentment will be reversed to the Issuing Bank. 3. In case of acceptance of pre-arbitration or deemed acceptance (in absence of response), a flat penalty of Rs 100 will be imposed at the time of Pre-arbitration, for uploading of incorrect copies of documents / records by Acquiring Bank. This amount will be credited to the Issuing Bank Arbitration 1. Where a decline by the Acquiring Bank is not acceptable to the Issuing Bank, they can refer the issue for arbitration by manual process What are the procedures for handling arbitration in the IMPS network? The procedures for handling arbitration in the IMPS network are as follows: 1. The timeframe for referring a dispute to arbitration is 30 days from the date of closure of pre-arbitration process 2. All disputes pertaining to settlements will be referred to Panel for Resolution of Disputes (PRD) 3. The processing fee for referring dispute to arbitration is Rs The Panel for Resolution of Disputes (PRD) as defined in the RBI circular DPSS.CO.CHD.No. 654/ / dated September 2010 will be constituted from the members of the steering committee 5. The PRD will comprise of 5 members, 4 members of the steering committee and the Chairman who will be either the Chief Executive Officer or the Chief Operating Officer of NPCI. Following are the members of PRD for IMPS: Page 34

35 1) SBI 2) ICICI Bank 3) Axis Bank 4) Corporation Bank The COO of NPCI shall be the Chairman. 6. In case of specific disputes involving any member(s) of the PRD, the member(s) concerned shall be replaced by other member(s) of IMPS for the limited purpose of looking into the specific dispute. 7. The PRD shall dispose of the dispute within 15 working days of submitting the dispute 8. Any party aggrieved by the decision of PRD can approach the Appellate Authority for review. Relevant provisions of RBI circular DPSS.CO.CHD.No. 654/ / dated September 24, 2010 will be applicable. 9. The Appellate Authority shall dispose of the appeal within 15 working days of submitting the appeal 10. Until the disposal of appeal by the Appellate Authority, the PRD can decide to levy the refund / compensation and hold such amount in an interim account till disposal of the appeal as per the RBI circular DPSS.CO.CHD.No. 654/ / dated September What is the Penalty for non-compliance of Settlement Guidelines NPCI will levy a penalty of Rs 100 for each instance of non-compliance of any provision of the IMPS Dispute Management & Settlement guidelines What are the Good-faith guidelines for IMPS transactions? 1. The good-faith window is available for those cases where chargeback/re-presentment/debit adjustment timeframe is lapsed 2. Transactions for which chargeback/re-presentment/debit adjustment was not raised within the prescribed timeframe can be represented through the good-faith 3. The good-faith request has to be lodged by issuer/acquirer within 30 days of expiry date of chargeback/re-presentment/debit adjustment. The good-faith resolution timeframe is 30 days from the date of raising good-faith 4. Only accepted cases will have a commercial impact. The transaction value will be included in that days settlement files for transfer of money to the member bank account 5. For decline cases, there will be no commercial impact What are the guidelines for handling customer complaints in IMPS network? In mobile remittance a debit to a customer s account takes place first at his / her request and therefore it is expected that there can only be complaint about beneficiary not receiving the credit. Any complaint about credit not being given to a beneficiary should be conclusively and bilaterally dealt with by the Remitting and Beneficiary banks within 3 days from the date of the complaint 16. What are the features required in merchant acquiring platform? The merchant acquiring platform needs to have following features: Page 35

36 1. Merchant account setup 2. Integration with merchant back-end system 3. Merchant technical configuration 4. Merchant financial configuration 5. Transaction processing 6. Transaction MIS 7. Reconciliation 8. Settlement with merchant 9. Refund processing 10. Dispute management system 17. How does merchant get integrated with Acquiring Bank? Integration kit is shared between Merchant and Acquiring Bank, and integration carried out accordingly For push transactions Acquiring bank should be able to integrate with merchant back-end system for payment reference verification and update of merchant back-end system after transaction is complete 17.2 For pull transactions API to be provided by acquiring bank to merchant for integration with merchant website / WAP application For SMS / IVR / mobile handset application, the following integration could be required with merchant application: 1. Pre-payment integration before the payment, the merchant payment reference data may need to be verified. This can be done through the pre-payment merchant URL, where merchant URL is called and payment reference field is passed. If successful response is received, further processing is done for payment transaction, otherwise error message is sent 2. Post-payment integration after the payment, the merchant back-end system may be called to update the transaction status at the back-end The above two can be configured in the merchant technical configuration of the merchant account Verification integration - If response is not received by merchant for transaction request, merchant should be able to call verification URL for verifying transaction status at acquiring bank. Page 36

37 18. What are the various interfaces through which merchant can receive payment via IMPS merchant payments PULL transaction? Acquiring bank needs to provide an application to merchant to receive payment. Following types of applications can be provided: 1. Web application for receiving payments via web 2. IVR application 3. Merchant mobile handset application for receiving payments from customers 4. SMS based application 18.1 Web application for integration with merchant web site Acquiring bank will provide a payment web page. This will be integrated with merchant website. Customer will be redirected to this webpage during the payment step of the transaction. The following parameters will be passed from merchant website to the payment web page: 1. Merchant user name 2. Merchant password 3. Merchant IP address 4. Amount (if pre-populated) 5. Customer mobile number (if pre-populated) 6. Payment reference (if pre-populated) The payment web page will validate the merchant details, such as user name, password, IP address, and allow payment only if validation is successful The above page will contain following input fields from customer: 1. Customer mobile number 2. Customer MMID 3. OTP 4. Amount (pre-populated, if available) 5. Payment reference (pre-populated, if available) This will be a secure page. Information from the secure page will be sent to the acquiring bank switch. Following parameters will be sent to acquiring bank switch: 1. Merchant mobile number 2. Merchant MMID 3. Customer mobile number 4. Customer MMID 5. OTP 6. Amount 7. Payment reference 18.2 WAP application for integration with merchant WAP site Page 37

38 Similar to above web application 18.3 IVR application Acquiring bank will provide an IVR number to merchant for receiving payments. Merchant can call the IVR number, and will be prompted to enter merchant ID. If merchant calls from his registered mobile number or phone number, the step to capture merchant ID can be skipped. Upon identifying the merchant, IVR will prompt to enter amount. Merchant will then be asked to conference the customer with the IVR call. Customer will get the confirmation of merchant name, and amount to be paid, will be prompted to asked to enter mobile number, MMID, and OTP. The information will be sent to acquiring bank switch, and IVR will wait for transaction status to be received. Once the transaction status is received, customer will be informed about the same on the IVR call Merchant mobile handset application Acquiring bank can provide a mobile handset application to the merchant. Merchant downloads the application on his handset and registers his mobile number with the acquiring bank. The application has a Receive payment form on the handset application. For receiving payment from customer, the merchant enters customer mobile number, MMID, OTP, amount, and payment reference. Merchant is identified from the mobile number from where the request is initiated. The transaction status is received on the mobile handset application of merchant SMS based application for customer Customer sends SMS with following parameters: merchant short name, amount, payment reference, MMID, OTP The acquiring bank platform validates the merchant short name, payment reference, amount. On successful validation, acquiring bank shall send customer mobile number, MMID, and OTP to NPCI for further transaction processing. Upon successful response, customer and merchant receive confirmation SMS SMS based application for merchant Merchant can initiate payment via SMS for receiving payment from customer. Merchant registers his mobile number with his merchant account with the acquiring bank. From his registered mobile number, merchant sends SMS with following parameters: 1. Customer mobile number 2. Amount 3. Payment reference An IVR call or USSD message is made to the customer mobile number, and is prompted for merchant name, amount and is asked to confirm or reject the transaction. Alternatively, merchant sends SMS with customer mobile number, MMID and OTP. Upon confirmation, customer will be asked to enter MMID, and OTP. Page 38

39 Upon successful transaction confirmation, an SMS will go to customer as well as merchant Reminder SMS based application Merchant can send a reminder SMS to customer for payment. The SMS will contain details about the payment. Customer will respond to the SMS with a reply SMS, and will send following parameters in the SMS: 1. Merchant ID 2. Amount 3. Payment reference 4. Customer MMID 5. OTP The acquiring bank will receive the SMS, will validate the various information, along with payment reference, and does transaction processing through NPCI Upon successful transaction confirmation, an SMS will go to customer as well as merchant Merchant server application Customer can call merchant call center for ordering product /service and making payment. The agent will help customer with the order, and enter following information in his merchant server application: 1. Customer mobile number 2. Amount 3. Payment reference Merchant will initiate the payment transaction upon entering the above information. Customer will receive an IVR call or USSD message on his mobile and will prompted for merchant name, amount and is asked to confirm or reject the transaction. Upon confirmation, customer will be asked to enter MMID, and OTP. Upon successful transaction confirmation, an SMS will go to customer as well as merchant USSD based application Merchant can initiate payment transaction via USSD. Acquiring bank to provide USSD number to the merchant. Merchant initiates transaction through the USSD number. A form is sent by the USSD server to the merchant, and merchant is prompted to enter customer mobile number, amount, and payment reference. Upon entry of these details, a USSD message or IVR call will be sent to customer and will be prompted for merchant name and amount and will be asked to confirm or reject the transaction. Upon confirmation, customer Page 39

40 will be asked to enter customer MMID, and OTP. Alternatively, merchant enters customer mobile number, MMID and OTP on the USSD form. Upon successful transaction confirmation, an SMS will go to customer as well as merchant STK based application The merchant transaction initiation form will be available on the merchant SIM card. Merchant accesses the form on the SIM card for initiating payment from customer, and enters following parameters 1. Customer mobile number 2. Amount 3. Payment reference An IVR call or USSD message is sent to the customer mobile number, and is prompted for merchant name, amount and is asked to confirm or reject the transaction. Upon confirmation, customer will be asked to enter MMID, and OTP. Alternatively, merchant enters customer mobile number, MMID and OTP on the USSD form. Upon successful transaction confirmation, an SMS will go to customer as well as merchant WAP based application Merchant can access the WAP site provided by acquiring bank for initiate payment transaction from customer. Merchant can log on to the WAP site, and can access payment initiation page. Merchant will enter customer mobile number, amount, payment reference. An IVR call or USSD message is sent to the customer mobile number, and is prompted for merchant name, amount and is asked to confirm or reject the transaction. Upon confirmation, customer will be asked to enter MMID, and OTP. Alternatively, merchant enters customer mobile number, MMID and OTP on the USSD form. Upon successful transaction confirmation, an SMS will go to customer as well as merchant Internet based application Merchant can access the Internet site provided by acquiring bank for initiate payment transaction from customer. Merchant can log on to the web site, and can access payment initiation page. Merchant will enter customer mobile number, amount, payment reference. An IVR call or USSD message is sent to the customer mobile number, and is prompted for merchant name, amount and is asked to confirm or reject the transaction. Upon confirmation, customer will be asked to enter MMID, and OTP. Alternatively, merchant enters customer mobile number, MMID and OTP on the USSD form. Upon successful transaction confirmation, an SMS will go to customer as well as merchant. Page 40

41 19. What is the merchant configuration required at the acquiring bank platform? The following configuration needs to be there in the acquiring side platform: 19.1 Merchant set-up Acquiring bank could set up the merchant account through web interface. Access should be provided on need basis to required personnel. Bank should be able to enter following information related to the merchant: 1. Merchant name 2. Address 3. Contact information 4. Merchant MMID 5. Merchant Mobile number 6. Merchant account number 7. Merchant IFSC code 8. Merchant category code 19.2 Merchant configuration Following configuration is required for merchant: 1. Payment reference is mandatory or not 2. Real-time validation is required or not 3. Real-time status update is required or not after transaction 4. Confirmation SMS is required to be sent to merchant or not 5. Confirmation is required to be sent to merchant or not 6. Mobile number(s) from where merchant can initiate payment via SMS / USSD / STK If real-time validation is required, the pre-payment URL is required to be configured If real-time status update is required, the post-payment URL is required to be configured If confirmation SMS is required, merchant mobile number is required to be configured where SMS is to be sent If confirmation is required, merchant is required to be configured where is to be sent 19.3 Financial configuration The following financial configuration is required to be configured: 1. Transaction fee from merchant 20. What facility is required for transaction status verification for merchant? An interface should be provided to merchant to verify the transaction status. This is useful in case the transaction is complete, but merchant doesn t get to see the transaction status. Page 41

42 An online API to be provided to merchant that can be used to check transaction status as exception handling process. In case merchant does not get transaction status, he can call this URL 3 times in 30 seconds interval and get transaction status. Apart from exception handling, this interface can be used for getting ad-hoc transaction status as well. 21. What MIS facility may be provided by Acquiring Bank to the merchant? Acquiring Bank may provide an interface to the merchant to get transaction MIS. The MIS may provide following facilities to the merchants, so they are able to cater to customer s queries without escalating queries to the Bank every time 1. Download the transactions through MIS for a particular date 2. Download the refunded transactions for a particular date 3. Track the complete lifecycle of particular transaction a. Life cycle starts with transaction details (transaction date, amount, merchant transaction id, Bank transaction id, etc) b. Refund details (if refund processed against that particular transaction, refund date, merchant transaction id, bank transaction id, amount, refund status, refund transaction number, etc) c. Dispute adjustment details (if dispute adjustment processed against this particular transaction, e.g. chargeback, re-presentment, pre-arbitration, etc) 4. Search based on merchant transaction id or bank transaction id Acquiring Bank may provide settlement and payment advice on daily basis to the merchant for all transactions, including the disputed transactions. Acquiring bank may provide intimation to the merchant in case of chargeback, pre-arbitration and other disputes. 22. What is the reconciliation procedure between Bank and Merchant? Acquiring Bank may provide reconciliation file to the merchant, which contains details on the successful transactions. The file may contain following fields: 1. Bank reference number 2. Amount 3. Date of transaction 4. Merchant transaction ID Based on the above information, merchant shall reconcile with their system, and shall identify all transactions where they have received the credit, but have not fulfilled the service. Merchant shall prepare a file of such transactions to issue refund to customers. Page 42

43 23. What is the refund procedure between Bank and Merchant? IMPS Merchant Payments For Banks and Merchants Merchant shall create a file containing Refund to be made transactions to the Acquiring Bank. The file shall contain following fields: 1. Merchant transaction id 2. Amount 3. Bank reference number 4. Date of transaction Merchant should provide the file for refunds to acquiring bank on the next day of transaction. Acquiring Bank shall create file for refunds to be issued as per format acceptable in the Dispute Management System (DMS) for credit adjustment (refund). The file shall be uploaded to the DMS system. During the settlement cycle, refunds shall be processed. Acquiring Bank shall be debited and respective Issuing Bank shall be credited. The next day daily settlement report shall contain the details of these adjustments for Acquiring Bank and respective Issuing Banks. Issuing Bank shall provide credit to the respective customer based on the advice in the daily settlement report. Acquiring Bank may provide a file with transactions details of refunds made through the system. 24. What are the security guidelines for acquiring Bank and merchants? The Merchant needs to have necessary information security controls in place. Merchant should be educated that critical data processed in IMPS transactions are important and equivalent to card holder data in debit or credit card transactions or any other bank transactions. They need to follow industry best practices when it comes to protect business critical data OTP should not be displayed on the merchant application end user screen in clear text HTTPS is mandatory between Merchant and Acquirer Acquirer needs to have strong authentication process for the merchant which includes IP address, username and password over encrypted channel Issuer need to adhere strictly on time validation since OTP generation (1 hour for all banks) The OTP will be used only for one transaction (either successful or failure) OTP length should be minimum of 6 digits and should be adhered by Issuer as well as Acquirer Triple DES encryption needs to be in place OTP and other transaction details from merchant end will traverse on secure channel (HTTPS) OTP will be encrypted at all times using TDES during the transaction process OTP transmission from acquirer bank to NPCI to issuing bank can be encrypted/decrypted using HSM encryption or software encryption. Mobile number and MMID of customer, if shared with merchant, should be masked by default, by acquiring bank. In case of MMID, the last 3 digits can be masked. First 4 digits comprising of NBIN can be left unmasked for easy recognition of issuer bank. However, sharing of customer mobile number and MMID with select merchants is allowed as per the discretion of the acquirer bank. The liability of misuse of customer mobile number and MMID lies with the Acquiring Bank. Acquiring Bank should take necessary precautions for the security and confidentiality of the data and if required as per the discretion of the Acquiring Bank this can be shared only with select personnel of the merchant Page 43

44 OTP should not be stored on merchant application (Just like PCI DSS does not allow storage of authentication data like CVV, PIN, PIN Block, Mag Stripe data) Merchant or aggregator application must follow secure application development and deployment practices. Merchant or aggregator application must have undergone application security testing comprising of standards like OWASP Top 10, SANS Top 20, etc. 25. What are the guidelines for settlement of payments for electronic payment transactions involving intermediaries? The directions for opening and operation of accounts and settlement of payments for electronic payment transactions involving intermediaries are as per the RBI circular RBI / /231/DPSS.CO.PD.No.1102/ / dated November 24, The details are as below: The credit to merchant account by Acquiring Bank may or may not be instant, and Banks may decide to settle funds instantly or on offline basis, as per terms and conditions agreed with merchant. 26. What are the risk management guidelines at Acquiring Bank? Acquiring bank shall be responsible for the following: 1) Operate a merchant acquiring platform 2) Provide mobile based application to merchants for receiving funds from customers via mobile 3) Decline the transaction if payee is merchant, but person-to-person form is being used for making payment 4) Decline the transaction if payee is individual, but person-to-merchant form is being used for making payment 5) Decline the transaction if merchant is determined to be fraud and account is blocked 6) Establish and ensure transaction amount limit for the merchant per customer i.e. merchant should not be able to receive more than the transaction limit from a single customer on a per hour, per day, per month basis 7) Establish and ensure number of transactions limit for the merchant per customer i.e. merchant should not be able to receive more than the number of transactions specified per customer on a per hour, per day, per month basis 8) Fraud check (online and offline) 9) Alert SMS to be sent to the merchant with customer s and merchant s details 27. What are the risk management guidelines at Issuing Bank? Issuing bank shall be responsible for the following: 1) Transaction amount limit applicable to OTP as per mobile payment guidelines of RBI. Depending on the method of OTP generation, the transaction limit should be applicable. For e.g. if OTP is generated using Page 44

45 mobile banking application with M-PIN as second factor authentication, and end-to-end encryption, the limit can be unlimited (based on bank discretion). If it is generated through means which are not end-toend encrypted, transaction limit can be Rs 5,000/- per customer per day. OTP generation process needs to be two-factor authentication process, as applicable to the funds transfer via mobile operating guidelines. 2) Debit authorization for transaction through OTP. Issuing bank needs to validate customer mobile number, customer MMID, amount, and OTP 3) OTP time limit. Issuing bank needs to provide OTP with a certain validity period. If transaction is conducted beyond this validity period, issuing bank needs to decline transaction 4) Validation of number of transactions in a day 5) Validation of transaction limit for a mobile in a day 6) Separate form for customer initiated person-to-merchant payment transactions. Ensure population of correct values in the transaction request 7) Multiple requests from same handset within X time period with same reference / transaction number (this is to avoid multiple requests for the same transactions) 8) Adequacy of Collateral posted with NPCI for mobile remittances. 9) AML related validations for Funds Transfer transaction for the debit leg (online or offline) 10) Fraud Check (online or offline) 11) An Alert SMS for Debit leg is sent to customer with details of Sender and Beneficiary. 12) Population of correct values in verification requests. NPCI shall not validate or match any of the values sent in the verification requests with the original transaction. 28. What is the list of response codes in the IMPS system? IMPS Response Code Description ISO8583 Response Code Technical decline CU HOST (CBS) OFFLINE 08 Y IU ISSUER NODE OFFLINE 08 Y 08 PROCESSOR DOWN 91 Y Business decline M0 VER SUCCESSFUL ORG CRD MO Y TRXN DECLINED M1 INVALID BENEFICIARY M1 Y MOBILE NO/MAS M2 AMOUNT LIMIT EXCEEDED M2 Y FOR CUSTOMER M3 ACCOUNT BLOCKED/FROZEN M3 Y M4 NRE ACCOUNT M4 Y M5 ACCOUNT CLOSED M5 Y M6 LIMIT EXCEEDED FOR M6 Y MEMBER BANK 86 INVALID NBIN 92 Y 00 TRANSACTION APPROVED TRANSACTION APPROVED (during verification processing code will be 032) 00 Page 45

46 01 INVALID TRANSACTION 12 Y 05 INVALID TRANSACTION TYPE 12 Y 07 INVALID RESPONSE CODE 20 Y 39 UNABLE TO PROCESS 96 Y MA Merchant error MA Y MC MK ML MF Functionality not yet available for merchant through the payee bank Payee is an individual and not a merchant. Please use person-toperson form for making payment Payee is a merchant and not an individual. Please use person-tomerchant form for making payment Merchant system not available, please try again M9 Invalid / Incorrect OTP M9 Y MZ OTP expired MZ Y MH OTP transaction limit exceeded MH Y MG Functionality not yet available for MG Y customer through the issuing bank 24 Not sufficient funds 51 Y 30 Transaction not permitted to account holder MC MK ML MF 57 Y 18 Invalid message format 30 Y 28 No action taken 21 Y 50 Response received too late 68 Y 08 Issuer or switch is inoperative 91 Y 96 PIN block error 10 Y 14 Exceeds transaction amount limit 61 Y 19 Security violation 63 Y 20 Lost or stolen account 43 Y 01 Error 06 Y 31 Suspected malfunction 22 Y 02 Do not honor 05 Y 38 Duplicate transaction 94 Y 20 Suspected fraud 34 Y 01 Cutoff is in process 90 Y 27 Customer cancellation 17 Y 01 Reconcile error 95 Y 15 Exceeds transaction frequency limit 01 Requested function not supported 65 Y 40 Y Y Y Y Y Page 46

47 06 Invalid amount field 13 Y 29. What are the reconciliation files and reports that IMPS provides to the member banks? The following reconciliation files and reports are available: 1. Acquirer raw data file for P2M transactions - This contains the transactions where BANK is acquiring the transactions for P2M acting as remitter in case of PUSH transaction and acting as beneficiary in case of PULL transaction 2. Issuer raw data file for P2M transactions - This contains the transactions where BANK is receiving the transactions for P2M acting as beneficiary in case of PUSH transaction and acting as remitter in case of PULL transaction 3. Beneficiary settlement report for all transactions - This contains all transactions where BANK is acting as beneficiary. 4. Remitter settlement report for all transactions Remitter Merchant Settlement Report - This contains all transactions where BANK is acting as remitter. 5. Verification report for P2M transactions - This report contains all verification transactions for P2M transactions 6. Acquirer reversal This contains all reversal advices initiated from acquiring bank which are dropped at NPCI switch 7. Issuer reversal This contains all reversal advices to be received by issuing bank which are dropped at NPCI switch Page 47