Distributed Ledger Technology Working Group at OMG FDTF Status and Summary of Activities Based on OFDG Report Slides + subsequent calls 01 Nov 2016

Introduction OMG Finance Domain Task Force “Blockchain” initiative Introduced in March 2016 in Reston Initial exploration calls June 2016 detailed sessions Sept 2016 Workshop for PoC Renamed to “Distributed Ledger” WG Ongoing activities

Blockchain and Distributed Ledgers Origin: BitCoin, paper Satoshi Nakamoto Ability to post non repudiatable stuff on a distributed ledger What stuff? Balances? Anything Binaries in theory but too cumbersome Hash code for any kind of binary file What is distributed? The content Validation rules for what you can post Pseudo code for Smart Contracts Smart Contracts

The “Blockchain Bundle” Menu Ref https://gendal.me/2016/04/05/introducing-r3-corda-a-distributed-ledger-designed-for-financial-services/ Consensus Validity Uniqueness Immutability Authentication

R3 Proposal for FiServ Bundle Consensus Between parties – not to all Validity Stakeholders Validation logic Uniqueness Uniqueness service implementations Trade-offs and prioritization Immutability and Authentication As per Blockchain

OMG Motivation Are there aspects of Blockchain where some standardization would be of value? If so, what to introduce as OMG standards v what to coordinate with other WGs Potential value of FIBO for Blockchain / DLs

OMG Motivation What we think can be standardized: Computationally independent representation of subject matter AKA Conceptual Model But some participants don’t like that term AKA Computationally Independent Model (CIM) AKA Ontology At least if we include process ontology BPMN and OML-Activity give computationally independent view of process also

FDTF DLTWG Consensus Provide computationally independent view of subject matter suitable for DLT applications Based on FIBO Is ontology Demonstrate process dimension also Proof of Concept Identify the concepts Show hw thee relate to >1 DT aplication or architcture

Initial Investigation Identified 2 areas where there is potential for standardization Common identifiers So called “Smart Contracts”

Smart Contracts What gets posted on the DL Off-blockchain activities Currently managed at the “code” level (physical) Variations Ethereum – VM where instructions are posted as pseudocode in the chain As soon as logic is executed off chain or information accessed off chain it is not longer a DLT thing Very limited opportunity for BC to be a closed system So SC is a heavily hybridized concept. “Permission side chains” R3: peer to peer copying of information with off-ledger services

Distributed Ledgers Ethereum Hyperledger Interledger R3 Not really a “Blockchain” but is a Distributed Ledger Messaging application with a shared data model Templates dine the data needed to apply the data to a different contract algorithm Not transmitting transctions but routign them as part of the workflow At one level this is just another implementation of distributed database concepts (replication) With differences Can be implemented publicly or as a private network

Discovery Ethereum Code Smart Contracts created a programming language like Javascript with a VM in which they run Less obvious how you wrote these things in the same way everyone else is writing them No common conceptual model All sites would have the same logic All nodes evaluate the same stuff and that is the basis for consensus Code Need to be able generate the code in an idiomatic way that can later be recognized, thereby improving trust Because of the overhead of large apps and large umbers of nodes, what is realistic t put on the chain is just he results e.g. settled transactions not contracts Chain is always evaluated from start to finish each time Smart Contracts Parties related to the contract interact with the object. State and history of the state is maintained on the BC. Who defines the template class for e.g. IR Swaps. Syndicated loans are a hard use case for BC.

Discovery: Smart Contracts Can propose a basic tenet of a few standard templates for those Smart Contracts. Banks can take those and inherit those and create their own SCs. People have to trust the class itself. "The Contract is on the BC" - the language is off line, the BC has the business logic. In theory – but bear in mind limitations Will not be a single smart contract.

SMART CONTRACTS Premise: Smart Contracts should standardize around ontological definitions of contracts (or commitments etc.) rather than whatever is the "Code" approach that others in Smart Contracts have been considering. One opportunity is that whatever code is distributed, itself has a hash key, so if that has been vetted and accepted then the code is known that it can be trusted. We know we are executing the same code in the same VM So consensus can be at the level of both the business content and the code that does the work (meta level) Then execution is off chain but the DLT validates that you can trust the outcome

A Model Driven Approach to Blockchain/DL We see things happening at a physical or logical design level Smart Contracts code in e.g. Python, defining required behaviors, conditions etc. when a thing is posted Physical architecture of the different Blockchain and DLs We see the need for and benefits of a common business view Computational independent of “Conceptual” Business semantics Conceptual view for both structural and behavioral

Structural and Behavioral Business Content (semantics) Structural: terms of the contract This should be mappable to FIBO and ACTUS Behavioral: off-Blockchain behaviors and activities Payments process flow

Structural If anything can be hashed and posted to the DL then: Can be at the level of the whole contract (PDF) OR Can be at the level of the individual Commitment FIBO describes commitments individually (based on REA transaction semantics) We think there is benefit in posting specific commitments to the DL for grater precision These also map more directly to process activities

Behavioral Business process or workflow Can model these in E.g. payments, settlement delivery workflows Swap: two cashflow-based commitments Can model these in UML Activity Diagram format BPMN (Business process modeling notation) FIBO Conceptual Abstractions Model Includes process and activity primitives These currently resemble UML Activity notation Can extend to BPMN constructs

Behavioral and PoC Cook-off between UML-Activity and BPMN representations Map out in UML Activity for now Convert that to FIBO Abstractions for Process Extend or convert to BPMN also Extend to “hybrid” type of diagram Process – information interface What information is used by a process step What information is generated by a process step E.g. Red Herring prospects; terms sheet

Proof of Concept Two separate instrument types chosen This is to illustrate the benefits of common semantics of concepts Interest Rate Swaps Treasury bonds

IR Swaps PoC Component Based on a simple vanilla IR Swap example Mapped out the process workflow (ongoing) Created simple class diagram (placeholder for ontology) Start to combine these as hybrid view Then link these to FIBO ontology terms in IR Swaps PoC ontology

Brainstorming Workshop

IR Swaps Process

IR Swap process Segregate business process view of the IR Swap Blockchain possible postings Q: different DLTs may present different opportunities or constraints for what to post and for what happens off-ledger? No This need not vary among DL architectures Ned to also identify access /visibility requirements O we can till do this as a computationally independent model as proposed standard

Treasury Bonds PoC Component Structural: FIBO concepts for bonds contractual terms Primary market (issuance): Auction process workflow Map out in UML Activity Based on earlier FIBO draft issuance process material Focus on specifics of Auction process workflow

Current Status: To Do More research on what can be posted where DL v Blockchain v Smart Contracts detail What to propose What architectures support what Keeping it “conceptual” Treasury Auction process to model Hybrid models (as ontology) Demonstrate linkage to >1 DL architecture

References Smart Contracts Treasury R3 Initiative Corda and R3 https://smartcontract.com Treasury R3 Initiative Corda and R3 http://www.reuters.com/article/us-banks-blockchain-r3-exclusive-idUSKCN12K17E Circle (Boston) initiative – mobile phone enabled payment transfers