Featured Product

    Buy or Build: Transforming Commercial Credit Origination

    April 2017

    Buy or Build: Transforming Commercial Credit Origination

    Technology is rapidly changing the way we do business. In the financial services sector, arguably the largest industry in the world, this has never been more true. 

    New Technology Is a Major Driver of Change in Financial Services
    From mobile accessibility to cloud computing, technology is driving a new wave of change fueled by a dynamic fintech industry comprising hundreds of companies—many of which did not exist 10 or even 5 years ago. Unconstrained by legacy architecture, alternative and challenger lenders embracing these technologies offer a new customer experience in terms of accessibility, speed, and transparency. And they are rapidly gaining market share as a result.

    Established banks have recognized this threat and are responding. As they seek to retain and expand their customer base and increase profitability in a market climate of increased regulation, diminishing returns, and ever-higher capital constraints, many are undertaking wide-scale transformation programs.

    Technology is enabling this transformation and is fast becoming the new battleground for competitive edge. A primary area of focus has been the ecosystem supporting commercial credit origination, largely untouched for many years but now seen by many as a key source of future growth.

    Banks are seeking radical process change in commercial lending, but how should this change be achieved—by building your own platform using internal resources or by purchasing a solution from an established vendor? This is the question we hope to answer—or at least explore sufficiently to help readers answer for themselves—in this paper.

    Meeting Ever-Increasing Expectations
    Since the financial crisis, leading banks have launched risk management initiatives as part of broader programs to attain parity with their competitors, or, preferably, gain an advantage. This is a dramatic shift from the traditional perception of the risk management function as “reactive” or backward-looking, largely focused on regulatory compliance. Today, forward-thinking banks regard the integration of risk management within the business process as an enabler of growth that can:

    • Provide an infrastructure supporting proactive risk and capital management to ensure the optimal use of increasingly scarce capital and ensure that excessive risk concentrations are avoided.
    • Supply risk-aware decision-making support both at the strategic planning stage and at the point of execution to ensure that both business and risk are fully cognizant of the potential impact of decisions.
    • Optimize the process of customer assessment and the credit decision framework to ensure that resources are engaged in risk management, not risk administration, and that all processes are focused on putting the customer first to improve loan servicing.

    Overcoming the Burden of Outdated Legacy Systems
    For the majority of banks, achieving the goals set out above dictates a complete re-think of credit risk management from a technology perspective. 

    While investment in new systems has been significant in the last 15 years, it has largely been focused on risk simulation for the more lucrative investment banking book, and then in support of Basel II compliance. However, in pursuit of regulatory readiness, most banks approached the task with large and expensive programs to transform data retrospectively in support of risk-weighted asset computations for a prior point in time. Warehousing, transformation, and calculation tools were the top priorities of the day, with little attention given to front-end system upgrades and enhancements.

    In the case of commercial loan management this has resulted in an aging, disparate system landscape. And for the process of credit origination and approval, all too often the system requires manual handling in support of the process—across scores of people.

    So the case for change is clear, but how should this change be addressed? Certainly through innovation and technical enablement. But what technology—or more specifically, in what form? Simply put, are you better off buying or building a commercial lending system?

    Buy Versus Build: Four Critical Considerations
    This is not a new debate. For many it has been a perennial question, particularly for larger organizations with a history of building their systems in-house. But given the shrinking size of in-house IT budgets and the growing trend toward outsourcing, this question is taking on greater prominence.

    The following sections outline four key factors when weighing a buy or build approach to credit risk management systems—specifically, commercial banking credit risk. Of course, this assumes that the organization already knows what it wants to achieve, its end state goal, which is essential before any investment should be made.

    1. REQUIREMENT COMPLEXITY AND RESOURCES
    Commercial credit management is a broad and complex domain that goes well beyond transactional risk computation to aspects of people, process, and relationships. For these reasons it can result in a lengthy process, taking weeks from inception to actual delivery of funds. For larger organizations, this is further compounded by the diversity of business models and geographies.

    This fact drives a complex set of development requirements that include:

    • Oversight and control of the entire relationship—requiring support for multiple complex relationship hierarchies and exposure aggregation algorithms
    • Complete risk assessment of the borrower both at the point of origination and throughout the life of the relationship—financial analysis, risk grading, and covenant monitoring
    • Thorough examination and monitoring of a transaction’s health and impact on the portfolio as a whole—facility structuring and pricing, availability of risk mitigation, and effect on the exposure, loss given default (LGD), and risk appetite framework
    • Ensuring business enablement while delivering risk control—a consistent, automated solution with controls and auditability to provide transparency to the right people at the right time
    • Providing a single point of integration for all stakeholders—linking data origination, validation and approval, document management and generation, limit-setting and monitoring, risk exposure calculation and reporting
    • Delivering a robust credit decision framework—recognizing complex access rights and authority levels across all stakeholders and activities

    Often, these complexities lead people to assume that only the bank itself can fully understand its requirements, and therefore no solution on the market can possibly deliver everything needed. This assumption is often cited as the principal reason for pursuing in-house development.

    However, a thorough assessment of your available resource pool, their skills and prior experience in delivering these programs, must be undertaken as part of this decision. Remember that, as with most things, the devil is in the details. Too often, legacy architecture will have masked some of these complexities, resulting in an underestimation of their true impact.

    In contrast, a good solution vendor should have the experience of addressing even the most complex situations. The key question here is: can you build it and can you build it in time to meet your deadlines—be they regulatory or internal? Do you have a complete understanding of the complexity of the job or is there a risk it has been underestimated? Do you have the resources both at the technical and business level available throughout the lifetime of the project—and if so, could they be better applied to other projects?

    A key part of the vendor’s offering should be the deployment of knowledgeable personnel with relevant experience who, in the best cases, will uncover issues that were not previously identified.

    2. FACTORING IN THE COST EQUATION
    Commercial credit transformation programs can be expensive. Recent testimony from a mid-sized European institution indicated a planned multi-million dollar spend for the in-house development of most, but not all, of the requirements outlined earlier. So, would it be cheaper to buy? In an era of tight budgets, internal competition for funds and the need to get more from a systems investment than mere regulatory compliance make this a natural question.

    The answer to this question is driven by the size and complexity of the job requirements, and further influenced by any sort of deal you can negotiate with a vendor. But don’t overlook the fact that if you do decide to build it yourself, you are bearing all of the R&D costs, whereas with a market-ready, “proven” solution the R&D cost has been spread across the entire customer base. Plus, when R&D effort is required, timelines are typically longer—with a corresponding increase in costs.

    On the other hand, with an internal build the bank has more control to hire developers in greater numbers. But while economies of scale may be achieved with the deployment of more developers, experience shows that this saving is often reduced by the costs of onboarding new hires to the necessary level of effectiveness. 

    And what about ongoing costs beyond those related to the initial deployment? Access to good technical and business support is essential following major transformational change, and it needs to be in place for a long time. This support can make the difference between a successfully launched and universally applauded solution and one whose mere name evokes consternation in your organization.

    An off-the-shelf solution should also include comprehensive training and support services. Indeed, training existing and new staff is a perpetual need and can represent a considerable investment in light of typical turnover rates. Solution providers with a dedicated training methodology and course curriculum are best placed to provide this service on an ongoing basis. In addition, the best providers offer their solution on an outsourced or Software-as-a-Service (SaaS) basis, which virtually eliminates the costs of purchasing new hardware and paying IT staff to maintain the system and back up the data securely.

    Of course, requirements often change—as do industry regulations and business strategies. Maintaining a team to react to these inevitable changes is a luxury most banks cannot afford. It requires making a case for budget, identifying and securing the necessary resources, and managing the development project to completion. When buying a vendor solution, in contrast, the regular delivery of upgrades with new capabilities should be included in your support and maintenance agreement.

    Considering your budget, the risk and cost of implementation delay is critical. If you have to meet a regulatory deadline, delay is simply not an option. Moreover, building a solution internally requires higher levels of testing, which may get squeezed as deadlines approach. And launching a software solution without thorough testing is a recipe for disaster.

    3. CONTROL AND ADAPTABILITY
    The business landscape has changed considerably over the last decade, as has the regulatory environment. At the same time, technological advances have created new challenges and opportunities. Nothing suggests there will be a return to the relaxed risk assessment standards of the past, and therefore it’s essential to adapt as regulators and the industry react to market changes.

    Historically, the case for build-it-yourself has been a strong one. Building your own platform, with your own people and your own design, and with your specific requirements in mind, should allow you to adapt faster than a vendor solution that services many customers. After all, one size doesn’t fit all. But this does not reflect the reality that providers have to be more in tune with the needs of the market and keeping their solution up to date in the face of heightened competition.

    Given the pace of technical and regulatory change, the best providers have built up experience in adapting their development approach to keep pace with changes in the industry. This has led to less dependence on expensive database management systems, increased API flexibility, and critically, huge advances in the configurability and modularity of solutions. Vendors have also increased customer involvement in the product development process via user groups and forums to guide and validate their designs.

    At the same time, vendors have struggled to maintain the necessary frameworks to accommodate the range of demands reflected in the different sizes, business process models, and regulatory frameworks of their customers. Once addressed through long and expensive customizations, the best solutions feature increased control and configurability by leveraging modern frameworks such as HTML5.

    No one knows what will be driving the market in 5 or 10 years. Therefore, adopting a highly flexible platform, be it via build or buy, will put you in a much better position to respond to future developments.

    4. SECURITY AND TECHNICAL STANDARDS
    As data proliferates exponentially and we access it from every point of the globe, protecting your own network and data is of the utmost concern.

    For a bank with thousands or millions of customer records, much of it highly sensitive, a security breach could result in irreparable damage to reputation. This risk has led banks to build multiple layers of security to monitor and protect against new threats which weren’t even imagined when the original code base was written. If you purchase a vendor platform, however, you should get built-in security that counters the latest threats and is regularly updated.

    Today, platform and data security have become key considerations when making the buy versus build decision. This is especially important as origination solutions achieve business-critical status, driving increased management attention and staff demands for continuous availability.

    Similarly, vendors are now pushing these considerations to the front of the queue when weighing their own development plans. For example, the need for more integration within banks’ front, middle, and back office ecosystems has already put the provision of secure but flexible APIs on the requirement roadmap.

    Certainly this reflects demands from banks themselves—and specifically from the technical departments of big banks, who submit high-priority issues that need fixing to vendors. So having a large and varied customer base may also benefit smaller banks, who simply cannot carry this cost themselves.

    A Compelling Case
    The needs of today’s commercial credit managers have certainly driven increased investment in technology. This is to be encouraged, as success will certainly sustain the sector in future downturns.

    However, investment itself is not a guarantee of success. It must be allied with a thorough process of assessment in terms of what the bank wants to achieve and an honest assessment of the complexities involved in meeting those needs.

    This is equally true when considering the bank’s overall appetite for change. For example, smaller banks might assume that the development or procurement of a robust credit origination solution is beyond their means. Given the affordable, modular approach of today’s most advanced solutions, this assumption is no longer valid.

    Similarly, larger banks might think that selecting a vendor solution would imply dependence on the solution provider and a loss of control. Again, the realities of today’s market, with highly configurable solutions that can be adopted as a whole or in part, ensure that the bank stays in control of what truly matters—its data and its intellectual property.

    Given the wide choice of providers offering capable and configurable solutions at a range of price points, buying a solution should be the natural start point. While this approach does not guarantee success, and is subject to choosing the right provider and solution, it enables a bank to compare its requirements against the feature set of an actual product. This comparison may shed light on the buy or build question and help the bank make the best choice for its needs and means.

    At the end of this exercise, many banks may find that acquiring a proven solution from an experienced vendor represents a compelling case.

    Print Download