Image source This #week is all about #Wearables. This is part of a series where we look at impact of different disruptive technologies on Finance. In the past we have covered #Blockchain, Artificial Intelligence, Regtech, Chatbots and XBRL. Today is a background briefing on the #technology and its broader implications.Read More
Bank Innovation
#Blockchain #startup #Factom has raised a $ 4.2m in new funding as part of a newly announced #Series A.
Two weeks ago, we reviewed the fast-developing world of real-time #payments. Since then, NACHA launched Phase 1 of its same-day ACH program, activating same-day credit transfers. We have also had further activity in the space, as Citi joined ClearXchange. (Note: I understand that none of these systems are true “real-time,” but that is the terminology that has stuck, so we will use it. A more accurate term would be “same-day payments” or the UK’s “Faster Payments”)
The real-time payments landscape is becoming more complex. By my count, we now have at least 7 major systems competing, with more on the way:
The first six systems are built on existing rails, either card or ACH or e-check, and bank support has been mandated. That is not to say that consumers can actually use them; in most cases, the user interfaces have not been built, or are in the process of being built. That’s what I mean when I refer to PayPal and Venmo as (sort of) faster payments; they act like real-time systems for certain use cases, but integration with the underlying funds transfer mechanisms is not yet seamless. This is why the recent announcements of integrations with Mastercard Send and Visa Direct that I discussed two weeks ago are important.
This is definitely a case of too much of a good thing, and I’m sure I’ve missed some important players. What are the terms of competition here, and where should #banks be placing their bets?
I think it’s helpful to think of the market in terms of layers, like this:
The top layer is what the end user sees, and might be a digital wallet like PayPal, or a mobile wallet like Apple Pay, or an app, or a web form or button on a web page that interacts with a cookie in the browser. Its purpose is to collect information about what payment the user wants to make.
Next in the stack is a routing and directory layer. The job of this layer is to find the “best” route for the payment to take, based on the options available. The answer to this question will depend on several factors:
Note that settlement is not typically going to be a factor here; I am assuming that any consumer-grade real-time payments service will in fact be using net settlement at regular intervals throughout the day, with ultimate money movement occurring over a real-time gross settlement system (RTGS) like Fedwire. This is how faster payment systems like the one in the UK are architected.
Parenthetical for those not familiar with the terms “net” and “gross” settlement: gross settlement is what most people think of when they think of a payment. A certain amount of money is taken out of one account, and is put into another account. Net settlement is a system where you record all the transfers out (debits) and the transfers in (credits) for each account, and sum them up periodically. This is more efficient, because a typical account will have both debits and credits over a period of time, and rather than settle each one individually, you can do them all as a batch. For example, suppose that you get paid $1,000, and you pay bills in the amount of $100, $200, and $300. The bank could do four separate settlements, or it could bundle them together and pay you the net amount: $1,000 in credits minus $600 in debits, or $400. Since each transfer costs about 79 cents, the savings really add up when you are talking about thousands of transactions.
The frequency of net settlement itself depends on how much risk can be tolerated by the system. As credits and debits accumulate, exposure grows, until net settlement occurs and balances are reset to zero. Authorizing a transaction by checking available balances will be an important feature for a real-time system to have; otherwise, the risk of a non-sufficient funds (NSF) event is greater. Gross settlement risk is usually covered by prefunding reserve accounts.
Any faster payments system can emulate true real-time performance by posting immediately and taking some risk that the net settlement phase will return some exceptions. This is essentially what the credit and debit card systems do, which is why they appear to operate in real-time at the point of sale (and also one of the big reasons they charge so much for interchange).
This sounds like a good job for a payments hub, and it seems to me that payment hubs are going to be in greater demand very shortly. Banks, processors, and wallets will all need ways to pick from a plethora of options using a range of criteria, and a payment hub is the best way to do that.
IBM’s previously announced work intersecting #blockchain and AI is moving forward with the establishment of a new work center in Germany.
While there weren’t any mega rounds this past week, the funding for #fintech is still trickling in—also Beyoncé became a tech investor, so maybe she needs a payment company; keep hope alive—and investors are still putting their money into the different areas of the industry, like specialized payment platforms, #blockchain,Read More
Bank Innovation
#Blockchain and #DEMO well integrated provide
Real #Smart Contracts.
Summary. The main blog, “Blockchain will change the world..?!”, proposes three fundamental research questions. In this blog and following blogs the third of these questions “How to apply blockchain?” or “How to do it..?!” is investigated.
In order to apply blockchain well, it must be well understood what blockchain provides us and what not. In the blog “Blockchain, what does it provide us..?!” is shown by observation that blockchain is a notarization system, explicitly not a transaction system. But notarization of documents and transactions are closely related. In this blog the relations between DEMO (Design and Engineering methodology for Organizations) transactions, notarization and real smart contracts is explained. It “fits like a glove”.
First the real world is observed to understand what transactions are and how they are related in the real world. Then the notions of Real Smart Contracts (RSC) and DEMO transactions are described. The functional perspective of a RSC is to represent the things in the real world by documents, transactions, contracts, communication, commitments, etc, with blockchain’s notarization capability, as good as possible. There are quality criteria defined.
Finally some aspects of the construction of the RSC, the relation between all kinds of information that may be notarized and a transaction is described. The next blog “Blockchain, how to do it..?!” shows how enterprises can be engineered using DEMO and how blockchain notarization is supported.
This blog and the related blogs are intended for the professionals, those who have to apply the blockchain #technology and design better services and enterprises. In most cases they have a background in economics, management and not so often in engineering. This nature of the blogs is informal and explanatory, making clear what is available and what can be done with it. Much emphasis is placed on how good engineering works and on what good observation of the real world provides us.
1. Introduction
There is a widely accepted perception that the potential impact of blockchain for society is huge and a game changer for many industries. However, there are many touted benefits that are questionable and probably will not be realized if we do not understand well what it is. In the root blog “Blockchain will change the World..?!” it is discussed that these benefits will not be realized if state of the art modeling technologies are applied to develop systems. Further, three fundamental research questions have been postulated;
1.1. What can we do with blockchain? The blog “Robust world financial blockchain systems..?!” states that society would probably benefit most from robust and fault tolerant financial systems in the world. The “Keeping the cyber criminal out” now enhanced with “Once the cyber criminal is inside, make sure that he cannot do much harm”, but doing it in a much better way than state of the art. Using a good engineering methodology to design and implement enterprises and applying the benefits of blockchain.
1.2. What does blockchain provide us? In that blog has been argued that blockchain provides trust-less authenticity of documents, or notarization of documents. It is that and nothing more, but this is already very valuable. The blockchain technology is not a transaction executing system.
Failure to understand this has serious consequences. First, blockchain experiments that apply blockchain as the core transaction system will be faced with large engineering problems, notably unmanageable complexity, and are therefor prone to failure. Secondly, a number of the promised and touted benefits of blockchain are based on the wrong assumption that blockchain is a transaction based system.
1.3. Blockchain, Real Smart Contracts..?!. In this blog is shown that there is a close relation between notarization and transactions. Blockchain notarizes results of transactions, such as communication, commitments, contracts, transaction related documents and the production of a transaction etc. The DEMO methodology, part of the enterprise engineering discipline, is strongly based on transactions. DEMO transactions have sophisticated capabilities. We need both capabilities. So, a good alignment and integration of blockchain notarization and DEMO transactions provides us the Real Smart Contracts (RSC’s).
2. The world of actors, transactions, communication and commitments.
As in most of these blogs, a careful and good observation of the things and their relations in the real world is mandatory if we want to build systems and enterprises that work well in that real world.
2.1 The notion of an actor. An actor is “somebody”, either carbon-human or silicon-computer, who does “something” in the real world. An actor “acts”, which results in “facts” in the real world. Actors fulfill roles. A role is the fulfillment of a specific task that is part of a specific service to a specific customer. There is an abstraction between actor and a role. Multiple actors can fulfill multiple roles. At run time a role can be assigned to an actor. This is represented for example in natural language, “Joe, will you do this job for me?..”, which is a Request.
2.2 The notion of a transaction. In this blog we do not use the notion of an economic transaction, with a transfer of products in one way and a matching transfer in finance the other way. An example of an economic transaction is the purchase and payment of a product. The notion of transaction applied here is an atomic or an elementary transfer. A purchase and a payment involve two elementary transactions. Any matching compensation for some payment or the delivery of some service may exist but is out of our scope of a specific transaction.
Any (atomic) transaction involves two parties, or actors, with mutual communication, commitments and some exchange, typically some kind of production or transfer of value. The mutual communication is typically expressed in natural language and involves very important notions such as negotiations, commitments, obligations, intentions and more. Part of the communication in a transaction is a mutually binding agreement or commitment to deliver the ‘production’ of the transaction from one actor to the other actor. In a legal sense this is a binding contract. Contracts are important entities, trust-less authenticity of all commitments and contracts is clearly a valuable asset. Another important part is the finalization of the contract; both actors agree that the transfer has been made and accepted (or not, or not yet). Transactions may embed other transactions in an ever recursive way. For example, a transaction for the delivery of a car demands that the transactions for the production of the engine and the wheels must have been performed and delivered before the car can be assembled, which is another transaction. Only, then, after completion of all the previous transactions in production, the transaction for the delivery of the car can be finalized. We see that transactions are often organized in a tree structure. The notion of a DEMO transaction between two actors is a very suitable building block for enterprises. There is much empirical experience, good theory, proven results. This works very well.
2.3 Observation of the world of transactions
Our world of interest is composed of transactions, transactions are everywhere.
An example: Assume that 2 people – actors communicate and agree to meet at the Liberty Statue on Thursday. There is a Request and a Promise and together that is a (legally or moral) binding contract, actually two contracts because each actor commits himself to the other to be there. They execute a transaction and the result of that transaction is that each of the two people actually meet there. The binding contract(s) may be fulfilled, or not, if one or both does not show up.
Many other transactions must be fulfilled before the actors can fulfill their transaction. A ticket and a hotel room must be booked, more transactions. The aircraft carrier must fulfill many other transactions first, etc. We observe that the world is composed of transactions and that these transaction are highly structured and inter dependent in a hierarchical way. The “lower” transactions must be finished before the “higher” transactions can be fulfilled.
This real world of transactions between individuals and enterprises is not much different from the world of transactions within enterprises. Within enterprises all the transactions are usually a bit better defined and organized, but there is no fundamental difference.
With this notion of a transaction, all transactions between financial services, #banks, insurance companies, customers etc. at a macro scale are captured. At a micro scale, within these enterprises, we also see an ocean of structured, nested and related transactions, in the finest details. The name of the game is to organize these transactions in such a way that the enterprise performs as good as possible.
Our world of interest consists of transactions, transactions are related or embed other transactions. Transactions are everywhere! If we understand the notion of transactions very well then we can realize huge benefits.
3. Real Smart Contracts
3. 1 The notion of a Real Smart Contract
Real Smart Contract = Blockchain + DEMO
Real. Refers to the requirement that all situations hat occur and all things that may happen around contracts in the real world around us, must be captured well. First the real world must be observed very well and well represented. Then must be shown that DEMO transactions provide the needed capabilities to capture the phenomena in the real world well.
Smart. Refers to the qualities of the RSC:
Contracts. The DEMO transaction captures communication and commitments that represent a contract and the fulfillment of that contract, plus much more. The RSC is a well aligned integration of a transaction, a DEMO transaction and the blockchain notarization capabilities.
RSC’s are the building blocks of any enterprise that needs blockchain notarization.
The DEMO methodology is the engineering way to build enterprises using RSC’s like brick stones.
3.2 The notion of a DEMO transaction
DEMO is based on communication and commitments. Typically the communication is in natural language, but not necessarily. Communication here is any exchange between two actors that creates binding commitments in some way. The seemingly simple question in a shop “Give me some of these flowers” has the effect that the shopkeeper must reply, either to Decline the Request and Promise the Request. Also the customer is now committed by this simple phrase. The power of social media shows us how important communication is. However, communication with binding commitments that must be kept, and will be kept with the help of a software engine, is probably a new paradigm.
The picture on the left is an informal representation of a simple transaction. On the right is a formal representation in a conceptual language.
The picture shows the most simple pattern of a transaction execution. The customer, initiator of the transaction, issues a Request for some flowers. The producer, the executor of the transaction issues a Promise to deliver the flowers. The Request and the Promise constitute a binding agreement, a contract. The fulfillment of the transaction is realized when the executor states that the flowers are there and the customer initiator accepts the flowers. Both actors agree that the initial contract has been fulfilled.
A more precise version of a transaction pattern is followed when there is a negotiation between the two actors, The Request may be followed by a Decline, for example if there are no flowers. The contract will not be agreed upon. Similarly, there may be a dispute about the fulfillment of the contract; the customer initiator may decide that these flowers are not what he wanted, he may Decline the flowers. Also here is a negotiation and a dispute may follow.
In an even more sophisticated transaction pattern the actors are also capable to revoke their earlier commitments. For example: the producer executor may first issue a Promise for the flowers – the contract has been signed by both actors – but decides for some reason that this was not a good decision. He revokes his earlier Promise and wants to issue a Decline, not bound to this contract. For this revoke, a contract termination, the permission from the other actor is needed. So, here is also a sophisticated communication pattern with negotiations.
In this way, with the several transaction patterns, all events that occur around a transaction, the things that may happen in the real world, are quite well captured. If our RSC’s would not be that real smart, then the appropriateness of it would be affected. It is not that suitable anymore. Empirical evidence shows that these transaction patterns have a very good degree of appropriateness.
3.3. The integration of blockchain notarization and a DEMO transaction
Observation of the execution of a DEMO transaction shows which elements of that transactions can be notarized. Assume a transaction for some #financial service, provided by a bank for a customer.
For each communicative act (a Request / Promise / Decline / State / Reject / Accept) usually some relevant documents that must be provided. A Request for a mortgage is typically accompanied with additional information such as the real estate, the identity of the customer, salary information etc. All these related documents must be notarized, together with the Request itself, at the moment the Request is issued.
The production of the financial service is represented by a document – it is not yet a contract! – that contains things like calculations, obligations, commitments, legal texts, conditions that may occur the real world later, etc. This document must be notarized immediately after it becomes available, independent from any communicative acts, though they are closely related. The unsigned contract must be notarized first! Then the customer gets access to the document and may decide to commit and sign or or not.
The contract is actually signed and agreed upon when the customer has confirmed his Request by placing his signature on the paper document and the service provider has confirmed his Promise also by signing the paper document.
Often there are other related documents that are part of financial service that may be notarized, such as interest rate calculations, approval of supervisors. In fact, a mortgage is a fairly complex financial service that is composed of a number of structured supporting transactions, RSC’s. For each of these transactions may be specified at modeling time what should be notarized, or not.
After signing, represented by a Request and a Promise by the parties, the contract must be fulfilled by the two parties. This encompasses in practice many other transactions, monthly payments, mandatory insurance, approvals, etc. In special cases some of these transactions may demand a partial roll-back, which must be carried out with formal correctness. Failure to realize this could result in a deadlock situation.
This shows how DEMO transactions and blockchain’s notarization capability are closely related and well integrated into RSC’s. From a software engineering perspective the implementation of notarization in a transaction is even remarkable simple. It is a simple extension to the DEMO engine as will be shown.
3.4. Some more capabilities of DEMO transactions
Observing the real world we see that transactions are nested in a structured hierarchical way both between and inside enterprises. The “lower” level transactions must be completed before the production of a higher transaction can be completed. This defines a close relationship between transactions, transaction may be stacked like brick stones.
Example: the delivery and manufacturing of a bicycle by a manufacturer. The transactions to produce wheels and a frame must be completed before the assembly of the bike can be done. After completion of the transaction for the assembly of the bike, only then, the bike can be sold and delivered via the transaction between customer and bike manufacturer.
If one of the lower transactions cannot be completed – assume there is a problem at the wheel manufacturer. The wheel manufacturer cannot deliver the wheels. The bike can not be assembled. The bike can not be delivered to the customer. It means that the transaction tree must exhibit several kinds of roll-back capabilities with mathematical correctness. Any deadlocks or anomalies should not occur. Looking closer at the total number of different execution path’s in models of more than two transactions shows exponentially growing complexity, far beyond our small brains to capture this. This is the reason that models with more than two transactions should be calculated by a software engine, not by human programmers. It shows also why the industry standard BPMN (Business Processes Modeling Notation) is only suitable to model the simplest “happy flows” in production and fails to handle any exceptional conditions such as roll-back phenomena.
DEMO transactions support business rules that control the execution of the transaction. An example is a Request from a customer to his bank for a loan. The bank must carry out all kinds of checks, each controlled by a transaction. A business rule could state that for an amount more than 1000,- USD the approval of a colleague must be given. The business rule would enforce the transaction with the colleague to be completed – approval given or refused – before the transaction with the customer may continue. This precise definition and control of each actor in the enterprise is of great importance to improve the quality of the daily operation.
3.5. DEMO modeling provides high quality enterprise specifications
DEMO theory provides also clear specifications of the notions of authority, competences and responsibilities for each actor role. The human actor who fulfills an actor role must meet these criteria. It supports the matching of employee competences to functions.
The qualities of communication between actors are defined by claims of truth, claim of justice, and claim for sincerity, that are provided by the Habermas communicative theory. Actors are assumed to communicate the objective truth; be sincere though they can be mistaken (subjective); and should only communicate what is allowed.
DEMO theory provides a methodology for constructional decomposition which provides clear specifications for each production part in production. This is typically a product blueprint with a BOM (Bill of Materials).
The Real Smart Contracts have these capabilities to capture the real world well and to be a good building block for enterprises. The other part of the equation is the methodology to do this.
4. Conclusions
The alignment and integration of blockchain and DEMO models matches in a conceptual way very well, is very straightforward and offers great advantages when sophisticated enterprises have to be designed and modeled that apply blockchain well.
The DEMO modeling methodology is very sophisticated and powerful. Instead of using DEMO transactions as the core building block of enterprises, the augmented Real Smart Contract is the building block of enterprises that need notarization.
In the next blog “Blockchain, how to do it..?!” is shown how DEMO models of enterprises are modeled, what they provide, how blockchain notarization can be modeled and how enterprises are driven and controlled by DEMO models in production.
More practical blogs on how to do it will be: “Banking transactions – PSD2 with blockchain” and “Co-creation and co-production in production chains using blockchain”.
The author, Steven J.H. van Kervel, Ph.D. computer science, is with Formetis Consultants BV in The Netherlands. Formetis are enterprise engineers. They develop methodologies, tools and software systems for the engineering of enterprises with supporting IT systems, applying and supporting the blockchain technology. Formetis participates in the CIAO! community of scientists and engineers on the field of enterprise engineering.
Formetis seeks partnerships to bring this technology to the real world.
Contact: [email protected]
[linkedinbadge URL=”https://www.linkedin.com/in/steven-j-h-van-kervel-0615671″ connections=”off” mode=”icon” liname=”Steven J.H. van Kervel”] is consultant at Formetis
Wall Street megabank #JPMorgan has co-developed a permissioned version of the #Ethereum network.
A think tank run by the European #Parliament recently released a discussion #paper on #blockchain-based #elections.
#Hyperledger announces a new #blockchain #healthcare #working #group with Kaiser Permanente and five other companies as inaugural members.
A group of 50 leading #blockchain #legal experts has launched the Digital Currency and Ledger #Defense #Coalition.
Reply