MAINTENANCE CHANGE REQUEST
FOR THE UPDATE OF ISO 20022 FINANCIAL REPOSITORY ITEMS
A. Name of the request:
Proxy Voting Messages Maintenance for year 2014/2015
B. Submitting organization(s):
SWIFT
C. Related messages:
Under this project, all the following ISO 20022 Proxy Voting messages would be maintained:
Message Name
Identifier
1 MeetingNotificationV04
seev.001.001.04
2 MeetingCancellationV04
seev.002.001.04
3 MeetingEntitlementNotificationV04
seev.003.001.04
4 MeetingInstructionV04
seev.004.001.04
5 MeetingInstructionCancellationRequestV04
seev.005.001.04
6 MeetingInstructionStatusV04
seev.006.001.04
7 MeetingVoteExecutionConfirmationV04
seev.007.001.04
8 MeetingResultDisseminationV04
seev.008.001.04
D. Commitments of the submitting organization:
SWIFT confirms that it can and will:
-
undertake the development of the new version of the candidate ISO 20022 message
models that it will submit to the RA for compliance review and evaluation by December
1.
-
provide a new version of part 1 of the Message Definition Report (MDR) by December
1, and new examples of valid message instances of each message by May 1 at the latest.
-
address any queries related to the description of the new models and messages as
published by the RA on the ISO 20022 website.
SWIFT confirms that it intends to organize the actual implementation of the new version of the
messages once the related documentation has been published by the RA.
SWIFT confirms its knowledge and acceptance of the ISO 20022 Intellectual Property Rights
policy for contributing organizations, as follows.
“Organizations that contribute information to be incorporated into the ISO 20022 Repository
shall keep any Intellectual Property Rights (IPR) they have on this information. A contributing
organization warrants that it has sufficient rights on the contributed information to have it
published in the ISO 20022 Repository through the ISO 20022 Registration Authority in
accordance with the rules set in ISO 20022. To ascertain a widespread, public and uniform use
of the ISO 20022 Repository information, the contributing organization grants third parties a
non-exclusive, royalty-free license to use the published information”.
E. Contact persons:
Jacques Littré – SWIFT Standards, jacques.littre@swift.com
Document1
Produced by SWIFT on 29 October 14
Page 1
ISO 20022 Proxy Voting Messages Maintenance 2014/2015
Table of Contents
1
CR0026: Replace Outdated BICOrBEI Elements............................................................................ 3
2
CR0404: Delete the Identification Component ................................................................................ 8
3
CR0405: Make the SubmittedBySecurityHolder Flag Optional ................................................... 11
4
CR0406: Align Extension Elements with Latest Version ............................................................. 14
5
CR0407: Allow Unknown Value for AttendanceRequired ............................................................ 17
6
CR0409: Set Meeting Date as a DateTime Data Type ................................................................... 20
7
CR0410: Add new Optional Elements EarlyVoteWithPremiumDeadline and
EarlyIncentivePremium ........................................................................................................................... 24
8
CR0411: Make the EntitlementSpecification Element Optional .................................................. 27
9
CR0412: Make Resolution/Type Element Optional and Delete Ordinary Code ......................... 29
10
CR0413: Add A DateTime Data Type to VoteMarketDeadline Element....................................... 31
11
CR0415: Make NotifyingParty Element Optional .......................................................................... 34
12
CR0427: Add new BondHolderMeeting as Meeting Type ............................................................ 37
13
CR0428: Add Start or EndOfDay to EntitlementFixingDate ......................................................... 39
14
CR0429: Add Optional Entitlement to Repetitive Resolution ...................................................... 41
15
CR0430: Add new Deadline in PowerOfAttorneyRequirements .................................................. 44
16
CR0431: Add New Optional PreviousInstructionInvalidity Flag .................................................. 47
17
CR0432: Delete MessageCancellation Element ............................................................................ 56
18
CR0433: Update Cancellation Guideline ........................................................................................ 59
19
CR0434: Make InstructingParty Optional ...................................................................................... 61
20
CR0435: Make ReportingParty Optional ........................................................................................ 64
21
CR0436: Update ReceivedByIssuerOrRegistrar Code Value Definition ..................................... 67
22
CR0437: Make VotePerResolution Element Optional ................................................................... 69
23
CR0438: Add New Withdrawn Code in VotePerResolution ......................................................... 72
24
CR0439: Add New “Say on pay” Vote Options ............................................................................. 75
25
CR0440: Change Data Type of Element TotalNumberOfSecuritiesOutstanding ....................... 78
26
CR0445: Change Date Element Name by DateTime in ISODateTime elements. ........................ 81
27
CR0446: Harmonize SecurityIdentification DT with Latest Used in Securitities Messages ..... 84
Document1
Produced by SWIFT on 29 October 14
Page 2
1 CR0026: Replace Outdated BICOrBEI Elements
A. Origin of the request:
A.1 Submitter: SWIFT
A.2 Contact person:
Alexandre Kech
Tel: +32 2 655 3942
Mail: alexandre.kech@swift.com
A.3 Sponsors: N/A
B. Related messages:
All securities message sets: Settlement & Reconciliation, Corporate Actions, Investment Funds,
proxy voting, Regulatory reporting, Issuer agent, etc.
C. Description of the change request:
In concordance with the RMG resolution 10/126 (BIC identifier in the Repository) approved by
the RMG at the Tokyo meeting of May 2010, the following rules will be followed:
1. To identify financial institutions, only the newly created data type BICFIIdentifier can be
used (iso BICIdentifier).
2. To identify non-financial institutions, only the newly created data type
BICNonFIIdentifier can be used (iso BEIIdentifier).
3. The updated AnyBICIdentifier datatype can still be used where either a financial
institution or a non-financial institution may be present.
4. The corresponding recommended message element names are BICFI, BICNonFI and
AnyBIC, unless more specific names are used.
5. There should no longer be any reference to BEI in either artefacts names or in
definitions.
This change request, if approved by the Standards Evaluation Group, should only be applied, if
additional change requests are impacting the same message sets (see list of message sets above).
D. Purpose of the change:
The purpose of this change request is to align the existing set of messages with the RMG
resolution 10/126 (BIC identifier in the Repository).
E. Urgency of the request:
For inclusion in the next ISO 20022 maintenance release.
F. Business examples:
Elements like PartyIdentificationXX make reference to BIC and/or BEI. The elements making
reference to those components must be updated to comply with the 10/126 resolution of the
RMG.
The impact on Securities messages will be largely limited to the renaming of message elements
called today BICorBEI into BIC.
G. SEG recommendation:
This section is not to be taken care of by the submitter of the change request. It will be
completed in due time by the SEG(s) in charge of the related ISO 20022 messages.
Document1
Produced by SWIFT on 29 October 14
Page 3
Consider
Y
Timing
- Next yearly cycle: 2010/2011
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2010 and
completes with the publication of new message versions in
the spring of 2011)
- At the occasion of the next maintenance of the Y
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
Priority:
high
medium
low
- Other timing:
Comments:
Approve, to be implemented at message set level organically, but at the latest within 3 years
(except for Investment Funds messages that are expected to be maintained in 2016/2017 only).
Reject
Reason for rejection:
H. Impact analysis:
This requirement applied to the PV messages results in renaming all occurrences of the
”BICOrBEI” message elements as “AnyBIC”.
Those messages elements appears only in the following 2 message components used throughout
the 8 PV messages: PartyIdentification9Choice and PartyIdentification3 (illustrated below)
a. The PartyIdentification9Choice MC appears in all 8 PV messages and is used to type the
message elements AccountOwner, RightsHolder, EmployingParty, Identification, Name,
NotifyingParty, InstructingParty, RequestingParty, ReportingParty.
Document1
Produced by SWIFT on 29 October 14
Page 4
a. The PartyIdentification3 MC appears in 6 out of the 8 PV messages i.e. in seev.001, 002,
003, 004, 005, and seev.008 and is used exclusively in the structure of the
SafekeepingPlace element in those messages (as shown below).
I. Proposed implementation:
a. Replacement of PartyIdentification9Choice
Since the name change from “BICOrBEI” to “AnyBIC” has already been applied in previous
years in other securities messages like the CA messages (seev.03x.001.05 and seev.04x.001.05
messages), it is proposed to reuse the same messages components as the ones used in the latest
version of the CA messages i.e. the PartyIdentification40Choice MC illustrated below where
AnyBIC is used.
Document1
Produced by SWIFT on 29 October 14
Page 5
So, in all the PV messages, replace all the 28 occurrences of the PatyIdentification9Choice MC
by the PartyIdentification40Choice MC.
b. Replacement of the PartyIdentification3 MC
In this case, the PartyIdentification3 component is not reused in any other more recent securities
messages, therefore we have 2 possibilities:

either we keep the existing component structure and create a new MC based on
PartyIdentification3 and changing the name of BICOrBEI in AnyBIC; however to
rationalise the structure we should rather directly type the Party element by the
AnyBICIdentifier data type.

or we reuse the same MC SafekeepingPlaceFormat2Choice typing the
SafekeepingPlace elements in the recent CA messages so as to harmonize the way the
Safekeeping Place is defined in both message sets.
Document1
Produced by SWIFT on 29 October 14
Page 6
The above 2 options will be discussed at the SEG ET meeting.
Implementation note:
The above remark saying that the “Party Element is no longer present” is erroneous because the
element “TypeAndIdentification/Identification” is typed by the AnyBIC data type in the
SafekeepingPlaceFormat2Choice component.
J. Therefore for the replacement of the PartyIdentification3, implement the second option i.e.
change the data type of SafekeepingPlace by SafekeepingPlaceFormat2Choice to ensure full
alignement with the Corporate Actions and Settlement and Reconciliation MX
messages.Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing
Timing
-
As requested
K. Final decision of the SEG(s):
Approve
X
Comments: Preference was to keep the existing component structure and create a new MC (versus
reusing the same MC)
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 7
2 CR0404: Delete the Identification Component
A. Origin of the request:
A.1 Submitter: SWIFT.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors:
B. Related messages:
seev.001.001.04
MeetingNotificationV04
seev.002.001.04
MeetingCancellationV04
seev.003.001.04
MeetingEntitlementNotificationV04
seev.004.001.04
MeetingInstructionV04
seev.005.001.04
MeetingInstructionCancellationRequestV04
seev.006.001.04
MeetingInstructionStatusV04
seev.007.001.04
MeetingVoteExecutionConfirmationV04
seev.008.001.04
MeetingResultDisseminationV04
C. Description of the change request:
In all the seev.001 to seev.008 messages, remove the “Identification” component containing the
message “Identification” and the “CreationDateTime” elements.
D. Purpose of the change:
The usage of the ISO 20022 BAH (Business Application Header ) with securities messages has
been recommended by the Securities SEG after those Proxy Voting messages were published.
Therefore the “Identification” and the “CreationDateTime” element s are now redundant with
the identical elements in the ISO 20022 Business Application Header to be used with the ISO
20022 Securities messages.
E. Urgency of the request:
Maintenance cycle 2014/2015
F. Business examples:
Document1
Produced by SWIFT on 29 October 14
Page 8
G. SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H. Impact analysis:
One occurrence of “Identification” appears in each PV message.
I. Proposed implementation:
Remove the Identification element in the 8 messages.
Document1
Produced by SWIFT on 29 October 14
Page 9
J. Proposed timing:
A. The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
-
As requested
K. Final decision of the SEG(s):
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 10
3 CR0405: Make the SubmittedBySecurityHolder Flag
Optional
A. Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B. Related messages:
seev.001.001.04
MeetingNotificationV04
C. Description of the change request:
Make the element “Resolution/SubmittedBySecurityHolder” optional or add a choice with a
code value “Unknown”.
D. Purpose of the change:
This is a mandatory yes / no flag. The group agreed that there would be instances where this
would not be known at the time of the meeting announcement and therefore we would need to
allow an ‘unspecified’ value, else make this an optional field.
E. Urgency of the request:
Maintenance cycle 2014/2015
F. Business examples:
N/A
G. SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Document1
Produced by SWIFT on 29 October 14
Page 11
Reject
Reason for rejection:
H. Impact analysis:
Only impacting the seev.001 message.
I. Proposed implementation:
In the seev.001 message, make the element Resolution/SubmittedBySecurityHolder optional as
illustrated below:
J. Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
-
As requested
K. Final decision of the SEG:
Approve
X
Comments:
Document1
Produced by SWIFT on 29 October 14
Page 12
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 13
4 CR0406: Align Extension Elements with Latest Version
A.
Origin of the request:
A.1 Submitter: SWIFT.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors:
B.
Related messages:
seev.001.001.04
MeetingNotificationV04
seev.002.001.04
MeetingCancellationV04
seev.003.001.04
MeetingEntitlementNotificationV04
seev.004.001.04
MeetingInstructionV04
seev.005.001.04
MeetingInstructionCancellationRequestV04
seev.006.001.04
MeetingInstructionStatusV04
seev.007.001.04
MeetingVoteExecutionConfirmationV04
seev.008.001.04
MeetingResultDisseminationV04
C.
Description of the change request:
In all the seev.001 to seev.008 messages, align with latest Extension components i.e. rename the
last “Extension” element as “SuplementaryData” and typed by “SupplementaryData1” as
illustrated below.
D.
Purpose of the change:
Migrate to the latest version of the “Extension” component, i.e. the SupplementaryData
component agreed by the RMG and requested by the RA in CR0049.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
Document1
Produced by SWIFT on 29 October 14
Page 14
G. SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
One occurrence of the Extension element in all 8 PV messages.
I.
Proposed implementation:
In all seev.001 to 008 messages, rename the element “Extension” as “SupplementaryData” and
change the date type “Extension2” by “SupplementaryData1” as illustrated below.
Document1
Produced by SWIFT on 29 October 14
Page 15
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG(s):
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 16
5 CR0407: Allow Unknown Value for AttendanceRequired
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
seev.001.001.04
C.
MeetingNotificationV04
Description of the change request:
In the Meeting/AttendanceRequired element, add a choice between the YesNoIndicator and a
new “Unknown” code value.
D.
Purpose of the change:
There may be instances where the “attendance required” is not known when the Meeting
Notification message is sent, so we need to indicate also if this information is unknown at
sending time.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Document1
Produced by SWIFT on 29 October 14
Page 17
Reject
Reason for rejection:
H.
Impact analysis:
One occurrence only of AttendanceRequired in seev.001 message.
I.
Proposed implementation:
Having the YesNoIndicator replaced by a choice element between the YesNOIndicator and a
single “Unknown” code value is a bit too complex for the simple requirement.
Therefore it is rather proposed to:

either set the AttendanceRequired element as optional so that when the information is not
known, the element is not present in the message. This would simplify the implementation
instead of having a choice between a yes/no indicator and a code with a single “Unknown”
value. This is by the way similar to the “Flag” elements in ISO15022 when they are often
optional.

Or to change the YesNoIndicator data type of the element by a code data type with 3 code
values: “Required”, “NotRequired” and” Unknown”
Document1
Produced by SWIFT on 29 October 14
Page 18
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG(s):
Approve
X
Comments:
Preference was for optional “attendance required” element. This clarifies that when the information is not
known, the element is not present (versus a yes/no and “unknown” value).
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 19
6 CR0409: Set Meeting Date as a DateTime Data Type
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
seev.001.001.04
C.
MeetingNotificationV04
Description of the change request:
Replace the current data type DateFormat2Choice of MeetingDetails/DateAndTime, which is a
choice between a date or date code (Unknown), by a choice between a Date alone or a DateTime
or a DateCode with code value “Unknown”.
D.
Purpose of the change:
In the current data type DateFormat2Choice, the element Date is typed by an ISODateTime data
type which is a bit confusing at first. Secondly, for meetings where only the date is known and
there is no time yet provided, having only a DateTime data type might also be confusing since
the time is mandatory.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
X
Document1
Produced by SWIFT on 29 October 14
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
Page 20
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
There is only one occurrence of MeetingDetails/DateAndTime in seev.001.
However since in the data type DateFormat2Choice, the element Date is typed by
ISODateAndTime, it should be more consistent to rename “Date” in “DateTime”. In this case we
could change globally in seev.001 the data type DateFormat2Choice by a new data type where
Date is renamed as DateTime.
There are in that case 26 remaining occurrences of elements typed by DateFormat2Choice in the
seev.001 and none in the other PV messages.
Those are the 26 remaining elements in seev.001 typed by DateFormat2Choice:
- AdditionalRightDeadline
- AdditionalRightMarketDeadline
- SecuritiesBlockingDeadline
- SecuritiesBlockingSTPDeadline
- SecuritiesBlockingMarketDeadline
- RegistrationSecuritiesDeadline
- RegistrationSecuritiesSTPDeadline
- RegistrationSecuritiesMarketDeadline
- RegistrationParticipationDeadline
- RegistrationParticipationSTPDeadline
- RegistrationParticipationMarketDeadline
- AttendanceConfirmationDeadline
- AttendanceConfirmationSTPDeadline
- AttendanceConfirmationMarketDeadline
- Deadline
- STPDeadline
- MarketDeadline
- VoteDeadline
- VoteSTPDeadline
- VoteMarketDeadline
- RevocabilityDeadline
- RevocabilitySTPDeadline
- RevocabilityMarketDeadline
- VoteWithPremiumDeadline
- VoteWithPremiumSTPDeadline
Document1
Produced by SWIFT on 29 October 14
Page 21
I.
VoteWithPremiumMarketDeadline
Proposed implementation:
a. For the MeetingDetails/DateAndTime element, create a new data type
DatFormat29Choice containing a choice between the DateOrDateTime element
typed by DateAndDateTimeChoice (to replace ISODateTime) and the existing
DateCode element with the Unknown code value.
The DateAndDateTimeChoice data type is a choice between a Date (ISODate) or a DateTime
(ISODateTime) as illustrated below:
b.
Additional Implementation proposal : For all other 26 deadline elements listed
in section H above and typed by DateFormat2Choice in the seev.001 message,
create a new data type DateFormatYYChoice identical to DateFormat2Choice
where the element Date is renamed DateTime.
As per the CR0413 approval further down, all remaining 26 deadlines will
finally be typed by the same data type DateFormat29Choice that the one created
for the point “a.” here above so that a Date alone or a DateTime can be
provided.
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Document1
Produced by SWIFT on 29 October 14
Page 22
Timing
K.
-
As requested
Final decision of the SEG(s):
Approve
X
Comments: Agreed with the “additional implementation proposal” that this change be applied to the 26
remaining elements.
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 23
7 CR0410: Add new Optional Elements
EarlyVoteWithPremiumDeadline and
EarlyIncentivePremium
A. Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
seev.001.001.04
C.
MeetingNotificationV04
Description of the change request:
Add a new optional “Vote/EarlyVoteWithPremiumDeadline” and a new optional
“Vote/EarlyIncentivePremium” elements similar to “VoteWithPremiumDeadline” and
“IncentivePremium” elements (with same data types respectively).
D.
Purpose of the change:
Each Vote With Premium deadline (STP, Market) can appear only once, however for
Bondholder meetings, Vote With Premium Deadline and Vote With Premium STP Deadline
could require another instance to reflect early deadlines with different incentive amounts.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
Document1
X
Timing
- Next yearly cycle: 2014/2015
(the change will be considered for implementation in the
Produced by SWIFT on 29 October 14
X
Page 24
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
Impact only the seev.001 message.
I.
Proposed implementation:
In the Vote component , add a new optional non repetitive element EarlyIncentivePremium
typed by IncentivePremium3 data type and add a new optional non repetitive element
EarlyVoteWithPremiumDeadline typed by DateFormat2Choice data type as illustrated below.
Document1
Produced by SWIFT on 29 October 14
Page 25
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG(s):
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 26
8 CR0411: Make the EntitlementSpecification Element
Optional
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group (Proxy Voting group).
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
seev.001.001.04
C.
MeetingNotificationV04
Description of the change request:
In seev.001, make the element EntitlementSpecification optional.
D.
Purpose of the change:
The entitlement information might not be known at the time the meeting is announced. Since
this element is mandatory, it prevents account servicers to send the message without that
information and is therefore hindering the usage of the message.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Document1
Produced by SWIFT on 29 October 14
Page 27
Reject
Reason for rejection:
H.
Impact analysis:
In seev.001 only one occurrence.
I.
Proposed implementation:
Make the element EntitlementSpecification optional as illustrated below:
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG(s):
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 28
9 CR0412: Make Resolution/Type Element Optional and
Delete Ordinary Code
A. Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
seev.001.001.04
C.
MeetingNotificationV04
Description of the change request:
Make “Resolution/Type” optional and eventually removing the code “Ordinary” as this would
be the default and the element could be used only for the Extraordinary and Special.
D.
Purpose of the change:
Resolution type is mandatory within the optional Resolution block and is a choice amongst
Extraordinary, Ordinary and Special. While there are examples of where you would want to flag
resolution differently within the same meeting, in most cases you would end up flagging all
resolutions with the same resolution type. The group agreed that it made sense for Resolution
Type to be optional and assume that by default a resolution is ordinary and to flag only when the
resolution is Special or Extraordinary.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Document1
Produced by SWIFT on 29 October 14
Page 29
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
Only one occurrence in seev.001.
I.
Proposed implementation:
Make the element Resolution/Type optional with a new ResolutionType2Code data type
containing only the Extraordinary and Special code values as illustrated below:
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG(s):
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 30
10 CR0413: Add A DateTime Data Type to
VoteMarketDeadline Element
A. Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
seev.001.001.04
MeetingNotificationV04
seev.002.001.04
MeetingCancellationV04
seev.003.001.04
MeetingEntitlementNotificationV04
seev.004.001.04
MeetingInstructionV04
seev.005.001.04
MeetingInstructionCancellationRequestV04
seev.006.001.04
MeetingInstructionStatusV04
seev.007.001.04
MeetingVoteExecutionConfirmationV04
seev.008.001.04
MeetingResultDisseminationV04
C.
Description of the change request:
For the element “Vote/VoteMarketDeadline”, make a choice between a Date alone or a
DateTime or a DateCode (“Unknown”).
D.
Purpose of the change:
In some markets, deadline time is not explicit, for example ‘close of business’ or not specified.
This field requires ISODateTime so we need to allow the presence of just a Date.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
Document1
X
Timing
- Next yearly cycle: 2014/2015
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
Produced by SWIFT on 29 October 14
X
Page 31
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
Only one occurrence of VoteMarketDeadline element in seev.001 (not in the other Proxy Voting
messages).
However, if the market deadline time for the vote is not always explicit, should’nt the
requirement apply also to other deadlines like VoteDeadline or VoteSTPDeadline or also to
RevocabilityDeadline and other deadlines eventually ?
I.
Proposed implementation:
This is a similar requirement to the CR409 (see section 6) and for which the same solution may
apply i.e. Create a new data type DatFormatXXChoice containing a choice between the Date
element typed by DateAndDateTimeChoice (to replace ISODateTime) and the existing
DateCode element with the Unknown code value.
The DateAndDateTimeChoice data type is a choice between a Date (ISODate) or a DateTime
(ISODateTime) as illustrated in section 6 paragraph I.a.
Refer to that section for an illustration of the implementation.
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG(s):
Document1
Produced by SWIFT on 29 October 14
Page 32
Approve
X
Comments: Also covered by the 26 remaining elements referenced in CR0409.
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 33
11 CR0415: Make NotifyingParty Element Optional
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group (PV Subgroup).
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
seev.001.001.04
MeetingNotificationV04
seev.003.001.04
MeetingEntitlementNotificationV04
C.
Description of the change request:
Make the NotifyingParty element optional.
D.
Purpose of the change:
This element is now redundant with the Business Application Header (BAH) element identifying
the Sender of the message (“From”) since at the time those messages were completed, the BAH
was not yet mandated for the securities messages.
The NotifyingParty element is a mandatory block and should now be changed in optional as the
only use case suggested by the group was where the Issuer or agent would want to include their
details if they sent the notification in ISO format. The sender should be assumed as the notifying
party – another party being sender on behalf of some other entity who would be flagged as the
notifying party did not seem to make sense to the Proxy Voting group.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
X
Document1
Produced by SWIFT on 29 October 14
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
Page 34
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
The NotifyingParty element seems to be fully redundant with the ISO20022 Business
Application Header “From” element which must now be used with the PV messages.
BAHMDR.pdf
ISO_20022_Business
ApplicationHeader_MUG_v1_4.pdf
So we could make the NotifyingParty optional and leave it in the messages or alternatively we
could simply remove the element from the messages as it would completely remove the
confusion about its usage.
If this removal is done for NotifyingParty in the seev.001, seev.002 and sev.003 to avoid
confusion with the application header “From” element, it should also apply to the elements
InstructingParty in the seev.004 (see CR 0434 further down) , to RequestingParty in the
seev.005 and to ReportingParty in the seev.006, seev.007 and seev.008 (see CR 0435 further
down) that should be removed too.
I.
Proposed implementation:
To fully remove the ambiguity with the application header “From” element, it is proposed to
remove the redundant elements as follows:
-
In seev.001, 002, 003 - remove the NotifyingParty element .
-
In seev.004, remove the InstructingParty element, (CR 0434)
-
In seev.005, remove the RequestingParty element,
-
In seev.006, 007, 008, remove the ReportingParty element (CR 0435)
Document1
Produced by SWIFT on 29 October 14
Page 35
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG:
Approve
X
Comments: Approved, These are required elements in the BAH and as such no longer needed. Also
recommend they be removed entirely versus retaining as optional
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 36
12
CR0427: Add new BondHolderMeeting as Meeting Type
A.
Origin of the request:
A.1 Submitter: SWIFT.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors:
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.001.001.04
MeetingNotificationV04
seev.002.001.04
MeetingCancellationV04
seev.003.001.04
MeetingEntitlementNotificationV04
seev.004.001.04
MeetingInstructionV04
seev.005.001.04
MeetingInstructionCancellationRequestV04
seev.006.001.04
MeetingInstructionStatusV04
seev.007.001.04
MeetingVoteExecutionConfirmationV04
seev.008.001.04
MeetingResultDisseminationV04
C.
Description of the change request:
In element “Meeting/Type” or “MeetingReference/Type” in the above messages, add the new
BMET - Bond Holder Meeting - with the definition”Physical meeting of bond holders” as
created in ISO 15022 MT Corporate Actions (CA) messages in SR2014.
D.
Purpose of the change:
Keep the alignment of the ISO 20022 Proxy Voting solution with the ISO15022 MT CA
messages.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
Document1
X
Timing
- Next yearly cycle: 2014/2015
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
Produced by SWIFT on 29 October 14
X
Page 37
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
One occurrence of Meeting/Type or MeetingReference/Type per message.
I.
Proposed implementation:
Add a new BondHolderMeeting (BMET) code value to MeetingTypeCode data type and create a
new derived MeetingType3Code data type containing the XMET, GMET, MIXD, SPCL and the
new BMET code values.
Replace in all occurrence of Meeting/Type or MeetingReference/Type the data type
MeetingType2Code by MeetingType3Code.
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG(s):
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 38
13 CR0428: Add Start or EndOfDay to EntitlementFixingDate
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.001.001.04
MeetingNotificationV04
seev.003.001.04
MeetingEntitlementNotificationV04
C.
Description of the change request:
A field indicating whether the record date is established at the start or end of the record date
should be added to the EntitlementFixingDate.
Although the EntitlementFixingDate element is also present in the seev.003, it might not be
absolutely necessary to repeat this information in the MeetingEntitlementNotification message.
D.
Purpose of the change:
Record date may be established at the start or end of the record date depending on jurisdiction,
therefore it is important to indicate this into the message element EntitlementFixingDate.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
X
Document1
Produced by SWIFT on 29 October 14
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
Page 39
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
One occurrence of EntitlementFixingDate in each seev.001 and 003 message.
I.
Proposed implementation:
In seev.001, replace the data type of EntitlementFixingDate by a new component having an
optional DateMode element typed by a new code containing the code value “End of Day” and
“Beginnning of Day” and having a Date element as previously defined. See illustration below.
If the Date mode element is not necessary in the seev.003, do not implement it in that message.
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG(s):
Approve
X
Comments: Approved, and a discussion occurred re: adding “time”, and it was decided that time was not
necessary. This change also applies to seev.001 only and not seev.003 in order to mitigate risk of the
data elements having different values in different messages.
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 40
14 CR0429: Add Optional Entitlement to Repetitive
Resolution
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.001.001.04
C.
MeetingNotificationV04
Description of the change request:
Add an optional Entitlement element with a choice between EntitlementRatio and Entitlement
Description in the repetitive Resolution element.
D.
Purpose of the change:
The choice needs to be expanded to add Entitlement Specification at the Resolution Level. In
Russia, there may be different entitlements for different resolutions. Cumulative voting applies
in some markets.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
Document1
Produced by SWIFT on 29 October 14
Page 41
G.
SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
Only 1 occurrence in seev.001.
I.
Proposed implementation:
Add an optional Entitlement element as defined in the EntitlementSpecification sequence to the
optional and repetitive Resolution sequence as illustrate below.
Document1
Produced by SWIFT on 29 October 14
Page 42
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG(s):
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 43
15 CR0430: Add new Deadline in
PowerOfAttorneyRequirements
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.001.001.04
C.
MeetingNotificationV04
Description of the change request:
In the element PowerOfAttorneyRequirements, add a new optional
DocumentSubmissionDeadline element with a choice between Date and DateCode as datatype.
D.
Purpose of the change:
A deadline for submission is required to know when the documents must be provided.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
Document1
X
Timing
- Next yearly cycle: 2014/2015
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
Produced by SWIFT on 29 October 14
X
Page 44
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
One occurrence in seev.001.
I.
Proposed implementation:
In the seev.001 message, in the PowerOfAttorneyRequirements sequence, add a new optional
non repetitive element DocumentSubmissionDeadline typed by DateFormat29Choice data type
as illustrated below:
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Document1
Produced by SWIFT on 29 October 14
Page 45
Timing
K.
-
As requested
Final decision of the SEG(s):
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 46
16 CR0431: Add New Optional PreviousInstructionInvalidity
Flag
A.
Origin of the request:
A.1 Submitter: SWIFT.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors:
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.001.001.04
MeetingNotificationV04
seev.006.001.04
MeetingInstructionStatusV04
C.
Description of the change request:
Add a new optional “PreviousInstructionInvalidity “ indicator/flag in the seev.001 message to
indicate if a previously received instruction is considered invalid after an extension of the
instruction deadline.
In the seev.006 MeetingInstructionStatus message, amend the definition of the
”CancelledBySubcustodian” cancellation reason code as proposed in the CR III.9 illustrated
below.
D.
Purpose of the change:
This Change Request (CR) is an alignment with the change CR III.9 from SR2011 on the ISO
15022 Corporate Actions MT messages in which the CA MWG has requested to implement this
element in the proxy voting solution as well.
Business case: On meetings, the Issuer may decide to extend the deadline or to add further
meeting resolutions. When the extension or additional resolutions are announced, instructions
may have already been sent, therefore we need a way to know if those instructions are still valid
or if new instructions are required.
Appendix - SR2011 – CR III.9
MT 564 – Add Previous Instructions Validity Flag for Extension of Deadline
Origin of request
Requesting Country: Euroclear Bank and Clearstream Banking
Requesting Group: ISMAG
Urgency of the request
ISMAG
Document1
Produced by SWIFT on 29 October 14
Page 47
Commitment to implement the change
Applicable to all BIDS TEND EXOF MEET XMET CONS on debt instruments.
Volumes for Offers: BIDS/TEND/EXOF
Total number of offers announced since Jan, 2010 = around 1,900
About 20% of total offers are extended => around 470 events impacted since Jan 2010
Amongst the offers extended, about 95% of the time the instructions remain valid.
For the other 5%, the instructions are cancelled and the clients needs to reinstruct.
Volumes for MEET/XMET/CONS:
Total number of meetings and consents announced since Jan, 2010 = around 5,000
About 25% of the consents have an extension of deadline => around 1,250 events impacted since
Jan 2010
Amongst the consents extended, about 95% of the time the instructions remain valid.
For the other 5%, the instructions are cancelled and the clients needs to reinstruct.
Nature of Change
Add a new :17B: flag in sequence D of the MT 564 to indicate if the previously received
instruction remains valid after the extension of the deadline.
Business context
Indicator
When there is a change to the event
(eg. deadline extension or resolutions
to vote on), the agent does not specify
if the instructions already in place
remain valid.
Definition
Yes or No
Defines if the previously sent
instructions remain valid after the
deadline extension is announced.
Business context
On unpredictable offers or meetings, the Issuer or Offeror may decide to extend the deadline.
When the extension is announced, instructions have usually already been sent, we need to know if
those instructions are still valid or if new instructions are required.
Other type of changes to the event (eg; meeting resolutions added) may imply that we need to
know if the sent instructions remain valid;
Message Type(s) Impacted
MT564, MT 567
Examples
Example: purchase offer on TELECA AB
Isin: SE0000366254
Ev 380774
-----------------------------------------------------------------NEW INFORMATION DATED 14/01/09: RESULTS OF OFFER+EXTENDED DEADLINE
-----------------------------------------------------------------CAYTEL 1 LP HOLDS APPROXIMATELY 88.1 PCT OF THE SHARES AND 88.7
PCT OF THE VOTES IN TELECA AB.
CAYTEL HAS DECIDED TO EXTEND THE ACCEPTANCE PERIOD UP UNTIL
Document1
Produced by SWIFT on 29 October 14
Page 48
16/01/09.
CAYTEL 1 LP. RESERVES THE RIGHT TO PROLONG THE ACCEPTANCE PERIOD
Example: purchase offer on GENENTECH INC -ORD SHS
Isin: US3687104063
Event 1001419
-----------------------------------------------------------------AMENDMENT OF INFORMATION DATED 13/03/09:
-----------------------------------------------------------------THE OFFER HAS BEEN EXTENTED.
THE TENDER PRICE HAS BEEN AMENDED.
Example: HOLDERS' MEETING
EXTRAORDINARY ADJOURNED MEETING: results
MAIN SECURITY: 534261 ARRAN RESIDENTIAL M VAR
EUROCLEAR HAS BEEN ADVISED THAT THE MEETING
HAS BEEN ADJOURNED DUE TO A LACK OF QUORUM
.
ANOTHER MEETING WILL BE HELD ON 21/12/09 AT 15:00 (LONDON TIME)
.
SAME LOCATION
.
PREVIOUS INSTRUCTIONS REMAIN VALID
POSITIONS WILL REMAIN BLOCKED
Example: HOLDERS' MEETING
EVENT: 3063658 230 HOLDERS' MEETING
MODEL:
ISO: XMET
EXTRAORDINARY COMBINED MEETING
MAIN SECURITY: 207287 AGEAS (B) NEW SHS -BEL 20
-------------------------------------------------------------------- PAGE 01 -
NEW INFORMATION DATED 07/04/10
-----------------------------PLEASE BE ADVISED THAT THE MEETING ORIGINALLY SCHEDULDED THE
12/04/10 IN BRUSSELS IS POSTPONED TO THE 28/04/10
.
MOREOVER, THIS MEETING IS AN EXTRAORDINARY COMBINED MEETING
.
THE INSTRUCTIONS RECEIVED FOR THE FIRST MEETING WILL THEREFORE NOT
BE TAKEN INTO ACCOUNT
.
THE MEETING AGENDA IS AVAILABLE AT WWW.EUROCLEAR.COM
THE PROXY FORM WILL BE MADE AVAILABLE AS SOON AS IT IS RECEIVED
.
Document1
Produced by SWIFT on 29 October 14
Page 49
TO ACCESS THESE DOCUMENTS, SELECT THE 'CORPORATE ACTIONS ON-LINE'
.
Standards Illustration
MT 564 Field Specifications
16.1.1 Format
Option F
:4!c/[8c]/4!c
(Qualifier)(Data Source Scheme)(Indicator)
16.1.2 Presence
Mandatory in optional sequence E
16.1.3 Qualifier
(Error code(s): T89)
Order
M/O
Qualifier
R/N
CR
Options
Qualifier Description
1
M
CAOP
N
F
Corporate Action Option Code Indicator
2
O
DISF
N
F
Disposition of Fractions Indicator
3
O
OFFE
R
F
Offer Type Indicator
4
O
OPTF
R
F
Option Features Indicator
5
O
RHDI
N
F
Intermediate Securities Distribution Type
Indicator
6
O
OSTA
N
F
Option Status
7
O
CETI
R
F
Certification Type Indicator
C12
16.1.4 Codes
If Qualifier is OPTF and Data Source Scheme is not present, Indicator must contain one of the following
codes (Error code(s): K22):
CAOS
Corporate Action
Option Applicability
The option applicability is not subject to the account owner decision
but depends on the terms defined by the issuer, for example in the
case of Equity Linked Notes or warrants.
COND
Conditional
Feature whereby the holder can elect to place a condition on the
acceptance of the option.
MAXC
Maximum Cash
Maximum cash option, may be subject to scaling, as such you may
receive a combination of cash and securities outturn.
Document1
Produced by SWIFT on 29 October 14
Page 50
MAXS
Maximum
Securities
Maximum stock option, may be subject to scaling, as such you may
receive a combination of securities and cash outturn.
NOSE
No Service Offered
Indicator
Feature whereby the holder must elect directly to the issuer's agent.
OPLF
Odd Lot Preference Tender or Exchange with the Odd Lot Preference.
PROR
Pro Ration
Feature whereby the option can be subject to pro ration in case, for
example, of over-subscription.
QOVE
Over and Above
Feature whereby the holder can elect a quantity to receive over and
above normal ensured entitlement.
QREC
Quantity to Receive Feature whereby the holder can elect a quantity to receive.
VVPR
Reduced
Withholding Tax
PINS
Previous
Instruction
Invalidity
Reduced withholding tax rate applies to the option.
Indicates the previously sent instructions becomes invalid.
This is only applicable after a market deadline extension.
MT 567: (13) Field 24B: Reason Code
16.1.5 Format
Option B
:4!c/[8c]/4!c
(Qualifier)(Data Source Scheme)(Reason
Code)
16.1.6 Presence
Mandatory in optional subsequence A2a
16.1.7 Qualifier
(Error code(s): T89)
Order
1
Document1
M/O
Qualifier
R/N
CR
Options
Qualifier Description
M
PEND
N
C1
B
Pending Reason
or
REJT
N
C1
B
Rejection Reason
or
CAND
N
C1
B
Cancellation Reason
or
CANP
N
C1
B
Cancellation Pending Reason
Produced by SWIFT on 29 October 14
Page 51
or
PACK
N
C1
B
Acknowledged/Accepted Reason
16.1.8 Definition
This qualified generic field specifies:
CAND
Cancellation
Reason
Specifies the reason why the instruction is cancelled.
16.1.9 Codes
If Qualifier is CAND and Data Source Scheme is not present, Reason Code must contain one of the
following codes (Error code(s): K24):
CANI
Cancelled By
Yourselves
Instruction has been cancelled as per your request.
CANO
Cancelled by
Another Party
Instruction has been cancelled by another party than the instructing
party, for example market infrastructure such as a Stock Exchange.
CANS
Cancelled By
System
Instruction has been cancelled by the system.
CSUB
Cancelled By
Subcustodian
Instruction has been cancelled by the agent due to an event deadline
extension.
NARR
Narrative Reason
See narrative field for reason.
ISO 20022 Messages Impacted
seev.041.001.01 (Corporate Action Notification)
seev.045.001.01 (Corporate Action Movement Preliminary Advice)
seev.044.001.01 (Corporate Action Instruction Status Advice)
seev.041.001.01 (Corporate Action Instruction Cancellation Request Status Advice)
Message design impact if the change is accepted
In the seev.041.001.01 message, the OptionFeatures2Code in the
CorporateActionOptionDetails/OptionFeatures sequence must be updated to contain a new PINS
code, (PreviousInstructionInvalidity) Code, with the same definition as in ISO 15022.
In the seev.045.01.01 message, the OptionFeatures2Code in the
CorporateActionMovementDetails/OptionFeatures sequence must be updated to contain a new
PINS code, (PreviousInstructionInvalidity) Code, with the same definition as in ISO 15022.
In the seev.044 and seev.041 message, the CSUB (CancelledByAgent) code definition in the Data
Type CancelledStatusReason6Code in the respective sequences
InstructionProcessingStatus/Cancelled/Reason/reasonCode and
InstructionCancellationRequestStatus/CancellationCompleted/Reason/ReasonCode must be
updated as illustrated in ISO15022CancelledStatusReason6Code
Document1
Produced by SWIFT on 29 October 14
Page 52
Discussion: The group agrees with the following:
1. to create rather a new “PreviousInstructionInvalidityIndicator” in 22F::OPTF in sequence E
instead of a flag in sequence D so as to be closer to the response deadlines and as it could also
potentially apply to one or more options.
2. to update the definition of the code CSUB in 24B::CAND in the MT567 sequence A2a as
follows: “Instruction has been cancelled by the agent for example, due to an event deadline
extension.”
The group suggests to add this functionality to the ISO 20022Proxy Voting and Issuer Agent
messages and request to submit this to the ISO 20022 Securities SEG.
Decision: Accepted with Alternate solution
Impacted
Messages
MT 564
MT 567
E.
Volume
Global
or
Local
impact
45,546,433
2,446,542 Global
Urgency
High
Back Office
impact
Optional,
Low impact
Impact on
standard
Discussion
New indicator
code and
update code
definition
Green
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Document1
Produced by SWIFT on 29 October 14
Page 53
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
One change occurrence in seev.001 and one in seev.003.
I.
Proposed implementation:
a. In the seev.001, in the Vote sequence, add a new optional non repetitive element named
PreviousInstructionInvalidityIndicator typed by a YesNoIndicator data type with the
following definition: “Indicates whether the previously sent instructions becomes invalid
after a market deadline extension.”
b. For the amendment of the definition of the cancellation code CSUB
(CancelledBySubcustodian), it appears that the seev.006 MeetingInstructionStatus message
does not contain any reason codes for a “Cancelled” (cancel complete) status code. Therefore
it is propose to add the new code value CSUB (CancelledBySubcustodian) with the amended
definition (as in ISO15022) in the data type Status3Code which is the data type of the
elements:
Document1
Produced by SWIFT on 29 October 14
Page 54
J.

InstructionTypeStatus/InstructionStatus/GlobalInstructionStatus/ProcessingStatus/Sta
tus and

InstructionTypeStatus/InstructionStatus/DetailedInstructionStatus/InstructionStatus/P
rocessingStatus/Status as illustrated below:
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG:
Approve
X
Comments: Approved, will be a helpful addition especially for markets like Italy where there are often
questions as to whether votes will need to be reinstructed or not.
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 55
17 CR0432: Delete MessageCancellation Element
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.002.001.04
C.
MeetingCancellationV04
Description of the change request:
Remove the MessageCancellation component from the message.
D.
Purpose of the change:
This is to align with the SMPG market practice implemented after the Corporate Actions XML
messages were created. The SMPG Market Practice is such that if the meeting is valid, a
MeetingCancellation message should not be sent. The cancellation message in only used to
withdraw/cancel events and not messages. The meeting notification messages are always
replaced and not cancelled. Therefore any reference to a message to be cancelled in that message
is useless.
Cancelling an event because the event was erroneously sent to a account owner can be done by
using the “Processing error” (PROC) code. On the other hand, if the issuer cancels the meeting a
Withdrawn (WITH) code is used.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
Document1
Produced by SWIFT on 29 October 14
Page 56
G.
SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
One occurrence in seev.002 only.
I.
Proposed implementation:
Remove the optional element MessageCancelletion as illustrated below.
Also, remove the Cancellation2Guideline,
MeetingIdentificationAndPreviousReference1Guideline and
MeetingIdentificationAndPreviousReference2Guideline rules which are no longer valid.
Document1
Produced by SWIFT on 29 October 14
Page 57
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG:
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 58
18 CR0433: Update Cancellation Guideline
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.005.001.04
C.
MeetingInstructionCancellationRequestV04
Description of the change request:
Update the Cancellation3Guideline in the message to specify that any information present in the
optional components (MeetingReference, SecurityIdentification, InstructedPosition) must be
identical to the information being present in the MeetingInstruction message being cancelled.
D.
Purpose of the change:
So that the rule is consistent with the existing market practice in ISO15022 Corporate action
messages.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
X
Document1
Produced by SWIFT on 29 October 14
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
Page 59
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
One occurrence only in seev.005.
I.
Proposed implementation:
Update the Cancellation3Guideline rule as follows:
“It is recommended to cancel an instruction message by using PreviousReference only. It is
recommended to avoid the repetition of optional building blocks, unless otherwise specified by
market practise rules and or legislation. If any information is present in the optional building
blocks, it must be identical to the information being present into the instruction message being
cancelled.”
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG(s):
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 60
19 CR0434: Make InstructingParty Optional
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.004.001.04
C.
MeetingInstructionV04
Description of the change request:
Make InstructingParty optional.
D.
Purpose of the change:
Similarly to the NotifyingParty in the MeetingNotification message, the InstructingParty element
in the MeetingInstruction message is redundant with the sender information (the
“From”component) contained in the IS0 20022 Business Application Header (BAH) since at the
time those messages were completed, the BAH was not yet mandated for the securities
messages.
Therefore this component should now be made optional and could be used eventually in case the
sender would not be the actual entity instructing on the meeting.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
Document1
X
Timing
- Next yearly cycle: 2014/2015
(the change will be considered for implementation in the
Produced by SWIFT on 29 October 14
X
Page 61
yearly maintenance cycle which starts in 2013 and
completes with the publication of new message versions in
the spring of 2014)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
One occurrence only in seev.004.
I.
Proposed implementation:
This element Instructing Party should either be set as optional or rather removed as it is fully
redundant with the ISO 20022 Business Application Header “From” information.
As in the CR 0415, we recommend to remove this element completely as illustrated below:
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Document1
Produced by SWIFT on 29 October 14
Page 62
Timing
K.
-
As requested
Final decision of the SEG:
Approve
X
Comments: Approved, These are required elements in the BAH and as such no longer needed. Also
recommend they be removed entirely versus retaining as optional.
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 63
20 CR0435: Make ReportingParty Optional
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.006.001.04
MeetingInstructionStatusV04
seev.007.001.04
MeetingVoteExecutionConfirmationV04
seev.008.001.04
MeetingResultDisseminationV04
C.
Description of the change request:
Make the ReportingParty element in the above 3 messages optional.
D.
Purpose of the change:
Similarly to the NotifyingParty in the MeetingNotification message, this ReportingParty element
is redundant with the Business Application Header (BAH) element identifying the Sender of the
message (“From” element) since at the time those messages were completed, the BAH was not
yet mandated for the securities messages.
Therefore this component should now be made optional and could be used eventually in case the
sender would not be the actual entity reporting on the meeting.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
Document1
Produced by SWIFT on 29 October 14
Page 64
G.
SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
One occurrence in each of the seev.006, 007, 008 messages.
I.
Proposed implementation:
This element ReportingParty should either be set as optional or rather removed as it is fully
redundant with the ISO 20022 Business Application Header “From” information.
As in the CR 0415, we recommend to remove this element completely as illustrated below:
Document1
Produced by SWIFT on 29 October 14
Page 65
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG(s):
Approve
X
Comments: Approved, These are required elements in the BAH and as such no longer needed. Also
recommend they be removed entirely versus retaining as optional.
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 66
21 CR0436: Update ReceivedByIssuerOrRegistrar Code Value
Definition
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.006.001.04
C.
MeetingInstructionStatusV04
Description of the change request:
Update the definition of the code value ReceivedByIssuerOrRegistrar (RCIS) in the component
”InstructionTypeStatus/InstructionStatus/GlobalInstructionStatus/ProcessingStatus/Status” so as
to say that the instruction has been “received” by the issuer instead of being “confirmed”.
D.
Purpose of the change:
The actual action pre-meeting would be confirmation that the instruction was “received” by the
issuer, not confirmed
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
X
Document1
Produced by SWIFT on 29 October 14
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2013 and
completes with the publication of new message versions in
the spring of 2014)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
Page 67
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
There are 2 occurrences of ReceivedByIssuerOrRegistrar (RCIS) in the seev.006, one is in the
Status3Code data type typing element
InstructionTypeStatus/InstructionStatus/GlobalInstructionStatus/ProcessingStatus/Status and the
other one is in the CancelletionStatus3Code data type typing element
InstructionTypeStatus/CancellationStatus/ProcessingStatus/Status.
I.
Proposed implementation:
Amend the definitions as follows:
RCIS in Status3Code: “Instruction has been confirmed received by Issuer.”
RCIS in CancellationStatus3Code: “Cancellation instruction / request has been confirmed received
by Issuer or Registrar.”
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG:
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 68
22 CR0437: Make VotePerResolution Element Optional
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.007.001.04
C.
MeetingVoteExecutionConfirmationV04
Description of the change request:
Make the element VoteInstruction/VotePerResolution optional (remaining repetitive).
D.
Purpose of the change:
The VoteInstructions/StandingInstruction flag element is distinct from the
VoteInstruction/VotePerResolution component, however, both are mandatory meaning that
VotePerResolution must always be present even if standing instructions were applied. This
seems inconsistent to the group and therefore agree that VotePerResolution should be optional
for cases where the Standing Instruction flag is “yes”.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
Document1
Produced by SWIFT on 29 October 14
Page 69
G.
SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
Only one occurrence in seev.007.
I.
Proposed implementation:
Make the element VoteInstruction/VotePerResolution element optional as illustrated below:
J.
Proposed timing:
Document1
Produced by SWIFT on 29 October 14
Page 70
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG:
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 71
23 CR0438: Add New Withdrawn Code in VotePerResolution
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.007.001.04
MeetingVoteExecutionConfirmationV04
seev.008.001.04
MeetingResultDisseminationV04
C.
Description of the change request:
In the seev.007 message, add an optional “Withdrawn” indicator code into the component
VoteInstructions/VotePerResolution.
In the seev.008 message, add an optional “Withdrawn” indicator code into the component
VoteResult.
D.
Purpose of the change:
The Vote Instructions & VoteResult components do not cater for proposal items that were
withdrawn at the meeting. Therefore another code is required within VotePerResolution
component to reflect withdrawn proposals.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
Document1
Produced by SWIFT on 29 October 14
Page 72
G.
SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
Impacts only seev.007 and 008.
I.
Proposed implementation:
1) In seev.007 (MeetingVoteExecutionConfirmation), add a new optional element
“Withdrawn” element with a YesNoIndicator data type in the repetitive
VoteInstructions/VotePerResolution sequence as illustrated below and defined as
“Resolution withdrawn at the meeting”.
Document1
Produced by SWIFT on 29 October 14
Page 73
2) In seev.008 (MeetingResultsDissemination), replace the mandatory element “Accepted”
typed by a “YesNoIndicator” by a mandatory element “ResolutionStatus” typed by a
ResolutionStatusCode with code values “Accepted”, “Rejected” and “Withdrawn” as
illustrated below:
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG:
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 74
24 CR0439: Add New “Say on pay” Vote Options
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.004.001.04
MeetingInstructionV04
seev.007.001.04
MeetingVoteExecutionConfirmationV04
seev.008.001.04
MeetingResultDisseminationV04
C.
Description of the change request:
Add new vote options ‘1 Year’, ‘2 Year’ or ‘3 Year’ in the above messages besides the existing
“For”, “Abstain”, Against”,.. vote options.
D.
Purpose of the change:
The messages do not cater for ‘Say on Pay’ proposals that are applicable to US meetings. In
these cases the relevant ‘Say on Pay’ proposal is not voted on the basis of FOR, AGAINST or
ABSTAIN, but as the option of ‘1 Year’, ‘2 Year’ or ‘3 Year’. It would appear as additional
codes in respectively the VoteInstruction / VotePerResolution / VoteResult components.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
X
Document1
Produced by SWIFT on 29 October 14
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
Page 75
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
In the seev.004 (MeetingInstruction), this impacts the following elements:
a) Instruction/Proxy/VoteInstructionForAgendaResolution/VoteInstruction
b) Instruction/Proxy/VoteInstructionForAgendaResolution/GlobalVoteInstruction/VoteOption
c) Instruction/VoteDetails/VoteInstructionForAgendaResolution/VoteInstruction
d) Instruction/VoteDetails/VoteInstructionForAgendaResolution/GlobalVoteInstruction/VoteO
ption
e) Instruction/VoteDetails/VoteInstructionForMeetingResolution/VoteIndication
In the seev.007 (MeetingVoteExecutionConfirmation), this impacts the following elements:
a) VoteInstructions/VotePerResolution
In the seev.008 (MeetingResultDissemination), this impacts the following elements:
a) VoteResult
I.
Proposed implementation:
In the seev.004 (MeetingInstruction),:
a) In the element Instruction/Proxy/VoteInstructionForAgendaResolution/VoteInstruction, add
3 new optional non repetitive elements “OneYear”, “TwoYears”, ThreeYears” typed by
“Number” data type
b) In the element
Instruction/Proxy/VoteInstructionForAgendaResolution/GlobalVoteInstruction/VoteOption,
add the 3 new code values ONEY (One Year) , TWOY (Two Years), THRY (Three Years)
in the data type VoteInstruction2Code
Document1
Produced by SWIFT on 29 October 14
Page 76
c) In the element
Instruction/VoteDetails/VoteInstructionForAgendaResolution/VoteInstruction, apply same
solution as in a) above.
d) In the element
Instruction/VoteDetails/VoteInstructionForAgendaResolution/GlobalVoteInstruction/VoteO
ption, apply same solution as b) above
e) In the element
Instruction/VoteDetails/VoteInstructionForMeetingResolution/VoteIndication, add the 3 new
code values ONEY (One Year) , TWOY (Two Years), THRY (Three Years) in the data type
VoteInstructionAtMeeting1Code similarly to solution b) above.
In the seev.007 (MeetingVoteExecutionConfirmation), In the element
VoteInstructions/VotePerResolution , apply the same solution as in a) above.
In the seev.008 (MeetingResultDissemination), in the element VoteResult, apply the same
solution as in a) above.
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG:
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 77
25 CR0440: Change Data Type of Element
TotalNumberOfSecuritiesOutstanding
A.
Origin of the request:
A.1 Submitter: SMPG CA Working Group.
A.2 Contact person: Jacques Littré, jacques.littre@swift.com, +3226554335
A.3 Sponsors: SMPG CA WG NMPGs members
B.
Related messages:
The list of ISO 20022 messages which would be impacted by the change, including the Message
IDs as shown in the Catalogue of ISO 20022 messages.
seev.008.001.04
C.
MeetingResultDisseminationV04
Description of the change request:
Change the data type ActiveCurrencyAndAmount of the element
Participation/TotalNumberOfSecuritiesOutstanding by UnitOrFaceAmount1Choice data type.
D.
Purpose of the change:
In the Participation component, the element TotalNumberOfSecuritiesOutstanding can only be
expressed as Active Currency and Amount. Given that a large proportion of results will apply to
shareholder meetings, the group agreed that it should be possible to also have the option to
express this simply in Units or in FaceAmount.
E.
Urgency of the request:
Maintenance cycle 2014/2015
F.
Business examples:
N/A
G.
SEG recommendation:
Consider
X
Document1
Produced by SWIFT on 29 October 14
Timing
Page 78
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2013 and
completes with the publication of new message versions in
the spring of 2014)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
The TotalNumberOfSecuritiesOutstanding element is present with the same data type once in the
seev.008 message but also in the seev.001 messages in the sequence Meeting. Therefore the
element data type must be replaced in both messages and not only in the seev.008.
I.
Proposed implementation:

In the seev.001, in the element Meeting/TotalNumberOfSecuritiesOutstanding, replace the
ActiveCurrencAndAmount data type by UnitOrFaceAmount1Choice as illustrated below.

In the seev.008, in the element Participation/TotalNumberOfSecuritiesOutstanding, replace
the ActiveCurrencyAndAmount data type by UnitOrFaceAmount1Choice.
J.
Proposed timing:
Document1
Produced by SWIFT on 29 October 14
Page 79
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG:
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 80
26 CR0445: Change Date Element Name by DateTime in
ISODateTime elements.
A.
Origin of the request:
A.1 Submitter: DTCC (USA)
A.2 Contact person: L.A. de Heering ldeheering1@dtcc.com +1 (646) 344-0737
A.3 Sponsors: ISITC Corporate Actions Working Group
B.
Related messages:
seev.001.001.04
C.
Description of the change request:
Update data type for the dates in Meeting Notification. Currently the element is called “Date”,
has a tag <Dt> and data type of ISODateTime, and accepts date time value “2007-0428T11:00:00”. This is contrary to general practice in other 20022 message, where <Dt> is
ISODate and <DtTm> is ISODateTime.
D.
Purpose of the change:
This request is to correct and align this element with the common practice. Date tag <Dt> in all
other messages accepts ISODate.
E.
Urgency of the request:
DTCC would like to request this for SR 2015 release.
F.
Business example:
<MtgNtfctn>
<Id>
<Id>ABC001</Id>
<CreDtTm>2007-04-03T09:00:00</CreDtTm>
</Id>
<NtfctnSts>
<Sts>ECON</Sts>
</NtfctnSts>
<Mtg>
<MtgId>AGM4528</MtgId>
<IssrMtgId>LS001</IssrMtgId>
<Tp>GMET</Tp>
<Clssfctn>
<Cd>AMET</Cd>
</Clssfctn>
<AttndncReqrd>false</AttndncReqrd>
</Mtg>
<MtgDtls>
<DtAndTm>
<Dt>2007-04-28T11:00:00</Dt>
</DtAndTm>
<QrmReqrd>false</QrmReqrd>
<Lctn>
<Adr>
Document1
Produced by SWIFT on 29 October 14
Page 81
<AdrLine>Great Hall at Kensington Town Hall</AdrLine>
<StrtNm>Hornton Street</StrtNm>
<PstCd>W87NX</PstCd>
<TwnNm>London</TwnNm>
<Ctry>GB</Ctry>
</Adr>
</Lctn>
<Lctn>
<Adr>
<AdrLine>Globe Arena</AdrLine>
<TwnNm>Stockholm</TwnNm>
<Ctry>SE</Ctry>
</Adr>
</Lctn>
</MtgDtls>
<NtifngPty>
<BICOrBEI>LOCAGB2L</BICOrBEI>
</NtifngPty>
<Issr>
<Id>
<NmAndAdr>
<Nm>Big Corp PLC</Nm>
<Adr>
<AdrLine>7th floor</AdrLine>
<AdrLine>The Corn Exchange</AdrLine>
<StrtNm>Mark Lane</StrtNm>
<BldgNb>55</BldgNb>
<PstCd>EC3R7NE</PstCd>
<TwnNm>London</TwnNm>
<Ctry>GB</Ctry>
</Adr>
</NmAndAdr>
</Id>
</Issr>
<IssrAgt>
<Id>
<BICOrBEI>AGNTGB2L</BICOrBEI>
</Id>
</IssrAgt>
<Scty>
<Id>
<Id>
<ISIN>GB4444A53L22</ISIN>
</Id>
</Id>
</Scty>
<EntitlmntSpcfctn>
<EntitlmntFxgDt>
<DtCd>UKWN</DtCd>
</EntitlmntFxgDt>
</EntitlmntSpcfctn>
</MtgNtfctn>
G.
SEG recommendation:
Consider
X
Document1
Produced by SWIFT on 29 October 14
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
Page 82
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
This requested change is already fully covered in the CR 0409 outlined in section 6 above in this
document.
I.
Proposed implementation:
Follow the proposed implementation detailed in CR 0409 which fully solve this CR.
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG:
.
Approve
X
Comments:
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 83
27 CR0446: Harmonize SecurityIdentification DT with Latest
Used in Securitities Messages
A.
Origin of the request:
A.1 Submitter: DTCC (USA)
A.2 Contact person: L.A. de Heering ldeheering1@dtcc.com +1 (646) 344-0737
A.3 Sponsors: ISITC Corporate Actions Working Group
B.
Related messages:
seev.001.001.04
C.
Description of the change request:
Update Security/Identification data type to SecurityIdentification15.
D.
Purpose of the change:
This request is to correct and align this element with the rest of the 20022 messages that use new
security identification structure since SR 2012.
E.
Urgency of the request:
DTCC would like to request this for SR 2015 release.
F.
Business examples:
Old seev.001.001.04:
Elements
Sequence /
Choice
Choice
Sequence
Sequence
Sequence
Choice
Choice
Identification
ISIN
Other Identification
Identification
Identification Source
Domestic
Algorithm : Country
Proprietary
Sequence
Document1
Type / Code
Mult.
XML Tag
SecurityIdentification11Choice
ISINIdentifier
AlternateIdentification1
Max35Text
IdentificationSource1Choice
CountryCode
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
<Id>
<ISIN>
<OthrId>
<Id>
<IdSrc>
<Dmst>
Max35Text
[1..1]
<Prtry>
Produced by SWIFT on 29 October 14
Page 84
New seev.001.001.05:
Sequence /
Choice
Financial Instrument Identification Sequence
ISIN
Sequence
Other Identification
Sequence
Identification
Sequence
Suffix
Sequence
Type
Choice
Code
Choice
Type / Code
Mult.
XML Tag
SecurityIdentification15
ISINIdentifier
OtherIdentification2
RestrictedFINXMax31Text
Max16Text
IdentificationSource4Choice
ExternalFinancialInstrumentIdentificationT
ype1Code
RestrictedFINExact2Text
[1..1]
[0..1]
[0..*]
[1..1]
[0..1]
[1..1]
[1..1]
<FinInstrmId>
<ISIN>
<OthrId>
<Id>
<Sfx>
<Tp>
<Cd>
[1..1]
<Prtry>
Elements
Proprietary
G.
Sequence
SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2014/2015
X
(the change will be considered for implementation in the
yearly maintenance cycle which starts in 2014 and
completes with the publication of new message versions in
the spring of 2015)
- At the occasion of the next maintenance of the
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
right – will be pending until more critical change requests
are received for the messages)
- Urgent unscheduled
(the change justifies an urgent implementation outside of
the normal yearly cycle)
- Other timing:
Comments:
Reject
Reason for rejection:
H.
Impact analysis:
The element Security/Identification or SecurityIdentification typed by the data type
SecurityIdentification11 are present once in every of the 8 seev proxy messages, therefore the
change must apply to all those 8 occurrences in all seev.001 to 008 messages.
I.
Proposed implementation:
It is proposed to replace the data type of the Security/Identification and SecurityIdentification
elements by the SecurityIdentification14 component which is the equivalent of the
Document1
Produced by SWIFT on 29 October 14
Page 85
SecurityIdentification15 component for the pure ISO20022 message (whilst
SecurityIdentification15 is used in the subsets of the ISO20022 messages which are fully aligned
with ISO 15022.
The SecurityIdentification14 component is less restrictive on the fields types than the
SecurityIdentification15 component and it therefore should accept all entries that fits into
SecurityIdentification15.
Also, all securities messages are now using the element name
“FinancialInstrumentIdentification” instead of the term “SecurityIdentification”. Therefore it is
proposed to also rename those elements typed by SecurityIdentification14 in all messages.
Note that the element “Security/Identification” will therefore be renamed
“Security/FinancialInstrumentIdentification”.
See below current design and new proposed design:

Current Security/Identification element with SecurityIdentification11

New proposed design for Security/Identification element with SecurityIdentification14:

Current SecurityIdentification element with SecurityIdentification11

New proposed design for SecurityIdentification element with SecurityIdentification14:
Document1
Produced by SWIFT on 29 October 14
Page 86
J.
Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
K.
-
As requested
Final decision of the SEG:
Approve
X
Comments: Approved, is in line with the changes to the corporate actions messages, and note that the
name change proposed in the “implementation” section is also approved.
Reject
Reason for rejection:
Document1
Produced by SWIFT on 29 October 14
Page 87