Getting the Digital Business Transactions Right

So far in this series, we have covered digital trust, that requires digital transactions. We have also covered digital money, which also is essentially powered by digital trust and transactions. Let’s expand our view even broader to cover digital business transactions.

First, we need to define the “Business transaction”. We’ve learned that AI, such as chat.openai.com, is pretty good at providing definitions. Here’s what it said:

A business transaction is a trade or exchange of goods, services, or financial assets. In a business transaction, one party provides something of value to another party in exchange for something else of value. For example, when a customer buys a product from a store, the store provides the product to the customer in exchange for payment. This is a business transaction because both parties are exchanging something of value. The transaction may be recorded in a financial system to track the flow of goods, services, and money between the parties involved.

Let’s dig in a bit deeper. How is a settlement transaction, that was discussed in the part 2 of this article trilogy, related to a business transaction?

Settlement transactions are a type of business transaction that involves the transfer of funds between two parties to finalize a financial agreement. For example, when a customer buys a product from a store, the store may send a request for payment to the customer’s bank. The customer’s bank will then transfer the agreed-upon amount of money to the store’s bank to complete the transaction. This is known as a settlement transaction because it settles the financial agreement between the parties involved. Settlement transactions are typically done electronically, using systems like the Automated Clearing House (ACH) or the Society for Worldwide Interbank Financial Telecommunication (SWIFT) network.

In other words, the settlement transaction is something, that happens between two or more (legal) persons, typically banks, in the context of a financial system.

On the other hand, the business transaction is something, that happens between two or more persons in a broader context. Typically, at least one of the persons is a legal person, i.e., an organization. The parties of a business transaction have their own databases for various purposes, that need to be updated to reflect the transaction agreed with the other parties. The business transaction also contains a settlement transaction.

See the big picture, and the problem therein?

The poor real-time transaction management is not just a problem of the current financial system. The same problem is practically with all business transactions. They are managed today essentially in the same way as how the settlement transactions are managed. They are split into a sequence of small transactions, that are executed according to instructions sent and received using various messaging channels, some of which are digital, e.g., purchase order messages, and some of which are analog, e.g., paper invoices.

Similarly, as with today’s settlement transactions, the eventual consistency of the overall transaction is guaranteed using various checks and double checks. “Reconciliation” is the term often used here. Each of the small transactions of the chain requires its own reconciliation routines to ensure the eventual consistency of the entire chain. Many of these reconciliation steps are manual. For example, an invoice may be sent electronically, but any disputes about the invoice typically require sending an e-mail or making a phone call.

If you calculate the total number of reconciliation actions required by a single business transaction and its settlement transaction, you easily end up with a fairly big figure. Each of those reconciliation actions costs both money and time. The long chain of steps also means, that tailoring the business transactions to match the requirements of the businesses is expensive and inefficient. A single change in the functionality of the business transaction may require changes on many of the “component transactions” and each of those changes may have an effect also on the reconciliation processes, which, as we know, are often manual.

In other words, the business transactions are long-lived transactions, whose current state and hence, value are not known to anyone in a real-time manner. The total cost of executing those transactions is also unnecessarily high. Also the cost of further development of the business transaction network is very high.

The big question seems to be: Can we make the economy real-time the same way as we can make the financial system real-time? Can we also make the economy run more efficiently and become more flexible?

In the previous article of this trilogy, one of the conclusions was the definition of total money in the system:

The total amount of customers’ money in the system is money in customers’ bank accounts

amended with the money in transit.

It is a tempting idea to expand that idea to the context of broader transactions, i.e., business transactions. Here’s the outcome.

The current state of the economy = Completed transactions persisted in the various databases of the participants of the economy + Currently active transactions occurring between the participants of the economy.

Today, a very small portion of the currently active business transactions are properly managed so, that their status at any given point of time is known to those, who might need to know it. Consequently, the current state of the economy is quite poorly known. This leads into a situation, where new business transactions often need to rely on old information about the state of the participating businesses.

Because of the inaccurate “baseline”, different actors need to maintain various “resource buffers” in their operations to keep their business running. In the case of banks, for example, these buffers are liquidity buffers residing in the accounts of different counterparty institutions. Freeing up those buffer resources for productive purposes is generally a good idea.

Imagine a cash-strapped small company, who receives a large purchase order from a large and wealthy company. That committed purchase order increases immediately the value of the small company in a significant manner because new contractual obligations are now in place. However, the small company cannot utilize this created value in its operations immediately, as there is no easy trusted way to communicate the value created by the new, but still ongoing transaction to those who would need that trusted information.

I am convinced, that making the ongoing business transactions as a trusted source of financial information is the key to making the economy much more efficient and fairer to all its participants.

We all who haven’t lived under a rock for the last decade have heard the gospel of Blockchains as the solution for all our problems concerning trust, money and business transactions. This article trilogy covers those three things, as they are the most significant concepts of the economy and they all have been supported poorly by the current IT systems and networks.

In the previous articles, I already concluded, that blockchains are not a proper technology for digital trust. Nor are they a solution for digital money. The same seems to apply also to digital business transactions. Why is that? Let’s hear it from my new friend, The Artificial Intelligence.

There are a few reasons why blockchains may not be well-suited for running legal business transactions.

First, blockchains are typically designed to be transparent, which means that all transactions on the blockchain are publicly visible. This level of transparency may not be desirable in some legal business transactions, where the parties may want to keep the details of the transaction private.

Second, blockchains are typically decentralized, which means that they are not controlled by a single authority. This can make it difficult to enforce legal agreements on a blockchain, as there is no central authority to enforce the terms of the agreement.

Third, blockchains are often slow and expensive to use. Because each transaction on a blockchain must be verified by multiple parties, transactions can take a long time to process. Additionally, the fees associated with using a blockchain can be high, which may not be cost-effective for some legal business transactions.

Overall, while blockchains have many potential uses, they may not be the best choice for running legal business transactions. Other technologies, such as traditional financial systems, may be more suited to this purpose.

The AI not only told us, why not to use blockchains, but also gave us a pretty good hint about the direction, where the solution might lie. Of course, we would not use traditional financial systems as the foundation of innovation here. Instead, we probably should use an innovative future financial system as the candidate foundation, as it indeed is advantageous to have the settlement part of the business transaction integrated with the rest of the business transaction as seamlessly as possible.

Let’s dig in…

The previous article about digital money described a network for settlement transaction execution, that had four major components: the existing banking systems, the existing messaging system between the banking systems, agents that connect the existing banking systems and their customers to the network of trust and agents (“transaction spaces”) that execute multi-party transactions in the network of trust.

If we want to replicate the model, that we designed for digital money, to be applicable also for digital business transactions, we need to construct the solution from similar components. Let’s see, if we can design a network, that is suitable for executing a financed purchase-to-pay process all the way from a purchase order to the settlement in an efficient manner.

Our primary goal is to fix what’s broken. That’s where the big rewards lie. The general idea is to use as many capabilities as possible from the legacy systems that is feasible and to add the missing capabilities to the business network using the network of trust.

In other words, the action plan is:

1. to build a network of trust by providing digital identities to all participants, i.e. persons and services, of the economy, and
2. to build transaction spaces to that network for providing the transaction management functionality that is missing from the business networks.
   
   

Digitalizing the persons

Business transactions occur between persons. The persons may be natural or legal persons. A business organization is a legal person. In a typical business transaction, at least one party of the transaction is a legal person. The ways, how natural and legal persons get, maintain, and use their digital identities are somewhat different.

Once the agent has been created for the person, he/she may access all those transaction spaces in the network, for which he/she has the credentials required by the space. The banking relationship credential is in many business transactions all that’s required from a person to participate. The person may get new credentials from those spaces as the result of transactions executed in those spaces.

Like a natural person, the agent for a legal person can be created using a trusted agent creation process which creates the agent instance, binds it with a(n “headless”) authenticator and issues the anchor credential. In the case of a legal person, the anchor credential may contain attributes obtainable from the official corporate register of the state where the legal person is incorporated. 

Because the legal person alone cannot do anything, it must be associated with at least one other person, e.g., the board members who are known to be authorized representatives of the company. The associated member receives a verifiable credential about the association. Such credential can be used as a power-of-attorney in the transactions, where the legal person is a party and must be represented by another person. The credential is issued by the transaction, who verifiably performed the steps required from such association.

Once the legal person has been created and associated with at least one person, the legal person may go to transaction spaces, that issue further credentials to it that are usable in other transactions. Also, further persons may be associated with the legal person. 

Most of the business functionality of the economy resides in legacy systems that come in all ages and sizes. It probably is a good idea to try to utilize those systems as much as possible and feasible. Therefore, they should be brought to the digital network of trust via agents that represent the legacy systems. 

1. seller’s sales system
2. buyer’s procurement system
3. buyer’s bank’s payment service

None of these has been originally designed to participate in the Network of Trust. Let’s assume, however, that their functionality can be accessed and controlled using an API. This makes it possible to integrate the systems to something new. In this case, we integrate them with the Network of Trust, where the new business transaction management resides.

The communication in the Network of Trust occurs between identity agents (“wallets”) using a standard protocol. Recently developed DIDcomm is one such protocol. To connect the legacy systems with the Network of Trust, each of them needs an agent. Because an identity agent represents a digital identity, this naturally means, that each legacy system needs to be given a digital identity in the network. The Network of Trust of this example will thus have three “service identities” who can participate in the trade transactions.

Technically speaking, the service identities are constructs similar to the legal person identities. They are created for a specific purpose, and they are associated with at least one person identity. The service agent may for example be associated with an owner/operator person, who is responsible of the functionalities and actions of the legacy service. The service agent uses the API of the legacy service to use the service and it communicates with the transaction space(s) of the Network of Trust using verifiable credentials and basic messages.

One way to integrate a legacy messaging system with the network of trust is to add to each message of the legacy system a reference to the transaction which is related with the message. The transaction is committed in the transaction space before the messages between the participants are exchanged. The authoritative truth is in the transaction space. The transaction stipulates, what each of the transaction’s participants has committed to do. If the transaction contains an instruction for buyer’s bank to send money to seller’s bank, there must exist a message sent from the buyer’s bank, that is associable with the transaction.

It is up for a debate, whether other legacy messaging systems such as eProcurement messages or eInvoicing messages should be kept in the design or whether they should be replaced with messages/credentials exchanged with the transaction space. In other words, should an electronic invoice still be a XML message transmitted between eInvoicing operators or should it be replaced with a verifiable credential that is exchanged using a new protocol, such as DIDcomm. Both ways are possible.

Now we have digitalized the participants of a business transaction. All persons and services involved have now a digital identity and a corresponding agent in the Network of Trust. The only thing remaining is to get these participants together so that they can perform the transaction.

For this purpose, we use the transaction space discussed already in the earlier articles of this trilogy.

A transaction space is the node (agent) in the network of trust, where the different participants, including legacy systems, meet to perform a business transaction. The transaction space contains the verifiable logic, according to which the transaction must be executed. As described in the first “Getting the Digital Trust Right” article of this series, the transaction space publishes the business logic of the transaction as a verifiable claim. The space also creates a signed execution log of each transaction it has executed. The participants of the transaction may receive a copy of the signed transaction log. That log along with the published business logic act as evidence in any dispute that may arise regarding the transaction.

So how would a purchase-to-pay transaction be executed in a space that has the business logic of such transaction?

Let’s first see, who are the participants of the transaction. To make things a bit more interesting, let’s assume that we’re talking about a (financed) B2B transaction. To complete the transaction, following participants need to gather to the transaction space.

• Buyer company
• Buyer company’s representative
• Buyer company’s eProcurement service
• Seller company
• Seller company’s representative
• Seller company’s eSales service
• Buyer Bank’s payment service
  
  

If the trade transaction needs to be a financed one, then some additional participants are needed:

• Buyer financing service
• Seller financing service
• (Financing services’ representatives, if manual approval of credit is needed)

To enter the space, each of the participants need to present to the space the verifiable proofs, that are required from the participant’s role by the transaction space. For example, all legal persons of the transaction must present proofs about their unique identifiers, such as the VAT number. All natural persons must present a power-of-attorney to prove their authorization to represent the legal person. Furthermore, all service identities must be able to provide proofs about who are their legally responsible owners/operators. (The service identities are not shown in the figure below for simplicity.)

This “entrance screening” step already tells us, why this kind of solutions were not feasible before the introduction of the Network of Trust, that operates on verifiable credentials. 

In the past, all those parties would have had to be onboarded to the “financed B2B trade” platform before any transactions could take place. Also, static point-to-point integrations from the related systems would have been required. Such onboarding and integration processes have been attempted e.g., on various B2B marketplaces, but they have very seldom been successful or economically viable. 

Now, any participant, who has a digital identity and credentials required by the transactions, may enter any of the transaction spaces available in the network and communicate with the space using a standard protocol capable of exchanging verifiable credentials.

This is the game changer! When everyone is able to bring the required trust with them to any of the transactions they want to participate, lots of friction disappears from the system we call the economy. Also, the stumbling blocks of onboarding and point-to-point integration have largely disappeared, as the same credentials can be used in a (large) number of transaction spaces.

Now that all participants are in the transaction space, the rest is actually quite simple. The business logic of the space takes e.g., the following steps:

• the transaction space receives a purchase order from the buyer’s eProcurement system agent; the purchase order is digitally signed by the authorized representative of the buyer company
• the space forwards the purchase order to the seller’s eSales system agent which enters the purchase order to the back-end legacy system
• the seller’s eSales system agent or the seller’s representative approves the purchase order using a signed acknowledgement that is sent to the transaction space
• the transaction space forwards a proof about the approval to the buyer’s eProcurement system agent, which updates the back-end legacy system with the approval status
• The transaction space commits the purchase-step of the transaction. Now there’s a binding contract between the buyer and the seller about the purchase.
• once the purchase order has been completed, the seller’s eSales system agent sends an invoice to the transaction space which forwards it to the eProcurement service agent of the buyer organization
• the buyer organisation’s representative approves the invoice and authorises the transaction space to instruct buyer’s bank to pay the invoice on its due date; if there is an issue with the invoice, the transaction space may provide a communication channel between the buyer and seller to resolve the issue
• the eProcurement service agent sends the status update and the payment authorization to the transaction space; both are signed by the buyer organization (or its representative)
• the transaction space creates a payment authorization and sends it to the Buyer’s bank’s payment service agent, which reserves funds from the buyer’s account or from its credit line; the successful reservation of funds is reported to the transaction space
• the transaction space forwards the invoice status update to the eSales service agent, which updates the back-end legacy system
• The transaction space commits the invoicing-step of the transaction.
• The buyer’s bank transfers the funds on the due date and informs the transaction space about the event
• The transaction space commits the settlement-step of the transaction
• The transaction space issues output credentials, e.g., a receipt, about the concluded transaction to the relevant parties, e.g., the buyer.

If we wanted to continue the scenario with buyer and seller side financing steps, they could be added to the same transaction space. The seller could enter, in the context of the same business transaction, into an agreement with its financier to get the money immediately from the financier and the buyer could get additional time for the payment from its financier. The transaction space would manage the lifecycles and related banking transactions of both financing contracts.

In conclusion, we demonstrated, how a multi-party business transaction can be executed in the transaction space in a way, that has the status of the transaction known at all times. The commitments between parties can be implemented as legal digital contracts binding the participants. The transaction space is the node in the network, that manages the life cycle of the contracts. The transaction space can be used in various contexts to communicate various aspects of the contracts it manages to eligible third parties. For example, the seller organization may request the transaction space to send a verifiable proof about an approved purchase order contract to a party, who would need such information about the seller in real-time for financing purposes.

This seems quite useful. Now we have the possibility to know, what is the status and hence, current value, of the ongoing business transactions of the economy and we can communicate that information across the network of trust. This capability, that is an essential building block of the real-time economy, has become possible because we have got the digital trust and digital money right.

This capability allows, among other things, providing embedded financing services in the business transactions without the trouble of onboarding and point-to-point integrations!

What’s the problem that remains? 

Decentralized financial and business transaction management in the network of trust is clearly something that everyone needs, but nobody provides today. Whose job is it to be the trailblazer of this new business that is required to make the economy properly real-time?