 Introduction: This process note serves the purpose to explain the process flow for Cards / QR transaction reconciliation and settlement for the internal team’s reference and review. A. System components and process flow of Cards / QR transaction reconciliation & settlement  TID Master – There should be one TID Master that should capture the details of each TID and associated QR tags once it’s created in our system after every new Merchant onboarding. This TID Master will have all the onboarding fields including - MID, Store ID, TID, QRID, Merchant Name (Legal & DBA), Merchant Bank Name, Merchant Bank A/c. Number, IBAN Number, Virtual IBAN Number, All enabled schemes, Different card scheme/Product type MDR Rates (Sell Rates) for Merchant, MCC, MCC Description, Registered Mobile Number, Registered E-Mail ID including onboarding source, source ID, onboarding date etc. This will also have last transaction date and last transaction amount for tracking activations at TID level. We should also add few additional blank fields to this master file for our future use.  Transaction Dump – There should be a transaction record for each transaction in Transaction Dump in our DB/ Middleware after every card/QR transaction flowing from any TID along with the status & type of transaction e.g., MID, Store ID, TID, QR tag, Merchant Name, Trxn date, Trxn Time, Trxn Amount, Trxn_ID (Internal), Scheme Name, DR_CR, Card Product Type, MCC, Transaction Type, RRN, Auth Number, Transaction Status (Success & Fail), Transaction Type (Sale, Void, etc.), Reversal Status (Y/N), Settled, Unsettled, Scheme Type, Invoice Number, STAN, Card No. (PAN), Card Holder Name, Customer Mobile Number, Country. These transaction records will also have the unique RRN (Retrieval Reference Number) / Transaction Reference Number for QR for each transaction which acts as common related reference for all the parties involved in processing and approving the transactions including Acquirer, Switch, Card Schemes and Issuer. We should also add few additional blank fields to this dump file for our future use. Sample file format is attached for reference with the Name “Transaction Dump”. This file will also have one blank date field with the name “Switch Settled Dump Date / QR Schemes Settled Dump Date”.  Switch Settled Dump / QR Schemes Settled Dump (Base II files) – There is a daily Switch Settled Dump received from cards switch (YSP) to be shared with Mercury Payments on SFTP/ email location (placed at Midnight or early morning). Similarly, there is a daily QR Schemes Settled Dump received from respective QR Schemes to be shared with Mercury Payments Middleware/ YSP. These dumps include all the settled transactions of the previous day including the unique RRN for every transaction. File format is attached for reference with the name Switch Settled Dump and QR Schemes Settled Dump.  Reconciliation Engine – There should be a Reconciliation Engine in Mercury Payments Middleware to perform the following tasks (Completed by 6:00 am 365 Days): 1. Consume the daily Switch Settled Dump / QR Schemes Settled Dump received from the cards switch (YSP)/ QR Schemes parked on our SFTP/ email into our / Middleware Reconciliation Engine tool. 2. The records of daily Switch Settled Dump / QR Schemes Settled Dump will be reconciled with our transaction records in our Transaction Dump up to last 30 days window. The reconciliation will happen on a 1:1 match basis by finding every individual transaction RRN (RRN + TID + Trxn Amount + Trxn Date + Auth) of daily Switch Settled Dump / QR Schemes Settled Dump in our Transaction Dump. (If in case any exception record is there in the system, System should create a report for the same). 3. Collect scheme files from YSP - SFTP and process in Reconciliation engine, reconcile individual record with the transaction dump and update settlement date, Interchange fees, etc. against each record. The status of this field should always be found blank and to be replaced with the date of current Scheme files from YSP from which we are doing the reconciliation. In case this field is not found blank and there is already a date, it means the transaction has already been reconciled with the Scheme file/ QR Scheme file in the past recorded date and represented again. However, this scenario will not be there but in case we find any, all such transactions should be highlighted in an exception report for the Finance Team. 4. Refund Transactions – In case there is any Refund transactions in Switch Settled Dump / QR Schemes Settled Dump, the status of the corresponding transaction should be updated in Transaction Dump with the refund status (Y) and refund date. (Partial Refund// Verified Refund) 5. After reconciliation the following exception reports/cumulative MIS should be available on the tool (interface) for the Finance & Tech Teams and/or through e-mail notifications. 5.1 - The transactions present in Switch Settled Dump / QR Schemes Settled Dump and not found in Transaction Dump - all such daily records should be highlighted in the exception reports of that particular day and should also be captured in cumulative MIS as outstanding entries. 5.2 - Outstanding entries in our Transaction Dump - All the transaction records where the “Switch Settled Dump Date / QR Schemes Settled Dump Date” field is still blank in our Transaction Dump (excluding the Current Date transactions and Void transactions) should be highlighted in the exception reports of that particular day and should also be captured in cumulative MIS as outstanding entries. 5.3 - If we found any RRN match for any Void transaction as per our Transaction Dump all such transactions should be highlighted in the exception reports of that particular day and should also be captured in cumulative MIS as outstanding entries. 5.4 - Duplicate Transaction – Any transaction which is already received in Switch Settled Dump / QR Schemes Settled Dump in the past and represented again in any current Switch Settled Dump / QR Schemes Settled Dump, all such transactions should be highlighted in the exception reports of that particular day and should also be captured in cumulative MIS as duplicate entries. (In Reference to point 3) *Note - All above exceptional transaction payment should be marked as Hold and there should be an interface for the Finance Team and / or through email notification to Review these transactions.  Settlement Engine - There should be a Settlement engine in Mercury Payments Middleware to perform the following tasks (Max. by 7:00 am 365 days): 1. This tool will also consume the daily Switch Settled Dump / QR Schemes Settled Dump and will process the payment batch of that date by: a) Mapping the Transaction Monitoring Rules on the Transaction Dump/ Settled Dump (as given in the Transaction Monitoring Process document), getting additional corresponding information and values from TID Master. b) checking the outstanding chargeback recovery against the Merchants (MIDs) appearing in the Switch Settled Dump / QR Schemes Settled Dump. c) checking the collection towards Merchant Lending/ LACR (Loan against card receivables) against the Merchants (MIDs) appearing in the Switch Settled Dump / QR Schemes Settled Dump. (This will come in phase 2 and process notes will be shared later). 2. After mapping the Risk Monitoring rules on Transaction Dump/ Settled Dump, the system will mark “Risk Hold” against all the transactions appearing in the Risk Monitoring along with the corresponding Risk Rule. (As given in the Transaction Monitoring Process document). These rules will be implemented at middleware (or at YSP as per feasibility). 3. Will be requiring one page on interface where we can do single or bulk adjustments at merchant level with debit or credit to the merchant by various adjustments such as the Debit adjustment, credit adjustment, other fees, Chargeback recoveries, LACR etc. selecting from drop down with a memo box for writing description against each selected item. Fields required a. Merchant id- on selection display merchant name b. Debit/credit c. Amount d. Drop down- Chargeback recovery, All other fees as per MPR, Debit/credit Adjustments as per MPR along with description. • Bulk Upload File Format to be decided. 4. In this payment batch processing, the tool will fetch the corresponding MDR rates, transaction fees and the Beneficiary Bank Details from the TID Master and do the calculation of MDR + Transaction Fee and VAT Amount and Net Payable Amount for every transaction received in the Switch Settled Dump / QR Schemes Settled Dump. 5. While processing this payment batch, the tool will also check for any Outstanding Chargeback against the merchants (MIDs) appearing in the Switch Settled Dump / QR Schemes Settled Dump and in case there is any merchant where Chargeback Recovery is due, or any other dues, the tool should adjust the recovery. 6. After above steps, the final Settlement MIS (Payment Output MIS) against that day Switch Settled Dump / QR Schemes Settled Dump file should be generated by system for the Finance Team review and actions. This Settlement MIS (Payment Output MIS) should be available on the tool (interface) for the Finance Team along with user rights. This file should have the consolidated information and fields including - Merchant Name, MID, Transaction ID/Auth code, Beneficiary Account Number, Transaction Date, Bank Name, IBAN, Gross Transaction Amount, Total Aggregator Commission Amount Payable, VAT, AR Recovery, Total Amount Payable to Merchant A/c, Risk Status, Terminal ID (TID)/ QR tags, RRN, Etc. This Settlement MIS file also have the corresponding interchange rates to calculate our cost and profitability at the transaction level (In case the actual interchange for the transaction is not available with YSP, Mercury will share the master Table of Interchange Fee of all card product types with YSP to maintain at their end and fetch the corresponding interchange fee from this table. Sample file format is attached for reference with the Name “Settlement MIS”. This date wise Settlement MIS (Payment Output MIS) should also be stored in our DB for records and future reference. 7. The Finance Team should have the following rights to perform the tasks below (Max. by 8:00 am): a) The Finance Team will review and should have the option to Approve or Discard the current Settlement MIS (Payment Output MIS) on the interface. (There should be a 2-level authorization in the Finance Team for approving the file). b) In case the finance team found any observation or would like to discard the file for any reason, will raise their query to the concerned team offline. c) The finance team should also be able to Download this daily Settlement MIS (Payment Output MIS) from the interface for their manual repository. 8. After Finance Team approval on the interface, the system should generate the Aggregated Settlement MIS (Final encrypted Payout File) at the MID level and will finally send the payment instructions to Mercury Settlement Bank Account in the agreed bank format through API / SFTP for merchant settlements. Sample Payout File attached. 9. At this stage, system should trigger an Auto MPR to all the respective merchants on their given email ids / merchant portal. Sample MPR file format attached. 10. After receiving these instructions and files from Mercury Payments through an API / SFTP, Mercury’s Bank will process these payments in respective Merchant’s Accounts as per the file. This payout file should be an encrypted file. 11. After these payments are processed, Mercury’s Bank through an API / SFTP will send the confirmation back to Mercury Payments along with the respective Transfer Reference Number with date and time in response for each merchant payment transfer. 12. After receiving the payment confirmation from Mercury’s Bank, the transaction status will be updated in our Transaction Dump with Transaction Reference Number and system should trigger Auto Settlement Advice to all the respective merchants on their given email ids / merchant portal from Mercury email domain. Sample Settlement Advice format attached. 13. At this stage, the system will also trigger auto VAT invoices and VAT MIS to all the respective Merchants from Mercury email domain. Sample VAT invoice format & VAT MIS format attached. 14. Settlement for Risk & chargeback Released transactions: There should be an interface for the Risk Team with User Rights for their review and actions towards outstanding risk and chargeback hold transactions. The Risk Team should have the right to release transactions as per their process and decision. All such transactions released by Risk team daily (or as and when) will be added on the next day in Settlement MIS (Payment Output MIS) and steps thereafter will remain the same as regular settlement mentioned above. 15. Settlement for transactions highlighted in the exception reports (In reference to point no. 5) – For all transactions appearing in the Exception Reports, there should be an interface for the Finance Team to review and release these transactions. All such Released transactions (as and when by the Finance Team) will be added in the next day Settlement MIS (Payment Output MIS) and steps thereafter will remain the same as regular settlement mentioned above. 16. Settlement for Payment Rejections cases: For all payments rejections cases, where merchant payment transfer failed due to any reason e.g., invalid beneficiary account number, account closer etc., an exception report to be sent to Finance Team and Operations Team through an email for their further action. As and when this rectification is done, there should be a separate option for Finance Team to re-initiate payout for this payment rejected cases and an independent payment batch should be processed for the same by the system. Sample File Formats: Formats of all the files mentioned in the document are attached for reference: (i) Draft Transaction Dump (Mercury Payments DB) - Attached (ii) Draft Settlement MIS (Mercury Payments Payment Output MIS) - Attached (iii) Draft Auto MPR Format (Mercury Payments) - Attached (iv) Auto Settlement Advice (Mercury Payments) - Attached (v) Merchant Payout File (Final Payout) - Attached (vi) VAT Invoice Format - Attached (vii) VAT MIS Format- Attached (viii) BIN Table – to be shared (ix) Interchange Table (Approx. values) – to be shared (x) Switch Transaction Dump - to be shared by YSP (xi) Scheme Transaction Dump (Base II files) - to be shared by YSP