Mastercard launched #PromptPay, a P2P payments application, in January 2017 in #Thailand. The app now has more than half of the Thai population registered — 40 million people with over 173 million transactions and 700 billion baht ($ 22 billion) in money transfer value, according to data newly released by Mastercard. The product comes from Mastercard’s […]
Bank Innovation
EXCLUSIVE – On March 6 in San Francisco, 12 impressive #startups demoed #their #latest in #fintech #technology at INV Fitnech’s 2nd annual #demo day. INV Fintech, the sister accelerator to Bank Innovation, is partnered with Fiserv and eight banking partners with over $ 3 trillion dollars in assets. The startups were carefully scrutinized and selected from …Read More
Bank Innovation
Keeping track of #credit #card #benefits can be a tedious task, at least that’s what #Sift is banking on. The app helps customers redeem and track credit card benefits as well as files automated claims on its users’ behalf, when necessary. Check out Bank Innovation’s interview with Sift CEO Abhinav Dubey to learn about new […]
Bank Innovation
TEL AVIV — #PayKey, an intriguing Israeli startup that lets #banks offer payments on any social media platform &8212; and we mean any &8212; won the #demo #contest at #Bank #Innovation #Israel 2016 here this week. PayKey beat out 12 other finalists at the DEMOvation Challenge at Bank Innovation Israel,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
This episode of #Breaking #Banks centers on the Startupbootcamp #FinTech #Demo Day that took place last week in New York. Host Brett King spoke to Jesse Podell, who MC’d the event, and Nektarios Liolios, the founder of Startupbootcamp Fintech.
Bank Innovation
Reply