Following solvability provisions, which write Basel II into German law, banks are obligated under the framework of applicable disclosure requirements to identify their demand for equity capital based on individual transactions. Also, they are to be aggregated and then transfered in the required disclosure forms to the Bundesbank. In doing so, banks may choose between the standard approach (KSA) and the significantly more complex internal ratings-based approach (IRBA).

The client, a mid-size mortgage bank, employed custom-made software, mentioned here as "equity capital calculator", to identify the demand for equity capital. To fulfill the conditions of the whole group, both the KSA-approach and the IRBA-approach needed to be wholly supported. The test was composed of 23 detailed disclosure forms with a total of about 2,000 blocks to be completed. In order to fill in the disclosure forms, disclosure software (payment solution) was utilized. Through an interface the disclosure software was provided with information pertaining to all of the bank's business operations relevant to equity capital and with the results of the equity capital calculator. In part, the disclosure software calculated the results anew using the entered data and remained a "black box" from the client's perspective.

Challenges

An examination of the forms would be impossible for the business department with the means available to it (very good business know-how but almost no technical skills). This is due to the fact that the forms include only strongly condensed results. The scale and complexity of the forms make manual plausibility assessment very demanding. A solely manual review is practically impossible. Moreover, strict deadlines had to be kept for the delivery and release for production. The availability of resources (regarding both personnel and financials) was very limited.

Solution

The consultants of Finaris put the following solution into practice:

• Development of a business specification for the display of calculation results in the disclosure forms, independent of the utilized disclosure software. The specification is the basis for identifying the filling target of the disclosure forms for any given number of business transactions.
• Realization of the target filling disclosure form based on RapidRep and the business side specification.
• Realization of an automated harmonization between target and performance filling of the disclosure forms supported by RapidRep and a variable RapidRep test report for the display of deviations from individual form spaces. On each disclosure form space the deviations must be exhibited both as a total and based on individual transactions to ensure an efficient error analysis.

The business side specification for the filling in of the disclosure forms based directly on the data of the equity capital calculator was the only possibility for the business department to create an exact target for the illustration of a business transaction. A target for the interface filling of the standard software would not have been viable because the final result - filled in disclosure forms - was to be tested and no intermediate result was available for detecting errors in the standard software.

The consultants of Finaris prepared the business side specification within four weeks of intensive cooperation with the business department. The structuring functionality of RapidRep enabled a redundancy-free implementation of the specification and a clear exposure of the business side requirements in the implementation.

For the purpose of automating the target-performance comparison, summary tables of the disclosure software have been prepared using RapidRep in such a way that it was easily feasible to compare the processed data from the equity capital calculator on the basis of individual transactions.

Success

Notwithstanding intense budget restrictions and an upcoming short-term production launch the test was conducted in remarkably good quality with the support of RapidRep. As opposed to often customary random sampling tests, the entire productive data inventory (that is the entire portfolio relevant to equity capital on the basis of individual transactions) was tested. Thus many errors were detected in the interface to the disclosure software and in the disclosure software itself.

The authors of the report definition were not distracted by technical aspects, but could concentrate purely on the correct business side implementation. After four weeks already the project team was able to focus completely on the analysis of the deviations and on the detection of error causes.

The business case was an example for testing a software process that had the particular difficulty of combining business side and technical complexity. In practice such projects are usually associated with very high costs and risks. By using RapidRep the business and IT departments were now capable of cooperating extremely well. By means of the business side specification the business department always had complete control over the targets for filling in forms. Through the many structuring possibilities offered by RapidRep very complex SQL commands (with partially several hundred lines of code) were very clearly defined. Furthermore, the to-be-implemented logic of the business side specification in the report definition was structurally recognizable almost 1:1 in RapidRep.

Thanks to RapidRep it was possible to decrease the work invested into the test by more than half compared to conventional approaches as the activities were reduced to a minimum and then could be distributed optimally among business and technical personnel.