19
2.4.3 Ownership Record Loading
Requirement
№41
: The system is able to display the prices for securities involved in the
voting process, and to calculate the principal amount for the loaded ownership records.
Normally prices and principal amounts are not needed, but for certain instruments (like
bonds), special kinds of meetings and simply for convenience having this information
could be desirable.
2.4.4 Electronic Identification
Requirement
№
70: The system is able to securely authenticate beneficial owners (or their
Proxies) via electronic identification (eID).
In some countries, the government or government-sanctioned organizations issue
electronic forms of ID. These eIDs can be used to securely authenticate their owner in
secure manner. For the Voting Parties who own these eIDs, using them is often the
preferred way of authentication and it must be supported by the system.
2.4.5 Proxy Chains
Requirement
№
100: It is possible for a proxy to assign further proxies to act on its behalf.
The act of assigning a proxy must be recorded in the blockchain.
In some cases according to local legislations the beneficial owner may not possess the
right to vote as well, which can be assigned to its Intermediary by default. Intermediary
can re-assign voting rights to the beneficial owner as a proxy for its own shares to be able
to vote personally. The beneficial owner can, in turn, delegate further to an actual proxy,
forming a chain of proxies.
2.4.6 Automatic Custodian Proxies
Requirement
№
110: It is possible for an Intermediary to assume a proxy role on behalf of
beneficial owners who hold accounts at it automatically unless the beneficial owner
expresses a desire to participate in the voting directly.
In some cases it may be beneficial for proxy rights to be assigned to the Intermediary
automatically, requiring the beneficial owner to explicitly express the desire to participate
in the voting. This may be desirable for the retail shareholders who hold limited voting
rights to make any difference. Intermediaries may pool their voting rights together and
vote in the interest of all of their beneficial owner clients. This is subject to any rights
granted to the beneficial owners by local legislation or rules.
20
2.4.7 Voting Right Responsibilities
Requirement
№
123: The system supports re-registration and correctly determines which
shares are eligible to vote.
In some countries, the custody chain cannot participate in the voting in the normal way.
It may require that all shares that intend to participate in the voting are de-registered from
their custodian and re-registered at the registrar or another designated entity such as the
repository.
Requirement
№125
: The system supports sending requests to block shares and other
external notifications related to the voting rights issue.
It may be necessary for external systems to know that the voting rights have been issued.
In different countries it can be used for different purposes: issuing offline certificates of
attendance, blocking shares to prevent their trading until the voting is over or for another
reason.
2.4.8 Ownership Record Updates
Requirement
№
130: An Intermediary is able to reload ownership records of a Voting
Party. The system is able to recalculate the voting right tokens according to the updated
records.
Some laws require the updating of the initially loaded voting rights with the new positions.
This may occur due to trading (when it is permitted), reconciliation settlements, mistakes
in applying rules or legislation and so on. The frequency and detailed requirements of the
updates are unique to each jurisdiction.
Requirement
№
132: When ownership records are updated, the system supports
validation of already cast votes and can adjust them if it is necessary to keep the counts
consistent.
Position updates affect voting rights, which in some cases (pre-voting or corrections) can
be already cast. The system must keep itself consistent at all times, so if voting rights
amounts are updated, cast votes may also need to be adjusted. The exact algorithm for
adjustment of cast votes can be defined by each implementation.
21
2.4.9 Voting Cancellation
Requirement
№
141: A Voting Party is able to cancel the voting instruction that it has cast.
Voting cancellation may be necessary for Voting Parties to correct their mistakes or to
change opinions prior to the voting deadline. The availability and restrictions on the use
of this feature are subject to the local rules and legislation.
Since DLT does not support erasing previously performed transactions, cancellation must
be implemented as marking previous transaction as invalid or creating a compensating
transaction that transfer the right to vote back to the Voting Party. The fact that the
instruction was cancelled must remain logged in the ledger.
2.4.10
Voting Timeline Management
Requirement
№
142: The system must support pre-voting, issuing voting rights and
casting votes prior to the record date.
In some countries it is possible to vote early, prior to the record date. The votes can be
cast early and are adjusted later if there are any changes in share ownership at the
registry or depository.
Requirement
№143
: The system must support custom instruction execution dates.
In many cases, it may be desirable for instructions to be executed not immediately, but at
a specified point in time. This feature can be used to fulfil process or regulation
requirements and for user convenience.
2.4.11
General Meeting Services
Requirement
№63
: A Voting Party must be able to register to participate in the general
meeting physically and obtain an attendance card from the party responsible for issuing
it.
In many jurisdictions, especially those with lower degree of automation, it is required for
the Voting Party to present an attendance card from an authorized party before they may
be admitted to the general meeting. The system must support issuing and keeping
records of the issued cards.
Dostları ilə paylaş: |