General Meeting Proxy Voting on Distributed Ledger



Yüklə 257,46 Kb.
səhifə2/9
tarix25.06.2018
ölçüsü257,46 Kb.
#51842
1   2   3   4   5   6   7   8   9

 

 

For  foreign  shareholders  the  complexity  rises  to  a  much  higher  level.  Expectations  of 

means of authentication, understanding the process and relevant laws and local practices 

are high. In some cases the interface language may also prove to be a barrier to vote. 

These  shareholders  would  like  to  be  able  to  exercise  voting  rights  on  their  foreign 

investments just as easily as they do domestically. However, this is not always achieved 

with current voting mechanisms. 

 

Objective 



This document aims to provide a set of requirements encompassing all major needs of 

voting  on  general  shareholder  meetings,  addressing  problems  present  in  the  current 

voting systems. These requirements are designed to be independent of any market as 

much as possible and are extensible, supporting further customization.

 

 

Document Structure 



This document contains a set of common requirements, as discussed and agreed by the 

members of the CSD Working Group on DLT.  

The structure of the document is as follows: 

Chapter 2 describes functional requirements, defining the actors, the voting process and 

its  various  high-level  details,  including  both  generic  minimal  viable  product  (MVP)  and 

various local extensions. 

Chapter 3 describes trust requirements to the DLT solution designed to mitigate the risks 

of the e-proxy voting process incurred in the traditional systems. 

Chapter 4 describes data entities necessary to support the process that must be stored 

on DLT to fulfill the trust requirements. 

Chapter 5 describes non-functional requirements of the software solution. 

Chapter 6 describes the plans for future development of this document and the e-proxy 

voting on DLT problem in general. 

 

Alignment with the Industry Standards 



The financial industry has business standards and data that enable the creation of robust, 

interoperable multi-party business processes by reducing the ambiguity of specifications 




 

 

and fostering efficient re-use of knowledge, skills and technology. There are two ways in 

which these standards work. 

First,  standards  specify  a  methodology  to  capture  and  publish  formal  business 

specifications in a consistent and precise way.  

Second, they provide governance processes that can be used to standardize the content 

and evolution of the business specifications themselves. These processes are among the 

key benefits of reusing the existing standard definitions for the DLT implementations. 

The benefits of reusing existing standards are twofold: 

 

Avoiding ‘re



-

inventing the wheel’ in terms of business definitions;

 



  Facilitating interoperability amongst DLT implementations and with existing 



financial industry infrastructure including electronic messaging. 

These benefits can be considered as 

‘quick wins’ that can accelerate the implementation 

and acceptance of DLT technology for industrial solutions while the work on producing 

full, all-encompassing specialized DLT standards is underway. 

The requirements in this document are aligned on a high-level with the business layer of 

the ISO 20022 standard. 

 

Out of Scope 



There are notable topics which are not covered in this document. Among them are the 

technological  architecture  of  the  solution  and  the  integration  methodology  between 

systems built according to these requirements. 

The architecture of the solution is something that we believe should be independent of 

the high-level standard. Architecture is a specific detail of implementation and can differ 

from  one  solution  to  another  even  if  they  operate  within  the  same  legislation. 

Organizations implementing these requirements will use their own judgment to design the 

most efficient architecture for their solutions.  

In addition, the architecture will be built around or will even impose some local features 

on the solution. The working group would like to make it possible to customize each local 

system as required by its administrators, so we do not define any concrete architecture 

in the product requirements and leave it as an implementation choice. 

The  integration  methodology  may  be  added  to  a  future  version  of  this  document.  The 

working  group  sees  the  global  context  as  a  key  opportunity  in  this  effort,  and  sharing 




 

 

common  requirements  are  the  first  step  towards  defining  a  methodology  for  DLT 

standardization.  




 

 

 

FUNCTIONAL REQUIREMENTS 



Functional requirements describe what the system must be able to do and how it should 

be accomplished. Functional requirements are driven by the needs of the business and 

the market, regulators

 requirements and local laws. 



This chapter contains a high-level set of requirements necessary to describe an MVP for 

an e-proxy voting system. The requirements also outline a set of extension requirements 

that cover the specific needs of the markets in Russia, South Africa, Switzerland, France, 

Chile,  Argentina,  Nordic  countries  and  Baltic  countries.  We  believe  that  these 

requirements will also cover many other markets with limited adaptations. 

 

Functional Role Definitions 



Functional role definitions describe the actors who have rights to process transactions on 

the distributed ledger.  

There are three actors in the system. Their definitions are synchronized with the e-proxy 

voting ISO 20022 messaging standard. 



Issuer  or  Issuer  Agent.  The  legal  entity  that  has  the  right  to  issue  securities  or  the 

organization appointed by the issuer for the purposes of administration of a security issue 

or processing of a corporate action or a meeting event. In some cases, the issuer acts as 

its own agent. 



Intermediary. Institutions providing services to other institutions in the frame of the proxy 

voting processing chain, i.e. a proxy voting agent. 



Voting Party. A party that  has the right  to vote on resolutions and agenda items on a 

shareholder meeting. 



Auditor/Regulator. An actor who does not take actions that impact the business process, 

but may have privileged access rights that allow it to verify that certain parts of the process 

are executed correctly. 

 

Process Flow 



E-proxy  voting  process  involves  multiple  steps  that  in  general  are  similar  between 

different countries. Depending on the local regulations they may be extended or placed 




Yüklə 257,46 Kb.

Dostları ilə paylaş:
1   2   3   4   5   6   7   8   9




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə