Traditional design approaches commonly referred as Black Box and White Box, can be described as two ends of a spectrum, where business users, either have their hands completely tied or have just too many configurations to manage. In either case, there is significant effort on the business user to manage and adhere to regulatory changes.
The need of the hour is to think out-of-the-box and come up with a design approach which uniquely blends the traditional approaches and provides business users with the right amount of flexibility and aims at significantly reducing the business user effort.
In this unique approach, the data is pushed to the reporting solution as is (similar to White Box approach), but the Fintellix configuration engine helps business users to map and configure conditions to a pre-defined reporting taxonomy (similar to the Black Box approach), thereby eliminating the need to have the configurations defined and applied at each reporting line.
With the above approach, the business users would have a consolidated view of all the business configurations at a single interface and once the configurations are set up, they only need to generate the reports and proceed with the submission process.
Integration of various systems that house bank’s data. E.g., Core Banking, Treasury Systems, Ledger Data, Trade, Loans etc.
Accommodation of external datasets from multiple flat-files. The file formats could be xls, xlsx, csv etc.
Experience of working with various Source Systems.
Unique blend of techno-functional banking experts with an excellent understanding of regulatory reporting landscape.
The Fintellix Glass Box approach is the most optimal approach to design, develop and implement a regulatory reporting solution.
Business logic can be defined and mapped to the relevant reporting taxonomy, thereby
passing the liability to the reporting solution and not outside of the solution.
One place to manage all business configurations, thereby reducing the overhead of
managing configurations for each reporting line across different reports.
Reporting teams of any size can manage the solution effectively as there are
significantly lesser number of configurations to manage.
Existing/newer configurations need to be defined at one place and the entire report
generation process downstream is taken care of automatically.
As the source data is not tweaked and available for business users to consume, the
solution can easily be extended to other reporting needs of the entity.
In a Black Box approach, the design provides for a pre-defined taxonomy, against which the data needs to be pushed to the reporting solution. The taxonomy is defined as per the business criteria mentioned by regulators across all reporting forms.
The business logic to identify and map data from different data sources, to the solution specific taxonomy, remains outside of scope of the reporting solution.
In a nutshell, the overall solution behaves like an aggregation platform, where the values are rolled-up basis the pre-defined taxonomy and associated with the end reporting outcome.
Various systems that house banks data. E.g, Core Banking, Treasury Systems, Ledger Data, Trade, Loans etc.
Can also include external datasets from various flat files. The format can be xls, xlsx, .txt, xml etc.
Experience of integrating with disparate source systems
A blend of techno-functional banking experts with a good understanding of regulatory reporting landscape
The Black Box Approach offers low transparency to business users on the underlying business logic and thereby increases the difficulty of extending the solution for accommodating future regulatory updates.
As the solution expects a predefined taxonomy, the business terminology that each
reporting entity understands is still outside of the system.
Significant manual effort or additional internal processes need to be defined to
constantly monitor the data mapping to the reporting taxonomy.
It becomes a tedious task, as any new changes requested by regulators would need a
new taxonomy, thereby disrupting the entire report submission process.
Business users will find it cumbersome to identify which reporting taxonomy refers to
which business rule internally, and thereby causes a lot of confusion.
In a White Box Approach, the design is primarily aimed at providing business users with a platform that empowers them to have any level of reporting generated out of the solution. The data is pushed to the reporting solution, as is from the respective data sources, and the solution then provides for maintaining historical cuts of data, by incorporating logical relationships across various entities.
Once the data is pushed to the solution, the business users have the flexibility to define, their own business definitions/configurations across various reporting lines, in-line with the regulatory requirements, and proceed with reporting submissions.
Various systems that house banks data. E.g, Core Banking, Treasury Systems, Ledger Data, Trade, Loans etc.
Can also include external datasets from various flat files. The format can be xls, xlsx, .txt, xml etc.
Experience of integrating with disparate source systems.
A blend of techno-functional banking experts with a good understanding of regulatory reporting landscape.
The White Box Approach is least efficient as it fails to take advantage of reusability of business rules. It also makes the reconciliation less certain.
Each reporting line must be configured with a definite business logic, which forces business users to constantly monitor and validate configurations for each reporting line.
As the configurations are to be performed independently for each reporting line, ensuring reconciliation between reporting lines configured by different business team becomes more challenging
Absence of reusability of business rules results in a linear increase in configuration efforts required to accommodate the regulatory changes to existing reporting lines as well as the introduction of new reporting lines.
Increased configuration efforts also increases the effort for maintaining the configurations. This increases the manpower requirement for maintenance activities.