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

2. 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

3. 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

4. The “Blockchain Bundle” Menu
Ref
Consensus
Validity
Uniqueness
Immutability
Authentication

5. 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

6. 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

7. 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

8. 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

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

10. 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

11. 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

12. 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.

13. 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.

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

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

21. 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

22. Brainstorming Workshop

23. IR Swaps Process

24. 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

25. 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

26. 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

27. References Smart Contracts Treasury R3 Initiative Corda and R3
Treasury R3 Initiative
Corda and R3
Circle (Boston) initiative – mobile phone enabled payment transfers