Last year I was offered the opportunity to transition from an intern to become a full-time employee in KRM22’s London headquarters. One major initiative I wanted to be involved in was to assist with the adoption of one of our risk products for our company’s internal use.

The product is our enterprise risk solution, The Risk Cockpit.

Initially I was concerned I lacked the technical knowledge to be successful in this role.  As my technical abilities progressed, I found that there was a more fundamental aspect that determined the success of onboarding a system like this.

The key to the Risk Cockpit becoming a valuable tool in any organisation, but especially at KRM22, is to create one central location that stores all risk related information powered by automated data flows. This allows the system to show the risks and empower the user to track the initiatives needed to reduce risk of achieving our corporate objectives.

When I first became involved in the project my primary task was to get information from underlying systems into this central location.  This system uses APIs (Application Program Interfaces) to “plumb” the information from one system into The Risk Cockpit.

At the beginning of the project the focus was on the integration of entire systems in one swoop. During our first system integration we imported over 200 metrics with specific filters applied at the same time. Trying to do all of this at once became very frustrating, not just because we stretched the limits of what the APIs could provide, but by bringing such a large set of data all at once, we blurred the discussions with key users around individual metrics and assessing their importance.

As the project progressed, I began to interact more regularly with department heads about their requirements. This led to a change in the way we configured the system.

We progressed to providing smaller, more manageable pieces of information each time we updated the system.  The success of this change led me to what I believe is the most valuable lesson I learned, the benefits of working in small batches and focusing discussion around the question of “What is one piece of information you feel you are missing?”

Asking this question leads managers to identify the major blind spots they feel they have and identify the risks they may face. Time taken to complete the integration and deliver value to the users became shorter and led to increased manager engagement and tapped into their creativity.

One of my favourite parts of an integration is when you spark a manager’s creativity. When you have a manager’s creativity it often leads them to identify requirements they had not previously considered.  This is key as it leads to a comprehensive understanding of their risk framework.

One of the reasons I chose to start my career with KRM22 is because we truly believe in the value our solutions provide. There is no doubt that adopting one of our key risk systems for our internal use is a great example of this.

We have worked hard to ensure we have one central location that stores all risk related information and cut costs and waste by eliminating multiple spread sheets by pulling information directly from underlying systems. Getting to this point has had its challenges, but we now are able to build on existing integrations quickly by operating in small batches.

KRM22’s Limits Manager application offers a central location to administer Limits Manager limits to Exchange trading applications and Independent Software Vendors (ISV’s), eliminating the need to interact with each application on an individual basis.

Consolidating communication across teams and reconciling limit information into one place, allows KRM22’s Limits Manager Limit application to provide a complete audit trail of all trading limit activity across user accounts and entities.

KRM22 Limits Manager Limits: New for Q2 2021!
  1. Historical Limit Tracking allows risk managers to view the limit settings of a Trading Entity during a specific calendar period. The limits in force on each date can be viewed in the Limits Manager limit GUI by dragging a scroll bar though dates or delivered via a report. The limit data is preserved for internal use as well as for compliance and audit purposes. Set the date/time range on the drop-down calendar and you are good to go!

  1. Copy limits from to/from Trading Entities. Conserve time and effort by applying limits already set for a given Trading Entity to another new or existing Trading Entity. The increased efficiency eliminates keypunch errors and simplifies the application of limits for new Trading Entities.

  1. Enhanced email functionality notifying risk managers of a pending approval of a limit change. The members of a workflow group are notified when there is a pending item needing attention as well as when the approval process is complete.

The buying process for technology solutions at major banks and asset managers has changed considerably over the past few decades.  Two factors have been instrumental in driving these changes.

The first change we have seen is the implementation of standardised procurement processes that were refined in business processes like Six Sigma. These processes leverage a centralised procurement team and a prescriptive procurement process to support and control how business teams license new technology systems.  This transition has forced business managers to learn how to conform their needs to corporate ‘standards’, some of which are diametrically opposed to what the business team is trying to accomplish.  

Over the past decade we have seen that most organisations have found a way to harmonise these sometime conflicting processes. Today, most centralised procurement processes have morphed into a valued partner to most of the business teams that we support at KRM22.      

Another change to the technology buying process finds major institutions discovering value in technology that ‘disrupts’ current business processes versus augmenting them.  This challenge can present difficult issues that must be addressed.  

By fundamentally changing how a business operates, the human capital component of an institution can be impacted in ways that may produce unintended consequences.    

A great discussion of this challenge was recently published by The Harvard Business Review in a case study by Leonard Schlesinger. The case study looked at how the implementation of a new technology solution at a regional bank could hurt morale at a commercial bank.  

This was important as this bank had carved out a unique space in the commercial lending market by providing a lending process that leverages “high touch” service to its customers.  This process created a unique and distinctive service that was hard or impossible for larger financial institutions or newly created FinTech companies to compete with.    

The bank knew it’s lending team were critical to providing this type of service.  There was concern that the result of the automation project would disrupt their team and destroy the high morale needed to provide the bank’s “secret sauce”.  Before completing the new technology plan, the banks senior IT resources met with senior management to find a solution to this question.

The answer came from patience, empowerment, and involvement.  The bank’s CEO had to temper her desire to obtain short term earnings improvement in order to avoid marginalising the bank’s unique value proposition.  They had to delay the implementation of this new technology until the bank’s executives, managers and line workers could get actively involved in the project.  

Work groups were created with specific deadlines tore-imagine the business post implementation. The work groups found a way to leverage an empowerment of the customer to complete tasks through automated processes and web sites while still providing a service level that FinTech’s and larger financial institutions could not or would not offer.    

This underscores one of the foundations of customer service that we employ at KRM22.  While we know how great our risk solutions are, we also know if our customer’s work teams are not actively ‘bought in’ to the changes we are helping to implement, our customers will not realise all the benefit we can provide.   

Dan Carter, Head of Customer Services at KRM22, sees this on a daily basis. Dan says, “We see customer engagement as a core principle for delivering quality systems to our client base. With customers that we have regular interactions with, we see vast improvements with efficiencies and functionality in comparison to those that are less engaged with us and our teams. We are a true Software as a Service (SaaS) company, and by engaging with us, clients get so much more from their applications than those that do not.”