Skip to content

The Ultimate Guide to Risk Analytics

Blog

September 17, 2022 | Jonathan Pryer

Everything you wanted to know about risk analytics but were too afraid to ask

As we speak, thousands of programmers across the globe are frantically fielding error messages and digging through millions of lines of code to prop up whatever development misstep threatens potential risks of a data breach that could annihilate their respective universe at any given time. Phew. Every so often, a new concept enters the fray, a prophet peddling the hope of a better future. More recently, this future comes in the form of a microservices architecture – the fulfillment of Service Oriented Architecture’s (SOA) loosely coupled promise.

To give you a deeper understanding of what this means for programmers, we created this ultimate risk analysis guide filled with valuable insights to aid in your risk assessment process. As an organization that gets input from a variety of risk management professionals and multiple sources, we see the benefits of using microservices in financial institutions, the positives and pitfalls of implementing them for the long-haul, and the differences between them and the traditional, monolithic approach to development.

Microservices: Risk analytics solutions

When assessing risk and development blunders, programmers everywhere say, “Everything is breaking, always.” However, this is not a catastrophe; this is the fragile reality of software development – every enterprise is a house of cards mortared with sticky notes and energy drinks.

On occasion, brand new concepts will crop up and give said programmers the potential to alleviate key risk indicators. The newest concept in question is the use of microservices. Together, we’ll explore their role in managing risk and increasing business performance for software developers globally.

So, if you’re thinking about making the move to microservices, keep reading.

3 Benefits of Microservices in Risk Management

A good place to start is to understand three high-level benefits that have propelled the adoption of microservices and the role they play in managing risk analytics solutions.

Microservices are Agile.

Let me paint this as a story. A hypothetical Chief Risk Officer would have their team expose a scorecard as a service as part of the credit underwriting process. The Chief Operations Officer is in charge of that process. In context of the exposure of the scorecard, everyone agrees that if the underwriting process passes seven variables to the scorecard service, the service will return as a score.

As long as I don’t violate the contract – give me seven data points, and I’ll return a score – it doesn’t matter to the underwriting process how the score is calculated. If the risk management team discovers new data analytics data sources they can leverage, or if a new scoring model is created, they are free to implement; that change will not negatively impact the underwriting process. This level of agility means risk professionals can quickly adapt to a changing risk factors landscape.

Microservices are Resilient

You have heard that because a microservice is autonomous and loosely coupled, the failure of one service tends to happen in isolation of the rest of the system. In the example above, as long as the service that is exposed adheres to the original contract, the processes that rely on the service will not break. Both sides of the contract – give me seven variables and I will give you a score – are able to meet terms in the contract best. The underwriting process can retrieve the variables any way deemed best, and the scorecard service can calculate the score as deemed best. As long as the contract is honored, neither is impacted.

Microservices are Open

At this point, most microservices are designed to leverage REST as the mechanism for data exchange. REST has shown itself to be secure, lightweight, and flexible. This open nature represents enormous potential in the creation of end-to-end processes to meet operational needs of the enterprise.

Now that you’ve got a feel for why microservices could mean a better future for software developers, it’s essential for risk managers to learn the advantages and disadvantages of using them for the long haul.

Risk Analytics in a Microservices Architecture: The positives and pitfalls of microservices in the long-term

The agile, resilient, and open nature of a microservices architecture are all significant benefits you get at first sight, but nothing is perfect. What about the long haul?

This Q&A goes further into the implementation of microservices, and some of the long-term positives and pitfalls.

How have microservices changed application development?

The vision to create a loosely-coupled enterprise environment has been a Holy Grail for some time. While the same theories and techniques showed promise with XML and SOAP-based web services, the implementation of microservices better supports an agile approach to development. The decomposition of monolithic end-to-end processes gives product and process designers and developers the flexibility to create solutions that may be better fit for purpose. It enables these professionals to define more discrete capabilities, allowing developers to develop discrete functions – a more appropriate solution to the business problem they must solve.

What are the most common risk issues you see affecting the implementation of microservices?

Microservices are yet another operational and developmental paradigm shift. These shifts always present challenges to implementation. The architectural maturity of an organization is often the most significant hindrance to adoption and implementation. If an organization is not in a place to facilitate the exposure of microservices, for example, due to legacy systems not supporting open messaging, it will hinder implementation.

Do you have any concerns regarding the current state of microservices?

My biggest concern regarding the state of microservices is the possibility that an organization may not adequately secure its endpoints. Due to the lightweight nature of microservices, it is not a prescriptive technology. By contrast, SOAP is governed by a standards body that ensures prescriptive security recommendations are provided. Microservices are not governed, so the potential roll-out is very “wild west.”

What kind of security techniques and tools do you find most effective for securing microservices?

The efficacy of security techniques and tools depend on the environment into which the microservice is deployed, but let’s take a general perspective. Microservices do not lend themselves to the “traditional” mode of security because components are not conjoined, therefore they do not share access to a common data repository (think identity control). To avoid making calls to an authentication service in every instance, using OAuth (Open Authorization) as a delegation protocol can simultaneously ensure the security and agility of the system.  

What do developers need to keep in mind when working on microservices?

When working on microservices, developers must be simple and discrete. A service should not be complicated. It should solve one singular problem. It should be as simple as: Give me seven data points, and I will give you a score. Nothing more.

What’s the future for microservices – where do the greatest opportunities lie?

One of the greatest opportunities in microservices lies in the potential for reuse. For example, many organizations require the ability to quickly reference employee information to match skill level to a given task. Instead of writing the code to look-up required information every time it is used in a process, the organization could write an employee look-up service to be reused by any process that needs the information.

Which programming languages, frameworks, and tools does Provenir use to enable the creation of microservices?

Provenir implements a development technique called graph theory, rather than implementing a language like Java or Scala. Graphs are designed and developed using Provenir’s Studio and deployed to our Decision Engine. As part of the development, users can expose REST-based endpoints. These endpoints enable decisions, analytics, processes, etc., to be exposed as microservices. We also provide tools that enable the testing and documentation of the exposed services.

To gain a better understanding of the concept as a whole, it’s important to nail the basics. In the final part of this risk analytics guide, we deep-dive into the defining differences of microservices and the traditional monolith and how they contribute to risk management strategies.

Microservices vs. Monolith

Unless you’ve been living under a rock without wi-fi, in which case I would question your ability to read this article, you’ve likely heard the concept of microservices compared with a monolithic architectural style. Comparison with the monolith is a great way to explain the characteristics of a microservices style because the two architectural concepts exist in stark contrast: large and interwoven, small and discrete.

For this section of the guide, we’ll contrast microservices with the monolithic approach to development to gain a baseline understanding of the concept.

Microservices

Part of an architectural concept where the focus is on discrete services that do one thing and do that one thing very well. In the risk decisioning context an analytics group within an organization might be responsible for developing and exposing scorecards as microservices. 

The data scientist, or analysts, would focus on developing really good scorecards and making sure these scorecards continuously deliver quality results. They would then expose these scorecards as discrete services that could be called upon to deliver excellent and accurate scores. An operations group could then develop applications or processes that call out to these scorecards at the right time, leveraging these scores in a decision process.

The Monolith

Most of the time, business processes are designed to be an end-to-end process. That’s what we call a monolithic architecture. All parts of the decision process are developed as one, large complex process. Let’s consider scorecards again, as an example. If you want to make a change to a scorecard there may be a great deal of coordination, refactoring or redevelopment of the process, then testing before rolling out again.

What’s Next?

Now that we’ve gone in dept on microservices… what’s next? Where is the industry headed? The use of microservices in financial technology can simplify how you turn your scorecards, risk models and other analytics components into services for use in a loan origination and decisioning processes. Simple right? But don’t forget that having the foundation of the right scorecards, data and risk models is critical. And then if you want to implement advanced analytics like AI/ML, you may be looking at additional challenges, despite the vast improvements it offers across the modeling lifecycle.

For more information on how to implement advanced AI algorithms (and maybe inform even more powerful microservices?), check out our Decisioning Cloud.