In this post, we’ll talk about invoice factoring (to put it simply, loans against receivables) and some of the common technological and data challenges encountered by both lenders (factors) and borrowers. We will then propose a solution to these working capital financing challenges involving Daml smart contracts running on either enterprise blockchains or databases: 

1. Outline an illustrative workflow
2. Demonstrate the smart contracts that achieve the workflow
3. Discuss deployment of nodes (blockchain or database)

Daml enables developers to get started without having to worry about locking in the underlying enterprise blockchain platform when the program is not fully defined. That’s because Daml is fully portable across multiple blockchain and non-blockchain platforms. Daml smart contracts also have a built-in rights and obligations model with granular privacy baked in, making Daml an ideal choice for modern software development when there are multi-party workflows involved. Here are some comparisons of Daml with Solidity, Python, and Kotlin & Java.

If you are an enterprise blockchain developer, you’ll notice in the code samples that all of the complexity of checking authorization, key management, and database management have been abstracted away. What you have is a smart contracts language fully focused on the business workflow you want to write — making your time-to-prototype extremely fast.

Technology and data challenges in factoring

The size of the global invoice factoring services market is expected to reach USD 5,973.9 billion by 2028. Businesses use factoring to receive funds against their receivables, and these funds are used as working capital or to procure specialized material to service an order. For businesses that work on long payment receivable cycles or are capital intensive, factoring is crucial to maintain the needed liquidity.

Some common technology and data-management challenges in invoice factoring are as follows:

1. Duplicates and/or fraud: A borrower may submit an invoice to multiple factors or submit a non-existent invoice. The process to verify the invoice is complex, but the alternative to verification is the risk of non-payment. Although some of these instances could simply be the result of process errors, the overhead of resolving these errors (e.g., refunds, delays due to verification, etc.) is significant.    
2. Workflow status: Factors and borrowers often interact through portals, which could be custom-made or third-party platforms. These solutions take over where the enterprise process ends. So, the end-to-end tracking of the workflow has to follow several offline methods (think, “Where’s my payment stuck right now?”)
3. Data reconciliation: Managing so many different systems leads to the challenge of constant reconciliation in order to accomplish basic operations management and reporting. Such reconciliation leads to errors, and these data-quality issues lead to higher costs and the inability to make effective use of analytics.

Thus, the question is: How can we simplify this complexity and work from a mutualized workflow and data layer that is fully private, yet provides real-time updates and requires no data reconciliation?

Daml smart contracts solution overview

By using Daml smart contracts and blockchain (or enterprise blockchain for permissioned networks), we can address these challenges in a scalable fashion. For the sake of simplicity, let’s consider the following illustrative workflow:

Note: For the sake of simplicity, we are omitting some steps such as a possible standing agreement between the borrower and the factor. We are also assuming here that a rate of 2% has already been agreed between them. In addition, the payor may want to negotiate different payment terms as well. All of those are simple extensions to this invoice factoring workflow. Post your questions in the daml community forum and we’ll be happy to help you.

Step 1: In the first step, the borrower submits the invoice to the factor. The code for the Daml smart contracts looks like this:

As you can see, both lender and borrower are denoted by the Party datatype. All of the privacy and permissions are handled by Daml at this level automatically. So in this contract, if Borrower A submits an invoice to Lender A, then neither Lender B not Borrower B can see it. Daml makes it impossible for that contract to be accessed by a non-entitled party unless specific business logic is created to make that sharing possible. That’s an example of why developers don’t have to worry about coding these constraints like they have to do with other languages.

You’ll also notice the Controller keyword. This one means that only this party is authorized to take the specified action of ValidateInvoice on this contract. If the borrower tries to perform this action, Daml will deny the request. This granular rights model reduces risk of developer error. It isn’t hard to imagine how much of your code today caters to this authorization and eligibility verification mechanism that has been taken under the hood by Daml.

Step 2: The factor must do some kind of validation. In the above code snippet, they do that by sending the invoice to the payor. The resulting contract that is created is shown below. The original contract is archived and no longer available so it cannot be submitted again to the payor. 

Think back to when we mentioned duplicate invoices as a challenge for working capital financing in supply chain and trade finance. In this solution, we can easily address that because the payor has a single source of information. So, their overhead is dramatically reduced as they confirm or deny an invoice. That validation is not shown here, but it’s easy to add now that we have a common (and private) data layer.

In our example, the payors have a single choice of ApproveInvoice. We can put in other functions to make this use case more robust (e.g., reject an invoice), but we kept those scenarios out for simplicity.  

Step 3: When the payor confirms, the payment is made to the borrower, minus the factoring charge. And the payor can simply pay the factor:

As with any payment flow, we can now easily build in the payment reminders or collections flows as needed on the enterprise blockchain.These have been done on the FactoredInvoice contract that was created.

And finally, when the payor makes the payment, the invoice can be marked as settled.

Summary of Daml Solutions 

For developers and architects, Daml provides an ideal option for solving issues in invoice factoring, as it provides for full flexibility in choosing an enterprise architecture, as well as the underlying persistence layer — a public ledger, enterprise blockchain, or database. As you saw in the code above, smart contracts written in Daml allow the focus to remain on the business workflow, rather than on the technical plumbing. As a result, your business rules are no longer fragmented. Daml is already in use at some of the world’s largest enterprises, including Goldman Sachs, HSBC, Australian Securities Exchange (ASX), and the HongKong Securities Exchange (HKEX) 

Additional languages and components in your business layer such as .Net core, Java, or Node.js, and the front-end frameworks and libraries such as ReactJs do not need to be changed. Daml is a smart contracts layer that houses the multi-party workflow and the rules that drive that workflow. Your existing enterprise applications can simply interact with the Daml layer using the auto-generated API layer. All you have to do is to code the workflow above, and the Daml runtime does the rest.

This exact Daml code can be deployed and will run on a multitude of blockchain ledgers, including Corda, Fabric, VMware, Ethereum, and more. An enterprise blockchain ledger may be needed when individual parties wish to have their own nodes, so that they can maintain physical privacy and segregation of their data. In fact, each of these parties can decide to be on different enterprise blockchains running Daml smart contracts, and the business process can be executed seamlessly through Daml’s interoperability protocol. 

To learn more and to engage with Daml, please visit our Daml tutorials and join the community. 

If you want to master Daml smart contracts, you should also read:

• Interoperability between different markets and how Daml fits,
• Programming Smart contracts - A look into Daml, Kotlin & Java
• How easy it is to learn Daml,
• Some of the reasons why Daml and not Java or Solidity,
• Daml brings a paradigm shift as a programming language,
• How privacy in Daml differs from the rest and why it’s better.