BLOG

To understand the regulation better, let’s delve into its origins and historical context. It is crucial to recognize that the Consumer Duty Regulation is a response to concerns raised about consumer outcomes in the industry. These concerns include issues such as mis-selling, lack of transparency, and poor treatment of vulnerable customers. The regulation aims to address these issues and create a more equitable and customer-centric financial services sector.

The three cross-cutting rules lay the foundation for the regulation. They require companies and to act in the best interest of their customers, provide products and services that meet customers’ needs, and maintain a duty of care. The four outcome rules focus on specific areas such as communications, products and services, customer service, and customer feedback.

An in-depth understanding of these rules and guidance will help credit risk professionals navigate the regulatory landscape effectively and ensure compliance.

1. FCA’s Assessment of Consumer Duty Compliance:

Since the publication of the Consumer Duty Regulation, the FCA has been actively reviewing implementation plans and their outcomes. The FCA’s assessment provides insights into the industry’s response to the regulation, highlighting areas of successful implementation as well as those that require improvement.

It is critical that credit risk teams stay informed about the FCA’s assessment findings and align their preparations accordingly in order to meet the regulatory requirements.

2. Prioritization Strategies for Effective Compliance:

To effectively comply with the Consumer Duty Regulation, credit risk teams need to prioritize their activities. Prioritization ensures that resources and efforts are directed toward addressing areas of highest importance, increasing the likelihood of successful compliance.

Developing clear strategies for identifying and addressing compliance gaps is crucial. This may involve assessing existing processes, systems, and policies, and making necessary adjustments to align with the regulation’s requirements.

3. Collaborative Engagement with 3rd Parties:

The Consumer Duty Regulation emphasizes the need for collaborative engagement within the distribution chain. Financial services organisations must work closely with intermediaries, such as brokers and price comparison websites, to ensure that information is effectively shared and implemented.

Building strong relationships and open lines of communication with 3rd parties is essential for achieving good customer outcomes and maintaining compliance with the regulation.

As the deadline for compliance approaches, companies must continuously update their knowledge, collaborate effectively, and adapt to regulatory changes. The path forward requires ongoing efforts to improve customer outcomes and create a fair and customer-centric financial services sector. By staying informed and embracing compliance, companies can successfully navigate the path forward and ensure positive customer experiences.

References:

• https://www.fca.org.uk/publications/multi-firm-reviews/consumer-duty-implementation-plans
• https://www.fca.org.uk/news/press-releases/fca-tells-lenders-support-consumers-struggling-cost-living
• https://www.fca.org.uk/firms/consumer-duty

BLOG

Credit risk analytics refers to the process of assessing the probability of default by borrowers and measuring the potential losses that lenders may incur due to credit defaults. This involves analyzing various factors such as the borrower’s credit history, financial health, and other relevant metrics to determine their creditworthiness.

Financial institutions rely heavily on credit risk analytics to make informed lending decisions and manage their credit risk exposure. By analyzing credit risk, financial institutions can identify potential losses and take proactive measures to minimize them. This can include measures such as setting appropriate interest rates, requiring collateral or guarantees, and establishing risk management policies and procedures.

However, relying solely on credit risk analytics without appropriate risk management solutions can have severe consequences. For example, if a lender fails to identify and mitigate potential credit risks, it could lead to significant losses, which could ultimately impact the lender’s financial stability and reputation. Therefore, it is essential for financial institutions to have robust risk management policies and procedures in place to manage potential credit risks effectively.

Credit risk management software is a specialized tool used by financial institutions to assess and manage the risk of default by borrowers. It leverages advanced analytics and modeling techniques to provide a comprehensive assessment of the creditworthiness of a borrower, helping lenders make informed decisions regarding loan approvals, interest rates, and other terms and conditions. Credit risk management software can also monitor and analyze credit portfolios, providing ongoing risk assessments and alerts to potential issues. By automating much of the credit risk management process, this software empowers financial institutions to improve the accuracy and efficiency of their risk management practices, ultimately leading to better business outcomes.

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 analytics 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.

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.

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.

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.

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.

BLOG

I loved Lego when I was a kid, ok, ok, I’m going to be totally honest, I still love Lego (PSA: other brands of building blocks are available). The pirate theme was a favorite, but Santa must have lost my pirate ship box set somewhere over the Atlantic. So, my pirate Lego supply was limited to a mini boat, Lego characters wearing pirate costumes, and treasure chests filled with pieces of eight. So, here I have my menacing pirates setting off on elaborate plundering adventures in… a tiny ‘wooden dinghy’. Let’s face it, no self-respecting pirate would be taking that dinghy anywhere, even to pop down to the grocery store to stock up on grog.

But what does Lego have to do with deciding whether to build or buy credit risk software?

Building a credit decisioning solution for your business is like creating a Lego model. Your solution – whether it’s a loan origination system, merchant onboarding tool, or payment platform – is not a self-contained Lego brick that can act as a user interface, store data, process applications, manage integrations, maintain KYC compliance, host risk models, use machine learning algorithms, and provide a credit decision. Similar to Lego, it is a set of building blocks joined together to create the right decisioning solution for your business.

The build vs. buy debate has been going on for years, and much of the discussion falls around simple options: you buy, or you build. But with technology getting more advanced every day there’s now other options such as: buying the building blocks or selecting a strategic partner. So, for the purpose of this guide we’re going to compare four options:

– Build

This is the from scratch, internal approach. If this were a Lego project it would include creating the plans for your blocks, developing the blocks internally, and building them into your finished solution. This is often the first option explored by tech savvy companies, especially if they have a wealth of tech talent available to take on the project.

– Build, but not from Scratch

This is the Lego kit solution for credit risk software. You buy the kit—so you don’t need to handle building the blocks/ components—and combine them into the solution that best fits your needs. The flexibility in finished design will vary by vendor solution. For example, some solutions may give you the option to build anything from a paddle board to a cruise liner. Others may only let you build a sailboat.

– Buy

Another common choice is the buy approach, in this situation you’re buying your pirate boat fully built, you might be able to change a few of the decorations, but the design stays pretty standard. Ongoing maintenance and upgrade options will vary by vendor. If you spring a leak you may need to depend on the vendor to fix the hole.

– Partner

Someone else owns the Lego and has already built the ship, you use it. This may sound like the perfect solution, but you could be very limited on the design. In other words, you’ll need to adjust your needs to fit their ship design.

Are you facing challenges in managing credit risks within your business? Maybe you’re struggling to keep up with your competitors, experiencing limitations in business growth, or dealing with a poor user experience. One way to address these challenges is by using credit risk software. However, before selecting a solution, it’s important to consider several factors:

1. Your Pain Points What’s your pain point? – Is there an issue causing you to lag behind your competitors, impacting your user experience, or limiting business growth? What do you need to do to fix it? Is it increasing your decisioning speed? Reducing the time it takes your team to deploy new risk models? Make integration to internal or external data sources easier? Improve the accuracy of your decisioning? Automate the decisioning process? Defining the project scope and listing solution requirements is an essential step in fully evaluating your options. Without knowing your need list and your wish list you could end up with a risk decisioning river boat when what you really needed was a jet ski
2. Fit – Perhaps the most important question: would the implemented solution meet all of your decisioning needs?  Or would you need to bring in other solutions to make up for any shortcomings? It’s also important to look at how the solution will fit in with your existing technology stack and how easy integrating the systems would be. For example, will the tech stack together like Lego blocks, or will it will it be more like trying to attach a Lego block to a house brick.
3. Flexibility – The thing that makes Lego so incredible is the huge amount of designs you can make with just a small set of blocks. My Lego house could absolutely transform into a pirate ship when needed! So, which of the solutions will give you the flexibility you need to create the right system for your business needs?
4. Time – Instant launch or long development process? How will each option impact your time to market? Long delays can be expensive, extend product launch times, limit business agility, and expose the business to increased risk, especially where credit origination and KYC processes are involved.
5. Costs – The cost of each option is an obvious consideration, but it’s important to look at both initial costs and ongoing costs. Things to consider include the cost of ongoing maintenance, changes, and upgrades, whether they’re completed internally or externally. If your solution will be inadequate in a few years, what will be the cost to replace it or make it fit new business needs?
6. Resources – What resources will you need to complete the project, and do you currently have that talent in your team? If not, what training or recruitment will need to be completed and what will be the cost to bring the required resources in house?
7. Focus – New development projects can be all consuming—using resources, effort, and focus that could be utilized elsewhere to drive the business towards its goals. If you decide to focus your resources on an internal build, what opportunities will you miss elsewhere and is the delay to these other projects a problem?
8. Usability – Usability can make a huge difference to your business in both the short and long-term, so it’s important to ask how usable the finished solution will be? Will you need specially trained team members? If it’s an externally built solution how much will it cost to train your team to use the system? In Lego terms, are you getting a simple kit with a few pages of instructions, or a 2000-block pack with a 500-page manual?
9. Control – While the ability to change settings and adjust processes may seem like a nice to have option, the delays caused by waiting for vendors or your tech team to implement change requests from your risk team can have a long-term impact. Each time you have to wait for a new data source to be integrated, a score card to be changed, or a risk model to be deployed you’re falling behind your competitors. When evaluating solutions make sure to ask how much control will you have over the software. Will you be able to easily make changes and adjust settings, or will you be reliant on a third party such as the vendor?
10. Competitive Advantage – In some situations, one solution will give you an advantage over the competition. For example, if you can build a Lego ship that has a unique design that makes it faster, smarter, and more efficient than other ships, then creating your own Intellectual Property makes sense. However, if an industry leading solution is available to buy, what competitive advantages would you gain by building internally?
11. Business Agility – Will the selected option impact your business agility? For example, could you quickly pivot direction and make quick decisions? Or would you need long lead times to adjust your decisioning processes, make updates, or completely switch direction?
12. Scalability – While it may be easier to shop for or build a solution that fits your needs now, looking ahead can help you avoid needing to replace your solution in a few years. So, when evaluating options ask: will your solution be able to easily grow and develop with your business, or will the decisioning solution be obsolete in a few years?

The decision to build or buy credit risk software is a critical one for financial institutions. While building an in-house solution may provide greater control and customization, it comes with a higher cost and longer development time. Buying a pre-built solution can offer faster implementation, cost savings, and access to advanced features and technology. Ultimately, the decision should be based on a thorough evaluation of the organization’s specific needs and capabilities. Working with a trusted partner can help organizations navigate the complex process of selecting and implementing the right credit risk software solution for their business.

What is a decision engine and how does it help your business processes?

BLOG

I’m going to defer to a quote from the Banker Scene in Monty Python’s Flying Circus to start this blog:

“I’m glad to say we’ve got the go-ahead to lend you the money you required…

We will, of course, want as security the deeds of your house, of your aunt’s house, of your second cousin’s house, of your wife’s parents’ house, and of your granny’s bungalow. And we will, in addition, need a controlling interest in your new company, unrestricted access to your private bank account, the deposit in our vaults of your three children as hostages…”

It may seem a little odd to quote Monty Python at the start of a blog about credit risk modeling using Python but, I have two very good reasons:

1. While the level of security the borrower in this scene needed to provide is absurd, it highlights the need for lenders to fully understand the risk of a loan in order to not require their customers to put their children up as collateral…
2. You’ll find out in a second

When Monty Python was filmed back in 1969 credit risk modeling was in its infancy, in fact it was barely crawling let alone walking into adolescence. Understanding default risk was a complicated, long, and labor-intensive process. We can thank risk modeling pioneers and languages like Python for helping banks and other lenders make more informed decisions about loan applications.

It was the week of Christmas in 1989 in Amsterdam, 48* F and cloudy, when Guido van Rossum started tinkering on a small project to busy himself while his employer’s office closed for the holiday. van Rossum set out to create a language, based on a previous project called ABC, that was reliant on the Unix infrastructure and conventions, without being Unix-bound. He placed a high emphasis on readability and uniformity in an era that praised languages like C and Perl (PHP’s high-maintenance personality would crash the party later). The result was a gorgeously elegant open source language named after (here’s reason 2) Monty Python’s Flying Circus.

Since its official release in 1993, Python has displayed its prowess across multiple industries and in widely varying use cases. It is now the most widely taught introductory language in the top computer science programs worldwide, was named the most in-demand programming language in the U.S. by Forbes’ fintech columnist, and hit #2 on the list of most GitHub pulls by language in 2017.

One increasingly popular application of Python is in credit risk modeling. Many brilliant data scientists and analysts wrangle the usability of Python to implement machine learning and deep learning algorithms. From simple algorithms like logistic regression, decision trees, random forests, support vector machines via classification and regression, to more advanced methods like clustering and neural networks, the many advantages of Python are opening the doors to apply artificial intelligence to credit risk challenges.

Yet, despite the promise that Python and other popular languages bring to financial services, we talk to companies nearly every day who vent frustration with the process of testing and deploying models to production, then maintaining or changing models as business objectives evolve. It has been stated that “The next breakthrough in data analysis may not be in individual algorithms, but in the ability to rapidly combine, deploy, and maintain existing algorithms.” I would venture to guess that most of us in financial services (or any data-driven industry, for that matter) would say, “Of course.” Delays in model deployment are nothing new, and we’re ready for a change.

Ben Lorica, the Chief Data Scientist at O’Reilly once called out the delays that exist from modeling to production, identifying two root causes for the long analytical lifecycle:

1. Silos -Data Scientists and Production Engineering teams are historically divided, resulting in a wall between the two organizations that results in inherent delays.
2. Recoding – Models often have to be recorded before they can be deployed into production. So, while your data scientist may prefer Python risk modeling, your production system probably requires Java.

You’re probably squirming in your seat right now because you get the same familiar anxiety that I do when thinking about this dynamic. But, stay with me.

If everybody is so frustrated with this problem, why doesn’t anyone fix it?

I’m so glad you asked.

Provenir tackled this challenge head on in two very distinct ways:

1. Empowerment – Silos or no silos, your production system should be so easy to use that your data scientist can deploy a model autonomously. Deploying a model into a Provenir decisioning environment is as simple as attaching a document to an email. Just upload the document, visually map your values, and go.
2. Native Operationalization – Recoding?! That sounds like re-work to me. Why not operationalize models in their native languages? So, Provenir supports the native operationalization of risk models in R, SaS, and Excel along with PMML and MathML. We also include support for Python, not just because we value any opportunity to share a Monty Python joke, but because we know how beneficial it is to let your team create models in the language they’re most comfortable with!