November 2014

BACKGROUND PAPER

ON

AUTOMATED DATA FLOW (ADF) PROJECT IMPLEMENTATION

IN COMPLAINCE OF RESERVE BANK OF INDIA (RBI) REQUIREMENTS

Prepared by:

Team @ XBRL. Our team members below would be happy to discuss the subject and can be reached

at:

Mr. Jayaprakash R. – Partner – jayaprakash@dhc.co.in

Mr. Adil M – team leader - adil.mukadam@dhc.co.in

November 2014

Contents 1.0 BACKGROUND ................................................................................................ 1

2.0 WHAT RBI INTENDS TO ACHIEVE .......................................................................... 1

3.0 ASSESSMENT OF CURRENT LEVEL OF READINESS ....................................................... 2

4.0 UNDERSTANDING THE VARIOUS PROCESSES ............................................................. 3

4.1 Data Acquisition .......................................................................................... 3

4.2 Data Integration and Storage .......................................................................... 4

4.3 Data Conversion .......................................................................................... 4

4.4 Data Submission .......................................................................................... 4

5.0 RECOMMENDATIONS ......................................................................................... 6

5.1 Processes .................................................................................................. 6

5.2 Returns Governance Group (RGG) ..................................................................... 7

6.0 BENEFITS OF ADF IMPLEMENTATION ..................................................................... 8

7.0 PROBLEMS DURING IMPLEMENTATION .................................................................... 9

7.1 IT Partner .................................................................................................. 9

7.2 Report ownership ........................................................................................ 9

7.3 Data ownership ........................................................................................... 9

7.4 Defining logic ............................................................................................. 9

7.5 Single point of contact .................................................................................. 9

7.6 Incremental changes introduced by RBI .............................................................. 9

7.7 UAT/Validation/Handoff ................................................................................ 9

7.8 Group entities ............................................................................................ 9

7.9 Flow of information ...................................................................................... 9

7.10 Documentation ........................................................................................... 9

8.0 About Us ..................................................................................................... 10

1

1.0 BACKGROUND

Timely data aggregation, analysis and dissemination are core to promoting vibrant financial

markets. The number of participants in the Indian financial market is increasing. Further the nature

of financial products / solutions are also becoming complex. In such a backdrop, Reserve Bank of

India (RBI) has introduced a path breaking initiative of mandating automated reporting system for

banks. The initiative has been termed as Automated Data Flow (ADF). ADF promotes straight-

through reporting process (STP) allowing commercial banks to file their reports generated directly

from data in their core banking solutions systems or any other IT systems.

Currently there are around 150 different reports that a banker needs to collate and submit to RBI in

differing periodicity (Weekly, fortnightly, monthly, quarterly and annually). Material time and

efforts is invested by bankers in collating data and preparing such reports. Ensuring the reports are

aligned with the financial statements is an additional task. It is envisaged that ADF implementation

would make the process of reporting easier and faster. Further as there is limited manual

intervention, such reports would be aligned with the financial statements of banks ensuring

consistency and comparability.

The RBI has also released a detailed note which highlights the approaches banks can adopt to

ensure smooth implementation of the ADF framework. The note can be downloaded from:

http://rbidocs.rbi.org.in/rdocs/PublicationReport/Pdfs/APSDS101110.pdf

Over the last 18 months, we have been involved in assisting banks in its ADF enabling project as

functional experts. As the project is one of its kinds, experience of working on the same was quite

enriching. We have captured the major requirements and our experiences in assisting bankers in

meeting the requirements.

RBI has mandated 5 banks to start with becoming ADF ready. It is expected that over a period of

time, ADF would become mandatory to all financial institutions. In this background we thought it

would be useful to share a white paper on the subject and reach out to Bankers and Consultants to

foster discussions.

2.0 WHAT RBI INTENDS TO ACHIEVE

RBI Approach paper on implementation of ADF states - “The common end state is the state of

complete automation for submission of the returns by the banks to RBI without any manual

intervention.”

The RBI intends to promote a level of automation in banks which would allow submissions directly

from their core banking solution systems without any manual intervention. To achieve this

objective, RBI has broken down the return submission process into four distinct logical processes

viz.

• Data Acquisition,

• Data Integration and Storage,

• Data Conversion,

• Data Submission.

2

3.0 ASSESSMENT OF CURRENT LEVEL OF READINESS

The ADF project is an IT intensive project and hence requires the participating commercial banks to

make a heavy investment for implementation. Keeping the end objective of all banks submitting

their returns through the RBI has designed a self-assessment questionnaire which assesses banks on

two dimensions – Process and Technology across each of the four categories mentioned above. Basis

the score received in the questionnaire the banks are able to plot themselves on a 2x3 matrix as

illustrated below.

Based on the level of Process and Technology maturity, each bank is placed in one of the six

clusters illustrated above. The timeframe for automation for each group of returns will depend on

the cluster in which the bank is placed. This in turn will determine the timelines for the banks to

achieve the common end state for all returns.

Basis our experience we’ve observed that banks prefers to deploy a mix of internal and external

resources to assess their level of readiness and to place them in the appropriate cluster.

Based on the extent of readiness, the ADF projects would take 18 to 24 months to be implemented.

3

4.0 UNDERSTANDING THE VARIOUS PROCESSES

The above diagram illustrates how the sum of each of the processes defined by the RBI forms a part

of the whole ADF project. Each of the processes are explained in detail below:

4.1 Data Acquisition Data Acquisition layer is the first process in which the data is captured and consolidated from

various source systems e.g. - Core Banking Solution, Treasury Application, Trade Finance

Application, etc. For data maintained in physical form, the RBI expects that this data would be

migrated to appropriate IT systems.

Generally there are difference IT systems to cater to different product / services offered by bank.

We have observed that a large bank would have separate systems for each of the following

domains:

• Overdraft/Retail portfolio

• EMI loans/Securitization

• Wholesale banking

• Investments and Treasury

• Derivatives

• Loan against collateral like gold

• Loan against shares/Mortgage

• Systems for Overseas branches

• Overseas systems for Money Market deals

• Systems for Domestic money market used for inter-branch reconciliation

• Core accounting system

Further, we noticed that many banks prefer to keep their NPA and Investment computations off

their systems in the physical form and thus is prone to human error. RBI through ADF intends to

ensure that this data is digitised.

4

The data acquisition process has been implemented by banks in a staged manner, dependent on the

frequency of the reports. Banks started with putting processes in place for reports submitted on an

annual basis and intend to gradually move up to sourcing data in to the CDR on a daily basis.

4.2 Data Integration and Storage The Data Integration & Storage layer extracts and integrates the data from source systems with

maximum granularity required for Reserve Bank returns and ensures its flow to the Centralised Data

Repository (CDR). Banks that have a Data Warehouse may consider using it as the CDR after

ensuring that all data elements required to prepare the returns are available in the Data

Warehouse. To ensure desired granularity, the banks may either modify source systems or define

appropriate business rules in the Data Integration & Storage layer.

4.3 Data Conversion This process converts the data stored in the CDR to the prescribed formats using pre-defined

business rules. The data conversion structure could be in the form of a simple spreadsheet to an

advanced XBRL instance file. The Data Conversion layer will also perform validations on the data to

ensure accuracy of the returns. Some common validations like basic data checks, format and

consistency validations, abnormal data variation analysis, reconciliation checks, exception report,

etc. are done in this layer.

Some of the validations that we deployed at one of our client banks are given below

• Flow of all data from various systems into the CDR

• Verification of new data added to CDR, namely:

o New products

o New GL’s

o New PSL codes

o New branch codes

o New facilities

o New collateral types

o New customer types

o New customer categories

• Once number flows into ADF drill-down of how the number was derived

• Checking if the number in the ADF report is correct

• Checking for any discrepancies between the manual and the ADF report

4.4 Data Submission The Data Submission layer is a single transmission channel which ensures secure file upload

mechanism in an STP mode with the reporting platforms like Online Return Filing System (ORFS). In

all other instances, the required returns may be forwarded from the bank’s repository in the

prescribed format. The returns submission process may use automated system driven triggers or

schedulers, which will automatically generate and submit the returns. When the returns generation

process is triggered, the system may check if all the data required to generate this return has been

loaded to the central repository and is available for generating the return. It may start preparing

the return only after all the required data is available. The Data Submission layer will acknowledge

error messages received from Reserve Bank for correction and further processing.

The table below highlights the frequency and the number of reports that are generated using the ADF system

Frequency Number of reports

As and when 6 reports

Daily 8 reports

Weekly 3 reports

Fortnightly 12 reports

Monthly 33 reports

Quarterly 39 reports

5

Half yearly 14 reports

Yearly 14 report

RBI recommends employing an automated trigger based system for the generation of reports

through ADF. However, during our implementation of the ADF project the following issues

presented themselves:

• Co-ordination between multiple departments

Some of the report elements require data to be sourced from multiple departments. This at

times creates difficulties in ensuring that the data in the system is updated in time.

• Missing data entry deadlines

Even when data is not to be sourced from multiple departments and only one department is

responsible for providing the report data, there are times when the data entry deadlines

are missed. This again proves to be a hurdle in the implementation of the ADF project.

• Adjustment entries

Utmost care needs to be taken to ensure that all relevant adjustment entries are

completed within the report generation deadlines. Failure to do so leads to a discrepancy in

the data in the report.

6

5.0 RECOMMENDATIONS

To ensure ease of implementation of the ADF framework the RBI has made the following

recommendations:

5.1 Processes For each of the four processes RBI recommends the following practices:

Process Key Characteristics to be captured as part of the Process Documentation

Data Acquisition

Process may document:

• Data fields in return

• Computations required

• Data owners, roles and responsibilities

• Source systems for different data fields

• System access privileges

• Frequency of data capture from source systems Process may be reviewed periodically and/or when there is a change in the sources systems or introduction of new reports, change in reporting format etc. Any change in the process may be made after a thorough assessment of the impact of the change on the end-to-end submission process Any change in the process may be documented and approved by an authorized committee which has representations from various departments

Data Integration & Storage Process may document:

• Data classification in the reports

• Business rules which synchronise the data

• Business rules to cleanse and classify the data

• Data quality and validation checks to ensure the correctness of the data

• Fields to be captured during audit trail

• Length of the time the data may be stored in the CDR

• Method of backup and archival after the elapsed time

• System details where the archived data is stored and the process of retrieval from the archived data store

Process may be reviewed periodically (frequency depending on the change in the sources systems, introduction of new reports, change in reporting format etc.)

Data Conversion Process may clearly document

• Reserve Bank requirements (codes, format, classification) for each return along with the interpretation of the fields

• Procedures for performing data validation to ensure correctness of format and content of the return. The data validation rules include checks for basic data validations and format validations as well as validations to ensure consistency, validity of the data

• Defined business rules to transform the data as per Reserve Bank requirements

• Fields to be captured during the audit trail

• Procedure for performing audits listing the roles and

7

responsibilities, frequency of the audit Process may be reviewed periodically and/or whenever there is a change in the reporting format.

Data Submission Process may clearly document

• Submission schedule for each return

• Return submission process (ORFS or others)

• Procedure to check compliance to Reserve Bank requirements (in terms of the format, syntax, timeliness of submission etc.) listing the roles for checking the compliance

• Assigned responsibility to check for the delivery acknowledgement

• Corrective procedure in case of failed data validation

• Procedure to investigate into discrepancy, if any

5.2 Returns Governance Group (RGG) Owing to the size of the banks the governance and submissions of various returns is distributed

across many departments with either little or no centralisation. To overcome this issue the RBI

recommends the formation of a Returns Governance Group (RGG) committee. It is advisable for the

RGG to include members from all areas such as compliance, business and technology.

The roles and responsibilities of the RGG committee are laid out as below:

• Setup of entire process

The RGG may take up the responsibility of setting up the entire automation process in

collaboration with the bank’s internal Technology and Process teams. This would ensure

timely and consistent submission of returns to Reserve Bank. Though the data within the

repository could be owned by the individual departments, the RGG could be the custodian

of this data.

• Central team/Facilitator

The RGG is responsible for routing queries to respective departments, monitoring report

content, verification of returns, adherence to timelines, interpretation of guidelines and

clarifications from Reserve Bank on queries.

• Compliance

The RGG is also to conduct periodic internal compliance audits, maintaining a repository of

various people across the organisation who are responsible for various returns. The RGG is

also to keep a check and provide updates on regulatory changes to internal users.

• Ownership

The RGG may be the owner of all the processes. The role of the RGG may be that of a

‘Vigilante and Custodian’.

• In context of Processes

o Data Acquisition

� Defining fault limits for errors

� Defining threshold limit for deadlines/ extensions on timelines

� Regulatory/ Guideline Changes as and when directed by the Reserve Bank

� Introducing select repetitive ad-hoc queries as standard queries in the

system

o Data Conversion

� Validating syntax of the reports

� Checking for compliance to RBI requirements

o Data Submission

� Enforcing data transmission timelines

� Delivery acknowledgement

� Investigation of anomalies

8

6.0 BENEFITS OF ADF IMPLEMENTATION

The key benefits of the ADF project are as follows:

• Improved timelines

• Enhanced data quality

• Improved efficiency of process

• Reduced costs

• Use of CDR for MIS purposes

A comparison of the issues with the current scenario and benefits of automation is given in the

table below:

Parameter Issues with Current State Benefits of Automation

Timelines Preparing the data for submission to Reserve Bank is a challenge owing to the extent of manual intervention required for the entire process.

• The end-to-end cycle time will be reduced as data will be available in a CDR.

• The entire process of submitting data will be driven by automated processes based on event triggers, thereby requiring minimal manual intervention. This would ensure that the returns are submitted to the RBI with minimal delays.

Quality Data Quality and Validation is not driven by defined processes. Hence the onus of validating and ensuring the data is entered correctly is dependent on the individuals preparing the returns. The data is not integrated across the different source systems. This results in data duplication, mismatches in similar data, etc. Metadata is not harmonized across different applications.

• Minimal manual intervention reduces errors and ensures better data quality.

• A well-defined process for ensuring data quality ensures that the source data is cleansed, standardised and validated so that the data submitted to RBI would be accurate and reliable.

• Data validation checks in the internal storage layer as well as in the data conversion layer ensure that the data being submitted is correct and consistent.

• The data would be harmonised by ensuring standard business definitions across different applications.

Efficiency Being a manual process, efficiency is person dependant.

• Automation will eliminate dependence on individuals and improve efficiency.

Cost Returns preparation is a non-core activity for the bank which does not generate any revenue. Manual processes require more manpower.

• Automation will reduce the manpower required for returns generation. So, more manpower will be available for revenue generating activities.

• Automation will also improve decision making process and MIS with the bank leading better business strategies and improved bottom lines.

Utilisation of CDR for MIS purposes

Use of spreadsheet or CBS for generation of MIS MIS is generated by each source application individually.

• The CDR created can be used for internal MIS purposes also. This would free up the core operational systems for transactional purposes.

• The CDR would have integrated data from across different source systems which will allow banks to have a consolidated view.

9

7.0 PROBLEMS DURING IMPLEMENTATION

The RBI ADF project being an IT intensive project requires various departments within the bank to come together during the implementation. From our past experience some of the problems that might present themselves during implementation are listed below

7.1 IT Partner The first step in the implementation of the RBI ADF project is the selection of a competent IT partner. It is very common for different departments within the same bank to each have a different system of their own. The selection of an appropriate vendor is of utmost importance as the vendor needs to understand and extract data from these multiple systems and compile them in to one report for submission.

7.2 Report ownership The ownership of each of the reports needs to be clearly defined. The report owner will be responsible to ensure that the reports are submitted on time.

7.3 Data ownership Multiple teams are simultaneously involved in providing the relevant information required in these reports. A clearly defined data owner enables the report owner to identify the correct person and resolve issues that might crop up during the reporting cycle.

7.4 Defining logic There are a few items in the reports which require certain operations to be performed before finally flowing into the report. For such numbers the logic for the operations to be performed on the numbers need to be clearly defined. Failure to do so can lead to incorrect numbers being reported to the RBI.

7.5 Single point of contact Since these reports involve inputs from various departments within the bank there is a dire need for someone to act as a mediator between these departments. This person who will see the report as a whole will be in a better position to assist the filing of the report within the stipulated timelines.

7.6 Incremental changes introduced by RBI In the event that any changes are introduced by RBI, the same have to be updated in the banks’ ADF system as well. A proper system needs to be created which would enable identification of the teams involved and ensure that the changes are incorporated in the least amount of time.

7.7 UAT/Validation/Handoff As with any new system being introduced there is always a need for extensive testing of the system before actually deploying it. During this phase all the data owners involved in a particular report have to actively participate and validate the data flowing through the ADF system. This validation process is an ongoing process until all the reported numbers are accurate.

7.8 Group entities It may be that the Subsidiaries/JV’s/Associates of the bank may not prepare their financials in accordance to the banking rules. In such a scenario a system needs to be designed to define the cut-off dates for providing the numbers.

7.9 Flow of information In case of certain numbers the numbers are not directly available from the financials. A reliable system has to be designed to capture such exceptional items.

7.10 Documentation Proper documentation needs to be maintained of all the steps and the people involved in the preparation of the report.

10

8.0 ABOUT US

DH Consultants Pvt. Ltd. (DHC) is one of the leading domestic accounting & consulting firm with

global ambition and outlook.

DHC is committed to going beyond service into value addition in the true sense of the word. To

understanding not just what our customers want, but what their business needs; to meeting not

just immediate requirements, but provide long term solutions; to being not just reactive to client

needs but being proactive to solve their future issues.

Led by two industry stalwarts – Shailesh Haribhakti and Dilip B. Desai, DHC brings together

combined expertise and knowledge of two leading firms to maximize opportunities and value for its

clients.

DHC is present in 11 cities across the country. We take pride in being a full service organisation

with complete focus on niche services. We provide tailor- made services as per the changing needs

of our clients with attention to detail to ensure our services are internationally bench marked.

Our services can be broadly classified as follows-

• Risk and Advisory Services

• Tax and Regulatory Services

• Corporate Finance Advisory Services

• Global Knowledge Services

• Assurance Services

Disclaimer: This publication has been carefully prepared, but it has been written in general terms

and should be seen as broad guidance only. The publication cannot be relied upon to cover specific

situations and you should not act, or refrain from acting, upon the information contained therein

without obtaining specific professional advice. Please contact DH Consultants Pvt. Ltd. to discuss

these matters in the context of your particular circumstances. DH Consultants Pvt. Ltd., its

partners, employees and agents do not accept or assume any liability or duty of care for any loss

arising from any action taken or not taken by anyone in reliance on the information in this

publication or for any decision based on it.

DH Consultants Pvt. Ltd. (CIN U74999MH2000PTC124842) is a private limited company

incorporated in India.