The digital future of syndicated loans
Loans & Tech: Now and the future
24 May 2019
Are we at the dawn of a new era in which a syndicated loan is seamlessly negotiated, executed, recorded, funded, managed, traded and regulated entirely on one technology platform? While this might be a little further on the horizon, financial institutions are already using or trialling a range of technology tools in all phases of the loan life cycle, from origination to secondary trading, and in key functions such as loan servicing and risk management.
Loans and Tech – Now and in the future
In this long read, we explore the benefits and opportunities, as well as the legal, regulatory and practical challenges, of some of today’s most talked about technologies in relation to syndicated loans.
DLT platforms for loans
“While DLT is at an early stage of development, it has the potential to deliver significant benefits in financial services.” - UK Government Cryptoassets Task Force report, October 2018
DLT may be used to store data, transact securely and automate processes in the context of many different financial contracts and services including loans, bonds, derivatives, trade finance and securities trading. Features of a DLT platform which make it attractive are the ability to transact autonomously without a trusted third party, records of transactions are identical and synchronised, and data on the ledger is secure, traceable (as only authorised participants using cryptographic technology can enter data) and immutable, i.e. it cannot be altered or removed. With DLT, reconciliation is embedded within the system. The parties are able to more efficiently, accurately and transparently record and track payments and obligations, such as primary allocations on syndication, lender commitments and participations, lender transfers and assignments, as well as borrower and obligor accessions and releases (without the need for duplicative manual entry processes across multiple databases of agents, arrangers and lenders).
Public or private DLT platforms?
One of the best known use cases of DLT is bitcoin, a public ledger system. The public ledger holds an immutable record of transactions which is visible to anyone (albeit the ‘owner’ of any given bitcoin is identified only by reference to a computer address). However, for financial institutions, privacy, security, compliance and control concerns mean it is unlikely such a public ledger would be suitable for many financial services applications. A permissioned or private ledger system is more likely to be adopted with limited identifiable participants (e.g. obligors, lenders, arrangers and agents).
Legal and practical considerations
Private DLT platforms necessitate an element of centralisation, such as an operator with overriding administration of the system – controlling who should be permitted to join, how and the circumstances in which participants might be ejected from the system. In practice this is likely to be governed by a detailed legal framework agreement agreed between the initial parties and acceded to by future participants. Amongst other things, the legal framework will have to govern risk allocation, default events and commercial terms.
Participants building such platforms need to be mindful of regulatory requirements, as well as outsourcing rules, cybersecurity, legal issues relating to title, security and settlement finality and antitrust considerations. A major antitrust consideration is the need to avoid any exclusionary effect which might foreclose competition by preventing parties from accessing the platform – particularly if the platform becomes an important gateway to competing in the market. This extends also to ensuring in such circumstances that access and participation is provided on fair, open and nondiscriminatory terms.
While initiating participants might benefit from preferential terms at the outset (especially where they have contributed assets or it is a necessary part of recouping investment) this will be more difficult to justify over time if the platform becomes important industry infrastructure and the impact of any such preference is profound.
The other main competition concern is to ensure through the establishment and adherence to appropriate compliance protocols that the platform does not become a vehicle for the inappropriate exchange of competitively sensitive information and/or the coordination of competitive behaviour.
A further practical point to note is the need for interoperability, i.e. the ability to communicate and share data with other platforms (including legacy bank systems). This is one of the biggest challenges to industry-wide use of DLT platforms. APIs (applied programming interfaces), which allow different software applications to communicate, help to integrate different platforms but there is still some way to go. For example, parties cannot yet complete payments in US dollars, euros, pound sterling or other fiat currencies on a DLT platform. Automated payment would therefore require interaction between the DLT platform and existing banking systems.
Smart contracts for Loans
“Smart contracts have huge potential in terms of efficiency and cost. Sadly, they are not yet so smart as to entirely remove the risk of disputes. But I am confident that courts will adapt to the technology and reach the right legal and commercial outcomes.” Kate Scott, Litigation and Dispute Resolution Partner, Clifford Chance
Smart contracts could make loan servicing more efficient and provide a more seamless customer experience. A key benefit is their ability to automate data and payment flows more highly. For example, a borrower could submit a utilisation request electronically and a smart contract-based facility agreement could check that the request complied with relevant terms (such as minimum amount, currency, availability period). If so it could execute instructions, e.g. automatically deducting participations from lenders’ open credit lines and initiating the payments.
A smart contract could also check compliance with certain undertakings, e.g. delivery of financial statements and compliance certificates or compliance with financial covenants.
In order to complete a task, a smart contract may require information (data) from an external source, known as an “oracle”. For example, in order to calculate an interest payment, it may request a reference rate from an external body (such as, for current LIBOR related rates, the London interbank offered rate administered by ICE Benchmark Administration Limited and displayed on the relevant Thomson Reuters screen page).
While much of the current industry focus is on DLT and smart contracts, technology is rapidly developing and it needs to be acknowledged that ultimately this may not be the tech solution adopted by the market
“The syndicated loans market is the perfect candidate for a technology upgrade. But, digitalisation comes with challenges – legal, regulatory and practical – which need to be identified and navigated.” - Peter Chapman, Regulatory Partner , Co-head Fintech Group, Clifford Chance
What do we mean by automation?
In this section we focus on automated performance under loan agreements by way of smart contracts on DLT platforms. However, automation can also be used at a much earlier stage and transform the drafting process. The use of tech tools to assist in the creation of documentation (whether an initial draft or in final form) is not new but it is increasing, bringing the benefits of speed, efficiency and quality control. These tools can be combined with DLT so that the negotiation process and the final agreed terms are stored on a blockchain platform.
Can loans be fully coded and performance automated?
The answer depends upon the facility agreement and the software. A short low-value facility agreement with little optionality will be easier to code and automate. A long highvalue syndicated facility agreement, running to hundreds of pages, with complex clauses and many negotiated (i.e. non-standard) terms will be harder to code and automate.
The spectrum of automatability of common clause types is set out opposite. Simple conditional actions (“if x, then y”) are more straightforward to automate. For example, the borrower shall repay the loan on the date specified as the termination date: or, to put it another way, if the termination date occurs, then the borrower shall repay the loan.
A simple conditional clause may not operate in isolation and other clauses of the facility agreement may need to be taken into account and built into the coding. Using our example, automation should ensure that if the termination date occurs, then the borrower shall repay the loan and pay any accrued interest, tax gross up or indemnity. Another example would be where a lender is obliged to pay a borrower but that lender may first set off any amounts due to it from that borrower.
Complex clauses are more difficult to automate, particularly where there is ambiguity or assessment required. An example would be “material adverse effect” (MAE). The definition of MAE can be heavily negotiated but it will be some variant of the following: MAE means, in the reasonable opinion of the majority lenders, a material adverse effect on the business of the borrower or the borrower’s ability to perform its obligations or the validity and enforceability of security or other remedies. The deliberately general wording gives lenders flexibility in unforeseen circumstances while the borrower has the protection of a “reasonableness” test (which has been tested in the courts). Removing such generality and flexibility may not be a route that market participants want to take.
Automation on a large scale will be easier if terms are standardised. While the LMA recommended forms for syndicated loans go a long way towards standardisation, they are only a starting point for negotiations and LMA documents are dynamic, changing in response to legal and market developments. Furthermore, borrowers may not use these “standard” forms. In particular, large corporate groups and private equity sponsors are likely to have their own preferred documents.
Should loans be fully automated?
Are there aspects of facility agreements that borrowers or lenders will not want automated? Or, if automated, will want the right to suspend or override?
While technology will improve many back and middle office functions, much of the lending process involves a relationship element. It is hard to imagine that technology will entirely replace human interaction in bidding for mandates or selling down loans for example, although the extent of interaction may be reduced.
If things go wrong and an event of default occurs, a loan agreement typically gives the lenders the option (after agreed grace periods having expired) to demand immediate repayment of outstanding loans or put outstanding loans on demand. However, exercising this option is discretionary and lenders and borrowers have the opportunity to discuss the situation and the way forward. Borrowers (and lenders) are likely to want to retain this flexibility. A smart loan contract could, however, identify that an event of default has occurred and notify the parties that action is required (rather than automatically accelerating the facilities).
How will borrowers react? What are the legal implications?
Although automating loans has clear operational benefits for lenders and agents, borrowers may be less motivated to change.
Fully coding and automating a facility gives rise to some interesting questions from a borrower’s perspective. If representations, covenants, events of default and notification procedures are written in code, will directors, management and corporate treasurers be comfortable that they know what needs to be done in order to comply with the terms of the facility? How can they be sure that the code reflects their intent? A “natural language” version of the agreement could sit alongside the coded version. With two versions, the potential for conflict, or disagreement as to the correct contractual interpretation, increases. It would be prudent for parties to decide in advance which version has priority if a discrepancy arises.
Parties (and courts) will need to decide how to deal with new risks that come with new technology. For example, who will be responsible, and what will be the remedy, when (rather than if) the code does not run as expected or data inputting is incorrect? Liability may lie with the coder, or with the lender that set up the process. Parties may seek to assert that the platform itself has not operated as expected, but in some cases it may be complicated to identify the party against whom to bring a claim.
What will the remedy be if the contract implements automatically but the conditions for implementation were not met (e.g. a loan is drawn down when there was an event of default)? Once self-executing code has been properly recorded on the blockchain, it cannot be altered, which creates difficulties if one party wants to amend or unwind the contract (e.g. on the ground of fraud). Whilst blockchain does not allow the deletion or amendment of a transaction that has already been recorded, a possible solution would be to allow “reverse transactions” which seek to restore the parties to the position they would have been in had the deficiency not occurred.
It may also be possible to provide that the ledger can be altered or overridden by consensus, and to include this at the outset of the smart contract or in an accompanying legal framework agreement. However, this would require all participants to agree to the override and could create scope for disputes where one party does not consent. Certain events could also be written into the code to govern how the contract would respond in certain circumstances e.g. to terminate or renegotiate. However, as discussed, the more complex clauses will be harder to code and automate.
Understanding the litigation risks is key to minimising the potential for disputes. Responsibilities and liability should be clearly allocated, due diligence and testing of smart contracts rigorously conducted and regular updates applied. Processes and rules for how to apply these steps could also be set out in an accompanying legal framework agreement.
When disputes arise, there is increased scope for satellite litigation around jurisdiction and governing law, given that servers will often be decentralised and spread around the world. Parties may need to pinpoint where an error occurred in order to identify the applicable law and forum for their disputes.
What could facility agreements look like in the future?
While operational efficiency would point towards a single automated electronic agreement, other factors, not least the inability of lawyers to code (or coders to write legal contracts), may lead parties towards a combination “natural language” and coded agreement, partly automating processes but still maintaining natural language terms.
It may be that facility agreements are structured differently, e.g. a short coded or codable term sheet, with key commercial data points (such as pricing and loan amount) and negotiated terms, together with a standard form framework agreement.
Signing loans electronically
“Contract law in the UK is flexible, but some businesses are still unsure if electronic signatures would satisfy legal requirements.” - Stephen Lewis Law Commissioner (2018)
If electronic platforms and the digitalisation of contracts are the way forward, would the law recognise an electronic agreement which is signed electronically? Can electronic records be presented as evidence to support the existence and authenticity of a contract?
Both the English Electronic Communications Act (ECA) and the European eIDAS Regulation recognise electronic signatures and electronic documents as admissible evidence in court. However, it is up to the court to determine the evidential weight attributed to such electronic signature.
Any electronic signature which meets the strict criteria for a “qualifying electronic signature” (or QES) under the Regulation has the same legal effect as a handwritten signature. Although, many types of e-signatures do not meet such criteria.
The English Law Commission published a consultation paper in August 2018 in which it provisionally concluded, on the basis of existing case law, that an electronic signature is capable of satisfying a statutory requirement for a signature under the current law where there is an intention to execute the document. Can formalities be a limitation? There are some specific instances where an electronic signature will not be sufficient. For example, there is uncertainty around electronic execution of documents as deeds under English law and whether the formalities required to execute a deed can always be satisfied electronically, e.g. a witness attesting a director’s signature. However, under the Companies Act 2006, an English company can validly execute a deed without witnessing if it is signed by either two directors or one director and the company secretary. Many secured transactions require a deed where, for example, security documents contain a power of attorney.
Documents which must be filed at a certain public registries, such as HM Land Registry, and documents subject to formalities like apostilling or notarising (common in many European civil code jurisdictions for credit facilities over a (low) de minimis threshold and security documents) may need to be written documents signed with traditional hand written or “wet ink” signatures.
Different jurisdictions have different formalities and requirements for an electronic signature to be effective. This is an area where law could be changed and harmonised to facilitate the advancement of technology.
“Outsourcing KYC-related functions comes with risk, but is that risk necessarily any different from performing those activities in-house? There is no such thing as a risk-free business, and with outsourcing it is all about managing the risk appropriately.” - Andre Duminy, TMT Partner, Clifford Chance
KYC (know your customer) is a particular pinch point in lending. KYC, AML and CTF risk assessment is subjective, which can lead to different interpretations of risk, and financial institutions will have different documentation and evidential requirements.
Multiple KYC processes with different documentary requirements can be an administrative burden, time consuming and costly, not to mention frustrating for borrowers. Ongoing KYC issues can delay sell-down/primary syndication and settlement of secondary loan trades, with balance sheet and regulatory capital implications.
KYC delays are often cited as one of the most significant factors in long settlement times for secondary trading. It is not unusual for a fund buyer to allocate a trade across a number of legal entities or sub funds, often well into the sale process, which can delay KYC processes.
Can technology improve KYC?
Greater consensus on what is required for KYC checks and an accessible repository for KYC due diligence materials would make the KYC process more efficient – whether that is a single utility provider or via a decentralised system.
A secure DLT-based repository could be made accessible to arrangers, agents and lenders with the KYC data validated and updated over time, but such a system does give rise to critical questions of reliance and reliability. Ultimately, whether financial institutions may get comfortable with such a system will depend on the extent to which financial institutions are willing to outsource aspects of the KYC process, to whom, on what terms and with what recourse.
Outsourcing KYC-related functions is fairly commonplace, although there are limits on the art of the possible within the current regulatory environment. Firms cannot outsource accountability for their regulatory responsibilities, so if an outsource KYC provider gets it wrong, the firm and its senior management will still be accountable. Outsource providers mostly do not assume uncapped liability for fines that may be imposed, and cannot indemnify against criminal sanction or personal accountability – which would leave the firm exposed.
Where third party providers are used and relied upon (whether that is in the context of a centralised utility or as, for example, a validator in a decentralised system), financial institutions will want to review their operational dependency and develop protocols to manage risk – for example if there were to be an outage and KYC checks could not be performed.
While efficiency points towards a single source for KYC data, from a regulator’s point of view this natural monopoly brings with it concentration and, consequently, systemic risk.
It may be that a technology solution to improve KYC for loans will be part of a wider solution to improve customer due diligence, onboarding and profiling across product lines and institutions
Secondary loan trading
“The secondary market for syndicated loans will be revolutionised almost instantaneously if the primary market adopts blockchain technology and KYC is digitised.” - Faizal Khan Finance Partner, Clifford Chance
Making trading more efficient and shortening settlement times is an industry-wide goal. Can technology help?
As discussed, it is widely recognised that KYC delays significantly increase settlement times and technological solutions to speed up KYC would be a huge leap forward.
Technology could also make transfers more efficient. If transfer certificates and assignment agreements were processed electronically, smart contracts could automatically check compliance with the facility agreement (e.g. minimum transfers and holds), execute the transfer, update the register of lenders and notify the borrower of the new lender (and its tax status for withholding purposes). Depending on the sophistication of the platform, instructions to initiate a payment between the buyer and seller could be directly linked to the transfer of title so as to minimise settlement credit risk.
In reality, effecting a transfer of a loan electronically may be easier in some jurisdictions than others. Europe is a patchwork of different legal systems and in some countries loan assignments must be in writing and notarised to be effective (or to have the fullest level of legal protection in the case of a borrower’s insolvency).
In Europe loans are less easily transferable than other assets, such as bonds. Many facility agreements require the borrower’s consent as a condition to transfer – and sometimes the consent of the agent or issuing bank as well. An electronic system could automate delivery of consent requests but slow response times are still likely to delay settlement.
Loans could also be tokenised i.e. an electronic instrument representing entitlement to the debt obligation could be issued on a DLT platform. That instrument or token could be traded and transferred on the platform. However that raises another layer of legal and regulatory considerations (including questions as to whether the token might be a transferable security and fall within the ambit of, for example, MiFID2 and the Prospectus Directive.
AI & Loans
“The adoption of new AI tools requires careful implementation with adequate controls – mistakes have the potential to destroy firms’ reputations.” - Jonathan Kewley, Co-head Tech Group, TMT Partner, Clifford Chance
The application of artificial intelligence, machine learning, natural language processing, data analytics and data algorithms to business has received increasing publicity. As a heavily regulated industry, financial services can expect its fair share of scrutiny, both in the public eye and from regulators.
Pricing and risk
Due diligence and data analysis to assist in loan pricing and risk management is not new. It has always been an important part of bidding for mandates and successful primary syndication, as well as one of the drivers for selling/buying loans. Lenders assess the creditworthiness of potential borrowers, seek to set risk-adjusted loan margins and monitor and cap their aggregate risk exposure in loan portfolios (e.g. to industries or geographies).
The rise of AI
What has changed is the power of computing and AI to analyse and learn from large amounts of data. This might be an analysis of a lender’s own internal data, such as recognising patterns in a lender’s non-performing loan portfolio. It might be an analysis of data from external sources, such as publicly available news.
Emerging online lending platforms have harnessed technology to analyse alternative data, such as cash flows for a small business or bank account transactions for individuals. However alternative or big data analysis is also attractive to more traditional mainstream bank lenders as part of informed decision making.
Adopting AI brings its own challenges. AI’s ability to evolve and use complex statistical algorithms can make decision processes opaque. There may be unexpected outcomes or potentially discriminatory or biased decisions: something which financial services regulators are increasingly attuned to. Furthermore, financial institutions need to ensure their use of AI is not anti-competitive: for example, if financial institutions were to implement algorithms which had the effect of competitors colluding on pricing. There is also an increased risk of market abuse as it is becoming increasingly difficult with new types and increasing volumes of data to distinguish between information which is publicly available and data which is non-public and therefore potentially inside information.
Compliance, regulatory, legal and internal audit teams, as well as senior managers, need to be comfortable that AI adoption does not lead to opacity or poor customer outcomes, that data sources and technologies used are clearly understood and that risks are identified, controlled and monitored. Failures on this front may give rise to enforcement action against individuals or firms.
Of course, there may also be cybersecurity concerns if the technology infrastructure is deployed and the data is held in the cloud, not to mention data privacy considerations, such as GDPR compliance where personal data is involved.
On a practical level, mistakes around AI have the potential to destroy firms’ reputations. Financial institutions need to embed a culture of transparent, ethical use of AI within their organisations.
It is clear that regulators will be highly-focused on technology adoption going forward. The Financial Stability Board, for example, warned that the interdependency between the financial sector and big-techs could cause an “IT risk event to escalate into a systemic crisis”. The FCA has also warned of the risks of outsourcing and technology.
AI and document/data management
Market developments such as Brexit and the transition away from LIBOR have encouraged financial institutions to explore AI tools which can be trained to quickly and accurately review documentation in large loan portfolios and identify or extract relevant clauses. The quality of data in loan portfolios will impact on the effectiveness of such tools, which has led to increased focus on the way documents are tagged and stored. Digitalisation of documentation could greatly assist with document and data management.
AI tools can be trained for various purposes, including “red flag” reviews of documentation and data extraction. Data extracted can be used for multiple internal functions such as reporting, audit and compliance. Various technology tools, including RPA (robotic process automation) and OCR (optical character recognition), are assisting with extracting, editing, entering and searching data.
Disruption or evolution?
“Data creates opportunities for innovation, but also can drive harm.” FCA Business Plan 2019/20
Technology can bring a wide array of benefits to the loans process, including reducing costs, risks and processing times, easing friction points between parties, the provision of secure transaction records and better-informed decision making.
Adoption of new technology will bring its own challenges – not least the difficulty of reaching sufficient consensus and critical mass amongst market participants, overcoming potential regulatory concerns and integrating technology into existing or new legal frameworks. However, action and discussion to overcome these challenges has already begun.
Have emerging technologies and fintechs disrupted traditional financial services as predicted? Yes, in the sense of driving new models for delivery of financial services. No, in that traditional financial service providers are part of the transformation, helping to develop technology solutions and collaborating with fintechs and technology vendors.
Questions remain as to how technologies like DLT can scale-up to cope with the volumes required in the financial markets and how to make them sufficiently robust. Yet the application of such technologies has moved from ideas stage to proof-of-concept testing to building in a relatively short space of time. The journey for some may have just started, but we expect change to accelerate in the very near future and businesses will need to evolve. And quickly!