Yesterday I posted a short note about the rift between fiat and cryptocurrencies and it occurred to me that readers may not necessarily make the connection between how the rift is being closed. I ended the piece talking about where the smart money is going. Here is one idea about how your bank is just an Amazon Cloud application.
The following is a thought experiment as to what a bank is and what its services will look like in the future.
As in any thought experiment, there is a lot of room for refinement and expansion. This isn’t a fully baked thought, but a good indicator of what banking could look like in the near future.
In any crypto system, attribution is a primary goal of defining movement of money through accounts which otherwise would be considered anonymous.
To accomplish attribution, walking the chain and assigning a cyber reputational risk score is necessary to build transactional network diagrams in which future attribution can be inferred. When the purpose of this attribution is for determining risk, this can be called a cyber reputational risk score.
For example, if Alice and Bob are unknown actors, but they both create new accounts and transfer coin between them, finding the funding source for the input into that transaction can infer risk. Meaning that if A to B requires A1 to A, then you can draw a direct line from A1 to A to B. Because block chains are entirely transparent, these inferred relationships break the concept of anonymity.
The modern economy addresses this by creating liquidity pools in which funds come in and go out, but there is no attribution attached to the money itself. Although, there is an inferred accountability in transactions within the pool, this can be regulated and governed.
This provides several benefits common to our modern banking system, including the ability to store funds in a central system that is accountable and responsive to fund holder needs, rather than in individual security. This is akin to keeping your money in a jar in the back yard or in your local credit union. Both are great until you reach a certain point. The centralized store has been problematic in that the lack of regulation and governance has made deposits risky. See Mount Gox.
The second function in creating a modern facility is the ability to perform business functions for the monies involved. Modern banks have limited functionality in how money is classified and addressed. Everything is kept in one or a limited few accounts and is fungible to all rules that the owner might place on their account for things like bill payment, or satisfaction of drafts presented to the bank for payment.
This artificial limitation is largely an artifact of legacy banking systems where deposit holders add a layer of accounting and business rules for that accounting within their own management layer and then impose that on the bank through requesting the movement of funds. Some basic automation is possible through bill payment systems and other forms of electronic transfers, but this is largely a minimalist system. Any sufficiently crafted transaction can drain an account in an unauthorized manner.
A modern system would need to present firewalls that limit risk to the level of trust associated with a transaction. For example, a modern debit card can withdraw monies from an account up to its daily withdraw limit. This is largely a risk management technique to limit losses from a lost card. But similar protections do not exist when providing a vendor ACH authorization to draft against an account for a monthly bill. The deposit holder is subject to potential losses if the creditor loses the ACH information or makes an error in their system when determining how much money to withdraw from a depositors account.
In a crypto world, there is a practically unlimited ability to tag transactions with unique account numbers which could represent specific kinds of workflows, and an immutable capability in DLT to validate and track those transactions.
This also presents opportunity to address cyber reputational risk scoring as these transactional types need only be attributable to the recipient and defer all KYC jurisdiction to the influx of money in to the system.
A basic system for this would provide a master account number for which the user would have a persistent and recoverable authentication for. In creating this system account, the user would then create (unlimited) funding accounts which would credit their primary account off chain. For example, if a user created account A and then funded it through a on chain transaction to account 1, the system could further deposit those funds to account SYS and note the credit within their system.
The user could then setup funding account B which represented specific funding rules, like send x BTC to account Y on the first day of each month, or allow debit requests from account Z on a not to exceed x basis every 30 days. These rules could easily follow a ITTT flow or provide an incoming API for demand request, like a credit card. Because of the unlimited number of accounts, the user would be able to determine the funding rules for each payment account and therefore limit their risk to unauthorized or unexpected transactions.
Because funds paid out by the system would go from SYS to A2 to B, there would be accountability for B to know the source of the funds by attributing A2 to a client transaction. This simply means that the system need only to create a way to transfer this account code to the parties when the rule is setup.
The primary agreement would be through protocol or API to facilitate the transaction. This also necessitates and would provide for an address book of account transaction agreements within the System that the user could leverage to simplify and secure transactions. This places the burden of providing these services on the service provider to build and negotiate a system for facilitating these types of initial transaction negotiations.
This type of service would also necessarily serve to provide coin conversion services to and from fiat currencies. The most beneficial scenario for this would be that the system maintains the user account in the coin type of their preference and that each incoming and outgoing transaction be in the coin type preferred by that transaction.
This inherently creates arbitrage scenarios and closed loop transfers which would be akin to anti-cyber reputational risk scoring techniques. For this reason, treatment of system accounts as a security would need to be considered depending on the jurisdiction of the system. This would ideally place a requirement on the system to be positioned in a favorable jurisdiction until regulation and governance mature to the point of being able to address risks inherent in the system.
A common framework for smart contracts would potentially be a benefit for outgoing payments if common execution criteria was necessary, although artificial to the common system management function. This could be specifically useful in setting up standardized smart contract types for common transactions. This is specifically useful because common users cannot craft smart contracts and need to leverage a service provider to create reusable contract vehicles that map to natural English agreements. Specifically, for the system user to benefit from smart contracts, a library of agreement types needs to emerge in the same way that we have common and reusable natural language contracts today. The features and integrity of these contracts would be potentially considered the intellectual property of the service provider. This is an area where licensing would need to address the IP concerns and because of the technology element may be considered unique and different than natural language contracts.
For these reasons, the most desirable characteristics for the digital currency token to function under would be an Ethereum token with a tether funding. This liquidity problem could be solved by the system providing transparency to its holdings or by moving its internal funding source to a tethered coin. For large system players, this will inevitably move to a centralized and regulated source, but until one emerges, may use alternate sources of security.
The real world application of this system is evident in the How I Help use case where users would deposit fiat currency into a system account in their name and then create instructions within the system to direct these funds to be further transferred to different payees in their currency of choice.
The system would be responsible for maintaining account security and anonymity as desired by the system user. The HIH platform would then only need to use an exposed interface to both account for existing funds, therefore transferring that role to the system, and for creating funding instructions for the movement of deposits to payees.
The transparency of the DLT creates a transfer of risk and management of accounting functions to the system. In this way, the system is more of an IT function than a financial function. The goal here is to create a more friction-less way to securely move money without regard to format and adhering to the regulation and governance required by deposit holders.