Last date of submission of bid is extended up to S.No Reference Reference Query Replies

Size: px

Start display at page:

Download "Last date of submission of bid is extended up to S.No Reference Reference Query Replies"

Blake Lawson
5 years ago
Views:

1 Replies to queries of Prospective bidders of Request for Proposal (RFP) for Procurement of Software for Implementation of Indian Accounting Standards (Ind AS) Last date of submission of bid is extended up to S.No Reference Reference Query Replies 1 RFP Details General Please extend the last date of submission of 2 weeks Last date of submission of bid is extended till Annexure E The Application should support multi currency accounting. The application Does the bank want to implement a new General should be configured to translate the balances into INR or any other desired Ledger solution as part of this implementation? In currency or vice versa this case, will the bank discontinue using existing General Ledger of the bank? The Bank does not want to discontinue using existing General Ledger of the Bank 3 Annexure E(A), point 5, 6, 7 Processing fees or any other loan origination fees collected and incremental cost incurred at the time of loan booking should be parked in Unamortized fees sub GL Other charges like documentation charges, Inspection fees, etc which are collected upfront at the time of origination of loan need to be captured separately in a separate GL. Upfront Fees related to loan accounts needs to be tagged to respective loan account Bifurcation/mapping of all charges/fees (Such as but not limited to Processing Fee, Mortgage Fee, Doc charges, etc.) received from borrowers into One-time charges & recurring charges Please clarify - is this not being done already when transactions are accounted for in CBS or moved into the current General Ledger where there is Chart of Accounts already defined and implemented? Does the bank wish to re-do existing accounting processes with this project? Currently charges are being booked under only two heads viz. Processing charges and Other charges. There is no bifurcation of one-time charges and recurring charges. Modification will be required to existing accounting processes 4 Annexure E(A), point 8 Processing fees reversed subsequently due to waiver or concessions given should also be factored in account wise This is typically done in core banking systems where account level transactions are maintained. The reversal effect only flows through into the General Ledger for financial reporting. Please explain what is expected in this required? Reversal is done in core banking system only. We mean details of both collection and reversal are to be captured. We can given effect of reversal at back date in Oracle GL system 5 Annexure E(A), point 9, 10, 11, 16, 17, 18, 19, 20, 21, 22, 23, 45, 46, Solution should have the functionality to generate cash flows (Cash flow engine) based on the repayment schedule or inputs fed in the system / available in different source systems The Cash Flow Engine shall be able to create expected and contractual Cash Flow from data characteristics of financial instruments according to different types of contracts The solution should provide the capability to alter cash flows through parameters (e.g. pre-payment) that can be set as part of configurations. Audit trail to be maintained of these configurations and changes. The bank has an existing cash flow engine for ALM which provides all of these capabilities. Does the bank want to create / implement a new cash flow engine for pure INDAS purposes? This may be sub optimal and create reconciliation issues other than replicating effort and duplicating data leading to increased costs of implementation and maintenance for the bank We understand from the ALM team that though the account wise cashflows are generated and bucketed to prepare the SLS and IRS reports, account wise cashflows are not getting stored in backend tables for extraction and use elsewhere. Only the bucketed data used for reports is available.

2 6 Annexure E(A), point 24 The solution should have a function to calculate the fair value of a financial instrument using cashflow discounting The bank has an existing cashflow engine that calculates fair value at account level. Need a clarification that the bank wishes to create a duplicate / parallel fair value calculation capability purely for INDAS. Yes 7 Annexure E(A), point 48 > Will the bank provide methodology for calculation of this fee? With regard to credit / debit card reward points, System should be capable > What is the frequency at which this fee is to be of computing the amount of interchange fees to be deferred as System calculated? needs to defer the interchange fees earned into fees allocated for issue of > Will the calculated fee amount be passed as an reward points and the balance fee will have to be recognized on completion accounting entry into GL post which adjustments of the transaction i.e. upfront. The fee allocated for issue of reward points have to be made for deferral? to be recognized as revenue as and when the customer redeems the reward > Will the bank be able to provide logic / points/ when the reward points lapses methodology and supporting data for computing amount of deferral at transaction / account level? Please be guided by RFP 8 Annexure E(A), point 59, 60, 117 To construct/generate account level residual cash flows based on actual repayments in loan accounts and arrive at IND AS balances (future remaining cash flows discounted at EIR) to be used for ECL computation The bank has an existing cash flow engine. Is this requirement intended to recreate cashflows for INDAS? This will increase the cost and time for implementation to the bank in addition to creating duplicate data repositories and multiple cashflow results which will be very hard to reconcile Please refer respnse serial number 5 of this corrigendum 9 Annexure E(A), point 86 To compute credit risk RWA as per Ind AS guidelines. Does this mean the bank also want to implement Basel Capital Calculation as a part of this project? Please confirm Banks expects capabilities in line with RBI requirement to calculate RWA based on ECL numbers. 10 Annexure E(A), point 149 The ECL engine should support Distributed in-memory processing for large volume of data ECL is a batch calculation process typically required to be done end of month when entries need to be passed into the GL. Please explain how in memory requirements will be used? Please be guided by RFP 11 Annexure E(A), point 159 Mandatory fields should be added to Security master for such classification, so that securities can be tagged appropriately at the time of purchase This can happen 'on time of purchase' only in the system where transaction originates, in this case we assume it is the Treasury. Can the bank clarify what is expected in the downstream INDAS system where data will sourced from the treasury system? Data sourcing will be from Treasury system. Based on the security classfication IND AS system should capture data from Treasury system

3 12 Annexure E(A), point 164, 168 System to map chart of accounts of Interest Accrued with securities where the classification is amortised cost Requirement unclear. Interest accrual happens in the core systems where the income amount will mapped if the instrument is amortized cost. Please explain what is expected from INDAS system? The interest accrual will happen in core systems, but the IND AS system should be able to fetch the data on interest accrual for those securities marked under amortised cost. 13 Annexure E(A), point 165 There should be adequate safeguards in the system to notify about restrictions on sale/transfer of securities held under amortised cost category Sale / transfer of instruments can happen only in the originating / transaction processing system and not in accounting / financial reporting system. Please explain what is expected from the INDAS system which will only do the calculations wrt INDAS on ECL, EIR and generate financial reporting The IND AS system should warn the user if there is change in the securities identifed under Amortisated cost. 14 Annexure E(A), point 166 Treasury module in the solution to be developed in a manner, which segregates the investment on the parameters of market (primary / secondary). Is the bank intending to replace / implement a new treasury system for INDAS? The information on primary /secondary market pruchases is available in Treasury system. The IND AS system should capture this information from Treasury system. The provision to record the same should be availbale in the system. 15 Annexure E(A), point 170, 171, 172, System should facilitate automatic fair value calculation of securities Calculating the MTM gain or loss on the securities. Provision to capture MTM portfolio wise (as classified under IND AS) and calculate the resulting unrealised gain / losses. Does the existing system of treasury calculate fair value and gain / loss on securities? The existing Treasury system and proposed new Treasury system calcualte fair value and gain and loss on securities based on the feeds from market information portals and manual data feed.

4 16 Annexure E(A), point 173, 179, 180, 181, 182, 188, 192, 194 Solution should enable calculation of fair value using level 1 input, level 2 input and level 3 input and generate report showing the fair value of the financial assets. Solution should have flexibility to add such information at inception level or thereafter. System should calculate the Purchase price of security System should run a schedule to calculate cumulative face value of the security taking into consideration all the transactions prior to reporting date. All sell transactions will be reduced from Face value using First in first out method (FIFO) Accordingly, Closing Face value of security to be computed System should calculate the New Price to compute the amortized cost of the securities which will be reported in the balance sheet. Amortized cost will be product of New Price and quantity of the security. Quantity of security should be computed using Closing Face value of the security as per FIFO method. New Price will be calculated using Solution should able to generate the portfolio transfer / sale / purchase report for the behavioural study from the inception / first time adoption Solution should recognize derivatives at fair value initially and subsequently as per Ind AS 109 System should provide MTM sensitivity analysis to comply with disclosure requirements of Ind AS 107 Reconfirming that the bank's existing treasury does not do level 1, 2 and 3 fair value calculation? Also does the treasury not do all the other requirements listed here in the query - typically it is done in treasury systems. Please clarify Presently, the Bank is following weighted average accounting for investment activity. Movement of security using FIFO and new price after amortisation is not supported by the system. The IND AS system should calculate with raw data available in the Treasury data from the security ledger. Same for all derivative products. 17 Annexure E(A), point Annexure E(A), point 197, 198 Solution should be able to link charges at the time of borrowings to each borrowing and recognise the same as per EIR instead of upfront charging to P & L. Solution should generate detailed report individually as well as collectively for CVA/ DVA calculation wherever applicable Solution should compute CVA / DVA based on positive MTM and negative MTM respectively and separate GL required for adjustment related to CVA and DVA. This is typically done on origination in the transaction processing system. Please explain what is expected? If this linkage is not being done, will the bank be able to provide transaction and account data to build the same? Does the existing Treasury / Market Risk / Basel solution of the bank not compute CVA and DVA? Reconfirming that the bank needs technology to enable this? The amortisation of expenses should be calculated in the IND AS system. The expenditurer is accounted upfront in Treasury system which are to be amortised over the period and calculation of EIR The present Treasury system does not calculate CVA/DVA and IND AS system should calculate it. 19 Annexure E(A), point 248 The tool should provide pre-build functionalities for the following: Financial Transformations Mathematical Transformations Statistical Computations These are typically expected from solutions that support data consolidation, analysis and reporting. INDAS being a calculation and financial reporting need, can the bank clarify where these transformations will be utilized? We need to generate all financial information from the system and these prebuilt functionalities will be required

5 20 Annexure E(A), point Financial reporting Statutory reporting to RBI such as The reports listed in this section are typically delivered through a DW. Please explain the expectation from INDAS standpoint and contribution required for these reports Statutory Reports prescribed need to be generated from the system

Islamic Derivatives Oracle FLEXCUBE Universal Banking Release [May] [2011]

Islamic Derivatives Oracle FLEXCUBE Universal Banking Release 11.3.0 [May] [2011] Islamic Derivatives Table of Contents 1. ABOUT THIS MANUAL... 1-1 1.1 INTRODUCTION... 1-1 1.2 AUDIENCE... 1-1 1.3 ACRONYMS