MAINTENANCE CHANGE REQUEST
FOR THE UPDATE OF ISO 20022 FINANCIAL REPOSITORY ITEMS
A. Name of the request:
“Trade Services Management Maintenance 2013/2014”
B. Submitting organization:
SWIFT
C. Related messages:
o tsmt.009.001.03 BaselineAmendmentRequestV03
o tsmt.012.001.03 BaselineReSubmissionV03
o tsmt.019.001.03 InitialBaselineSubmissionV03
o tsmt.018.001.03 FullPushThroughReportV03
o tsmt.014.001.03 DataSetSubmissionV03
o tsmt.017.001.03 ForwardDataSetSubmissionReportV03
o tsmt.002.001.03 ActivityReport
o tsmt.044.001.01 IntentToPayNotificationV01
o tsmt.045.001.01 ForwardIntentToPayNotificationV01
D. Commitments of the submitting organization:
The submitting organization 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 candidate
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.
The submitting organization 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
MCRTemplate.v7
Produced by ISO 20022 RA
Page 1
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:
Robert Marchal (robert.marchal@swift.com)
MCRTemplate.v7
Produced by ISO 20022 RA
Page 2
Change request number CR0286
Copy of the approved change request:
A. Origin of the request:
A.1 Submitter: SWIFT/ ICC Banking Commission
A.2 Contact person: Gary Collyer (gary@collyerconsulting.com) /David Meynell
(davidmeynell@aol.com)
A.3 Sponsors: ICC National Committees
B. Related messages:
BPO block in Baseline in
o tsmt.009.001.03 BaselineAmendmentRequestV03
o tsmt.012.001.03 BaselineReSubmissionV03
o tsmt.019.001.03 InitialBaselineSubmissionV03
o tsmt.018.001.03 FullPushThroughReportV03
C. Description of the change request:
It is understood that in the current messages the charges are defined as being paid by the
Recipient Bank to the Obligor Bank.
A change is required so that any of the following parties could either be responsible to pay or
be entitled to receive charges: BUYER’S BANK, OBLIGOR BANK, RECIPIENT BANK
=SELLER’S BANK.
A new option is also required to identify the type of charge that is to be levied.
These fields must be added in the BPO block in the baseline.
D. Purpose of the change:
To facilitate the interchange of messages utilizing the Bank Payment Obligation in
accordance with ICC Uniform Rules for Bank Payment Obligations.
This has been requested by ICC National Committees. Without such change, manual work is
required in order to add the information in a bilateral agreement between banks.
E. Urgency of the request:
To be handled in accordance with the normal yearly maintenance cycle.
F. Business examples:
Suggested type of charges: “Banking or Transaction Charges” and “Financing Charges”,
“Obligation", "Payment", "Deferred Payment" and "Other".
Suggested type: 35 character free format field
MCRTemplate.v7
Produced by ISO 20022 RA
Page 3
G. SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2013/2014
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:
The trade SEG recommends that interest be added.
This can be mentioned in the type of charges field
H. Impact analysis:
As described in the change request.
I. Proposed implementation:
Detailed description of the required modification to implement the requested change.
The Payment Obligation block will have a repetitive optional sub-block “Charges”
containing the following
Definition of ChargesPayer: Bank which will pay the charges.
Definition of ChargesPayee: Bank which will receive the charges.
MCRTemplate.v7
Produced by ISO 20022 RA
Page 4
ChargesPayer and ChargesPayee are typed by a code list:
J. Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
-
As requested: X
-
Other:
K. Final decision of the SEG:
This section is not to be taken care of by the submitting organization. It will be completed in
due time by the SEG in charge of the related ISO 20022 messages.
Approve
Comments:
Reject
Reason for rejection:
MCRTemplate.v7
Produced by ISO 20022 RA
Page 5
Change request number CR0285
Copy of the approved change request:
A. Origin of the request:
A.1 Submitter: SWIFT/ ICC Banking Commission
A.2 Contact person: Gary Collyer (gary@collyerconsulting.com) /David Meynell
(davidmeynell@aol.com)
A.3 Sponsors: ICC National Committees
B. Related messages:
BPO block in Baseline in
o tsmt.009.001.03 BaselineAmendmentRequestV03
o tsmt.012.001.03 BaselineReSubmissionV03
o tsmt.019.001.03 InitialBaselineSubmissionV03
o tsmt.018.001.03 FullPushThroughReportV03
C. Description of the change request:
A new optional field is required in the BPO block to add ‘place of jurisdiction’.
Definition: The location and forum for dispute resolution.
The “Governing Law” field must allow for something else than a country code (for example
“New York”, “Ontario”). Technically it should be a choice between a country code and a
free format field.
D. Purpose of the change:
To facilitate the interchange of messages utilising the Bank Payment Obligation in
accordance with ICC Uniform Rules for Bank Payment Obligations.
This has been requested by ICC National Committees. Without such change, manual work is
required in order to add the information in a bilateral agreement between banks.
E. Urgency of the request:
To be handled in accordance with the normal yearly maintenance cycle.
F. Business examples:
There is currently no ability to indicate a governing law other than by ISO Alpha code for
the applicable law data field. These codes do not allow specification of New York, English
or Ontario law, for example. The place of jurisdiction is likely to be a country, state or
province or other location: “Courts of England” or “State or Federal Courts located in New
York, New York”.
MCRTemplate.v7
Produced by ISO 20022 RA
Page 6
G. SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2013/2014
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:
SEG suggests to use a variant of the component used in guarantees messages (Location1).
But Location1 has a Text field of 2000 characters, repeatable up to 5 times which is way too
much. So the SEG asks to restrict the text field to 35 characters.
H. Impact analysis:
As described in the change request.
I. Proposed implementation:
Detailed description of the required modification to implement the requested change.
The Payment Obligation block will have a new optional block (choice)
“PlaceOfJurisdiction”
MCRTemplate.v7
Produced by ISO 20022 RA
Page 7
Definition of PlaceOfJurisdiction: Location and forum for dispute resolution.
It is a choice between a country code and a text of 35 characters
J. Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
-
As requested: X
-
Other:
K. Final decision of the SEG:
This section is not to be taken care of by the submitting organization. It will be completed in
due time by the SEG in charge of the related ISO 20022 messages.
Approve
Comments:
Reject
Reason for rejection:
MCRTemplate.v7
Produced by ISO 20022 RA
Page 8
Change request number CR0282
Copy of the approved change request:
A. Origin of the request:
A.1 Submitter: SWIFT/ ICC Banking Commission
A.2 Contact person: Gary Collyer (gary@collyerconsulting.com) /David Meynell
(davidmeynell@aol.com)
A.3 Sponsors: ICC National Committees
B. Related messages:
The Baseline and BPO block in Baseline in
o tsmt.009.001.03 BaselineAmendmentRequestV03
o tsmt.012.001.03 BaselineReSubmissionV03
o tsmt.019.001.03 InitialBaselineSubmissionV03
o tsmt.018.001.03 FullPushThroughReportV03
C. Description of the change request:
Addition of codes to the PaymentTimeCode list at the level of the baseline and BPO for
Payment at end of period after shipment date
Payment at end of period after purchase order date
Payment at end of period after Baseline establishment
Payment at end of period after invoice date.
Removal of the following codes at the level of the BPO because the payment date cannot be
determined by the Obligor Bank:
CASH
PaymentOnDelivery
Code for payment on delivery.
EMTD EndOfMonthOfDelivery
Code for payment at end of month of
delivery.
EMTR EndOfMonthOfReceipt
Code for payment at end of month of
receipt of invoice.
EPRD
Code for payment at end of period
after delivery.
EndOfPeriodAfterDelivery
MCRTemplate.v7
Produced by ISO 20022 RA
Page 9
EPRR
EndOfPeriodAfterReceipt
Code for payment at end of period
after receipt of invoice.
IREC
PaymentOnReceiptOfInvoice
Code for payment on receipt of
invoice.
PRMD EndOfPeriodAfterEndOfDeliveryMonth Code for payment at end of period
after end of month of delivery
PRMR EndOfPeriodAfterEndOfReceiptMonth
Code for payment at end of period
after end of month of receipt of
invoice.
D. Purpose of the change:
To facilitate the interchange of messages utilising the Bank Payment Obligation in
accordance with ICC Uniform Rules for Bank Payment Obligations.
E. Urgency of the request:
To be handled in accordance with the normal yearly maintenance cycle.
F. Business examples:
The 4 letter codes are to be decided.
The current list and codes are:
CASH
PaymentOnDelivery
Code for payment on delivery.
EMTD EndOfMonthOfDelivery
Code for payment at end of month of
delivery.
EMTR EndOfMonthOfReceipt
Code for payment at end of month of
receipt of invoice.
EPAM EndOfPeriodAfterMatch
Code for payment at end of period
after match or mismatch acceptance.
EPRD
Code for payment at end of period
after delivery.
EndOfPeriodAfterDelivery
MCRTemplate.v7
Produced by ISO 20022 RA
Page 10
EPRR
EndOfPeriodAfterReceipt
Code for payment at end of period
after receipt of invoice.
IREC
PaymentOnReceiptOfInvoice
Code for payment on receipt of
invoice.
PRMD EndOfPeriodAfterEndOfDeliveryMonth Code for payment at end of period
after end of month of delivery
PRMR EndOfPeriodAfterEndOfReceiptMonth
Code for payment at end of period
after end of month of receipt of
invoice.
G. SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2013/2014
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: The SEG recommends that additional codes will be needed in the interbank
arena and that the old codes remain
H. Impact analysis:
As described in the change request. The SEG asked not to remove codes, but only add codes.
This is safer approach.
MCRTemplate.v7
Produced by ISO 20022 RA
Page 11
I. Proposed implementation:
Detailed description of the required modification to implement the requested change.
PaymentTerms in the BPO block will use another code list
This code list will be:
At the level of the baseline (PO), the list of codes will be almost the same: only difference
being that “End of Period After MATCH” is not present.
MCRTemplate.v7
Produced by ISO 20022 RA
Page 12
J. Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
-
As requested: X
-
Other:
K. Final decision of the SEG:
This section is not to be taken care of by the submitting organization. It will be completed in
due time by the SEG in charge of the related ISO 20022 messages.
Approve
Comments:
Reject
Reason for rejection:
MCRTemplate.v7
Produced by ISO 20022 RA
Page 13
Change request number CR0283
Copy of the approved change request:
A. Origin of the request:
A.1 Submitter: SWIFT/ ICC Banking Commission
A.2 Contact person: Gary Collyer (gary@collyerconsulting.com) /David Meynell
(davidmeynell@aol.com)
A.3 Sponsors: ICC National Committees
B. Related messages:
BPO block in Baseline in
o tsmt.009.001.03 BaselineAmendmentRequestV03
o tsmt.012.001.03 BaselineReSubmissionV03
o tsmt.019.001.03 InitialBaselineSubmissionV03
o tsmt.018.001.03 FullPushThroughReportV03
C. Description of the change request:
A new optional field is required in the BPO block to add ‘Applicable rules’, for example
URBPO.
With version number (and possibly Issuer)
Definition: The URBPO are rules that apply to a BPO when the Payment Obligation
Segment within an Established Baseline expressly states that it is subject to these rules or
when each Involved Bank agrees in a separate agreement that a BPO is subject to these rules.
If an Established Baseline or separate agreement does not indicate the applicable version of
URBPO, the BPO will be subject to the latest version in effect when the Baseline is
established in accordance with sub-article 9 (d).
D. Purpose of the change:
To facilitate the interchange of messages utilizing the Bank Payment Obligation in
accordance with ICC Uniform Rules for Bank Payment Obligations.
This has been requested by ICC National Committees. Without such change, manual work is
required in order to add the information in a bilateral agreement between banks.
Article 2 a) of URBPO: The URBPO are rules that apply to a BPO when the Payment Obligation Segment
within an Established Baseline expressly states that it is subject to these rules or when each Involved Bank
agrees in a separate agreement that a BPO is subject to these rules.
A field is required stating that the BPO is subject to URBPO.
Article 2 b) of URBPO: If an Established Baseline or separate agreement does not indicate the applicable
version of URBPO, the BPO will be subject to the latest version in effect when the Baseline is established in
accordance with sub-article 9 (d).
MCRTemplate.v7
Produced by ISO 20022 RA
Page 14
E. Urgency of the request:
To be handled in accordance with the normal yearly maintenance cycle.
F. Business examples:
“URBPO” for applicable rules, “1.0” for version.
MCRTemplate.v7
Produced by ISO 20022 RA
Page 15
G. SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2013/2014
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:
H. Impact analysis:
As described in the change request.
I. Proposed implementation:
Detailed description of the required modification to implement the requested change.
The Payment Obligation block will have a new optional block (choice)
“ApplicableRules”
Definition of ApplicableRules: Rules which apply to the BPO (Bank Payment Obligation).
It is a choice between a URBPO version number (decimal format, for example 1.0 , 24.3)
and a text to specify other rules and version.
MCRTemplate.v7
Produced by ISO 20022 RA
Page 16
J. Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
-
As requested X
-
Other:
K. Final decision of the SEG:
This section is not to be taken care of by the submitting organization. It will be completed in
due time by the SEG in charge of the related ISO 20022 messages.
Approve
Comments:
Reject
Reason for rejection:
MCRTemplate.v7
Produced by ISO 20022 RA
Page 17
Change request number CR0284
Copy of the approved change request:
A. Origin of the request:
A.1 Submitter: SWIFT/ ICC Banking Commission
A.2 Contact person: Gary Collyer (gary@collyerconsulting.com) /David Meynell
(davidmeynell@aol.com)
A.3 Sponsors: ICC National Committees
B. Related messages:
For changes to the Baseline
o tsmt.009.001.03 BaselineAmendmentRequestV03
o tsmt.012.001.03 BaselineReSubmissionV03
o tsmt.019.001.03 InitialBaselineSubmissionV03
o tsmt.018.001.03 FullPushThroughReportV03
For changes to the Transport data set
o tsmt.014.001.03 DataSetSubmissionV03
o tsmt.017.001.03 ForwardDataSetSubmissionReportV03
1)
2)
3)
4)
5)
6)
Vessel Name – Baseline
Carrier Country – Transport Data Set (Sea, Air, Rail, Road) and Baseline
Carrier’s Agent Name and Country – Transport Data Set (Sea, Air, Rail, Road) and Baseline
Flight Number - TransportByAir in the Transport data set
Master’s Name; Charterer’s Name, Owner’s Name - TransportBySea in Transport data set.
IMO Number- TransportBySea in Transport data set.
C. Description of the change request:
The following fields should be added as optional elements:
1) A field is required in the Baseline for ‘Vessel Name’. This is currently available only in
TransportBySea in the Transport data set (in DataSetSubmission).
2) Fields are available for Carrier Name (as below) – this needs extension to additionally cover
Carrier Country.
SeaCarrierName is present in TransportBySea in the Transport data set (in DataSetSubmission)
AirCarrierName is present in TransportByAir in the Transport data set (in DataSetSubmission)
MCRTemplate.v7
Produced by ISO 20022 RA
Page 18
RailCarrierName is present in TransportByRail in the Transport data set (in DataSetSubmission)
RoadCarrierName is present in TransportByRoad in the Transport data set (in DataSetSubmission)
The corresponding elements are in the Baseline.
3) Carrier’s Agent Name and Country - no field currently available in TransportBySea /
TransportByAir / TransportByRail / TransportByRoad.
4) Flight Number - no field currently available. Required in TransportByAir in the Transport
data set.
5) Master’s Name; Charterer’s Name; Owner’s Name - no fields currently available. Required in
TransportBySea in the Transport dataset.
6) IMO Number - TransportBySea in Transport data set.
Definitions
Vessel Name - the name of the vessel carrying the goods from a port of loading to a port of
discharge;
Carrier Country - country in which the carrier of the goods i.e., shipping company, is located
or registered;
Carrier's Agent Name and Country - Name and country of the carrier's (shipping company's)
agent that acts on behalf of the carrier and may be the issuer of transport documents relating
to the underlying shipment;
Flight Number - the flight number allocated by the airline that is carrying the goods from an
airport of departure to an airport of destination;
Master's Name - the name of the master or captain of a vessel that signs the document i.e.,
bill of lading, charter party bill of lading, non-negotiable sea waybill or multimodal transport
document that evidences shipment of the goods from a port of loading to a port of discharge;
Charterer's name - the name of the company or individual that signs a charter party bill of
lading that evidences shipment of the goods from a port of loading to a port of discharge and
acts in the capacity of charterer;
Owner's name - the name of the company or individual that signs a charter party bill of
lading that evidences shipment of the goods from a port of loading to a port of discharge and
acts in the capacity of owner;
IMO Number: International Maritime Organisation identification of a ship. The IMO
identification number scheme was introduced in 1987 as a measure aimed at enhancing maritime
safety and pollution prevention and to facilitate the prevention of maritime fraud. It assigns a
permanent number to each vessel for identification purposes. This number remains unchanged
upon transfer of the vessel to other flag(s) and is inserted in all vessel certificates. The IMO
identification number is made up of the three letters "IMO" followed by a seven-digit number
assigned to all vessels by IHS FairPlay (formerly known as Lloyd's Register-Fairplay). This is a
unique seven digit number that is assigned to vessels and aids banks in determining whether a
vessel is subject to an order that would not permit a bank to handle a certain transaction under
local or international laws.
MCRTemplate.v7
Produced by ISO 20022 RA
Page 19
D. Purpose of the change:
To facilitate the interchange of messages utilizing the Bank Payment Obligation in
accordance with ICC Uniform Rules for Bank Payment Obligations.
The rationale for adding these fields is regulatory and governmental linked to sanctions
regulations implemented by the likes of the UN, EU, etc.
E. Urgency of the request:
To be handled in accordance with the normal yearly maintenance cycle.
F. Business examples:
Vessel name. Examples “Agamemnon, Aegean Leader”. Suggested type: 35 character free
format field.
Carrier Country: Suggested type CountryCode list (2 characters)
Carrier's Agent Name: Suggested type: 70 character free format field.
Carrier's Agent Country: Suggested type CountryCode list (2 characters)
Flight Number: Suggested type: 10 character free format field.
Master's Name: Suggested type: 70 character free format field.
Charterer's name: Suggested type: 70 character free format field.
Owner's name: Suggested type: 70 character free format field.
IMO example: “IMO1234567”. Suggested type: 10 character free format field
MCRTemplate.v7
Produced by ISO 20022 RA
Page 20
G. SEG recommendation:
Consider
X
Timing
- Next yearly cycle: 2013/2014
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: Name Field length to be increased to 70 characters
The SEG wonders why flight number is present for TransportByAir and not “Voyage
Number” for the TransportBySea. After discussion with the Draffting Group (ICC), it is
agreed to add VoyageNumber typed by Max35Text
H. Impact analysis:
As described in the change request. The SEG asked that new elements containing names be
70 char long.
I. Proposed implementation:
Detailed description of the required modification to implement the requested change.
The different transport elements (TransportBySea, TransportByRoad, TransportByRail,
TransportByAir) in the transport data set will be updated and the new elements will be
added.
Here are the details, with new elements highlighted:
MCRTemplate.v7
Produced by ISO 20022 RA
Page 21
(new elements highlighted)
TransportByRoad and TransportByRail:
Addition of
-
Road/Rail Carrier Country
-
Carrier Agent Name
-
Carrier Agent Country
Definitions will be as indicated in the change request. (section C)
The different transport elements (TransportBySea, TransportByRoad, TransportByRail,
TransportByAir) in the baseline will be updated and the new elements will be added.
Same data types will be used that in the transport data set
MCRTemplate.v7
Produced by ISO 20022 RA
Page 22
1° TransportBySea,
-
Vessel Name
-
Sea Carrier Country
-
Carrier Agent Name
-
Carrier Agent Country
2° TransportByRoad,
-
Road Carrier Country
-
Carrier Agent Name
-
Carrier Agent Country
3° TransportByRail
-
Rail Carrier Country
-
Carrier Agent Name
-
Carrier Agent Country
4° TransportByAir
-
Air Carrier Country
-
Carrier Agent Name
-
Carrier Agent Country
The usual matching rules between baseline and data sets will be applied:
1° if an element is specified in the baseline, and no corresponding element in the data set,
this is a mismatch
2 ° if an element is specified in the baseline, and the corresponding element in the data
set is present and different, this is a mismatch
3° if an element is NOT specified in the baseline, and the corresponding element is
present in the data set, this is NOT a mismatch
MCRTemplate.v7
Produced by ISO 20022 RA
Page 23
J. Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
-
As requested: X
-
Other:
K. Final decision of the SEG:
This section is not to be taken care of by the submitting organization. It will be completed in
due time by the SEG in charge of the related ISO 20022 messages.
Approve
Comments:
Reject
Reason for rejection:
MCRTemplate.v7
Produced by ISO 20022 RA
Page 24
Change request number CR0113
Copy of the approved change request:
A. Origin of the request:
A.1 Submitter: SWIFT on behalf of Deutsche Bank, Bayer and BP Chemical
A.2 Contact person: Robert Marchal robert.marchal@swift.com
A.3 Sponsors: Deutsche Bank, Bayer and BP Chemical
B. Related messages:
o tsmt.009.001.03 BaselineAmendmentRequestV03
o tsmt.012.001.03 BaselineReSubmissionV03
o tsmt.019.001.03 InitialBaselineSubmissionV03
o tsmt.018.001.03 FullPushThroughReportV03
o tsmt.014.001.03 DataSetSubmissionV03
o tsmt.017.001.03 ForwardDataSetSubmissionReportV03
C. Description of the change request:
Today, the PaymentTerms block contains the two options (it’s a choice)
-
PaymentCode (contains a code and a number of days)
-
OtherPaymentTerms (is a free text field of 140 characters)
The CR requests the addition of a 3rd option
-
InvoiceDueDate (formatted as any other date in XML, YYYY-MM-DD)
D. Purpose of the change:
To allow to specify a latest date for the payment, as a specific day. This is a common
practice. Today, this can be achieved through the OtherPaymentTerms but because of
different formats and conventions, this will not allow automation and straight-through
processing
E. Urgency of the request:
To be handled in accordance with the normal yearly maintenance cycle.
F. Business examples:
InvoiceDueDate = 2011-05-27
MCRTemplate.v7
Produced by ISO 20022 RA
Page 25
G. SEG recommendation:
Consider
X
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)
- At the occasion of the next maintenance of the X
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:
H. Impact analysis:
As described in the change request.
I. Proposed implementation:
Detailed description of the required modification to implement the requested change.
Currently we have
This will be changed to
MCRTemplate.v7
Produced by ISO 20022 RA
Page 26
The above is strictly compliant with the initial request. However it is restrictive in the sense
that the element specifically refers to Invoice. We should consider to make the element more
generic by calling it Payment Due Date.
J. Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
-
As requested: X
-
Other:
K. Final decision of the SEG:
This section is not to be taken care of by the submitting organization. It will be completed in
due time by the SEG in charge of the related ISO 20022 messages.
Approve
Comments:
Reject
Reason for rejection:
MCRTemplate.v7
Produced by ISO 20022 RA
Page 27
Change request number CR0114
Copy of the approved change request:
A. Origin of the request:
A.1 Submitter: SWIFT
A.2 Contact person: Robert Marchal robert.marchal@swift.com
B. Related messages:
o tsmt.009.001.03 BaselineAmendmentRequestV03
o tsmt.012.001.03 BaselineReSubmissionV03
o tsmt.019.001.03 InitialBaselineSubmissionV03
o tsmt.018.001.03 FullPushThroughReportV03
C. Description of the change request:
The block ShipmntSubSchdl (ShipmentSubSchedule) which is meant for a breakdown of
shipped quantities inside a line item, must always be present at least twice. Today the
multiplicity is 1..*, so this must be changed to 2..*
If there is only one occurrence of this field, there is by definition no sub-schedule.
D. Purpose of the change:
This is a technical change that will clarify the usage of this field.
E. Urgency of the request:
Should only be implemented if other business-related change(s) trigger a new version of the
messages. In other words, this change request alone should not trigger a new version of the
messages.
F. Business examples:
ShipmentSubSchedule such as:
50 to be shipped between 1st and 31st of July and
50 to be shipped between 1st and 31st of August
Out of a total of 100 in one line item.
MCRTemplate.v7
Produced by ISO 20022 RA
Page 28
G. SEG recommendation:
Consider
X
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)
- At the occasion of the next maintenance of the X
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:
H. Impact analysis:
As described in the change request.
I. Proposed implementation:
Detailed description of the required modification to implement the requested change.
This component in the baseline
Will be replaced by this one
MCRTemplate.v7
Produced by ISO 20022 RA
Page 29
Baseline4/Goods:LineItem11/LineItemDetails10/ ShipmentSchedule2Choice
J. Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
-
As requested: X
-
Other:
K. Final decision of the SEG:
This section is not to be taken care of by the submitting organization. It will be completed in
due time by the SEG in charge of the related ISO 20022 messages.
Approve
Comments:
Reject
Reason for rejection:
MCRTemplate.v7
Produced by ISO 20022 RA
Page 30
Change request number CR0115
Copy of the approved change request:
A. Origin of the request:
A.1 Submitter: SWIFT
A.2 Contact person: Robert Marchal robert.marchal@swift.com
B. Related messages:
o tsmt.002.001.03 ActivityReportV03
C. Description of the change request:
The ReportedEntity in the ActivityReport should be of multiplicity 1..*. If the user asks an
ActivityReport for ReportedEntities A, B and C, and there is a transaction involving A, B
and C and they all have exchanged messages, then ReportedEntities in the ActivityReport
should be A, B and C. Currently there is only space for one entity.
D. Purpose of the change:
This is a technical change that will allow the matching application to send a report that is
compliant to the XML schemas in all cases.
E. Urgency of the request:
Should only be implemented if other business-related change(s) trigger a new version of the
messages. In other words, this change request alone should not trigger a new version of the
messages.
F. Business examples:
G. SEG recommendation:
Consider
X
MCRTemplate.v7
Timing
- Next yearly cycle: 2011/2012
(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 X
messages
(the change will be considered for implementation, but
does not justify maintenance of the messages in its own
Produced by ISO 20022 RA
Page 31
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:
H. Impact analysis:
As described in the change request.
I. Proposed implementation:
Detailed description of the required modification to implement the requested change.
Currently we have
This will be modified to be
MCRTemplate.v7
Produced by ISO 20022 RA
Page 32
J. Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
-
As requested: X
-
Other:
K. Final decision of the SEG:
This section is not to be taken care of by the submitting organization. It will be completed in
due time by the SEG in charge of the related ISO 20022 messages.
Approve
Comments:
Reject
Reason for rejection:
MCRTemplate.v7
Produced by ISO 20022 RA
Page 33
Change request number CR0066
Extract of the approved change request:
A. Origin of the request:
A.1 Submitter: SWIFT
A.2 Contact person: David Dobbing david.dobbing@swift.com
A.3 Sponsors: - CGI (Common Global Implementation)
www.swiftcommunity.net/communities/CGI
Ms Susan Collessusan.k.colles@baml.com
Ms Mieko Morioka
mieko.morioka@swift.com
B. Related messages:
We noticed that the component CashAccountType4Code is also used in the trade services
messages definitions below. Although the change request doesn't relate to these messages,
we leave it to the SEG(s) to decide if it makes sense to also adapt these message definitions
for consistency purposes.
tsin.001.001.01
tsin.002.001.01
tsin.003.001.01
tsin.004.001.01
tsmt.009.001.03
tsmt.012.001.03
tsmt.014.001.03
tsmt.017.001.03
tsmt.018.001.03
tsmt.019.001.03
tsmt.044.001.01
tsmt.045.001.01
InvoiceFinancingRequestV01
InvoiceFinancingRequestStatusV01
InvoiceFinancingCancellationRequestV01
FinancialInvoiceV01
BaselineAmendmentRequestV03
BaselineReSubmissionV03
DataSetSubmissionV03
ForwardDataSetSubmissionReportV03
FullPushThroughReportV03
InitialBaselineSubmissionV03
IntentToPayNotificationV01
ForwardIntentToPayNotificationV01
C. Description of the change request:
Change request is in two related parts that should be reviewed together, but could be subject
to independent approval or rejection.
1) Request the addition of two new code values to the below list of Cash Account Type
codes:
MCRTemplate.v7
Produced by ISO 20022 RA
Page 34
Add:
Code
Name
Definition
LLSV
Limited Liquidity Savings Account
Account used for savings with special interest and
withdrawal terms.
OTHR
Other account
Account not otherwise specified.
2) Request that this code list be transformed from an ISO 20022 internal schema defined
code list to an ISO 20022 external code list.
MCRTemplate.v7
Produced by ISO 20022 RA
Page 35
D. Purpose of the change:
In the Japanese retail payment system messages (Zengin messages), in both C2B and B2B
messages, type of creditor’s account is mandatory information. To fully utilize the ISO code
rather than proprietary code, 2 new codes are necessary in ISO 20022 messages.
1) Requested Code: LLSV (Limited Liquidity Savings Account)
Limited Liquidity Savings Account (Chochiku-Yokin, Zengin account code 04)
A deposit account with higher interest rate than the savings account (Futsu-Yokin) and
has more flexibility (in principle, this account can be freely withdrawn and credit) than
the term deposit account (Teiki-Yokin). There are two types of special savings account:
(1) special savings account with interest rate differentiated by deposit amount, and (2)
special savings account with higher interest rate upon maintaining required minimum
amount. Currently, the majority of special savings accounts are type (1). A special
savings account is only allowed for individuals. It can be used to receive funds via credit
transfers, however, cannot be used for direct debit, and certain types of payments such as
salary, pension, dividend, etc.
Each bank offers different conditions for the details of interest rate calculation and the
terms of withdrawal: Reduction of interest rate when the amount of deposit was below
floor amount, deduct additional charges in case number of withdrawal exceeds the agreed
frequency, etc.
http://www.mizuhobank.co.jp/saving/chochiku/index.html
http://www.bk.mufg.jp/tameru/yen/samazama/chochiku/btm/index.html
http://www.smbc.co.jp/kojin/yokin/chochiku/index.html
2) Requested code: OTHR (Other Account)
Other account (Sono-ta, Zengin account code 09)
In the Zengin message, there are 4 account type codes defined, and one of these codes
must be present as creditor account information.
01: Ordinary Account (mapped to CACC)
02: Savings Account (mapped to SVGS)
04: Limited Liquidity Savings Account (to be mapped to a new code, LLSV)
09: Other Account (to be mapped to a new code, OTHR)
The Cash Account Type code set is considered a core ISO 20022 code set. The
transformation to an ISO 20022 external code list will better facilitate maintenance that may
occur in the future. In defining specific financial accounts it is likely that new cash account
MCRTemplate.v7
Produced by ISO 20022 RA
Page 36
types can be expected and for interoperability reasons, these should be defined as part of an
ISO 20022 code list rather than as proprietary codes.
E. Urgency of the request:
Should only be implemented if other business-related change(s) trigger a new version of the
messages. In other words, this change request alone should not trigger a new version of the
messages.
F. Business examples:
See D (Purpose of Change).
G. SEG recommendation:
Consider
X
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)
- 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:
for
Payment
s
messages
for Trade
Services
messages
Comments:
The Payments SEG prefers using an external code list
- The Trade Services SEG agrees to implement the external code list to be defined by the
Payments SEG at the occasion of the next maintenance of the related tsin and tsmt messages.
However, the Trade SEG requests clarification on the use of “othr” as a new external code.
ISO 20022 has strived for the use of specific code lists and this request seems to break with
that historical philosophy.
The Trade SEG also requests to update the IncoTerms contained in the tsmt messages. They
are not the latest version, which is IncoTerms 2010. An appropriate component exists
(Incoterms3); it has been used in the FinancialInvoice message. It uses an external code list
with Incoterms 2010 elements.
MCRTemplate.v7
Produced by ISO 20022 RA
Page 37
25 Nov 2013 - SEG agreed to increase the size of Location in the component Incoterms3
from Max35Text to Max70Text. To be applied as part of the current maintenance for the
tsmt messages and held over for the next occasion of update for the tsin.004 (Financial
Invoice).
For information, here is the External code list, as published on the iso20022.org web site:
The definitions in this list should mention Incoterms 2010.
H. Impact analysis:
As described in the change request.
MCRTemplate.v7
Produced by ISO 20022 RA
Page 38
I. Proposed implementation:
Detailed description of the required modification to implement the requested change.
Currently, we have the following code list for CashAccountType
Would be replaced with
J. Proposed timing:
The submitting organization confirms that it can implement the requested changes in the
requested timing.
Timing
-
As requested: X
- Other:
K. Final decision of the SEG:
This section is not to be taken care of by the submitting organization. It will be completed in
due time by the SEG in charge of the related ISO 20022 messages.
Approve
XXX
Comments: The trade SEG requests that the definitions in this list should mention Incoterms
2010
Reject
Reason for rejection:
MCRTemplate.v7
Produced by ISO 20022 RA
Page 39