The Argus Glass Box Approach

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 way), but the change kicks in where the Argus configuration engine helps business users to map and configure conditions to a pre-defined reporting taxonomy (similar to the Black Box way), 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.

Is it Recommended?

The Argus Glass Box approach is the most optimal approach to design, develop and  implement a regulatory reporting solution considering:

  • Configurable framework where business logic can be defined and mapped to the relevant reporting taxonomy, thereby passing the onus of computation to the reporting solution and not outside of the solution (as is the case with Black Box Approach)
  • One place to manage all business configurations, thereby reducing the overhead of managing configurations for each reporting line across different reports (as is the case with White Box Approach)
  • Changes can be easily tracked and managed, where existing configurations/newer configurations need to be defined at one place and the entire report generation process downstream is taken care of automatically
  • Reporting teams of any size can manage the solution effectively as there are significantly lesser number of configurations to manage
  • 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 as well.

The Black Box Approach

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.

Is it Recommended?

We believe that a black box approach is not optimal for reporting entities, because of the following observations:

  • As the solution expects a pre-defined 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
  • Change management becomes a tedious task, as any new changes requested by regulator 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 therefore causing a lot of confusion

The White Box Approach

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 relationship 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, albeit inline with the regulatory requirements, and proceed with reporting submissions.

Is it Recommended?

This approach seems highly convenient as it allows near-complete freedom to configure and report data in a manner that best suits the needs. However, the approach has a significant shortcoming in the context of regulatory reporting owing to:

  • Each reporting line needs to have a definite business logic to be defined and configured, thereby adding significant effort on business side in constant monitoring and validations of such configurations
  • Significant risk of duplicating business logic, for similar reporting lines, especially in scenarios where different teams are involved, thereby making the overall reconciliation process a lot more complex
  • Changes to existing reporting lines or addition of new reporting lines would mean a significant number of configurations to be redone
  • Reporting entities with smaller teams will struggle in the maintenance of such configurations.
""
1
TALK TO AN EXPERT
Name
Job Title
Organization
Contact Number
Messagemore details
0 /
Previous
Next
""
1
TALK TO AN EXPERT
Name
Job Title
Organization
Contact Number
Messagemore details
0 /
Previous
Next

Thank you for your interest. One of our experts will get in touch with you shortly.

[[[[]],[[]],"and"]]
1

PLEASE PROVIDE YOUR DETAILS

Name
Job Title
Organization
Contact Number
Downloadyour full name
Previous
Next

Thank you for your interest! A link to download the document you have requested, will be emailed to you shortly. In case you do not see the email in your inbox, please check your spam folder.

""
1

PLEASE PROVIDE YOUR DETAILS

Name
Job Title
Organizationyour full name
Contact Numberyour full name
Download
Previous
Next