General Meeting Proxy Voting on Distributed Ledger
Yüklə 257,46 Kb.
|
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.
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.
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.
Yüklə 257,46 Kb. Dostları ilə paylaş:
|