If Bitcoin isn’t the Answer, What Should a Payment System Look Like

I have said more than once in my blog that if I was to create a payment system it would not look like Bitcoin, i.e. a blockchain-based technology.  I will bet that you have thought: “Well, smart-guy, what would it look like?”  That is an extremely difficult question to answer.  And, I have used that difficulty as an excuse not to attempt to answer the question.  That said, I started writing down a list of requirements that I believe are necessary to a modern payment infrastructure.  I know that this is not a design, but I firmly believe that you need to understand what your requirements are before you can begin to design a solution.

Let me start out by saying that I believe that modern payment systems built on the foundation of a modern payment infrastructure will transform business in fundamental ways.  It will:

• Improve the efficiency of doing business;
• Free up resources to attend to other, higher value activities, rather than spending time processing payments;
• Open opportunities for new kinds of business activities;
• Open opportunities for people who might not previously been able to participate in the business ecosystem.

These are not just hypotheticals.  At Textura we changed the way commercial construction handled payments and we did not even get a chance to fully implement the vision.  Textura achieved all four of the goals that I listed above.  Imagine what could be done if a payment system with a much broader scope of coverage could be achieved.  Be clear, I am not suggesting that Textura’s payment system is the answer, just a narrow example of what is possible when a modern payment solution is deployed.

Before we get to my requirements, a little necessary foundation needs to be laid.  Several paragraphs up, I underlined my use of the word “requirements”.  I used that term intentionally because I believe that any good solution begins with a thorough, well documented statement of what it needs to achieve to be considered successful, i.e. you must define requirements.  Building a solution based on an incomplete understanding of the requirements leads to implementations that are designed to meet only a subset of the users’ needs. 

I am not against high level statements of requirements; I just believe that they need to be: 1) complete at the highest level; and 2) followed by increasingly detailed (stepwise from the top down) descriptions of needs.  This is necessary to provide a framework against which a successful design can be developed.  Further, I believe that a technical solution that is developed without complete and well-defined requirements most often (there are exceptions) results in abject failure, i.e. the implementation, without well-defined requirements, is then kludged together in the most inelegant and costly (in terms of build and operating costs) way to meet the many fundamental, everyday user needs.

The exceptions, though small in number, are overwhelming in their influence on people’s thinking.  But “build it and they will come” requires a special situation where you truly have a greenfield and the vision to develop a fundamental solution that is malleable, extensible and rich in its fundamental nature and capability that magic can happen.  The Internet is one of those solutions/exceptions.  The graphical user interface is another.  They were foundational and provided the basis for the computing environment we enjoy today.  But examples like these come only once every couple of generations.

Yes, this is another one of my slams against Bitcoin.  I am not looking for a fight here, but someone has to say it, we deserve (need) something better than what we have gotten from blockchain/Bitcoin and its brethren.  It just is not one of those very special cases.  With that off my chest, let me now lay out the fundamental requirements for a generalized payment system.

Let’s start at the top.  The requirements begin here:

• It must be functionally and operationally complete.  That does not mean that it must do everything, but it does have to have the characteristics of a good payment system.
• Universally accessible.  A payment system must be available to all users whether they are technically skilled or not.  It cannot require expensive technology although it should take advantage of it where it makes sense.
• Money must be a stable store of value.  People must be able to be sure that the money they hold will be worth the same tomorrow as it is today, i.e. if they get paid today and it gets put into their account, they must be confident that when they go to pay their rent or mortgage that the tokens they are holding will be worth the same as when the money was deposited.
• Payment systems must separate from the underlying money system.  My reasoning on this is laid out in the next bullet point below.  That said: 1) we must recognize this duality and keep the two intentionally separate; and 2) the money system must be updated to be able to support today’s economy which includes operating efficiently and effectively within a modern payment system.
• The money system which is the foundation upon which payment systems exist must be controlled by the sovereign state.  No payment system will be successful without the government’s blessing.  Any government that is predisposed to outsourcing control of its money has failed to comprehend that controlling the money is critical to the ability to make and execute on policy.  Moreover, there will come a time when such governments become very uncomfortable with their lack of control, and will, at great expense, need to take back control of the money system.  The great expense will be incurred because it is always significantly more expensive to fix something you let get out of hand than to do it right in the first place. So, there is and will be a bifurcation between the money system and the payment system and governments must continue to control the money! That said, the money system must accommodate the need for people and organizations to “hold” money.  This might or might not be operated separately from the payment system.  Careful consideration should be given to the design of this piece of the system.  We would certainly want money, wallet and payment to be modular, i.e. there could be multiple providers serving wallet and payment options for any consumer of these services.   

• Money and the associated payment system(s) that enable the economy to function must be designed in a manner that promotes maintainability, extensibility and interoperability.  These are the characteristics of a system that is designed for the long term, i.e. the environment in which any system exists is bound to change and you must adapt to continue to be relevant and thrive.
• Payment systems must be robust, i.e. they must be built to resist failure and be resilient when they do fail.  They must also be able to handle high volumes of transactions and process them quickly.
• Payment systems must be secure.  And a system is only as secure as its weakest link.  The design must recognize that systems will be “interfaced” to other systems—and I am not specifying how these interfaces will occur.  That said, the design must reflect this reality to support technology, processes and procedures that enforce security imperatives.

There are existing architectures that exhibit these characteristics to one degree or another.  They include those associated with the internet, computers and cellular networks.  These architectures are all compartmentalized, layered and have extremely well-defined interfaces.

Please note that I did not include record keeping (populating a ledger) as part of the list of requirements I outlined above.  This is not because record keeping is not important or necessary; it is.  I list it here, outside the other requirements because record keeping is a shared requirement.  Record keeping is an important part of many processes and cannot be effective in that role if it is bundled with payments. 

The record keeping data is potentially part of several related processes that only perform a useful function in the context of the other separate, atomic components that define what we think of as the transaction.  For instance paying for a house involves: 1) the payment transaction; 2) recording the debit to one wallet and a credit to another; and 3) the transfer of real property from one entity to another; 4) updating tax records, etc.  Only one of these record keeping transactions is directly related to the payment, but they are all related to each other.  And it would not be good programming practice to overload a data structure or processing component with details that are related to other operations.

You will also note that I did not include distributed processing and recording of transactions as a requirement.  This is not because I do not think these are requirements, but because I am not sure they are.  My decision not to include them highlights my thought that this document does not constitute a complete, or fully developed requirements definition, but a starting point.

In summary:

• I believe that a modern, robust, functional payment system is necessary to a healthy growing economy.  The one we have is outdated and a replacement should be developed;
• The payment system should be based on requirements (what do we want to do), not a technical solution that is looking for a problem to solve;
• A payment system is part of a larger ecosystem that includes the money system, a recordkeeping capability, wallet services, automatic processing and others;
• Each of the other components of the ecosystem are separate but heavily interrelated.  These components are best developed separately, but in the context of an overarching architecture that ensures functionally rich, operationally deep, secure, efficient and extensible interoperability.

In an earlier post, I proposed that the U.S. government constitute a FARPA (Finance Advanced Research Project Administration) modeled after DARPA to work with the private sector to develop these ideas (Money, Payments, Record Keeping, etc.) first as requirements and then move to the design and implementation phases.

As I have said before, this is an enormous task and as much time and effort will need to be spent figuring out how to roll these capabilities out (no big bang here) if we are to be successful in this endeavor.

Copyright 2022 Howard Niden

— you can find this (days earlier) and other posts at www.niden.com.

       And, if you like this post: 1) please let me know; and 2) pass on your “find” to others.