Decoding the Impact of Changes in the Monetary Authority of Singapore’s Regulatory Reporting Guidelines
- Shivani Venkatesh, Lead Consultant at Fintellix
- 18.06.2015 01:00 am Banking , Shivani Venkatesh is a Lead Consultant at Fintellix and comes with rich experience in Consumer Banking (Channel Management, Proposition Development, Customer Portfolio Management and Segment Strategy). Shivani is currently working with Fintellix’s solutions team in building nextgen banking decision enablement products and solutions.
Singapore’s premier regulator is in the process of finalising the proposed revisions to the MAS 610 (Banks) and MAS 1003 (Merchant Banks) notices. Though the public consultation process concluded in February 2015, the new notices are yet to be issued by MAS. The impact of the proposed changes is expected to be significant and banks have been given 18 months to implement them, with 2 half-yearly reviews.
Some of the key drivers for this widespread change is the demand for more granular data, to ensure consistency across financial and compliance reporting and including new products in the purview of reporting.
The ask for granular data is a consistent change across many of the modifications required. Some examples are – Assets by Country and Counterparty (and Ultimate Borrower) have to be furnished currency wise, and in 7 different currencies. Similarly smaller ticket “Non-Customer Deposit Transaction” details which were earlier bucketed together in the sub- $20,000 slab have been pulled out into 2 new separate slabs. In the Property Loan to Value ratio report for individuals and others, LTV buckets have been increased to 11 as against the earlier 5.
MAS intends to align all reporting with Singapore Financial Reporting Standards (SFRS). In order to do this, banks have been asked to report the Statement of Financial Position (Appendices B1 & B2) in accordance with the Singapore Financial Reporting Standards. Similarly, reporting on fair value of derivatives has been introduced in line with SFRS.
Also, there’s a lot of additional information asked for around Derivatives Reporting indicating the growing importance of this particular class of products. Some examples are – introduction of the Financial Derivatives Turnover Report which requires reporting on foreign exchange and interest rate derivatives by trading channel (E.g. voice, direct electronic, indirect electronic). Similarly Commodity Derivatives now figure as a separate category in the Financial Derivatives Report as against being clubbed in the previously “Others” category.
The impact of the revised notice will be experienced by banks at 3 levels – Data Level, Business Logic change, and Template level as seen below.
While some of the changes may purely be at a business logic level (not having additional data acquisition or template level impact) more often than not, execution of a change might demand additional data acquisition, changes to a template and/or change to an existing business logic.
To implement changes at the data level, banks might have to “go back” to their source systems to acquire additional data or enrich existing data to meet the reporting requirements. Some examples of such requirements are the multidimensional Asset Ageing Report and the Financial Derivatives Transaction Throughput Report.
There are many examples to exemplify the business logic changes that are required. A case in point is the definition change which requires total outstanding for term loans to also include the accrued interest, which in the current regime is reported under “Other Assets”. In this case, there’s no impact on the report format or additional data requirement, but rather a pure business logic change. Another important change from the business logic standpoint is the introduction of the “Ultimate Borrower” concept.
Ultimate Borrower is defined as the party bearing the ultimate risk and control over the counterparty. So for each loan, banks will require identifying the ultimate borrower based on the logic provided by MAS which takes into account the nature of the instrument and the type of the counterparty.
Template level changes could typically reflect additional data being asked for, or for a new representation of data (additional dimensions, more granularity) already being reported. An example of this is the extensive reporting on bad loans that has been included in MAS610. The ageing analyses section requires banks to report on non-performing loans in different “Days Past Due” buckets by counterparty type and purpose. In addition, multidimensional reporting on “Classified Accounts” both in terms of value and volume have been demanded.
Overall, there are significant changes which Singaporean banks need to implement within 18 months. In such a scenario, banks will face challenges from both Data and Reporting perspectives as seen below.
Depending on the way the regulatory reporting solution is designed, the effort involved in implementing these changes could vary significantly. For example, if the regulatory reporting solution acquires and stores only “return specific” data, the underlying data model would need to be upgraded and incremental data acquisition could be significant as compared to a solution that takes a more “banking subject area view” to data storage. Also, if “business logics” are encoded in the data extraction layer, there would be significant dependencies on the technology team for implementing even simple changes and users too would find it challenging to review and approve of changes once implemented. Integration of new source systems or changes in classification logics by the regulator could result in significant regression impact.
While the proposed set of changes to MAS 610 are particularly “high impact”, the on-going changes (externally triggered or internally initiated) are now an integral part of compliance reporting. In this context, flexibility will be critical in enabling banks to comply with the proposed set of changes and other such requirements in future in a minimally disruptive manner. A configurable solution that doesn’t code business logics in the extraction or reporting layer makes sense as it enables users to review and edit business logics and create validation checks as required. Such a solution would make on-going change management faster and relatively easier.
The other critical factor is extensibility. Using the same data infrastructure to meet multiple business and regulatory compliance reporting requirements is a great way to build “trust in data”. While business reporting would typically require historical data to be stored (for trend analyses, predictive modelling, etc.) and presented in a business user friendly nomenclature, compliance reporting would demand data from all areas of the banks’ operation and track data accuracy very closely. Using the same data source for both business and compliance reporting brings together these complementary strengths and builds trust in data. It also minimises reconciliation overheads and enhances user experience.
Given these multiple facets, it makes sense for banks to identify the right technology solution to not only address the current MAS 610 related challenges but also use the opportunity to establish a “future proof” compliance reporting foundation.