Sorting out Risk in FinTech Source Chains
Most big banks (MUFG, Citi, Deutschbank, HSBC, JP Morgan, and others) have been forced to re-examine their external supplier relationships in a highly regulated environment. This is old news. But emerging technology is now beginning to create new ways to think about sourcing risk, which in the past has been a very manual, encumbered process. For global banks, the regulations will be different in each of the countries they operate in, and will cause executives to re-think how we standardize the gaps in the organization, and whether they are in compliance with the regulatory environment in each country. This has caused banks to look at the flow of activities in the “source chain”, which refers to the way that third parties use bank data for different opreations. Today, this end to end sourcing process has literally hundreds of different steps in the process. But the real benefit of technology is the promise of moving to a more efficient process, as well as the ability to better FORECAST and PLAN and BUDGET for our future supply chain activities.
Let’s examine the source chain in more detail. At the entry point, a business has a need they have to have fulfilled. This is generally done through a business strategy, which leads to a budgeting activity and a budgeting application by the financial planning group. The next process involves introducing a third-party risk management assessment. This third party will look at the engagement implied by the project, whether the process is done internally or through a third party, and assess the engagement through a risk lens. The tools here are very immature, and must be compliant with what are very general guidelines provided by the OCC and FRB policies, which are also written in a very general manner. Once the project has been assigned a level of risk by the third party risk assessment, it goes through a source to pay process, which includes various systems such as Coupa, Ariba or others. The sourcing request can generate a customer proposal, solution e-auction, supplier selection process, contract negotiation, and master agreement. Eventually this leads to a purchasing transaction, and to fulfillment, through a catalog, order release, then an invoice and accounts payable. The last stage in the process is where the elements of these transactions are entered into the ERP system where the General Ledger resides, and the transaction is fit into one of the GL accounts determined by the company comptroller.
One of the big challenges with this process, (which involves literally hundreds of individual steps), is the lack of visibility that occurs as a project proceeds through these stages. There is almost no visibility into where the “work in process” is, and today, most of these processes are connected through manual transactions (emails, phone calls, etc.). The process is not only complicated, but can take up to 22 months to go through the end to end process.
A further complication arises because of the inability to correctly classify the project, supplier, and procurement transaction. Comptrollers determine and set the GL codes, which are not always commonsense. For instance at one bank, all travel expenses fall under the GL code “Business Development’. Because of these challenges, the executive worked with his team to establish a new set of sourcing category codes that could be mapped back to the GL, which also allowed greater category-based analysis that aligned with a category structure, NOT the GL structure. Within each sourcing category, they have developed subcategories, and the risk associated with the engagement is now down at the subcategory level, (NOT for each and every statement of work that comes across separately). The subcategory risk is assessed for that class of supply, which then allows the team to develop six primary buying channels that can be used for each subcategory. This then allows some level of continuity between the different stages across the four different elements of the process. And this is effectively a bridge now between the systems, using the subcategory code that ties together the project budget, the risk assessment, the sourcing process, and the mapping finally to the GL codes. And for the first time, this will also help to build the ability to forecast and measure the flow of work across these different elements.
Another important outcome of tying back to a subcategory code is the ability to prioritize work that is coming across from different businesses at the portfolio level. Today, there is no way to prioritize work for the retail bank, for information security, the transaction bank, etc. In the past, prioritization of work inevitably got someone else upset that their work was being ignored, and eventually everyone would be upset! And businesses don’t understand why procurement is taking so long, without a full understanding of the hundreds of steps that have to occur across the system that was designed by the bank, NOT by procurement. But with visibility to the pipeline of work, and the ability to map workflow, there is an ability to provide reports that shed transparency on the process.
Understanding the Regulatory Risk Standards
Further discussions reveal other insights into the risk standards set up by the OCC (Office of the Comptroller of Currency). The risk standard set up following the financial crisis are officially known a “guidelines”, but are in fact very prescriptive. When there is a financial audit at one bank, the regulatory bodies that carry this out include auditors from multiple other banks. This tells you that standardization of regulations is “possible”, and not that it is a moving target.. However, the regulatory standards are still not explicit, and will always be a guideline that is subject to interpretation. But if programs at different banks are all compliant, one can assume that there is some level of commonality among the approaches being used. And there is a high probability that one bank’s interpretation of the policies, and what we think regulators will be asking for, will be the same things: data security, business continuity, data integrity, etc. There will certainly be a lot of elements around the contracts. And for this reason, the first stage in the evaluation of a program in a portfolio is always around the interpretation of the overall risk associated with the engagement. Once we understand the risk, we can overlay a taxonomy for a standard nomenclature for that level of risk and that market perspective.
It quickly became clear in this discussion of the sourcing process in financial services that there is no single tool that can be used to manage this end to end process. In the first stage, finance uses a budgeting tool, next there is a risk assessment tool, third a set of source to pay tools (e.g. Ariba), and finally the GL codes are embedded (PeopleSoft, SAP, or multiple ERP systems). Today, there is a need for a subcategory coding structure that “sits on top” of the process, that pulls data elements from each process and links them there a common subcategory code. The tool set that sits on top of the process provides a portfolio view of risk, as well as allowing how to prioritize efforts for managing the many different engagements that are underway. It also allows the team to see which business units have a higher priority, which isn’t possible without visibility.
Landscape for Emerging Tools
Emerging tools will be developed to help speed up the process include process automation and block chain, to automate the contract life cycle. Also, it was important to move risk out from the “end” of the life cycle (during evaluation of the SOW) to the front end of the design cycle, where a new process or product can be evaluated for risks such as data privacy, cross-jurisdictional transactions, etc. Spend is taking OUT of the risk equation. And it is notable that in many cases, risk levels have nothing to do with the level of spend. A $500M cleaning contract may be inherently less risky than a programmer writing security codes for $100K in Russia!
It is also important to link internal and external contracts to evaluate risk. A single contract with an external supplier (say HP global contract) may span more than 300 internal contracts across different business units, and each of these may be treated as different relationships by regulators in each of the different countries they span. And the internal transfer costs between different legal entities may also be reviewed by regulators, and viewed as a different supply transaction. Thus it become important to be able to look at the end to end process, and to track the source of the original contract to determine how they span and link back to a single contract.
To help create a balanced approach for risk assessment, a number of banks have created an entity called “Truesight” to provide risk assessments. This entity uses 1200 questions with almost 90% overlap among the four, that will become hopefully a clearinghouse for risk. The idea is that suppliers struggle to go through each banks individual risk assessment process, and a single process could prove to be better for everyone involved. The challenge is that risk assessments are done once a year, are timely and costly. What is really needed is a behavioral analytics program, to monitor internal and external activity, which will trigger to start a risk assessment based on certain noted irregularities. The trigger could come at any time, and target a review based on certain guidelines. This would be similar to the Amazon or E-Bay “Vendor Score”, which is updated in real time. Banks would support such a tool if it covered all of the risk assessment requirements, covering and providing insights into changes in behavior. And just like the credit card monitoring process, such a system could leverage what one company is doing, and have 4-12 others leverage the same data. Coupa is set up for something like that as well for items such as data security, data protection, general business information, personal information security, etc. This could also be aligned with the sourcing category structures being developed at several banks, as the language and contract structures are very similar in assigning the risk criteria. This in turn drives similar transactional events on how to structure the SOW or the PO used. The problem today with doing this at the individual transaction level, is that the trigger for risk assessments often are more expensive that the value of the contract for low spend items!