Maintenance Change Request

for the update of ISO 20022 financial repository items

A.  Name of the request:

“Investment Funds Transfers Maintenance 2011/2012”

B.  Submitting organization(s):

SWIFT

C.  Related messages:

Under this project, all ISO 20022 Funds Transfers candidate messages will be maintained:

TransferOutInstruction / Sese.001.001.02
TransferOutCancellationRequest / Sese.002.001.02
TransferOutConfirmation / Sese.003.001.02
ReversalOfTransferOutConfirmation / Sese.004.001.02
TransferInInstruction / Sese.005.001.02
TransferInCancellationRequest / Sese.006.001.02
TransferInConfirmation / Sese.007.001.02
ReversalOfTransferInConfirmation / Sese.008.001.02
RequestForTransferStatusReport / Sese.009.001.02
TransferCancellationStatusReport / Sese.010.001.02
TransferInstructionStatusReport / Sese.011.001.02
PEPOrISAOrPortfolioTransferInstruction / Sese.012.001.02
PEPOrISAOrPortfolioTransferConfirmation / Sese.013.001.02
PEPOrISAOrPortfolioTransferCancellationRequest / Sese.014.001.02
PEPOrISAOrPortfolioInformation / Sese.018.001.01
RequestForPEPOrISAOrPortfolioInformation / Sese.019.001.01

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. For the ISO 20022 yearly maintenance cycle, new valid Message Definition models must be available to the RA by December 1.

-  provide compliant updated Business Process Diagram (activity diagram), Message Flow Diagram (sequence diagram) and, optionally, new examples of valid and invalid XML instances of each candidate message and other descriptive material that will be used by the RA to generate the full Message Definition Report 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 testing and 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 ISO20022 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 ISO20022 Repository through the ISO20022 Registration Authority in accordance with the rules set in ISO20022. To ascertain a widespread, public and uniform use of the ISO20022 Repository information, the contributing organization grants third parties a non-exclusive, royalty-free license to use the published information”.

E.  Contact persons:

Omar Rodriguez – SWIFT Standards, mailto:

Mireia Guisado Parra – SWIFT Standards, mailto:

Change request number # CR0067 (000285)

A.  Origin of the request:

A.1 Submitter: FINDEL Transfer Group

A.2 Contact person: Kathy Shackle:

A.3 Sponsors: FINDEL & ALMUS groups

B.  Related messages:

TransferInstructionStatusReportV02 sese.011.001.02

TransferOutInstructionV02 sese.001.001.02

TransferOutConfirmationV02 sese.003.001.02

TransferInInstructionV02 sese.005.001.02

TransferInConfirmationV02 sese.007.001.02

C.  Description of the change:

Replace the mandatory Requested Transfer Date with an optional date in the transfer messages. This field is not appropriate in the Luxembourg or Cross Border market as the transfer must be processed on receipt. Inclusion of a requested Transfer Date may result in the rejection of a transfer instruction.

D.  Purpose of the change:

This concept is not appropriate in the Luxembourg or Cross Border market (UK Specific) therefore the field should not be mandatory within the message.

E.  Urgency of the request:

Next yearly cycle.

F.  Business examples:

G.  SEG recommendation:

Consider / V / Timing
- Next yearly cycle: 2011/2012
(the change will be considered for implementation in the yearly maintenance cycle which starts in 2011 and completes with the publication of new message versions in the spring of 2012) / V / Priority:
high
medium
low
- 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:

Change multiplicity of element Request Transfer Date to optional within the Transfer Details block.

Messages mentioned in the original change request (sese.011.001.02 TransferInstructionStatusReportV02, sese.003.001.02 TrasferOutConfirmationV02, sese.005.001.02 TransferInInstructionV02, and sese.007.001.02 TransferInConfirmationV02 are not impacted. The message element RequestTransferDate is not present.

The message element RequestedTransferDate is only present and impacts sese.001.001.02 TransferOutInstructionV02 and sese.002.001.02 TransferOutCancellationRequestV02.

I.  Proposed implementation:

Current structure:

Future structure:

J.  Proposed timing:

Timing / -  As requested: SR2012
-  Other:

K.  Final decision of the SEG:

Approve / V

Comments:

Reject

Reason for rejection:

Change request number # CR0068 (000286)

A.  Origin of the request:

A.1 Submitter: FINDEL Transfer Group

A.2 Contact person: Kathy Shackle,

A.3 Sponsors: FINDEL & ALMUS groups

B.  Related messages:

RequestForPEPOrISAOrPortfolioInformationV01 sese.019.001.01

PEPOrISAOrPortfolioInformationV01 sese.018.001.01

PEPOrISAOrPortfolioTransferInstructionV02 sese.012.001.02

PEPOrISAOrPortfolioTransferCancellationRequestV02 sese.014.001.02

PEPOrISAOrPortfolioTransferConfirmationV02 sese.013.001.02

C.  Description of the change:

Replace the mandatory Residual Cash Indicator with an optional code list in the portfolio transfer messages. This field is not appropriate in the Luxembourg or Cross Border market (UK Specific) therefore should not be mandatory within the message.

D.  Purpose of the change:

The Information sharing messages named PEP&ISA&PORTFOLIO” transfer message set have a global usage to agree the assets to be transferred, but the terminology used is very UK centric. To encourage global or cross border implementation of the transfer process generic terminology should be used.

E.  Urgency of the request:

Next yearly cycle.

F.  Business examples:

G.  SEG recommendation:

Consider / V / Timing
- Next yearly cycle: 2011/2012
(the change will be considered for implementation in the yearly maintenance cycle which starts in 2011 and completes with the publication of new message versions in the spring of 2012) / V / Priority:
high
medium
low
- 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:

Inside Product Transfer building block update the element Residual Cash Indicator by:

-  Make element optional

-  Change the data type by a code list with code values:

o  RCTR : Residual Cash to be transferred

o  NRCT: Residual Cash not to be transferred

Message mentioned in the original change request, sese.019.001.01 RequestForPEPOrISAOrPortfolioInformationV01 is not impacted. The message element ResidualCashIndicator is not present in the message.

I.  Proposed implementation:

Current structure:

xs:element name="RsdlCsh" type="YesNoIndicator"/>

Future structure:

xs:simpleType name="ResidualCash1Code">

xs:restriction base="xs:string">

xs:enumeration value="RCTR"/>

xs:enumeration value="NRCT"/>

</xs:restriction

</xs:simpleType

J.  Proposed timing:

Timing / -  As requested: SR2012
-  Other:

K.  Final decision of the SEG:

Approve / V

Comments: approved as modified

Reject

Reason for rejection:

Change request number # CR0069 (000287)

A.  Origin of the request:

A.1 Submitter: FINDEL Transfer Group

A.2 Contact person: Kathy Shackle, Fidelity,

A.3 Sponsors: FINDEL & ALMUS groups

B.  Related messages:

RequestForPEPOrISAOrPortfolioInformationV01 sese.019.001.01

PEPOrISAOrPortfolioInformationV01 sese.018.001.01

PEPOrISAOrPortfolioTransferInstructionV02 sese.012.001.02

PEPOrISAOrPortfolioTransferCancellationRequestV02 sese.014.001.02

PEPOrISAOrPortfolioTransferConfirmationV02 sese.013.001.02

C.  Description of the change:

Change terminology in the PEP&ISA&PORTFOLIO Transfer message set to be internationally generic for use in markets outside the UK.

1.  New Plan Manager Should be Receiving Party or Transferee

2.  Nominee Account Should be the Account of the Receiving Party or Transferee account

3.  To clarify the Account field (Client Account) should be the Delivering Account or Transferor account

4.  The “Portfolio Information” message name should be “Account Holding Information”

5.  The “Portfolio Transfer” message name should be “Account Information Sharing”

D.  Purpose of the change:

The Information sharing messages named PEP&ISA&PORTFOLIO” transfer message set have a global usage to agree the assets to be transferred, but the terminology used is very UK centric. To encourage global or cross border implementation of the transfer process generic terminology should be used.

E.  Urgency of the request:

Next yearly cycle.

F.  Business examples:

G.  SEG recommendation:

Consider / V / Timing
- Next yearly cycle: 2011/2012
(the change will be considered for implementation in the yearly maintenance cycle which starts in 2011 and completes with the publication of new message versions in the spring of 2012) / V / Priority:
high
medium
low
- 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:

For number 4 and 5: renaming messages to “Account Holding Information” & “Account Information Sharing”, the change request is in conflict with the also approved CR0079 (000296).

Following the conf call on the 12th of September, it was decided to carry number 4 and 5 to CR0079. For number 2 it was decided to carry it over to CR0085. Therefore this was not updated as stated in this change request.

I.  Proposed implementation:

Current structure:

Future structure:

J.  Proposed timing:

Timing / -  As requested: SR2012
-  Other:

K.  Final decision of the SEG:

Approve / V

Comments: approved as modified

Reject

Reason for rejection:

Change request number # CR0070 (000288)

A.  Origin of the request:

A.1 Submitter: FINDEL Transfer Group

A.2 Contact person: Kathy Shackle:

A.3 Sponsors: - FINDEL & ALMUS groups

B.  Related messages:

TransferInstructionStatusReportV02 sese.011.001.02

TransferOutInstructionV02 sese.001.001.02

TransferOutConfirmationV02 sese.003.001.02

TransferInInstructionV02 sese.005.001.02

TransferInConfirmationV02 sese.007.001.02

C.  Description of the change:

Replace the mandatory Stamp Duty Indicator by an optional code list in the transfer messages. This field is not appropriate in the Luxembourg or Cross Border market (UK Specific) therefore should not be mandatory within the message.

D.  Purpose of the change:

This concept is not appropriate in the Luxembourg or Cross Border market (UK Specific) therefore the field should not be mandatory within the message.

E.  Urgency of the request:

Next yearly cycle.

F.  Business examples:

G.  SEG recommendation:

Consider / V / Timing
- Next yearly cycle: 2011/2012
(the change will be considered for implementation in the yearly maintenance cycle which starts in 2011 and completes with the publication of new message versions in the spring of 2012) / V / Priority:
high
medium
low
- 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:

Need to discuss at a later stage the solution for this request: an optional indicator is meaningless.

Reject

Reason for rejection

H.  Impact analysis:

Inside Settlement Details building block update the element Stamp Duty Indicator by:

-  Make element optional

-  Change the data type by a code list with code values:

o  ASTD : Applicable

o  NSTD: Not applicable

Message mentioned in the original change request sese.011.001.02 TransferInstructionStatusReportV02 is not impacted. The message element StampDutyIndicator is not present in the message.

Following the conf call of Sept the 12th: change name of element to StampDuty and update the code values to applicable and not applicable.

I.  Proposed implementation:

Current structure:

xs:element name="StmpDtyInd" type="YesNoIndicator"/>

Future structure:

xs:simpleType name="StampDuty1Code">

xs:restriction base="xs:string">

xs:enumeration value="ASTD"/>

xs:enumeration value="NSTD"/>

</xs:restriction

</xs:simpleType

J.  Proposed timing:

Timing / -  As requested: SR2012
-  Other:

K.  Final decision of the SEG(s):

Approve / V

Comments: approved as modified

Reject

Reason for rejection:

Change request number # CR0071 (000289)

A.  Origin of the request:

A.1 Submitter: FINDEL Transfer Group

A.2 Contact person: Kathy Shackle, Fidelity,

A.3 Sponsors: - FINDEL & ALMUS groups

B.  Related messages:

TransferInstructionStatusReportV02 sese.011.001.02

TransferOutInstructionV02 sese.001.001.02

TransferOutConfirmationV02 sese.003.001.02

TransferInInstructionV02 sese.005.001.02

TransferInConfirmationV02 sese.007.001.02

C.  Description of the change:

Replace the mandatory Physical Transfer Indicator (also known as the Physical Delivery Indicator in the Order messages) by an optional code list in the transfer messages. This field is not appropriate in the Luxembourg or Cross Border market therefore should not be mandatory within the message.

D.  Purpose of the change:

The purpose of an electronic transfer is to change the owner in a dematerialized register, therefore to transfer a fund with a physical share certificate this first needs to be dematerialized (share certificate returned) to transfer.

E.  Urgency of the request:

Next yearly cycle.

F.  Business examples:

G.  SEG recommendation:

Consider / V / Timing
- Next yearly cycle: 2011/2012
(the change will be considered for implementation in the yearly maintenance cycle which starts in 2011 and completes with the publication of new message versions in the spring of 2012) / V / Priority:
high
medium
low
- 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:

Need to discuss at a later stage the solution for this request: an optional indicator is meaningless.

Reject

Reason for rejection

H.  Impact analysis:

Inside Settlement Details building block update the element Physical Transfer Indicator by:

-  Make element optional

-  Change the data type by a code list with code values:

o  PHYS : Physical

o  DEMT: Dematerialised

Message mentioned in the original change request sese.011.001.02 TransferInstructionStatusReportV02 is not impacted. The message element PhysicalTransferIndicator is not present in the message.

Following the conf call on Sept the 12th: change name of element to Physical Transfer and update the Code names change to physical and dematerialised.

I.  Proposed implementation:

Current structure:

xs:element name="PhysTrfInd" type="YesNoIndicator"/>

Future structure: