ARCHIVED: TF Credit Line Management

The purpose of this document is to describe the technical solution of the Credit Line Management project.

The project’s main goal is to provide the different teams (Sales/Dealing, TF Risk, TF Ops, Onboarding) ways to improve the efficiency of the Lending processes by introducing more flexibility to the products and credit lines offered to the client, improve user experience for Sales/Dealing and Risk, improve tracking and reporting for senior levels.

Problem Description

Currently, Ebury offers SMEs a range of products and services in the field of financial services. For lending services there is a Trade Finance product which is used by many clients. At present, the system (Salesforce) is only capable of catering for a single credit line for the client, which introduces many challenges and limitations for the users.

The main pain points are:

  • single credit line
    • does not correctly reflect the products/services that Ebury offers to the client;
    • many of the additional products are currently being managed outside of the system(s), in spreadsheets, without a proper process tracking;
    • information might not sit in a single place, which makes it difficult to report with accuracy;
  • credit line is currently built-in the Account object (which represents the client record)
    • the processes inherent to Lending have contributed to overcrowding the Account object, to the point of hitting platform limits (for example, there is no more room to add more fields);
  • key processes are currently not being tracked in the system (for example, credit line renewals, updates and reactivations);
  • key scenarios are not being accounted for in the system (for example, new clients vs. existing clients);
  • the flow is not user friendly, although significant efforts are already being made to improve it.

There is a need for expansion of the products and services offered, therefore we need to make sure that we can support the company in it’s growth by helping to provide and maintain data that is accurate and processes that are efficient, robust and scalable.

The main goals are:

  • split the current single credit line (TF product) into multiple credit lines (different TF products) with specific characteristics;
  • eliminate the built-in dependency between credit line (TF product) and client record (Account) and better summarize the information;
  • facilitate the management of different credit/lending/risk/sales/dealing scenarios;
  • improve efficiency of processes (qualification, renewals, reactivation, etc.);
  • improve user experience in SF;
  • better control visibility/security on the TF flow, based on the users roles.

Background

The current TF functionality was built quickly to support the new product back in 2015. The product did not start to gain traction until relatively recently, and therefore investment has been minimal. The data model currently in place was chosen for simplicity only, with scalability not a consideration.

Solution

Data Model

The data model for this process will be structured with 5 key objects, 4 of which already exist in the system and will essentially remain as is, 1 of them will be created.

  • Account - represents the client; this will contain the summary of all credit lines and credit lines from government schemes associated to the client;

    • a client can have multiple credit lines, therefore the account record can be associated to multiple credit line records;
    • a client can have multiple credit lines from government schemes, therefore the account record can be associated to multiple government scheme records;

  • Product (new object) - represents a product/service offered by Ebury to clients, for the purpose of Lending/Trade Finance;

    • these are products that are offered (or will be offered):
      • Trade Finance (standard) - MVP
      • Invoice Finance
      • Term Loans
      • Purchase Order Finance
      • Letter of Credit

  • Credit Line (new object) - represents a standard credit line granted to the client by Ebury, associated to a specific product;

  • Government Scheme - represents a credit line granted by the client by Ebury through a government scheme; more information on government schemes can be found here. Note: Since Government Schemes are likely to become obsolete soon, in this implementation we will not put so much effort to develop them further.

  • Trade - represents the trade submitted by the client through EBO;

    • a trade can be associated to a credit line or a government scheme (defined by the client via EBO);
    • the trade amount will be added to the Line Used of the credit line or government scheme associated with the trade.
    • the trade amount will be summed up to the Total Line Used of the account.

  • Case - used to track the approval processes for the credit line (for example, TF Qualification) or for the trades (for example, TF Trade Approval).

TF CLM - Data Model

Link to full diagram here.

Product (new object)

The Product object is a new object that will represent and store information related to the TF Products; records of this object will compose the Product Catalogue. Each will contain settings of that product that can be used to inform other parts of the process, for example setting defaults on credit lines or trades when they are created, enforcing validations, applying specific rules for the repayment amount calculation, etc. Credit Line records can be associated with Product records. The details of the new object are described here.

Credit Line (new object)

The Credit Line object is a new object that will represent and store information related to a standard credit line (TF Products). The details of the new object are described here.

Credit Line Life-cycle

  • Application - Credit Line is created when a Sales/Dealing user submits a TF FactFinder form to request a new credit line for their client. This in turn creates a case and starts a TF Qualification, type Application.
    Triggered by the Sales/Dealing user.

  • Amendment - Credit Line is updated when a Sales/Dealing user submits a TF FactFinder form to request to amend (increase/decrease) an existing credit line for their client. This in turn creates a case record and starts a TF Qualification, type Application but Credit Line is marked as Amended. Triggered by the Sales/Dealing user.

  • Freeze/Unfreeze - Credit Line is freezed when TF Risk decides to suspend the credit line for whatever reason. No TF Qualification needed.
    Triggered by the TF Risk user.

  • Renewal - Credit Line is extended when the active credit line is close to expiring and the system automatically triggers the renewal process, by creating a case and starting a TF Qualification, type Renewal.
    Triggered automatically.

  • Cancellation - Credit Line is cancelled when TF Risk decides to terminate the credit line for whatever reason. No TF Qualification needed.
    Triggered by the TF Risk user.

  • Re-Activation - Credit Line is reactivated when TF Ops receives a request to reactivate a credit line that has gone dormant/inactive due to the client not trading for the past X Months. This in turn creates a case record and starts a TF Qualification, type Application but Credit Line is marked as Re-Activated. Triggered by TF Risk user.

Note: The flows described above, except for Freeze/Unfreeze and Cancellation, aim to leverage the existing TF Qualification Process, whilst introducing a few enhancements.

Insurance (new object)

The Insurance object is a new object that will represent and store information related to insurances that can be associated to credit lines. The details of the new object are described here.

T&Cs (new object)

The T&Cs object is a new object that will represent and store information related to the T&Cs that will be sent to the client regarding a credit line. T&Cs can be sent at when:

  • a new credit line is approved;
  • an existing credit line is updated (increased/decreased);
  • an existing credit line is renewed;
  • an existing credit line is reactivated.

The details of the new object are described here.

UI

Account

At the Account level, it’s important that the user has an overview of all credit lines and governments schemes that the client has. This will help the user access relevant information quickly as well as better assess the state of the client’s business with Ebury, in regards to Lending.

For this, a new component will be embedded in the Account record detail page; this component will be built in LEX. The following diagram illustrates what this component will look like.

TF CLM - Credit Line Management Component

Link to full diagram here.

Additionally, the account detail page will be reviewed (remove fields that are no longer relevant, rearranged the sections, etc.)

Deal

From a Sales/Dealing perspective, we are assuming that there will always be only one TF Qualification in progress, therefore only one open case record associated with the deal.

Trade

Additionally, the trade detail page will be reviewed (remove fields that are no longer relevant, rearranged the sections, etc.)

Flows

TF Qualification

At present, TF Qualification flow supports a single credit line. Moving forward, since we are splitting the TF products and allowing the client to have more than one credit line, all steps of the process need to be adapted to cater to display multiple credit lines and allow users to operate them individually (approve, reject, back to sales, etc.).

TF FactFinder

The TF FactFinder form is the first step in the TF Qualification process; once it is submitted by Sales/Dealing, a new case is created and TF Risk initiates the qualification for the credit line. The following diagram illustrates what changes will be introduced to this component.

TF CLM - TF Fact Finder

Link to full diagram here.

TF Pricing

The TF Pricing request form, submitted by Sales/Dealing at Pricing Agreement stage, is another step of the process that will change to cater for multiple credit lines. The following diagram illustrates what changes will be introduced to this component.

TF CLM - TF Pricing

Link to full diagram here.

The rest…

For the rest of the steps on the qualification flow, the premise is roughly the same: adapt all steps to cater for multiple lines and allow users to operate in all of them individually.

Repayment Calculation

The standard repayment calculation will apply to almost all of the lending products, except for products like Invoice Finance, Term Loan or Purchase Order Finance. More information can be found here.

Reporting

Overall, the solution aims to introduce major enhancements to the current processes by improving data structure and quality, improving user experience and closing the gap on the parts that are not being properly tracked at the moment.

Regardless, because of the significant changes being made on the data model, the data itself will suffer changes and therefore the reporting. But this will only affect the data going forward; new reports that comply with the changes will have to be created. Historical data and historical reports will remain as is.

Activation

We must ensure that we are able to release the changes (deliverables) in a progressive way without going LIVE and without disturbing the current flow; we also must ensure backwards compatibility and that the process(es) cater for the coexistence of both data from old world (before changes) and new world (after changes).

In order to achieve this, there are a few aspects we will cover in this implementation:

  1. define activation settings - could be done by implementing a simple toggle on/off on the new functionalities or defining custom permissions for users/profiles (or both); but essentially, this will draw the line between old vs. new and allow for changes to be completed but kept inactive until due time;

  2. adapt the flow(s) to temporarily duplicate information - this means old world and new world will exist together for period;

  3. back-fill the new model with the existing data - this would require a migration of the all current active data into the new model;

  4. as post-go-live steps, sanitize the database to gradually close/remove old code, processes and/or data.

Alternatives

N/A

Caveats

Challenge #1

One of the fundamental changes we are doing is re-structure the data model, which means that how the data is collected, stored, processed and reported on will change significantly. Since the current Trade Finance flow was introduced, there is 5 years of historical data and it does not make sense to do a migration from old world (before changes) to new world (after changes); not only a deep analysis of the current state of the data would have to be done, but also we would need to define a migration strategy, which would significantly impact the scope of this project.

Instead the approach would be to focus on the data going forward and keep the historical data, and all that relates to it, unchanged. The challenge here is to make sure that data from the old world can still be accessed and reported on, even if done separately, and it can co-exist with data from the new world, for at least a period of transition. The proposal to tackle this challenge is described in the Solution > Activation part of this document.

Challenge #2

Another aspect that presents a challenge for this project is that the different parts don’t live in isolation, they are intimately connected with each other. For example, the application part of the process cannot go-live without the activation part, because they are both part of the same flow (Qualification) that onboards the client; similarly, we cannot have the full qualification piece ready to go-live, but not have the trading part, because when the credit line is approved, the client will start booking trades against it, calculations need to be in place, repayments need to be collected.

To get around this, we will adopt an MVP approach, where we’ll focus our efforts in building the process from beginning to end for one product - standard Trade Finance - then later, gradually, introduce the other products (Invoice Finance, PO Finance, etc). Trade Finance is currently our standard/default product and we already understand a lot about it as a business; a lot of the heavy-lifting would fall on the work to decouple the product from the Account and adapt all parts of the process. Then introducing the other products to this process would be more straightforward.

Challenge #3

This is a very long project, there are many different aspects that need to be covered, TF Qualification alone, for example, as a process has many steps that need to be properly analysed, enhanced and tested. The project will have multiple epics with multiple stories attached; it’s very likely that it will take more than a few sprints to deliver the full MVP implementation.

But this is a re-structure of a very crucial part of the business that has been long overdue, it’s important that we are able to get it right.

Operation

TF Credit Line Management will be largely operated internally, in the Salesforce platform. The main actors involved in the processes are: front-office (Sales/Dealing) and back-office (TF Risk, TF Ops, Onboarding).

However, the client will be one of the final consumers of the information, whether by accessing it through front-office or through Ebury Online platform (EBO).

Security Impact

N/A

Performance Impact

The basis of the core functionality is in place; what this implementation will do is expand on it by introducing more objects, therefore more queries, and a few more UI elements. Generally, the impact on performance should not be too severe.

Developer Impact

N/A

Data Consumer Impact

The data structure and the user experience will suffer changes. This will impact the way the final user will see and consume the data; also, in some of the parts of the process, the final user will need to be re-trained.

This project is being conducted in conjunction with the Product Team and the relevant stakeholders from the business side; the proposed solution should be agreed by all parties.

All parties should be notified of the progress, accordingly.

Deployment

Although the aim is to ensure the core processes remain, in their essence, the same, there are significant changes that will be introduced. And because we are dealing with a very sensitive part of the business, where certain parts are directly client-facing, we need to make sure that the rollout of the changes is done in a controlled way.

Therefore, the project will be split in different phases (or epics), each with their own set of achievables.

Dependencies

The implementation will affect Online Team; since a part of this involves exposing the credit lines for the client, through EBO, and allow the to book trades against them. This also affects TFO, which is in the process of being retired, so we either need to make sure TFO is fully deprecated by the time we go-live with this implementation or that it is compatible with the new changes.

References