DTCC SOLUTIONS
Conceptual Solution
DTCC SOLUTIONS
OTC Derivatives
Conceptual Solution
Date:
Version:
Status:
Author:
09/24/02
0.4
Draft
Bob Green
OTC Derivatives Conceptual Solution
DTCC Solutions - Internal Use Only
Page 1 of 16
DTCC SOLUTIONS
Conceptual Solution
Table of Contents
1 OVERVIEW ............................................................................................... 3
2 ARCHITECTURE OVERVIEW ..................................................................8
3 SUBJECT AREA MODEL ....................................................................... 10
4 MESSAGE FLOW DIAGRAMS ............................................................... 11
OTC Derivatives Conceptual Solution
DTCC Solutions - Internal Use Only
Page 2 of 16
DTCC SOLUTIONS
1
Conceptual Solution
Overview
The main features of this system are:

Provide support in the creation of OTC Derivative electronic confirmation messages

Provide interfaces to one or more communication networks

Provide a trade matching system for OTC Derivatives using these messages

Provide a web front end for trade entry, modification and trade discrepancy workflow management

Provide a historical repository for OTC Derivative trade activity
1. OTC Derivatives Electronic Order Messages
The following OTC Derivatives XML message actions are envisioned at this time:
i. Trade Entry
ii. Trade Modification
iii. Alleged Trade Notification
iv. Unconfirmed Trade Acknowledgement
v. Trade Confirmation
vi. Unilateral Trade Cancel
vii. Unilateral Trade Cancel Notification
viii. Unilateral Trade Cancel Confirmation
ix. System Reject (either format or business logic)
Details of how these messages will flow are included below in the Message Flow Diagrams section.
It is expected that the “Trade Entry”, “Trade Modification”, “Unconfirmed Trade Acknowledgement”,
“Alleged Trade Notification” and the “Trade Confirmation” messages are very similar. The portion of the
message detailing the trade will be identical.
The differences in the “Allege” and the “Confirmation” messages will only pertain to the creator of the
message. These message types may support a “short-form” version where only certain “key fields” are
required.
If possible, the various OTC Derivative product types should be encompassed within the “Trade Entry or
Modification” and “Alleged Trade Confirmation” pair of messages. It is understood that each OTC
Derivative type will have a unique set of message fields associated with that product type.
The nine message types named above will be constructed to support the following workflow:
1. Members of the DTCC OTC Derivatives service may send “Trade Entry or Modification” or
“Unilateral Trade Cancel” messages for their own trades.
2. Upon receipt of a valid “Trade Entry” or “Trade Modification” message the DTCC system will
send an “Alleged Trade Notification” message to the contra party named in the “Trade Entry or
Modification” message. The DTCC system will send an “Unconfirmed Trade Acknowledgement”
message to the message originator; this message will include the DTCC control number and
may include other changes (status, potential trade match information, etc.) Upon receipt of a
“Unilateral Trade Cancel” message the DTCC system will send the “Unilateral Trade Cancel
Notification” message to the named contra party.
OTC Derivatives Conceptual Solution
DTCC Solutions - Internal Use Only
Page 3 of 16
DTCC SOLUTIONS
Conceptual Solution
3. Upon receipt of a “Trade Entry” or “Trade Modification” message modifying the contra party field
the DTCC system will send an “Alleged Trade Notification” to the newly named contra party and
will send a “Unilateral Trade Cancel Notification” message to the previously named contra party.
4. When either side submits a “Trade Entry” or “Trade Modification” message that matches a trade
of a contra party (see “Trade Matching” below) a “Trade Confirmation” message will be sent to
both parties to the trade.
5. Inter Broker Dealer (IBD) may submit trades for both sides of a trade. Upon receipt of an IBD
“Trade Entry” message the DTCC system will send out four (4) messages as follows:
-
An “Unconfirmed Trade Acknowledgement” to Party-1 representing their trade entry by
the IDB
-
An “Unconfirmed Trade Acknowledgement” to Party-2 representing their trade entry by
the IDB
-
An “Alleged Trade Notification” message to Party-1 indicating Party-1 has been named
as the contra party for a trade entered by an IBD on behalf of Party-2
-
An “Alleged Trade Notification” message to Party-2 indicating Party-2 has been named
as the contra party for a trade entered by an IBD on behalf of Party-1
While the single trade entered by the IDB will be used to generate both the Party-1 and the
Party-2 trade entry an additional field will be set to cause the IDB entered trade to “not match”.
Both Party-1 and Party-2 must send in a “Trade Modification” message, modifying this field and
indicating their affirmation of the IDB trade entry, to cause the trades to match.
6. The DTCC system may receive malformed messages or messages which conform to format
rules but do not conform to business rules. When receiving these messages the DTCC system
will send a “System Reject” message to the submitting member. The “Systems Reject” message
will include as much information about the reason for rejection as possible.
7. Once a trade is in Confirmed status it may not be modified nor cancelled.
Message for activities subsequent to the trade confirmation will not be supported initially. Creation of
decline/”DK” messages would not be part of the initial implementation.
2. Network Communication Interfaces
Interfaces to several communication systems are contemplated. While each communication system will
be considered on it’s own marketing merit, wherever possible the design of the system should flexibly
allow for additional communication systems to be added at a future time.
The communication systems under consideration include:
i.
networks capable of supporting SWIFT messages
ii.
DTCC’s frame relay private network using CCF interfaces
iii. SIAC’s private network using Datatrack/Autoroute
iv. Public Internet to a DTCC web server
The communication interface will provide a network-appropriate transmission acknowledgement (e.g. a
Datatrack confirm, etc.)
3. Trade Matching
The trade matching engine portion of this project will provide the following:
i.
Validate messages received from participants conform to the format and the business rules
appropriate for that message type
ii.
Store received trade entry, modifications, cancellations or rejection messages into a trade
database
OTC Derivatives Conceptual Solution
DTCC Solutions - Internal Use Only
Page 4 of 16
DTCC SOLUTIONS
Conceptual Solution
iii. Provide trade matching based on various field matching rule types defined below
iv. Provide “key-field matched”, “potential match”, or “no potential match” pairing for trades that are
not confirmed.
v.
Maintain the trade status based on messages received or trade matching results
vi. Maintain an audit trail of entry, modifications, cancellation and/or confirmations of a trade
throughout the trade lifecycle
vii. Provide views into the trade database for the web front end
Both XML Schema validation and additional business rule validations as appropriate will be performed by
the trade matching engine regardless of the source of the message. Business rules may include
required field, conditionally required field, format, and field content validations not explicitly covered by
XML Schema validation. Business rules will include message sequence validation (e.g. a cancellation
can only occur for a previously submitted trade, etc.) and message status validation (corrections to a
confirmed trade are not allowed, etc.)
Rejected messages are stored as a single entry into the trade database and are not otherwise part of the
matching or status functionality described below.
Trade matching will occur only on messages that conform to both the format and business rules.
For new trade sides, the trade matching engine will assign a DTCC trade control number. For
modifications or cancellation of an existing trade, the submitting firm will be able to use its own internal
trade ID number.
The trade matching engine will maintain the following statuses for a trade:
-
“Unconfirmed” (or “Alleged” depending on the side you are on)
-
“Confirmed”
-
“Cancelled”
-
“Rejected”
Trades will be considered Confirmed when all but a defined subset of informational fields in the OTC
XML messages (described above) match. For each field in the OTC XML message one of the following
matching rule types will be defined:
1. Exact field matching (this is the norm)
2. Matching within a defined percent of value tolerance (example: two fields match if the value in
the lower of the two is within 5% of the value in the higher of the two fields)
3. Matching of one list to another list (example: a list of underlying securities match if each ISIN
number in the list of one trade matches one ISIN in the list on the other trade and vice-versa)
4. Matching one participant number to a “family” of participant numbers. For example participant
xxxx may also have sister companies yyyy and zzzz. In scope is to provide a mechanism to link
xxxx, yyyy, and zzzz as a family and to treat an alleged trade naming any of the family against
trades entered by any of the family for potential trade grouping purposes. A trade will never be
considered matched unless the named parties exactly match (e.g. that a trade naming xxxx will
not be considered matched if a trade by yyyy exists that otherwise matches.)
5. Null entry in a field in one side of a trade may be considered matched if a specific “default value”
is entered in this field by the contra side (example: if the default value is 360/30 for business
days and one side enters this value and the other side enters null for this field then a match on
this field will be asserted) Issue: will the matching engine change the null entry to the default
value when sending out confirm messages?
Trades will be considered Rejected when the trade engine receives a message from a firm that cannot
be validated against the XML Schema or business rules of the system. A trade in Rejected status will
OTC Derivatives Conceptual Solution
DTCC Solutions - Internal Use Only
Page 5 of 16
DTCC SOLUTIONS
Conceptual Solution
cause the DTCC system to send a “System Reject” message back to the submitter. Only that portion of
the message that is valid and conforms to business rules will be stored in the trade history database.
Note: for DTCC produced web data entry systems, DTCC will assure the validity of the message at data
entry time and therefore this issue should not exist.
Trades will be considered Cancelled when the trade engine receives a “Unilateral Trade Cancel”
message for a trade in Unconfirmed status (Trades that are Confirmed cannot be cancelled or modified.)
Trades that are neither Confirmed, Cancelled or Rejected are considered Unconfirmed.
When the trade engine receives a “Trade Entry” or “Trade Modification” message it will attempt to
confirm this message to another trade side in the database. When the trade side received is not
confirmed the trade engine would attempt to find “best matches” to existing trade sides in the database
using the following rules:
1. A trade pairing will exist only if matching exists on the pairing fields. “Pairing fields” will include
contra party (which may be a family – see above) and trade type; other fields may be defined. If
no trade side exists where pairing fields match then this side has “no potential match.”
2. When pairing fields match it is possible a second set of “key fields” may match. If all fields
designated “key fields” match then this pair is considered “key field matched.“ If pairing fields
match but all the key fields do not then this pair is considered “potential matched.”
3. The trade engine will provide a list of “key field matched” and “potential matched” trade
identifiers in the “Alleged Trade Notification” message sent to the contra party. The trade engine
will provide the same list of “key field matched” and “potential matched” trade identifiers in the
“Unconfirmed Trade Acknowledgement “ message sent back to the originator.
The trade engine will provide a mechanism for the web portion of this project to receive the list of “key
field matched” and “potential matched” trades by providing the DTCC control number for one side of the
match.
4. Web Front End
A web application will be created to support participant trade entry and trade matching issue resolution.
The web front end functionality is substantially defined by the “Tracer” demo. The “Tracer” demo
functionality will be provided except as defined below:
1. The trade list feature will be enhanced to display the “best match” candidate as a pre-selected
comparison target. “Best match” candidate will be the top of the match ordering list. The match
ordering list will be sorted based on:
a. “key field matched” trades ordered by descending count of non-key fields that match
b. “potential matched” trades ordered by number of key fields that match then by number of
non-key fields that match
The existing mechanism of manually picking comparison targets will continue to be available.
2. The trade list will provide a drill down to all “potential” or “key fields” matched trades. The
display of these trades will be per the match ordering list order (i.e. best to worse potential
match.)
3. Display the history for any given trade.
4. The unmatched notational, unmatched counterparty and unmatched aging reports identified but
not developed for the demo will be available in a subsequent phase.
5. Several additional list sorting/filtering criteria are to be provided:
a. Matched to single “key fields match” trade list
b. Not “key field matched” but “potential match” candidates exist
c.
Alleged with no “potential match” trade
OTC Derivatives Conceptual Solution
DTCC Solutions - Internal Use Only
Page 6 of 16
DTCC SOLUTIONS
Conceptual Solution
d. Unconfirmed with no “potential match” trade
e. Trades with “special clause” language
6. A method to send notes to the contra party and store private notes will be created. These timestamped notes will be stored as part of the history of the trade and can be viewed as part of the
trade history. Note: this is “web only” and will not be part of the message flow nor fields seen by
the trade matching engine.
7. Initial trade entry will be supported. Trades entered via the web will always be verified to be
syntactically correct and follow business rules prior to submission to the trade matching engine.
8. PCWeb supports the concept of entitlements for data entry, for submission of data, or for both.
Entitlements for this project include the following requirements:
a. A user may represent a single company or may be able to represent data about a family
of companies (e.g. a “service bureau” in PCWeb today). Individual users from the same
“family” may have varying abilities to view members within the family (e.g. user “A” can
see family members xxxx, yyyy, and zzzz but user “B” can only see family members
xxxx and zzzz)
b. Entitlements are by company (and potentially within family of companies as stated
above.) A user may have either:
i. “view only” or
ii. “view, enter, modify, submit”
entitlements for a company.
c.
The PCWeb model of establishing a “coordinator” role within a company (or for a family
of companies) and allowing the coordinator to assign “view only” or “view, enter, modify
or submit” roles to other members within the company/family of companies. The
“coordinator” entitlement is separate from the “view only” or “view, enter, modify or
submit” entitlements. A coordinator may also have one of the other roles, but need not.
5. Additional Considerations
The Derivatives market creates new deal types frequently. The design of the messages should be as
accommodating to changes as possible. The design of the system should anticipate frequent changes to
confirmation messages and frequent creation of new, similar messages for other derivative types.
The initial derivative product types to be supported are single reference entity, cash settlement credit
derivatives and single basket equity derivatives. Consideration for the need to rapidly support additional
derivative product types should be included in the design.
6. Future Developments
The following items have been discussed but are not included in this conceptual solution:
1. Notification of corporate actions on underlying securities
2. Collateral management
3. Pricing of underlying securities or collateral
4. Mark-to-market
OTC Derivatives Conceptual Solution
DTCC Solutions - Internal Use Only
Page 7 of 16
DTCC SOLUTIONS
Conceptual Solution
2 Architecture Overview
Concept Overview
Swift Interface
ISO
Swiftnet
DTCC
DB2
DT/AR Interface
XML /
Fpml
MQ
Customer
Back/Mid Office System
SIAC AN
(Datatrak/Autoroute)
Validitation
Module
(SwiftNet/Radianz)
Data
Formatting
Customer
Back/Mid Office System
DTCC
DB2
CCF Interface
XML /
Fpml
MQ
MQ
HTTPS
Customer Browser
Internet
DTCC Web Server
2. A new message format,
based off FPML XML
Schemas, will be used across
any transmission type.
3. An alternative of Web input
for non-automated participants
will be allowed.
Trade Edit
Rules
4. If more than one
transmission type is to be
used, then transmission type
cross-references must exist.
DTCC
DB2
5. All interfaces with the trade
matching engine will be via
MQ. The trade matching
engine will run on the DTC
mainframe
XML
DTCC Frame Relay
(CCF)
Matching
Engine
Customer
Back/Mid Office System
Participant Profile
Rules
1. Product management wants
to know initial costs and each
additional cost of adding
transmission type. Swiftnet/
Radianz/Merva is most likely
candidate and should be the
baseline estimate.
Trade Matching
Rules
6. The trade engine will return
alleged, rejected, unconfirmed
and confirmed trades via
messages.
7. The trade match engine will
store the results of matching in
a trade database.
DTCC
DB2
REG 08/20/02
Alleged, Unmatched,
Rejected and Confirmed
Trade Database
8. The web server will use the
trade database for data display
and match resolution. Trade
match updates will go through
the matching engine.
1. External Interfaces
a. All communications to customers will be via a standard, XML message; the standard for this message is
undetermined at this time but expected to be similar to FpML
2. Interfaces In
a. Each communication method may have channel specific wrappers. The communications interface strips the
wrapper and presents a standard message format into the trade matching engine MQ bus
3. Interfaces Out
a. Each communication method may require channel specific wrappers. The communication interface receives
messages from the trade matching engine via the MQ bus and wrappers the messages as appropriate for the
communication channel.
4. Communication
a. The above general communication channels are under consideration
b. The Swift interface is currently considered the most likely and will be the baseline for cost estimates
c. The incremental cost of adding the other contemplated interfaces need to be estimated as well
OTC Derivatives Conceptual Solution
DTCC Solutions - Internal Use Only
Page 8 of 16
DTCC SOLUTIONS
Conceptual Solution
5. User Interfaces
a. The web interface will include:
i. Detail display-only page (used for confirmed trades, historical drill down, etc.)
ii. Update page (used for corrections and trade mismatch resolution)
iii. Entry page (assume update and entry business rules are equivalent for estimating)
iv. Alleged vs. Unconfirmed trade mismatch resolution page
v. Trade list page
vi. Trade list selection criteria page
vii. Trade match resolution pages:
- Alleges with no likely Unconfirmed
- Unconfirmed with no likely Alleges
- Unconfirmed with likely Alleges with most likely paired
6. Trade Matching Application
a. Up front trade mapping and validation.
i. Each input message type will be mapped to the appropriate format and business table elements.
ii. Validation rules will be invoked to determine the authenticity of the message received.
iii. All messages that do not pass the validation rules will be flagged and stored in a DB2 table as a
rejected message.
iv. By accessing a profile table, rejected messages will be returned to the submitting participant in the
original received format
v. The submitting participant will be able to repair all rejected messages by entering the original
participant reference number and then updating all rejected elements.
b. The Trade Matching engine.
i. Only trades that have passed all validation rules will be passed to the Matching Engine.
ii. The Matching Engine will be a Real Time process utilizing DB2 Databases.
iii. Matching criteria will be rules based and table driven.
iv. The number of matching fields will be table driven and different for each type Derivative.
v. Soft matches will be supported using a predefined minimum matching criteria. (A list of Soft/Possible
Matches will be presented to the Contra participant).
c. Acknowledgement trade status report.
i. IP / MQM will be the primary communication interface.
ii. “XML” messages will be the primary format. Additional formats are available and determined by the
participant profile table.
iii. A Swift interface will be available for foreign message delivery.
iv. DB2 Databases will be accessible to Java Web Application.
7. Data
a. All data will be stored in DB2 tables residing on the DTC mainframe. Existing trade matching databases will
be used whenever possible
b. Billing interfaces will use the new “unified billing” format
c. The DTCC master file databases will be used when applicable in this application.
d. The current IFE participant profile database will be used to determine message (Data) format.
8. Security
a. Web security (privacy, entitlements, authentication) will follow the PCWeb rules and use the PCWeb
infrastructure
b. Mainframe security (privacy, entitlement, authentication) will follow the DTC mainframe rules and use existing
DTC infrastructure
c. No deviations from standard security policies are expected at this time
OTC Derivatives Conceptual Solution
DTCC Solutions - Internal Use Only
Page 9 of 16
DTCC SOLUTIONS
Conceptual Solution
3 Subject Area Model
HIGH LEVEL BUSINESS REQUIREMENTS FOR OTC DERIVATIVES
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Screen print all page
Documentation of demo
File save capability
Delete a reject capability
Spec out credit swap
Interest Rate Products
Short Book
Basis Book
Long Book
Interest Rate Structures
(need complexity matrix/ # of fields for each)
WEB FRONT END
USER ID
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Clear Trust/Servant
Link to Digital Certificate
(VeriSign)
Clear Trust will need to link to
entitlements
Authentication/Authorization
ENTITLEMENTS
Backbone communicator
FPML
Messaging utility
Track trade
validate
edit
acknowledge
store in dual dbase
API
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Support status tab
Standard reportsbi-product of search
engine
API
DATABASE
Ÿ
ANALYTIC
LIBRARY
Rules based for multiple
transaction types
SEARCH
ENGINE
Ÿ
Ÿ
Dbase
Hierarchy/User Profile
Delegated Administrator
Assume entitlements dabs
REPORT WRITER
TRADE MATCHING
ENGINE
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Process application layer
Cash and physical
Produces results of matched fields
Matching engine for 5 basic types
Match criteria
ISDA confirm format (can DTCC be
identified on an ISDA certified confirm)
Archive/ filtered dbase
MASTER FILE
IRS
A
P
I
EQUITY
CREDIT
SWAP
COMMUNICATION
FPML
ISO15022
Real time
Linked to ATP/Corp. Actions/
Risk
Terminate a transaction and
re-enter
OTC Derivatives Conceptual Solution
DTCC Solutions - Internal Use Only
Page 10 of 16
DTCC SOLUTIONS
4
Conceptual Solution
Message Flow Diagrams
Simple Matching Example
Action = New
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
Action = Unconfirmed
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
BestFit = {null}
Action = Confirmed
YourTradeID = A1
ContraTradeID = B1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
BestFit = {5555 B1Cnf}
1
2
D
T
C
C
M
A
T
C
H
I
N
G
6
OTC Derivatives Conceptual Solution
E
N
G
I
N
E
DTCC Solutions - Internal Use Only
3
4
5
Action = Alleged
ContraTradeID = A1
DTCCMember = 5555
EnteredBy = 8888
ContraParty = 8888
BestFit = {null}
Action = New
YourTradeID = B1
DTCCMember = 5555
EnteredBy = 5555
ContraParty = 8888
Action = Confirmed
YourTradeID = B1
ContraTradeID = A1
DTCCMember = 5555
EnteredBy = 5555
ContraParty = 8888
BestFit = {8888 A1 Cnf}
Page 11 of 16
DTCC SOLUTIONS
Conceptual Solution
Typical Matching Example
Action = New
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
1
Action = Unconfirmed
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
BestFit = {null}
Action = Modify
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
6
Note: Did not
match
7
3
DTCC TRADE MATCHING ENGINE
Action = Alleged
ContraTradeID = B1
DTCCMember = 8888
EnteredBy = 5555
ContraParty = 5555
BestFit = {8888 A1 Key}
2
4
5
Note: Did not
match
Action = Alleged
ContraTradeID = A1
DTCCMember = 5555
EnteredBy = 8888
ContraParty = 8888
BestFit = {null}
Action = New
YourTradeID = B1
DTCCMember = 5555
EnteredBy = 5555
ContraParty = 8888
Action = Unconfirmed
YourTradeID = B1
DTCCMember = 5555
EnteredBy = 5555
ContraParty = 8888
BestFit = {8888 A1 Key}
Note: Sends in
corrections
causing a match
Action = Confirmed
YourTradeID = A1
ContraTradeID = B1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
BestFit = {5555 B1Cnf}
OTC Derivatives Conceptual Solution
8
9
DTCC Solutions - Internal Use Only
Action = Confirmed
YourTradeID = B1
ContraTradeID = A1
DTCCMember = 5555
EnteredBy = 5555
ContraParty = 8888
BestFit = {8888 A1 Cnf}
Page 12 of 16
DTCC SOLUTIONS
Conceptual Solution
Complex Matching Example
Action = New
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
1
Action = Unconfirmed
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
BestFit = {null}
Action = Alleged
ContraTradeID = B2
DTCCMember = 8888
EnteredBy = 5555
ContraParty = 5555
BestFit = {8888 A1 Near}
Action = Modify
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
6
Note: Did not
match
completely, but
did match on
key fields
8
Note: Did not
match, did not
match on key
fields
3
DTCC TRADE MATCHING ENGINE
Action = Alleged
ContraTradeID = B1
DTCCMember = 8888
EnteredBy = 5555
ContraParty = 5555
BestFit = {8888 A1 Key}
2
4
5
Note: Did not
match
completely, but
did match on
key fields
6
Note:Sends in a
2nd trade,
similar to the
first trade
7
Note: Did not
match, did not
match on key
fields
Action = Alleged
ContraTradeID = A1
DTCCMember = 5555
EnteredBy = 8888
ContraParty = 8888
BestFit = {null}
Action = New
YourTradeID = B1
DTCCMember = 5555
EnteredBy = 5555
ContraParty = 8888
Action = Unconfirmed
YourTradeID = B1
DTCCMember = 5555
EnteredBy = 5555
ContraParty = 8888
BestFit = {8888 A1 Key}
Action = New
YourTradeID = B2
DTCCMember = 5555
EnteredBy = 5555
ContraParty = 8888
Action = Unconfirmed
YourTradeID = B2
DTCCMember = 5555
EnteredBy = 5555
ContraParty = 8888
BestFit = {8888 A1 Near}
9
Note: Sends in
corrections, still
no confirming
match
Action = Unconfirmed
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
BestFit = {5555 B1Key},
{5555 B2 Near}
OTC Derivatives Conceptual Solution
10
11
DTCC Solutions - Internal Use Only
Action = Alleged
ContraTradeID = A1
DTCCMember = 5555
EnteredBy = 8888
ContraParty = 8888
BestFit = {5555 B1Key},
{5555 B2 Near}
Page 13 of 16
DTCC SOLUTIONS
Conceptual Solution
DTCC Edit Reject Examples
Malformed message, but
due to message envelope
whe know who sent in the
message
1
Note: contains malformed
message, can only
determine who sent it
Action = Rejected
YourTradeID = Unknown
DTCCMember = 8888
EnteredBy = 8888
ContraParty = Unknown
BestFit = {null}
RejectRsn = {Malformed}
1
Note: message follows
XML rules and schema but
does not follow business
rules
Action = Rejected
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
BestFit = {null}
RejectRsn = {code1},...
Action = Modify
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
Action = Rejected
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
BestFit = {null}
RejectRsn = {Sequence}
2
DTCC TRADE MATCHING ENGINE
Action = New
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
2
1
Note: follows XML &
business rules, but is
subsequent transaction
(Modify/Reject) where
primary transaction
unknown or in "Confirmed"
status
OTC Derivatives Conceptual Solution
2
DTCC Solutions - Internal Use Only
Page 14 of 16
DTCC SOLUTIONS
Conceptual Solution
Participant Trade Cancel Example
Action = New
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
Action = Alleged
ContraTradeID = B1
DTCCMember = 8888
EnteredBy = 5555
ContraParty = 5555
BestFit = {8888 A1 Key}
2
3
6
Note: Did not
match
completely, but
did match on
key fields
Action = Cancel
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
Action = CancelConf
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
BestFit = {5555 B1 Keyl}
OTC Derivatives Conceptual Solution
7
DTCC TRADE MATCHING ENGINE
Action = Unconfirmed
YourTradeID = A1
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
BestFit = {null}
1
8
4
5
Note: Did not
match
completely, but
did match on
key fields
9
DTCC Solutions - Internal Use Only
Action = Alleged
ContraTradeID = A1
DTCCMember = 5555
EnteredBy = 8888
ContraParty = 8888
BestFit = {null}
Action = New
YourTradeID = B1
DTCCMember = 5555
EnteredBy = 5555
ContraParty = 8888
Action = Unconfirmed
YourTradeID = B1
DTCCMember = 5555
EnteredBy = 5555
ContraParty = 8888
BestFit = {8888 A1 Key}
Action = Cancel
ContraTradeID = A1
DTCCMember = 5555
EnteredBy = 8888
ContraParty = 8888
BestFit = {5555 B1 Key}
Page 15 of 16
DTCC SOLUTIONS
Conceptual Solution
IDB Initiates Trades Example
Action = New
YourTradeID = IDB1
DTCCMember1 = 8888
DTCCMember2 = 5555
EnteredBy = XXXX
1
IDB Enters Valid
Trade
Action = Unconfirmed
YourTradeID = X8888
DTCCMember = 8888
EnteredBy = XXXX
ContraParty = 5555
BestFit = {5555 X5555 Key}
AgreeWithIt = No-8888
Action = Alleged
ContraTradeID = X5555
DTCCMember = 8888
EnteredBy = 8888
ContraParty = 5555
BestFit = {8888 X8888 Key}
AgreeWithIt = No-5555
Action = Modify
YourTradeID = X8888
DTCCMember = 8888
EnteredBy = XXXX
ContraParty = 5555
AgreeWithIt = Yes
3
4
5
Note: Did not
confirm since
AgreeWithIt
does not match
Note: Did not
confirm since
AgreeWithIt
does not match
8
Note: Did not
confirm since
AgreeWithIt still
does not match
9
Note: Sends in
corrections
causing a match
Action = Confirmed
YourTradeID = X8888
ContraTradeID = X5555
DTCCMember = 8888
EnteredBy = XXXX
ContraParty = 5555
BestFit = {5555 X5555 Cnf}
OTC Derivatives Conceptual Solution
DTCC TRADE MATCHING ENGINE
Action = Alleged
ContraTradeID = X5555
DTCCMember = 8888
EnteredBy = XXXX
ContraParty = 5555
BestFit = {8888 X8888 Key}
AgreeWithIt = Yes
2
6
7
Note: Did not
confirm since
AgreeWithIt still
does not match
10
11
DTCC Solutions - Internal Use Only
Action = Alleged
ContraTradeID = X8888
DTCCMember = 5555
EnteredBy = XXXX
ContraParty = 8888
BestFit = {5555 X5555 Key}
AgreeWithIt = No-8888
Action = Unconfirmed
YourTradeID = X5555
DTCCMember = 5555
EnteredBy = XXXX
ContraParty = 8888
BestFit = {8888 X8888 Key}
AgreeWithIt = No-5555
Action = Modify
YourTradeID = X5555
DTCCMember = 5555
EnteredBy = XXXX
ContraParty = 8888
AgreeWithIt = Yes
Action = Unconfirmed
YourTradeIDD = X5555
DTCCMember = 5555
EnteredBy = XXXX
ContraParty = 8888
BestFit = {8888 X8888 Key}
AgreeWithIt = No-5555
Action = Confirmed
YourTradeID = X5555
ContraTradeID = X8888
DTCCMember = 5555
EnteredBy = XXXX
ContraParty = 8888
BestFit = {8888 X8888 Cnf}
Page 16 of 16