6
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
7
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
8
common requirements are the first step towards defining a methodology for DLT
standardization.
9
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
Dostları ilə paylaş: |