Getting The Digital Money Right

by Timo Hotti, Principal Technology Strategist, OP Financial Group

This is the second part in a trilogy of articles by OP Lab on Digital Trust, Digital Money and Digital Business Transactions. What is digital money essentially and how does it relate to digital trust?  How do we need to re-think the settlement function of money in the digital era?

Money is probably the most used and least understood asset in the economy. Relatively few people understand, what it is and how it is created, destroyed and moved around in the economy. 

Although the essence of money is somewhat poorly understood, there seems to be a widespread consensus about the need to improve it. It is commonly acknowledged, that we need to streamline and automate the intermediaries and clearing processes that are dealing with money. We probably should also need to have a good look at something called “digital money” to connect the money better with the value-creating and -moving transactions occurring in the economy.

How can we make money more “digital”? How can we “leverage technology and innovation” to achieve our goals?

Let’s dig in. 

Money has three roles:

1. Unit of account
2. Store of value
3. Means of settlement

Let’s keep things simple here and assume two of the roles being “givens”:

1. It’s the responsibility of the state to dictate, what’s the unit of account in the particular state
2. It’s the responsibility of the market to determine, what’s the value of the money at any given time

These two assumptions leave to us, who work with money, only one job: ponder, how the settlement of transactions of different kinds could be done better in the future, utilizing the technological and business innovations done in the recent years.

(Although a very tempting idea, I will not add any “You had only one job” meme here.)

Money in the monetary system, that is globally used today, is always one person’s asset and another person’s liability. “Person” here can mean both a natural person and a legal person. Bank is a legal person. Money in the bank is depositor’s asset and bank’s liability. Conversely, a loan from a bank is bank’s asset and debtor’s liability.

Settlement is essentially about accounting of the assets and liabilities in various financial institutions and making those assets and liabilities move around in the financial system to settle business transactions while maintaining the consistency of the financial system.

When money moves in the financial system, it has an effect on both the assets and the liabilities of the system. This would be easy to implement in computer systems, if there was only one bank in the world. All transactions would be simple atomic database transactions against a single database. If the database and its owner were universally trusted to perform the asset and liability transfers according to universally known and accepted rules, the single database and its owner would qualify as the “world bank”. Banking would be easy!

Banking is not easy, however. There is more than one bank in the world. The SWIFT network has 11 000 banks in it and not all banks are SWIFT members. Moreover, not all banks are directly connected with each other. In other words, they cannot move money directly between each other. They need help from other banks to provide this service.

A bank must be able to transfer a liability to another bank, if the depositor of a bank wants to move his/her asset to another person having an account in the other bank. The transaction affects databases of two (or more) banks. Those databases need to be kept in synch.

The transfer of money from one bank to another happens using messages of a trusted messaging system. SWIFT is one such messaging system. The sender of the message can trust that it will be delivered to the correct recipient in its original intended form. Similarly, the recipient can trust, that the message has been sent from the claimed source. The messaging system also guarantees, that no message is lost in transit. It also provides means for ensuring, that the cryptographic materials needed to keep the messages private and immutable, are in right hands. The trusted messaging system connects the transactions done in the sending and receiving banks together. Once the database transactions in both the sending and receiving bank have been completed, the money transfer transaction between banks is complete. This may take time, but eventually the transfer completes. 

“Eventual” is the polar opposite of “real-time”. 

What if the settlement system’s state and consistency could be managed, monitored, and guaranteed, instead of the eventual basis, on a real-time basis? Wouldn’t that be a game-changer?

Transactional systems, such as data management systems and financial transaction networks, can be made real-time and high-performance capable by splitting the system into two components: data storage management and transaction management.

People who are familiar with data management systems, know, that the current state of a transactional data management system is the last known persistent state of the system amended with transactions committed to the system after persisting the last persistent state. In other words, data of the database consists of data persisted in the index trees of the tables amended with the data persisted sequentially in the transaction log.

Similarly, people who are familiar with transactional financial systems, know, that the total amount of customers’ money in the banking system is money in customers’ bank accounts amended with the money in transit, i.e., in agreed transactions that have not yet updated the balances of all participating accounts. In other words, money may have been debited from the buyer’s account, but it is not showing yet in the seller’s account. The money in transit is in the accounts of the correspondence banking system, for example. 

Today, data management systems are very real-time and high-performance. Financial systems are not. The reason for the non-real-time nature of financial systems is that the overall architecture is lacking the transaction management component that controls the entire settlement transaction.

The “money” described earlier is generally perceived as “traditional money”. It is numbers on accounts that are managed in the various banks of the banking system. When the numbers change, they change in transactions, that are well-understood and trusted by the banks participating in the system.

The accounting definition for “transaction” is as follows:

A transaction is a monetary activity that is recorded as an entry in accounting records and has a monetary effect on the financial statements.

That probably sounds good to a banker, but a computer engineer probably considers that insufficient. The database management definition for the word “transaction” is a bit different:

A transaction is a single logical unit of work which accesses and possibly modifies the contents of a database. Transactions access data using read and write operations. In order to maintain consistency in a database, before and after the transaction, certain properties are followed. These are called ACID properties. They are:

Atomicity – The entire transaction takes place at once or doesn’t happen at all

Consistency – The database must be consistent before and after the transaction

Isolation – Multiple transactions occur independently without interference

Durability – The changes of a successful transaction occur even if the system failure occurs

The banker and the computer engineer probably agree, that the financial transactions must have the ACID properties as well. They already have, but not in a real-time manner.

It’s worth mentioning again here, that in the database management systems, data is stored twice: in the index tree of the database and in the transaction log. In case of any error situations, the transaction history is the authoritative source of truth. The data on the tables can always be re-built based on the transaction history of the database.

From a computer engineer’s point of view, it is somewhat surprising, that the management of financial transaction history data has not been addressed better than how is currently is. Money of a single monetary transaction may move across a number of banks in a system in multiple database transactions without any single actor in the network knowing in real-time, what’s the overall status of the monetary transaction. There’s no single authoritative source of truth for the state of a transaction spanning across multiple financial institutions.

Rest assured, the overall status of ongoing transactions can be figured out in the current financial system, but in many cases, not in any real-time or automated manner. What I’m saying here is that the internal plumbing of the financial system is stable and reliable, but not efficient let alone flexible in any widely accepted meaning of the word. Not only may it take days to move money from one institution to another, but it may also take years to make any functional changes to the system. If it works, don’t touch it!

When designing the better digital money, which in our scope involves “only” the means of settlement component, there are two goals, that should be regarded as equally important: 

1. the reliability, speed, versatility and efficiency of settlement, and
2. the speed and efficiency of future system development. 

How real-time can we make the settlement process and how tailorable and adaptable for different business transactions could it be?

At this point, let’s ask a very fundamental question:

What is digital money?

Money is already today “just numbers in databases”. Why don’t we just call the current money digital and move on? What’s the big change everyone is talking about?

The big change is about the change! It’s about how the numbers in the various databases of the financial system are updated in a properly managed way to change the state of the system from one consistent durable state to another in an atomic and isolated manner.

As described already earlier, the way how we achieve the ACID properties in “non-digital” financial transactions today, is quite complicated and inefficient. We essentially split the settlement transaction into a set of sequentially executable messages, that instruct the recipient of the message to update its databases according to the content of the message. The system is trusted to stay in a consistent state, because all messages are guaranteed to eventually go through, and all possible exceptions are trusted to be resolved. Liquidity buffers between banks ensure, that a sufficient amount of liquidity exists for clearing each step of the transaction.

The amount of checking and double-checking required to maintain the trust across the system is significant. Should an error occur, its resolution in many cases requires manual work. A settlement transaction between two customers may take days to complete today. During that time, liquidity is tied in this “money in transit” and also the settlement risk is higher than in a transaction, that occurs immediately.

There is a significant financial incentive in fixing the manageability, performance and efficiency flaws of the current settlement process alone. If we not only fix the existing pain points, but also improve the settlement transactions to better support the business transactions of banks’ customers, the incentive grows much bigger. If we were able to integrate also the financing services into the settlement network, we could elevate the game to a whole new level.
How can we get the transactions of the financial system properly ACID, much more real-time and more relevant to the customers who run business transactions?

The first part of this article series was titled “Getting the digital trust right”. The main takeaway of that article was:

The network of digital trust consists not only of persons, but also of spaces, where the persons may interact according to the rules of the space.

Money in general is probably the most used “application” of trust. If we have now found a proper way to define and implement digital trust, we should, at least in theory, have an opportunity to re-think also digital money. Let’s reuse the lessons learned about digital trust here and create a new hypothesis:

The network of digital money consists not only of banks and their customers, but also of spaces, where the banks and their customers may execute multi-party contracts to settle business transactions of the customers according to the rules of the space.

Banks are the identities, who hold in their books the monetary assets and liabilities resulting from past concluded settlement transactions. In the proposed model, a settlement transaction between banks is executed in the “transaction space” node of the network, into which all parties of the settlement transaction may gather, which is trusted by all participants of the transaction, and which trusts all participants of the transaction.

There may be any number of transaction spaces in the network of trust. Different spaces may specialize in different transactions.

When a settlement transaction is executed in the transaction space, participating banks and possible other identities bring with them to the transaction space the facts, that are needed from the participant to participate in the transaction and for the transaction to complete successfully. Such facts may include proofs about the identity and regulatory compliance of the participant, for example. Also, the amount of funds to be settled is communicated to the transaction space as a verifiable fact.

The transaction space must similarly be able to present facts about itself to the participants, so that the participants can trust that the transaction space is a legitimate one. Such proof may be e.g., an approval claim from a regulator. The transaction space must also disclose the logic and rules, that are used in the transactions executed in the space. Furthermore, the transaction space must be able to share with the participants of the transaction the signed execution log of a completed transaction.

The following picture shows an example about the participants of a B2B settlement transaction. 

Once the participants of the settlement transaction have gathered into the transaction space and presented the facts that prove their right to participate in the transaction, the transaction space evaluates the inputs received from the participants according to the published business logic of the space and either accepts or rejects the transaction in an atomic operation. The inputs of the settlement transaction may include for example: 

• Payment request from the seller company signed by the representative of the company, 
• Payment approval from the buyer company signed by the buyer representative,
• Commitment from buyer’s bank to transfer funds to the correspondence bank, and 
• Commitment from correspondence bank to transfer fund to the seller’s bank. ​​​​​​​

(For simplicity, the additional potential participants such as regulator, guarantor and financier of the settlement transaction are not shown.) 

The successful completion of the transaction creates a multi-party contract, that is recorded in the transaction vault of the space. Copies of the contract are shared with the participants. The contract is a binding one for all the participants of the transaction. This contract is the authoritative source of truth for the transaction. It resides outside of the systems of the participants of the transaction. 

The obligations created for each participant of the transaction are communicated to the participants as new verifiable credentials issued by the transaction space. The participants must then each execute the obligations in their own systems and databases to comply with the multi-party contract. These obligations may include e.g., updating of the own databases and sending SWIFT messages to other participants of the transaction. The SWIFT message may be associated with the multi-party contract by assigning the unique identifier of the contract to one of the header attributes of the SWIFT messages that fulfill the obligations set by the transaction.

What if something goes wrong, when the transaction is being executed in the transaction node? We need some error handling here as well! A party may fail to fulfill its obligations to the executed transaction. In such case, the exception is handled automatically according to the rules of the transaction. For example, if a bank fails to transfer a liability from itself to another bank because of a liquidity issue, the guarantor of the transaction may automatically step in and provide the liquidity for the transfer.

This sounds quite straightforward, both from the financial and data management system points of view and the solution seems to have quite a few advantages.

The financial transaction can be made real-time. It can also be made tailorable using straightforward programming, because the transaction logic is in one single location in the transaction space. Essentially, we’re talking about “programmable digital money” here. Furthermore, the settlement transactions can be financed, guaranteed and regulated properly at the level of individual transactions simply by allowing financiers, guarantors and regulators to be participants of the transactions.

The data management side can be made much more robust and efficient, primarily because the state of the financial transaction is properly known and managed by the transaction space. The solution also enables the fundamental data management principle of making the transaction execution log as the single authoritative source of truth of the monetary transactions.

Why hasn’t the current financial network been built this way?

This is quite simply because we haven’t known before, how to build a proper network of digital trust. We haven’t been able to make bank and transaction nodes trust each other digitally in a manner, that allows execution of transactions between the banks in the decentralized manner in any number of transaction spaces described above. Our ability has been limited to building centralized platforms, i.e. silos, with their own isolated and purpose-specific trust models.

Let’s get back to the big question: What is digital money?

I repeat one sentence from an earlier chapter of this article:

The total amount of customers’ money in the system is money in customers’ bank accounts amended with the money in transit.

I also stated earlier in this article, that the money in bank accounts is what we called “traditional money”. On the other hand, the money in transit essentially is in the proposed model the aggregate sum of monetary value of the currently active multi-party settlement contracts. An active contract here means one, whose participants have not yet fully updated their own “traditional money” accounts according to the obligations of the settlement contract. 

In other words, the “digital money” is made of the multi-party money-moving contracts, that are managed in the transaction spaces.

Digital money is money that’s managed in digital settlement contracts.

If the contract has a guarantor as a participant, the money of the contract is guaranteed. If the contract has a regulator as a participant, the money of the contract is regulated. Most interestingly, if the contract has a financier (or two, one for buyer and one for seller) as a participant, the money of the contract is financed and thus has a life span of the duration of the financing.

Because the transaction settlement, all SWIFT etc. messaging between banks included, can happen in near-real-time, digital money can be very short-lived, e.g., of sub-second duration. However, it can also be long-lived, especially when financing services are present in the transaction. Hence, the digital money that lives “in contracts between banks”, may also exist for a longer period, e.g., months, should it be deemed useful. With the state information about active transactions available at the transaction spaces of the network, we know the overall system state in real-time, regardless of how much money there is “in transit”.

For whom could it be useful to have such additional layer of regulated, 3rd party guaranteed and financed money in the economy? Why would it be beneficial to have more long-lived digital money in the system? Now, these are some interesting questions!

Digital money is all about re-thinking the settlement function of money. This seems to require the addition of the new role of transaction space into the network of trust to power the multi-party settlement function of the next-gen financial network.

If we choose to have just one such space that is operated by a central bank, we’re essentially talking about CBDCs (Central Bank Digital Currency). Technically that’s straightforward to implement, so I don’t doubt its technical or functional viability. Banks by default have a trust relationship with the central bank. Therefore, it is trivial to build connections from the commercial banks to the central settlement management system. It just does not look too “networky” to me. I also have my doubts about the functional flexibility of such centralized solution. There are different kinds of business transactions that may benefit from different kinds of settlement processes.

Settlement is an essential part of all business transactions. We should make sure, that the financial services providing settlement services and the business transactions using them are well aligned.

If we go through the trouble of redesigning something this important, why not do it in a way, that provides the best growth path to the future in terms of scalability, efficiency, and richness of functionality?

There are valid technical and business arguments for choosing a model, that can have a larger, even unlimited number of trusted transaction spaces, that provide regulated, guaranteed, financeable and tailorable settlement transaction management services to the financial institutions and their customers.

By now, we know, how to build the network of digital trust in general. We also have an idea now, how to build the settlement network for digital money. Now it probably pays off to spend some time thinking, how the settlement network might be integrated with the business transactions. After all, the economy is essentially a network of business transactions that all must be settled.

What if we could make not only the settlement transaction, but also the business transaction, whose part the settlement is, ACID in the real-time sense of the word? Would it be worth the effort? Proper transaction management as part of the network of digital trust seems to enable significant improvements in the areas of efficiency and functional flexibility. Could the same advances, and more, be achievable also at the level of business transactions?

That will be the topic of the last part of this trilogy of articles.