General Meeting Proxy Voting on Distributed Ledger

 

 

28 

 

Infrastructure failure 

Risk 

Description 

Mitigation 

Loss of control 

over network 

It may be possible for a 

perpetrator to take over the 

network or to disrupt its 

operation completely, preventing 

the network operator from 

fulfilling its responsibilities. 

Each individual node of the 

network can be easily replicated 

anywhere as long as its private 

key is not compromised. Any 

compromised node only gives the 

perpetrator authority to perform 

actions valid for that node and the 

state of the system. Owner of each 

mode must take measures to 

protect its private keys from being 

compromised. 

Denial of service 

Voting process, like any other, is 

susceptible to denial of service 

attacks which can bring down 

key infrastructure nodes and 

prevent execution of business 

processes in a timely manner. 

Each individual node of the 

network can be easily replicated 

anywhere without loss of data. The 

network can automatically rewrite 

its physical routing when that 

happens. 

Difficulty of 

recovering 

trustworthy and 

complete data for 

audit and 

regulation 

purposes 

Regulators often change their 

requirements to processes in 

the financial industry, including 

shareholder voting. These 

changes create significant costs 

to alter the systems that can 

provide the data as required by 

regulators or auditors. 

Blockchain supports having 

master keys with elevated read 

access rights, which can be given 

to the auditors or other parties 

which require this access. The 

blockchain stores all data that is 

significant for the process. If the 

regulatory requirements change, 

the regulators or auditors can 

adapt which data they retrieve 

from the chain to satisfy these 

requirements. 

---

 

 

29 

 

DATA ENTITIES IN DISTRIBUTED LEDGER 

 

General considerations 

This  document  does  not  postulate  the architecture  or  the  exact  structures  of data  that 

should be used in  the implementation of a local proxy  voting solution. We believe that 

when systems based on these requirements are implemented for production use, there 

will be detailed standards that require certain data elements to be stored in a particular 

way to enable easy interoperability.  

This chapter looks into what kinds of data entities may be stored on the ledger in general 

in  relation  to  proxy  voting  product,  and  how  its  business  vocabulary  is  affected by  the 

move from traditional messaging solutions to DLT-based solutions.  As described earlier, 

storing data in the ledger allows the system to provide certain guarantees to its users and 

to be the source of trust and thus reduces many of the traditional risks in the  process. 

The copies of data stored in the ledger are the golden source of truth, and any replica of 

this data stored elsewhere is not considered valid if it is different from what is stored in 

the ledger. 

Data stored in the distributed ledger can be classified into several distinct kinds: 



  Regular data and metadata, stored on the network (e.g. meeting agenda 

information) or on the node (e.g. identification data). Access to this kind of data is 

defined in the same way as in traditional systems. 



  Tokens. They are owned by the wallets in which they are stored and may be 

transferred by the owner of the wallet (and in some cases, other parties 

according to particular rules). 



  Transactions, which are traces of token movements between wallets. They can 

never be created manually. 

This  classification  emphasizes  the  differences  on  how  the  data  can  be  perceived, 

accessed and acted upon. 

 

Access Rights Considerations 

Most data entities in the distributed ledger contain some kind of confidential information 

and  must  not  be  accessible  without  proper  authorization.  Despite  that  many  DLT 

platforms,  especially  those  that  are  permissionless,  do  not  naturally  support  granular 

confidentiality  controls,  any  system  implementing  these  requirements  must  be  able  to 

---

 

 

30 

provide sufficient segregation of access rights. 

Those DLT platforms that don’t support 

proper  confidentiality  and  access  controls  may  be  unsuitable  for  implementing  this 

product. 

In general, voting requires three large roles: Issuer Agent, Intermediary and Voting Party. 

However, local extensions may and likely will introduce their own more granular roles to 

comply with local laws. 

The Auditor role deserves a special mention. There are different kinds of auditors with 

different needs: 



  Regulators, which may require full read access to all data, and possibly even the 

ability to execute certain administrative actions. Each regulator is certain to 

impose its own requirements to its access rights and they may be hard to predict 

on a global scale. For the sake of completeness, we assume that most regulators 

will want full read access on all entities and transactions. 



  Auditors of the market participants, who perform audit on behalf of their 

employers. These auditors will need to have access rights corresponding to the 

access rights of their employer and may not have any higher access rights.  



  Independent auditors, who perform the audit to prove the correctness of the 

process in general, without looking at any specific details. They don’t need any 

access to confidential data and can work with the data that is available publicly. 

Implementing an Auditor/Regulator role is likely to be a requirement in every jurisdiction. 

Due to the nature  of DLT, data can’t be modified or deleted on the distributed ledger. 

Instead, if at any time it is necessary to modify or delete any piece of data, a separate 

new record is created, which also includes in itself a trait that invalidates the old record. 

The  old  record  will  remain  visible  and  accessible  on  the  network  for  all  time.  Any 

amendments of confidential data and changes to network algorithms must take this into 

account. 

 

Alignment with the business layer of ISO 20022 

ISO 20022 standard is the most widely accepted standard in the financial world today that 

covers business, logical and physical layers of many processes in the industry that require 

integration. DLT-based solutions are bound to make significant alterations to the logical 

and  physical  parts  of  this  standard 

–

  the  means  of  data  storage,  integration  and 

communication on distributed ledgers are very different from messaging. 

---

 

 

31 

The business standard, however, was designed to fit the business process, rather than 

the  technology  on  which  it  is  implemented.  As  a  part  of  this  document,  we  provide  a 

detailed review of the data elements from existing ISO 20022 standard on voting including 

proxy  voting  (seev.002-008  messages)  that  are  mapped  to  the  requirements  from  this 

document. 

The 

detailed 

cross-reference 

is 

available 

in 

the 

separate 

excel 

file 

MDR_Part3_ProxyVoting_Maintenance_2014_2015_DLT_aligned.xls  that  is  distributed 

jointly with the present document. That excel file is based on the ISO 20022 specification 

of the voting process. 

After performing this review, we can with confidence say that the business layer of ISO 

20022 can be implemented on DLT with minimal alterations. Most of the business terms 

and definitions apply to the DLT-based process. 

There are two main difference points to consider: 



  DLT has different kinds of data, which should not be treated in the same way. In 

messaging, the meaning of data was always explicitly encoded in the data itself. 

On DLT, it can be encoded in part by how a particular data entity is represented 

–

 e.g. the fact that a transaction has happened between particular wallets means 

something on its own, without any additional data fields. 



  DLT is a new technology that has a different cost structure for solutions based on 

it. When DLT-based products become commonplace, changes in the cost 

structure will drive businesses to adapt business processes so that they can take 

advantage of that new cost structure, rather than go against it. It would result in 

changes in business processes, and, as a result, the business vocabulary.  

In the future, specialized DLT-based standards may need to be created, and it may be 

too early to define them fully at this point in time. However, for the moment we can use 

the business layer of ISO 20022 to guide definitions of DLT-based products. 

 

---

 

 

32 

 

NON-FUNCTIONAL REQUIREMENTS 

Non-functional requirements are heavily dependent on the local operating environment 

of the system. For each particular implementation, the exact service levels for availability, 

performance,  integration  and  so  on  may  be  not  the  same,  if  not  greatly  different.  This 

chapter describes the requirements that must be defined by the implementing system. 

№

  Requirement 

Description 

1 

General 

availability 

The system must define how much downtime it may have per year.  

2 

Data integrity 

The  system  must  provide  audit  trails.  The  audit  trails  must  be  easily 

retrievable and understandable for all appropriate parties  according to the 

local legislation. 

3 

IT environments 

It must be possible to deploy the system in non-production environments as 

required by the implementing parties. 

4 

Interoperability 

The system must provide open, documented APIs for integration purposes. 

The distributed ledger must not use any non-public integration channels. 

The  system  should  be  able  to  support  a  hybrid  model  i.e.  electronic 

messaging  and  DLT  to  foster  interoperability  and  to  avoid  market 

fragmentation. 

5 

Performance 

The  system  must  define  maximum  acceptable  response  time  to  a  user 

action. 

6 

Recoverability 

The system must define recovery time and point objective parameters and 

guarantee that they will be met. 

7 

Reliability 

The  system  must  support  a  failover  configuration  that  is  able  to  fulfill  its 

recoverability and availability requirements. 

8 

Scalability 

The  system  must  define  the  minimum  amount  of  simultaneous  meetings, 

voting parties per meeting and transactions per second that it can support. 

9 

Security 

The system must pass relevant security tests and be compliant with relevant 

security measures (e.g. HSMs, 2-factor authentication, etc). 

10  Accessibility 

The system must define its supported range of platforms and or/devices with 

which it can be accessed. 

11  Usability 

The system must define its expectations to the level of technology literacy 

of is target audience and provide sufficient learning tools to compensate for 

the lack of it. 

---

 

 

33 

 

FUTURE DEVELOPMENTS 

This document is a work in progress that is maintained by the  CSD Working Group on 

DLT. Future versions will include but are not limited to: 



  wider coverage of the international market, including more countries, 



  deeper alignment with existing international standards, e.g. ISO 20022, 



  complete requirements for a cross-system and cross-border integration solution, 



 

… and more.

 

The work outlined in this document is innovative in its nature. The members of the working 

group hope that this document will be useful to the wide range of market participants in 

understanding, implementing and standardizing DLT solutions of all kinds and in the field 

of e-voting in particular.  

---

 

 

34 

 

DISTRIBUTION AND CONTACTS 

This  work  is  licensed  under  the  Creative  Commons  Attribution-NoDerivatives  4.0 

International 

License. 

To 

view 

a 

copy 

of 

this 

license, 

visit 

http://creativecommons.org/licenses/by-nd/4.0/

  or  send  a  letter  to  Creative  Commons, 

PO Box 1866, Mountain View, CA 94042, USA. 

This document may be shared by the member organizations of the working group freely 

with the interested parties. The working group welcomes feedback on the contents of the 

document as well as proposals for cooperation on any further work. 

The logos and company names of NSD, Strate, SIX Securities Services, Nasdaq, DCV, 

Caja  De  Valores,  SWIFT  and  SLIB  are  registered  trademarks  of  the  respective 

companies. 

To get in touch with the working group, please contact: 



  Alexander Chekanov, NSD, 

[e-mail]

  



  Tanya Knowles, Strate, 

[e-mail]

  



  Urs Sauer, SIX Securities Services, 

[e-mail]

  



  Michael Rexestrand, Nasdaq, 

[e-mail]

 



 

Claudio Calderón

, DCV, 

[e-mail]

  



  Alejandro Wyss, Caja de Valores, 

[e-mail]

  

The alignment of this work with the ISO 20022 has been prepared in deep collaboration 

with SWIFT. To get in touch with them, please contact: 



  Stephen Lindsay, SWIFT, 

[e-mail]

   

The adaptation of this document to the French market has been prepared with a major 

contribution from SLIB. To get in touch with them, please contact: 



  Guillaume Guerin, SLIB, 

[e-mail]