Are you still clinging on to your rusty legacy technology that's gracefully aging towards obsolescence? Perhaps you are still running important applications on legacy databases with legacy operating systems because they're "good enough" and still "work fine." In many aspects, your old legacy technologies are like a rusty old car. You know where the kinks are and it gets you where you need to go. But lurking below the surface of that rusty old car and your old technologies can be hidden risks that can result in very big problems, even dangers, usually when least expected.
The world around us is changing rapidly, faster than anyone could have imagined. The Future is Now. The varied forces of disruption are redefining the shape of almost every industry and workplace. The banking industry is no exception. The challenge organizations are facing today is about how to anticipate, adapt, maneuver, make decisions and change course as needed. With the emergence of technologies such as automated teller machines, the Internet, and mobile transactions, banking industry catapulted to a different orbit in the last decade. But the future will bring even more change. Banking as we know it, may be revolutionized in the next 10 years, as more disruption is waiting to happen.
So far, banks have adapted to the change and are aware of the threats they are going to face in the future. But intent is one thing ? the reality for most banks lies in inflexible, complex legacy systems that make it difficult to pivot towards becoming agile, fast-moving technology adopters. Even with a conservative view, The definition of legacy system is changing rapidly. In today's era solutions developed using ever bulging RBDMS demanding multi-core licenses & expensive engineered-systems and middleware heavy technologies that require expensive deployment & ongoing maintenance costs can be labelled as a legacy system. Current systems are IT user-centric, require long gestation & customization cycles that result in vendor lock-in and vested interests disconnected from business users & bankers who have to deliver to regulatory / compliance requirements. Banks have created abstraction layers between the mainframe and mid-range systems ? that is the middleware heavy and not tuned to flexible plug & play deployment models. Even solutions that profess configurability require considerable IT driven customization effort. Business users can rarely interact & alter methodologies to model various approaches to determine the best fit. If the current solution stack is legacy, what's the future? That is schema free NoSQL databases, distributed file system, in memory calculation, parallel computation and built for & ready to deploy to Cloud. Banks need to be extremely careful about how they architect their technology stack to make it "future proof". They have to look for technology options of the future rather than prevalent technology, as these multi - million dollar investments may run the risk of becoming "legacy" in next 2-3 years' time.
Currently, banks have either already invested or planning to invest multi-million dollars in buying a strategic solution for implementation of IFRS 9 accounting standards. Many have bought solutions developed on technologies, which may soon become obsolete, putting the whole investment in danger. IFRS 9 compliance has given a good business case to banks for investing in technologies. Banks should use this great opportunity to have a relook at their current technology architecture, evaluate various available emerging technology options and architect their IFRS 9 technology stack accordingly. This will help banks to future proof their investment for IFRS 9 solution and get the plumbing right for adding/hosting upcoming regulatory & compliance asks. Later, banks may use IFRS 9 business case to adopt these emerging technologies in other areas of banking. Having the option to deploying on premise, or on Cloud will help banks to scale their solution on demand without incurring the upfront capital cost and embrace an ecosystem that allows rapid assimilation of incremental solutions with assemble & use strategy.
Given this, we thought of sharing some key insights, which might assist banks' in selecting a strategic solution that will future-proof their investment.
One of the hardest things about technology selection is that for every problem there are several solutions and a mass of information available about them. How the bank decides which one to pick will depend on the answers to the following two basic questions.
What are the functional requirements that this technology needs to satisfy?
What are the non-functional requirements that this technology needs to satisfy?
Unless these critical questions are answered, it is not going to matter which technology the bank chooses; because without this clarity, it will probably turn out to be wrong.
In this blog, we will first understand the functional requirements of business users (risk and finance department) before exploring the appropriate technology options to satisfy these requirements.
Over last few years, regulation has become more complex. Regulators have given flexibility to the banks to select appropriate methodologies based on the principles of "proportionality" and "materiality". Given these flexibilities, banks are not only expected to report the numbers but also to explain the results and conduct "what if" analysis across various methodologies. IFRS 9 regulation published by IASB is no different. In this blog, we will try to understand the impact of these changes in defining the business requirements for IFRS 9 strategic solution.
IFRS 9 being a principles-based standard, banks were looking towards local regulators to provide guidance on the precise practices. Unfortunately, this has not materialized so far, with limited clarity from local regulators. Such a scenario almost guarantees a host of regulatory refinements and updates as the standard is rolled out, making it crucial for the bank to have a solution with added dimension of flexibility to protect their data and models against the caprices of tomorrow. The solution should allow incorporation of a new methodology or a new model with great ease (preferably with limited/no intervention from vendor) and without impacting the overall solution metadata schema and architecture.
IFRS 9 Expected Credit Loss (ECL) calculation is a multiple level sequential calculation process {e.g. Point in Time Probability of Default (PIT PD) calculation Process for Wholesale Portfolio: PIT PD calibration -> Adjustment of PD for Macro Economic Structure -> Creation of PD Term Structure} of estimating various risk components {e.g. PD, Loss Given Default (LGD), Exposure at Default (EAD), Maturity} followed by estimation of ECL. Under each of these steps, the bank has the option to choose from multiple methodologies. Hence, the solution should have the capability of configuring and executing multiple computation methodologies and sequence of calculations simultaneously with minimal/no intervention from IT. The solution should allow the user to modify a particular methodology step for a particular risk component (e.g. PIT PD calibration) without affecting calculation methodology of other risk components (e.g. LGD, EAD) or overall sequence of the calculation process. ECL methodologies are yet to be stabilize in most of the banks, and likely to evolve with time. Given the lack of reliability on the outcome of model/methodologies, it is important that the solution allows manual override at each stage of calculation process with appropriate audit trail.
Initially, banks would like to focus more on exploring various modeling methodologies and its impact on ECL before identifying a particular set of methodologies and calculation sequence for ECL computation. The solution should allow the bank to configure multiple methodologies and execute them simultaneously before allowing the user to select a particular methodology for the final production run. Moreover, during the methodology exploration phase, multiple users from the bank are expected to access the system simultaneously putting extreme pressure on the scalability and response time of the solution. Understandably the users may not find it acceptable to wait for hours for the results.
Solutions that come with multiple pre-configured methodologies for risk components (PD, LGD, EAD, Maturity) estimations will help the bank to reduce the implementation time. Methodologies should be in "ready to use form" for ECL estimation rather than a laundry list of statistical libraries that need to be customized to configure methodologies.
IFRS 9 requires many changes to an impairment model what assumptions are made, how decisions are arrived at to be recorded as a separate line item in the P&L statement. That means that whenever a change is made, a bank must run the model again and account for any differences in outcomes. To achieve this objective, the solution should have the capability to store the methodology along with the underlying data used for a particular calculation run with a date stamp.
Together with the fact that audit activity is increasing across the industry globally, IFRS 9 solution must be fully traceable.
The solution should have interactive dashboard providing visualization in the form of tables, charts, and graphs to display key meaningful insights. The dashboard should allow the user to drill down (not only to the data ? standard features in most solutions but also to calculation sequence) and compare results across reporting period providing transparency and auditability to the entire ECL computation process. Dashboard with attribution analysis capability will help the bank to make intelligent choices based on the understanding of the contribution of various factors on ECL, which would otherwise be difficult given the nonlinear nature of the relationship between various risk components and ECL. It will also enable the bank to explain the results of ECL computations to management and regulators without extensive additional manual effort.
In addition to the above, there are few non-functional solution features, which a strategic IFRS 9 solution should possess. Banks should look at these features more as 'good to have" hygiene factors, rather than as critical "differentiation" or "selection" criterion.
The solution should allow the bank to conduct data quality analysis before using the same for ECL calculation. This feature will be useful in case the bank is not using any ETL (Extraction, Transform, and Load) solution (Informatica etc.) to transfer the data from source system to IFRS 9 solution. Most of the ETL solutions are expected to have this as inbuilt feature. Some software solutions profess to possess inbuilt ETL with a comprehensive data model, but oftentimes the implementation of such solutions lead the bank onto the path of development of risk data warehouse as a prerequisite, which is eminently avoidable.
Like in any other regulatory solution, reconciliation is an important activity in the implementation of IFRS 9 solution and a solution that facilitates the reconciliation process will be preferable to banks. Though useful, this is not that critical as the bank or the solution implementation partner can always develop Ms-Excel based spreadsheet / tool for reconciliation purpose. Anyway, reconciliation is one-time activity and historically most of the banks are quite comfortable doing reconciliation on Ms-Excel spreadsheet. However, in case there is a mismatch of exposure value during the reconciliation process, IFRS 9 solution should allow the user to make balancing entry into the solution database with appropriate user rights and audit trail. This feature is extremely important from timely regulatory submission point of view, till the time bank identifies the source of mismatch and rectifies the same at the source system level. Documentation on how IFRS-9/CECL computation approach can enable rapid data reconciliation process that can be handled offline would be helpful. It is pertinent to highlight that GL-Reconciliation as a pre-built solution stack component to be licensed with IFRS9 kills flexibility of adding new methodologies & solution components outside of a single-vendor stack.
Banks need to pass the provision entry to General Ledger (G/L) based on incremental ECL between two consecutive reporting dates. The solution that can provide data to banks' existing G/L system in a readily useable form will be desirable to banks. The above feature will be extremely useful, in case the bank decides to pass provision entry at each instrument level in G/L system. However, based on our discussion with many CFOs' across jurisdictions, we understand that most of the banks will pass a consolidated provision entry at the portfolio/business unit level (especially for exposures at Stage 1) rather than at individual instrument level. These banks are planning to generate a report of Incremental Provision from their IFSR 9 solution at the portfolio/business unit level, pass a consolidated entry in the G/L at the consolidated level and share the report with the auditor to validate.
IFRS 9 strategic solution having its own proprietary reporting capability may not be a necessity. Most of the banks typically use generic reporting tools (Cognos, BO, Tableau etc.), for financial and regulatory reporting and we expect them to continue to use the same for IFRS 9 related reporting also. However, IFRS 9 solution should be able to export the data in a format that can be easily used by these reporting solutions.
Based on the above requirements of IFRS 9 solution, below are some of the key technology features that are desirable in a Strategic IFRS 9 solution to make the investment future-proof. Some of these will depend on the core technology on which the solution is developed and some will depend on the way the solution is designed.
Strategic IFRS 9 solutions built on RDBMS (Relational Database Management System) may not be capable of meeting the above requirements. RDBMS fits highly structured data-centric approach to solution building that is largely managed by IT. However, when the solution requires to support business users to visually & interactively configure/ model/ execute solution methodologies in real-time without having to work lock-in-step with IT team, it may not be the right approach.
RDBMS is strictly structure driven. The structure of data to be processed has to be "statically" defined upfront. This does not lend itself a flexible architecture that heavy computing oriented processing paradigm is embracing. Ability to bring in a set of new attributes and define compute expressions on top of them cannot be done in RDBMS without significant data-modeling effort done upfront to account for placeholder attributes. In such a scheme, these attributes will not be descriptive or traceable innately.
As regulatory demands require new data elements, attributes to be brought in for analysis, this should be enabled at the speed of thought and with complete interactivity. This should not require IT heavy time-consuming pre-requisites of refactoring data-models, updating them for logical/physical representation, run offline impact analysis of the change to data-model on existing application definitions, redefine all of the impacted objects before these new elements can even begin to be used in the solution. A tool that allows for a dynamic refresh of the data model instantaneously and automates its availability of analysis & use in computations interactively gives the power back to business users. To summarize, IT should not drive what is essentially a complex regulatory solution that is squarely in the bankers' domain.
This need for schema free database design that can scale linearly, does not require expensive licensing options nor requires expensive engineered systems for deployment was quickly realized as a pre-requisite for proven disruptors like Google & Facebook to linearly scale and add functionality in an agile fashion. Companies like Facebook, Google had encountered this problem of "unstructured" data while dealing with social media information. They managed to solve this problem by segregating the "Data repository" from "Metadata store". This quickly transformed into a data-repository technology for both 'Structured' & 'Unstructured' data. This architecture allows the solution to do an impact analysis of change to a definition both in terms of application flow, as well as data-flow. Metadata (is application objects or definitions that make up the application process flows) change can be logically unconnected to physical data with this sort of architecture. This allows the application to switch the datastore without having to change the application definition or processing logic.
NoSQL (originally referring to "nonSQL", "nonrelational" or "not only SQL") is a document oriented dynamic database standard for metadata store meant for rapid distributed processing and supports schema-free data store idea. There are various metadata stores used by various technology solutions that are available the market. Among these, MongoDB is used widely & publicly and has fantastic support both in term of user-base and UI tools. There are others like Cassandra pioneered by Facebook, Cloud BlgTable from Google.
Even though Metadata stores can work with both RDBMS store like Oracle, MySQL or file store like Hadoop Distributed File System (HDFS), solutions architected with separate Metadata store typically use file store data format like HDFS, as it allows the solution to work with newer data-elements/attributes without requiring data-model changes or the expensive upfront effort of data-model rationalization & physicalization. With HDFS, there is native support for distributed approach to holding data for distributed processing, high-availability without having to pay for expensive database technology packs (like Partition,RAC, etc.,). With HDFS, the storage is both flexible and optimal with a variety of file formats to account for "compression", "encryption at rest" and modern processing tools that can read directly off of HDFS for in-memory processing, but cannot do the same with RDBMS.
In addition to the above, RDBMS is expensive and does not support in-place upgrade of static data models. The system will need to re-spun, customizations or extensions have to be re- factored every time the data-model is upgraded by the vendor. RDBMS also comes with a huge cost. The core-based licensing in tandem with enterprise edition adds to a steep infrastructure cost to be borne. Business-Applications should focus on providing best of the breed, highly flexible/interactive business user centric solutions, rather than an IT-centric solution. RDBMS mandates maintaining large IT staff, keeping abreast with vendor's choice of infrastructure/middleware and technology stack.
Historically file-systems have not been reliable because of disk fragmentation, lack of encryption at the disk level or at the level of file-system and limitations regarding the ability to hold a large volume of data on raw files. These aspects are now pass. File-system today support "distributed or sharing" with file-system level encryption-at-rest built natively into the file-system supporting immutability, scalability, and tools that process natively off of file-systems. File-System referred here is not normal desk-topfile-system but one that is enterprise-ready, highly secure and smartly distributed for optimized processing.
Legacy File-Systems were either maintained by the operating system or as external disks that were essentially state-unaware dumb storage media. RDBMS added the abstraction layers and engines to control the file-system and box it for structured processing requirements. However ultimately, even RDBMS also stores data in "files". With evolution of distributed file-systems, sharing and technologies that are built to process data directly off of file-systems with I/O latency circumvented by distribution, memory to IO replication in real-time and the enormous business flexibility to bring in data (new data with new attributes) on demand for modeling & scenario processing, the technology paradigm has shifted. NoSQL databases, for example, work directly off of file-systems without needing specialized software for managing file systems. RDBMS is still critical for transaction & operational systems where data format/structure is pre-ordained, though not for analytical systems.
IFRS 9 calculation logic is not a single or monolithic entity. It is made of multiple calculation steps and under each of these steps, the bank has the option to choose from multiple methodology options. Most of the legacy strategic solutions pre-wire a particular solution path. If there are different ways to get to the solution, they are coded upfront and flexibility is limited to choosing one of the paths pre-coded. If new data-elements & attributes or sources have to be brought in, then it almost always entails data model customization, followed by custom extensions to the solution by way of use of these additional data-elements/attributes.
Some legacy solutions code logic as a black-box calculation engine whereas some have a rule-engine based approach, where the rules can be configured to setup an execution hierarchy of tasks. However, the rule configurations are not business-user friendly, with the business user having to document what is required for a given problem down to the finest granular task. Then the IT user configures rules against them. Most of the time, there is a disconnect between business-user and IT-user. Even if they sit together to configure the system, the business user has to go by a leap of faith that the IT user has configured the requirements exactly as per the requirement. There is no way to verify or validate it upfront without going through an elaborate UAT (user acceptance test) process.
In legacy systems, different approaches are presented as scenarios or 'alternate runs'. The problem with this is that the "macro-view" is never visible. All possible permutations or combinations cannot be visualized upfront. There are numerous screens or forms through which parameters are captured. As a result, traditional solutions are not suitable where the users are required to create/configure new computation sequence, models, and metadata sets. This is reminiscent of IT oriented solutions that takes the power away from business / domain experts. In every solution available in the market today, business has to sit with IT to describe the tasks and the IT needs to translate the same into solution. There is no way for the business to build or configure the solution, and do this interactively is almost impossible. This is where disruptors can play a paradigm defining role. IFRS9 /CECL should be seen as a strategic opportunity to invest in such a disruptor to building the foundation of next generation solution stack that is driven by business/domain specialists and can stand the scrutiny of regulators.
To meet this user requirement, IFRS 9 solution should be able to define multiple calculation steps and break down calculation logics into several smaller constructs or building-block objects. By storing each of these building-block objects that make up a large calculation as distinct objects in the metadata repository (as business metadata), solution should be able to provide simple visual view of these objects, allow for modifications without getting lost in the complexity of the calculation, and by exposing all of these as simple constructs, it should help business users to manage the system / configure / modify without necessitating IT to take over.
Some of the new technology solutions allow these building blocks to be grouped visually using DAG (Directed-Acyclic-Graph) in a particular sequence to represent a specific calculation path. DAG allows the visual representation of the calculation paths/methodologies possible along with conditional flow, inclusions, exclusions and combinations feasible. With this, the business user is able to make interactive & visual choice of the path for processing, and can exercise any combination or all paths. It enables compare & contrast visually in tandem with the process path tagged to each execution result. This level of interactivity is unheard of in the complex analytical processing using traditional technologies. Most traditional solutions offer the ability to parameterize, change input values, and configure steps within the boxed solution but not the openness, and seldom complete business-user control.
Traceability of calculation process is natural with these types of solutions.
The DAG paths or sequence of steps to get to the final number (ECL) will be completely driven by business users. The interface is interactive and built for business users. The business determines which sequence or path to choose, and can select various sequences to compare & contrast. The traceability is dynamic and visual. Execution is interactive and does not require data-center operators to schedule activities. Multiple users can simultaneously model methodologies both visually and interactively. Different methodologies or sequence can be exercised, and results of various calculation paths are visible (filtered by user credentials so that a user sees only his or her executions).
The IFRS 9 strategic solutions should be designed to handle concurrency and processing concurrent sessions in near real-time. Solutions with in-memory processing technology allow the execution to be interactive with processing in synchronous mode. Traditional solutions provide batch as a medium of executing "alternate run" against large data- volumes. DAG along with in memory calculation ensures interactivity and traceability without impacting the performance and scalability of the solution.
Traditionally processing has been either by way of "shipping data to computations" or "shipping computations to data". With the former, there is large server required with large amounts of memory and the processing approach is hard-wired & not amenable to business users prying open the compute logic to alter compute paths/methodologies. With the latter, compute formulae are shipped to the database where the database executes the logic locally within the database engine requiring massive database server with expensive database options like Partitions, RAC, in-DB analytic, etc.
The modern day in-memory processing framework like "Apache Spark" allows data to be securely persisted on file-systems like HDFS with high availability, fail-safe redundancy and allows for processing to look at data in a distributed in-memory fashion on commodity hardware. There is no I/O latency, no database engine to license like Partitions, RAC, etc.,
In-memory calculation constructs the processing logic in ways that can be applied in distributed, parallel fashion to data held in-memory, and processed there with standard bells & whistles like precedence, solve-order, conditional branching, etc., Write-back of results to disk is also rapid.
In memory, distributed processing technologies were not efficient or mature in the past. With the explosion of power engines like Google and social media applications like Facebook that allow millions of users access information in real-time, traditional processing models that are server intensive and use database heavily would simply have not scaled and would be way too expensive to run. Imagine the size of servers, amount of power required to run a Google or Facebook with traditional processing models.
Distribution, Sharding, raw information storage (on file-system) without enrichment formatting (that are massive workloads, when data is stored in database engines) and ability to process this in-memory are game changers.
Apache Spark along with Hadoop has leapfrogged the legacy world of in-database processing in favor of in-memory processing, in both volume and speed metrics. Apache Spark is a project that pioneered in memory processing framework that was built around massive data, speed, ease of use and ability to apply sophisticated analytical processing methods. Hadoop is an open source, Java-based programming framework that supports the processing and storage of extremely large data sets in a distributed computing environment. Apache Spark and Hadoop have cracked the problem of ever increasing the complexity of data and the demands to include newer/additional sources/attributes into existing processing logic without requiring to rewire application systems. This offers the ability to build a strong metadata oriented declarative processing systems where new objects can be "declaratively defined" on the fly for newer data attributes and include them in processing optimally. Ability to distribute processing in-memory across commodity hardware without the latency of write- back of results to distributed file-systems is key.
Most traditional solutions offer static traceability based on data-model entities used. RDBMS based data-model is static and a result traceability is also static. Moreover, this traceability is only at the data level and not at the computation process level. In traditional solutions, computation process is either defined in black box calculation engine or within rule engines. These engines are not amenable for a visual representation of calculation logic including all steps and processing-paths. With new technologies, objects can be built on the fly as new data-elements/attributes are brought in. Execution is interactive and the interactivity is visually presented for real-time traceability.
Existing "In house" capability always made out to be a "Big Deal" while zeroing on a technology choice. However, it's not really a "Big Deal". Banks have always been proactive in technological transformations and invested billions on this. IT employees of banks have always responded positively towards the adoption of new technologies as it helps the organizations and its employee's progress in the future. To be successful in today's fast changing world, adaptability to new technologies has to be part of the core DNA of banks. Moreover, many of these new technologies have either already been adopted in other industries or in use for another business case within the bank. These new technologies are well supported by vendors and there is big enough ecosystem already in existence to support these technologies. Moreover, a solution developed based on these technologies can easily be deployed on Cloud. With cloud computing, banks can save substantial capital costs with zero in-house server storage and application requirements. The lack of on-premises infrastructure also removes their associated operational costs in the form of power, air conditioning, and administration costs. Banks pay for what is used and disengage whenever they like - there is no invested IT capital to worry about.
Most of the desired technology features mentioned above are recent developments and unless the technology vendor has developed IFRS 9 solution from the scratch, the solutions are unlikely to have these technology features. Most of the solution providers, who are aggressively pitching their products for IFRS 9 have either repackaged their existing solution for IFRS 9 or developed their IFRS 9 solution as an extension to their existing solutions. In most of the cases these existing solutions are based on decade old technologies and are unlikely to provide the functionalities (flexible metadata structure, configurable calculation methodology, rapid execution of in memory calculation, interactivity, auditability & traceability, data visualization, attribution analysis, cloud computing etc.) that is desirable in an IFRS 9 strategic solution.
The majority of these solutions are based on RDBMS, and extending them to accommodate additional data requirement is always a challenge, regardless of vendors' claims about their data model being extendable. Lack of in-memory calculation capability, make the what-if analysis a batch process, making the exploration of alternative approaches time consuming and cumbersome.
In addition to these technological shortcomings, most of the IFRS 9 strategic solutions are an extension of existing solutions and lack in functional capabilities for IFRS 9 computation. These solutions do not come with pre-configured approach/methodology and merely provide rule engines, which are to be configured during the implementation process. Configuring these rule engines is cumbersome and time-consuming, leading to extended implementation timeframe. Banks are unlikely to meet their IFRS 9 reporting deadline if they select a strategic solution for IFRS 9 compliance deadline.
Given this, we believe, today banks are at crossroads where have to make an important choice. They need to decide whether they would like to select a Strategic Solution based on legacy technologies, that is "good enough" and just "work fine" or they would select a solution architected with new age technologies, admittedly "a road less taken", but that, in the immortal words of Robert Frost will "make all the difference".
For immediate compliance, it may be prudent to develop a tactical solution and postpone the decision to invest millions in a Strategic solution right away. We expect that in near future, there will be strategic solutions in the market that are specifically designed and architected to address the specific needs of IFRS 9 regulation. This is a critical juncture wherein banks needs to be wise and may want to take a pause to assess the situation from a strategic perspective.
Don't miss this roundup of our newest and most distinctive insights