FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: BASEL TESTING AND VALIDATION
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Nirmal Building, 9th Floor, Nariman Point,
SERVICES LIMITED Indian Mumbai, Maharashtra 400021, India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it is to be performed.

TECHNICAL FIELD
[0001] The present subject matter is related, in general to data testing and validation and, particularly but not exclusively, to a method and a system for Basel testing and validation.
BACKGROUND
[0002] A data warehouse is a repository of data, such as data, derived from transaction data. For example, in a banking domain, multiple transactions pertaining to a user can be stored in a database, and this transaction data can be transformed and stored in the data warehouse. Therefore, for multiple users, this data can be generated on a continuous basis and stored in the database. Due to the constant updating of the data in the database, a dynamic nature is conferred to the data in the data warehouse.
[0003] The data stored in such data warehouses is generally queried to generate reports pertaining to decision support systems. Generally, data warehouses are optimized for querying and analysis, which is why they are often referred to as online analytical processing (OLAP) databases. For example, data warehouses may be subject-oriented in order for the users to effectively analyze the data pertaining to a specific industry or market sector. In order for the data warehouses to respond quickly to analytical questions or queries that are targeted at the data therein, the data warehouses are read-optimized.
[0004] Due to the constant transactions that occur on a daily basis in businesses and industries, the corresponding data stored in the data warehouses are also subject to constant change and updates. Furthermore, due to differences in data format between various disparate data sources, the data is generally integrated into a consistent format by transformation of said data. Therefore, the data is extracted, transformed, and loaded by what is generally referred to as an Extract Transform and Loading (ETL) module, which utilizes business rules associated with each of the transformations before loading said data into the data warehouse. Due to the vast amounts of data that is transformed and stored in the data warehouses, the data needs to be analyzed and validated on a regular basis to ensure integrity and completeness of said data.
[0005] In the banking domain, the Basel Accords are a set of agreements set by the Basel Committee on Bank Supervision (BCBS), which provides recommendations on banking regulations in regards to capital risk, market risk and operational risk. The purpose of the Basel

Accords is to ensure that financial institutions have enough capital on account to meet obligations and absorb unexpected losses. The data generated during Basel testing projects are generally stored in the data warehouses and need to undergo repetitive, stringent and rigorous quality checks.
SUMMARY
[0006] This summary is provided to introduce concepts related to Basel testing and validation, and the concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0007] In one implementation, a computer implementable method for Basel testing and validation is provided. In one implementation, the method includes fetching financial data, pertaining to a financial institution from a data warehouse, calculating at least one of a risk requirement and a market risk based on the fetched financial data, where the risk requirement and the market risk are calculated in conformance to Basel Accords. Furthermore, the method includes comparing at least one of the calculated risk requirement and the market risk with at least one reference value in order to ascertain differences therein.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
[0009] Fig. 1 illustrates a network environment implementing a Basel testing and validation system, in accordance with an implementation of the present subject matter.
[00010] Fig. 2 illustrates a Basel testing and validation system for validating data stored in a data warehouse, in accordance with an implementation of the present subject matter.
[00011] Fig. 3 illustrates a method for Basel testing and validating in a data warehouse, in accordance with an implementation of the present subject matter.

[00012] Figs. 4a and 4b illustrate screenshots of a graphical user interface of the Basel testing and validation system, in accordance with an implementation of the present subject matter.
DETAILED DESCRIPTION
[00013] Systems and methods for Basel testing and validation are described herein. The systems and methods can be implemented in a variety of computing devices, such as, laptops, desktops, workstations, tablet-PCs, smart phones, notebooks or portable computers, tablet computers, mainframe computers, mobile computing devices, entertainment devices, computing platforms, internet appliances and similar systems. Although the description herein is with reference to certain networks, the systems and methods may be implemented in other networks and devices, albeit with a few variations, as will be understood by a person skilled in the art. [00014] Data warehouses are utilized by many organizations and government agencies to consolidate data from across the organization with a single consistent historical view. These data warehouses are generally optimized for reporting and analysis. The data warehouses collect and organize data for performing various functions, say strategic decision making. For storing the data in these data warehouses the data is generally extracted over a period of time from various sources, such as transaction systems and databases. Upon extraction of the data, business rules can be associated with said extracted data, and subsequently the extracted data can be transformed into a format consistent with the data warehouse, where the transformed data is loaded.
[00015] In Basel testing projects, data utilized for said projects and data subsequently generated therein, are generally stored in the data warehouses. This data can be vast and complex in nature, due to which rigorous, repetitive, and stringent quality checks need to be executed in order to ensure adherence to one or more rules or conditions as specified within Basel Accords. The Basel Accords are a set of agreements set by the Basel Committee on Bank Supervision (BCBS), which provides recommendations on banking regulations in regards to capital risk, market risk and operational risk. Therefore, a financial institution will generally adhere to the guidelines specified by the Basel Accords in calculating their capital risk, market risk and operational risk. The purpose of the Basel Accords is to ensure that financial institutions have sufficient capital on account to meet obligations and absorb unexpected losses. Furthermore, the

Basel Accords are designed to encourage greater uniformity in the way financial institutions approach risk management on an international level. Therefore, financial institutions worldwide must strive to operate in conformance with the Basel Accords.
[00016] Due to the volume of the data that is extracted, transformed, and stored, errors can be incurred during the process of moving data from a source (e.g., database) to a target (e.g., data warehouse). The errors can arise due to different reasons, such as incorrect implementation of business rules and errors during migration processes. Ensuring quality of the extracted and transformed data requires recurrent checks and validations. Furthermore, in order to minimize these errors, data warehouses incorporate data testing processes, where the data stored therein can be validated, for example, for integrity and completeness. Testing and validation of data is critical for the success of a data warehouse project, as users need to rely on the quality of the data stored therein.
[00017] Conventional methods involve defining test categories in order to validate the data in the data warehouses for record counts (expected vs. actual), duplicate checks, reference data validity, and referential integrity. Once the test categories have been defined, one or more test cases can be formed based on the test categories. The test cases may be executed to validate the data. Test cases can be defined as a set of inputs, execution conditions, and expected results developed for a particular objective, such as to verify compliance with a specific requirement. Therefore, based on the type of data stored in the data warehouse, specialized test cases need to be designed and executed. Furthermore, in Basel testing projects, ensuring the quality of the extracted and transformed data requires a substantially high number of recurrent checks and validations, which is a time consuming task. Moreover, regression testing of the data is necessary, which can be manpower intensive. Usually, the data migrates through different databases, so the testing has to be done by connecting to multiple databases and manually extracting data and checking business rules if imposed properly can be time consuming. Furthermore, the risk calculation tasks in these Basel testing projects, such as the capital risk and market risk calculations as mentioned earlier, can also be very complex. Generally, users perform these calculations with the help of Excel sheets using complex formulae, which in itself is substantially slow and error prone. Furthermore, manually ensuring conformance with the Basel Accords is substantially effort and time intensive.

[00018] The present subject matter describes systems and methods for Basel testing and validation in a data warehouse. In one implementation, the Basel testing and validation system can be configured to utilize validated Basel data from the data warehouse in order to perform Basel testing project calculations, such as capital and market risk calculations. The Basel testing and validation system can be further configured to perform the above risk calculations along guidelines specified in the Basel Accords. In one implementation, the Basel testing and validation system can be configured to compare results from the above mentioned risk calculations with certain known or actual reference values to ascertain a difference or deviation from the reference values. In one example, these known reference values can be results obtained from a third party risk engine performing similar risk calculations in adherence to the guidelines specified in the Basel Accords. The third party risk engine can be implemented at a third party server, such as that of a financial institution, configured to perform various risk calculations. The risk calculations can include, but is not limited to, credit risk, liquidity risk, market risk, operational risk, and insurance risk. The validation of the data can be based on a plurality of criteria, such as integrity and completion checks of data that is extracted, transformed and loaded into the data warehouse. In one implementation, the Basel testing and validation system allows for a user to create one or more test cases for validating the data in the data warehouse. In one example, the test cases can be a group of queries, which can be used to query the data to indicate a quality of the data stored therein. Furthermore, the Basel testing and validation system facilitates an execution of the test cases from multiple points within the Basel testing and validation system.
[00019] In one implementation, the Basel testing and validation system includes a Risk Weighted Asset (RWA) validator and a market risk calculator. The RWA validator can be configured for performing testing, such as Basel II testing, where said RWA validator can be configured to utilize validated Basel data in order to perform said Basel testing in conformance to the Basel Accords. Furthermore, the RWA validator can be configured to calculate risk requirements for capital calculation of a financial institution, and can be further configured to compare the calculated risk requirements with a reference RWA calculation, to check for differences if any. In one example, the reference RWA calculation can be obtained from the risk engine as disclosed earlier.

[00020] In one implementation, the market risk calculator can be configured for calculation of market risks along the guidelines specified in the Basel Accords. For example, the market risk calculator can be configured to utilize financial data from the data warehouse that has been validated, in order to perform the market risk calculations in conformance to the guidelines specified in the Basel Accords. In another example, the market risk calculator can be configured to compare results of said market risk calculation with one or more reference values to display differences, if any. In said example, the reference values of market risk calculations can be obtained from the risk engine as provided earlier.
[00021] In one implementation, in order to validate the data stored in the data warehouses, such as financial data, the Basel testing and validation system includes an in-built query builder and data repository. The query builder may be used to create a test case, according to a testing scenario, which further depends on the type of data to be tested. Generally, a test scenario refers to an overall workflow or process regarding one or more transactions. For example, a test scenario might be "using an ATM". The usage of an ATM can involve a series of steps, such as enquiring a bank balance, depositing a cheque, and withdrawing or depositing cash. There can be various stages of transactions in this scenario, and the test cases may be created based on an analysis of the above test scenario. In one implementation, the Basel testing and validation system can store the test cases, for example, in the in-built data repository, hereinafter referred to as a test case repository, for easy access and execution of the test cases at any given instance. Furthermore, in one implementation, the Basel testing and validation system can be interfaced to a plurality of types of databases and operating systems, thereby imparting enhanced adaptability and flexibility to the Basel testing and validation system. The test cases can then be executed on any of these databases and operating systems in order to validate the data stored therein.
[00022] In one implementation, during operation, the Basel testing and validation system may be interfaced with a source data system, such as an operational database. The Basel testing and validation system can then be configured to query a target data within the source data system. The target source data can subsequently be associated with customizable business rules, and then transformed based on the associated business rules into a particular format in order to migrate the data into the data warehouse. The data warehouse in this case, may be referred to as a destination data system. The data validation that is carried out at this stage involves the query builder generating a further test case for validating or querying the data in the destination data system.

The validation can include integrity and completeness checks on the target data, to verify if the data has been properly migrated with the proper implementation of the business rules.
[00023] In one implementation, the Basel testing and validation system can be configured to access previously stored test cases in the test case repository in order to validate data in Basel testing projects having a similar test scenario. In an example, the test cases may be modified as required using the query builder, and executed in the data system, i.e., either the source data system, the destination data system (the data warehouse) or a combination thereof. By facilitating a storage and easy accessibility of said stored test cases, the present subject matter provides a substantially high degree of reusability. Moreover the Basel testing and validation system according to the present subject matter provides a substantially high degree of flexibility and adaptability with various databases and data systems. The Basel testing and validation system according to the present subject matter provides an effective framework with which to monitor data accuracy, completeness and consistency on an ongoing basis that substantially automates the data validation process in a data warehouse. As a result, manual effort required to maintain and validate the data warehouses is also substantially reduced. Furthermore, according to the present subject matter, providing said degree of automation can not only improve timelines for data warehousing, but also substantially increases confidence on the quality of Basel data stored in the data warehouses.
[00024] In one implementation, according to the present subject matter, the Basel testing and validation system is provided with a convenient and easy to understand graphical user interface (GUI). In an example, the GUI may include but is not limited to, a home page, a user configuration page, a database configuration page, a file configuration page, a report configuration page, a password management page, a test case module page, an RWA module page, and a market risk module page.
[00025] These and other advantages of the present subject matter would be described in greater detail in conjunction with the following figures. The present subject matter is specifically described with the perspective of Basel Accords. However, validating data to ascertain whether the data conforms to other types of accords would be within be within the scope of the present subject matter. While aspects of described systems for data validation in data warehouses can be implemented in any number of different computing systems, environments, and/or

configurations, the embodiments are described in the context of the following exemplary system(s).
[00026] Fig. 1 illustrates a network environment 100 implementing a system for Basel testing and validation, according to an implementation of the present subject matter. Hereinafter, the system for Basel testing and validation may be referred to as a Basel testing and validation system 102. In the network environment 100, the Basel testing and validation system 102 is connected to a network 104. Moreover, a source data system 105, a destination data system, and an extraction, transformation, and loading (ETL) system 107 are also connected to the network 104. In one implementation, the destination data system can be implemented as a data warehouse 106. Furthermore, one or more client devices 108-1, 108-2...108-N, collectively referred to as client devices 108, are also connected to the network 104.
[00027] The Basel testing and validation system 102 can be implemented as any computing device connected to the network 104. For instance, the Basel testing and validation system 102 may be implemented as mainframe computers, workstations, personal computers, desktop computers, multiprocessor systems, laptops, network computers, minicomputers, servers and the like. In addition, the Basel testing and validation system 102 may include multiple servers to perform mirrored tasks for users, thereby relieving congestion or minimizing traffic.
[00028] Furthermore, the Basel testing and validation system 102 is connected to the client devices 108 through the network 104. Examples of the client devices 108 include, but are not limited to personal computers, desktop computers, smart phones, PDAs, and laptops. Communication links between the client devices 108 and the Basel testing and validation system 102 are enabled through a desired form of connections, for example, via dial-up modem connections, cable links, digital subscriber lines (DSL), wireless or satellite links, or any other suitable form of communication.
[00029] Moreover, the network 104 may be a wireless network, a wired network, or a combination thereof. The network 104 can also be an individual network or a collection of many such individual networks interconnected with each other and functioning as a single large network, e.g., the internet or an intranet. The network 104 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet and such. The network 104 may either be a dedicated network or a shared

network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), etc., to communicate with each other. Further, the network 103 may include network devices, such as network switches, hubs, routers, host bus adapters (HBAs), for providing a link between the Basel testing and validation system 102 and the client devices 108. The network devices within the network 104 may interact with the Basel testing and validation system 102 and the client devices 108 through communication links.
[00030] In one implementation, the Basel testing and validation system 102 includes a Risk Weighted Asset (RWA) module 112. RWAs are generally a financial institution's assets or off-balance sheet exposures, weighted according to risk. In one implementation, the RWA module 112 can be configured to utilize data, such as financial data, to calculate capital risk requirements of a financial institution. For example, the RWA module 112 can utilize validated data, from the data warehouse 106, to calculate the capital risk requirements of the financial institution in conformance to guidelines specified in the Basel Accords. The RWA module 112 can further be configured to compare results from the calculation of the capital risk requirements with reference RWA data to check for differences or deviations. In one implementation, the reference RWA data can be an output of a third party risk engine configured to calculated a capital risk requirement along the guidelines specified in the Basel Accords.
[00031] In one implementation, the Basel testing and validation system 102 includes a market risk module 114. In one implementation, the market risk module 114 can be configured to determine a market risk, in conformance to the Basel Accords, for example of a financial institution by utilizing validated data from the data warehouse 106. Market risk is generally the risk that the value of a portfolio faces due to market risk factors, such as stock prices, interest rates, foreign exchange rates, and commodity prices. Financial data pertaining to these market risk factors can be stored and updated in the data warehouse 106. Furthermore, in one example, the market risk module 114 can be configured to fetch such data from the data warehouse 106 and perform the market risk determination thereof. Moreover, in one implementation, the market risk module 114 can be configured to compare the determined market risk and at least one reference value to ascertain differences if any. In one example, the at least one reference value can be the value obtained from the output of the third party risk engine as disclosed earlier.

[00032] In one implementation, the user may utilize the client devices 108 to access and control the RWA module 112 and the market risk module 114. In one example, the user may specify certain rules and constraints with which to perform the capital risk calculations. In one implementation, the user may select the source data system 105 and/or the data warehouse 106 to validate the data therein, through the client devices 108 via the network 104. The manner in which the Basel testing and validation system 102 performs the Basel testing and validates the data stored in the data warehouse 106 is further described in conjunction with fig, 2.
[00033] Fig. 2 illustrates the Basel testing and validation system 102, in accordance with an implementation of the present subject matter. In said implementation, the Basel testing and validation system 102 includes one or more processor(s) 202, interface(s) 204, and a memory 206 coupled to the processor 202. The processor 202 can be a single processing unit or a number of units, all of which could also include multiple computing units. The processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 202 is configured to fetch and execute computer-readable instructions and data stored in the memory 206.
[00034] The interfaces 204 may include a variety of software and hardware interfaces, for example, interface for peripheral device(s), such as a keyboard, a mouse, an external memory, and a printer. Further, the interfaces 204 may enable the Basel testing and validation system 102 to communicate with other computing devices, such as web servers and external data repositories in the communication network (not shown in the figure). The interfaces 204 may facilitate multiple communications within a wide variety of protocols and networks, such as a network, including wired networks, e.g., LAN, cable, etc., and wireless networks, e.g., WLAN, cellular, satellite, etc. The interfaces 204 may include one or more ports for connecting the Basel testing and validation system 102 to a number of computing devices. In one implementation, the data validation system 102 can be interfaced with the other computing devices with Open Database Connectivity (ODBC) drivers.
[00035] The memory 206 may include any computer-readable medium known in the art including, for example, volatile memory such as static random access memory (SRAM) and

dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory 206 also includes module(s) 208 and data 210.
[00036] The module(s) 208 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. In one implementation, the module(s) 208 includes the RWA module 112, the market risk module 114, a query generation module 212, a data validation module 214, and other module(s) 216. The other module(s) 216 may include programs or coded instructions that supplement applications and functions of the Basel testing and validation system 102.
[00037] On the other hand, the data 210, inter alia serves as a repository for storing data processed, received, and generated by one or more of the module(s) 208. The data 210 includes for example, risk data 218, query generation data 220, data validation data 222, and other data 224. The other data 224 includes data generated as a result of the execution of one or more modules in the module(s) 208.
[00038] In one implementation, the Basel testing and validation system 102 can be configured for Basel testing and validation purposes. The Basel testing includes performing certain risk calculations in conformance to the guidelines specified by the Basel Accords, and comparing said calculations with one or more reference values in order to ascertain differences therein. In one implementation, the reference values can be the output of a third party risk engine as provided earlier. The third party risk engines can be configured for example, at an external financial institution server (not shown in figure), to perform various risk calculations. The risk calculations can include, but is not limited to, credit risk, liquidity risk, market risk, operational risk, and insurance risk. The validation of data, such as financial data, can include but is not limited to validating the financial data stored in the data warehouse 106 for integrity, completeness, etc. Furthermore the Basel testing and validation system 102 can further be configured to validate results of the risk calculations in the data warehouse 106.
[00039] In one implementation, the RWA module 112 can be configured to calculate risk requirements based on Risk Weighted Asset (RWA) calculations. RWAs are generally a financial institution's assets or off-balance sheet exposures, weighted according to risk. In one example, the RWA data can be stored in the data warehouse 106. In one example, the RWA

module 112 can be configured to calculate the risk requirements based on an asset class, to which the data belongs to. In another example, the RWA module 112 can be configured to provide a result based on a calculation for a term loan asset class. In an example, the RWA module 112 can be configured to cater to Basel II Accords, where the RWA module 112 can be configured to calculate risk requirements based on the RWA data from the data warehouse 106, and further be configured to compare results from the calculation of the capital risk requirements with at least one reference value. In one example, the reference value can be obtained from the output of the third party risk engine as disclosed earlier. In a further example, based on a predetermined threshold value, the reports generated from said comparison can be shown as "Pass" or "Fail", indicating whether or not the risk requirements are in conformance to the Basel Accords or not. In one implementation, the RWA module 112 can be configured to store the risk requirements in the risk data 218 or the other data 224. The RWA module 112 can further be configured to fetch the stored risk requirements at a later stage based on the requirements of the user.
[00040] In one implementation, the market risk module 114 can be configured to determine a market risk, say for a financial institution, according to the guidelines specified in the Basel Accords. In one example, the market risk module 114 can be configured to fetch required financial data from the data warehouse 106 to perform said determination of the market risk. Once the data is fetched, the market risk module 114 can be configured to perform calculations such as validations for return, market price etc. Furthermore, the market risk module 114 can be further configured to compare the market risk with at least one actual value. In one example, the actual value can be obtained from the output of the third party risk engine as provided earlier. In one example, the market risk module 114 can be configured to generate a report based on said comparison and provided to the user, and stored in the risk data 218 or the other data 224. The report thus generated can be informative to the user on a possible deviation of the calculated market risk from the actual value.
[00041] In one implementation, the Basel testing and validation system 102 can be configured to validate Basel data (hereinafter interchangeably referred to as simply data) in the data warehouse 106 based on rules specified by a user. In order to validate the Basel data in the data warehouse 106, the Basel testing and validation system 102 can be configured to form test cases depending on a test scenario. In one implementation, the query generation module 212 can be

configured to create the test scenario, where the user may specify a mandatory set of inputs. In one implementation, once the test scenario is created, the rules pertaining to the test scenario can be stored in the query generation data 220.
[00042] In one example, the test case can include multiple test queries. The test queries can rely on an analytical approach to validating the Basel data stored in the data warehouse 106. For example, the test queries may fall under various test categories, such as, data completeness and data transformation. Data completeness verifies that the data has been entirely loaded from the source data system 105 to the data warehouse 106, and data transformation verifies that business rules specified by the user have been correctly implemented.
[00043] Furthermore, in one implementation, the query generation module 212 is configured to generate the test queries. In an example, the test query can be in the form of an SQL query. The query generation module 212 can be configured to provide the user with a list of functions in order to effectively generate a test query based on the type of data that needs to be validated. In one implementation, the test queries thus generated can be stored in the query generation data 220. In another example, the test queries can be stored in a data repository, such as a MYSQL® database integral or external to the Basel testing and validation system 102.
[00044] Furthermore, in one example, the Basel testing and validation system 102 may be interfaced to one or more source data systems 105, such as an online transaction processing (OLTP) database. Furthermore, the extraction, transformation, and loading (ETL) system 107, can be configured to extract data of interest from one or more of the source data systems 105. In one implementation, the Basel testing and validation system 102 can include an extraction module (not shown in figure), configured to extract the data of interest from the one or more source data systems 105. In one example, extraction module of the Basel testing and validation system 102 can be configured to extract data irrespective of file format, i.e., fixed length files and delimited files can be extracted by the extraction module. Each of the source data systems might not utilize the same data format or organizational structure. The ETL system 107 can be configured to extract data from source data systems of various data formats and organizational structure and convert said data into a standardized format for transformation processes. The transformation process can include but is not limited to parsing, standardization, aggregation, cleansing, reformatting, or application of one or more business rules. These business rules are

generally associated with the data during the transformation stage in the ETL system 107, where the business rules define the manner in which the data must be transformed before loading into a target database, such as, the data warehouse 106. In one example, for a customer details table in the source data system 105, which needs to be migrated to the data warehouse 106, the user may specify a business rule to combine a customer name field and a customer address field. Upon transformation, the ETL system 107 may load the transformed data into the data warehouse 106.
[00045] In one implementation, the data validation module 214 can be configured to compile the test queries generated by the query generation module 212, to form one or more test cases. For example, the data validation module 214 can be configured to fetch the test queries from the query generation data 220 and subsequently compile the test queries. Furthermore, in one implementation, the data validation module 214 can be configured to execute the test cases at one or more specified locations in the data systems. For example, the user can choose to execute the test cases either in the source data system 105 after extraction and before transformation, after transformation in the ETL system 107 and before loading in the data warehouse 106, in the data warehouse 106 after loading, or in any combination thereof. In an example, the data validation module 214 can be configured to check completeness and integrity of the data before association of the business rules during the transformation of the data. Moreover, the data validation module 214 can be configured to verify correct implementation of the business rules while transforming the data. Furthermore, in another example, the data validation module 214 can be configured to check the completeness and integrity of the data in the data warehouse 106 after transformation and loading in the data warehouse 106.
[00046] The data validation module 214 can be configured to store the test cases in a data repository, such as the data validation data 222. In one example, the data validation module 214 can be configured to access the stored test cases in the data validation data 222. Therefore, the test cases can be stored, accessed, modified and reused depending on the requirement of the data validation process. For example, for regression testing purposes, the test cases can be easily accessed by means of the data repository, modified as per the requirement of the test scenario, and executed in the target location as described earlier. In this manner, a substantially high degree of re-usability of the test cases can be provided by the present subject matter, thereby reducing the need to re-create test cases for each case of data validation. This further reduces testing times, manual labor, and chances of errors during the data validation process. In order to

cater to the substantially high quality control procedures of the Basel testing process, in one implementation, the data validation module 214 can be configured to upload the test cases to a quality management system, where said quality management system can be provided with predetermined parameters in order to assess the quality of the uploaded test cases.
[00047] In one implementation, the data validation module 214 can be configured to create a summary or report containing results of the test case execution as described above. In one example, the data validation module 214 can be configured to create a summary report and a detailed report. For example, if a test case pertaining to the completeness of data is executed in the data that is loaded in the data warehouse 106, the data validation module 214 can be configured to extract a summary or report of the test case execution. In one example, the detailed report can include details relating to test case statistics, such as number of entries tested, number of data mismatches, time taken to execute the test case, date and time of the test case and an overall quality of the loaded data. In another example, the user can specify an output format of the report, for example in Hyper Text Markup Language (HTML) or an excel format. In one implementation, the data validation module 214 can be configured to store the reports in the test case data 222.
[00048] Fig. 3 illustrates a method 300 for testing and validating Basel data stored in the data warehouse 106, according to one implementation of the present subject matter. The method 300 may be implemented in a variety of computing systems in several different ways. For example, the method 300, described herein, may be implemented using the Basel testing and validation system 102, as described above.
[00049] The method 300, completely or partially, may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. A person skilled in the art will readily recognize that steps of the method can be performed by programmed computers. Herein, some embodiments are also intended to cover program storage devices, e.g., digital data storage media, which are machine or computer readable and encode machine-executable or computer-executable programs of instructions, wherein said instructions perform some or all of the steps of the described method 300.

[00050] The order in which the method 300 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method, or an alternative method. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof. It will be understood that even though the method 300 is described with reference to the Basel testing and validation system 102, the description may be extended to other systems as well.
[00051] At block 302, data can be fetched from the data warehouse 106, pertaining to a financial institution. For example, financial data relating to the financial institution can be fetched from the data warehouse 106 in order to perform a Basel testing project. In one example, the Basel testing project can involve performing calculations to ascertain a capital risk requirement of the financial institution with regard to the guidelines specified in the Basel Accords. The Basel testing project can further include determining a market risk of the financial institution with regard to guidelines specified in the Basel Accords.
[00052] At block 304, a Risk Weighted Asset (RWA) based calculation can be performed in order to calculate a capital risk requirement, for example, of a financial institution's off-balance sheet exposure. For example, an RWA module 112 of a Basel testing and validation system 102 can be configured to utilize the fetched financial data to perform the RWA calculation. In one example, the calculation of the risk requirement can be dependent on an asset class. In one example, the results thus obtained can be stored in a risk data 218 of the Basel testing and validation system 102.
[00053] At block 306, calculated capital risk requirement can be compared with at least one reference value, for example, the RWA related capital risk calculation performed by the third party risk engine as disclosed earlier, in conformance to the Basel Accords. According to this comparison, it can be ascertained whether the financial institution is at risk or not with regard to the guidelines specified in the Basel Accords. For example, the RWA module 112 of the Basel testing and validation system 102 can be configured to generate a report of the comparison, indicating whether the comparison has "passed" or "failed" with regard to the reference value. Furthermore, this report can be stored in an internal or external data repository for further

reference. In one example, the report can be stored in the risk data 218 of the Basel testing and validation system 102.
[00054] At block 308, based on the financial data fetched from the data warehouse 106, a market risk of the financial institution can be determined. The market risk of a financial institution can be described as the possible fluctuations of a portfolio of the financial institution, with regard to market risk factors. The market risk factors generally involve stock prices, interest rates, foreign exchange rates, and commodity prices. Based on the trends exhibited by each of these market risk factors, the market risk of the financial portfolio of the financial institution can be determined. In one example, the market risk of the financial institution can be determined according to the guidelines specified in the Basel Accords. In one example, a market risk module 114 of the Basel testing and validation system 102 can be configured as described earlier, to determine the market risk of the financial institution based on the fetched financial data. The market risk module 114 can also be configured to store the determined market risk in a data repository, such as the risk data 218.
[00055] At block 310, it is ascertained by comparison between the market risk determined in block 308 and at least one actual value, whether there is any difference between the two. In one implementation, as disclosed earlier, the actual value can be the result obtained from the third party risk engine. Furthermore, based on a predetermined threshold value, the compared value can be classified accordingly. The differences thus obtained can be provided in the form of a report, which can be stored in a data repository for further reference. In one example, the market risk module 114 of the Basel testing and validation system 102 can be configured to generate the report of the comparison disclosed above.
[00056] In one implementation (not illustrated in fig. 3) of the method according to the present subject matter, the Basel data stored in the data warehouse 106 can also be validated in a manner described earlier. The data generated from such Basel testing projects is often subject to rigorous quality control and validation to ensure conformity with the Basel Accords. Due to the vast quantities of data generated from such projects, the stringent testing of the same can be a time and effort intensive task. The financial data stored in the data warehouse 106 can primarily be regression tested for inconsistencies and errors before the data is utilized for the Basel testing projects. Moreover, the results thus generated from the Basel testing projects can be regression

tested for quality and conformance with the Basel Accords. According to the present subject matter, an efficient, accurate and flexible testing and validation methodology is provided, by which manual effort, probability of error, testing times are substantially reduced. Furthermore, even though the present subject matter has been explained with respect to the risk requirement and the market risk calculations, the concept of the present subject matter can be extended to various other risk calculations adhering to the Basel Accords. For example, according to the output of the third party risk engine, the Basel testing and validation system 102 can be modified, and suitable frameworks for performing such additional calculations thereof, can be catered to.
[00057] Therefore, in cases where a regression testing of the Basel data has to be performed, or data validation for the same or similar data has to be performed, test cases from previous Basel testing projects can be obtained, modified as per the requirement and re-executed. Therefore, in this manner, manual effort is substantially reduced and an overall efficiency of the data validation process can be increased.
[00058] In one implementation, the present subject matter provides a simple and easy to understand graphical user interface (UI). The graphical UI is designed to provide an easy control of the Basel testing and validation system 102, by a user of average computing skill. Various options indicative of the different functions of the Basel testing and validation system 102 is presented to the user to run the Basel testing and validation system 102.
[00059] Figs. 4a and 4b illustrate screenshots of a graphical user interface of the Basel testing and validation system 102, in accordance with an implementation of the present subject matter.
[00060] Fig. 4a illustrates a home page of the Basel testing and validation system 102. The home screen preliminary serves as a navigation point to other modules of the Basel testing and validation system 102. Fig. 4a illustrates an RWA calculator, where the user may utilize said calculator to perform risk based calculations in the manner described earlier. Fig. 4b illustrates, a market risk calculator, where the user can utilize said calculator to perform market risk calculations in the manner described earlier.
[00061] In a further examples (not shown), various other navigational aids and GUI implementations can be provided. In one example, a home screen can be provided, which contains navigation keys that facilitate efficient navigation between the various modules in the Basel testing and validation system 102. In one example, a user with administrator privileges on

the Basel testing and validation system 102 can add and edit users. In one example, the user can edit access privileges of other users through the user configuration page. Furthermore, a database configuration page can be provided, where the user can configure connectivity of the Basel testing and validation system 102 with one or more other systems. In one example, the user can configure the connectivity of the Basel testing and validation system 102 with the MSQL® database, where the test cases for Basel validation can be stored. In yet another example, a file configuration page can be provided, where in one example, the user can set fixed length file header and footer information and also delimit file information. In a further example, a report configuration page can be provided, where the user can select a report path, i.e., the destination folder where the testing and validation reports can be generated, and also a format in which the reports can be generated. In one example, a password management page can be provided, where in one example, the user can edit access credentials, such as user names and passwords. In a further example, a test case module page can be provided, where the user can create, store, access, modify and execute test cases in the Basel testing and validation system 102.
[00062] Although implementations of Basel testing and validation for data warehouses have been described in language specific to structural features and/or methods, it is to be understood that the present subject matter is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as implementations for Basel testing and validation in a data warehouse.

I/We claim:
1. A computer implementable method to test and validate Basel data, the method comprising:
fetching financial data, pertaining to a financial institution, from a data warehouse;
calculating at least one of a risk requirement and a market risk based on the fetched financial data, wherein the risk requirement and the market risk are calculated in conformance to Basel Accords; and
comparing at least one of the calculated risk requirement and the market risk with at least one reference value in order to ascertain differences therein.
2. The computer implementable method as claimed in claim 1, wherein the comparing
further comprises:
categorizing the calculated risk requirement as one of a "pass" and "fail" based on a configurable threshold value; and
analyzing the difference between the calculated market risk and the at least one actual value based on a predetermined threshold value to ascertain deviation from the at least one actual value.
3. The computer implementable method as claimed in claim 2, wherein the at least one actual value is an output obtained from a risk engine of a Basel testing project.
4. The computer implementable method as claimed in claim 1, wherein the method further comprises validating the financial data in the data warehouse, wherein the validating comprises:
generating at least one test query based on a testing scenario;
compiling the at least one test query to form at least one test case;
storing the at least one test case in a data repository for subsequent utilization;
selecting one of the stored test cases based on fresh data to be validated; and
modifying and executing the selected test case.
5. A Basel testing and validation system (102) comprising:

a processor (202); and
a memory (206) coupled to the processor (202), the memory (206) comprising:
a Risk Weighted Asset (RWA) module (112) configured to:
calculate a risk requirement, based on financial data, and in conformance to Basel Accords; and
compare the calculated risk requirement with a reference RWA calculation in order to ascertain differences therein; and
a market risk module (114) configured to:
determine a market risk, based on financial data, and in conformance to the Basel Accords; and
analyze the determined market risk with respect to at least one reference value in order to ascertain differences therein.
6. The Basel testing and validation system (102) as claimed in claim 5, wherein the reference RWA calculation and the at least one reference value is an output value of a risk engine of a Basel testing project, and wherein the risk engine is external to the Basel testing and validation system (102).
7. The Basel testing and validation system (102) as claimed in claim 5, wherein the RWA module (112) is further configured to categorize the calculated risk requirement as one of a "pass" and a "fail" based on a configurable threshold value.
8. The Basel testing and validation system (102) as claimed in claim 5, further comprising a query generation module (212) configured to generate at least one test query based on a testing scenario.
9. The Basel testing and validation system (102) as claimed in claim 5, further comprising a data validation module (214) configured to:
compile the at least one test query to form at least one test case; and
store the at least one test case in a data validation data (222) for access, modification and re-execution thereof.

10. The Basel testing and validation system (102) as claimed in claim 5, wherein the data validation module (214) is further configured to create a report based on the test case execution, wherein the report comprises at least one of a time taken for the execution of the test, date of the test case execution, number of entries tested, overall quality of the data validation, type of data validation, and the location of the test case execution.
11. A computer-readable medium having embodied thereon a computer program for executing a method comprising:
fetching financial data, pertaining to a financial institution, from a data warehouse;
calculating at least one of a risk requirement and a market risk based on the fetched financial data, wherein the risk requirement and the market risk is calculated in conformance to Basel Accords; and
comparing at least one of the calculated risk requirement and the market risk with at least one reference value in order to ascertain differences therein.