0% found this document useful (0 votes)

16 views126 pages

2 SWIFT sr2015 - mdr1 - Standards

The document is a Message Definition Report for Trade Services Management, detailing the use of messages, business scenarios, and message flows. It outlines the scope, functionality, business roles, and transactions involved in trade services, along with a comprehensive list of message definitions. The report serves as a foundational guide for understanding the communication requirements and interactions within trade transactions.

Uploaded by

Herbert Marcelo de Andrade

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

16 views126 pages

2 SWIFT sr2015 - mdr1 - Standards

Uploaded by

Herbert Marcelo de Andrade

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 126

Standards

Trade Services Management November 2015

Standards MX

Message Definition Report Part 1

This document provides information about the use of the messages for Trade Services Management and
includes, for example, business scenarios and messages flows.

20 February 2015
Trade Services Management November 2015

Table of contents
1. Introduction ..................................................................................................................... 5
1.1 Terms and definitions ....................................................................................................... 5
1.2 Glossary ........................................................................................................................... 5
1.3 Document Scope and Objectives...................................................................................... 6
1.4 References ........................................................................................................................ 6
2. Scope and Functionality ................................................................................................ 7
2.1 Background ...................................................................................................................... 7
2.2 Scope ................................................................................................................................ 7
2.3 Groups of MessageDefinitions and Functionality ............................................................ 7
3. BusinessRoles and Participants ................................................................................... 9
4. BusinessProcess Description ..................................................................................... 10
4.1 Trade Services Management .......................................................................................... 10
5. BusinessTransactions ................................................................................................. 12
5.1 Successful transaction establishment scenario - lodge ................................................... 12
5.2 Successful transaction establishment scenario – push-through ...................................... 12
5.3 Unsuccessful transaction establishment scenario – lodge .............................................. 13
5.4 Unsuccessful transaction establishment scenario – push-through .................................. 14
5.5 Unsuccessful transaction establishment scenario – duplicate transaction ...................... 15
5.6 Baseline Establishment: Baseline mismatch scenario .................................................... 16
5.7 Successful transaction establishment with secondary bank scenario - lodge ................. 18
5.8 Successful transaction establishment with secondary bank scenario – push-through .... 19
5.9 Successful transaction establishment with secondary bank scenario – several secondary banks
........................................................................................................................................ 21
5.10 Baseline Establishment: Closure of not yet established push-through transactions scenario 24
5.11 Baseline Establishment: Prohibited instructions scenario .............................................. 25
5.12 Data Set Submission: Data set pre-match scenario ........................................................ 26
5.13 Data Set Submission: Data set match in the push-through mode scenario ..................... 27
5.14 Data Set Submission: Data set match for transactions initiated in the lodge mode scenario 29
5.15 Data Set Submission: Data set match for transactions with secondary bank scenario ... 32
5.16 Data Set Submission: Data set submission - multiple baselines scenario ...................... 35
5.17 Data Set Submission: Data set submission - multiple submitters scenario .................... 38
5.18 Baseline Amendment: Amendment of transactions initiated in the push-through mode scenario
........................................................................................................................................ 39
5.19 Baseline Amendment: Amendment of transactions initiated in the lodge mode scenario43
5.20 Baseline Amendment: Baseline amendment with secondary bank scenario .................. 43
5.21 Status Change and Extension: Request to change status of push-through transactions scenario
........................................................................................................................................ 45
5.22 Status Change and Extension: Request to change or extend the status for transactions initiated in
the lodge mode scenario ................................................................................................. 48
5.23 Status Change and Extension: Request to close transactions initiated in the push-through mode
scenario .......................................................................................................................... 49
5.24 Status Change and Extension: Change or extend status in presence of secondary bank scenario
........................................................................................................................................ 49
5.25 Status Change and Extension: Request to change or extend status by a secondary bank scenario
........................................................................................................................................ 51
5.26 Intent to pay scenario ..................................................................................................... 52
5.27 Reminder notification scenario ...................................................................................... 53

20 February 2015 Page 2

Table of Contents

5.28 Time-out notification scenario ....................................................................................... 54

5.29 Activity Reporting .......................................................................................................... 55
5.30 Status Reporting ............................................................................................................. 56
5.31 Transaction Reporting .................................................................................................... 57
5.32 Error notification scenario .............................................................................................. 57
5.33 Special request scenario ................................................................................................. 58
6. Examples ....................................................................................................................... 59
6.1 Acknowledgement - tsmt.001.001.03............................................................................. 59
6.2 ActivityReport - tsmt.002.001.04 ................................................................................... 60
6.3 ActivityReportRequest - tsmt.003.001.03 ...................................................................... 61
6.4 ActivityReportSetUpRequest - tsmt.004.001.02 ............................................................ 61
6.5 AmendmentAcceptance - tsmt.005.001.02 .................................................................... 61
6.6 AmendmentAcceptanceNotification - tsmt.006.001.03 ................................................. 62
6.7 AmendmentRejection - tsmt.007.001.02 ........................................................................ 63
6.8 AmendmentRejectionNotification - tsmt.008.001.03..................................................... 63
6.9 BaselineAmendmentRequest - tsmt.009.001.05 ............................................................ 64
6.10 BaselineMatchReport - tsmt.010.001.03 ........................................................................ 68
6.10.1 XML Instance - Scenario 1 ....................................................... 68
6.10.2 XML Instance - Scenario 2 ....................................................... 69
6.11 BaselineReport - tsmt.011.001.04 .................................................................................. 70
6.12 BaselineReSubmission - tsmt.012.001.05 ...................................................................... 74
6.13 DataSetMatchReport - tsmt.013.001.03 ......................................................................... 79
6.14 DataSetSubmission - tsmt.014.001.05 ........................................................................... 80
6.14.1 XML Instance 1 ......................................................................... 81
6.14.2 XML Instance 2 ......................................................................... 84
6.15 DeltaReport - tsmt.015.001.03 ....................................................................................... 89
6.16 ErrorReport - tsmt.016.001.03 ....................................................................................... 90
6.17 ForwardDataSetSubmissionReport - tsmt.017.001.05 ................................................... 91
6.18 FullPushThroughReport - tsmt.018.001.05 .................................................................... 95
6.19 InitialBaselineSubmission - tsmt.019.001.05 ................................................................. 99
6.19.1 XML Instance 1 ....................................................................... 100
6.19.2 XML Instance 2 ....................................................................... 104
6.20 MisMatchAcceptance - tsmt.020.001.02 ...................................................................... 108
6.21 MisMatchAcceptanceNotification - tsmt.021.001.03................................................... 109
6.22 MisMatchRejection - tsmt.022.001.02 ......................................................................... 109
6.23 MisMatchRejectionNotification - tsmt.023.001.03 ...................................................... 110
6.24 ActionReminder - tsmt.024.001.04 .............................................................................. 111
6.25 StatusChangeNotification - tsmt.025.001.03................................................................ 111
6.26 StatusChangeRequest - tsmt.025.001.03 ...................................................................... 112
6.27 StatusChangeRequestAcceptance - tsmt.027.001.02 ................................................... 112
6.28 StatusChangeRequestNotification - tsmt.028.001.03 ................................................... 113
6.29 StatusChangeRequestRejection - tsmt.029.001.02....................................................... 113
6.30 StatusChangeRequestRejectionNotification - tsmt.030.001.03 ................................... 114
6.31 StatusExtensionRequestAcceptance - tsmt.031.001.03................................................ 114
6.32 StatusExtensionNotification - tsmt.032.001.03 ............................................................ 115
6.33 StatusExtensionRequestRejection - tsmt.033.001.03 ................................................... 116

Message Definition Report Part 1 Page 3

Trade Services Management November 2015

6.34 StatusExtensionRejectionNotification - tsmt.034.001.03............................................. 116

6.35 StatusExtensionRequest - tsmt.035.001.03 .................................................................. 117
6.36 StatusExtensionRequestNotification - tsmt.036.001.03 ............................................... 117
6.37 StatusReport - tsmt.037.001.03 .................................................................................... 118
6.38 StatusReportRequest - tsmt.038.001.03 ....................................................................... 118
6.39 TimeOutNotification - tsmt.040.001.03 ....................................................................... 118
6.40 TransactionReport - tsmt.041.001.03 ........................................................................... 119
6.41 TransactionReportRequest - tsmt.042.001.03 .............................................................. 120
6.42 IntentToPayNotification - tsmt.044.001.02 .................................................................. 120
6.43 ForwardIntentToPayNotification - tsmt.045.001.02 .................................................... 121
6.44 IntentToPayReport - tsmt.046.001.01 .......................................................................... 122
6.45 SpecialRequest - tsmt.047.001.01 ................................................................................ 122
6.46 SpecialNotification - tsmt.048.001.01 .......................................................................... 123
6.47 RoleAndBaselineAcceptance - tsmt.049.001.01 .......................................................... 123
6.48 RoleAndBaselineRejection - tsmt.050.001.01 ............................................................. 124
6.49 RoleAndBaselineAcceptanceNotification - tsmt.051.001.01 ....................................... 124
6.50 RoleAndBaselineRejectionNotification - tsmt.052.001.01 .......................................... 124

Page 4 Message Definition Report Part 1

Introduction

1. Introduction

1.1 Terms and definitions

The following terms are reserved words defined in ISO 20022 Edition 2013 – Part1. When used in this
document, they will be in italic and follow the UpperCamelCase notation.

Term Definition

BusinessRole functional role played by a business actor in a particular BusinessProcess

or BusinessTransaction
Participant involvement of a BusinessRole in a BusinessTransaction

unrealized definition of the business activities undertaken by BusinessRoles

BusinessProcess within a BusinessArea whereby each BusinessProcess fulfils one type of
business activity and whereby a BusinessProcess may include and extend
other BusinessProcesses
particular solution that meets the communication requirements and the
BusinessTransaction interaction requirements of a particular BusinessProcess and
BusinessArea

MessageDefinition formal description of the structure of a message instance

1.2 Glossary
Acronyms

Acronym Definition

TSU Trade Services Utility

Abbreviations

Abbreviation Definition
ACK Acknowledgement

20 February 2015 Page 5

Trade Services Management November 2015

1.3 Document Scope and Objectives

This document is the first part of the SWIFT Message Definition Report (MDR) that describes the
BusinessTransactions and underlying message set. For the sake of completeness, the document may
also describe BusinessActivities that are not in the scope of the project.
This document describes the following:
• The BusinessProcess scope (business processes addressed or impacted by the project)
• The BusinessRoles involved in these BusinessProcesses
The main objectives of this document are as follows:
• To explain what BusinessProcesses and BusinessActivities these MessageDefinitions have
addressed
• To give a high level description of BusinessProcesses and the associated BusinessRoles
• To document the BusinessTransactions and their Participants (sequence diagrams)
• To list the MessageDefinitions

1.4 References

Document Version Date Author

ISO 20022 Business Justification (RA ID: 7) Trade Services July 2008 11 April 2008 SWIFT
Management

Page 6 Message Definition Report Part 1

Scope and Functionality

2. Scope and Functionality

2.1 Background
This Message Definition Report covers a set of 50 MessageDefinitions developed by SWIFT and
approved by the Trade Services Standards Evaluation Group (SEG) on 29 January 2014.

2.2 Scope
This set of messages is specifically designed to support a centralised trade transaction matching utility.
The flows and the processes leading to these flows are detailed in the following chapters.

2.3 Groups of MessageDefinitions and Functionality

For the scope of each message, please refer to MDR part 2. The messages are designed to be used
without Business Application Header (BAH) and can be grouped as shown in the table below:
Message name Message Identifier
Baseline Establishment

InitialBaselineSubmission tsmt.019.001.xx

FullPushThroughReport tsmt.018.001.xx
BaselineMatchReport tsmt.010.001.xx
BaselineReSubmission tsmt.012.001.xx
Baseline Amendment

BaselineAmendmentRequest tsmt.009.001.xx

AmendmentAcceptance tsmt.005.001.xx

AmendmentAcceptanceNotification tsmt.006.001.xx

AmendmentRejection tsmt.007.001.xx
AmendmentRejectionNotification tsmt.008.001.xx

DeltaReport tsmt.015.001.xx
Data Set Submission
DataSetSubmission tsmt.014.001.xx
ForwardDataSetSubmissionReport tsmt.017.001.xx
DataSetMatchReport tsmt.013.001.xx
BaselineReport tsmt.011.001.xx
MisMatchAcceptance tsmt.020.001.xx
MisMatchAcceptanceNotification tsmt.021.001.xx
MisMatchRejection tsmt.022.001.xx
MisMatchRejectionNotification tsmt.023.001.xx
Intent To Pay
IntentToPayNotification tsmt.044.001.xx
ForwardIntentToPayNotification tsmt.045.001.xx
IntentToPayReport tsmt.046.001.xx

20 February 2015 Page 7

Trade Services Management November 2015

Message name Message Identifier

Messages specific to secondary banks
RoleAndBaselineAcceptance tsmt.049.001.xx
RoleAndBaselineRejection tsmt.050.001.xx
RoleAndBaselineAcceptanceNotification tsmt.051.001.xx
RoleAndBaselineRejectionNotification tsmt.052.001.xx
Status Change and Extension
StatusChangeNotification tsmt.025.001.xx
StatusChangeRequest tsmt.026.001.xx
StatusChangeRequestAcceptance tsmt.027.001.xx
StatusChangeRequestNotification tsmt.028.001.xx
StatusChangeRequestRejection tsmt.029.001.xx
StatusChangeRequestRejectionNotification tsmt.030.001.xx
StatusExtensionRequestAcceptance tsmt.031.001.xx
StatusExtensionNotification tsmt.032.001.xx
StatusExtensionRequestRejection tsmt.033.001.xx
StatusExtensionRejectionNotification tsmt.034.001.xx
StatusExtensionRequest tsmt.035.001.xx
StatusExtensionRequestNotification tsmt.036.001.xx
Reports
ActivityReportRequest tsmt.003.001.xx
ActivityReport tsmt.002.001.xx
ActivityReportSetUpRequest tsmt.004.001.xx
StatusReportRequest tsmt.038.001.xx
StatusReport tsmt.037.001.xx
TransactionReportRequest tsmt.042.001.xx
TransactionReport tsmt.041.001.xx
Miscellaneous
Acknowledgement tsmt.001.001.xx
ErrorReport tsmt.016.001.xx
SpecialRequest tsmt.047.001.xx
SpecialNotification tsmt.048.001.xx
ActionReminder tsmt.024.001.xx
TimeOutNotification tsmt.040.001.xx

Page 8 Message Definition Report Part 1

BusinessRoles and Participants

3. BusinessRoles and Participants

A BusinessRole represents an entity (or a class of entities) of the real world, physical or legal, a person,
a group of persons, a corporation. Examples of BusinessRoles: “Financial Institution”, “ACH”, “CSD”.
A Participant is a functional role performed by a BusinessRole in a particular BusinessProcess or
BusinessTransaction: for example the “user” of a system, “debtor”, “creditor”, “investor” etc.
The relationship between BusinessRoles and Participants is many-to-many. One BusinessRole (that is, a
person) can be involved as different Participants at different moments in time or at the same time: "user",
"debtor”, "creditor", "investor", etc. Different BusinessRoles can be involved as the same Participant.

Participants and BusinessRoles definitions

Description Definition
Participants
Buyer’s Bank Bank of the buyer. The Buyer’s Bank may also be an Obligor Bank.
Seller’s Bank Bank of the seller. The Seller’s Bank is also the Recipient Bank of the
BPO.
Submitting Bank Involved Bank whose only role is to submit one or more Data Sets
required by an Established Baseline.
BusinessRoles

20 February 2015 Page 9

Trade Services Management November 2015

4. BusinessProcess Description

4.1 Trade Services Management

This diagram pictures the high level BusinessProcesses covered by this project. These high level
BusinessProcesses, if necessary, can be further split down into more detailed BusinessProcesses during
the business modelling phase. The aim of the below is to describe the high-level scope of the project, not
to be exhaustive.

Baseline Submission:
Definition: Process which leads to the establishment of the Baseline. During the process, the
involved parties submit copies of the baseline and the TMA will match them, until all the parties
agree to the same version of the baseline, which is called “established baseline”
Baseline Amendment:
Definition: Process by which a primary party in the transaction can propose a change
(amendment) to the Baseline, and by which the other parties are consulted to see if they agree
or not to this change. If all of them agree, the baseline is amended. If one of them disagrees, the
baseline is not changed and remains as it was before the start of the process.
Data Set Submission:
Definition: Process by which the parties responsible to submit data sets do so, and by which the
TMA will compare the data sets between themselves and against the baseline and report the
result of the comparison in a match report. If mismatches are found, they must be accepted or
rejected.
Intent To Pay:
Definition: Process by which the buyer informs the seller, through the buyer’s and the seller’s
bank, that it intends to pay a specified amount, at a certain date, in relation to one or several
baselines.

Page 10 Message Definition Report Part 1

BusinessProcess Description

Status Extension and Change:

Definition: Process by which one party in the transaction can request to extend or change the
status of the transaction, and by which the other parties are consulted to see if they accept or
reject this extension or change. If all of them agree, the status is extended or changed. If one of
them disagrees, the status is not changed and remains as it was before the start of the process.
Reporting:
Definition: Process by which a party to the transaction can request a report to the TMA and
receive the report back.

20 February 2015 Page 11

Trade Services Management November 2015

5. BusinessTransactions
This section describes the message flows. It shows the typical exchanges of information in the context of
a BusinessTransaction.

5.1 Successful transaction establishment scenario - lodge

This scenario describes a successful establishment of a transaction in the lodge mode in the matching
application.

• Bank 1 submits an InitialBaselineSubmission message to the matching application with the

instruction lodge.
• After the matching application has successfully performed compliance and consistency check on
the message (InitialBaselineSubmission message), it submits an Acknowledgement message to
bank 1 (submitter of the InitialBaselineSubmisssion message) to indicate that the transaction has
been successfully established and that it is in the state established.

Bank 1 : TSU :
FinancialInstApp SystemApplication

InitialBaselineSubmission (Code:LODGE)

Acknowledgement

5.2 Successful transaction establishment scenario – push-through

This scenario describes a successful establishment of a transaction in the push-through mode in the
matching application.

• Bank 1 submits an InitialBaselineSubmission message to the matching application with the

instruction push-through.
• After the matching application has successfully performed compliance and consistency check on
the message (InitialBaselineSubmission message), it submits an Acknowledgement message to
bank 1 (submitter of the InitialBaselineSubmission message) and forwards the baseline
information to the counterparty (FullPushThroughReport).
• Bank 2 (counterparty) submits matching baseline information (BaselineReSubmission message).
• After the matching application has successfully performed compliance and consistency check on
the message (BaselineReSubmission message) it compares the baseline information it has
received from both parties.
It forwards the baseline information to bank 1 (FullPushThrough message) and submits a
notification (BaselineMatchReport message) about the successful match to both parties. The
transaction goes to the status established.

Page 12 Message Definition Report Part 1

BusinessTransactions

Bank 1 : TSU : Bank 2 :

FinancialInstApp SystemApplication FinancialInstApp

InitialBaselineSubmission
Acknowledgement FullPushThroughReport

BaselineReSubmission

FullPushThroughReport
BaselineMatchReport (0 MisMatch) BaselineMatchReport (0 MisMatch)

5.3 Unsuccessful transaction establishment scenario – lodge

This scenario describes the unsuccessful establishment of a transaction in the lodge mode in the
matching application.

• Bank 1 submits the InitialBaselineSubmission message to the matching application with the
instruction lodge.
• The matching application sends back an ErrorReport message because the
InitialBaselineSubmission message failed the compliance/consistency check performed by the
matching application.

Bank 1 has to submit a new InitialBaselineSubmission message until it achieves a successful

establishment. No transaction (identified by a Transaction Identification) is registered in the matching
application when the initiation fails.

Bank 1 : TSU :
FinancialInstApp SystemApplication

InitialBaselineSubmission (Code:LODGE)
ErrorReport

20 February 2015 Page 13

Trade Services Management November 2015

5.4 Unsuccessful transaction establishment scenario – push-through

This scenario describes the unsuccessful establishments of a transaction in the push-through mode in
the matching application.

Example 1

• Bank 1 submits an InitialBaselineSubmission message to the matching application with the

instruction push-through.
• The matching application sends back an ErrorReport message because the
InitialBaselineSubmission message failed the compliance/consistency check performed by the
matching application.

Bank 1 has to submit a new InitialBaselineSubmission message until it achieves a successful registration
of the transaction in the matching application. No transaction (identified by a Transaction Identification) is
registered in the matching application when the initiation fails.

Example 2

• Bank 1 submits an InitialBaselineSubmission message to the matching application with the

instruction push-through.
• After the matching application has successfully performed compliance and consistency check on
the message (InitialBaselineSubmission message), it submits an Acknowledgement message to
bank 1 (submitter of the InitialBaselineSubmission message) and forwards the baseline
information to the counterparty (FullPushThroughReport).
• Bank 2 (counterparty) submits baseline information (BaselineReSubmission message).
• The matching application rejects the baseline information (ErrorReport message) because the
core data elements of the submitted baseline information (BaselineReSubmission message) do
not match with the registered baseline information (InitialBaselineInformation message).

Bank 2 has to re-submit baseline information (BaselineReSubmisssion message) with matching core
data elements in order to establish a transaction in the matching application with the status partially
matched.

Example 3

• Bank 1 submits an InitialBaselineSubmission message to the matching application with the

Before a transaction is established, that is, in the status proposed or partially matched, both parties can
close the transaction unilaterally.

Page 14 Message Definition Report Part 1

BusinessTransactions

Bank 1 : TSU : Bank 2 :

FinancialInstApp SystemApplication FinancialInstApp
Example 1

InitialBaselineSubmission
ErrorReport

Example 2

InitialBaselineSubmission
Acknowledgement FullPushThroughReport

BaselineReSubmission

ErrorReport

Example 3

InitialBaselineSubmission

Acknowledgement FullPushThroughReport

StatusChangeRequest (Code: CLOSE)

StatusChangeNotification (Code: CLOSE) StatusChangeNotification (Code: CLOSE)

5.5 Unsuccessful transaction establishment scenario – duplicate

transaction

This scenario describes the unsuccessful attempt to establish twice the same push-through transaction
in the matching application.

• Bank 1 submits an InitialBaselineSubmission message to the matching application with the

instruction push-through.
• After the matching application has successfully performed compliance and consistency check on
the message (InitialBaselineSubmission message), it submits an Acknowledgement message to
bank 1 (submitter of the InitialBaselineSubmission message) and forwards the baseline
information to the counterparty (FullPushThroughReport).
• Bank 2 (counterparty) submits an InitialBaselineSubmission message to the matching application
with the instruction push-through and the exact same core data elements as the baseline
information sent by bank 1.
• The matching application rejects (ErrorReport message) the baseline information sent by bank 2
because the same transaction cannot be established twice in the matching application. In case

20 February 2015 Page 15

Trade Services Management November 2015

bank 1 would try to initiate a second time a transaction with the same core data, the matching
application would similarly reject the second initiation.

Please note that the same transaction can be established several times in the lodge mode.

Bank 1 : TSU : Bank 2 :

FinancialInstApp SystemApplication FinancialInstApp

Example 1

InitialBaselineSubmission

Acknowledgement FullPushThroughReport

InitialBaselineSubmission
ErrorReport

5.6 Baseline Establishment: Baseline mismatch scenario

This scenario describes possible message flows for the establishment of a transaction after the matching
application has detected mismatches in the submitted baseline information.

• Bank 1 submits an InitialBaselineSubmission message to the matching application with the

instruction push-through.
• After the matching application has successfully performed compliance and consistency check on
the message (InitialBaselineSubmission message), it submits an Acknowledgement message to
bank 1 (submitter of the InitialBaselineSubmission message) and forwards the baseline
information to the counterparty (FullPushThroughReport).
• Bank 2 (counterparty) submits baseline information (BaselineReSubmission message).
• After the matching application has successfully performed compliance and consistency check on
the message (BaselineReSubmission message), it compares the baseline information it has
received from both parties.

It forwards the baseline information of bank 2 to bank 1 (FullPushThroughReport message) and

notifies both parties about the inconsistencies it has detected between the two sets of baseline
information (BaselineMatchReport message).

After both parties have been informed about the mismatches either bank 1 or bank 2 can re-submit the
baseline.

Example A

• Bank 1 re-submits corrected baseline information (BaselineReSubmission message).

• After the matching application has successfully performed compliance and consistency check on
the message (BaselineReSubmission message), it compares the re-submitted baseline
information with the earlier submitted baseline information of bank 2.

Page 16 Message Definition Report Part 1

BusinessTransactions

It forwards the baseline information of bank 1 to bank 2 (FullPushThroughReport message) and

submits a notification (BaselineMatchReport message) about the successful match to both
parties. The transaction goes to the status established.

Example B

• Bank 2 (submitter of the first BaselineReSubmission message) re-submits corrected baseline

information (BaselineReSubmission message).
• After the matching application has successfully performed compliance and consistency check on
the message (BaselineReSubmission message), it compares the re-submitted baseline
information with the earlier submitted baseline information of bank 1.

It forwards the baseline information of bank 2 to bank 1 (FullPushThroughReport message) and

submits a notification (BaselineMatchReport message) about the successful match to both
parties. The transaction goes to the status established.

Example C

• Bank 1 re-submits corrected baseline information (BaselineReSubmission message).

It forwards the baseline information of bank 1 to bank 2 (FullPushThroughReport message) and

notifies both parties about the inconsistencies it has detected between the earlier submitted
baseline information of bank 2 and the re-submitted baseline information of bank 1.

• Bank 2 re-submits corrected baseline information (BaselineReSubmission message).

• After the matching application has successfully performed compliance and consistency check on
the message (BaselineReSubmission message), it compares the re-submitted baseline
information of bank 2 with the earlier re-submitted baseline information of bank 1.

It forwards the baseline information of bank 2 to bank 1 (FullPushThroughReport message) and

submits a notification (BaselineMatchReport message) about the successful match to both
parties. The transaction goes to the status established.

Example D

• Bank 2 re-submits corrected baseline information (BaselineReSubmission message).

• After the matching application has successfully performed compliance and consistency check on
the message (BaselineReSubmission message), it compares the re-submitted baseline
information of bank 2 with the earlier submitted baseline information of bank 1.

Because the matching application detects inconsistencies between the baseline and because
the number of possible establishment trials has been reached, it notifies both parties about the
closure of the transaction (StatusChangeNotification message).

20 February 2015 Page 17

Trade Services Management November 2015

Bank 1 : TSU : Bank 2 :

FinancialInstApp SystemApplication FinancialInstApp
InitialBaselineSubmission

Acknowledgement FullPushThroughReport

BaselineReSubmission

FullPushThroughReport

BaselineMatchReport (with MisMatches) BaselineMatchReport (with MisMatches)

A re-submission of a corrected baseline can be initiated by either party.

Example A:

BaselineReSubmission

FullPushThroughReport

BaselineMatchReport (0 MisMatch) BaselineMatchReport (0 MisMatch)

Example B:

BaselineReSubmission

FullPushThroughReport

BaselineMatchReport (0 MisMatch) BaselineMatchReport (0 MisMatch)

Example C:

BaselineReSubmission

FullPushThroughReport

BaselineMatchReport (with MisMatches) BaselineMatchReport (with MisMatches)

BaselineReSubmission

FullPushThroughReport
BaselineMatchReport (0 MisMatch) BaselineMatchReport (0 MisMatch)

Example D:
Limit reached and no match
BaselineReSubmission

StatusChangeNotification (Code: CLOSE) StatusChangeNotification (Code: CLOSE)

5.7 Successful transaction establishment with secondary bank scenario -

lodge

This scenario describes a successful establishment of a transaction in the lodge mode in presence of a
secondary bank.

• Bank 1 submits an InitialBaselineSubmission message to the matching application with the

Page 18 Message Definition Report Part 1

BusinessTransactions

bank 1 (submitter of the InitialBaselineSubmisssion message) to indicate that the transaction has
been processed and that it is still in the state partially matched, because another bank must
approve it.
• The matching application forwards a copy of the baseline to bank 3, in a FullPushThroughReport
message.
• Bank 3 accepts the baseline and its role by sending a RoleAndBaselineAcceptance message.
• The matching application sends back an Acknowledgement to bank 3 and notifies bank 1 of the
acceptance by sending a RoleAndBaselineAcceptanceNotification message. In these messages,
the status of the baseline is indicated as established.

Bank 1 : Financi al InstApp Bank 3 : Financi al InstApp TSU : SystemApplicati on

InitialBaselineSubmisson (code=LODGE)

Acknowledgement

FullPushThroughReport

RoleAndBaselineAcceptance

Acknowledgement

RoleAndBaselineAcceptanceNotification

5.8 Successful transaction establishment with secondary bank scenario –

push-through

This scenario describes a successful establishment of a transaction in the push-through mode in

presence of a secondary bank. Bank 1 and 2 are the primary banks. Bank 3 is a secondary bank
(submitting or obligor), included in the baseline.

• Bank 1 submits an InitialBaselineSubmission message to the matching application with the

It forwards the baseline information to bank 1 (FullPushThrough message) and submits a

notification (BaselineMatchReport message) about the successful match to both parties.

20 February 2015 Page 19

Trade Services Management November 2015

Case 1

• Bank 3 accepts its role and the baseline by sending a RoleAndBaselineAcceptance message
• The matching application sends a BaselineAcceptanceNotification to notify the two primary
banks.

Baseline is now established.

Case 2

• Bank 3 rejects its role and the baseline by sending a RoleAndBaselineRejection message
• The matching application sends a BaselineAcceptanceNotification to notify the two primary
banks.

Baseline stays in partially matched status. Primary banks will have to agree on another baseline or close
the transaction.

Page 20 Message Definition Report Part 1

BusinessTransactions

TSU : Bank 2 :
Bank 1 : Bank 3 : SystemApplication FinancialInstApp
FinancialInstApp FinancialInstApp

InitialBaselineSubmission

Acknowledgement FullPushThroughReport

FullPushThroughReport BaselineReSubmission

BaselineMatchReport (0 MisMatch) BaselineMatchReport (0 MisMatch)

FullPushThroughReport

Case 1: Acceptance of
Role and Baseline

RoleAndBaselineAcceptance

Acknowledgement

RoleAndBaselineAcceptanceNotification

Case 2: Rejection of Role

and Baseline

RoleAndBaselineRejection

Acknowledgement

RoleAndBaselineRejectionNotification

5.9 Successful transaction establishment with secondary bank scenario –

several secondary banks

This scenario describes a successful establishment of a transaction in the push-through mode in

presence of several secondary banks. Bank 1 and 2 are the primary banks. Bank 3 and 4 are secondary
banks (submitting or obligor), included in the baseline.

• Bank 1 submits an InitialBaselineSubmission message to the matching application with the

instruction push-through.

20 February 2015 Page 21

Trade Services Management November 2015

• After the matching application has successfully performed compliance and consistency check on
the message (InitialBaselineSubmission message), it submits an Acknowledgement message to
bank 1 (submitter of the InitialBaselineSubmission message) and forwards the baseline
information to the counterparty (FullPushThroughReport).
• Bank 2 (counterparty) submits matching baseline information (BaselineReSubmission message).
• After the matching application has successfully performed compliance and consistency check on
the message (BaselineReSubmission message) it compares the baseline information it has
received from both parties.

It forwards the baseline information to bank 1 (FullPushThrough message) and submits a

notification (BaselineMatchReport message) about the successful match to both parties.

Case 1

In case 1, each primary bank and banks 3 and 4 accept one after the other its role and the baseline, and
matching application sends in each case a RoleAndBaselineAcceptanceNotification to notify the three
other banks. Baseline is now established. Please note that there is no defined order in the sending of the
different RoleAndBaselineAcceptanceNotification, they are sent in any order by the matching application.

Case 2

In case 2, bank 4 accepts and bank 3 rejects its role and the baseline. After bank 4 response, matching
application sends a RoleAndBaselineAcceptanceNotification to notify the three other banks. After bank 3
response, matching application sends a RoleAndBaselineRejectionNotification to notify the three other
banks. Baseline stays in partially matched status. Primary banks will have to agree on another baseline
or close the transaction.

Page 22 Message Definition Report Part 1

BusinessTransactions

TSU : Bank4 : Bank 2 :

Bank 1 : Bank 3 : SystemApplication FinancialInstApp
FinancialInstApp FinancialInstApp FinancialInstApp

InitialBaselineSubmission

Acknowledgement FullPushThroughReport

FullPushThroughReport BaselineReSubmission

BaselineMatchReport (0 MisMatch) BaselineMatchReport (0 MisMatch)

FullPushThroughReport

Case 1: Acceptance of
Role and Baseline by both

RoleAndBaselineAcceptance

Acknowledgement

RoleAndBaselineAcceptanceNotification

RoleAndBaselineAcceptance

Acknowledgement

RoleAndBaselineAcceptanceNotification

Case 2: Acceptance by
one, rejection by the other.
RoleAndBaselineAcceptance

Acknowledgement

RoleAndBaselineAcceptanceNotification

RoleAndBaselineRejection

Acknowledgement

RoleAndBaselineRejectionNotification

20 February 2015 Page 23

Trade Services Management November 2015

5.10 Baseline Establishment: Closure of not yet established push-through

transactions scenario
This scenario describes possible message flows for the closure of not yet established push-through
transactions.

A push-through transaction can be closed unilaterally (by a primary party) before it reaches the status
established.

Example A

• Bank 1 submits an InitialBaselineSubmission message to the matching application with the

Example B

• Bank 1 submits an InitialBaselineSubmission message to the matching application with the

instruction push-through.
• After the matching application has successfully performed compliance and consistency check on
the message (InitialBaselineSubmission message), it submits an Acknowledgement message to
bank 1 (submitter of the InitialBaselineSubmission message) and forwards the baseline
information to the counterparty (FullPushThroughReport).
• Bank 2 (counterparty) submits baseline information (BaselineReSubmission message).
• After the matching application has successfully performed compliance and consistency check on
the message (BaselineReSubmission message), it compares the baseline information it has
received from both parties.

It forwards the baseline information of bank 2 to bank 1 (FullPushThroughReport message) and

notifies both parties about the inconsistencies it has detected between the two baselines
(BaselineMatchReport message).

• Bank 1 submits the instruction to close the transaction (StatusChangeRequest message).

• The matching application notifies both parties about the closure of the transaction
(StatusChangeNotification message).

Page 24 Message Definition Report Part 1

BusinessTransactions

Bank 1 :
FinancialInstApp TSU : Bank 2 :
SystemApplication FinancialInstApp
Status of baseline is: proposed/partially matched

Example A:
Closure before reaction of counterparty

InitialBaselineSubmission

Acknowledgement FullPushThroughReport

StatusChangeRequest (Code: CLOSE)

StatusChangeNotification (CLOSE) StatusChangeNotification (CLOSE)

Example B:
Closure of partially matched baseline

InitialBaselineSubmission

Acknowledgement FullPushThroughReport

BaselineReSubmission
FullPushThroughReport

BaselineMatchReport (with MisMatches) BaselineMatchReport (with MisMatches)

StatusChangeRequest (CLOSE)

StatusChangeNotification (CLOSE) StatusChangeNotification (CLOSE)

5.11 Baseline Establishment: Prohibited instructions scenario

This scenario describes instructions which are prohibited and will be rejected by the matching application
during the pre-establishment phase of the transaction, that is, when a transaction is registered in the
matching application but is not yet in the status established.

20 February 2015 Page 25

Trade Services Management November 2015

• Bank 1 submits an InitialBaselineSubmission message to the matching application with the

instruction push-through.
• After the matching application has successfully performed compliance and consistency check on
the message (InitialBaselineSubmission message), it submits an Acknowledgement message to
bank 1 (submitter of the InitialBaselineSubmission message) and forwards the baseline
information to the counterparty (FullPushThroughReport).
• The transaction is now in the status proposed. In this pre-establishment phase the following
instructions (messages) are prohibited:
• match of data sets (DataSetSubmission message with instruction match)
• pre-match of data sets (DataSetSubmission message with instruction pre-match)
• request to amend the baseline (BaselineAmendmentRequest message)
• request to re-activate the transaction (StatusChangeRequest message)
• request to complete the transaction (StatusChangeRequest message)

This diagram does not show all prohibited instructions (messages).

Bank 1 : TSU : Bank 2 :

FinancialInstApp SystemApplication FinancialInstApp

InitialBaselineSubmission

Acknowledgement FullPushThroughReport

DataSetSubmission (Code: MATCH)

ErrorReport

BaselineAmendmentRequest

ErrorReport

5.12 Data Set Submission: Data set pre-match scenario

This scenario describes possible message flows for the pre-match of data sets.

A pre-match of data sets does not change the status of a transaction and only the submitter of the data
sets is notified about the match result.

• Bank 1 submits data sets for pre-match to the matching application (DataSetSubmission
message).
• After the matching application has successfully performed compliance and consistency check on
the message (DataSetSubmission message), it compares the data sets with the related baseline
information.

Page 26 Message Definition Report Part 1

BusinessTransactions

It notifies bank 1 (submitter of the data sets for pre-match) about the result of the comparison it
has performed (BaslelineMatchReport message). The BaselineMatchReport message will either
show 0 (zero) mismatches or list the mismatches it found.

Bank 1 : Bank 2 :
FinancialInstApp TSU : FinancialInstApp
SystemApplication
Status of baseline: Established / Active

DataSetSubmission (Code: PREMATCH)

DataSetMatchReport

NO change of Status

DataSetSubmission (Code: PREMATCH)

DataSetMatchReport

NO change of Status

5.13 Data Set Submission: Data set match in the push-through mode
scenario

This scenario describes possible message flows for the match of data sets for transactions established in
the push-through mode.

Only the party identified in the baseline as submitter of data sets can submit data sets for match. A
match of data sets might change the status of a transaction and both parties to a transaction are notified
about the match result.

Example A

• Bank 1 submits data sets for match to the matching application (DataSetSubmission message).
• After the matching application has successfully performed compliance and consistency check on
the message (DataSetSubmission message), it compares the data sets with the related baseline
information.

It forwards the data sets to bank 2 (ForwardDataSetSubmissionReport message).

Furthermore, it submits a notification about the successful match (DataSetMatchReport

message) as well as a report on the calculation of the dynamic part of the established baseline
(BaselineReport message) to both parties.

Example B1

20 February 2015 Page 27

Trade Services Management November 2015

It forwards the data sets to bank 2 (ForwardDataSetSubmissionReport message) and notifies

both parties about the inconsistencies it has detected between the data sets and the related
baseline (DataSetMatchReport message). Bank 2 is requested to either accept or reject the data
sets.

• Bank 2 accepts the mismatched data sets and sends a notice of acceptance to the matching
application (MisMatchAcceptance message).
• After the matching application has successfully performed compliance and consistency check on
the message (MisMatchAcceptance message), it notifies bank 1 about the acceptance of the
mismatched data sets (MisMatchAcceptanceNotification message).

Furthermore, it submits a report on the final calculation of the dynamic part of the established
baseline (BaselineReport message) to both parties.

Example B2

It forwards the data sets to bank 2 (ForwardDataSetSubmissionReport message) and notifies

both parties about the inconsistencies it has detected between the data sets and the related
baseline (DataSetMatchReport message). Bank 2 is requested to either accept or reject the data
sets.

• Bank 2 rejects the mismatched data sets and sends a notice of rejection to the matching
application (MisMatchRejection message).
• After the matching application has successfully performed compliance and consistency check on
the message (MisMatchRejection message), it submits an Acknowledgement message about the
receipt of the rejection to bank 2 and notifies bank 1 about the rejection of the mismatched data
sets (MisMatchRejectionNotification message).

In case data sets are submitted for match against multiple transactions (multiple Transaction Identifiers
specified in one DataSetSubmission message), there will be as many flows of subsequent messages as
there are transactions (Transaction Identifiers) specified. That is as many BaselineReport messages, and
DataSetMatchReport messages will be sent by the matching application as transactions are specified
(but always one ForwardDataSetSubmissionReport message). Each DataSetMatchReport conveying
mismatches has to be accepted or rejected.

Page 28 Message Definition Report Part 1

BusinessTransactions

Bank 1 : TSU : Bank 2 :

FinancialInstApp SystemApplication FinancialInstApp

Baseline is Established

Example A:
no mismatches

DataSetSubmission (Code: MATCH)

BaselineReport ForwardDataSetSubmissionReport
BaselineReport
DataSetMatchReport (with zero MisMatches) DataSetMatchReport (with zero MisMatches)

Status changed to Active

Example B1:
mismatches - accepted

DataSetSubmission (Code: MATCH)

ForwardDataSetSubmissionReport
DataSetMatchReport (with MisMatches) DataSetMatchReport (with MisMatches)

MisMatchAcceptance

MisMatchAcceptanceNotification BaselineReport
BaselineReport

Status changed to Active

Example B2:
mismatches rejected

DataSetSubmission (Code: MATCH)

ForwardDataSetSubmissionReport

DataSetMatchReport (with MisMatches) DataSetMatchReport (with MisMatches)

MisMatchRejection

MisMatchRejectionNotification Acknowledgement

NO change of Status

5.14 Data Set Submission: Data set match for transactions initiated in the
lodge mode scenario

This scenario describes possible message flows for the match of data sets for transactions established in
the lodge mode.

20 February 2015 Page 29

Trade Services Management November 2015

Example A

It submits a notification (DataSetMatchReport message) about the successful match as well as a

report on the calculation of the dynamic part of the established baseline (BaselineReport
message) to bank 1 (submitter of the data sets for match).

Example B1

It notifies bank 1 (submitter of the data sets for match) about the inconsistencies it has detected
between the data sets and the related baseline (DataSetMatchReport message). Bank 1 is
requested to either accept or reject the data sets.

• Bank 1 accepts the mismatched data sets and sends a notice of acceptance to the matching
application (MisMatchAcceptance message).
• After the matching application has successfully performed compliance and consistency check on
the message (MisMatchAcceptance message), it acknowledges the receipt of the acceptance of
the mismatched data sets by submitting a report on the calculation of the dynamic part of the
established baseline (BaselineReport message) to bank 1.

Example B2

• Bank 1 rejects the mismatched data sets and sends a notice of rejection to the matching
application (MisMatchRejection message).
• After the matching application has successfully performed compliance and consistency check on
the message (MisMatchRejection message), it acknowledges the receipt of the rejection of the
mismatched data sets (MisMatchRejectionNotification message) to bank 1.

Page 30 Message Definition Report Part 1

BusinessTransactions

Bank 1 : TSU :
FinancialInstApp SystemApplication

Baseline is Established
Lodge model (single bank)

Example A:
no mismatches

DataSetSubmission (Code: MATCH)

DataSetMatchReport (with 0 MisMatch)

BaselineReport

Status changed to Active

Example B1:
mismatches - accepted
DataSetSubmission (Code: MATCH)

DataSetMatchReport (with MisMatches)

MisMatchAcceptance
BaselineReport

Status changed to Active

Example B2:
mismatches rejected

DataSetSubmission (Code: MATCH)

DataSetMatchReport (with MisMatches)

MisMatchRejection

MisMatchRejectionNotification

NO change of Status

20 February 2015 Page 31

Trade Services Management November 2015

5.15 Data Set Submission: Data set match for transactions with secondary
bank scenario

This scenario describes possible message flows for the match of data sets for transactions involving at
least one secondary bank.

These message flows show two primary banks, bank 1 and bank 2 and one secondary bank, bank 3.
Only the party identified in the baseline as submitter of data sets can submit data sets for match.

Case A

• Bank 1 submits data-set(s) for match.

• After matching application has successfully performed the consistency check and the matching it
submits a match report (showing zero mismatches) and a baseline report to bank 1 (submitter)
and
- Forwards the data set(s) and a baseline report to bank 2
- matching application sends to bank 3 (secondary) same reports than to bank 2
- Status becomes "Active".

Note: same flows for submitting or obligor banks, they are only informed.

Case B

• Bank 1 submits data-set(s) for match.

• After matching application has performed the consistency check and matching and discovered
mismatches, it sends a (mis)match report to bank 1 (submitter)

The matching application forwards a (mis)match report plus data set(s) to bank 2 (counterparty)
requesting the acceptance or rejection of the match results. The matching application sends the
same messages, for information only, to secondary bank.

• Bank 2 accepts the match results and sends a notice of acceptance to the matching application.
At this stage, data set is accepted, but participation of secondary bank must be confirmed.
• The matching application sends MisMatchAcceptanceNotification to bank 3 and requests
confirmation (acceptance or rejection) of baseline and its role. The matching application waits for
this confirmation (transaction cannot proceed without it)

The matching application sends a baseline report to all banks.

Case B1

• Bank 3 accepts and sends a RoleAndBaselineAcceptance.

• The matching application acknowledges reception of the message.
• The matching application sends a RoleAndBaselineAcceptanceNotification to both primary
banks and a BaselineReport to all parties.

Case B2

• Bank 3 rejects and sends a RoleAndBaselineRejection.

• The matching application acknowledges reception of the message.
• The matching application sends a RoleAndBaselineRejectionNotification to both primary banks.

NOTE: these are the flows for Obligor bank. Submitting bank is only informed and has no option to
accept/reject baseline and role.

Case C

Page 32 Message Definition Report Part 1

BusinessTransactions

• Bank 1 submits data-set(s) for match.

• After matching application has performed the consistency check and matching and discovered
mismatches, it sends a (mis)match report to bank 1 (submitter)
• The matching application forwards a (mis)match report plus data set(s) to bank 2 (counterparty)
requesting the acceptance or rejection of the match results. The matching application sends the
same messages, for information only, to secondary bank.
• Bank 2 rejects the results and sends a notice of rejection incl. reason(s) for the rejection to the
matching application.
• The matching application sends an acknowledgement about the rejection to bank 2 and a
notification about the rejection of the match results to bank 1 (submitter)
• The matching application sends the MisMatchRejectionNotification message for information (no
action) to the secondary bank.

A baseline report is sent only after acceptance of match results (not after rejection).

20 February 2015 Page 33

Trade Services Management November 2015

Bank 1 : Bank 3 : TSU : Bank 2 :

FinancialInstApp FinancialInstApp SystemApplication FinancialInstApp

Case A: Immediate Match

DataSetSubmission (Code: MATCH)

BaselineReport ForwardDataSetSubmissionReport
BaselineReport
DataSetMatchReport (0 Mismatch) DataSetMatchReport (0 Mismatch)

ForwardDataSetSubmissionReport

BaselineReport

DataSetMatchReport (0 Mismatch)

Case C: mismatches and

rejection by primary

DataSetSubmission (Code: MATCH) ForwardDataSetSubmissionReport

DataSetMatchReport (Mismatches) DataSetMatchReport (Mismatches)

ForwardDataSetSubmissionReport

DataSetMatchReport (Mismatch)

MisMatchRejection

MisMatchRejectionNotification Acknowledgement

MisMatchRejectionNotification

Page 34 Message Definition Report Part 1

BusinessTransactions

Bank 1 : Bank 3 : TSU : Bank 2 :

FinancialInstApp FinancialInstApp SystemApplication FinancialInstApp

Case B: Mismatches and

acceptance by primary

DataSetSubmission (Code: MATCH)

ForwardDataSetSubmissionReport

DataSetMatchReport (Mismatches)
DataSetMatchReport (Mismatches)

ForwardDataSetSubmissionReport

DataSetMatchReport (Mismatches)

MisMatchAcceptance
MisMatchAcceptanceNotification

BaselineReport
BaselineReport

BaselineReport

MisMatchAcceptanceNotification

Case B1: Obligor accepts

RoleAndBaselineAcceptance

Acknowledgement

BaselineReport

RoleAndBaselineAcceptanceNotification

BaselineReport

RoleAndBaselineAcceptanceNotification

BaselineReport

Case B2: Obligor rejects

RoleAndBaselineRejection

Acknowledgement

RoleAndBaselineRejectionNotification

5.16 Data Set Submission: Data set submission - multiple baselines

scenario

In this scenario, data set(s) are submitted against multiple Baseline/PO (2 in this example) and matching
is triggered. The matching application will match the data sets against each baseline, as separate
processes. For the commercial data set, it will match the part of the data set that is relevant to the
baseline/PO against each of them.

20 February 2015 Page 35

Trade Services Management November 2015

If the DataSetSubmission message passes all consistency checks, for each baseline/PO against which
the matching application has matched the data sets, it will send a set of messages (see
DataSetSubmission against one baseline/PO).

Example A

In case of no mismatch, the submitter will receive two DataSetMatchReport messages and the other
party one ForwardDataSetSubmission (always one), and two DataSetMatchReport messages. The
DataSetMatchReport messages report 0 mismatch.

Example B

In case of mismatches against the two baselines/PO the submitter will receive two
DataSetMatchReport messages and the other party one ForwardDataSetSubmission and two
DataSetMatchReport messages. The DataSetMatchReport messages contain mismatches, and each
of them must be accepted or rejected. In this example, they are both accepted. After each
acceptance, both parties receive a BaselineReport message. Mismatches could also be both
rejected, or one accepted and one rejected.

Page 36 Message Definition Report Part 1

BusinessTransactions

TSU :
SystemApplication Bank 2 :
Bank 1 : FinancialInstApp
FinancialInstApp
Baseline is Established

Example A:
no mismatches

DataSetSubmission (PO1; PO2)

BaselineReport (PO1) ForwardDataSetSubmissionReport

BaselineReport (PO1)
DataSetMatchReport (PO1;with zero MisMatches) DataSetMatchReport (PO1; with zero MisMatches)

BaselineReport (PO2)

DataSetMatchReport (PO2; with zero MisMatches)

DataSetMatchReport (PO2;with zero MisMatches)

Example B:
mismatches

DataSetSubmission (PO1;PO2)

ForwardDataSetSubmissionReport
DataSetMatchReport (PO1; with MisMatches) DataSetMatchReport (PO1; with MisMatches)

DataSetMatchReport (PO2; with MisMatches)

Mis MatchAcceptance (PO1)

Mis MatchAcceptanceNotification (PO1)

BaselineReport (PO1)

Mis MatchAcceptance (PO2)

Mis MatchAcceptanceNotification (PO2)

BaselineReport (PO2)

20 February 2015 Page 37

Trade Services Management November 2015

5.17 Data Set Submission: Data set submission - multiple submitters

scenario
Bank 1 and 2 are the primary banks. Bank 3 is a secondary (submitting) bank, included in the baseline,
on bank 1 side. We describe a scenario for a baseline that requires 3 data sets in each submission group
and one data set must come from each party.
• Data set 1 is sent by bank 1 in a DataSetSubmission message.
• The matching application checks the consistency of the data set, forwards the data set to the
other primary bank and to the secondary bank, for information. No matching is triggered as the
matching application expects other data sets.
• Data set 2 is sent by bank 2 in a DataSetSubmission message.
• The matching application checks the consistency of the data set, forwards the data set to the
other primary bank and to the secondary bank, for information. No matching is triggered as the
matching application expects other data sets.
• Data set 3 is sent by submitting bank 3 in a DataSetSubmission message.
• The matching application checks the consistency of the data set. Matching is triggered as the
matching application has all required data sets. The matching application forwards the data set
to the other primary bank and to the secondary bank, for information. In case of full match,
matching application forwards BaselineReport and DataSetMatchReport (with 0 mismatch)
messages. In case of mismatches, they would have to be accepted or rejected by the buyer's
bank.

Page 38 Message Definition Report Part 1

BusinessTransactions

Bank 1 : Bank 3 : TSU : Bank 2 :

FinancialInstApp FinancialInstApp SystemApplication FinancialInstApp

DataSetSubmission (DS1; Code: MATCH)

Acknowledgement

ForwardDataSetSubmissionReport

DataSetSubmission (DS2; Code: MATCH)

Acknowledgement

ForwardDataSetSubmissionReport

DataSetSubmission (DS3; Code: MATCH)

BaselineReport

DataSetMatchReport (0)

ForwardDataSetSubmissionReport

DataSetMatchReport (0)

BaselineReport

DataSetMatchReport (0)

ForwardDataSetSubmissionReport

5.18 Baseline Amendment: Amendment of transactions initiated in the

push-through mode scenario

This scenario describes possible message flows for the amendment of a transaction established in the
push-through mode.

Example A

• Bank 1 submits a baseline amendment request (BaselineAmendmentRequest message) to the

20 February 2015 Page 39

Trade Services Management November 2015

amendment request to bank 1 by submitting a report listing the differences between the
established and newly proposed baseline (DeltaReport message).

Furthermore, it forwards the amendment request (FullPushThroughReport message), a report

listing the differences between the established and newly proposed baseline (DeltaReport
message) and a report on the pre-calculation of the dynamic part of the suggested baseline
(BaselineReport message) to bank 2.

• Bank 2 accepts the amendment request (AmendmentAcceptance message).

• After the matching application has successfully performed compliance and consistency check on
the message (AmendmentAcceptance message) it acknowledges the acceptance of the
amendment to bank 2 by submitting a report on the calculation of the dynamic part of the new
baseline (BaselineReport message).

Furthermore, it notifies bank 1 about the acceptance of the amendment request

(AmendmentAcceptanceNotification) and submits a report on the calculation of the dynamic part
of the new baseline (BaselineReport message) to bank 1.

Example B

• Bank 1 submits a baseline amendment request (BaselineAmendmentRequest message) to the

matching application.
• After the matching application has successfully performed compliance and consistency check on
the message (BaselineAmendmentRequest message), it acknowledges the receipt of the
amendment request to bank 1 by submitting a report listing the differences between the
established and newly proposed baseline (DeltaReport message).

Furthermore, it forwards the amendment request (FullPushThroughReport message), a report

listing the differences between the established and newly proposed baseline (DeltaReport
message) and a report on the pre-calculation of the dynamic part of the proposed baseline
(BaselineReport message) to bank 2.

• Bank 2 rejects the amendment request (AmendmentRejection message).

• After the matching application has successfully performed compliance and consistency check on
the message (AmendmentRejection message) it acknowledges the rejection of the amendment
to bank 2 (Acknowledgement).

Furthermore, it notifies bank 1 about the rejection of the amendment request

(AmendmentRejectionNotification message).

Example C

• Bank 1 submits a baseline amendment request (BaselineAmendmentRequest message) to the

matching application.
• The matching application sends back an ErrorReport message because the amendment request
(BaselineAmendmentRequest message) failed the compliance/consistency check performed by
the matching application.

Example D

• Bank 1 submits a baseline amendment request (BaselineAmendmentRequest message) to the

Page 40 Message Definition Report Part 1

BusinessTransactions

Furthermore, it forwards the amendment request (FullPushThroughReport message), a report

• Bank 2 submits a baseline amendment request (BaselineAmendmentRequest message) to the

matching application.
• The matching application sends back an ErrorReport message because the matching application
does not expect bank 2 to submit an amendment request while an amendment request
submitted by bank 1 is still pending, that is, waiting for the acceptance or rejection of the request
by bank 2.

20 February 2015 Page 41

Trade Services Management November 2015

Bank 1 : TSU : Bank 2 :

FinancialInstApp SystemApplication FinancialInstApp

Status of baseline is Established / Active

One single amendment

Example A:
Acceptance of amendment request

BaselineAmendmentRequest

FullPushThroughReport (Code: AMEND)

DeltaReport DeltaReport
BaselineReport (Code: PRECALCULATED)

AmendmentAcceptance

AmendmentAcceptanceNotification BaselineReport
BaselineReport

Example B:
Rejection of amendment request

BaselineAmendmentRequest

FullPushThroughReport (Code: AMEND)

DeltaReport DeltaReport
BaselineReport (Code: PRECALCULATED)

AmendmentRejection

AmendmentRejectionNotification Acknowledgement

Example C:
Error in amendment request

BaselineAmendmentRequest
ErrorReport

Example D:
No "cross" amendment request allowed

BaselineAmendmentRequest

FullPushThroughReport (Code: AMEND)

DeltaReport DeltaReport
BaselineReport (Code: PRECALCULATED)

BaselineAmendmentRequest

ErrorReport

Page 42 Message Definition Report Part 1

BusinessTransactions

5.19 Baseline Amendment: Amendment of transactions initiated in the

lodge mode scenario

This scenario describes the message flows for the amendment of a transaction (baseline) established in
the lodge mode.

• Bank 1 submits a baseline amendment request (BaselineAmendmentRequest message) to the

matching application.
• After the matching application has successfully performed compliance and consistency check on
the message (BaselineAmendmentRequest message), it confirms the completion of the
requested update of the baseline by submitting a report listing the differences between the
original and new baseline (DeltaReport message) and a report on the calculation of the dynamic
part of the new baseline (BaselineReport message) to bank 1.

5.20 Baseline Amendment: Baseline amendment with secondary bank

scenario

This scenario describes possible message flows for the amendment of a transaction established in the
push-through mode in the presence of a secondary bank (obligor bank). Bank 1 and 2 are the primary
banks. Bank 3 is an obligor bank, included in the baseline. Only primary banks may initiate an
amendment: in this case it is bank 1. This is the scenario for an amendment that does not change the
parties to the transaction.

• Bank 1 submits a baseline amendment request (BaselineAmendmentRequest message) to the

Furthermore, it forwards the amendment request (FullPushThroughReport message), a report

• Bank 2 accepts the amendment request (AmendmentAcceptance message).

• After the matching application has successfully performed compliance and consistency check on
the message (AmendmentAcceptance message) it acknowledges the acceptance of the

20 February 2015 Page 43

Trade Services Management November 2015

amendment to bank 2 by submitting a report on the calculation of the dynamic part of the new
baseline (BaselineReport message).

Furthermore, it notifies bank 1 about the acceptance of the amendment request

(AmendmentAcceptanceNotification) and submits a report on the calculation of the dynamic part
of the new baseline (BaselineReport message) to bank 1.

• At this stage, the two primary banks have accepted the amendment, but there is another bank
that still needs to accept, therefore the status is still "AmendmentRequested".
• The matching application sends DeltaReport, pre-calculated BaselineReport and
FullPushThroughReport to bank 3 with a request to accept or reject the baseline and its role. The
FullPushThroughReport message contains a request to accept or reject the role assigned to
bank 3 in the baseline, and the baseline

Case 1

• Secondary bank accepts the baseline amendment and its role by sending a
RoleAndBaselineAcceptance message.
• The matching application sends RoleAndBaselineAcceptanceNotification to both primary banks
to inform them
• The matching application sends BaselineReport to all parties, confirming that the amendment is
effective.

Case 2

• Secondary bank rejects the baseline amendment and its role by sending a
RoleAndBaselineRejection message.
• The matching application sends RoleAndBaselineRejectionNotification to both primary banks to
inform them. The matching application also sends a BaselineReport to all parties. The
amendment is not effective.

NOTES:

• In case bank 2 would reject the amendment, bank 3 would not be involved at all and would not
receive any message from matching application. (Case 3)
• In the same scenario, but with a submitting bank instead of obligor bank: Submitting bank is
informed only, it receives the three messages, DeltaReport, BaselineReport and
FullPushThroughReport, and does not have any decision to make (accept/reject).
• Exactly the same flows apply if as part of an amendment process between two primary banks,
these two primary banks agree to add a secondary bank to the transaction.
• If a BaselineAmendmentRequest contains a baseline that is identical to the established baseline,
the matching application will reject it and return an ErrorReport.

Page 44 Message Definition Report Part 1

BusinessTransactions

Bank 1 : Bank 3 : TSU : Bank 2 :

FinancialInstApp FinancialInstApp SystemApplication FinancialInstApp
BaselineAmendmentRequest

FullPushThroughReport (Code: AMEND)

DeltaReport DeltaReport
BaselineReport (PRECALCULATED)

AmendmentAcceptance
AmendmentAcceptanceNotification

Acknowledgement

FullPushThroughReport (Code: AMEND)

DeltaReport

BaselineReport (PRECALCULATED)

Case 1: Obligor bank

accepts

RoleAndBaselineAcceptance

RoleAndBaselineAcceptanceNotification RoleAndBaselineAcceptanceNotification

BaselineReport(CURRENT)

BaselineReport(CURRENT) BaselineReport(CURRENT)

Case 2: Obligor bank

rejects
RoleAndBaselineRejection

RoleAndBaselineRejectionNotification RoleAndBaselineRejectionNotification

BaselineReport(CURRENT)

Case 3: Bank 2 rejects

the amendment

BaselineAmendmentRequest
FullPushThroughReport (Code: AMEND)
DeltaReport DeltaReport

BaselineReport (PRECALCULATED)
AmendmentRejection

AmendmentRejectionNotification Acknowledgement

Bank 3 will not receive

any message.

5.21 Status Change and Extension: Request to change status of push-

through transactions scenario
This scenario describes possible message flows for the change of a status of transactions established in
the push-through mode.

20 February 2015 Page 45

Trade Services Management November 2015

When a transaction is in the status active, either party can request to change the status of the transaction
to complete. The receiver of the status change request has to either accept (see Example A1) or reject
(see Example A2) the status change request.
When a transaction is in the status complete either party can request to change (re-activate) the status of
the transaction, i.e. to put the transaction in a state that will allow new submissions of data sets and/or
amendment requests. The receiver of the status change request has to either accept (see Example B1)
or reject (see Example B2) the status change request.
The transaction will go back to the status active.

Page 46 Message Definition Report Part 1

BusinessTransactions

Bank 1 : TSU : Bank 2 :

FinancialInstApp SystemApplication FinancialInstApp

Status of baseline: Active

Example A1:
request to complete - acceptance

StatusChangeRequest (Code: COMPLETE)

Acknowledgement

StatusChangeRequestNotification

StatusChangeRequestAcceptance
StatusChangeNotification StatusChangeNotification
Status changed to
Complete

Example A2:
request to complete - rejection

StatusChangeRequest (Code: COMPLETE)

Acknowledgement StatusChangeRequestNotification

StatusChangeRequestRejection

StatusChangeRejectionNotification Acknowledgement

NO Status change; remains Active

Status of baseline: Complete

Example B1:
request to re-activate - acceptance

StatusChangeRequest (Code: ACTIVE)

Acknowledgement
StatusChangeRequestNotification

StatusChangeRequestAcceptance

StatusChangeNotification StatusChangeNotification

Status change to Established or Active

Example B2:
request to re-activate - rejection

StatusChangeRequest (Code: ACTIVE)

Acknowledgement
StatusChangeRequestNotification

StatusChangeRequestRejection
StatusChangeRejectionNotification Acknowledgement

No change of status

20 February 2015 Page 47

Trade Services Management November 2015

5.22 Status Change and Extension: Request to change or extend the

status for transactions initiated in the lodge mode scenario
This scenario describes possible message flows for the handling of status changes or status extensions
for transactions established in the lodge mode.
Requests to change or extend the status of transactions established in the lodge mode are carried out
immediately by the matching application since no other party needs to agree to the request.
The matching application informs the requester about the result of the request.

Bank 1 : TSU :
FinancialInstApp SystemApplication

Status of baseline: Active

Example A1:
request to complete

StatusChangeRequest (Code: COMPLETE)

StatusChangeNotification

Status changed to
Complete

Example A1:
request to close

StatusChangeRequest (Code: CLOSE)

StatusChangeNotification

Status changed to Closed

Status of baseline: Complete

Example B1:
request for re-instate

StatusChangeRequest (Code: ACTIVE)

StatusChangeNotification

Status changed to Active

NotifyTimeOut (Code: CLOSE)

StatusExtensionRequest
StatusExtensionNotification

No change of status

Page 48 Message Definition Report Part 1

BusinessTransactions

5.23 Status Change and Extension: Request to close transactions initiated

in the push-through mode scenario
This scenario describes possible message flows for the handling of a request to close a transaction
established in the push-through mode.
When a transaction is in the status complete either party can request the closure of a transaction, that is,
to change the status from complete to close. The receiver of the closure request
(StatusChangeRequestNotification message) has to either accept (see Example C1) or reject (see
Example C2) the request.

Bank 1 : TSU : Bank 2 :

FinancialInstApp SystemApplication FinancialInstApp

Status of push-through baseline: Complete

Example C1:
request to close - acceptance

StatusChangeRequest (Code: CLOSE) StatusChangeRequestNotification

StatusChangeRequestAcceptance

StatusChangeNotification StatusChangeNotification

Status change to Closed

Example C2:
request to close - rejection

StatusChangeRequestRejection

StatusChangeRejectionNotification Acknowledgement

No change of status
Status of push-through baseline: Complete

5.24 Status Change and Extension: Change or extend status in presence

of secondary bank scenario
These message flows show requests to extend or change status initiated by a primary bank, in presence
of a secondary bank. The secondary bank is informed of the extension or change of status if it was
accepted by the second primary bank. The secondary bank does not receive any message if the

20 February 2015 Page 49

Trade Services Management November 2015

extension or change of status was rejected by the second primary bank.

Bank 1 : Bank 3 : TSU : Bank 2 :

nancialInstApp FinancialInstApp SystemApplication FinancialInstApp

Case A1:
request to change status - acceptance

StatusChangeRequest
Acknowledgement StatusChangeRequestNotification

StatusChangeRequestAcceptance

StatusChangeNotification StatusChangeNotification

StatusChangeNotification

Status changed

Case A2:
request to change status - rejection

StatusChangeRequest

Acknowledgement StatusChangeRequestNotification

StatusChangeRequestRejection

StatusChangeRejectionNotification Acknowledgement

NO Status change

Case B1:
request to extend status - acceptance

StatusExtensionRequest
Acknowledgement
StatusExtensionRequestNotification

StatusExtensionRequestAcceptance

StatusExtensionNotification StatusExtensionNotification
StatusExtensionNotification

Status is extended

Case B2:
request to extend status - rejection

StatusExtensionRequest

Acknowledgement
StatusExtensionRequestNotification

StatusExtensionRequestRejection
StatusExtensionRejectionNotification Acknowledgement

No extension of status

Page 50 Message Definition Report Part 1

BusinessTransactions

5.25 Status Change and Extension: Request to change or extend status by

a secondary bank scenario
These message flows show requests to extend (change of status is not allowed) initiated by a secondary
bank (submitting bank only, not obligor).
Both primary banks, and only primary banks, are requested to accept/reject the request. If they both
accept, the request is accepted, if one of them rejects the request, the request is rejected. The matching
application waits for both answers then sends a StatusExtensionNotification (in the first case) and
StatusExtensionRejectionNotification (in the second case) to the three banks.
In case of several secondary banks, the secondary bank(s) that did not initiate the request will receive a
StatusExtensionNotification if the extension was accepted, and no message at all if the extension was
rejected.

Bank 1 : Bank 3 : TSU : Bank 2 :

FinancialInstApp FinancialInstApp SystemApplication FinancialInstApp

StatusExtensionRequest
Acknowledgement
StatusExtensionRequestNotification StatusExtensionRequestNotification

Case A1:
request to extend status - both primary accept

StatusExtensionRequestAcceptance
Acknowledgement

StatusExtensionRequestAcceptance

Acknowledgement

StatusExtensionNotification

Status extended

Case A2:
request to extend status - one of the primary rejects

StatusExtensionRequestRejection

Acknowledgement
StatusExtensionRequestAcceptance
Acknowledgement
StatusExtensionRejectionNotification StatusChangeRejectionNotification

StatusExtensionRejectionNotification

NO extension of status

20 February 2015 Page 51

Trade Services Management November 2015

5.26 Intent to pay scenario

In this scenario, one of the primary banks, bank 1, will send two IntentToPayNotification messages
relating to the same transaction, identified by its transaction identification (TID). The transaction must
have been established prior to sending these messages, and it may not be closed.
A first IntentToPayNotification is sent, for a certain amount related to a purchase order. The matching
application receives and validates the message, it will check, eg, that the TID is valid and the transaction
is not yet closed. If the message passes all validation, it will send back an Acknowledgement message to
the originator, and forward a copy to the other primary bank, bank 2, as a
ForwardIntentToPayNotification. The matching application will also send the same report, the
IntentToPayReport, to both primary banks. This report contains amounts that have been committed so
far, per purchase order listed in the IntentToPayNotification message.
Later on a second IntentToPayNotification is sent, for an additional amount related to the same purchase
order. The matching application goes through the same validation process, and sends the same types of
messages. The IntentToPayReport now contains the sum of the two amounts sent in the two
IntentToPayNotification messages previously sent.
If the IntentToPayNotification contains references to several TID's and the corresponding purchase
orders, all transactions must be in the correct states, ie after establishment and before closure. If the
status of the baseline is closed, the IntentToPayNotification message will be rejected by the matching
application and an ErrorReport message will be sent back. An ErrorReport message will also be sent if
the message fails validation.

Bank 1 :
FinancialInstApp
TSU : Bank 2 :
SystemApplication FinancialInstApp

Status of baseline:
Established/Active/Complete

IntentToPayNotification

Acknowledgement ForwardIntentToPayNotification

IntentToPayReport IntentToPayReport

IntentToPayNotification
Acknowledgement ForwardIntentToPayNotification

IntentToPayReport IntentToPayReport

Status of baseline: Closed

IntentToPayNotification

ErrorReport

Page 52 Message Definition Report Part 1

BusinessTransactions

5.27 Reminder notification scenario

This scenario describes possible message flows for the handling of action reminders for transactions
established in the push-through mode.
In the following cases the matching application will send a reminder every number of days when it did not
receive the expected response from the counterparty:

• submission of twin baseline, or re-submission

• acceptance/rejection of role and baseline
• acceptance/rejection of mismatched data sets
• acceptance/rejection of amendment request.

In the following cases the matching application will send one reminder when it did not receive the
expected response from the counterparty. It will cancel the request and inform the parties about the
cancellation when no action is taken following the reminder:

• acceptance/rejection of a status change request

• acceptance/rejection of a status extension request.

Bank 1 : TSU : Bank 2 :

FinancialInstApp SystemApplication FinancialInstApp

Status of baseline is Established / Active

One single amendment

BaselineAmendmentRequest

FullPushThroughReport (Code: AMEND)

DeltaReport DeltaReport
BaselineReport (Code: PRECALCULATED)

No Accept or
Reject sent.

ActionReminder

Every 7 days

ActionReminder

Reminder for status

changes/extensions.

StatusChangeRequest
StatusChangeRequestNotification

No Accept or
Reject sent.
ActionReminder

No Accept or
Reject sent.

StatusChangeRejectionNotification StatusChangeRejectionNotification

20 February 2015 Page 53

Trade Services Management November 2015

5.28 Time-out notification scenario

This scenario describes possible message flows for the notification of time-outs by the matching
application.
Time-outs may occur because no activity on a transaction has taken place during a period of time, or
because a significant date, for example latest shipment date, is reached.
In all cases of time-outs, the matching application will notify both parties a number of days before the
event and requests them to take action. If no action is taken by the parties, the time-out will occur at the
given date and time that is the parties will be informed about the change of status of the transaction.

Example A1

The transaction is in the status established, active or complete.

• The matching application informs bank 1 and bank 2 a number of days before a time-out will
occur that it will close the transaction if no action is taken by the parties (TimeOutNotification
message) before a given date and time.
• At the given date and time the matching application informs bank 1 and bank 2 about the change
of the status of the transaction.

Example A2

The transaction is in the status established, active or complete.

• The matching application informs bank 1 and bank 2 a number of days before a time-out will
occur that it will close the transaction if no action is taken by the parties (TimeOutNotification
message) before a given date and time.
• Bank 1 submits the request to extent the status of the transaction (StatusExtensionRequest
message).
• After the matching application has successfully performed compliance and consistency check on
the message (StatusExtensionRequest message) it acknowledges the receipt of the request to
bank 1 (Acknowledgement message) and forwards the request to bank 2
(StatusExtensionRequestNotification message) requesting acceptance or rejection of the
request.
• Bank 2 accepts the status extension request (StatusExtensionAcceptance message).
• After the matching application has successfully performed compliance and consistency check on
the message (StatusExtensionAcceptance message) it notifies both parties about the extension
of the status of the transaction (StatusExtensionNotification message).

The transaction remains in the same status.

Example A3

Continuation of example A2 after the matching application has requested bank 2 to either accept or
reject the status extension request.

• Bank 2 rejects the status extension request (StatusExtensionRejection message).

• After the matching application has successfully performed compliance and consistency check on
the message (StatusExtensionRejection message) it acknowledges the receipt of the rejection to
bank 2 (Acknowledgement message) and notifies bank 1 about the rejection of the request
(StatusExtensionRejectionNotification).

At the given date and time the matching application informs bank 1 and bank 2 about the change
of the status of the transaction.

Page 54 Message Definition Report Part 1

BusinessTransactions

Bank 1 : TSU : Bank 2 :

FinancialInstApp SystemApplication FinancialInstApp

Status of baseline:
Established/ActiveComplete

Example A1:
time-out after 90 days - no reaction

TimeOutNotification (Code: CLOSE) TimeOutNotification (Code: CLOSE)

StatusChangeNotification (Code: CLOSE) StatusChangeNotification (Code: CLOSE)

Status change to Closed

Status of baseline:
Established/Active/Complete

Example A2:
time-out after 90 days - extension accepted

TimeOutNotification (Code: CLOSE) TimeOutNotification (Code: CLOSE)

StatusExtensionRequest

Acknowledgement StatusExtensionRequestNotification
StatusExtensionAcceptance

StatusExtensionNotification StatusExtensionNotification

NO Status change

Example A3:
time-out after 90 days - extension rejected

StatusExtensionRejection
StatusExtensionRejectionNotification Acknowledgement

StatusChangeNotification (Code: CLOSE) StatusChangeNotification (Code: CLOSE)

Status change to Closed

5.29 Activity Reporting

The activity report can be requested (ActivityReportRequest message) at any moment in time. It must
specify a time span in the past. The resulting report (ActivityReport message) will then cover all activities
that have taken place during the specified time span.

20 February 2015 Page 55

Trade Services Management November 2015

An unsolicited activity report covering the last 24 hours is generated by the matching application every 24
hours. The hour when it is generated can be specified (ActivityReportSetUpRequest message) by the
user as an offset to midnight UTC time, for example -5.

Bank 1 : Bank 2 :
FinancialInstApp TSU : FinancialInstApp
SystemApplication
ActivityReportRequest

ActivityReport

Automatic Activity
Report

ActivityReportSetUpRequest
Acknowledgement

ActivityReport

ActivityReport Every 24H

5.30 Status Reporting

The status report can be requested at any moment in time. The status report will list all transactions that
the bank is a party of.
For each transaction it will give the status (for example established) and if applicable a time
condition/violation.
For example, if the transaction was inactive for a long time and a notification was sent that the matching
application will close the transaction, it will indicate "Transaction will be closed by matching application
on 2009.07.13 at 00:00". It will also show pending requests for action.

Page 56 Message Definition Report Part 1

BusinessTransactions

5.31 Transaction Reporting

The transaction report can be requested at any moment in time. The transaction report provides details
on those transactions for which the report has been requested.

5.32 Error notification scenario

This scenario describes possible message flows handling the receipt of incorrect instructions by the
matching application.
The request to change the status of a transaction to complete (StatusChangeRequest message) a
transaction that is in any other state than established or active will result in the sending of an error
notification (ErrorReport message) by the matching application.
The request (StatusChangeRequest message) to re-activate a transaction that is in any other state than
complete will result in the sending of an error notification (ErrorReport message) by the matching
application.
The request to change the status of a transaction to close (StatusChangeRequest message) for a
transaction that is in the status closed will result in the sending of an error notification (ErrorReport
message) by the matching application.
If the same party submits several equivalent requests (StatusChangeRequest message) to change the
status of a transaction before receiving a response from the counterparty, the matching application will
each time acknowledge the request (Acknowledgement message) and forward it to the counterparty
(StatusChangeRequestNotification). However, it will consider that there is only one single request
pending and therefore a single response (acceptance or rejection) from the counterparty will be enough
(StatusChangeRequestAcceptance/ StatusChangeRequestRejection message).

20 February 2015 Page 57

Trade Services Management November 2015

Bank 1 : TSU : Bank 2 :

FinancialInstApp SystemApplication FinancialInstApp
Status of baseline: any other state than
Established or Active

StatusChangeRequest (Code: COMPLETE)

ErrorReport

Status is not changed.

Status of baseline: any other state than

Completed

StatusChangeRequest (Code: ACTIVE)

ErrorReport

Status is not changed.

Status of baseline: Closed

StatusChangeRequest (Code: CLOSE)

ErrorReport

Status is not changed.

Status of baseline: Completed

StatusChangeRequest (Code: CLOSE)

Acknowledgement
StatusChangeRequestNotification

StatusChangeRequest (Code: CLOSE)

Acknowledgement StatusChangeRequestNotification

StatusChangeRequest (Code: CLOSE)

Acknowledgement StatusChangeRequestNotification

StatusChangeRequestAcceptance
StatusChangeNotification StatusChangeNotification

No request pending.

5.33 Special request scenario

Bank 1 and 2 are the primary banks. Bank 3 is a secondary bank (obligor or submitting), included in the
baseline.

Page 58 Message Definition Report Part 1

Examples

At any moment when the transaction is established and not closed, a secondary bank may send a
SpecialRequest message in two cases: 1) "force majeure" that prevents the bank from continuing to take
part in the transaction. 2) a problem that prevents a submitting bank from being able to submit data
set(s).
The matching application will inform the two primary banks by sending a SpecialNotification message,
and it is up to the primary banks to take action, by amending or closing the transaction.
In another scenario, a primary bank may send a SpecialRequest message at any moment when the
transaction is established and not closed, in case of "force majeure" that prevents the bank from
continuing to take part in the transaction. In this case, the transaction cannot go on in the absence of a
primary bank, and therefore the matching application will close immediately the transaction and send a
StatusChangeNotification message to each party to the transaction (primary and secondary).

Bank 1 : Bank 3 : Bank 2 :

FinancialInstApp TSU :
FinancialInstApp SystemApplication FinancialInstApp

SpecialRequest sent by a
secondary bank

SpecialRequest

Acknowledgement

SpecialNotification

SpecialRequest sent by a
primary bank

SpecialRequest

StatusChangeNotification

6. Examples

6.1 Acknowledgement - tsmt.001.001.03

The following illustrates the acknowledging of a message received by the matching application.

In below scenario the matching application acknowledges to the buyer's bank (ADIABE22) the receipt of an
InitialBaselineSubmission message (AckdMsgRef) (see business example InitialBaselineSubmission) sent by the
buyer's bank.

20 February 2015 Page 59

Trade Services Management November 2015

<Ack>
<AckId>
<Id>ACKMessage42</Id>
<CreDtTm>2009-07-04T11:03:00</CreDtTm>
</AckId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<TxSts>
<Sts>PROP</Sts>
</TxSts>
<AckdMsgRef>
<Id>IBSMessage1</Id>
<CreDtTm>2009-07-04T11:02:00</CreDtTm>
</AckdMsgRef>
</Ack>

6.2 ActivityReport - tsmt.002.001.04

The following illustrates the reporting of all transactions for which an activity has taken place within a given time span
and in which the requester of an activity report is involved.

In the scenario below the matching application informs the buyer's bank (ADIABE22) of all transactions that the bank
is involved in and on which an activity has taken place on 6 September 2009. The report is triggered by an
ActivityReportRequest message (see business example).

<ActvtyRpt>
<RptId>
<Id>ARPMessage25</Id>
<CreDtTm>2009-09-09T11:38:00</CreDtTm>
</RptId>
<RltdMsgRef>
<Id>ARRMessage24</Id>
<CreDtTm>2009-09-09T11:37:00</CreDtTm>
</RltdMsgRef>
<Rpt>
<TxId>01190799181-6940-48</TxId>
<RptdNtty>
<BIC>ADIABE22</BIC>
</RptdNtty>
<RptdItm>
<DtTm>2009-09-06T08:52:00</DtTm>
<Actvty>
<MsgNm>tsmt.020.001.02</MsgNm>
</Actvty>
<Initr>
<BIC>ADIABE22</BIC>
</Initr>
</RptdItm>
<RptdItm>
<DtTm>2009-09-06T08:54:00</DtTm>
<Actvty>
<MsgNm>tsmt.011.001.02</MsgNm>
</Actvty>
<Initr>
<BIC>SWHQBEBB</BIC>
</Initr>
</RptdItm>
</Rpt>
</ActvtyRpt>

Page 60 Message Definition Report Part 1

Examples

6.3 ActivityReportRequest - tsmt.003.001.03

The following illustrates the request for an activity report.

In the scenario below the buyer's bank (ADIABE22) requests a report of all transactions that the bank is involved in
and for which an activity has taken place on 7 September 2009.

The matching application will respond to the request by sending an ActivityReport message (see business example).

<ActvtyReqRpt>
<ReqId>
<Id>ARRMessage24</Id>
<CreDtTm>2009-09-09T11:37:00</CreDtTm>
</ReqId>
<RptPrd>
<FrDtTm>2009-09-07T00:00:00</FrDtTm>
<ToDtTm>2009-09-07T23:59:00</ToDtTm>
</RptPrd>
</ActvtyReqRpt>

6.4 ActivityReportSetUpRequest - tsmt.004.001.02

The following illustrates the request to set the specific time at which an activity report is generated.

In the scenario below the buyer's bank (ADIABE22) requests to generate the daily production of the activity report at
midnight UTC time minus 8 hours.

<ActvtyRptSetUpReq>
<ReqId>
<Id>ARSMessage26</Id>
<CreDtTm>2009-09-10T09:16:00</CreDtTm>
</ReqId>
<UTCOffset>
<Sgn>false</Sgn>
<NbOfHrs>08:00:00</NbOfHrs>
</UTCOffset>
</ActvtyRptSetUpReq>

6.5 AmendmentAcceptance - tsmt.005.001.02

The following illustrates the acceptance of an amendment request.

In the scenario below the seller's bank (AFMBZAJJ) accepts the amendment requested by the buyer's bank
(ADIABE22) with the BaselineAmendmentRequest message (see business example) and specified in the associated
DeltaReport message (see business example).

The message specifies the DeltaReport message that it relates to (DltaRptRef) and the number of the amendment
the sender of the message, that is the seller's bank, accepts (AccptdAmdmntNb).

The matching application will convey the information about the acceptance of the amendment request by sending an
AmendmentAcceptanceNotification message (see business example) to the requester of the amendment, that is the
seller's bank.

Furthermore, it will report on the actual value of the dynamic part of the baseline (goods component) by sending a
BaselineReport message to the seller's and buyer's banks.

The rejection of an amendment request can be achieved by submitting an AmendmentRejection message (see
business example).

20 February 2015 Page 61

Trade Services Management November 2015

<AmdmntAccptnc>
<AccptncId>
<Id>AACMessage7</Id>
<CreDtTm>2009-07-08T16:46:00</CreDtTm>
</AccptncId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<DltaRptRef>
<Id>DELMessage6</Id>
<CreDtTm>2009-07-08T09:14:00</CreDtTm>
</DltaRptRef>
<AccptdAmdmntNb>
<Nb>1</Nb>
</AccptdAmdmntNb>
</AmdmntAccptnc>

6.6 AmendmentAcceptanceNotification - tsmt.006.001.03

The following illustrates the notification of an amendment acceptance.

In the scenario below the matching application informs the buyer's bank (ADIABE22), that is, the requester of the
amendment and submitter of the BaselineAmendmentRequest message (see business example), that the seller's
bank (AFMBZAJJ) has accepted the requested amendment (see business example AmendmentAcceptance).

The message specifies the DeltaReport message that it relates to (DltaRptRef), the number of the amendment that
the sender of the AmendmentAcceptance message, that is, the seller's bank, accepts (AccptdAmdmntNb) and the
baseline identification.

The matching application will inform about the rejection of an amendment request by sending an
AmendmentRejectionNotification message (see business example AmendmentRejectionNotification).

<AmdmntAccptncNtfctn>
<NtfctnId>
<Id>AANMessage9</Id>
<CreDtTm>2009-07-08T16:48:00</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<EstblishdBaselnId>
<Id>01190799181-6940-48</Id>
<Vrsn>1</Vrsn>
</EstblishdBaselnId>
<TxSts>
<Sts>ESTD</Sts>
</TxSts>
<DltaRptRef>
<Id>DELMessge6</Id>
<CreDtTm>2009-07-08T09:14:00</CreDtTm>
</DltaRptRef>
<AccptdAmdmntNb>
<Nb>1</Nb>
</AccptdAmdmntNb>
<Initr>
<BIC>AFMBZAJJ</BIC>
</Initr>
</AmdmntAccptncNtfctn>

Page 62 Message Definition Report Part 1

Examples

6.7 AmendmentRejection - tsmt.007.001.02

The following illustrates the rejection of an amendment request.

In the scenario below the seller's bank (AFMBZAJJ) rejects the amendment requested by the buyer's bank
(ADIABE22) with the BaselineAmendmentRequest message (see business example) and specified in the associated
DeltaReport message (see business example).

The message specifies the DeltaReport message that it relates to (DltaRptRef), the number of the amendment the
sender of the message, that is the seller's bank, rejects (RjctdAmdmntNb) and the reason for the request rejection
(RjctnRsn).

The matching application will convey the information about the rejection of the amendment request by sending an
AmendmentRejectionNotification message (see business example) to the requester of the amendment, that is the
seller's bank.

The acceptance of an amendment request can be achieved by submitting an AmendmentAcceptance message (see
business example).

<AmdmntRjctn>
<RjctnId>
<Id>ARJMessage8</Id>
<CreDtTm>2009-07-08T16:46:00</CreDtTm>
</RjctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<DltaRptRef>
<Id>DELMessage6</Id>
<CreDtTm>2009-07-08T09:14:00</CreDtTm>
</DltaRptRef>
<RjctdAmdmntNb>
<Nb>1</Nb>
</RjctdAmdmntNb>
<RjctnRsn>
<GblRjctnRsn>
<Desc>Shipment too late</Desc>
</GblRjctnRsn>
</RjctnRsn>
</AmdmntRjctn>

6.8 AmendmentRejectionNotification - tsmt.008.001.03

The following illustrates the notification of an amendment rejection.

In the scenario below the matching application informs the buyer's bank (ADIABE22), that is, the requester of the
amendment and submitter of the BaselineAmendmentRequest message (see business example), that the seller's
bank (AFMBZAJJ) has rejected the requested amendment (see business example AmendmentRejection).

The message specifies the DeltaReport message that it relates to (DltaRptRef), the number of the amendment that
the sender of the AmendmentRejection message, that is, the seller's bank, rejects (RjctdAmdmntNb) and the reason
for the request rejection (RjctnRsn).

The matching application will inform about the acceptance of an amendment request by sending an
AmendmentAcceptanceNotification message (see business example).

<AmdmntRjctnNtfctn>
<NtfctnId>
<Id>ARNMessage10</Id>
<CreDtTm>2009-07-08T16:48:00</CreDtTm>
</NtfctnId>

20 February 2015 Page 63

Trade Services Management November 2015

<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<EstblishdBaselnId>
<Id>01190799181-6940-48</Id>
<Vrsn>1</Vrsn>
</EstblishdBaselnId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<DltaRptRef>
<Id>DELMessage6</Id>
<CreDtTm>2009-07-08T09:14:00</CreDtTm>
</DltaRptRef>
<RjctdAmdmntNb>
<Nb>1</Nb>
</RjctdAmdmntNb>
<Initr>
<BIC>AFMBZAJJ</BIC>
</Initr>
<RjctnRsn>
<GblRjctnRsn>
<Desc>Shipment too late</Desc>
</GblRjctnRsn>
</RjctnRsn>
</AmdmntRjctnNtfctn>

6.9 BaselineAmendmentRequest - tsmt.009.001.05

The following illustrates the request to amend an established baseline.

In the scenario below the buyer's bank (ADIABE22) requests the amendment of an established baseline (see
business example InitialBaselineSubmission and BaselineReSubmission).

It requests a change of latest shipment date and of airport of destination from Antwerp to Amsterdam.

The amendment is requested by submitting complete baseline information conveying the changed data elements
and repeating the unchanged ones.

The matching application will acknowledge the receipt of the amendment request to the buyer's bank by sending a
DeltaReport message (see business example).

It will inform the counterparty (seller's bank) about the amendment request by sending a DeltaReport message (see
business example), a FullPushThroughReport message and a pre-calculated BaselineReport message.

<BaselnAmdmntReq>
<ReqId>
<Id>BARMessage5</Id>
<CreDtTm>2009-07-08T09:12:00</CreDtTm>
</ReqId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<Baseln>
<SubmitrBaselnId>
<Id>PO20090615/003567</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>ADIABE22</BIC>
</Submitr>
</SubmitrBaselnId>
<SvcCd>LEV1</SvcCd>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>

Page 64 Message Definition Report Part 1

Examples

<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<BuyrBk>
<BIC>ADIABE22</BIC>
</BuyrBk>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<Goods>
<GoodsAndOrSvcsDesc>Raw Diamonds</GoodsAndOrSvcsDesc>
<PrtlShipmnt>true</PrtlShipmnt>
<TrnsShipmnt>false</TrnsShipmnt>
<ShipmntDtRg>
<LatstShipmntDt>2009-10-15</LatstShipmntDt>
</ShipmntDtRg>
<LineItmDtls>
<LineItmId>1</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>20</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">4473.00</Amt>
</UnitPric>
<PdctNm>Round shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>RO</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>0.7</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>E</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>IF</Id>
<IdTp>clarity</IdTp>

20 February 2015 Page 65

Trade Services Management November 2015

</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>brilliant</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<PdctOrgn>ZA</PdctOrgn>
<TtlAmt Ccy="USD">89460.00</TtlAmt>
</LineItmDtls>
<LineItmDtls>
<LineItmId>2</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>25</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">6205.00</Amt>
</UnitPric>
<PdctNm>Princess shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PR</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.0</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>G</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>WSI</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>princess</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<PdctOrgn>ZA</PdctOrgn>
<TtlAmt Ccy="USD">155125.00</TtlAmt>
</LineItmDtls>
<LineItmDtls>
<LineItmId>3</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>10</Val>
</Qty>
<UnitPric>

Page 66 Message Definition Report Part 1

Examples

<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">7788.00</Amt>
</UnitPric>
<PdctNm>Pear shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PE</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.5</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>H</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>SI1</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>pear</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<TtlAmt Ccy="USD">77880.00</TtlAmt>
</LineItmDtls>
<LineItmsTtlAmt Ccy="USD">322465.00</LineItmsTtlAmt>
<RtgSummry>
<IndvTrnsprt>
<TrnsprtByAir>
<DprtureAirprt>
<OthrAirprtDesc>
<Twn>Johannesburg</Twn>
</OthrAirprtDesc>
</DprtureAirprt>
<DstnAirprt>
<OthrAirprtDesc>
<Twn>Amsterdam</Twn>
</OthrAirprtDesc>
</DstnAirprt>
</TrnsprtByAir>
</IndvTrnsprt>
</RtgSummry>
<Incotrms>
<IncotrmsCd>
<Cd>FCA</Cd>
</IncotrmsCd>
<Lctn>Amsterdam</Lctn>
</Incotrms>
<TtlNetAmt Ccy="USD">322465.00</TtlNetAmt>
</Goods>
<PmtTerms>
<PmtTerms>
<PmtCd>
<Cd>CASH</Cd>
</PmtCd>

20 February 2015 Page 67

Trade Services Management November 2015

</PmtTerms>
<AmtOrPctg>
<Amt Ccy="USD">322465.00</Amt>
</AmtOrPctg>
</PmtTerms>
<SttlmTerms>
<CdtrAcct>
<Id>
<IBAN>ZA7757935JJ2435</IBAN>
</Id>
<Nm>Gem Grafting and Export Ltd.</Nm>
</CdtrAcct>
</SttlmTerms>
<ComrclDataSetReqrd>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</ComrclDataSetReqrd>
<TrnsprtDataSetReqrd>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</TrnsprtDataSetReqrd>
<InttToPayXpctd>true</InttToPayXpctd>
</Baseln>
</BaselnAmdmntReq>

6.10 BaselineMatchReport - tsmt.010.001.03

The following illustrates the passing on of information on a successful establishment of a transaction (baseline) in the
matching application.

In the first scenario below the matching application informs the buyer's and seller's banks (ADIABE22, AFMBZAJJ)
about the successful establishment of the transaction. (NbOfMisMtchs=0). The transaction has been registered in
the matching application by the seller's bank sending an InitialBaselineSubmission message (see business example)
and by the buyer's bank responding with a BaselineReSubmission message (see business example).

In the second scenario below the matching application informs the buyer's and seller's banks (ADIABE22,
AFMBZAJJ) that the InitialBaselineSubmission message sent by the buyer's bank differs from the
BaselineReSubmission message sent by the seller's bank (Rpt). The report component (Rpt) shows the number of
mis-matches found (NbOfMisMtchs) as well as details regarding the differences between the two baseline initiation
messages.

6.10.1 XML Instance - Scenario 1

<BaselnMtchRpt>
<RptId>
<Id>BMRMessage4</Id>
<CreDtTm>2009-07-05T08:34:00</CreDtTm>
</RptId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<EstblishdBaselnId>
<Id>01190799181-6940-48</Id>
<Vrsn>0</Vrsn>
</EstblishdBaselnId>
<TxSts>
<Sts>ESTD</Sts>
</TxSts>

Page 68 Message Definition Report Part 1

Examples

<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<BuyrBk>
<BIC>ADIABE22</BIC>
</BuyrBk>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<BaselnEstblishmtTrils>
<Cur>1</Cur>
<Lmt>6</Lmt>
</BaselnEstblishmtTrils>
<CmpardDocRef>
<Id>PO20090615/003567</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>ADIABE22</BIC>
</Submitr>
<DocIndx>1</DocIndx>
</CmpardDocRef>
<CmpardDocRef>
<Id>CONPO20090615-002258B</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
<DocIndx>2</DocIndx>
</CmpardDocRef>
<Rpt>
<NbOfMisMtchs>0</NbOfMisMtchs>
</Rpt>
</BaselnMtchRpt>

6.10.2 XML Instance - Scenario 2

20 February 2015 Page 69

Trade Services Management November 2015

<Nm>Diamant Import NV</Nm>

<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<BuyrBk>
<BIC>ADIABE22</BIC>
</BuyrBk>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<BaselnEstblishmtTrils>
<Cur>1</Cur>
<Lmt>6</Lmt>
</BaselnEstblishmtTrils>
<CmpardDocRef>
<Id>PO20090615/003567</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>ADIABE22</BIC>
</Submitr>
<DocIndx>1</DocIndx>
</CmpardDocRef>
<CmpardDocRef>
<Id>CONPO20090615-002258B</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
<DocIndx>2</DocIndx>
</CmpardDocRef>
<Rpt>
<NbOfMisMtchs>1</NbOfMisMtchs>
<MisMtchInf>
<SeqNb>1</SeqNb>
<RuleId>6314</RuleId>
<RuleDesc>partial shipment indicators must match</RuleDesc>
<MisMtchdElmt>
<DocIndx>1</DocIndx>
<ElmtPth>BaseIn/Goods/</ElmtPth>
<ElmtNm>PartlShipmnt</ElmtNm>
<ElmtVal>true</ElmtVal>
</MisMtchdElmt>
<MisMtchdElmt>
<DocIndx>2</DocIndx>
<ElmtPth>BaseIn/Goods/</ElmtPth>
<ElmtNm>PartlShipmnt</ElmtNm>
<ElmtVal>false</ElmtVal>
</MisMtchdElmt>
</MisMtchInf>
</Rpt>
</BaselnMtchRpt>

6.11 BaselineReport - tsmt.011.001.04

The following illustrates the calculation of the dynamic part of a baseline (goods component).

Page 70 Message Definition Report Part 1

Examples

In the scenario below the matching application informs the seller's and buyer's banks (AFMBZAJJ, ADIABE22) about
the actual status of the dynamic part of a baseline (goods component) after the acceptance of mis-matched data
sets (see business example) by the buyer's bank.

The message gives an overview of the

 ordered (baseline plus/minus amendments),

 accepted (successful data-set matches or accepted data-set mis-matches),
 outstanding (ordered minus successful or accepted data-set mis-matches) and
 pending (not yet accepted data-set mis-matches)

for each of the following:

• quantity per line item,

• total amount per line item,
• total line items amount and
• total net amount.

<BaselnRpt>
<RptId>
<Id>BSRMessage19</Id>
<CreDtTm>2009-09-07T08:54:00</CreDtTm>
</RptId>
<RptTp>
<Tp>CURR</Tp>
</RptTp>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<EstblishdBaselnId>
<Id>01190799181-6940-48</Id>
<Vrsn>1</Vrsn>
</EstblishdBaselnId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<BuyrBk>
<BIC>ADIABE22</BIC>
</BuyrBk>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<RptdLineItm>
<LineItmDtls>
<LineItmId>1</LineItmId>
<PdctNm>Round shape</PdctNm>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>RO</Id>

20 February 2015 Page 71

Trade Services Management November 2015

<IdTp>shape</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>0.7</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>E</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>IF</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>brilliant</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<OrdrdQty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>20</Val>
</OrdrdQty>
<AccptdQty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>0</Val>
</AccptdQty>
<OutsdngQty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>20</Val>
</OutsdngQty>
<PdgQty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>0</Val>
</PdgQty>
<OrdrdAmt Ccy = "USD">89460.00</OrdrdAmt>
<AccptdAmt Ccy = "USD">0</AccptdAmt>
<OutsdngAmt Ccy = "USD">89460.00</OutsdngAmt>
<PdgAmt Ccy = "USD">0</PdgAmt>
</LineItmDtls>
<LineItmDtls>
<LineItmId>2</LineItmId>
<PdctNm>Princess shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PR</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.0</Id>

Page 72 Message Definition Report Part 1

Examples

<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>G</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>WSI</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>princess</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<OrdrdQty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>25</Val>
</OrdrdQty>
<AccptdQty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>25</Val>
</AccptdQty>
<OutsdngQty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>0</Val>
</OutsdngQty>
<PdgQty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>0</Val>
</PdgQty>
<OrdrdAmt Ccy = "USD">155125.00</OrdrdAmt>
<AccptdAmt Ccy = "USD">155125.00</AccptdAmt>
<OutsdngAmt Ccy = "USD">0</OutsdngAmt>
<PdgAmt Ccy = "USD">0</PdgAmt>
</LineItmDtls>
<LineItmDtls>
<LineItmId>3</LineItmId>
<PdctNm>Pear shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PE</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.5</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>H</Id>

20 February 2015 Page 73

Trade Services Management November 2015

<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>SI1</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>pear</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<OrdrdQty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>10</Val>
</OrdrdQty>
<AccptdQty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>10</Val>
</AccptdQty>
<OutsdngQty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>0</Val>
</OutsdngQty>
<PdgQty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>0</Val>
</PdgQty>
<OrdrdAmt Ccy = "USD">77880.00</OrdrdAmt>
<AccptdAmt Ccy = "USD">77880.00</AccptdAmt>
<OutsdngAmt Ccy = "USD">0</OutsdngAmt>
<PdgAmt Ccy = "USD">0</PdgAmt>
</LineItmDtls>
<OrdrdLineItmsTtlAmt Ccy = "USD">322465.00</OrdrdLineItmsTtlAmt>
<AccptdLineItmsTtlAmt Ccy = "USD">233005.00</AccptdLineItmsTtlAmt>
<OutsdngLineItmsTtlAmt Ccy = "USD">89460.00</OutsdngLineItmsTtlAmt>
<PdgLineItmsTtlAmt Ccy = "USD">0</PdgLineItmsTtlAmt>
<OrdrdTtlNetAmt Ccy = "USD">322465.00</OrdrdTtlNetAmt>
<AccptdTtlNetAmt Ccy = "USD">233005.00</AccptdTtlNetAmt>
<OutsdngTtlNetAmt Ccy = "USD">89460.00</OutsdngTtlNetAmt>
<PdgTtlNetAmt Ccy = "USD">0</PdgTtlNetAmt>
</RptdLineItm>
</BaselnRpt>

6.12 BaselineReSubmission - tsmt.012.001.05

The following illustrates the response of the counterparty to the registration of a push-through transaction in the
matching application.

In the scenario below the seller's bank (AFMBZAJJ) submits details of the purchasing agreement, negotiated
between buyer (Diamant Import Nv, Antwerp, Belgium) and seller (Gem Grafting and Export Ltd., Johannesburg,
South Africa) in response to the FullPushThroughReport received earlier (see business example).

Page 74 Message Definition Report Part 1

Examples

In order to establish a transaction (baseline) in the matching application, the information submitted by the
counterparty (seller's bank, AFMBZAJJ) with the BaselineReSubmission message has to be the same as the
information submitted by the initiator of the transaction (buyer's bank ADIABE22). Only the contact details
components of the message are an exception to this rule.

After the receipt of the BaselineReSubmission message, the matching application will inform the seller's and buyer's
banks either about the successful establishment of the transaction (baseline) or the mis-matches found between the
two baseline initiation messages by sending a BaselineMatchReport message (see business example).

In case of mis-matches, either party can submit another BaselineReSubmission message to achieve a match and,
with that, the establishment of the transaction (baseline) in the matching application.

<BaselnReSubmissn>
<SubmissnId>
<Id>BRSMessage1</Id>
<CreDtTm>2009-07-04T11:02:00</CreDtTm>
</SubmissnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<Baseln>
<SubmitrBaselnId>
<Id>PO20090615/003567</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>ADIABE22</BIC>
</Submitr>
</SubmitrBaselnId>
<SvcCd>LEV1</SvcCd>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>
<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<BuyrBk>
<BIC>ADIABE22</BIC>
</BuyrBk>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<Goods>
<GoodsAndOrSvcsDesc>Raw Diamonds</GoodsAndOrSvcsDesc>
<PrtlShipmnt>true</PrtlShipmnt>
<TrnsShipmnt>false</TrnsShipmnt>
<ShipmntDtRg>
<LatstShipmntDt>2009-10-15</LatstShipmntDt>
</ShipmntDtRg>
<LineItmDtls>
<LineItmId>1</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>

20 February 2015 Page 75

Trade Services Management November 2015

</UnitOfMeasr>
<Val>20</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">4473.00</Amt>
</UnitPric>
<PdctNm>Round shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>RO</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>0.7</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>E</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>IF</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>brilliant</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<PdctOrgn>ZA</PdctOrgn>
<TtlAmt Ccy="USD">89460.00</TtlAmt>
</LineItmDtls>
<LineItmDtls>
<LineItmId>2</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>25</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">6205.00</Amt>
</UnitPric>
<PdctNm>Princess shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PR</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.0</Id>
<IdTp>carat</IdTp>

Page 76 Message Definition Report Part 1

Examples

</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>G</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>WSI</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>princess</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<PdctOrgn>ZA</PdctOrgn>
<TtlAmt Ccy="USD">155125.00</TtlAmt>
</LineItmDtls>
<LineItmDtls>
<LineItmId>3</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>10</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">7788.00</Amt>
</UnitPric>
<PdctNm>Pear shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PE</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.5</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>H</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>SI1</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>pear</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>

20 February 2015 Page 77

Trade Services Management November 2015

<TtlAmt Ccy="USD">77880.00</TtlAmt>
</LineItmDtls>
<LineItmsTtlAmt Ccy="USD">322465.00</LineItmsTtlAmt>
<RtgSummry>
<IndvTrnsprt>
<TrnsprtByAir>
<DprtureAirprt>
<OthrAirprtDesc>
<Twn>Johannesburg</Twn>
</OthrAirprtDesc>
</DprtureAirprt>
<DstnAirprt>
<OthrAirprtDesc>
<Twn>Amsterdam</Twn>
</OthrAirprtDesc>
</DstnAirprt>
</TrnsprtByAir>
</IndvTrnsprt>
</RtgSummry>
<Incotrms>
<IncotrmsCd>
<Cd>FCA</Cd>
</IncotrmsCd>
<Lctn>Amsterdam</Lctn>
</Incotrms>
<TtlNetAmt Ccy="USD">322465.00</TtlNetAmt>
</Goods>
<PmtTerms>
<PmtTerms>
<PmtCd>
<Cd>CASH</Cd>
</PmtCd>
</PmtTerms>
<AmtOrPctg>
<Amt Ccy="USD">322465.00</Amt>
</AmtOrPctg>
</PmtTerms>
<SttlmTerms>
<CdtrAcct>
<Id>
<IBAN>ZA7757935JJ2435</IBAN>
</Id>
<Nm>Gem Grafting and Export Ltd.</Nm>
</CdtrAcct>
</SttlmTerms>
<ComrclDataSetReqrd>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</ComrclDataSetReqrd>
<TrnsprtDataSetReqrd>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</TrnsprtDataSetReqrd>
<InttToPayXpctd>true</InttToPayXpctd>
</Baseln>
<BkCtctPrsn>
<BuyrBkCtctPrsn>
<Nm>Poncelet</Nm>
<NmPrfx>MISS</NmPrfx>
<GvnNm>Claire</GvnNm>
<EmailAdr>Claire.Poncelet@Antwerp_Diamantbk.be</EmailAdr>
</BuyrBkCtctPrsn>
</BkCtctPrsn>
</BaselnReSubmissn>

Page 78 Message Definition Report Part 1

Examples

6.13 DataSetMatchReport - tsmt.013.001.03

The following illustrates the passing on of information on an unsuccessful data set match.

In the scenario below the matching application informs the buyer's and seller's banks (ADIABE22, AFMBZAJJ) about
the mis-matches found between the data sets submitted by the seller's bank with the DataSetSubmission message
(see business example) and the related baseline (see business examples InitialBaselineSubmission and
BaselineReSubmission).

The message outlines that the Incoterm mentioned in the commercial data set differs from the Incoterm mentioned in
the related baseline. Furthermore, it specifies the action that the buyer's bank is expected to take (ReqForActn).

The counterparty, that is the buyer's bank, can either accept the mis-matched data sets by sending a
MisMatchAcceptance message (see business example) or reject the mis-matched data sets by sending a
MisMatchRejection message (see business example).

In the case of a successful match, the message below would indicate in the report component (Rpt) the number of
mis-matches found (NbOfMisMtchs), that is 0.

<DataSetMtchRpt>
<RptId>
<Id>DMRMessage14</Id>
<CreDtTm>2009-08-31T13:24:00</CreDtTm>
</RptId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<EstblishdBaselnId>
<Id>01190799181-6940-48</Id>
<Vrsn>1</Vrsn>
</EstblishdBaselnId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<BuyrBk>
<BIC>ADIABE22</BIC>
</BuyrBk>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<CmpardDocRef>
<Id>TSU20090704003789665</Id>
<Vrsn>1</Vrsn>
<Tp>BASE</Tp>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
<DocIndx>1</DocIndx>
</CmpardDocRef>

20 February 2015 Page 79

Trade Services Management November 2015

<CmpardDocRef>
<Id>CONINV20090050946/0830B</Id>
<Vrsn>1</Vrsn>
<Tp>CODS</Tp>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
<DocIndx>2</DocIndx>
</CmpardDocRef>
<SubmissnTp>
<Tp>MTCH</Tp>
</SubmissnTp>
<Rpt>
<NbOfMisMtchs>1</NbOfMisMtchs>
<MisMtchInf>
<SeqNb>1</SeqNb>
<RuleId>2563</RuleId>
<RuleDesc>IncoTerms are different</RuleDesc>
<MisMtchdElmt>
<DocIndx>1</DocIndx>
<ElmtPth>BaseIn/Goods/Incotrms/Cd/</ElmtPth>
<ElmtNm>Lctn</ElmtNm>
<ElmtVal>Johannesburg</ElmtVal>
</MisMtchdElmt>
<MisMtchdElmt>
<DocIndx>2</DocIndx>
<ElmtPth>ComrclDataSet/Goods/Incotrms/Cd/</ElmtPth>
<ElmtNm>Lctn</ElmtNm>
<ElmtVal>Amsterdam</ElmtVal>
</MisMtchdElmt>
</MisMtchInf>
</Rpt>
<ReqForActn>
<Tp>ARDM</Tp>
</ReqForActn>
</DataSetMtchRpt>

6.14 DataSetSubmission - tsmt.014.001.05

The following illustrates the submission of data sets against the related baseline.

In the scenario below the seller's bank (AFMBZAJJ) submits invoicing (ComrclDataSet) and transport
(TrnsprtDataSet) details related to the purchasing agreement covered by the transaction. The transaction that covers
the purchasing agreement is established with the InitialBaselineSubmission and BaselineReSubmission message
(see business examples). The message includes the instruction match (Instr), that is requesting the matching of the
submitted information with the related baseline.

The message covers a partial shipment (FnlSubmissn), that is details about the invoicing and shipment of line items
2 and 3, but not line item 1. The commercial data set shows the Incoterm FCA Amsterdam, whereas the baseline
shows the Incoterm FCA Johannesburg.

The matching application will compare the submitted data sets with the related baseline and will inform the submitter
of the data sets, that is the seller's bank, and the counterparty, that is the buyer's bank (ADIABE22), about the
matching result by sending a DataSetMatchReport message (see business example).

Furthermore, the matching application will pass on the data set information to the buyer's bank by sending a
ForwardDataSetSubmissionReport message (see business example).

A second instance is provided as an example of a data set submission containing invoice, transport, insurance and
certificate information.

Page 80 Message Definition Report Part 1

Examples

6.14.1 XML Instance 1

<DataSetSubmissn>
<SubmissnId>
<Id>DSSMessage12</Id>
<CreDtTm>2009-08-31T13:21:00</CreDtTm>
</SubmissnId>
<RltdTxRefs>
<TxId>01190799181-6940-48</TxId>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>
<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<ForcdMtch>false</ForcdMtch>
</RltdTxRefs>
<CmonSubmissnRef>
<Id>INV20090050946</Id>
</CmonSubmissnRef>
<Instr>
<Tp>MTCH</Tp>
</Instr>
<BuyrBk>
<BIC>ADIABE22</BIC>
</BuyrBk>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<ComrclDataSet>
<DataSetId>
<Id>CONINV20090050946/0830B</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</DataSetId>
<ComrclDocRef>
<InvcNb>INV20090050946</InvcNb>
<IsseDt>2009-08-30</IsseDt>
</ComrclDocRef>
<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<Goods>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>
<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<FnlSubmissn>false</FnlSubmissn>
<ComrclLineItms>
<LineItmId>2</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>

20 February 2015 Page 81

Trade Services Management November 2015

<Amt Ccy="USD">6205.00</Amt>
</UnitPric>
<PdctNm>Princess shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PR</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.0</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>G</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>WSI</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>princess</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<PdctOrgn>ZA</PdctOrgn>
<TtlAmt Ccy="USD">155125.00</TtlAmt>
</ComrclLineItms>
<ComrclLineItms>
<LineItmId>3</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>10</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">7788.00</Amt>
</UnitPric>
<PdctNm>Pear shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PE</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.5</Id>
<IdTp>carat</IdTp>

Page 82 Message Definition Report Part 1

Examples

</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>H</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>SI1</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>pear</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<TtlAmt Ccy="USD">77880.00</TtlAmt>
</ComrclLineItms>
<LineItmsTtlAmt Ccy="USD">233005.00</LineItmsTtlAmt>
<TtlNetAmt Ccy="USD">233005.00</TtlNetAmt>
<Incotrms>
<IncotrmsCd>
<Cd>FCA</Cd>
</IncotrmsCd>
<Lctn>Amsterdam</Lctn>
</Incotrms>
</Goods>
<PmtTerms>
<PmtTerms>
<PmtCd>
<Cd>CASH</Cd>
</PmtCd>
</PmtTerms>
<AmtOrPctg>
<Amt Ccy="USD">233005.00</Amt>
</AmtOrPctg>
</PmtTerms>
<SttlmTerms>
<CdtrAcct>
<Id>
<IBAN>ZA7757935JJ2435</IBAN>
</Id>
<Nm>Gem Grafting and Export Ltd.</Nm>
</CdtrAcct>
</SttlmTerms>
</ComrclDataSet>
<TrnsprtDataSet>
<DataSetId>
<Id>CONTRPAWB20090046897/0830B</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</DataSetId>
<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>

20 February 2015 Page 83

Trade Services Management November 2015

<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<Consgnr>
<Nm>General Export</Nm>
<PstlAdr>
<Ctry>ZA</Ctry>
</PstlAdr>
</Consgnr>
<TrnsprtInf>
<TrnsprtDocRef>
<Id>AWB20090046897</Id>
<DtOfIsse>2009-08-30</DtOfIsse>
</TrnsprtDocRef>
<TrnsprtdGoods>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>
<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<GoodsAndOrSvcsDesc>Raw Diamonds</GoodsAndOrSvcsDesc>
</TrnsprtdGoods>
<RtgSummry>
<IndvTrnsprt>
<TrnsprtByAir>
<DprtureAirprt>
<OthrAirprtDesc>
<Twn>Johannesburg</Twn>
</OthrAirprtDesc>
</DprtureAirprt>
<DstnAirprt>
<OthrAirprtDesc>
<Twn>Amsterdam</Twn>
</OthrAirprtDesc>
</DstnAirprt>
</TrnsprtByAir>
</IndvTrnsprt>
</RtgSummry>
<ShipmntDt>
<ActlShipmntDt>2009-08-30</ActlShipmntDt>
</ShipmntDt>
</TrnsprtInf>
</TrnsprtDataSet>
</DataSetSubmissn>

6.14.2 XML Instance 2

Page 84 Message Definition Report Part 1

Examples

<Tp>MTCH</Tp>
</Instr>
<BuyrBk>
<BIC>ADIABE22</BIC>
</BuyrBk>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<ComrclDataSet>
<DataSetId>
<Id>CONINV20090050946/0830B</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</DataSetId>
<ComrclDocRef>
<InvcNb>INV20090050946</InvcNb>
<IsseDt>2009-08-30</IsseDt>
</ComrclDocRef>
<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<Goods>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>
<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<FnlSubmissn>false</FnlSubmissn>
<ComrclLineItms>
<LineItmId>2</LineItmId>
<Qty>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
<Val>25</Val>
</Qty>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
<Amt Ccy = "USD">6205.00</Amt>
</UnitPric>
<PdctNm>Princess shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PR</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.0</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>G</Id>

20 February 2015 Page 85

Trade Services Management November 2015

<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>WSI</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>princess</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<PdctOrgn>ZA</PdctOrgn>
<TtlAmt Ccy = "USD">155125.00</TtlAmt>
</ComrclLineItms>
<ComrclLineItms>
<LineItmId>3</LineItmId>
<Qty>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
<Val>10</Val>
</Qty>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
<Amt Ccy = "USD">7788.00</Amt>
</UnitPric>
<PdctNm>Pear shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PE</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.5</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>H</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>SI1</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>pear</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<TtlAmt Ccy = "USD">77880.00</TtlAmt>
</ComrclLineItms>
<LineItmsTtlAmt Ccy = "USD">233005.00</LineItmsTtlAmt>
<Incotrms>
<Cd>FCA</Cd>
<Lctn>Amsterdam</Lctn>
</Incotrms>
<TtlNetAmt Ccy = "USD">233005.00</TtlNetAmt>
</Goods>

Page 86 Message Definition Report Part 1

Examples

<PmtTerms>
<PmtCd>
<Cd>CASH</Cd>
</PmtCd>
<Amt Ccy = "USD">233005.00</Amt>
</PmtTerms>
<SttlmTerms>
<CdtrAcct>
<Id>
<IBAN>ZA7757935JJ2435</IBAN>
</Id>
<Nm>Gem Grafting and Export Ltd.</Nm>
</CdtrAcct>
</SttlmTerms>
</ComrclDataSet>
<TrnsprtDataSet>
<DataSetId>
<Id>CONTRPAWB20090046897/0830B</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</DataSetId>
<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<Consgnr>
<Nm>General Export</Nm>
<PstlAdr>
<Ctry>ZA</Ctry>
</PstlAdr>
</Consgnr>
<TrnsprtInf>
<TrnsprtDocRef>
<Id>AWB20090046897</Id>
<DtOfIsse>2009-08-30</DtOfIsse>
</TrnsprtDocRef>
<TrnsprtdGoods>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>
<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<GoodsAndOrSvcsDesc>Raw Diamonds</GoodsAndOrSvcsDesc>
</TrnsprtdGoods>
<Consgnmt/>
<RtgSummry>
<IndvTrnsprt>
<TrnsprtByAir>
<DprtureAirprt>
<OthrAirprtDesc>
<Twn>Johannesburg</Twn>
</OthrAirprtDesc>
</DprtureAirprt>
<DstnAirprt>
<OthrAirprtDesc>

20 February 2015 Page 87

Trade Services Management November 2015

<Twn>Amsterdam</Twn>
</OthrAirprtDesc>
</DstnAirprt>
</TrnsprtByAir>
</IndvTrnsprt>
</RtgSummry>
<ActlShipmntDt>2009-08-30</ActlShipmntDt>
</TrnsprtInf>
</TrnsprtDataSet>
<InsrncDataSet>
<DataSetId>
<Id>INS245896542</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</DataSetId>
<Issr>
<Nm>Insurers United</Nm>
<PstlAdr>
<TwnNm>Cape Town</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Issr>
<IsseDt>2009-07-30</IsseDt>
<FctvDt>2009-08-15</FctvDt>
<InsrncDocId>INS245896542</InsrncDocId>
<Trnsprt>
<TrnsprtByAir>
<DprtureAirprt>
<OthrAirprtDesc>
<Twn>Johannesburg</Twn>
</OthrAirprtDesc>
</DprtureAirprt>
<DstnAirprt>
<OthrAirprtDesc>
<Twn>Amsterdam</Twn>
</OthrAirprtDesc>
</DstnAirprt>
</TrnsprtByAir>
</Trnsprt>
<InsrdAmt Ccy = "USD">250000</InsrdAmt>
<InsrncClauses>ICCA</InsrncClauses>
<Assrd>
<NmAndAdr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<Ctry>ZA</Ctry>
</PstlAdr>
</NmAndAdr>
</Assrd>
<ClmsPyblAt>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</ClmsPyblAt>
</InsrncDataSet>
<CertDataSet>
<DataSetId>
<Id>CERT/2652/4587/96</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</DataSetId>
<CertTp>QUAL</CertTp>
<CertfdChrtcs>

Page 88 Message Definition Report Part 1

Examples

<Qlty>PRIME GRADE</Qlty>
</CertfdChrtcs>
<IsseDt>2009-07-30</IsseDt>
<Issr>
<Nm>SGS</Nm>
<PstlAdr>
<StrtNm>1 place des Alpes</StrtNm>
<PstCdId>1211</PstCdId>
<TwnNm>Geneva</TwnNm>
<Ctry>CH</Ctry>
</PstlAdr>
</Issr>
<CertId>CERT/2652/4587/96</CertId>
</CertDataSet>
</DataSetSubmissn>

6.15 DeltaReport - tsmt.015.001.03

The following illustrates the listing of the differences between an established baseline and a newly proposed
baseline (amendment request).

In the scenario below the matching application informs the seller's and buyer's banks (ADIABE22, AFMBZAJJ) about
the differences between the established and newly proposed baseline as outlined in the
BaselineAmendmentRequest message sent by the buyer's bank (see business example).

The message shows the proposed extension of the latest shipment date and the change of the place of destination
by giving the actual and newly proposed value of the respective data elements. It requests (ReqForActn) the seller's
bank to accept or reject the amendment request by either sending an AmendmentAcceptance message (see
business example) or an AmendmentRejection message (see business example).

<DltaRpt>
<RptId>
<Id>DELMessage6</Id>
<CreDtTm>2009-07-08T09:14:00</CreDtTm>
</RptId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<EstblishdBaselnId>
<Id>01190799181-6940-48</Id>
<Vrsn>0</Vrsn>
</EstblishdBaselnId>
<TxSts>
<Sts>AMRQ</Sts>
</TxSts>
<AmdmntNb>
<Nb>1</Nb>
</AmdmntNb>
<UsrTxRef>
<Id>POS-ANT-IM-040705</Id>
<IdIssr>
<BIC>ADIABE22</BIC>
</IdIssr>
</UsrTxRef>
<UsrTxRef>
<Id>OAC-Ex-2009-07-05-JB</Id>
<IdIssr>
<BIC>AFMBZAJJ</BIC>
</IdIssr>
</UsrTxRef>

20 February 2015 Page 89

Trade Services Management November 2015

<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<BuyrBk>
<BIC>ADIABE22</BIC>
</BuyrBk>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<SubmitrPropsdBaselnRef>
<Id>PO200050615/003567</Id>
<Vrsn>2</Vrsn>
<Submitr>
<BIC>ADIABE22</BIC>
</Submitr>
</SubmitrPropsdBaselnRef>
<UpdtdElmt>
<ElmtSeqNb>1</ElmtSeqNb>
<ElmtPth>Goods/GoodsDesc/</ElmtPth>
<ElmtNm>LatstShipmntDt</ElmtNm>
<Rplcmnt>
<CurVal>2009-09-30</CurVal>
<PropsdVal>2009-10-15</PropsdVal>
</Rplcmnt>
</UpdtdElmt>
<UpdtdElmt>
<ElmtSeqNb>2</ElmtSeqNb>
<ElmtPth>RtgSummry/IndvTrnsprt/TrnsprtByAir/DstnAirprt/OthrAirprtDesc/</ElmtPth
>
<ElmtNm>Twn</ElmtNm>
<Rplcmnt>
<CurVal>Antwerp</CurVal>
<PropsdVal>Amsterdam</PropsdVal>
</Rplcmnt>
</UpdtdElmt>
<ReqForActn>
<Tp>ARBA</Tp>
</ReqForActn>
</DltaRpt>

6.16 ErrorReport - tsmt.016.001.03

The following illustrates the information about the inability of the matching application to process a received
message.

In below scenario the matching application informs the buyer's bank (ADIABE22) that it cannot process a message
(RjctdMsgRef) sent by the buyer's bank. The message identifies the reason for the inability to process the message
(ErrDesc).

Page 90 Message Definition Report Part 1

Examples

<Id>ERRMessage41</Id>
<CreDtTm>2009-09-05T08:53:00</CreDtTm>
</RptId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<RjctdMsgRef>
<Id>MMRMessage16</Id>
<CreDtTm>2009-09-05T08:52:00</CreDtTm>
</RjctdMsgRef>
<NbOfErrs>
<Nb>1</Nb>
</NbOfErrs>
<ErrDesc>
<SeqNb>1</SeqNb>
<RuleId>9423</RuleId>
<RuleDesc>Unexpected message</RuleDesc>
</ErrDesc>
</ErrRpt>

6.17 ForwardDataSetSubmissionReport - tsmt.017.001.05

The following illustrates the passing on of data set information that the matching application has received.

In the scenario below the matching application passes on the information in the DataSetSubmission message (see
business example) it received from the seller's bank (AFMBAZJJ) to the buyer's bank (ADIABE22).

The message conveys all information included in the DataSetSubmission message plus information on the action
that the buyer's bank is expected to take (ReqForActn).

In the outlined scenario, the buyer's bank is expected to either accept (see business example MisMatchAcceptance)
or reject (see business example MisMatchRejection) the data sets.

<FwdDataSetSubmissnRpt>
<RptId>
<Id>FDSMessage13</Id>
<CreDtTm>2009-08-31T13:23:00</CreDtTm>
</RptId>
<RltdTxRefs>
<TxId>01190799181-6940-48</TxId>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>
<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<ForcdMtch>false</ForcdMtch>
<EstblishdBaselnId>
<Id>01190799181-6940-48</Id>
<Vrsn>1</Vrsn>
</EstblishdBaselnId>
<TxSts>ACTV</TxSts>
</RltdTxRefs>
<CmonSubmissnRef>
<Id>INV20090050946</Id>
</CmonSubmissnRef>
<Submitr>
<BIC>ADIABE22</BIC>
</Submitr>
<BuyrBk>

20 February 2015 Page 91

Trade Services Management November 2015

<BIC>ADIABE22</BIC>
</BuyrBk>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<ComrclDataSet>
<DataSetId>
<Id>CONINV20090050946/0830B</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</DataSetId>
<ComrclDocRef>
<InvcNb>INV20090050946</InvcNb>
<IsseDt>2009-08-30</IsseDt>
</ComrclDocRef>
<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<Goods>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>
<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<FnlSubmissn>false</FnlSubmissn>
<ComrclLineItms>
<LineItmId>2</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>25</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">6205.00</Amt>
</UnitPric>
<PdctNm>Princess shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PR</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.0</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>

Page 92 Message Definition Report Part 1

Examples

<Id>G</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>WSI</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>princess</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<PdctOrgn>ZA</PdctOrgn>
<TtlAmt Ccy="USD">155125.00</TtlAmt>
</ComrclLineItms>
<ComrclLineItms>
<LineItmId>3</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>10</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">7788.00</Amt>
</UnitPric>
<PdctNm>Pear shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PE</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.5</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>H</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>SI1</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>pear</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<TtlAmt Ccy="USD">77880.00</TtlAmt>
</ComrclLineItms>
<LineItmsTtlAmt Ccy="USD">233005.00</LineItmsTtlAmt>
<TtlNetAmt Ccy="USD">233005.00</TtlNetAmt>

20 February 2015 Page 93

Trade Services Management November 2015

<Incotrms>
<IncotrmsCd>
<Cd>FCA</Cd>
</IncotrmsCd>
<Lctn>Amsterdam</Lctn>
</Incotrms>
</Goods>
<PmtTerms>
<PmtTerms>
<PmtCd>
<Cd>CASH</Cd>
</PmtCd>
</PmtTerms>
<AmtOrPctg>
<Amt Ccy="USD">233005.00</Amt>
</AmtOrPctg>
</PmtTerms>
<SttlmTerms>
<CdtrAcct>
<Id>
<IBAN>ZA7757935JJ2435</IBAN>
</Id>
<Nm>Gem Grafting and Export Ltd.</Nm>
</CdtrAcct>
</SttlmTerms>
</ComrclDataSet>
<TrnsprtDataSet>
<DataSetId>
<Id>CONTRPAWB20090046897/0830B</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</DataSetId>
<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<Consgnr>
<Nm>General Export</Nm>
<PstlAdr>
<Ctry>ZA</Ctry>
</PstlAdr>
</Consgnr>
<TrnsprtInf>
<TrnsprtDocRef>
<Id>AWB20090046897</Id>
<DtOfIsse>2009-08-30</DtOfIsse>
</TrnsprtDocRef>
<TrnsprtdGoods>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>
<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<GoodsAndOrSvcsDesc>Raw Diamonds</GoodsAndOrSvcsDesc>
</TrnsprtdGoods>

Page 94 Message Definition Report Part 1

Examples

<RtgSummry>
<IndvTrnsprt>
<TrnsprtByAir>
<DprtureAirprt>
<OthrAirprtDesc>
<Twn>Johannesburg</Twn>
</OthrAirprtDesc>
</DprtureAirprt>
<DstnAirprt>
<OthrAirprtDesc>
<Twn>Amsterdam</Twn>
</OthrAirprtDesc>
</DstnAirprt>
</TrnsprtByAir>
</IndvTrnsprt>
</RtgSummry>
<ShipmntDt>
<ActlShipmntDt>2009-08-30</ActlShipmntDt>
</ShipmntDt>
</TrnsprtInf>
</TrnsprtDataSet>
</FwdDataSetSubmissnRpt>

6.18 FullPushThroughReport - tsmt.018.001.05

The following illustrates the passing on of baseline information that the matching application has received.

In the scenario below the matching application passes on the information of an InitialBaselineSubmission message
(see business example) that it has received from the buyer's bank (ADIABE22) to the seller's bank (AFMBZAJJ).

The message conveys all information included in the InitialBaselineSubmission message plus a transaction
identification (TxId) assigned by the matching application to the transaction.

The receiver of the message is expected to respond with a BaselineReSubmission message (see business example)
which contains matching information in order to establish the transaction in the matching application.

<FullPushThrghRpt>
<RptId>
<Id>FPTMessage10</Id>
<CreDtTm>2009-07-04T11:02:00</CreDtTm>
</RptId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<TxSts>
<Sts>PROP</Sts>
</TxSts>
<RptPurp>
<Tp>FWIS</Tp>
</RptPurp>
<PushdThrghBaseln>
<SubmitrBaselnId>
<Id>PO20090615/003567</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>ADIABE22</BIC>
</Submitr>
</SubmitrBaselnId>
<SvcCd>LEV1</SvcCd>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>
<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<Buyr>

20 February 2015 Page 95

Trade Services Management November 2015

<Nm>Diamant Import NV</Nm>

<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<BuyrBk>
<BIC>ADIABE22</BIC>
</BuyrBk>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<Goods>
<GoodsAndOrSvcsDesc>Raw Diamonds</GoodsAndOrSvcsDesc>
<PrtlShipmnt>true</PrtlShipmnt>
<TrnsShipmnt>false</TrnsShipmnt>
<ShipmntDtRg>
<LatstShipmntDt>2009-10-15</LatstShipmntDt>
</ShipmntDtRg>
<LineItmDtls>
<LineItmId>1</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>20</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">4473.00</Amt>
</UnitPric>
<PdctNm>Round shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>RO</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>0.7</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>E</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>IF</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>

Page 96 Message Definition Report Part 1

Examples

<OthrPdctCtgy>
<Id>brilliant</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<PdctOrgn>ZA</PdctOrgn>
<TtlAmt Ccy="USD">89460.00</TtlAmt>
</LineItmDtls>
<LineItmDtls>
<LineItmId>2</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>25</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">6205.00</Amt>
</UnitPric>
<PdctNm>Princess shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PR</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.0</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>G</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>WSI</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>princess</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<PdctOrgn>ZA</PdctOrgn>
<TtlAmt Ccy="USD">155125.00</TtlAmt>
</LineItmDtls>
<LineItmDtls>
<LineItmId>3</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>10</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>

20 February 2015 Page 97

Trade Services Management November 2015

<Amt Ccy="USD">7788.00</Amt>
</UnitPric>
<PdctNm>Pear shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PE</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.5</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>H</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>SI1</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>pear</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<TtlAmt Ccy="USD">77880.00</TtlAmt>
</LineItmDtls>
<LineItmsTtlAmt Ccy="USD">322465.00</LineItmsTtlAmt>
<RtgSummry>
<IndvTrnsprt>
<TrnsprtByAir>
<DprtureAirprt>
<OthrAirprtDesc>
<Twn>Johannesburg</Twn>
</OthrAirprtDesc>
</DprtureAirprt>
<DstnAirprt>
<OthrAirprtDesc>
<Twn>Amsterdam</Twn>
</OthrAirprtDesc>
</DstnAirprt>
</TrnsprtByAir>
</IndvTrnsprt>
</RtgSummry>
<Incotrms>
<IncotrmsCd>
<Cd>FCA</Cd>
</IncotrmsCd>
<Lctn>Amsterdam</Lctn>
</Incotrms>
<TtlNetAmt Ccy="USD">322465.00</TtlNetAmt>
</Goods>
<PmtTerms>
<PmtTerms>
<PmtCd>
<Cd>CASH</Cd>
</PmtCd>
</PmtTerms>
<AmtOrPctg>
<Amt Ccy="USD">322465.00</Amt>

Page 98 Message Definition Report Part 1

Examples

</AmtOrPctg>
</PmtTerms>
<SttlmTerms>
<CdtrAcct>
<Id>
<IBAN>ZA7757935JJ2435</IBAN>
</Id>
<Nm>Gem Grafting and Export Ltd.</Nm>
</CdtrAcct>
</SttlmTerms>
<ComrclDataSetReqrd>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</ComrclDataSetReqrd>
<TrnsprtDataSetReqrd>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</TrnsprtDataSetReqrd>
<InttToPayXpctd>true</InttToPayXpctd>
</PushdThrghBaseln>
<BuyrCtctPrsn>
<Nm>Vandamme</Nm>
<NmPrfx>MIST</NmPrfx>
<GvnNm>Peter</GvnNm>
<EmailAdr>Peter.Vandamme@Dimimp.be</EmailAdr>
</BuyrCtctPrsn>
<SellrCtctPrsn>
<Nm>Mondu</Nm>
<NmPrfx>MIST</NmPrfx>
<GvnNm>Thomas</GvnNm>
<EmailAdr>Thomas.Mondu@Gemexp.za</EmailAdr>
</SellrCtctPrsn>
<BuyrBkCtctPrsn>
<Nm>Poncelet</Nm>
<NmPrfx>MISS</NmPrfx>
<GvnNm>Claire</GvnNm>
<EmailAdr>Claire.Poncelet@Antwerp_Diamantbk.be</EmailAdr>
</BuyrBkCtctPrsn>
</FullPushThrghRpt>

6.19 InitialBaselineSubmission - tsmt.019.001.05

The following illustrates the creation of a transaction in the matching application.

In the scenario below the buyer's bank (ADIABE22) submits details of the purchasing agreement, negotiated
between buyer (Diamant Import NV, Antwerp, Belgium) and seller (Gem Grafting and Export Ltd., Johannesburg,
South Africa), to the matching application with the instruction push-through.

In addition to the buyer's bank references and the purchasing agreement reference, the message conveys an
exhaustive description of the goods ordered, details regarding the conveyance of the products and information
regarding the settlement conditions of the purchase.

The matching application will acknowledge the receipt of the buyer's bank message by sending an
Acknowledgement message (see business example) and will pass on the information to the seller's bank by sending
a FullPushThroughReport message (see business example).

This baseline requires invoice and transport information for later matching. A second example is provided, of a
baseline that requires invoice, transport, insurance and certificate information.

20 February 2015 Page 99

Trade Services Management November 2015

6.19.1 XML Instance 1

<InitlBaselnSubmissn>
<SubmissnId>
<Id>IBSMessage1</Id>
<CreDtTm>2009-07-04T11:02:00</CreDtTm>
</SubmissnId>
<SubmitrTxRef>
<Id>OS-ANT-IM-040705P</Id>
</SubmitrTxRef>
<Instr>
<Tp>FPTR</Tp>
</Instr>
<Baseln>
<SubmitrBaselnId>
<Id>PO20090615/003567</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>ADIABE22</BIC>
</Submitr>
</SubmitrBaselnId>
<SvcCd>LEV1</SvcCd>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>
<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<BuyrBk>
<BIC>ADIABE22</BIC>
</BuyrBk>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<Goods>
<GoodsAndOrSvcsDesc>Raw Diamonds</GoodsAndOrSvcsDesc>
<PrtlShipmnt>true</PrtlShipmnt>
<TrnsShipmnt>false</TrnsShipmnt>
<ShipmntDtRg>
<LatstShipmntDt>2009-10-15</LatstShipmntDt>
</ShipmntDtRg>
<LineItmDtls>
<LineItmId>1</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>20</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">4473.00</Amt>

Page 100 Message Definition Report Part 1

Examples

</UnitPric>
<PdctNm>Round shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>RO</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>0.7</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>E</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>IF</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>brilliant</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<PdctOrgn>ZA</PdctOrgn>
<TtlAmt Ccy="USD">89460.00</TtlAmt>
</LineItmDtls>
<LineItmDtls>
<LineItmId>2</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>25</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">6205.00</Amt>
</UnitPric>
<PdctNm>Princess shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PR</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.0</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>G</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>

20 February 2015 Page 101

Trade Services Management November 2015

<PdctChrtcs>
<OthrPdctChrtcs>
<Id>WSI</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>princess</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<PdctOrgn>ZA</PdctOrgn>
<TtlAmt Ccy="USD">155125.00</TtlAmt>
</LineItmDtls>
<LineItmDtls>
<LineItmId>3</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>10</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">7788.00</Amt>
</UnitPric>
<PdctNm>Pear shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PE</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.5</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>H</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>SI1</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>pear</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<TtlAmt Ccy="USD">77880.00</TtlAmt>
</LineItmDtls>
<LineItmsTtlAmt Ccy="USD">322465.00</LineItmsTtlAmt>
<RtgSummry>
<IndvTrnsprt>
<TrnsprtByAir>
<DprtureAirprt>
<OthrAirprtDesc>

Page 102 Message Definition Report Part 1

Examples

<Twn>Johannesburg</Twn>
</OthrAirprtDesc>
</DprtureAirprt>
<DstnAirprt>
<OthrAirprtDesc>
<Twn>Amsterdam</Twn>
</OthrAirprtDesc>
</DstnAirprt>
</TrnsprtByAir>
</IndvTrnsprt>
</RtgSummry>
<Incotrms>
<IncotrmsCd>
<Cd>FCA</Cd>
</IncotrmsCd>
<Lctn>Amsterdam</Lctn>
</Incotrms>
<TtlNetAmt Ccy="USD">322465.00</TtlNetAmt>
</Goods>
<PmtTerms>
<PmtTerms>
<PmtCd>
<Cd>CASH</Cd>
</PmtCd>
</PmtTerms>
<AmtOrPctg>
<Amt Ccy="USD">322465.00</Amt>
</AmtOrPctg>
</PmtTerms>
<SttlmTerms>
<CdtrAcct>
<Id>
<IBAN>ZA7757935JJ2435</IBAN>
</Id>
<Nm>Gem Grafting and Export Ltd.</Nm>
</CdtrAcct>
</SttlmTerms>
<ComrclDataSetReqrd>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</ComrclDataSetReqrd>
<TrnsprtDataSetReqrd>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</TrnsprtDataSetReqrd>
<InttToPayXpctd>true</InttToPayXpctd>
</Baseln>
<BuyrCtctPrsn>
<Nm>Vandamme</Nm>
<NmPrfx>MIST</NmPrfx>
<GvnNm>Peter</GvnNm>
<EmailAdr>Peter.Vandamme@Dimimp.be</EmailAdr>
</BuyrCtctPrsn>
<SellrCtctPrsn>
<Nm>Mondu</Nm>
<NmPrfx>MIST</NmPrfx>
<GvnNm>Thomas</GvnNm>
<EmailAdr>Thomas.Mondu@Gemexp.za</EmailAdr>
</SellrCtctPrsn>
<BkCtctPrsn>
<BuyrBkCtctPrsn>
<Nm>Poncelet</Nm>
<NmPrfx>MISS</NmPrfx>
<GvnNm>Claire</GvnNm>
<EmailAdr>Claire.Poncelet@Antwerp_Diamantbk.be</EmailAdr>
</BuyrBkCtctPrsn>

20 February 2015 Page 103

Trade Services Management November 2015

</BkCtctPrsn>
</InitlBaselnSubmissn>

6.19.2 XML Instance 2

<InitlBaselnSubmissn>
<SubmissnId>
<Id>IBSMessage1</Id>
<CreDtTm>2009-07-04T11:02:00</CreDtTm>
</SubmissnId>
<SubmitrTxRef>
<Id>OS-ANT-IM-040705P</Id>
</SubmitrTxRef>
<Instr>
<Tp>FPTR</Tp>
</Instr>
<Baseln>
<SubmitrBaselnId>
<Id>PO20090615/003567</Id>
<Vrsn>1</Vrsn>
<Submitr>
<BIC>ADIABE22</BIC>
</Submitr>
</SubmitrBaselnId>
<SvcCd>LEV1</SvcCd>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>
<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>
<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<BuyrBk>
<BIC>ADIABE22</BIC>
</BuyrBk>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<Goods>
<GoodsAndOrSvcsDesc>Raw Diamonds</GoodsAndOrSvcsDesc>
<PrtlShipmnt>true</PrtlShipmnt>
<TrnsShipmnt>false</TrnsShipmnt>
<ShipmntDtRg>
<LatstShipmntDt>2009-09-30</LatstShipmntDt>
</ShipmntDtRg>
<LineItmDtls>
<LineItmId>1</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>20</Val>
</Qty>

Page 104 Message Definition Report Part 1

Examples

<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">4473.00</Amt>
</UnitPric>
<PdctNm>Round shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>RO</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>0.7</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>E</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>IF</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>brilliant</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<PdctOrgn>ZA</PdctOrgn>
<TtlAmt Ccy="USD">89460.00</TtlAmt>
</LineItmDtls>
<LineItmDtls>
<LineItmId>2</LineItmId>
<Qty>
<UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>25</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">6205.00</Amt>
</UnitPric>
<PdctNm>Princess shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PR</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.0</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>

20 February 2015 Page 105

Trade Services Management November 2015

<OthrPdctChrtcs>
<Id>G</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>WSI</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>princess</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<PdctOrgn>ZA</PdctOrgn>
<TtlAmt Ccy="USD">155125.00</TtlAmt>
</LineItmDtls>
<LineItmDtls>
<LineItmId>3</LineItmId>
<Qty><UnitOfMeasr>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitOfMeasr>
<Val>10</Val>
</Qty>
<UnitPric>
<UnitPric>
<UnitOfMeasrCd>EA</UnitOfMeasrCd>
</UnitPric>
<Amt Ccy="USD">7788.00</Amt>
</UnitPric>
<PdctNm>Pear shape</PdctNm>
<PdctIdr>
<OthrPdctIdr>
<Id>PE</Id>
<IdTp>shape</IdTp>
</OthrPdctIdr>
</PdctIdr>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>1.5</Id>
<IdTp>carat</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>H</Id>
<IdTp>color</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctChrtcs>
<OthrPdctChrtcs>
<Id>SI1</Id>
<IdTp>clarity</IdTp>
</OthrPdctChrtcs>
</PdctChrtcs>
<PdctCtgy>
<OthrPdctCtgy>
<Id>pear</Id>
<IdTp>cut</IdTp>
</OthrPdctCtgy>
</PdctCtgy>
<TtlAmt Ccy="USD">77880.00</TtlAmt>
</LineItmDtls>
<LineItmsTtlAmt Ccy="USD">322465.00</LineItmsTtlAmt>
<RtgSummry>

Page 106 Message Definition Report Part 1

Examples

<IndvTrnsprt>
<TrnsprtByAir>
<DprtureAirprt>
<OthrAirprtDesc>
<Twn>Johannesburg</Twn>
</OthrAirprtDesc>
</DprtureAirprt>
<DstnAirprt>
<OthrAirprtDesc>
<Twn>Brussels</Twn>
</OthrAirprtDesc>
</DstnAirprt>
</TrnsprtByAir>
</IndvTrnsprt>
</RtgSummry>
<Incotrms>
<IncotrmsCd>
<Cd>FCA</Cd>
</IncotrmsCd>
<Lctn>Amsterdam</Lctn>
</Incotrms>
<TtlNetAmt Ccy="USD">322465.00</TtlNetAmt>
</Goods>
<PmtTerms>
<PmtTerms>
<PmtCd>
<Cd>CASH</Cd>
</PmtCd>
</PmtTerms>
<AmtOrPctg>
<Amt Ccy="USD">322465.00</Amt>
</AmtOrPctg>
</PmtTerms>
<SttlmTerms>
<CdtrAcct>
<Id>
<IBAN>ZA7757935JJ2435</IBAN>
</Id>
<Nm>Gem Grafting and Export Ltd.</Nm>
</CdtrAcct>
</SttlmTerms>
<PmtOblgtn>
<OblgrBk>
<BIC>ADIABE22</BIC>
</OblgrBk>
<RcptBk>
<BIC>AFMBZAJJ</BIC>
</RcptBk>
<PmtOblgtnAmt>
<Amt Ccy="USD">322465.00</Amt>
</PmtOblgtnAmt>
<XpryDt>2009-11-30</XpryDt>
<PmtTerms>
<PmtTerms>
<PmtCd>
<Cd>EMTD</Cd>
</PmtCd>
</PmtTerms><AmtOrPctg>
<Pctg>1</Pctg>
</AmtOrPctg>

</PmtTerms>
</PmtOblgtn>
<ComrclDataSetReqrd>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
</ComrclDataSetReqrd>

20 February 2015 Page 107

Trade Services Management November 2015

<InsrncDataSetReqrd>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
<MtchIsseDt>true</MtchIsseDt>
<MtchTrnsprt>false</MtchTrnsprt>
<MtchAmt>false</MtchAmt>
</InsrncDataSetReqrd>
<CertDataSetReqrd>
<Submitr>
<BIC>AFMBZAJJ</BIC>
</Submitr>
<CertTp>QUAL</CertTp>
<MtchIsseDt>true</MtchIsseDt>
<MtchInspctnDt>true</MtchInspctnDt>
<AuthrsdInspctrInd>false</AuthrsdInspctrInd>
<MtchConsgn>false</MtchConsgn>
</CertDataSetReqrd>
<InttToPayXpctd>true</InttToPayXpctd>
</Baseln>
<BuyrCtctPrsn>
<Nm>Vandamme</Nm>
<NmPrfx>MIST</NmPrfx>
<GvnNm>Peter</GvnNm>
<EmailAdr>Peter.Vandamme@Dimimp.be</EmailAdr>
</BuyrCtctPrsn>
<SellrCtctPrsn>
<Nm>Mondu</Nm>
<NmPrfx>MIST</NmPrfx>
<GvnNm>Thomas</GvnNm>
<EmailAdr>Thomas.Mondu@Gemexp.za</EmailAdr>
</SellrCtctPrsn><BkCtctPrsn>
<BuyrBkCtctPrsn>
<Nm>Poncelet</Nm>
<NmPrfx>MISS</NmPrfx>
<GvnNm>Claire</GvnNm>
<EmailAdr>Claire.Poncelet@Antwerp_Diamantbk.be</EmailAdr>
</BuyrBkCtctPrsn>
</BkCtctPrsn>
</InitlBaselnSubmissn>

6.20 MisMatchAcceptance - tsmt.020.001.02

The following illustrates the acceptance of mis-matched data sets.

In the scenario below the buyer's bank (ADIABE22) accepts the mis-matched data sets submitted with a
DataSetSubmission message (see business example) by the seller's bank (AFMBZAJJ) and forwarded to the
buyer's bank by the matching application with a ForwardDataSetSubmissionReport message (see business
example).

The message specifies the DataSetMatchReport message that it relates to (DataSetMtchRptRef), that is the mis-
matched data sets which are accepted by submitting this message.

The matching application will convey the information about the acceptance of the mis-matched data sets by sending
a MisMatchAcceptanceNotification message (see business example) to the submitter of the mis-matched data sets,
that is, the seller's bank.

Furthermore, it will report on the actual value of the dynamic part of the baseline (goods component) by sending a
BaselineReport message (see business example) to the seller's and buyer's banks.

The rejection of mis-matched data sets can be achieved by submitting a MisMatchRejection message (see business
example).

Page 108 Message Definition Report Part 1

Examples

<AccptncId>
<Id>MMAMessage15</Id>
<CreDtTm>2009-09-07T08:52:00</CreDtTm>
</AccptncId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<DataSetMtchRptRef>
<Id>DMRMessage14</Id>
<CreDtTm>2009-08-31T13:24:00</CreDtTm>
</DataSetMtchRptRef>
</MisMtchAccptnc>

6.21 MisMatchAcceptanceNotification - tsmt.021.001.03

The following illustrates the notification of an acceptance of mis-matched data sets.

In the scenario below the matching application informs the seller's bank (AFMBZAJJ), that is, the submitter of the
DataSetSubmission message (see business example), that the buyer's bank (ADIABE22) has accepted the mis-
matched data sets (see business example MisMatchAcceptance).

The message specifies the DataSetMatchReport (DataSetMtchRptRef) that it relates to, that is the mis-matched data
sets which have been accepted by the buyer's bank.

The matching application will inform about the rejection of mis-matched data sets by sending a
MisMatchRejectionNotification message (see business example).

<MisMtchAccptncNtfctn>
<NtfctnId>
<Id>MANMessage17</Id>
<CreDtTm>2009-09-07T08:54:00</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<EstblishdBaselnId>
<Id>01190799181-6940-48</Id>
<Vrsn>1</Vrsn>
</EstblishdBaselnId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<DataSetMtchRptRef>
<Id>DMRMessage14</Id>
<CreDtTm>2009-08-31T13:24:00</CreDtTm>
</DataSetMtchRptRef>
</MisMtchAccptncNtfctn>

6.22 MisMatchRejection - tsmt.022.001.02

The following illustrates the rejection of mis-matched data sets.

In the scenario below the buyer's bank (ADIABE22) rejects the mis-matched data sets submitted with a
DataSetSubmission message (see business example) by the seller's bank (AFMBZAJJ) and forwarded to buyer's bank
by the matching application with a ForwardDataSetSubmissionReport message (see business example).

The message specifies the DataSetMatchReport message that it relates to (DataSetMtchRptRef), that is, the mis-
matched data sets which are rejected by submitting this message and the reason for the rejection of the data sets
(RjctnRsn).

20 February 2015 Page 109

Trade Services Management November 2015

The matching application will convey the information about the rejection of the mis-matched data sets by sending a
MisMatchRejectionNotification message (see business example) to the submitter of the mis-matched data sets, that
is, the seller's bank.

The acceptance of mis-matched data sets can be achieved by submitting a MisMatchAcceptance message (see
business example).

<MisMtchRjctn>
<RjctnId>
<Id>MMRMessage16</Id>
<CreDtTm>2009-09-07T08:52:00</CreDtTm>
</RjctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<DataSetMtchRptRef>
<Id>DMRMessage14</Id>
<CreDtTm>2009-08-31T13:24:00</CreDtTm>
</DataSetMtchRptRef>
<RjctnRsn>
<RjctdElmt>
<ElmtSeqNb>1</ElmtSeqNb>
<IndvRjctnRsn>Difference in Incoterms is not acceptable</IndvRjctnRsn>
</RjctdElmt>
</RjctnRsn>
</MisMtchRjctn>

6.23 MisMatchRejectionNotification - tsmt.023.001.03

The following illustrates the notification of a rejection of mis-matched data sets.

In the scenario below the matching application informs the seller's bank (AFMBZAJJ), that is the submitter of the
DataSetSubmission message (see business example), that the buyer's bank (ADIABE22) has rejected the mis-
matched data sets (see business example MisMatchRejection).

The message specifies the DataSetMatchReport message (DataSetMtchRptRef) that it relates to, that is the mis-
matched data sets which have been rejected by the buyer's bank and the reason for the rejection of the data sets
(RjctnRsn).

The matching application will inform about the acceptance of mis-matched data sets by sending a
MisMatchAcceptanceNotification message (see business example).

<MisMtchRjctnNtfctn>
<NtfctnId>
<Id>MRNMessage18</Id>
<CreDtTm>2009-09-07T08:54:00</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<EstblishdBaselnId>
<Id>01190799181-6940-48</Id>
<Vrsn>1</Vrsn>
</EstblishdBaselnId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<DataSetMtchRptRef>
<Id>DMRMessage14</Id>
<CreDtTm>2009-08-31T13:24:00</CreDtTm>
</DataSetMtchRptRef>
<RjctnRsn>

Page 110 Message Definition Report Part 1

Examples

<RjctdElmt>
<ElmtSeqNb>1</ElmtSeqNb>
<IndvRjctnRsn>Difference in Incoterms is not acceptable</IndvRjctnRsn>
</RjctdElmt>
</RjctnRsn>
</MisMtchRjctnNtfctn>

6.24 ActionReminder - tsmt.024.001.04

The following illustrates a reminder for an action which has to be taken.

In the scenario below the matching application reminds the buyer's bank (ADIABE22) that it has to accept or reject
mis-matched data sets (PdgReqForActn).

The message specifies the related message in which the action was requested (MsgReqrngActn).

<ActnRmndr>
<RmndrId>
<Id>RFARMessage39</Id>
<CreDtTm>2009-09-07T06:00:00</CreDtTm>
</RmndrId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<MsgReqrngActn>
<Id>DMRMessage14</Id>
<CreDtTm>2009-08-31T13:24:00</CreDtTm>
</MsgReqrngActn>
<PdgReqForActn>
<Tp>ARDM</Tp>
</PdgReqForActn>
</ActnRmndr>

6.25 StatusChangeNotification - tsmt.025.001.03

The following illustrates the passing on of information on the acceptance of a request to change the status of a
transaction.

In the scenario below the matching application informs the buyer's bank (ADIABE22) that the seller's bank
(AFMBAZJJ) has accepted the request to change the status of the transaction (see business example
StatusChangeRequestAcceptance).

Furthermore, the same message is sent to the seller's bank (AFMBAZJJ) to confirm the completion of the request to
change the status of the transaction.

The message specifies the actual status of the transaction (TxSts).

The matching application will inform about the rejection of a request to change the status of a transaction by sending
a StatusChangeRequestRejectionNotification message (see business example).

<StsChngNtfctn>
<NtfctnId>
<Id>SCNMessage31</Id>
<CreDtTm>2009-09-16T09:37:00</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>

20 February 2015 Page 111

Trade Services Management November 2015

</TxId>
<TxSts>
<Sts>COMP</Sts>
</TxSts>
</StsChngNtfctn>

6.26 StatusChangeRequest - tsmt.025.001.03

The following illustrates the request to change the status of a transaction.

In the scenario below the buyer's bank (ADIABE22) requests to change the status of a transaction (TxId) to complete
(ReqdSts). The reason (ReqRsn) for the request that the bank states (ReqRsn) is that it does not expect any further
delivery for the transaction in question.

The matching application will acknowledge the receipt of the request to the buyer's bank by sending an
Acknowledgement message.

It will inform the counterpart (seller's bank) about the request by sending a StatusChangeRequestNotification
message (see business example).

<StsChngReq>
<ReqId>
<Id>SCRMessage27</Id>
<CreDtTm>2009-09-15T12:21:00</CreDtTm>
</ReqId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<ReqdSts>
<Sts>COMP</Sts>
</ReqdSts>
<ReqRsn>
<Desc>No further delivery expected</Desc>
</ReqRsn>
</StsChngReq>

6.27 StatusChangeRequestAcceptance - tsmt.027.001.02

The following illustrates the acceptance of a request to change the status of a transaction.

In the scenario below the seller's bank (AFMBZAJJ) accepts the request to change the status of a transaction
requested by the buyer's bank (ADIABE22) with a StatusChangeRequest message (see business example) and
passed on to the seller's bank by the matching application with a StatusChangeRequestNotification message (see
business example).

The message specifies the status of the transaction (AccptdSts) which has been accepted by the sender of the
message, that is, the seller's bank.

The matching application will convey the information about the acceptance of the request by sending a
StatusChangeNotification message (see business example) to the submitter of the request to change the status of
the transaction, that is, the buyer's bank.

Furthermore, the matching application sends the same message to the accepter of the request to change the status
of the transaction, that is, the seller's bank, to confirm the actual status of the transaction.

The rejection of a request to change the status of a transaction can be achieved by submitting a
StatusChangeRequestRejection message (see business example).

Page 112 Message Definition Report Part 1

Examples

<Id>SCRAMessage29</Id>
<CreDtTm>2009-09-16T09:36:00</CreDtTm>
</AccptncId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<AccptdSts>
<Sts>COMP</Sts>
</AccptdSts>
</StsChngReqAccptnc>

6.28 StatusChangeRequestNotification - tsmt.028.001.03

The following illustrates the passing on of information on the request to change the status of a transaction.

In the scenario below the matching application informs the seller's bank (AFMBZAJJ) that the buyer's bank
(ADIABE22) has requested a change in the status of a transaction by sending a StatusChangeRequest message
(see business example).

The message specifies the action that the seller's bank is expected to take (ReqForActn).

The seller's bank can either accept the request by sending a StatusChangeRequestAcceptance message (see
business example) or reject the request by sending a StatusChangeRequestRejection message (see business
example).

<StsChngReqNtfctn>
<NtfctnId>
<Id>SCRNMessage28</Id>
<CreDtTm>2009-09-15T12:22:00</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<PropsdStsChng>
<Sts>COMP</Sts>
</PropsdStsChng>
<Initr>
<BIC>ADIABE22</BIC>
</Initr>
</StsChngReqNtfctn>

6.29 StatusChangeRequestRejection - tsmt.029.001.02

The following illustrates the rejection of a status change request.

In the scenario below the seller's bank (AFMBZAJJ) rejects the request to change the status of a transaction that
was requested by the buyer's bank (ADIABE22) with a StatusChangeRequest message (see business example).

The request was passed on to the seller's bank by the matching application with a StatusChangeRequestNotification
message (see business example).

The message specifies the status of the transaction (RjctdStsChng) for which a change of the status has been
rejected by the sender of the message, that is the seller's bank and the reason for the request rejection (RjctnRsn).

The matching application will acknowledge the rejection of the request to change the status of the transaction to the
seller's bank by sending an Acknowledgement message. Furthermore, it will convey the information about the

20 February 2015 Page 113

Trade Services Management November 2015

rejection of the request by sending a StatusChangeRequestRejectionNotification message (see business example)

to the submitter of the request to change the status of the transaction, that is the buyer's bank.

The acceptance of a request to change the status of a transaction can be achieved by submitting a
StatusChangeRequestAcceptance message (see business example).

<StsChngReqRjctn>
<RjctnId>
<Id>SCRRMessage30</Id>
<CreDtTm>2009-09-16T09:36:00</CreDtTm>
</RjctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<RjctdStsChng>
<Sts>COMP</Sts>
</RjctdStsChng>
<RjctnRsn>
<Desc>One shipment outstanding</Desc>
</RjctnRsn>
</StsChngReqRjctn>

6.30 StatusChangeRequestRejectionNotification - tsmt.030.001.03

The following illustrates the passing on of information on the rejection of a request to change the status of a
transaction.

In the scenario below the matching application informs the buyer's bank (ADIABE22) that the seller's bank
(AFMBAZJJ) has rejected the request to change the status of the transaction (see business example
StatusChangeRequestRejection).

The message specifies the status of the transaction for which the request to change the status has been rejected
(RjctdStsChng) and the reason for the request rejection (RjctnRsn).

The matching application will inform about the acceptance of a request to change the status of a transaction by
sending a StatusChangeNotification message (see business example).

<StsChngReqRjctnNtfctn>
<NtfctnId>
<Id>SCRRNMessage32</Id>
<CreDtTm>2009-09-16T09:37:00</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<RjctdStsChng>
<Sts>COMP</Sts>
</RjctdStsChng>
<RjctnRsn>
<Desc>One shipment outstanding</Desc>
</RjctnRsn>
</StsChngReqRjctnNtfctn>

6.31 StatusExtensionRequestAcceptance - tsmt.031.001.03

The following illustrates the acceptance of a request to extend the status of a transaction.

Page 114 Message Definition Report Part 1

Examples

In the scenario below the seller's bank (AFMBZAJJ) accepts the request to extend the status of the transaction
requested by the buyer's bank (ADIABE22) with a StatusExtensionRequest message (see business example) and
passed on to the seller's bank by the matching application with a StatusExtensionRequestNotification message (see
business example).

The message specifies the status of the transaction (XtndedSts) for which the request to extend the status has been
accepted by the sender of the message, that is the seller's bank.

The matching application will convey the information about the acceptance of the request to extend the status of the
transaction by sending a StatusExtensionNotification message (see business example) to the submitter of the
request, that is, the buyer's bank.

Furthermore, the matching application will send the same message to the accepter of the request, that is, the seller's
bank, to confirm the actual status of the transaction.

The rejection of a request to extend the status of a transaction can be achieved by submitting a
StatusExtensionRejection message (see business example).

<StsXtnsnReqAccptnc>
<AccptncId>
<Id>SEAMessage35</Id>
<CreDtTm>2009-09-18T11:13:00</CreDtTm>
</AccptncId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<XtndedSts>
<Sts>ACTV</Sts>
</XtndedSts>
</StsXtnsnReqAccptnc>

6.32 StatusExtensionNotification - tsmt.032.001.03

The following illustrates the passing on of information on the acceptance of a request to extend the status of a
transaction.

In the scenario below the matching application informs the buyer's bank (ADIABE22) that the seller's bank
(AFMBAZJJ) has accepted the request to extend the status of the transaction (see business example
StatusExtensionAcceptance).

Furthermore, the same message is sent to the seller's bank (AFMBAZJJ) to confirm the extension of the status.

The message specifies the extended status of the transaction (XtndedSts) and the date (ChngDtTm) until when the
status is extended.

The matching application will inform about the rejection of a status extension request by sending a
StatusExtensionRejectionNotification message (see business example).

<StsXtnsnNtfctn>
<NtfctnId>
<Id>SENMessage37</Id>
<CreDtTm>2009-09-18T11:14:00</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<XtndedSts>
<Sts>ACTV</Sts>
<ChngDtTm>2009-12-17T00:00:00</ChngDtTm>
</XtndedSts>
</StsXtnsnNtfctn>

20 February 2015 Page 115

Trade Services Management November 2015

6.33 StatusExtensionRequestRejection - tsmt.033.001.03

The following illustrates the rejection of a request to extend the status of a transaction.

In the scenario below the seller's bank (AFMBZAJJ) rejects the request to extend the status of the transaction
requested by the buyer's bank (ADIABE22) with a StatusExtensionRequest message (see business example) and
passed on to the seller's bank by the matching application with a StatusExtensionRequestNotification message (see
business example).

The message specifies the status of the transaction (StsNotToBeXtnded) for which the request to extend the status
has been rejected by the sender of the message, that is the seller's bank and the reason for the request rejection
(RjctnRsn).

The matching application will acknowledge the rejection of the request to extend the status of the transaction to the
seller's bank by sending an Acknowledgement message. Furthermore, it will convey the information about the
rejection of the request to extend the status of the transaction by sending a StatusExtensionRejectionNotification
message (see business example) to the submitter of the request to extend the status of the transaction, that is, the
buyer's bank.

The acceptance of a status extension request can be achieved by submitting a StatusExtensionAcceptance

message (see business example).

<StsXtnsnReqRjctn>
<RjctnId>
<Id>SERRMessage36</Id>
<CreDtTm>2009-09-18T11:13:00</CreDtTm>
</RjctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<StsNotToBeXtnded>
<Sts>ACTV</Sts>
</StsNotToBeXtnded>
<RjctnRsn>
<Desc>No further utilization</Desc>
</RjctnRsn>
</StsXtnsnReqRjctn>

6.34 StatusExtensionRejectionNotification - tsmt.034.001.03

The following illustrates the passing on of information on the rejection of a request to extend the status of a
transaction.

In the scenario below the matching application informs the buyer's bank (ADIABE22) that the seller's bank
(AFMBAZJJ) has rejected the request to extend the status of the transaction (see business example).

The message specifies the status of the transaction (NonXtndedSts) for which the request to extend the status has
been rejected and the reason for the rejection of the request (RjctnRsn).

The matching application will inform about the acceptance of a request to extend the status of a transaction by
sending a StatusExtensionNotification message (see business example).

<StsXtnsnRjctnNtfctn>
<NtfctnId>
<Id>SERNMessage38</Id>
<CreDtTm>2009-09-18T11:14:00</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<NonXtndedSts>
<Sts>ACTV</Sts>

Page 116 Message Definition Report Part 1

Examples

</NonXtndedSts>
<RjctnRsn>
<Desc>No further utilization</Desc>
</RjctnRsn>
</StsXtnsnRjctnNtfctn>

6.35 StatusExtensionRequest - tsmt.035.001.03

The following illustrates the request to extend the status of a transaction.

In the scenario below the buyer's bank (ADIABE22) requests to extend the current (active) status of the transaction
(StsToBeXtnded).

The matching application will acknowledge the receipt of the request to extend the status of the transaction by
sending an Acknowledgement message.

It will inform the counterparty (seller's bank) about the request to extend the status of the transaction by sending a
StatusExtensionRequestNotification message (see business example).

<StsXtnsnReq>
<ReqId>
<Id>SERMessage33</Id>
<CreDtTm>2009-09-17T15:52:00</CreDtTm>
</ReqId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<StsToBeXtnded>
<Sts>ACTV</Sts>
<ChngDtTm>2009-12-17T15:52:00</ChngDtTm>
</StsToBeXtnded>
</StsXtnsnReq>

6.36 StatusExtensionRequestNotification - tsmt.036.001.03

The following illustrates the passing on of information on the request to extend the status of a transaction.

In the scenario below the matching application informs the seller's bank (AFMBZAJJ) that the buyer's bank
(ADIABE22) has requested to extend the status of the transaction by sending a StatusExtensionRequest message
(see business example).

The message specifies the action that the seller's bank is expected to take (ReqForActn).

The seller's bank can either accept the request by sending a StatusExtensionAcceptance message (see business
example) or reject the request by sending a StatusExtensionRejection message (see business example).

<StsXtnsnReqNtfctn>
<NtfctnId>
<Id>SERNMessage34</Id>
<CreDtTm>2009-09-17T15:53:00</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<StsToBeXtnded>
<Sts>ACTV</Sts>
<ChngDtTm>2009-12-17T15:52:00</ChngDtTm>
</StsToBeXtnded>
<Initr>
<BIC>ADIABE22</BIC>

20 February 2015 Page 117

Trade Services Management November 2015

</Initr>
<ReqForActn>
<Tp>ARES</Tp>
</ReqForActn>
</StsXtnsnReqNtfctn>

6.37 StatusReport - tsmt.037.001.03

The following illustrates the reporting on statuses and sub-statuses of transactions the requester of the status report
is involved in.

In the scenario below the matching application informs the buyer's bank (ADIABE22) about the status and sub-status
of all transactions that the bank is involved in, after having received a StatusReportRequest message (see business
example) from the buyer's bank.

<StsRpt>
<RptId>
<Id>SRPMessage21</Id>
<CreDtTm>2009-09-07T16:18:00</CreDtTm>
</RptId>
<RltdMsgRef>
<Id>SSRMessage20</Id>
<CreDtTm>2009-09-07T16:17:00</CreDtTm>
</RltdMsgRef>
<RptdItms>
<TxId>01190799181-6940-48</TxId>
<RptdNtty>
<BIC>ADIABE22</BIC>
</RptdNtty>
<Sts>ACTV</Sts>
</RptdItms>
<RptdItms>
<TxId>01190792381-6478-21</TxId>
<RptdNtty>
<BIC>ADIABE22</BIC>
</RptdNtty>
<Sts>AMRQ</Sts>
</RptdItms>
</StsRpt>

6.38 StatusReportRequest - tsmt.038.001.03

The following illustrates the request for a status report.

In the scenario below the buyer's bank (ADIABE22) requests a report on the status and sub-statuses of all
transactions that the bank is involved in.

The matching application will respond to the request by sending a StatusReport message (see business example).

<StsRptReq>
<ReqId>
<Id>SRRMessage20</Id>
<CreDtTm>2009-09-07T16:17:00</CreDtTm>
</ReqId>
</StsRptReq>

6.39 TimeOutNotification - tsmt.040.001.03

The following illustrates the passing on of information about an imminent closure of a transaction.

Page 118 Message Definition Report Part 1

Examples

In the scenario below the matching application informs the recipient that it will close the transaction if no party takes
an action before a specified point in time, that is, 5 November 2009 (ChngDtTm).

<TmOutNtfctn>
<NtfctnId>
<Id>TONMessage40</Id>
<CreDtTm>2009-09-30T06:00:00</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<EstblishdBaselnId>
<Id>01190799181-6940-48</Id>
<Vrsn>1</Vrsn>
</EstblishdBaselnId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<TmOutDesc>
<TxFutrSts>
<Sts>CLSD</Sts>
<ChngDtTm>2009-11-05T00:00:00</ChngDtTm>
</TxFutrSts>
</TmOutDesc>
</TmOutNtfctn>

6.40 TransactionReport - tsmt.041.001.03

The following illustrates the reporting on various details of transactions the requester of a transaction report asked
for.

In the scenario below the matching application informs the buyer's bank (ADIABE22) of the details of all transactions
that the bank and its correspondent with the BIC code AFMBZAJJ are involved in.

The report is triggered by a TransactionReportRequest (see business example).

<TxRpt>
<RptId>
<Id>TRPMessage23</Id>
<CreDtTm>2009-09-08T14:04:00</CreDtTm>
</RptId>
<RltdMsgRef>
<Id>TRRMessage22</Id>
<CreDtTm>2009-09-08T14:03:00</CreDtTm>
</RltdMsgRef>
<RptdItms>
<TxId>01190799181-6940-48</TxId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<PurchsOrdrRef>
<Id>PO20090615/003567</Id>
<DtOfIsse>2009-06-15</DtOfIsse>
</PurchsOrdrRef>
<Buyr>
<Nm>Diamant Import NV</Nm>
<PstlAdr>
<PstCdId>2018</PstCdId>
<TwnNm>Antwerp</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Buyr>
<Sellr>
<Nm>Gem Grafting and Export Ltd.</Nm>

20 February 2015 Page 119

Trade Services Management November 2015

<PstlAdr>
<PstCdId>28225</PstCdId>
<TwnNm>Johannesburg</TwnNm>
<Ctry>ZA</Ctry>
</PstlAdr>
</Sellr>
<BuyrBk>
<BIC>ADIABE22</BIC>
</BuyrBk>
<BuyrBkCtry>BE</BuyrBkCtry>
<SellrBk>
<BIC>AFMBZAJJ</BIC>
</SellrBk>
<SellrBkCtry>ZA</SellrBkCtry>
<OutsdngAmt Ccy = "USD">89460.00</OutsdngAmt>
<TtlNetAmt Ccy = "USD">322465.00</TtlNetAmt>
</RptdItms>
</TxRpt>

6.41 TransactionReportRequest - tsmt.042.001.03

The following illustrates the request for a transaction report.

In the scenario below the buyer's bank (ADIABE22) requests a report of the details of the transactions that the bank
is involved in. The buyer's bank limits the request (RptSpcfctn) by asking only for details of transactions that the
correspondent with the BIC code AFMBZAJJ (seller's bank) is involved in.

The matching application will respond to the request by sending a TransactionReport message (see business
example).

<TxRptReq>
<ReqId>
<Id>TRRMessage22</Id>
<CreDtTm>2009-09-08T14:03:00</CreDtTm>
</ReqId>
<RptSpcfctn>
<Crspdt>
<BIC>AFMBZAJJ</BIC>
</Crspdt>
</RptSpcfctn>
</TxRptReq>

6.42 IntentToPayNotification - tsmt.044.001.02

The following illustrates the sending of intent to pay information from the buyer's bank (ADIABE22) to the matching
application.

This message contains information about the intention of the buyer to pay the seller on a given date an amount in
relation with a purchase order known to the matching application.

<InttToPayNtfctn>
<NtfctnId>
<Id>MSGID#139585</Id>
<CreDtTm>2009-09-26T11:34:27Z</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<BuyrBk>
<BIC>BNPASGSG</BIC>
</BuyrBk>
<SellrBk>

Page 120 Message Definition Report Part 1

Examples

<BIC>CHASUS33</BIC>
</SellrBk>
<InttToPay>
<Brkdwn>
<ByPurchsOrdr>
<PurchsOrdrRef>
<Id>PO/2009/1234</Id>
<DtOfIsse>2009-08-01</DtOfIsse>
</PurchsOrdrRef>
<Adjstmnt>
<Tp>
<Tp>REBA</Tp>
</Tp>
<Drctn>SUBS</Drctn>
<Amt Ccy="USD">100</Amt>
</Adjstmnt>
<NetAmt Ccy="USD">3500</NetAmt>
</ByPurchsOrdr>
</Brkdwn>
<XpctdPmtDt>2009-10-31</XpctdPmtDt>
</InttToPay>
</InttToPayNtfctn>

6.43 ForwardIntentToPayNotification - tsmt.045.001.02

The following illustrates the passing on of intent to pay information that the matching application has received.

In the scenario below the matching application passes on the information from the IntentToPayNotification message
(see business example) it received from the buyer's bank (ADIABE22) to the seller's bank (AFMBAZJJ).

No further action is expected from the receiver of the message by the matching application.

<FwdInttToPayNtfctn>
<NtfctnId>
<Id>BRWS#1395856#SWHQBEBB003</Id>
<CreDtTm>2009-09-26T11:39:27Z</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<EstblishdBaselnId>
<Id>BAS/01190799181-6940-48</Id>
<Vrsn>1</Vrsn>
</EstblishdBaselnId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<BuyrBk>
<BIC>BNPASGSG</BIC>
</BuyrBk>
<SellrBk>
<BIC>CHASUS33</BIC>
</SellrBk>
<InttToPay>
<Brkdwn>
<ByPurchsOrdr>
<PurchsOrdrRef>
<Id>PO/2009/1234</Id>
<DtOfIsse>2009-08-01</DtOfIsse>
</PurchsOrdrRef>
<Adjstmnt>
<Tp>
<Tp>REBA</Tp>
</Tp>

20 February 2015 Page 121

Trade Services Management November 2015

6.44 IntentToPayReport - tsmt.046.001.01

The following illustrates the report generated by the matching application following the reception of an
IntentToPayNotification message (see business example).

The report contains accumulated amounts, from all previous IntentToPayNotification message relevant to the same
purchase order(s).

No further action is expected from the receiver of the message by the matching application.

<InttToPayRpt>
<RptId>
<Id>BRWS#1395856#SWHQBEBB003</Id>
<CreDtTm>2009-09-26T11:39:27Z</CreDtTm>
</RptId>
<RptLine>
<TxId>01190799181-6940-48</TxId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<PurchsOrdrRef>
<Id>PO/2009/1234</Id>
<DtOfIsse>2009-08-01</DtOfIsse>
</PurchsOrdrRef>
<PurchsOrdrTtlNetAmt Ccy = "USD">10000</PurchsOrdrTtlNetAmt>
<AcmltdNetAmt Ccy = "USD">3500</AcmltdNetAmt>
</RptLine>
</InttToPayRpt>

6.45 SpecialRequest - tsmt.047.001.01

The following illustrates the sending of a special request message.

In the scenario below a submitting bank signals that it will not be able to submit a specific type of data set required
by the baseline.

The message specifies the type of special request and contains space for additional information, for example the
reason.

<SpclReq>
<ReqId>
<Id>SRMessage23</Id>
<CreDtTm>2009-08-31T13:21:00</CreDtTm>
</ReqId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<Ntfctn>
<Tp>CSDS</Tp>
<AddtlInf>Document was not issued</AddtlInf>
</Ntfctn>

Page 122 Message Definition Report Part 1

Examples

</SpclReq>

6.46 SpecialNotification - tsmt.048.001.01

The following illustrates the passing on of information received by the matching application in a special request
message.

In the scenario below a submitting bank has signaled that it will not be able to submit a specific type of data set
required by the baseline (see business example SpecialRequest) and the matching application informs the parties to
the transaction.

<SpclNtfctn>
<NtfctnId>
<Id>SPNMessage30</Id>
<CreDtTm>2009-08-31T13:21:00</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<EstblishdBaselnId>
<Id>01190799181-6940-48</Id>
<Vrsn>1</Vrsn>
</EstblishdBaselnId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<Initr>
<BIC>ADIABE33</BIC>
</Initr>
<Ntfctn>
<Tp>CSDS</Tp>
<AddtlInf>Document was not issued</AddtlInf>
</Ntfctn>
</SpclNtfctn>

6.47 RoleAndBaselineAcceptance - tsmt.049.001.01

The following illustrates the acceptance of role and baseline by a secondary bank.

In the scenario below a secondary bank accepts its role and baseline, as described in a FullPushThroughReport
received from the matching application

The message specifies the FullPushThroughReport message that it relates to and the transaction identification.

The matching application will convey the information about the acceptance of the role by sending a
RoleAndBaselineAcceptanceNotification message (see business example).

<RoleAndBaselnAccptnc>
<AccptncId>
<Id>RABAMessage5</Id>
<CreDtTm>2009-07-05T11:02:00</CreDtTm>
</AccptncId>
<RltdMsgRef>
<Id>FPTMessage1</Id>
<CreDtTm>2009-07-04T11:02:00</CreDtTm>
</RltdMsgRef>
<TxId>
<Id>01190799181-6940-48</Id>

20 February 2015 Page 123

Trade Services Management November 2015

</TxId>
</RoleAndBaselnAccptnc>

6.48 RoleAndBaselineRejection - tsmt.050.001.01

The following illustrates the acceptance of role and baseline by a secondary bank.

In the scenario below a secondary bank accepts its role and baseline, as described in a FullPushThroughReport
received from the matching application

The message specifies the FullPushThroughReport message that it relates to and the transaction identification.

The matching application will convey the information about the acceptance of the role by sending a
RoleAndBaselineRejectionNotification message (see business example).

<RoleAndBaselnRjctn>
<RjctnId>
<Id>RABRMessage4</Id>
<CreDtTm>2009-07-05T11:02:00</CreDtTm>
</RjctnId>
<RltdMsgRef>
<Id>FPTMessage1</Id>
<CreDtTm>2009-07-04T11:02:00</CreDtTm>
</RltdMsgRef>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
</RoleAndBaselnRjctn>

6.49 RoleAndBaselineAcceptanceNotification - tsmt.051.001.01

The following illustrates the notification of an acceptance of role and baseline by a secondary bank.

In the scenario below the matching application informs the receiver, that a secondary bank has accepted its role and
baseline (see business example RoleAndBaselineAcceptance).

<RoleAndBaselnAccptncNtfctn>
<NtfctnId>
<Id>RABANMessage1</Id>
<CreDtTm>2009-07-05T11:02:00</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<Initr>
<BIC>ADIABE33</BIC>
</Initr>
</RoleAndBaselnAccptncNtfctn>

6.50 RoleAndBaselineRejectionNotification - tsmt.052.001.01

The following illustrates the notification of the rejection of role and baseline by a secondary bank.

In the scenario below the matching application informs the receiver, that a secondary bank has rejected its role and
baseline (see business example RoleAndBaselineRejection).

Page 124 Message Definition Report Part 1

Examples

<RoleAndBaselnRjctnNtfctn>
<NtfctnId>
<Id>RABANMessage1</Id>
<CreDtTm>2009-07-05T11:02:00</CreDtTm>
</NtfctnId>
<TxId>
<Id>01190799181-6940-48</Id>
</TxId>
<TxSts>
<Sts>ACTV</Sts>
</TxSts>
<Initr>
<BIC>ADIABE33</BIC>
</Initr>
</RoleAndBaselnRjctnNtfctn>

20 February 2015 Page 125

Trade Services Management November 2015

Legal Notices
Copyright
SWIFT © 2015. All rights reserved.
Restricted Distribution
Do not distribute this publication outside your organisation unless your subscription or order expressly
grants you that right, in which case ensure you comply with any other applicable conditions.
Disclaimer
The information in this publication may change from time to time. You must always refer to the latest
available version.
SWIFT Standards Intellectual Property Rights (IPR) Policy - End-User License Agreement
SWIFT Standards are licensed subject to the terms and conditions of the SWIFT Standards IPR Policy -
End-User License Agreement, available at www.swift.com > About SWIFT > Legal > SWIFT Standards
IPR Policy.
Translations
The English version of SWIFT documentation is the only official and binding version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: the
SWIFT logo, SWIFT, SWIFTNet, Accord, Sibos, 3SKey, Innotribe, the Standards Forum logo,
MyStandards, and SWIFT Institute. Other product, service, or company names in this publication are
trade names, trademarks, or registered trademarks of their respective owners.

Page 126 Message Definition Report Part 1

The Off-Grid Blueprint: DIY Survival Projects for Modern Self-Reliance: DIY Survival Projects for Modern Self-Reliance: DIY Survival Projects for Modern Self-Reliance
From Everand
The Off-Grid Blueprint: DIY Survival Projects for Modern Self-Reliance: DIY Survival Projects for Modern Self-Reliance: DIY Survival Projects for Modern Self-Reliance
Grant Wilder
No ratings yet
DEL3 - Delivery (OUTWARD - PART II)
No ratings yet
DEL3 - Delivery (OUTWARD - PART II)
43 pages
MX Pacs 002 001 10
No ratings yet
MX Pacs 002 001 10
159 pages
SR2022 MX Funds MDR1 Standards
No ratings yet
SR2022 MX Funds MDR1 Standards
362 pages
Global Platform Core Services MT Technical Specifications - v1.25
No ratings yet
Global Platform Core Services MT Technical Specifications - v1.25
142 pages
SWIFT SR2019 - MX - BankToCustomerCashManagement - MDR1 - Standards
No ratings yet
SWIFT SR2019 - MX - BankToCustomerCashManagement - MDR1 - Standards
39 pages
Delivery Updated 1
No ratings yet
Delivery Updated 1
129 pages
MX Pacs 004 001 09
No ratings yet
MX Pacs 004 001 09
178 pages
SWIFT SR2019 - Standards
No ratings yet
SWIFT SR2019 - Standards
36 pages
List of Swift Messages PDF
100% (4)
List of Swift Messages PDF
47 pages
Business Example Pacs003 Pacs008 Pacs004
No ratings yet
Business Example Pacs003 Pacs008 Pacs004
147 pages
MX - Pain - 002 - 001 - 10 2
No ratings yet
MX - Pain - 002 - 001 - 10 2
171 pages
SR2020 MX PaymentsClearingAndSettlement MDR1 Standards
No ratings yet
SR2020 MX PaymentsClearingAndSettlement MDR1 Standards
146 pages
SWIFT sr2015 - Standards
No ratings yet
SWIFT sr2015 - Standards
26 pages
List of Swift Messages
No ratings yet
List of Swift Messages
50 pages
1 SWIFT sr2015 - Securitiesclearing - Standards
No ratings yet
1 SWIFT sr2015 - Securitiesclearing - Standards
387 pages
Design and Implementation of A Distributed 3D Computer Game Engine
No ratings yet
Design and Implementation of A Distributed 3D Computer Game Engine
337 pages
GlobalPayments Technical Specifications
No ratings yet
GlobalPayments Technical Specifications
66 pages
ASE1 - Module (Dec 08)
No ratings yet
ASE1 - Module (Dec 08)
144 pages
Codificación para Envio de Tramas
No ratings yet
Codificación para Envio de Tramas
149 pages
Reply Bwlinanx 230818
No ratings yet
Reply Bwlinanx 230818
6 pages
Notsro Reconcilation For Nostro Account
100% (1)
Notsro Reconcilation For Nostro Account
14 pages
List of All SWIFT-ISO Messages
50% (2)
List of All SWIFT-ISO Messages
47 pages
Speeduino Manual PDF
100% (1)
Speeduino Manual PDF
107 pages
Boundaries, Baby: How to Say ‘No’ and Still Be a Rockstar Educator,”
From Everand
Boundaries, Baby: How to Say ‘No’ and Still Be a Rockstar Educator,”
Thomas Grey
No ratings yet
Spring Boot
No ratings yet
Spring Boot
29 pages
MA-AML Audit Template
100% (1)
MA-AML Audit Template
11 pages
ISO20022 PaymentsInitiation MDR1 PDF
No ratings yet
ISO20022 PaymentsInitiation MDR1 PDF
54 pages
MT 940 Setup Procedure - v2 - Abl
No ratings yet
MT 940 Setup Procedure - v2 - Abl
8 pages
TPS Mms
No ratings yet
TPS Mms
28 pages
PID500 Modbus
No ratings yet
PID500 Modbus
41 pages
Capstone-Thesis 1 To 3
No ratings yet
Capstone-Thesis 1 To 3
83 pages
Vismat Material V-Ray For Sketchup
No ratings yet
Vismat Material V-Ray For Sketchup
19 pages
Bulls Eye
No ratings yet
Bulls Eye
102 pages
Standards List of MT Messages
No ratings yet
Standards List of MT Messages
16 pages
Exploring The Impact of A New Data Structure On The Payments Ecosystem
No ratings yet
Exploring The Impact of A New Data Structure On The Payments Ecosystem
9 pages
Resetting Windows Password
No ratings yet
Resetting Windows Password
8 pages
Poweredge-T320 Owner's Manual En-Us
No ratings yet
Poweredge-T320 Owner's Manual En-Us
167 pages
Plain JavaScript: Learning the Front-End
From Everand
Plain JavaScript: Learning the Front-End
Roger Beans-Rivet
No ratings yet
Active With Brazil 2020 (EN Web-1a)
No ratings yet
Active With Brazil 2020 (EN Web-1a)
68 pages
Cutting-Edge Desktop UI Development with Python, PySide6, PyQt6
From Everand
Cutting-Edge Desktop UI Development with Python, PySide6, PyQt6
Jay Nans
No ratings yet
Module 11 AWS Best Practices: Introduction: Operational Checklist
No ratings yet
Module 11 AWS Best Practices: Introduction: Operational Checklist
10 pages
MT 940 Setup Procedure - v2 - Abl
100% (1)
MT 940 Setup Procedure - v2 - Abl
8 pages
Multiplication Squares Game R PDF
100% (1)
Multiplication Squares Game R PDF
5 pages
Trading Mastery: Unleashing Financial Potential in the Modern Markets Innovative Strategies, Prudent Approaches, and Insider insights for Mastering the Art of Trading
From Everand
Trading Mastery: Unleashing Financial Potential in the Modern Markets Innovative Strategies, Prudent Approaches, and Insider insights for Mastering the Art of Trading
GEORGE L . BROWN
No ratings yet
Becoming A Full-Stack Developer With Python Involves Mastering Both Front - 20241230 - 120127 - 0000
No ratings yet
Becoming A Full-Stack Developer With Python Involves Mastering Both Front - 20241230 - 120127 - 0000
23 pages
Xtool Ip819 Smart Diagnostic System User Manual
No ratings yet
Xtool Ip819 Smart Diagnostic System User Manual
49 pages
Unlocking Statistics for the Social Sciences
From Everand
Unlocking Statistics for the Social Sciences
Norma Sinclair
No ratings yet
Human Nature Potential in Nurture
From Everand
Human Nature Potential in Nurture
David L. Hawk
No ratings yet
Applog
No ratings yet
Applog
56 pages
The Stock Market from A to See - 2nd Edition
From Everand
The Stock Market from A to See - 2nd Edition
John Nunez
No ratings yet
Finma JB e 2011 01
No ratings yet
Finma JB e 2011 01
94 pages
Emasters in Data Science Data Analytics
No ratings yet
Emasters in Data Science Data Analytics
12 pages
Sip Project
No ratings yet
Sip Project
57 pages
Options Trading for Income: Learn the strategies and techniques for maximizing returns and minimizing risk in the options market (2023 Guide for Beginners)
From Everand
Options Trading for Income: Learn the strategies and techniques for maximizing returns and minimizing risk in the options market (2023 Guide for Beginners)
Lane Conner
No ratings yet
Coverage Analysis For Model Based Design Tools: William Aldrich The Mathworks, Inc. 3 Apple Hill Dr. Natick, Ma 02478
No ratings yet
Coverage Analysis For Model Based Design Tools: William Aldrich The Mathworks, Inc. 3 Apple Hill Dr. Natick, Ma 02478
17 pages
The Linux Terminal for Advanced Users - The Command Line Made Easy: First Edition
From Everand
The Linux Terminal for Advanced Users - The Command Line Made Easy: First Edition
Michael Basler
No ratings yet
ChatGPT for Business: Strategies for Success
From Everand
ChatGPT for Business: Strategies for Success
Matthew C. Smith
1/5 (1)
Reading A Computer Science Research Paper
No ratings yet
Reading A Computer Science Research Paper
6 pages
SIF Bericht en 2016
No ratings yet
SIF Bericht en 2016
52 pages
Blog Smarter, Not Harder: SEO, Blogging, and AI Strategies to Skyrocket Your Traffic
From Everand
Blog Smarter, Not Harder: SEO, Blogging, and AI Strategies to Skyrocket Your Traffic
Jay Nans
No ratings yet
Gray Hat Hacking the Ethical Hacker's
From Everand
Gray Hat Hacking the Ethical Hacker's
Çağatay Şanlı
5/5 (1)
Notes - Sap BPC 340
No ratings yet
Notes - Sap BPC 340
10 pages
Cybersecurity for Executives: A Guide to Protecting Your Business
From Everand
Cybersecurity for Executives: A Guide to Protecting Your Business
Matthew C. Smith
No ratings yet
MT700 or MT760 or ISO 20022
No ratings yet
MT700 or MT760 or ISO 20022
10 pages
Day Trader-Forex Trading
From Everand
Day Trader-Forex Trading
Murry Naga
No ratings yet
10K Blueprint
From Everand
10K Blueprint
Cian O Farrell
5/5 (2)
Unit 6 Software Metrics
No ratings yet
Unit 6 Software Metrics
6 pages
6 SWIFT SR2019 - MX - Notification - Standards
No ratings yet
6 SWIFT SR2019 - MX - Notification - Standards
19 pages
LAWO PI - MADI - SRC - en
No ratings yet
LAWO PI - MADI - SRC - en
2 pages
What Are Green Bonds
No ratings yet
What Are Green Bonds
32 pages
Intrusion Detection Honeypots
From Everand
Intrusion Detection Honeypots
Chris Sanders
3/5 (2)
Samarth Polytechnic, Belhe: Department of Computer Engineering
No ratings yet
Samarth Polytechnic, Belhe: Department of Computer Engineering
6 pages
ISYS2092 Software Testing Assignment 1 (15%) : Learning Objectives
No ratings yet
ISYS2092 Software Testing Assignment 1 (15%) : Learning Objectives
2 pages
BlockChain for Beginners
From Everand
BlockChain for Beginners
Matthew Smith
No ratings yet
BCECE Chemistry 2016 (English)
No ratings yet
BCECE Chemistry 2016 (English)
26 pages
CV-Lazar-v4 0 0
No ratings yet
CV-Lazar-v4 0 0
3 pages
Content Creation Revolution with chatGPT
From Everand
Content Creation Revolution with chatGPT
Maria Cowen
No ratings yet
Multimedia Final Exam
No ratings yet
Multimedia Final Exam
2 pages
Viva Q Python
No ratings yet
Viva Q Python
4 pages
Modifying A Tool To Make A PE Loader That Evades Defender
No ratings yet
Modifying A Tool To Make A PE Loader That Evades Defender
5 pages
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
From Everand
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
Matthew C. Smith
No ratings yet
Swiss Climate Scores en
No ratings yet
Swiss Climate Scores en
5 pages
ARRC March 7 2018 Press Release
No ratings yet
ARRC March 7 2018 Press Release
2 pages
PLSQL 16 18
No ratings yet
PLSQL 16 18
3 pages

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.