1.

Company Profile

Fintellix Solutions Private Limited provides analytics, risk, and compliance solutions for the banking
sector. It offers Fintellix platform, a banking data management infrastructure for data management and
processing, content management and administration, and content and collaboration.
Fintellix Data Foundation that includes core system integration framework, banking data hub, banking
metadata repository, and external and big data adaptors; and Fintellix Cloud, a cloud-based
implementation of Fintellixs compliance, risk, and analytics solutions.
The company also offers products, including Fintellix Compliance that provides regulatory reporting,
FATCA compliance, ALLL, asset quality management, risk based supervision, and basel II/III solutions;
Fintellix Risk, which offers solutions for market, credit, LCR/NSFR, interest rate, and value at risk and
Fintellix Analytics, a productized business intelligence solution suite that offers executive, financial, and
risk insights.
In addition, it provides information management services, such as DWBI competency centre, strategy
consulting, architecture consulting, design and development, and managed services, as well as MDM and
data quality consulting; banking technology services, including core banking consulting and data
migration services; and business applications, such as statements and advices solutions, and customer
loyalty management systems.
The company serves local, regional, and global banks in Europe, Africa, the Middle East, India, and
ASEAN.

Fintellix Solutions Private Limited was formerly known as iCreate Software India Pvt. Ltd. and changed
its name to Fintellix Solutions Private Limited in December 2014. The company was founded in 2006 and
is based in Bengaluru, India.

2. Abstract

Automated Data Flow from the Reserve bank of India (RBI) has

transformed the hitherto manual

reporting ecosystem in India. With its clear architectural guidelines of the Data Integration, Central Data
Repository (CDR), Data Conversion and Submission layers, the RBI mandated that the data flow from the
Banks source systems to the reports be fully automated. Fintellix (then known as iCreate) emerged as a
pioneer in the ADF space with a next generation Data management layer with a powerful Business rules
engine to convert the data from the CDR to the regulatory reporting lines and a user-friendly Review
Process

flow

to

streamline

and

automate

the

submission.

Fintellix RBI ADF (previously known as Biz$core RBI ADF) is a product that comprehensively meets the
RBI ADF guidelines with a completely metadata-driven data flow as well as a flexible conversion and
submission layer which is independent of the reporting content, form and format. Due to the adherence to
the RBIs architectural guidelines, Fintellix has been able to meet RBIs other compliance requirements
(NPA Automation, Risk Based Supervision, LCR) on the same Platform and CDR and will be able to
leverage the same CDR and infrastructure for RBIs future compliance guidelines.

Firstly Data acquisition is done by tool know as Infomatica where data is loaded into Reception area. Then
by scripts in ETL, the required data is loaded into Mart area.
Further this data loaded in mart is populated in fact tables according to rules configuration of that report.
Rules configuration is stage which states logic for data cell in report where vale is to be populated. It
could either directly come from data source or it would be calculates from multiple dimensions.
This project aims at complete automation of Reports which banks have to submit to RBI.

Benefits of new Proposed system:

Timeline: The end-to-end cycle time will be reduced as data will now be available in a CDR.The
entire process of submitting the 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 Reserve Bank with minimal delays.

Quality: 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, standardized and
validated so that data submitted to Reserve Bank would be accurate and reliable. Data validation
checks in the data integration & storage layer as well as in the data conversion layer ensures that
the data being submitted is correct and consistent.The data would be harmonized by ensuring
standard business definitions across different applications.

Efficiency: Automation will eliminate dependence on individuals and improve efficiency.

Cost : 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 within the bank leading better business strategies and improved bottom lines

 Utilization of CDR for MIS purposes: 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.

3. Introduction

ADF (Automated Data Flow) is complete automation for submission of the returns by the banks to RBI
without any manual intervention. To achieve the objective of automated data flow and ensure uniformity
in the returns submission process there is need for a common end state which the banks may reach. The
common end state defined in this chapter is broken down into four distinct logical layers i.e. Data
Acquisition, Data Integration & Storage, Data Conversion and Data Submission. The end state covers the
dimensions of Process and Technology.
3.1 Data Architecture
Data Architecture refers to the design of the structure under which the data from the individual source
systems in the bank would flow into a Centralized Data Repository. This repository would be used for the
purpose of preparation of returns.
3.1.1 The conceptual end state architecture representing data acquisition, integration, conversion and
submission is represented in Figure 3 given below. Under this architecture, the Data Integration & Storage
layer would integrate and cleanse the source data. Subsequently, the Data Conversion layer would
transform this data into the prescribed formats. The transformed data would then be submitted to Reserve
Bank by the Data Submission layer.

Figure 3: Conceptual Architecture for End State for banks to automate data submission

The details of each layer are enumerated below:

(a) Data Acquisition Layer: The Data Acquisition layer captures data from various source systems e.g. Core Banking Solution, Treasury Application, Trade Finance Application, etc. For data maintained in
physical form, it is expected that this data would be migrated to appropriate IT system(s) as mentioned in
the chapter on approach for banks.
(b) Data Integration & Storage Layer: 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 Centralized Data Repository (CDR). Banks having 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.
(c) Data Conversion/Validation Layer: This layer 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.
would be required to be done in this layer.
(d) Data Submission Layer: The Data Submission layer is a single transmission channel which ensures
secure file upload mechanism in an STP mode with the reporting platforms like ORFS. In all other
instances, the required returns may be forwarded from the banks 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.

4. Domain Knowledge

Fintellix solutions provides consulting for banking domain only. Hence before developing any report
functional need of that report is necessary.
International Banking Statistics (IBS) is defined as banks on-balance sheet liabilities and assets vice
versa non-residents in any currency or unit of account along with such liabilities and assets vice versa
residents in foreign currencies or units of account.
HDFC has three foreign branches in Hong Kong, Bahrain and newly opened Dubai. Data for these
braches flows into database in the form of General ledger account level data. Which will be brought to
Mart using Informatica ETLs. Through GL accounts of each and every customer, the branch he belongs to
can be determined.
Through branch address country field country of the customer can be determined. Data flowing in IBS
report will be segregated on the basis of the country of the customer.
Using predefined codes for asset, liability and their types data will be represented in tabular form.
The IBS report is part of BASEL activity. When RBI gets data of all Indian banks having braches outside
Indian region, RBI consolidated all bank level data into one and this report goes to BASEL committee.
IBS report depicts position of a particular bank with respect to International Banking. As per RBIs
regulation a bank can not invest more than certain percentage capital in foreign market. Thus IBS also
helps RBI to control banks investment in International Market.

5. Existing System

Existing System uses a manual approach for generation of reports. This approach is time consuming and
might have errors. This results are sent were made in excel and are mailed to RBI.
In totality there are 228 reports which RBI decides which bank has to submit which report.
Report covered as project is IBS Return that is International Bank Statistics. Earlier this report used to go
as text files separate for India, Bahrain and Hong Kong for derivative and non-derivative accounts. HDFC
Bank used to pull data for India, Bahrain and Hong Kong through various data source systems and then
through procedure and views it used to write three separate text files.
Following are the problems in existing system.

Problems in the Existing system:

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

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 application

Being a manual process, efficiency is person dependant.

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

6. Problem Definition and Scope of Project

IBS is a quarterly return submitted to RBI. HDFC bank created a new change request to meet changes
required in IBS report as per RBIs new template. Also HDFC opened new branch in Dubai, UAE, so this
should be included as new data source system from which data will flow to IBS report.

Format of the report will be as follows:

S
L

Short
Field Description

Name

Description

1 Year and Quarter

YRQTR

Newly Added field mentioning Year and Quarter

2 Bank Code of Reporting Bank

BKCODE

Newly Added field mentioning Bank Code

Residence Country Code of

Newly Added field mentioning Country code

3 Branches

FORCD

(India/ barbarian / hong kong)

4 Asset/Liability Category

ALCD

As per existing report Logic

5 Category

TYPECD

As per existing report Logic

6 Currency of the Account/Settlement

CURCD

As per existing report Logic

7 Borrowers/Customers

COUNCD

As per existing report Logic

8 Sector of the Borrowers/Customers

SECTCD

As per existing report Logic

Type of Asset/Liability under the

Residence Country Code of the

difference between the date of maturity of

international
Assets/liabilities and reporting date of IBS data
9 Residual Maturity Classification
1

Country of Ultimate Risk

MATCD

**

C_U_CD

As per existing report Logic

0
1
1 Sector of Ultimate Risk

S_U_CD

As per existing report Logic

FC_BAL

As per existing report Logic

FC_INT

As per existing report Logic

Outstanding Balance in terms of

Currency of
1

Account /MTM value in terms of

2 US Dollar
1 Accrued Interest in terms of
3 Currency of Account
1 Outstanding Balance/MTM value in
4 terms of Rs. 000

As per Existing logic - and amount required in

RS_BAL

1 Accrued Interest in terms of Rs.

5 000

Rs. '000'
As per Existing logic - and amount required in

RS_INT

Rs. '000'

As a part of change request IBS report will have one flat file (.csv) with data of India, Bahrain and Hong
Kong as main report and based on this main report there will be five summery reports. These five reports
are as follows:
a. Asset and liability code wise summary (domestic branches)
b. Country-wise @ outstanding assets for top 20 countries (domestic branches)
c. Country-wise @ outstanding liabilities for top 20 countries (domestic branches)
d. Country-wise (ultimate risk basis) @ exposures under derivatives, guarantees, Letters of Credit and
Credit Commitments for top 5 countries (domestic branches)
e. Country-wise (ultimate risk basis) @ exposures under derivatives, guarantees, Letters of
Credit Commitments for top 5 countries (foreign branches)
f. Assets and liabilities code wise exposures summary (foreign branches)
Also validation should be done for each record after all the data has been processed.

Credit and

Then Functional Specification document is submitted by the Fintellix defining scope of the change
request. In this document technical aspects of the change requests are specified along with testing scope
and detailed ETL level changes as well if required.
Once the scope of the project is signed off by Bank, no additional changes in request are accepted. It
will be treated as new change request.
Scope of the IBS report is addition of columns in main reports, change in derivative logic and additional
summery reports.

7. Requirement Analysis

Whenever the change request arises, bank prepares a Requirement Specification Document.

In this

document bank briefly introduces report if the report is the new one, else states direct details of the report
like frequency and data sources.
This requirement document consist of details of current working process of the report and the process that
needs to be changed and the reason behind it. This document also consist of all the documents necessary
to study change request, for example RBI circular specifying change request, if RBI generated.
When the document is received by Fintellix, proposed change request is studied in detail to see its
feasibility. If needed meeting is arranged with Business Support Group and Bank User and Business
Analyst as well asking for more clarifications about changes.
Fintellix submits User Understanding document to Bank pertaining to the change request specifying
functional understanding of the change request.
After this User Understanding document is signed off by HDFC Bank. Then purchase order is set with
bank providing them Effort Estimation Document ( provided in Effort Estimation section).
After approving effort estimation, purchase order is placed and actual development of the report get
started.

8. Estimation and Planning

There are several techniques for cost estimation, but the 2 basic approaches are top-down and bottom-up.
In the top-down approach, cost is derived from a business analysis of the major project components. In the
bottom-up approach, cost is derived by accumulating estimates from the people responsible for various
components.
Gantt chart for Bizscore product i.e ADF is given below.

Gantt Chart

The Effort estimation for IBS Return report submitted by Fintellix to HDFC bank is as follows

Activity

Sub Activity

Effort

Total

Units (if

(In

Efforts

applicab

Person

(in

le)

Days per Person

Unit)

Comments

Days)

Requireme
nt analysis
and

Functional Analysis

20

1.00

20

0.00

Discussion
Understanding of Source Files/Tables and
Solutioning

Sources :
***

ETL Design and Mapping

0.00

0 ***

ETL Development and Unit Testing

2.00

8 ********

RCM Development and Unit Testing

0 ******

Data
Integration

****
**********
*
*******
**********
**
*******

**********
****
******
Data load Activity for SIT/UAT (3 Rounds:
SIT - 1, UAT - 2)
Report Logic Understanding, feasibility and
finalization

0.00

600

25

Fact Configuration.
Metric/Template Configuration.
Rules Configuration.

Data Load

Report Parameter Configuration and

Testing

Report Testing post data load

0.00

Report and

14

Rules

Configurat

74

ion

SIT/UAT Support

0.00

Basic COCOMO (Constructive Cost Model) computes software development effort (and cost) as a
function of program size using multiplying factors of the cost driver attributes are multiplied to calculate
EAF (Effort Adjustment Factor).
Basic COCOMO is good for quick estimate of software costs. Using this one can calculate efforts required
for development, duration and man-power required for development.

Estimation of these three parameters of this project (calculated using COCOMO) is explained here:
This is semi-detached project where "medium" teams with mixed experience working with a mix of
rigid and less than rigid requirements, working on different interactivities. So the total efforts for project,
development time and cost of the project can be determined by on the basis of cost estimation of
individual exploration.
Cost estimation of individual interactivity is done by using co-efficient values in semi-detached project.
On an average estimated KLOC of each interactivity is 1.5. So estimation of efforts applied, development
time and people required is calculated as shown below:

The basic COCOMO equations which are used calculate efforts applied, development time and manpower required are:
Effort Applied (E) = ab(KLOC)bb [ man-months ]
Development Time (D) = cb(Effort Applied)db [months]
People required (P) = Effort Applied / Development Time [count]
Where, KLOC is the estimated number of delivered lines (expressed in thousands)
of code for project

9. Development Tools and Technology

Since being part of delivery team, we work on Data migration and report generation in Bizcore application
is Proprietary product of fintellix solutions and is developed in java.

Following are well known tools for data migration

Commercial
Ab Intio
IBM Datastatge
Informatica PowerCenter
Microsoft Data Integration Services
Oracle Data Integrator
SAP Business Objects Data Integrator
SAP Data Integration Studio
Open Source
Pentaho Data Integration (Kettle)
Talend Open Studio
From above techniques, we use Infomatica Powercenter for Data extraction.

11. Implementation

With the help of Informatica Power Designer, data will pulled from various data source systems and then
It will be brought to reception area first and then mart area. Views will created based on dimensions and
fact tables. Then procedure will create main report in .csv format and then using Microstrategy Report
generation tool summery reports template will be created. These summery reports will be populated with
help of Fintellix platform Biz$core.
The tool of Biz$core, which will be used to populated data into table is Rules Engine.
This Rule Engine creates rules as per configuration requirement. Once these rules are created and tested
then this report will be automated through Autosis software and from there report will be automatically
generated for every quarter and submitted to RBI.
Implementation of the report done in following steps:
1. Whenever change request is created by HDFC bank it provides Requirement Analysis document
specifying existing and proposed report format.

2. As a vendor we analyse Requirement Analysis document to see if the proposed change is feasible
through our product.

3. Once the change request is accepted a User Understanding document is created by Fintellix.

4. Bank analyses this and place Purchase Order for this change request.

5. Then Fintellix prepares Functional specification document, providing detailed logic and
implementation approach behind each and every line item.
Given Below are the templates of the reports as provided in Requirement Analysis document:

IBS Report :

International Banking Statistics (IBS) is defined as banks on-balance sheet liabilities and
assets vice versa non-residents in any currency or unit of account along with such liabilities and assets
vice versa residents in foreign currencies or units of account

The report data will be submitted as one text file with naming convention as P_IBS_XXXYYQ.txt
where XXX presents the bank code of the reporting bank, YY is the year of reporting in two digits and
Q is the quarter for which data is reported. Values for Q are 1, 2, 3 and 4 for March, June, September
and December, respectively.

Column Name
Year and Quarter
Bank Code of Reporting Bank

Residence Country Code of Branches

Logic
Reporting Year and Quater in the format YYYYQQ
Bank Code in the format of XXX (Hard coded To :
051)
Country code in ('IN','BH','HK','UAE') depending on
service_outlet_id of branch

Asset/Liability Category

As per existing logic

Type of Asset/Liability under the Category

As per existing logic

Currency of the Account/Settlement

As per existing logic

Residence Country Code of the

Borrowers/Customers
Sector of the Borrowers/Customers

As per existing logic

As per existing logic
difference between the date of maturity of

Residual Maturity Classification **

international
Assets/liabilities and reporting date of IBS data **

Country of Ultimate Risk

As per existing logic

Sector of Ultimate Risk

As per existing logic

Outstanding Balance in terms of Currency of

Account /MTM value in terms of US Dollar

As per existing logic

Accrued Interest in terms of Currency of Account

As per existing logic

Outstanding Balance/MTM value in terms of Rs.

As per existing logic and amount converted to

000
Accrued Interest in terms of Rs. 000
Validation Check IND

**Residual Maturity Classification

000' INR
As per existing logic and amount converted to
000' INR
Indicator for result validation check list.

Residual Maturity Code (MATCD)

Up to and inclusive of six months *

Over six months but up to and inclusive of one year

Over one year but up to and inclusive of two years

Over two years

Unallocated **

Summery Reports :
1. DOM Type-wise Summary

I. TYPE WISE SUMAMRY FOR ASSETS AND LIABILITIES (Domestic Branches)

Amount (` '000)
ALCD

TYPCECD

Variation

Assets/Liabilities
Type Name

Present

Previous

Qtr

Qtr

for Large
(%)
6

A. INTERNATIONAL ASSETS
Loans

to

Non-

residents
11

( (Present Qtr Previous Qtr) /

11

Previous Qtr ) * 100

CAN BE +VE OR VE

11

12

11

21

Foreign Currency
Loan to Residents

SAME AS ABOVE

Outstanding
Export Bills

SAME AS ABOVE

Foreign Currency
11

41

in hand, Travelers
Cheques, etc.

SAME AS ABOVE

NOSTRO
11

51

Balances

and

Placements
Abroad
Investment

21

11

SAME AS ABOVE
in

Foreign
Government

Explanation

SAME AS ABOVE

Variation
7

Securities
Investment
21

12

in

Other

Debt

Securities Abroad
31

11

Investments

SAME AS ABOVE

in

Equities Abroad

SAME AS ABOVE

Other
31

21

International
Assets

SAME AS ABOVE
B. INTERNATIONAL LIABILITIES

51

11

FCNR

(B)

deposits

SAME AS ABOVE

Residents Foreign
51

12

Currency

(RFC)

Deposits

SAME AS ABOVE

Exchange
51

13

Earners

Foreign

Currency (EEFC)
A/Cs

SAME AS ABOVE

51

14

Other FC deposits

SAME AS ABOVE

51

41

FC Borrowings

SAME AS ABOVE

Balances
51

51

in

VOSTRO
Accounts

SAME AS ABOVE

Non-Resident
51

52

External

(NRE)

Rupee Accounts

SAME AS ABOVE

Non-Resident
51

55

Ordinary

(NRO)

Rupee Accounts
51

57

SAME AS ABOVE

Embassy
Accounts

SAME AS ABOVE

Foreign
51

58

Institutional
Investors'

(FIIs)

Accounts
51

59

SAME AS ABOVE

ESCROW
Accounts

SAME AS ABOVE

International
61

11

Bonds (IMDs of
SBI, etc.,)

61

12

FRNs

SAME AS ABOVE

(Floating

Rate Notes)

SAME AS ABOVE

Other Own Issues,

61

13

if

any,

of

International Debt
Instruments

SAME AS ABOVE

GDRs/ADRs
71

11

(issued

by

the

reporting banks)

SAME AS ABOVE

Rupee Equities of
71

12

banks

held

NRIs/OCBs

by
SAME AS ABOVE

Other
71

13

international
liabilities

SAME AS ABOVE

2. ASSETS VS COUNTRY

III COUNTRY WISE EXPOSURES UNDER ASSETS (Domestic Branches)

Previous Quarter

ISO Code
Vis--vis country

(Vis--vis

Total claims/

Domestic

Total claims/

Domestic

Country)

Assets

currency

Assets

currency

BAHRAIN

BH

CANADA

CA

CHINA

CN

FRANCE

FR

GERMANY(Incl.
ECB)

Current Quarter

DE

HONG KONG

HK

INDIA

IN

JAPAN

JP

KUWAIT

KW

MAURITIUS

MU

NETHERLANDS

NL

NO SPECIFIC
COUNTRY

XX

OMAN

OM

SAUDI ARABIA

SA

SINGAPORE

SG

UNITED ARAB
EMIRATES

AE

UNITED
KINGDOM

GB

UNITED
STATES #
Total

US

3. LIAB VS COUNTRY

II COUNTRY WISE EXPOSURES UNDER LIABILITIES (Domestic Branches)

Previous Quarter
Vis--vis country

Current Quarter

ISO Code (Vis-

Total

-vis Country)

claims/

Domestic

Total claims/

Domestic

Assets

currency

Assets

currency

BAHRAIN

BH

BELGIUM

BE

CANADA

CA

CHINA

CN

FRANCE

FR

GERMANY(Incl.ECB)

DE

HONG KONG

HK

INDIA

IN

ITALY

IT

JAPAN

JP

NETHERLANDS

NL

NO SPECIFIC
COUNTRY (Country
unknown)

XX

OMAN

OM

SINGAPORE

SG

SRI LANKA

LK

SWITZERLAND
(Includes BIS)

CH

UNITED ARAB
EMIRATES

AE

UNITED KINGDOM

GB

UNITED STATES #

US

Total

4. OFF-BALANCE SHEET

IV & V. DERIVATIVES, LETTER OF CREDITS, GUARANTEES AND

CREDIT COMMITMENTS
(on ultimate risk
basis)

Derivatives (8111)
Country of
Exposure

Canada
China
France
German
y
Hong
Kong
Singapo
re
South
Korea
Switzerl
and
(Includi
ng BIS)
United
Arab
Emirate
s
United
Kingdo
m
United
States of
America

CA
CN
FR
DE
HK
SG
SK

CH

AE

GB

US

Domest
ic
Branch
es

Foreign
Branch
es

Letter of Credit
(8121)
Domest
ic
Branch
es

Foreign
Branch
es

Guarantees (8131)
Domest
ic
Branch
es

Foreign
Branch
es

Credit
Commitments
(8141)
Domest Foreig
ic
n
Branch Branc
es
hes

5 Expo of Foreign Branches

VI. TYPE WISE SUMAMRY FOR ASSETS AND LIABILITIES (Foreign Branches)
Amount (` '000)
ALC

TYPCEC

Assets/Liabilities Type

Name

t Qtr

s Qtr

(%)

( (Present Qtr Previous Qtr) /

11

Previous Qtr ) *

11

100
CAN BE +VE
OR -VE

11

12

11

21

11

41

11

51

21

11

21

12

Foreign Currency Loan to

Residents

SAME AS
ABOVE

Outstanding Export Bills

SAME AS
ABOVE

Foreign Currency in hand,

Travelers Cheques, etc.
NOSTRO

Balances

Placements Abroad
Investment

in

SAME AS
ABOVE

Foreign

Government Securities
Investment in Other Debt
Securities Abroad

SAME AS
ABOVE

and

Large
Variation

A. INTERNATIONAL ASSETS
Loans to Non-residents

Explanatio
n for

Presen Previou

Variation

SAME AS
ABOVE
SAME AS
ABOVE

31

11

31

21

Investments

in

Equities

Abroad

SAME AS
ABOVE

Other International Assets

SAME AS
ABOVE

B. INTERNATIONAL LIABILITIES
51

11

51

12

51

13

51

14

51

41

51

51

51

52

51

55

51

57

51

58

51

59

FCNR (B) deposits

SAME AS
ABOVE

Residents Foreign Currency

(RFC) Deposits

SAME AS
ABOVE

Exchange Earners Foreign

Currency (EEFC) A/Cs
Other FC deposits

SAME AS
ABOVE
SAME AS
ABOVE

FC Borrowings

SAME AS
ABOVE

Balances

in

VOSTRO

Accounts

SAME AS
ABOVE

Non-Resident External (NRE)

Rupee Accounts

SAME AS
ABOVE

Non-Resident

Ordinary

(NRO) Rupee Accounts

Embassy Accounts

SAME AS
ABOVE
SAME AS
ABOVE

Foreign

Institutional

Investors' (FIIs) Accounts

ESCROW Accounts

SAME AS
ABOVE
SAME AS
ABOVE

61

11

61

12

International Bonds (IMDs of

SBI, etc.,)

SAME AS
ABOVE

FRNs (Floating Rate Notes)

SAME AS
ABOVE

Other Own Issues, if any, of

61

13

International

Debt

Instruments
71

11

71

12

71

13

GDRs/ADRs (issued by the

reporting banks)
Rupee Equities of banks held
by NRIs/OCBs
Other international liabilities

SAME AS
ABOVE
SAME AS
ABOVE
SAME AS
ABOVE
SAME AS
ABOVE

C. LOCAL EXPOSURES IN LOCAL CURRENCY

91

11

91

12

Local Assets in Local

Currency
Local Liability in Local
Currency

SAME AS
ABOVE
SAME AS
ABOVE

6. Then all the format and logic mentioned in Functional Specification Document has been signed off
by user and Business Support Group of HDFC bank.

7. After sign off, Product team of the Fintellix, configure report template in Microstrategy Reporting
tool, and send all the artifacts necessary to build the report in Biz$core platform.

8. After this data loading starts, given below is the flow which is used to extract data from various
source systems. It is then brought to reception area, then stage area and then mart in the form of
dimension tables and fact tables and metadata.

Source

RECP

RCM

Fig. Source to Datawarehouse (Mart) Flow

MART

For data load Informatica PowerDesigner is used as ETL tool.

ETL (Extract-Transform-Load)
ETL is an abbreviation of the three words Extract, Transform and Load.
It is the foundation of the data warehouse.
A properly designed ETL system extracts data from the source systems, enforces data quality and
consistency standards, conforms data so that separate sources can be used together and finally delivers
data in a presentation-ready format so that application developers can build applications and end users can
make decisions.
ETL is one of the methods to implement Data Integration. DI can be achieved through other ways such as
E-L-T (Extract, Load and Transform) as done in Oracle data integrator.
The basic mission of the ETL system is to get data out of the source and load it into the data warehouse.
But it is necessary to clean and transform the data along the way.
The next step in the design of the ETL system breaks into several sub cases, depending on the data
sources, business rules, existing software and destination-reporting applications. The challenge is to
tolerate the subcases keeping in mind the simple overall mission of the ETL system.
Extract :
The Extract step covers the data extraction from the source system and makes it accessible for further
processing. The main objective of the extract step is to retrieve all the required data from the source
system with as little resources as possible. The extract step should be designed in a way that it does not
negatively affect the source system in terms or performance, response time or any kind of locking.
There are several ways to perform an extract
Update notification - if the source system is able to provide a notification that a record has been changed
and describe the change, this is the easiest way to get the data.
Incremental extract - some systems may not be able to provide notification that an update has occurred,
but they are able to identify which records have been modified and provide an extract of such records.
During further ETL steps, the system needs to identify changes and propagate it down.

Full extract - some systems are not able to identify which data has been changed at all, so a full extract is
the only way one can get the data out of the system.

Clean :
The cleaning step is one of the most important as it ensures the quality of the data in the data warehouse.
Cleaning should perform basic data unification rules, such as:
Making identifiers unique (sex categories Male/Female/Unknown, M/F/null, Man/Woman/Not
Available are translated to standard Male/Female/Unknown)
Convert null values into standardized Not Available/Not Provided value
Convert phone numbers, ZIP codes to a standardized form
Validate address fields against each other (State/Country, City/State, City/ZIP code, City/Street).

Transform :
The transform step applies a set of rules to transform the data from the source to the target.
Transformation involves
Joining data from several sources
Generating aggregates
Generating surrogate keys
Sorting
Deriving new calculated values
Applying advanced validation rules

Load :
During the load step, it is necessary to ensure that the load is performed correctly and with as little
resources as possible.
The target of the Load process is a database.
In order to make the load process efficient, it is helpful to disable any constraints and indexes before
the load and enable them back only after the load completes.
The referential integrity needs to be maintained by ETL tool to ensure consistency.

Components Of Informatica

Informatica domain The primary unit for management and administration of services in
PowerCenter. Your license agreement restricts you to a single domain.

Node A logical representation of a machine in a domain. The node that hosts the domain is the
master gateway for the domain. Your license agreement restricts you to a single node.

Informatica Services A Windows service that starts the Service Manager on a node.

Service Manager Starts and runs the application services on a machine in a domain.

Integration Service Reads workflow information from the PowerCenter repository, and runs
sessions and workflows that extract, transform, and load data.

Repository Service Manages connections to the PowerCenter repository.

Informatica Administrator A Web application for managing the Informatica domain,

PowerCenter security, and the PowerCenter repository.

Informatica domain configuration database Stores the information (metadata) related to the
configuration of the Informatica domain.

PowerCenter repository Stores the information (metadata) required to extract,

PowerCenter Client, which consists of:

Designer Allows you to define sources and targets, and create mappings with
transformation instructions, for use in workflows.
Workflow Manager Allows you to create, schedule, and run workflows.

Workflow Monitor
Allows you to monitor scheduled and running workflows.
Repository Manager Allows you to administer the PowerCenter repository: assign permissions to users
and groups, manage folders, and view PowerCenter repository metadata

Components of Designer :

Source Analyzer: Importing Source definitions for Flat file, XML, COBOL and relational Sources.

Target Designer: Use to Import or create target definitions.

Transformation Developer: Used to create reusable transformations

Mapplet Designer: Used to create mapplets

Mapping Designer: Used to create mappings

Transformations:

A transformation is a repository object that generates, modifies, or passes data

The Designer provides a set of transformations that perform specific functions

Data passes into and out of transformations through ports that you connect in a mapping or
mapplet

Transformations can be active or passive

Types of Transformations:
Active transformations - Active transformation can change the number of rows that pass through it.
Below are some examples:
Aggregator

performs aggregate calculations

Filter

serves as a conditional filter

Router

serves as a conditional filter (more than one filters)

Joiner

allows for heterogeneous joins

Source qualifier

represents all data queried from the source

Passive Transformations
Passive transformation does not change the number of rows that pass through it
Below are some examples:
Expression-

performs simple calculations

Lookup-

looks up values and passes to other objects

Sequence generator-

generates unique ID values

Stored procedure-

calls a stored procedure and captures return values

Update strategy-

allows for logic to insert, update, delete, or reject data

Mappings :
A mapping is a set of source and target definitions linked by transformation objects that define the
rules for data transformation.
Mappings represent the data flow between sources and targets.

Mapping Components:
Every mapping must contain the following components:
Source definition : Describes the characteristics of a source table or file.
Transformation : Modifies data before writing it to targets. Use different transformation objects to
perform different functions.
Target definition : Defines the target table or file.
Links : Connect sources, targets, and transformations so the Integration Service can move the data
as it transforms it.

Mapping Parameter & variable:

A mapping can utilize parameters and variables to store information during the execution. Each
parameter and variable is defined with a specific data type and their main purpose is to provide
increased development flexibility.
Parameters are different from variables in the fact that:
The value of a parameter is fixed during the run of the mapping
Variables can change in value during run-t
The format is $$VariableName or $$ParameterName.

Workflow Designer:
workflow contains a session and any other task you may want to perform when you run a workflow.
Tasks can include a session, email, command, decision or scheduling information.
You connect each task with links in the workflow.

Workflow Monitor :
View logs for the workflow instance.
View the context of the workflow instance to view other workflow instances that started around the same
time as the selected workflow instance.
Cancel or abort the workflow instance.
Recover the interrupted workflow instance.

Repository Manager
Allows you to administer the PowerCenter repository: assign permissions to users and groups, manage
folders, and view PowerCenter repository metadata.
Import & Export objects.

9. Next Step once data is loaded into mart is filter data as per requirement against each line item. For
this purpose rules are configured for line items each rule has specific template.
10. Rules can be configured using Fintellix platform that is Biz$core through backend that is through
oracle. If the rules are to be configured in bulk then backend loading is preferred. But through
frontend any end-user with very little knowledge of database SQL whatsoever can configure rule
in future.

Rules:
Rules are basically SQL query broken into part for better flexibility so that bank user can
understand and would be able to modify them
Example of rule configuration with comparison between SQL query is given below :

Configuration Item

Examples

<Configure Operation>

SUM, MAX, MIN, COUNT

SELECT

CURRENT_BALANCE, INTEREST_RATE,
<Configure Metric>

PRODUCT_INSTANCE_ID

* <Configure Conversion
Type>

ACY_To_LCY_RATE, ACY_TO_RCY_RATE

* <Configure Parameter
Mnemonic>

CRR_NDTL

<Group By Dimensions>
FROM
<Configure Fact>

FCT_DEPOSIT_DD

<Configure Dimension>

PRODUCT_TYPE

<Configure operator>

IN

WHERE

<Configure Dimension
Values>
GROUP BY

(PT01, PT02, PT03)

<Configure Group By
Dimensions>

PRODUCT_TYPE, SERVICE_OUTLET
SELECT
SUM(CURRENT_BALANCE) *
ACY_TO_LCY_RATE * CRR_NDTL METRIC_1
,MAX(INTEREST_RATE) METRIC_2
,MIN(INTEREST_RATE) METRIC_3
,COUNT(PRODUCT_INSTANCE_ID) METRIC_4
, PRODUCT_TYPE, SERVICE_OUTLET
FROM
FCT_DEPOSIT_DD
WHERE
PERIOD_ID = <Request Period ID>
AND
PRODUCT_TYPE IN (PT01, PT02,PT03)
GROUP BY PRODUCT_TYPE,
SERVICE_OUTLET

12. Testing

Functional testing:
Functionality testing of interactivity is testing conducted to evaluate the interactivitys compliance with its
specified requirements. Functional tests validate not a simple input-to-output conversion, but a complete
feature. It's a type of GUI testing where functionality of an application is tested. The requirement for each
interactivities are mentioned in storyboard provided and testing is done to check whether those
requirements are fulfilled
Once report is created it is sent to Technical Support Group of HDFC bank. This group generates the
report to check whether it is getting generated properly. And if approved pass it to the Business Support
Group.

Unit testing:

Unit testing is a software development process in which the smallest testable parts of an application,
called units, are individually and independently scrutinized for proper operation. In this project the
smallest units are individual tabs .The interaction of many functions but confine to the tab are tested.
In HDFC bank, Business Support Group test each and every section of the report and tally the report with
the one generated using traditional method.

Integration testing:

Finding the error (or errors) in the integrated tabs is much more complicated than first isolating the units,
testing each, then integrating them and testing the whole. Hence first individual tabs are tested and then
they are all integrated and tested as whole application. The purpose of integration testing is to verify
functional, performance, and requirements specified are met by the entire application developed.
In HDFC bank, Business Support Group test overall report in integration testing.

Web testing & accessibility testing:

Web testing is the name given to software testing that focuses on web applications. Complete testing of a
web-based system before going live can help address issues before the system is revealed to the public.
Issues such as the basic functionality of the application, its accessibility to handicapped users and fully
able users are tested before going live.

Usability testing:

Usability testing is a technique used in user-centered interaction design to evaluate a product by testing it
on users. This testing is done and feedback is conveyed to the developers through content team which is
incorporated in next iteration of the interactivity.
Once Business Support Group tested the report, report goes to actual user and User test it against
RBI template and then if correct then it is generated as per frequency of the report. And this report goes to
Reserve Bank of India as part of ADF report from HDFC Bank.

Regression testing:

Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions,
in

existing functional and non-functional areas

of

system

after

changes,

such

as

enhancements, patches or configuration changes, have been made to them. If any rework is need to be
done in which results in some functionality change or new functionality is added in the interactivity then
regression testing is performed.

Checklist Testing:

This is a testing methodology in which lists of different test conditions are specified and software is tested
against those conditions to check the correctness completeness and conciseness of built product.
For the Discovery High school project the checklist includes following tests

Storyboard violations testing

Content testing

Performance testing

Localization testing

Miscellaneous testing

Cross Browser testing

Across

Miscellaneous testing

Miscellaneous testing is basically testing of some standards specified by the organization for this
particular project. As a developer we first try to make it sure that these standards are followed by us during
the development.

Check Button:
Should get activated when user performs some new action which is to be checked by the system in order
to complete the interactivity.

Tab switch:
States of all tabs should be maintained even when tabs are switched rigorously. When some animation is
being shown on the screen (in one tab) all other tabs should be disabled.

Text:
All text must be parsed from localization JSON file.

13. Conclusion

Implementation of ADF in banks of India will help RBI to get clear picture of the situation of
economy as the data in reports would be error less.
Since economy planning is performed by ministry of finance and government of india, it uses analysis of
actual data from RBI in terms of financial status of the country.
Hence it is crucial that vigorous testing is performed and it is necessary that the logic applied to populate
values in cells is provided properly.
In case of International Banking Statistics Return report, it will give clear picture of the HDFC Banks
position in international market to Reserve Bank of India. IBS report will depict global market value of
the HDFC Bank, as it is one of the top hundred global brands.

14. Limitations.

o It is mandatory for bank to have Core banking system as the data required for this is collected from
database of CBS.
o Data going into bank database should be accurate.
o The cost of project is high.
o Developing report would take time of around 8 months depending on the resources deployed and
sanity of data.

15. Bibliography

https://www.rbi.org.in/
http://www.fintellix.com/India_index.php
https://www.informatica.com/
http://www.learnbi.com/

16. Report of communication with Internal Mentor

Sr.

Date

No.

Topic

Of Mode

discussion

Of Suggestions

Communication

Remarks

given

4th
1

March

Project Details

Personal

Synopsis Document

Personal

Personal

Mail

Mail

Changes required

Changes done

Personal

Format Changes

formatted

2015
18th
2

March
2015

3.

7th April

Project

2015

and Presentation

4th May

Project status

2015

review

4.

27rd
5.

May
2015

Black book
document

18th
6.

June

Black book review

2015
7.

25th

Final

June

Documentation

Personal

Sign