You are on page 1of 11

Information paper

Distributed Ledgers,
Smart Contracts,
Business Standards
and ISO 20022

September 2016
Contents Distributed Ledgers, Smart Contracts,
Business Standards and ISO 20022
Executive Summary The subject isDistributed
considered from Smart
Ledgers, two angles:
Contracts,
Business Standards and ISO 20022
What are the necessary preconditions for
standardisation of DLT/SC and are these
met? What would be the characteristics
of standards in the DLT/SC world, and
what can be learned from previous
industry standardisation initiatives?

What can be re-used today from existing


Introduction 4 Distributed Ledger Technology (DLT) and Smart standards, and what are the benefits of
doing so?
About business standards 5 Contracts (SC) promise to transform automation
Standards governance 6 in the financial industry, and are generating We conclude that business standards for
DLT/SC will be important, but that the
Legal concerns 6 huge interest amongst financial institutions and present variety of philosophical and technical
approaches to the technology, added to its
Towards business standards for DLT/SC 7 technology providers. Rapid progress is being relative immaturity, make it too much of a
Standards and Contracts 9 made towards more robust implementations of moving target for full-scale standardisation
today. We do, however, extrapolate from
Interoperability and re-use: ISO 20022 and DLT/SC 10 the technology that might meet the needs of current trends to make recommendations
about the direction standardisation should
Introduction 10 the financial industry for security, resilience and take, including the need for a standard

ISO 20022 Business Model 10 scalability. However, regardless of the technology, methodology for defining DLT-implementations
and a collection of such definitions, or
Reusing the ISO 20022 Business Mode 11 addressing automation problems in a multi-party templates, for common use cases (such
as a financial instrument, its relationships
Reference Data 13 network environment also requires business and lifecycle processes). We also conclude
that these should be open standards, not
Behaviour 13 participants to define and agree the meaning and controlled by a single commercial entity, in

Summary 13 content of shared data, business processes, roles order to ensure the level of trust and industry
participation necessary for success.
Models at a glance 14 and responsibilities. This is the domain of business
The second part of the paper is based on
Interoperability with messaging 16 standards, and the focus of this paper is the a SWIFT proof-of-concept development

Conclusion 17 application of business standards to distributed that explores the benefits of using existing
standards, including ISO 20022, in the context
Appendix A ISO 20022 18
ledger technology. of a DLT/SC implementation for fixed-rate
bonds. The conclusion is that while existing
About ISO 20022 18 standards do not cover all aspects of DLT/SC,
there is clear value in this approach - to avoid
Methodology 18 re-inventing the wheel in terms of business
definitions and to facilitate interoperability
Content 18 amongst DLT implementations and with
existing financial industry infrastructure
Governance 19
including electronic messaging. We further
SWIFT, Standards and ISO 20022 19 conclude that as the industry evolves DLT/
SC-specific standards, ISO 20022 will provide
a great foundation, in terms of both existing
business content and approach.

As a financial industry-owned cooperative


active in the business standards space, SWIFT
expects to take a leading role in formulating
and operationalising open business standards
for DLT, building on its extensive experience
and relationships with industry players,
regulators and standards bodies.

2 3
Distributed Ledgers, Smart Contracts, Distributed Ledgers, Smart Contracts,
Introduction Business Standards and ISO 20022 About business Business Standards and ISO 20022
standards

Distributed Ledger Technology (DLT) and It is unlikely that a complex business process Formal specifications and business standards A more complete description of ISO 20022
Smart Contracts (SC) promise to transform will be scoped to a single DLT environment are a prerequisite for automating business can be found in Appendix A, but the aspects
automation in the financial industry, and are (there is already a proliferation of distributed processes of more than trivial complexity, of the standard that it is important to
generating huge interest amongst financial ledgers and more are being announced), Attempting to particularly where multiple cooperating actors understand are: There are many
institutions and technology providers. More and this is a second important reason for and/or large sums of money are involved.
details of the technology and some views on considering standards: business processes impose standards Todays business standards fall into two broad It is both a methodology for making messaging standards
its readiness for deployment can be found in a will require DLT to interact with existing too soon, before categories: reference data and messaging. messaging standards in a consistent way but the most
recent SWIFT position paper. One conclusion automation mechanisms, including messaging and a body of content message and
of this paper is that a key factor inhibiting and APIs, and with other distributed
the capabilities Reference data standards define universal other definitions - created according to
modern in terms
application of the technology on an industrial ledgers. In addition to progress on technical and constraints codes for key data elements such as the methodology; of architecture and
scale is a lack of standardisation. This view synchronization standards, for this to occur of a technology currencies, legal entities or securities. They broadest in terms of
is further emphasized in an academic paper safely and seamlessly, consistent, cross- define both the format of the data (e.g. the It is organised in such a way that
funded by the SWIFT Institute on The Impact referenced definitions will be required between are understood, length and format of a currency code; the common business semantics are business coverage
and Potential of Blockchain on the Securities DLT and existing platforms where business risks creating attributes required to describe a currency) and identified independently of messaging, and adoption is ISO
Transaction Lifecycle. standards are already widely deployed. A the data itself (e.g. the list of agreed currency and referenced in message definitions
further aim of this paper, therefore, is to
standards that are codes, EUR, USD, etc). Reference data to ensure consistency and reduce
20022.
Today, the industry is focused on the explore principles of re-use and interoperability quickly obsolete or standards ensure consistency for important ambiguity;
technical standards required to create
robust interoperable DLT/SC platforms and
between the new or adapted standards that
will be deployed in DLT environments and
irrelevant. business data.
It features a strong governance process
great strides are being made. However, if existing messaging and data standards. Messaging standards describe formally the that locates control of the evolution of the
DLT/SC technology is to address complex content of business messages exchanged by standard with its users.
problems, the industry will also need to find Electronic messaging has been used for many industry participants to complete business
agreement on the meaning and format of decades to automate business processes in processes, such as payment initiation and These features ensure that messaging
data deployed on DLT platforms, formalised the financial industry. When the technology securities settlement. Message standards standards created by different actors
business processes and clarity around the first emerged, deployment was typically local specify data elements using reference data and for different business domains are
legal implications of both for participants, that to a particular market or community, and a standards wherever possible to minimise compatible in terms of data format and
is to say, business standards. The focus of this huge variety of local business standards was ambiguity. There are many messaging semantics; important because it enables
paper, therefore, is the application of business created. Recent global standards, such as standards but the most modern in terms of the effort to create business standards
standards to DLT/SC. ISO 20022 (financial messaging) and ISO architecture and broadest in terms of business to be distributed without compromising
17442 (Legal Entity Identifier) seek ultimately coverage and adoption is ISO 20022. overall integrity.
Financial industry business standards for to replace many of these local standards, to The examples in this paper will therefore
messaging and data enable the creation of reduce over time the number of competing focus on ISO 20022, but it is likely that Communities of ISO 20022 users can
robust, interoperable multi-party business and overlapping standards with which similar observations apply to other industry build market-specific rulebooks and
processes by reducing the ambiguity of the financial industry has to contend. But messaging standards. guidelines to tailor use of the standard
specifications and fostering efficient re-use replacing a standard that is working well in for a given business context while
of knowledge, skills and technology. They a particular market is never easy, and it is maintaining high level compatibility with
work in two ways. First, standards specify a clear that the industry will be struggling for other user communities.
methodology to capture and publish formal many years with the inefficiencies that this
business specifications in a consistent and proliferation of standards has created. There
precise way. Second, they provide governance is a clear lesson here for the development
processes that can be used to standardise of DLT/SC, and a clear opportunity to avoid
the content and evolution of the business creating fragmentation in the early days of
specifications themselves. the technology that will lead to entrenched
inefficiencies later on. Timing, however, is all
important. Attempting to impose standards
too soon, before the capabilities and
constraints of a technology are understood,
risks creating standards that are quickly
obsolete or irrelevant. This is probably where
we stand with DLT/SC today, so this paper
aims only to provide some general, non-
prescriptive thoughts on the direction of DLT/
SC standardisation; what can be learned or
re-used from existing standards, and how
practically this might be applied.

4 5
continued on
Standards governance Legal concerns Distributed Ledgers, Smart Contracts,
Business Standards and ISO 20022
Towards business standards next page
for DLT/SC

All business standards require a governance In the messaging world, the legal obligations What is different about DLT/SC and how remove the need for many of the interactions Also, it is likely that business content and
process to maintain the consistency and of a party that sends or receives a standard does it change the game? Distributed required to realise todays business processes behaviour will be described by smart
integrity of the standard, while also allowing it message are typically defined outside the ledger technology offers a single, consistent (and may ultimately remove the need for some contracts2 and their underlying data models,
to adapt to meet evolving business needs. standard itself in scheme or system rules and shared view of the state of a business of the actors too). and that these will be programmed in a
that set the context in which the message is process. In principle, it can eliminate the need language that supports object orientation3,
ISO 20022 has an open and effective used, such as, for euro retail payments, the to pass information between actors, and for So what would it take to formalise a DLT/ so contracts will support inheritance/
governance model, which is described SEPA rulebook published by the European individual actors to maintain independent SC use-case, and what would a standard polymorphism, and data will be encapsulated
in detail in Appendix A. It conforms to a Payments Council. copies of the data in their own systems. look like? It is clear that standards will have with behaviour. Finally, another seemingly
general pattern of governance for successful DLT can therefore reduce the point-to-point to define clearly the data present on the common characteristic of smart contract
standards, which allies open participation from However, the precise meaning of these rules messaging and other processing required to ledger; how it is represented and what it implementations is that to ensure consistency
the user community with rigorous procedures depends on the clarity of the definitions in the keep data synchronised and reconciled. Smart means. For smart contract applications it will of the ledger, processing must execute on
to ensure that changes are business- message standards. A similar dependency will contracts can provide further efficiencies by also be necessary to define the behaviour of every validating node, and in each instance
justified and that the frequency of releases surely also apply in the case of DLT/SC-based moving business logic that today may require the contract logic. But before going much yield the same result. This introduces an
can be accommodated by users. As DLT/ solutions. complex interactions amongst many actors further, we first need to set out some basic important constraint: since the result of each
SC technology matures, it will be important to self-executing processes deployed on the assumptions about DLT/SC implementations. nodes computation needs to be identical,
to ensure that any business standards that ledger. This is an area that is evolving rapidly, and any data used in computation needs to be
emerge draw on the experience and best- many competing projects aim to improve available identically at every node, which
practice enshrined in existing standards such This change of paradigm from messaging various aspects of DLT: permissions, implies that it has to be available on the ledger,
as ISO 20022. to DLT/SC requires us to rethink our ideas smart contract languages, scalability and provided by a client application or oracle.
about business standards. Messaging enables performance, etc. But while some of the Its therefore important to think carefully about
business actors to share specific information present characteristics of the technology the data required by a smart contract to do
about a transaction in a specific context. A will evolve and change, others appear more its work, in addition to the data that might be
standard message typically combines two fundamental. For example, a common shared with the participants in the business
distinct functions - which from familiarity we principle of existing distributed ledgers is that process.
may fail to distinguish - first, to notify an event the same data is present at every node1. For
or instruct an action (make a payment); some use-cases, such as a land registry,
second, to convey information required by the shared open access to data may be desirable,
recipient to complete the action (1000 USD but for many financial industry applications it
to Jane Smiths account number 12345). In a will not. DLT technology, therefore, will need
DLT/SC environment we can separate these to evolve to ensure that either data is not the
functions and in some instances eliminate one same everywhere, or that the ability to access
or both of them. For example, some or all the some data is restricted to specific parties.
information required to complete a payment Furthermore, only certain parties should be
may already be present on the ledger and not able to trigger or approve certain actions
need to be sent; only the instruction (make (e.g. only the owner of an account can initiate
a payment) may be required. Equally, the a payment). In the messaging world, the
business event that gives rise to the payment data each party can see in a given context
(interest falling due on a deposit, for example) is defined by the messages exchanged in
could be raised autonomously by a smart that context, and a partys ability to send a
contract on the ledger (albeit with an external message is defined by its role. In the DLT/SC
trigger), not requiring any external party to world, we will need to find equivalent ways of
act. These characteristics of DLT and what defining who can see what and who can do
makes the technology so potentially disruptive what.

ISO 20022 has an


open and effective
governance model,
which conforms to Some implementations, in order to solve the Not everyone agrees: some DLT adherents Ethereum/Eris specifies Solidity; IBM OBC/Linux
1 2 3

data-visibility problem, use side chains or other challenge the notion of implementing business Foundation Hyperledger project implementation
a general pattern techniques, such as links to persistent encrypted data logic in smart contracts, because of the difficulty support smart contracts through chaincode with
support for GoLand and Java and Javascript planned
sources, to separate shared data from private data. At of accessing external data sources described and
of governance the level of abstraction required to formalize a business concerns about concurrent data access. Rather, they for 2016.
for successful process we would assume an implementation that recommend use of the ledger for data storage only,
supports visibility controls, but would not specify a with data processing conducted in specialised client
standards. mechanism. applications.

6 7
Towards business standards Distributed Ledgers, Smart Contracts,
Business Standards and ISO 20022
Standards Distributed Ledgers, Smart Contracts,
Business Standards and ISO 20022
for DLT/SC (continued) and Contracts

So far we have discussed smart contracts


From these observations we can draw several There is still much work to do in this area, in terms of processing characteristics, but
broad conclusions about the requirements for but to draw a parallel with ISO 20022, we smart contracts promise to be more than
formalising and standardising the application can imagine an equivalent 3 layer model for This change of just a way to capture business logic on the
Smart contracts
of DLT/SC: DLT/SC formalisation, where the Business/ ledger. Opinions vary as to whether they
Conceptual layer provides re-usable definitions paradigm from could replace conventional legal contracts, promise to be more
Formal specifications will describe the for key concepts that are not DLT-specific; mirror them, or supplement them to provide
data and the behaviour (processing) the Logical layer is an abstract but precise
messaging to DLT/ automated execution of some or all of a than just a way to
required to realise a business process. definition of a DLT-implemented use-case (e.g. SC requires us to contractual agreement, but in any case it capture business
The data required is not restricted to the a financial instrument, its relationships and is important that their behaviour is well-
data exhibited externally; specifications lifecycle processes); and the physical layer is rethink our ideas understood and predictable, and this is an logic on the ledger.
will also need to consider data required a concrete realisation of the same use-case about business area where standardisation can play a role.
internally to perform any computation in an existing DLT/SC technology, either a full This could take many forms: standard design
required by the business process; implementation or a skeleton that can be standards. patterns to bring consistency to the way in
further elaborated using the target technology. which contract features are implemented;
It will be necessary to formalise the libraries of tested and industry ratified
roles played by parties involved in a There are other, perhaps less fundamental standardised contracts that can be configured
transaction. Specification of who can see characteristics of DLT/SC technology that will to create concrete implementations; libraries
what and more generally who can do likely influence the development of standards of contract features that can be used to
what according to role will be required. in this area. One is that, when all data is assemble custom contracts; Domain Specific
To observe these restrictions at run-time, replicated everywhere, and maintained in Languages (DSLs) to simplify the capture
DLT platforms will need to support strong an immutable form, bandwidth and storage of contracts and provide transformations to
identity management and access control. become important considerations. In natural (legal) language and executable forms4;
recent years, advances in these areas have tagging schemes to allow a smart contract to
Formal models will not be bound to meant that optimisation of message size, be parameterised from a legal document.
any specific implementation (rather as for example, has ceased to be a concern As the approach sketched in the previous
ISO 20022 logical messages are format for all but very low latency, high throughput section shows, there are clear parallels
independent), so the representation applications. With DLT/SC these concerns are between standardising smart contracts, and
should be abstract, but detailed. Ideally back; designs will need to be efficient, storing the standardised methodology, semantics,
it should be possible to transform a only the minimum data set required to support business processes, and data structures
specification into an implementation, but a given use-case, and using references described by ISO 20022. The eXtended
this is unlikely to be practical initially. reference data codes, or addresses on other Business Reporting Language (XBRL) also
ledgers to capture common data. shows how natural language documents can
Despite being implementation- be prepared for machine processing using a
independent, logical definitions will need data tagging model.
to make some basic assumptions about
the target implementation technology,
including support for generic object-
oriented principles.

As with messaging standards, it will


be important to distinguish between a
standard methodology and meta-model,
which formally describe how and what
information can be captured, and the
standardisation of the specifications
themselves.

4
CLACK is one such proposed DSL that aims also
to be transformable into natural (legal) language, to
ensure consistency between legal and executable
contracts.

8 9
Distributed Ledgers, Smart Contracts, Distributed Ledgers,continued on
Smart Contracts,
Interoperability and re-use: Business Standards and ISO 20022 Business Standards next
and ISO 20022
page
ISO 20022 and DLT/SC

Introduction
Investor Registrar Custodian
The material is derived from a proof-of- (pro-active)
Since ISO 20022 is the existing standard ISO 20022 Business Model
that is broadest in business scope and concept (PoC) exercise undertaken by SWIFT
deployment, and architecturally separates that attempts to automate aspects of the As explained in Appendix A, ISO 20022
business concepts from messaging concerns, lifecycle of a simple fixed-rate bond. This defines a layered architecture, where the top I.P.O. Subscription Ownership Ownership Notification of
use-case was chosen partly because the accounting new Issue
it makes sense to consider ISO 20022 as layer is an abstract model of key business
both a source of business content for DLT/SC mechanics of bond processing today are concepts that is in principle independent
implementations, and as a means to achieve rather complex, with many actors and moving of any automation paradigm. This then, seems
parts, and DLT/SC might offer opportunities Issuer Issuer Initial
interoperability between DLT/SC and other a good place to look for content that can be Issuer Authorisation
Agent
Ownership Settlement &
owner
for simplification, and also because it allows us and details acounting CSD Holdings
automation mechanisms. shared and re-used in a DLT/SC context.
to explore interactions with other technologies,
This section considers which parts of ISO specifically electronic messaging for instructing The diagram below illustrates how the same
20022 can be re-used and how, and what are coupon payments. The PoC is built on the Eris set of definitions can be shared between the Listing Listing Identification Identification Ownership
Process Process Number (SIN) Number (SIN) registrati
the gaps and limitations in the standard when platform, using the Solidity language. existing ISO 20022 standard and a putative
used in a DLT/SC context. It then goes on to new or adapted standard for DLT/SC.
explore how a new standard would need to
adapt and extend ISO 20022 to support more Exchange NNA
Registrar
completely the DLT/SC automation model. (re-active)

Interacting parties in bonds processing

Shared
business
definitions
Reusing the ISO 20022 Business Model Unfortunately, looking more closely, we notice not be a bond. However, when we look in the
Iso 20022 as a messaging Business / Conceptual Defines financial concepts, e.g., Credit Transfer that the model is polluted, not with messaging business model, we also find many accidental
standard and business processes concerns as such, but with assumptions based properties.
Diagram A on page 14 (using the Unified
Modeling Language, UML) is an extract from on the way bonds are issued and processed
The logical message layer
references the business layer Logical Defines e.g. credit transfer messages, the ISO 20022 business model for securities. today (as shown in the diagram above which We start by identifying and removing these,
for semantic definitions to serve the business process It indicates via specialisation that a security is illustrates some of the actors and interactions only to add them back should the need
a kind of asset and that a debt instrument (or required in the issuance process), and which be established in the DLT/SC context. For
bond) is a kind of security. Further, it shows may no longer hold in a DLT environment: example, the business model defines the ISIN
Physical Defines physical syntax, e.g. XML
the attributes common to all securities and the (International Securities Identification Number)
attributes specific to debt instruments, including The first step in making ISO 20022 business as a required property for a bond. In principle,
the details of the calculation information that content suitable for re-use in a DLT/SC context an instrument on a distributed ledger already
Standards for DLT Business / Conceptual Defines financial concepts, e.g., Credit Transfer needs to be specified for interest (coupon) is to filter out the noise of assumptions about has a unique identifier its address on the
and business processes payments. Some attributes (or business current industry structures. To borrow an old ledger but as long as it remains necessary
The logical DLT elements) are defined as simple types, like text distinction, we can separate the essential to refer to that instrument in other business
implementation re-uses strings, others are typed by other structures properties of a concept from the accidental. or technical contexts, a universal identifier is
business concepts to ensure Logical A logical implementation - defines data and behaviour based on For example, a bond is an instrument that required, so the ISIN property stays. We may
new paradigm assumptions
(business components). For example, a party -
interoperability with messaging
say the bond issuer - is defined by a business allows the issuer to raise capital from investors also need to add new properties to support the
component that specifies name, address and (holders) according to agreed terms, typically use case proposed for DLT/SC. This exercise
Physical A physical implementation using regular interest payments (the coupon) and/ cannot be performed mechanically it requires
e.g. Hyperledger, Ethereum
other identifiers such as Business Identifier
Code (ISO 9362 BIC). Each Business Element or repayment of the principal. Issuer, holder, detailed business knowledge and business
and Business Component is fully described, in payment terms etc. are essential properties analysis skills.
English, in the business model. of a bond; without them the instrument would

A logical model for DLT/SC

10 11
Distributed Ledgers, Smart Contracts, Distributed Ledgers,continued on
Smart Contracts,
Interoperability and re-use: Business Standards and ISO 20022 Business Standards next
and ISO 20022
page
ISO 20022 and DLT/SC
(continued)

The table below shows a small example of The full table also flattens the inheritance The Solidity code includes class definitions Reference Data Behaviour Summary
data extracted from the business model for a hierarchy found in the business model - for the major components, each with getter
fixed rate bond, where the components are attributes from Security and Debt Instrument and setter methods for data attributes, with Many ISO 20022 data elements are typed In ISO 20022, behaviour is captured as More stable underlying technology, more
fundamental to the definition of the bond and are merged. Inheritance in the business validation that the caller fulfils the role required according to global reference data standards business processes simple UML activity experience, and much more work will
its processing requirements. Missing from the model is used to illustrate relationships to perform the request. Much more work ISO currency codes, party identifiers diagram-type representations of messages be required to design the meta-models
information in the business model is any idea between concepts; it is not intended to guide will be required to formalise a logical DLT including BIC and LEI, ISO country codes, sent between parties to achieve a business and methodology to capture DLT/SC
of which data elements should be accessible implementation in code. We may introduce implementation (the table is only a start) and to etc. By re-using ISO 20022 definitions for goal, supplemented by written descriptions, implementations formally in an equivalent
to which actors in the process. ISO 20022 inheritance in our implementation and in our formulate best-practice and design patterns to common concepts like parties and countries, as illustrated in diagram C on page 15 for an to the logical model ISO 20022 defines for
does include the notion of role, and in the bond logical representation of it, but this will be guide developers. DLT/SC implementations automatically interest payment. messaging. However, it is clear that there
example some roles are defined, but which role for engineering reasons (cohesion, re-use, re-use these standards, gaining multiple is already scope for re-use of ISO 20022
can read and/or write which data is not explicit etc.). This reasoning, combined with the benefits processing efficiency; universality; While a business analyst can infer some business model content, and that this content,
in the business model, so this is a gap in the information in the table, leads us to a first-pass interoperability with messaging and APIs; of the information required for a DLT/SC suitably filtered, modified and supplemented,
standard when applied to DLT. For the proof-of- implementation of the bond data model in Eris/ consistency with existing industry and private implementation from this material it is not can provide real value to implementers
concept we have addressed this gap by adding Solidity, illustrated in the implementation class data models. possible to apply the ISO 20022 content because it is detailed, consistent and uses
information as shown in the orange columns. diagram B on page 14. directly, because the DLT/SC automation terms and definitions recognised and ratified
model is so different from point-to-point by the financial industry.
messaging. Again, detailed business
knowledge is required, and more work will be
necessary to define how to capture formally
the outcome of the business analysis, whether
Read/Write using a Domain Specific Language or some
other abstract form. For the PoC, several
lifecycle behaviours for fixed-rate bonds were
implemented directly in Solidity, including the
Securities Business Definition Type Issuers Account Account
component Agent Services Owner payment of a coupon. The implementation
(Investor was informed by details of the message flows
Side) documented in the business model for todays
Identification Ways of identifyin the security Securities identification R/W - -
process, but not derived from them directly.

Denomination Currency Currency in which a security is issues or redenominated Currency Code R/W - -

Actual Denomination Amount Nominal value per security unit Currency And Amount R/W - -

Minimum Denomination Indicates the minimum denomination of security Securities Currency R/W - -

Place of listing Market(s) on which the security is listed Trading Market R/W - -

Available Date Date on which securities become available for sale ISO Date Time R/W - -

First Dealing Date Date on which new securities begin trading ISO Date TIme R/W - -

Rating Rating(s) of the security Rating R/W - -

Registration Jurisdiction Jurisdiction in which the security is legally recorded Jurisdiction R/W - -

Dematerialised Indicator Indicates wheather a security exits only as an electronic Yes/No indicator R/W - -
record
Security Status Specifies the status of the security within its lifecycle Security Status Code R/W R/W -

Extract from business model describing bonds,


with additional role information

12 13
Distributed Ledgers, Smart Contracts, Distributed Ledgers,continued on
Smart Contracts,
A Business Standards and ISO 20022 Business Standards next
and ISO 20022
page

Issuer Account Servicer Account Owner

Validate Scheduled
event anouncement
Date
Details Anounce new CA notification Process new
complete? CA event CA event
Additional
event
information
Record Date Update CA event CA notification Process
Reached anouncement update

Notify Balance CA notification Process


Payments Date
x days reached and Entitlements identification

Payments Date Pre-advice CA preliminary advice Process


reached Final Entitlements update
B

Confirm Reflex
Funds received CA confirmation
Cash/Securities Cash/Securities
from issuer
Postings Movements

A B C

Extract from the ISO 20022 business model Class diagram for the implementation of a ISO 20022 Business Process definition for an
for securities. It indicates via specialisation Fixed Rate Bond smart contract in Solidity. interest payment corporate action.
that a security is a kind of asset and that a The implementation draws on business
debt instrument (or bond) is a kind of security. definitions defined in the ISO 20022 business
Further, it shows the attributes common to model.
all securities and the attributes specific to
debt instruments, including the details of
the calculation information that needs to be
specified for interest (coupon) payments.

14 15
Distributed Ledgers, Smart Contracts, Distributed Ledgers, Smart Contracts,
Interoperability and re-use: Business Standards and ISO 20022 Conclusion Business Standards and ISO 20022
ISO 20022 and DLT/SC
(continued)

Interoperability Solidity code executes at every validating For the reasons mentioned in the introduction As DLT/SC technology matures and stabilises,
with messaging node, but each payment should be made to this paper, full-scale standardisation of and the industry gains real-world experience,
exactly once, so for the PoC payment DLT/SC use-cases is probably premature. it will be important to mobilise the standards
This is where one of the key benefits of re- messages are sent by a client application that
would be operated by the institution acting
However, even without a formal methodology,
there is clear value today in re-using reference
community to create the standards necessary
to overcome fragmentation and confusion at
Even without
using ISO 20022 definitions for the DLT/SC
implementation becomes apparent. as account servicer as illustrated below. data standards and business content from an industry level. ISO 20022 already offers a formal
However, the calculations are performed messaging standards, most obviously ISO much that could form the basis of such
In the fixed-rate bond PoC, when a coupon and data assembled into an ISO 20022 20022 which has the widest industry coverage standards. SWIFT, as a key contributor to methodology,
compatible structure for hand-off to the client and an adaptable technical architecture. financial business standards for over 40
falls due, a payment has to be made to
by a smart contract present on the ledger. years, including ISO 20022, expects to take a there is clear value
each bond holder. Payments automation is
well-developed in the financial system, and The same principle would apply to other
messaging standards, including the SWIFT MT
The benefits are twofold: leading role in formulating and operationalising
open business standards for DLT, building on
today in re-using
increasingly based on ISO 20022 messaging.
Because they are derived from the same ISO standard, which continues to dominate in the Avoiding re-inventing the wheel in terms its extensive experience and relationships with reference data
correspondent banking world, and ISO 15022 of business definitions; industry players, regulators and standards
20022 business model, the PoC definitions
for the key data elements required to make a (securities messaging), which is closely aligned bodies. standards and
payment the currency and amount, details with ISO 20022. Facilitating interoperability amongst
DLT implementations and with existing
business content
of the bond holders etc., are fully compatible
with the structures in the ISO 20022 pacs.008 financial industry infrastructure including from messaging
electronic messaging.
Customer Credit Transfer message.
standards, most
These are quick wins that can accelerate the
implementationand acceptance of DLT/SC
obviously ISO
technology for industrial solutions. 20022.

DLT Client Messaging


ISO 20022 (Oracle) ISO 20022 XML
defintions
in Smart
Contracts

ISO 20022
definitions end-to-end

16 17
Distributed Ledgers, Smart Contracts, Distributed Ledgers, Smart Contracts,
Appendix A Business Standards and ISO 20022 Business Standards and ISO 20022
ISO 20022

About ISO 20022 The business/conceptual layer contains The physical layer is the technical realisation of Governance SWIFT, Standards and ISO 20022
formally defined financial concepts and the the logical message, which can be generated
There are two key aspects to ISO 20022. It relationships between them (e.g. a cash mechanically from the logical definition. There are two aspects to ISO 20022 SWIFT has been at the forefront of financial
is a methodology, a recipe to be followed to account is a kind of account; accounts have Several physical layer implementations governance, linked to its two roles as a industry standardisation for over 40 years. SWIFT has been
create financial messaging standards; and it servicers and owners; or a bond is a kind of are possible, which allows ISO 20022 methodology and a repository of content. The SWIFT Standards developed the original
is a body of content, the message definitions security; a bond has an issuer and holders). logical definitions to be decoupled from standard itself effectively the methodology MT standard, which remains the dominant at the forefront of
themselves and other content required by This content is not messaging-specific. implementation technology. is governed by the ISO maintenance standard in international cross-border financial industry
the methodology to explain the underlying
concepts and processes in the business The logical layer defines logical message Content
processes. A revision of the standard is
requested by its users, a working group
payments, and covers many other business
areas, including securities settlement and
standardisation for
domain in which the messages will be used. definitions that can be used by one actor in a under ISO Technical Committee (TC) 68 is reconciliation, corporate actions, trade finance over 40 years.
business process to instruct or inform another. The ISO 20022 methodology allows key convened, which works to deliver a new and treasury.
Methodology The data elements specified in logical concepts and message definitions to be version of the standard (the present version is
messages refer to concepts in the business/ formalized, which ensures that the technical ISO 20022:2013). A draft is submitted to TC SWIFT is also a key contributor to ISO 20022.
The ISO 20022 methodology is in part conceptual layer for their definitions, which format of the specifications is well-defined 68 for approval. Once approved the standard SWIFT contributed to the working group
described by a formal meta-model a precise ensures that the semantics of the logical and consistent. This is a great advantage for is handed over to the Registration Authority that defined the standard, is the single most
definition of what kind of information can be message are well-defined, stable and anyone implementing specifications, because (RA) (currently operated by SWIFT under significant contributor of message definitions,
consistent from one logical message definition
captured. The methodology distinguishes 3
to another. Logical layer content is messaging
it ensures easier analysis and enables contract to ISO) for implementation. The RA is
responsible for the technical implementation
and publishes the content, under contract
to ISO, in its role of ISO 20022 Registration
The ISO 20022
layers: automated consumption of specifications.
specific, but does not impose a particular of the standard, which involves maintaining Authority (RA). SWIFT also operates as RA methodology allows
format or messaging technology. Specifications in the form dictated by the the standards content. Ensuring the business for a number of other key industry standards, key concepts and
standard, can themselves be standardised; relevance and consistency of this content is including ISO 15022 (securities messaging),
formally published as part of the standard. the second aspect of ISO 20022 governance. ISO 9362 (Business Identifier Code, BIC), ISO message definitions
For any process that will be implemented 10383 (Market Identifier Code, MIC), and ISO to be formalized,
3 layers of ISO 20022 more than once, this is a great advantage,
because it brings global consistency to the
Any user can propose to create new ISO
200022 messages (including new content
13616 (International Bank Account Identifier,
IBAN).
which ensures that
Business / Conceptual way business processes are automated, in the business model required to define the technical format
Defines financial concepts, e.g., Credit Transfer reducing overall costs and allowing best- the concepts, terminology and relationships of the specifications
and business processes practice distilled from one implementation to needed to understand them). Each proposal
be re-used in others. is formalised in a Business Justification is well-defined and
a standard document that captures in consistent.
Logical ISO 20022 published content consists of detail the context and motivation for the
Defines e.g. credit transfer messages, to serve business/conceptual definitions and logical development. The RA checks this document
the business process message definitions that are defined according for completeness, then hands it over to one of
to the methodology and maintained according several domain-specific Standards Evaluation
to a strict maintenance process. For example, Groups (SEGs), who are required to judge
Physical the ISO 20022 Financial Institution to whether the proposed development is justified
Defines physical syntax, e.g. XML Financial Institution Customer Credit Transfer in business terms. If so, development can
(pacs.008) specification defines the data that begin. On completion the proposed messages
one Financial Institution sends to another are submitted to the RA for consistency and
to instruct a customer credit transfer (a quality checks, then to the appropriate SEG
payment). The data elements in the pacs.008 for review. The SEG may request changes,
specification, such as Creditor, or Instructed which the submitter is required to implement,
Amounted, refer to the semantic content in before the messages are again submitted to
the business/conceptual layer above for their the RA for publication.
definitions. ISO 20022 also specifies roles
Instructing Agent, Ultimate Creditor etc. A similar process applies for maintenance. Any
and which role should send and receive which user, or prospective user, can submit a change
message in which business context. request for an existing message. An annual
process operates where change requests are
referred to the SEGs for approval or rejection.
Approved change requests are applied to the
messages, usually by the initial submitter, and
a new version of the message is published by
the RA.

18 19
About SWIFT Disclaimer

SWIFT is a cooperative of and for the SWIFT supplies this publication


financial community - a trusted provider for information purposes only. The
with our sights on serving the industry information in this publication may
in new and ground-breaking ways. change from time to time. You must
always refer to the latest available
For more information about SWIFT, version.
visit www.swift.com
To find out more about our work on
distributed ledger technologies, please
contact DLT@swift.com
swiftcommunity company/SWIFT

Copyright
Copyright SWIFT SCRL, 2016
all rights reserved.

SWIFT 2016
57221 - September 2016