1. Bank statements, at present, lack uniformity and do not necessarily depict or describe properly the transactions recorded therein unless supporting documentation viz., pay-in-slips (Deposits) or noting’s in cheque books (withdrawals) are referred to.
2. This is on account of Core Banking Solution (CBS) of different banks capturing information from different field tags of the transaction voucher created in the CBS of the bank.
3. The KYC data (principally Name of the Account Holder) of the customer is available in electronic format – in the CBS – data servers of the respective bank branches. Further, it is also shared in most cases for their inter-bank transactions relating to their customers.
4. Bank statements will be intelligible (meaningful and easy to understand) – if they capture and record – the name of the remitter or beneficiary – as the case may be.
5. This can be achieved by modification / updation in the Core Banking Solution of the Banks – to capture the appropriate field tag – principally the name of the remitter or beneficiary – in case of transfer of funds.
6. The project is likely to add VISIBILITY to the Audit Trail inherent in banking transactions which will assist in prevention of money laundering and audit and investigation of cases of tax evasion as well as considerable savings in terms of man-hours devoted in reconciling bank statements.
7. The proposal is explained in depth and particularly covering all aspects of the bank statements and matters incidental thereto in this draft discussion paper. The draft may be required to be modified based on inputs / feedback received from all stakeholders.
This Discussion Paper envisages
TO make Bank Statements INTELLIGIBLE (MEANINGFUL and UNDERSTANDABLE) without reference to supporting documents and thereby add VISIBILITY to the AUDIT TRAIL inherent therein.
BY TRANSFER & CAPTURING OF THE KYC DATA – NAME OF THE ACCOUNT HOLDER – ELECTRONICALLY along with the existing process of recording banking transactions
AND matters incidental thereto.
B. INTRODUCTION – THE PRESENT SCENARIO
Banks play a vital role in our everyday life – be it an individual, a small trader, an SME or a large corporate house – everyone receives and pays – money through the services of Banks.
Consequently, bank statements –in pass book or by way of account statements in paper mode or any electronic mode need to depict & describe properly the transactions entered into by the customer.
Further, the August 2009 issue of The Banking Codes and Standards Board of India – Clause 8.1.1 para Statements and sub-clause (e) mandated Banks to – “We will ensure that entries in your pass book / statements are brief and intelligible.”
In a significant effort in this direction, the Reserve Bank of India vide Circular RBI/2008/09/426 dated April 8, 2009 advised banks to furnish the name of the remitter and beneficiary in the pass book / account statement to the customer , however, only with respect to RTGS/ NEFT transactions.
Invariably, the present state of bank statements is rather dismal with no uniformity on the information provided to customers in these account statements / pass books and entries therein don’t make sense without reference to supporting documents viz., Pay-in Slips (for Deposits) and Noting’s in Cheque books (for Withdrawals). This is on account of the Core Banking Solution of different banks capturing information from different field tags of the Transaction Voucher created by the Bank (System).
This leads to reconciliation issues and the Bank Statements are not meaningful unless and until the supporting documentation is referred to viz., Pay-in Slips (Deposits) and Noting’s in Cheque books (Withdrawals) – which are not readily available to all users and at all times or may have not been properly maintained.
Further, with the advent of multi-branch banking on account of CBS (Core Banking Solution) conversion as well as electronic banking services (Net banking, Mobile Banking, Electronic Credit Service) – even these supporting documents are now becoming extinct. For eg., The payer can directly deposit the cheque at a remote branch without mailing the cheque to the payee.
C. THE PROPOSED SCHEME
The Bank Statements will be more intelligible, meaningful and understandable when the narration as recorded in the said Statement properly depicts & describes the transaction i.e.,
1). In case of Clearing / Transfer of Funds by Cheques (Domestic – Clearing or Transfer), RTGS or NEFT* and ECS Transactions
a). A Bank Customer receiving a payment (Credit) is provided with the name of the remitter in his account statement / pass book.
b). A Bank Customer making a payment (Debit) is provided with the name of the beneficiary in his account statement / pass book.
* Provision already made in case of RTGS / NEFT by virtue of RBI Circular RBI/2008/09/426 dated April 8, 2009
** In case of MICR clearing – at present, Account Name is not shared, though Account Number is shared.
*** In case of International Clearing / Transfer of Funds – not covered in this discussion paper – further inputs are required.
2). In case of a demand draft / pay order or a like instrument
a). A Bank customer making a payment (Debit) by a Demand Draft / Pay Order or like instrument is provided with the name of the beneficiary (in whose name the DD is issued by the Bank) and
b). Subject, to feasibility, a bank customer receiving a payment (Credit) by a Demand Draft / Pay Order or like instrument is provided with the name of the remitter (who has sought for the issue of the DD).
3). In case of Government Business module (GBM)
a) Direct Tax payments – the narration is “Tax – CBDT” along with the Challan Identification Number^ (BSR Code of Branch + Date of Payment + Challan No.) is given. [OLTAS]
b) CBEC – Customs & Excise payments – the narration is “Tax – CBEC” along with the Challan Identification Number^ (BSR Code of Branch + Date of Payment + Challan No.) is given. [EASIEST]
c) Tax Payments to State Government – the narration is “Tax –“ & [State Name] & [tax Type] along with the appropriate equivalent of Challan No.
d) Other business such as deposit / withdrawal from PPF, Senior Citizen Savings Scheme 2004 (SCSS) and pension payments (transfer entries to savings / current account)
i. PPF Deposit / Withdrawal & “Account No.” of the PPF Account
ii. SCSS Deposit / Withdrawal & “Account No.” of the SCSS Account
iii. Pension payments – Scheme under which pension is paid or abbreviation thereof with suffix or prefix (as appropriate) – “pension”.
^ CIN or Challan Identification Number – for CBDT & CBEC – tax payments allows – the user to gather all relevant information regarding payment from the NSDL website – vis PAN / TAN or assessee code, type of payment and break-up of payment – tax, surcharge and cess, interest, penalty & other payments in addition to date of payment and challan no. – everything that is necessary to claim credit of the Tax paid
4). Further, in case of internal transactions –Term Deposit & Term Loan Accounts – Creation, Interest and Maturity
a) Principal is debited / credited separately from interest&&
b) Interest is broken up & credited separately, where it relates to different accounting years (financial year) separately. &&
c) Tax Deducted at Source is debited separately & not netted up with Interest & subject to feasibility, accounting year is also mentioned.
&& Rationale –
- Ease of Accounting – both at the end of the Bank & the Customer – if following accrual system of accounting.
- At present separate certificates are required to be issued for income tax purposes – to separately depict interest and principal – for claim of housing loan deduction u/s 80C and 24(1)(b) of the Income Tax Act, 1961.
- Ease of claim of credit of Income Tax Deducted at Source which is at present hit by Explanation to Section 194A(1) (requirement of TDS on provision for interest) – though a Contrary view expressed in IDBI v. ITO (2006) 10 SOT 197 (Mum.) and Section 199 read with 37BA(3) (TDS claim only in the year in which it forms part of income) of the Income Tax Act, 1961.
5). Other transactions – Bank Charges & Savings Bank Interest
a) Bank Charges (inclusive of all taxes – Service Tax & Education Cess are shown separately at present) & narrative for type – Account Maintenance, Cheques Bounce (Own or Third Party) or Failure to maintain Minimum Account Balance, etc.
b) Savings bank interest is broken up & credited separately, where it relates to different accounting years (financial year) separately.
In this regard it pertinent to note that the information – Account No., Name & KYC data of the Account Holders is available in the Core Banking System of banks & is also shared in most cases for the inter-bank transactions relating to the customers. Therefore, this scheme can be implemented by CAPTURING OF THE KYC DATA – NAME OF THE ACCOUNT HOLDER – ELECTRONICALLY along with the existing process of recording banking transactions – through software programming modifications and without manual data entry by bank staff.
1. Regulatory Framework by the Reserve Bank of India
For implementation of the proposed scheme, the Reserve Bank of India will have to issue an appropriate Circular since it involves modification (addition) to data shared in the case of Cheque Truncation Service.
2. Transactions Internal to the Bank
Except for clearing transactions, all other transactions are internal to the Bank or already involve the sharing of name of remitter / beneficiary (such as ECS / RTGS / NEFT) and hence can be implemented without reference to RBI or with other banks.
E. ISSUES IN IMPLEMENTATION
1. INTEGRATION WITH
a. RTGS / NEFT (REAL TIME GROSS SETTLMENT / NATIONAL ELECTRONIC FUND TRANSFER)
Provision already made by virtue of RBI Circular RBI/2008/09/426 dated April 8, 2009
b. CHEQUE TRUNCATION SERVICE (CTS)
Cheque Truncation Service (CTS) – is being used principally for inter-bank clearing of cheques.
Current Process –
- The presenting bank (or its branch) captures the data (on the MICR band) and the images of a cheque using their Capture System (comprising of a scanner, core banking or other application) which is internal to them, and have to meet the specifications and standards prescribed for data and images.
- The collecting bank (presenting bank) sends the data and captured images duly signed and encrypted to the central processing location (Clearing House) for onward transmission to the paying bank (destination or drawee bank).
- The Clearing House processes the data, arrives at the settlement figure.
- The Clearing House routes the images and requisite data to the drawee banks. (Presentation Clearing)
- The drawee uses the images and data received from the Clearing House for payment processing and the drawee CHIs also generates the return file for unpaid instruments, if any.
- The return file / data sent by the drawee banks are processed by the Clearing House in the return clearing session in the same way as presentation clearing and return data is provided to the presenting banks for processing.
- The clearing cycle is treated as complete once the presentation clearing and the associated return clearing sessions are successfully processed.
Proposed Modifications in Existing Process – At present, the KYC data – Account No. & Name of the Account Holder is NOT shared with the clearing house and onward. For implementation of the proposed scheme, it is quintessential to share the KYC data – Account No. & Name of the Account Holder with the Clearing House – by the presenting bank & the drawee bank.
The following modifications will have to be made to the existing process:-
Process 2 –> Data and image sent by the presenting bank to the Clearing House to include the KYC Data of the beneficiary (Account No. & Name).
(The data is already linked to the Cheque but is not shared)
Process 5 –> Processing by Drawee bank, in addition to return file for unpaid instruments, if any, a return file for paid instruments is also generated and includes the KYC Data of the remitter (Account No. & Name) and transmitted onward to the Clearing House and then to the presenting bank.
(The data is already linked to the Cheque but is not shared)
The Account No. & Name of the remitter / beneficiary so transferred are captured by the Core Banking Software for the purpose of the narration in the Bank Statements.
c. ELECTRONIC CLEARING SERVICE (ECS)
i. According to ECS (Credit) Procedural Guidelines, 2011, the following information is already transmitted : in Credit Records – Field 6 – Destination Account Holder’s Name and in Credit Contra Records – Field 3 – User Name : to be captured as the Narration.
ii. Similarly, according to ECS (Debit) Procedural Guidelines, 2011 the following information is already transmitted : in Debit Contra Records – Field 3 – User Name and in Debit Records – Field 6 – Destination Account Holder’s Name : to be captured as the Narration.
Since the data is already being transmitted, with changes in computer programming to capture the appropriate field for the purpose of narration – can be implemented very easily.
2. IMPLEMENTATION WITHIN THE BANK
In case of Transfer entries – Cheque / issued of DD or PO, Government Business Module – the transactions are internal to the bank and can be implemented without the sharing of information from other banks / clearing houses.
3. SECURITY, INTEGRITY AND CONFIDENTIALITY OF DATA
The Security, Integrity and Confidentiality of Data to be transmitted over the Clearing House Network can be assured by implementation of Public Key Infrastructure – already in use along with the Cheque Truncation Service (CTS).
4. INFORMATION TECHNOLOGY COSTS TO BANKS / CLEARING HOUSES
The Banks / Clearing Houses will have to bear information technology cost for the update of the software to make these changes. The discussion paper does not envisage any significant additional costs of hardware except to the extent of storage of additional data to be captured / transmitted.
F. CHANGE IN THE PROCESS FOR CUSTOMERS
The discussion paper does not envisage any change in the existing process for customers / account holders except to the extent they get “intelligible” bank statements.
G. CHANGE IN THE PROCESS FOR BANKS
1. STAFF / PERSONNEL TRAINING
The discussion paper does not envisage any change in the existing process of data entry by the Bank personnel or any additional burden of data entry to the Bank personnel because the change is automated.
The discussion paper does not envisage any additional requirement of Information Technology Hardware – except to the extent of any additional cost of storage of data.
The discussion envisages implementation of the proposed scheme with changes / updation in the Software – Core Banking Solution (CBS) of the Banks and Clearing Houses.
The Banking System provides an Audit Trail but hitherto this Audit Trail is not wholly VISIBLE until the supporting documentation such as Pay-in Slips (Deposits) or Noting’s in Cheques (Withdrawals) are referred to. The Discussion paper envisages making this Audit Trail CLEARLY VISIBLE without the need to refer supporting documentation.
1. TO CUSTOMERS
a. Ease of tracking of funds – receipts and payments – without need to refer to supporting documentation.
b. Ease of accounting
2. TO BANKERS
a. Compliance with the Banking Code and Standards – August 2009
b. Better service to the Customers
3. TO REGULATORY AUTHORITIES
a. Since the Audit Trail will be clearly visible in the Bank Statements – Regulatory Authorities can keep a track of funds as well as monitor the end use of these funds. It will assist in the Prevention of Money Laundering and Investigation in Tax Evasion cases.
I REFERENCES [External Links]
Electronic Clearing Service ECS (Debit) Procedural Guidelines on the Website of RBI
BSCBI Banking Codes and Standards Board of India
CH Clearing House
CHI Clearing House Interface (CHI) – Software used by Clearing Houses (CH)
CTS Cheque Truncation Service / Scheme
ECS Electronic Clearing Service
FAQ Frequently Asked Questions
MICR Magnetic Ink Character Recognition
NEFT National Electronic Fund Transfer
RBI Reserve Bank of India
RTGS Real Time Gross Settlement