EFET Electronic Confirmation
Matching
Version 4 Release 0 (v4.0 Final)
Created by EFET
Revision History
|
Version |
Date |
Changes |
Author
of changes |
|
2.1 |
April 04 |
Gathered Doc. 1-7 of EFET eCM standards and combined into one |
|
|
3.0 |
Sep 04 |
Issued |
EFET eCM Project Work Group |
|
3.1 |
Jul 05 |
Issued. Updated to include Broker Confirms |
EFET eCM Project Work Group |
|
3.1.1 |
Jan 06 |
Corrections to V3.1. This version contains no process enhancements. |
EFET eCM Project Work Group |
|
3.2 |
Feb 06 |
Updated to include Emissions Confirmation and minimum compliancy requirements to Chapter 7 |
EFET eCM Project Work Group |
|
3.3 |
Dec 07 |
Updated to include financial instruments. Final review by KEMA Consulting. |
EFET eCM Project Work Group |
|
3.3.1 |
Feb 09 |
Updated follow SAT of v3.3 and development and testing of the KEMA Certification Service |
SAT group on behalf of the EFET eCM Project Work Group |
|
4.0 |
July 2010 |
Updated to include Physical Coal, amendment of cancellations, amendment of matched documents, tear-up of match documents and service based operation. |
EFET eCM PwG Signed off by EFET BPOC 8th Sep 2010 |
References
|
Reference ID |
Document
Name |
Document
Version.Release |
Document
Publishing Date |
|
1 |
EFET electronic Communmications Standard |
1.0 |
June 2010 |
|
2 |
EFET Communication eCM v4.0 Profile |
1.0 |
June 2010 |
Copyright notice
Copyright © EFET 2010. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to EFET except as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by EFET or its successors.
This document and the information contained herein is provided on an "as is" basis.
EFET DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Content
1.1 The Need for EFET Standards
2.1 Roles and Responsibilities in Standardisation
3 Current Processes and
Business Requirements
3.1 Current Business Processes
Description of Current Trade Confirmation Process
Issues linked to Current Process
3.2 Requirements for Electronic Business Processes
4 Electronic Business
Processes – Overview
4.2 High Level Business Document Flows
High Level Business Document Match Processing
High Level Business Document Amendment Processing
High Level Business Document Cancellation Processing
High Level Matched Document Tear-Up Processing
High Level Business Document Submission and Result
Process
Role of the ‘Multi-Tenant’ Process Implementation in
Peer-to-Peer Matching
4.3 Detailed Business Document Flows
Detailed Business Document Match Processing
Detailed Business Document Amendment Processing
Detailed Business Document Cancellation Processing
Detailed Matched Document ‘Tear-Up’ Processing
Detailed Submission and Results Processing
Legal and Confidentiality Issues
4.4 Business Document Processing
‘Suggested Match Acceptance/Refusal’ Processing
‘Trade Data’ and Broker ‘Match’ Processing
Recommendations for ‘Potential Match’ Processing
Avoiding Race Conditions between two EFET Boxes
5 Electronic Business
Processes – by Document Types
5.1 Naming and Typing Conventions
Trade Confirmation – Document Root
Trade Confirmation Section XML Schema
Trade Confirmation – EUA Trade Details
EUA Trade Details Section XML Schema
Trade Confirmation – Physical Coal Trade Details
Physical Coal Trade Details Section XML Schema
Trade Confirmation – Option Details
Options Details Section XML Schema
Trade Confirmation – Delivery Periods Details
Delivery Periods Section XML Schema
Trade Confirmation – Fixed Price Information
Fixed Price Information Section XML Schema
Trade Confirmation – Float Price Information
Float Price Section XML Schema
Document specific Business Rules – Trade Confirmation
Trade Confirmation document Field Specifications
Section Time Interval Quantities
Calculation and Delivery Periods
Trade Confirmation document XML Schema
Match Suggestion Document XML Schema
5.4 Match Suggestion Acceptance Document
Match Suggestion Acceptance Document XML Schema
Match Suggestion Refusal Document XML Schema
Document specific Business Rules
Cancellation Document XML Schema
Acknowledgement Document XML Schema
Document specific Business Rules for Rejections
Broker Confirmation Section XML Schema
Broker Confirmation – EUA Trade Details
EUA Trade Details Section XML Schema
Broker Confirmation – Physical Coal Trade Details
Physical Coal Trade Details Section XML Schema
Broker Confirmation – Option Details
Options Details (Broker) Section XML Schema
Broker Confirmation – Delivery Periods Details
Delivery Periods (Broker) Section XML Schema
Broker Confirmation – Fixed Price Information
Fixed Price Information (Broker) Section XML Schema
Broker Confirmation – Float Price Information
Float Price Section XML Schema
Document specific Business Rules – Broker Confirmation
Broker Confirmation document Field Specifications
Broker Confirmation document XML Schema
5.9 Broker Fee Information Document
Broker Fee Information Document XML Schema
Document specific Business Rules for Broker Fee
Information
5.10 Broker Match Notification Document
Broker Match Notification Document XML Schema
Document specific Business Rules for Broker Match
Notification
Tear-Up Request Document XML Schema
6.1 Business Document State Processing
6.1.1......... State Processing for the Trade Confirmation in the
Counterparty Dialogue
6.1.2................... State Processing for the Trade
Confirmation in the Broker Dialogue
6.1.3............. State Processing for the Broker Fee
Information in the Broker Dialogue
6.1.4.................. State Processing for the Broker
Confirmation in the Broker Dialogue
6.2 General Document Exchange State Processing
6.3 Acknowledgement/Rejection Document State Processing
6.4 Detailed Transition Processing
6.4.1.5. Matched
to Tear-Up Requested
6.4.1.6. Tear-Up
Requested to Cancelled
6.4.1.9. Peer-to-Peer
Matching Dialogue
Potential Match to Match Suggested
6.4.2.1. Pending
or Preliminary Matched to Amended
6.4.2.2. Pending
or Preliminary Matched to Cancelled
6.4.2.1. Pending
to Matched or Preliminary Matched
6.4.2.2. Preliminary
Matched to Pending
6.4.2.3. Preliminary
Matched to Matched
6.4.2.1. Peer-to-Peer
Matching Dialogue
Potential Match to Preliminary Matched or Matched
6.4.3.2. Pending
or Preliminary Matched to Amended
6.4.3.3. Pending
or Preliminary Matched to Cancelled
6.4.3.2. Pending
to Matched or Preliminary Matched
6.4.3.3. Preliminary
Matched to Pending
6.4.3.1. Preliminary
Matched to Matched
6.4.3.2. Peer-to-Peer
Matching Dialogue
Pending to Potential Match (Trader instance only)
Potential Match to Preliminary Matched or Matched (Trader
instance only)
Pending to Preliminary Matched or Matched (Broker
instance only)
6.4.4.2. Pending
or Preliminary Matched to Amended
7 Communication Protocol
and Interfaces
Appendix A. Definition of eCM Types and
Codes
Appendix B. Glossary of Data Elements and
Terms
B.1. Context Specific Data Elements in Alphabetic Order
Appendix C. Definition of Vanilla and
Complex Products
Appendix D. Backwards Compatability with
v3.3.1
Appendix E. Clarifications to the
Standard and Subsequent Versions
List of Tables
Table
1 Possible matching scenarios supported by eCM v4.0
Table 2: Specification of Trade Confirmation Elements
Table 3: Business Rules for Trade Confirmation Documents
Table 4: Element Specification for Match Suggestion
Table 5: Element Specification for Match Suggestion
Acceptance
Table 6: Element Specification for Match Suggestion
Refusal
Table 7: Element Specification for Cancellation
Table 8: Business Rules for Cancellation
Table 9: Element Specification for Acknowledgement
Table 10: Element Specification for Rejection
Table 11: Business Rules for Rejections
Table 12: Specification of Broker Confirmation Elements
Table 13: Business Rules for Broker Confirmation
Documents
Table 14: Element Specification for Broker Fee
Information
Table 15: Business Rules for Rejections
Table 16: Element Specification for Broker Match
Notification
Table 17: Business Rules for Rejections
Table 18: Element Specification for Tear-Up Request
Table 22: Context-specific Data Elements in alphabetic
Order
List of Figures
Figure
1 Organisation of the EFET working groups
Figure 2 Use Case Diagram for eCM
Figure 3 Counterparty Confirmation Matching dialogue with
tenant Traders
Figure 4 Counterparty Confirmation Matching dialogue with
tenant 'buyer' and peer-to-peer 'seller'
Figure 5 Counterparty Confirmation Matching dialogue with
tenant 'seller' and peer-to-peer 'buyer'
Figure 9 Trilateral Matching dialogue with tenant
counterparties and Broker (incl. BFI)
Figure 10 Trilateral Matching dialogue with tenant
Traders and peer-to-peer Broker (incl. BFI)
Figure 13 Trilateral Matching dialogue with tenant Broker
and peer-to-peer Traders (incl. BFI)
Figure 14 Document flows for amendment of a Trade
Confirmation in the Counterparty Matching dialogue
Figure 15 Document flows for amendment of a Trade
Confirmation in the Broker Matching dialogue
Figure 22 Document flows for the tear-up of a pair of
matched Trade Confirmation documents
Figure 24 Document flows for reconciling the tearing-up
of a previously matched deal
Figure 26 XML Schema for the TradeConfirmation Document
Figure 27 XML Schema for the MatchSuggestion Document
Figure 28 XML Schema for the MatchSuggestionAcceptance
Document
Figure 29 XML Schema for the MatchSuggestionRefusal
Document
Figure 30 XML Schema for the Cancellation Document
Figure 31 XML Schema for the Acknowledgement Document
Figure 32 XML Schema for the Rejection Document
Figure 33 XML Schema for the BrokerConfirmation Document
Figure 34 XML Schema for the Broker Fee Information
Document
Figure 35 XML Schema for the Broker Match Notification
Document
Figure 36 XML Schema for the Tear-Up Request Document
Figure 37 Counterparty Process Trade Confirmation
Document State Diagram
Figure 38 Trade Confirmation Document Broker Dialogue
State Diagram
Figure 39 Broker Fee Information Document StateDiagram
Figure 40 Broker Confirmation State Diagram
Figure 41 General Document State Processing
Figure 42 Acknowledgement/Rejection State Processing
1 Executive Summary
1.1 The Need for EFET Standards
Problem Definition
Communication is an essential key to the successful integration of business processes. Successful communication requires that the communicating parties speak the same language. This fact is as important in electronic communication as it is in face to face communication.
As volumes increase in energy trading, business transactions are occurring more rapidly, and trading volumes are growing, traditional means of communication like phone and fax are necessarily being replaced as a core communication medium, by automated electronic communication.
Increasingly energy trading companies are looking towards the integration of internal and external business processes, with the eventual aim of straight-through processing. This is to enhance process efficiency, as well as to reduce operational risk, both of which reduce overall transaction costs.
The energy trading industry does not have in use widely accepted electronic communication standards. Like the financial industry there are some standards for specific parts of the industry, but the fragmentation is arguably even higher in the energy trading industry. Currently each service provider (exchanges, broker platforms, clearing houses, matching services, etc.) and each software vendor use their own proprietary “standard”, requiring implementation of a different interface and cumbersome translation for each of these “standards”. This results in a costly and risky “spaghetti” network of interfaces.
To solve the business process integration problem, common electronic communication standards (a common language) must be established within the energy industry and adopted within individual organisations. The messages and processes that need standardisation in the Energy Trading industry include Trade Confirmations, Scheduling and Logistics, Clearing and Settlement, and Quotes.
By standardising the exchange of this information and the corresponding processes both internally and externally, companies could reduce costs and streamline business processes. Standardisation has to be driven by the industry itself, and coordinated by an accepted industry wide neutral body.
The Solution: EFET Standards
EFET is an industry wide neutral body that can coordinate the creation and maintenance of industry standards. EFET project workgroups comprising members from the Back Office Group and IT Taskforce are specifically responsible for defining the EFET Standards for electronic exchange of information.
The EFET standards will define the structure of the electronic messages, as well as how these electronic messages are exchanged. The EFET standards apply to all electronic messages exchanged in the energy trading environment, and therefore can be considered a general standard.
These standards will also define the reference codes (vocabulary of the language) to be used for commonly used data within these electronic messages. This includes the unique codes identifying the different trading parties, and the reference codes for energy specific characteristics such as market, commodity, etc. These reference codes could also be used in paper and fax communications.
1.2 The eCM initiative
eCM as a pilot
EFET has decided on a prioritised approach to the development of standards covering the various business processes to facilitate rapid deployment of the systems and infrastructure required to implement working services. The eCM Project Workgroup has been tasked with focusing on one part of the overall information exchange, but with consideration to broader integration of processes in the future. Developing standards for a specific business process rather than attempting to cover all process simultaneously, will enable the production of measurable benefits throughout the overall standardisation process.
The business process concerning the exchange and validation of electronic trade confirmations has been prioritised for the first phase of standardisation. This will be referred to as eCM, which stands for “Electronic Confirmation and/or Matching”.
As a first step, the eCM process itself has been clearly defined and agreed. The workflow has been established defining how two trading parties will interact to confirm a deal and the message flows and message structure definitions needed to support this process have been defined.
These EFET eCM standards consist of the definition of the exact message flow, message content and message structure for the information exchanged during an eCM process.
EFET Compliant eCM Processes
The eCM Project Workgroup has structured the eCM process on a bilateral or peer-to-peer style of interaction where responsibility for accurate matching resides with each party. An alternative style of interaction using 3rd party agencies to implement matching on behalf of each party has been considered but rejected in favour of the peer-to-peer approach.
Note: The EFET compliant eCM processes describe how trade confirmations can be matched electronically. This does not mean that confirming a deal via fax is no longer possible. In fact, trade confirmations via fax will always exist as a fall back solution in case of technical problems with the electronic confirmation system, and for non-standardised, complex or structured products.
The EFET eCM Standards
The EFET eCM standards consist of the definition of the message flow, message content and message structure for the information exchanged during an eCM process.
The structure of the eCM messages, and to some extent the content of the messages, will form the basis for the development of other EFET messages that will be defined in the future. These EFET eCM standards will therefore act as an important initial step towards the definition of global EFET standards covering the complete business requirements of traders.
Disclaimer: This standard will not overrule other documents (e.g. EFET Master Agreement). Results of this standards may have influence on the next version on these documents.
Next Steps
In each subsequent phase, the general EFET Standards will be extended to support further business processes, including describing the standard interface between processes (see the EFET eCM Standards).
The general EFET Standards will be extended to support each specific process and to describe it in greater detail (see the EFET eCM Standards) once agreement has been reached upon the standardization of the process itself.
Service and/or system providers will be encouraged to comply with these standards. Companies will thus be able to achieve integration with these different service providers and/or systems without having to develop and maintain a different interface for each.
When the eCM project has been implemented, it is the intention to focus on other projects to stimulate electronic exchange of data, e.g. for nomination, scheduling, clearing, settlement and other processes to make energy trading more efficient.
EFET will cooperate with other organisations and stimulate harmonisation and standardisation to increase electronic exchange of data in the European Energy industry.
1.3 Conclusions
Communication is an essential key to the
successful integration of business processes. To solve the business process
integration problem, common electronic communication standards (a common
language) must be established within the energy industry and adopted within
individual organisations.
EFET has selected the trade confirmations process as the first project for standardisation. This project is called the eCM (“Electronic Confirmation and Matching”) project and is driven by the urgent need for the back office to automate manual confirmation processes.
After consideration the peer-to-peer model of interaction has been preferred over the alternative agency based model as a progressive enhancement to the current faxed based process in which responsibility for accuracy of matching resides with each party.
It is expected that further standardisation work will be done to facilitate the electronic exchange of data to further increase efficiency in the European Energy Industry.
2 Overview
2.1 Roles and Responsibilities in Standardisation
The EFET Board oversee all the activities undertaken or sponsored by EFET. Responsibility for coordination of Back Office activities has been delegated to the Back Office Group. Responsibility for coordination of IT activities has been delegated to the IT Task Force. Project Workgroups, such as the eCM Project Workgroup, which carry out specific activities on behalf of EFET. The eCM Project Workgroup is sponsored by the EFET Board, controlled by the BO Group and comprises specialist personnel from both the Back Office and IT business areas.
Figure 1 Organisation of the EFET working groups
2.2 Version Control
The EFET standards documentation for electronic confirmation matching comprises a single document with chapters and sections.
2) Each chapter shall be a configuration item within the single document controlled by either the eCM Project Workgroup and audited via the Revision History between major releases leading to intermediate versioning i.e. 1.1, 1.2, 1.3…(Also release version with change bars)
Note that draft versions are signified by using a letter: 1.1a
The related XML Schemas are expected to be backward compatible within the same version. I.e., an eCM process implementation that is able to process Trade confirmations in version 3, release 3 is also able to process version 3, release 2 and version 3, release 1 – but not, e.g., version 2, release 3.
I.e., extensions to the EFET XML Schema within the same version, can only add optional elements or attributes or reduce the number of values in enumerations. Each eCM process implementation should therefore be able to process earlier releases within the same version.
Should different versions be supported (since individual counterparties may update their systems at different times), dedicated eCM process implementation implementations should handle version-specific eCM protocols.
3 Current Processes and Business Requirements
3.1 Current Business Processes
Description of Current Trade Confirmation Process
The current trade matching processes are generally paper based requiring both parties to produce documents that summarise the transaction. These documents are passed between each party to confirm that the transaction details are accurate and valid.
The main steps in the process are:
1. A transaction is agreed between two parties and details of the transactions are entered into each party’s trade management system
2. An internal check (usually manual) is normally undertaken by each party to ensure that the transaction details have been accurately entered into the trade management system
3. A Trade Confirmation document is then generated by the trade management system. The Trade Confirmation document is checked for accuracy. The trade confirmation might also be signed by the originator (normally the Seller) as an accurate summary of the trade details and then faxed or digitally sent to the recipient party (normally the Buyer) for that transaction
4. The recipient party then checks the trade confirmation. (A number of trade management systems will generate a confirmation independently of the fact that the party is the Buyer or the Seller. The Buyer will often use their version of the confirmation to check the details of the Seller’s confirmation). If the recipient party agrees with the details of the transaction, they might sign the trade confirmation to confirm that the details are accurate and valid.
5. The recipient party’s signed document might then be faxed back to the originator of the confirmation. This is then a paper affirmation or authentication.
6. Each party will enter information into their trade management system to indicate that the transaction has been authenticated.
7. The paper work associated with the trade data capture and trade confirmations will, at an appropriate point in time, be archived and retained for a number of years (depending upon local procedures and laws)
8. In the event that the transaction details are not agreed as accurate (or the Seller has not raised a confirmation):
· The party finding the mistake first will contact the other party (normally verbally) to indicate the details that are not agreed (or in the case where the Seller did not send a confirmation the Buyer will contact the Seller to indicate that the confirmation has not been received)
· After investigations the transactions details are agreed
· Steps 1 to 8 are repeated such that an accurate and confirmed transaction is recorded in each party’s trade management system.
Many variations of this process exist. Depending on the agreements (Master Agreements like EFET2.1 or industry accepted terms and conditions like NBP97) that exist between the two parties, both the Buyer and the Seller will send a confirmation or only Seller will send a confirmation and the Buyer will affirm or authenticate:
· One of the parties (logically the Seller) has to send the trade confirmation to the other party. The Buyer will then check this confirmation against its own record of the trade. If consistent he will consider the trade confirmed. He might or might not send back by fax an authentication (signed acknowledgement authenticating the confirmation). Certain parties require an authentication of their confirmation to be sent back and will systematically expect one, others will not.
· Both parties send each other the trade confirmation and each will check for itself the validity of the received party’s confirmation against its own trade data. If consistent the trade is then considered “confirmed”. Even in this case one of both parties might still send back an authentication of the received confirmation.
· In the case where a trade is concluded by mediation of an intermediary (either on an e-OTC platform or a voice broker), the intermediary sends a broker “confirmation” of the transaction to both the Buyer and the Seller. It is also customary for a trader to check at the end of the day by phone, the trades concluded via a certain broker. Some e-OTC platforms either list the executed trades or immediately after execution send an email to the trader with the trade details.
Some industry participants refer in the confirmation to an existing Master Agreement in place between both parties. In case no Master is in place, the confirmation might contain certain legal language to ensure legal enforceability of the trade.
The content of the confirmations will also typically vary according to the product (gas, power, oil, …), the transaction type (forward, day ahead, intraday, options, …), the delivery point, Master Agreement and the legal framework.
In case of a dispute, the transaction tapes or the transaction log of an e-OTC platform will always prevail on the written documents (confirmations) irrespective if they are matched or authenticated. Of course, it goes without saying, that if the confirmations match or the confirmation of the Seller is authenticated by the Buyer, it would be highly unlikely for the traders to revert successfully to the transaction tapes and the trade would stand as confirmed.
Important Note: Currently, no unique trade reference for a trading transaction exists between the parties (as is customarily the case for example for the purchase of airline tickets). Each party defines its own unique TradeID.
Issues linked to Current Process
Major issues with the current process are:
· Cost and operational risk linked to manual processing of confirmations
· Archiving cost of paperwork
· Neither the process itself nor the material terms of the trade are standard, introducing complexity in the confirmation matching process and trade follow up
· Risk linked to delay in identifications of trade data capture errors and inconsistencies between parties.
3.2 Requirements for Electronic Business Processes
The Goal of the current project is to find a common solution for the automation of the transmission, reception, matching and processing of electronic trade confirmations.
The EFET organisation itself will provide a central EFET directory service and will ensure maintenance of the standard with the publication of new codes etc… See also Section 7.5.
eCM Business Process Scope
The aim of the EFET eCM Project Workgroup is to define a “standard electronic confirmation process” and thus provide a framework enabling parties to:
· Replace the manual transfer of information with the electronic transmission of standard confirmation data between two parties (on a peer-to-peer basis)
· Facilitate the reporting and capture within their trade management systems of electronic data related to the trade confirmation process
· Legal Requirements are covered by the Master Agreement which is refer to by each trade confirmation document.
· Security Requirements are covered by using ebXML as the basic transport protocol for transfer of eCM documents.
4 Electronic Business Processes – Overview
This section describes the workflow defined for the standard EFET compliant eCM process. For this purpose the actors and their systems are considered to be “black boxes”. EFET has restricted itself to defining the interface requirements for the incoming and outgoing documents and matching criteria where appropriate.
N.B. for the purpose of defining the role of Buyer and Seller for Financial Transactions where there is no exchange of any physical commodity or other indication the following convension is used within the eCM process: the party with the lesser identification code value (using alphabetical sorting) shall be deemed the ‘‘Seller’ and the counterparty with the greater identification code value (using alphabetical sorting) shall be deemed the ‘Buyer’.
4.1 Actors and Roles
Figure 2 Use Case Diagram for eCM
Figure 2 Use Case Diagram for eCMprovides an overview of the scope and context of the eCM process. A trade is carried out between traders or through the help of a broker. Once the transaction has been executed, each respective information system is updated with the trade data. Each information system then transmits a confirmation document to the eCM process which conducts the matching in order to reconcile any differences between the independent records of the trade data, any exceptions resulting from the matching process are manually resolved.
Version 4.0 of the eCM process introduces the concept of ‘multi-tenanancy’ as an possible deployment option for implementations of the process. The matching dialogue between ‘tenants’ of the same shared process instance can be optimised to dispense with some steps in the defined matching dialogue since all data required for achieving a match between two ‘tenants’ sharing the same implementation will be present locally; conversely, matching between counterparties who do not happen to be ‘tenants’ of the same implementation will require the full peer-to-peer dialogue to be completed. This approach permits some parties the option to reduce the operational overheads of operating their own eCM installation whilst retaining matching continuity with parties that prefer to retain operational control of their own independent implementation of the process.
4.2 High Level Business Document Flows
High Level Business Document Match Processing
The eCM process provides Traders and Brokers with the following matching capabilities:
· Counterparty Trade Confirmation Matching: the bilateral matching of Trade Confirmation documents between the two counterparties to a trade
· Broker Confirmation Matching: the independent bilateral matching of Trade and Broker Confirmation and optionally Broker Fee Information documents between the Broker of a trade and both (or either) of the Traders
· Trilateral Confirmation Matching: the cross matching of a Trader’s Trade Confirmation and optionally Broker Fee Information document(s) with the Counterparty’s Trade Confirmation and the Broker’s Broker Confirmation document.
Trilateral matching is in effect the combination of both Counterparty and Broker Matching dialogues into a two ‘legged’ matching dialogue which matches the counterparty Trade Confirmation document with a Trader’s Trade Confirmation document via one ‘leg’ and the Broker Confirmation with the same Trade Confirmation and optionally Broker Fee Information documents via the other ‘leg’. Use of the same Trade Confrimation document ensures the integrity of the trilateral match and avoids the possibility that different versions of the deal are separately matched with the Broker and with the Counterparty over time leading to two independent matches for the same deal on differing commercial terms, should there have been an amendment of the deal between matching with Broker and Counterparty. The Trader is therefore prevented from independently submitting separate Trade Confirmation documents for the same trade to both the Counterparty Trade Matching dialogue and to the Broker Confirmation Matching dialogue.
High Level Counterparty Trade
Confirmation Matching Dialogue
Both trading parties submit a Trade Confirmation document to the eCM process. A Trade Confirmation document is considered to have fully entered the eCM process once it has been well processed. Successfully submitted documents are assigned to the ‘Pending’ state and become subject to matching otherwise they are rejected from the process.
The instance of the process where the buyer is registered takes the lead in initiating the matching dialogue and applies the ‘Suggested Match’ Processing algorithm specified in 4.4 Business Document Processing to establish a ‘Suggested Match’ which is communicated to the seller’s instance and if successfully verified using the ‘Suggested Match Acceptance/Refusal’ Processing algorithm specified in 4.4 Business Document Processing, results in a ‘Match Acceptance’ to finalise the dialogue and establish the match between the two Trade Confirmation documents.
In the case of a ‘multi-tenant’ implementation the exchange of Trade Confirmation documents and subsequent issue of the ‘Match Suggested’ and ‘Match Accepted’ documents are not required within the matching process since it is no longer distributed and a single agreed result is achieved by virtue of using the ‘locally’ available Trader Confirmation documents present in the same shared process instance.
A ‘Match’ result in the form of a ‘Box Result’ document is returned to each party.
High Level Broker Confirmation Matching Dialogue
The Trader and the Broker each submits a document, either a Trade Confirmation and optionally a Broker Fee Information document in the case of the Trader, or in the case of a Broker, a Broker Confirmation, to the process. The documents are considered to have fully entered the eCM process once they have been well processed and are then set to the ‘Pending’ status.
As indicated the Trader can optionally elect to match brokerage fees with the Broker through the eCM process. The choice is in effect a parameter to the matching algorithm (i.e. it can be enabled for matching or disabled for matching depending on the Trader’s preference) causing the Broker Fee Information document to be included, or not, within the match. If the Trader elects to match brokerage then they must submit an associated Broker Fee Information document with any Trade Confirmation that they submit to the Broker Matching dialogue. If the Trader elects not to match brokerage then they must not submit an associated Broker Fee Information document with any Trade Confirmation that they submit to the Broker Matching dialogue, any Broker Fee Information document submitted in this case will be rejected from the process. The level of control (e.g. per counterparty, per broker, per commodity etc.) at which the matching parameter is controlled is a matter for implementers to decide.
Once the documents have been successfully submitted the Trader instance of the process applies the ‘Trade Data’ and Broker ‘Match’ Processing algorithm specified in 4.4 Business Document Processing to establish a ’Match’ between the Broker Confirmation and the Trade Confirmation and optional Broker Fee Information documents which is communicated to the Broker instance through the issue of a ‘Broker Match Notifcation’.
In the case of a ‘multi-tenant’ implementation, with Trader and Broker, the exchange of documents and subsequent issue of the ‘Broker Match Notification’ are not required within the matching process since it is no longer distributed and a single agreed result is achieved by virtue of using the ‘locally’ available documents present in the same shared process instance.
A ‘Match’ result in the form of a ‘Box Result’ document is returned to each party.
High Level Trilateral Matching Dialogue
The Trader submits a single Trade Confirmation document to both the Counterparty Trade Confirmation Matching and to the Broker Confirmation Matching dialogues supported by the eCM process and in the latter case, optionally, a Broker Fee Information document. The appropriate match processing is invoked for each ‘leg’ of the match, as described previously for each dialogue.
The dialogue for each leg of the match proceeds independently as soon as the documents required by the dialogue have successfully entered the process; it is however possible for the Trader to prioritise the Broker Confirmation Matching dialogue so that it must be completed before the Counterparty Matching dialogue can commence. In either case the result of the Counterparty Confirmation Matching dialogue is deemed to take precedence over the Broker Confirmation Matching dialogue since the former relates directly to the confirmation of the underlying trade, whereas the latter is considered to corroborate the counterparty match result. The Broker leg of the trilateral match is therefore not considered fully ‘Matched’ until a ‘Match’ has been established in the Counterparty leg. The documents in the Broker leg are set to an interim state of ‘Preliminary Matched’ until the Counterparty leg is completed and then moved to the final ‘Matched’ state to complete the Trilateral Matching Dialogue.
Matching results for each leg of the trilateral match are returned for each dialogue in the form of ‘Box Result’ documents as described above to each relevant party.
High Level Business Document Amendment Processing
Documents submitted for match processing can be amended by the document ‘owner’ if the originally submitted document is in an amendable state, otherwise the new document will be rejected by the eCM process.
Documents already in a ‘Matched’ state can be amended in version 4.0 of the eCM process however the new versions of a currently matching pair of documents can only be matched with one another as stated in 4.4 Business Document Processing ‘Suggested Match’ Processing. This constraint enables the ‘owners’ of the documents in a matching pair to use the existing matching dialogues to mutually amend the content of the matched documents, and thus reconcile changes made to the terms of the underlying deal, after completion of the original match processing which established a link between the separately held trade records. Traders and Brokers may configure this dialogue on or off for ‘Matched’ documents. If the dialogue if configured ‘off’ by any party then an amendment submitted by any of the parties will be rejected from the process, otherwise it will be processed.
It is strongly recommended that implementers
notify users of amendments to ‘Matched’ business documents.
A new document must contain the same reference number but a higher version number than the document to be amended. The high level processing of amendments for each eCM business document in each matching dialogue is described below.
High Level Trade Confirmation Amendment
Processing
A Trade Confirmation document may already be
‘Matched’ as a result of, or be participating in, the Counterparty Trade
Confirmation Matching dialogue, the Broker Confirmation Matching dialogue or
both these dialogues as part of the Trilateral Matching dialogue. There will be
no limit placed on this functionality within the process but business users
must consider the relevance of the dialogue for a document that refers to an underlying
trade that has passed its maturity date or other major lifecycle event.
Using the amendment process a Trade
Confirmation document in the Counterparty Matching dialogue can be entered into
a Trilateral Matching dialogue, through inclusion of a Broker; and a Trade
Confirmation document in the Broker Matching dialogue can be entered into a
Trilateral Matching dialogue, through amending the Reciever ID of the
recipient; it is not possible however to cancel a ‘leg’ of a Trilateral
Matching dialogue by amending the Trade Confirmation document to remove the
broker or change the recipient, this can only be achieved using processing
described in High Level Business
Document Cancellation Processing.
A Trade Confimation Document in the
Counterparty Trade Confirmation Matching or in the Broker Confirmation Matching
dialogue is in an amendable state if it has not yet
fully entered the process or if it has fully entered the process and is in the
‘Pending’ or ‘Matched’ state.
A Trade Confimation Document in the
Trilateral Matching dialogue is in an amendable state if it has not yet fully entered the process or if it has fully entered
the process and is in the ‘Pending’ or ‘Matched’ state in the Counterparty
dialogue and in the ‘Pending’, ‘Matched’ or ‘Preliminary Matched’ state in the
Broker dialogue .
The successfully submitted ‘new’ Trade Confirmation document is assigned to the ‘Pending’ state. If the ‘old’ Trade Confirmation is matched then it remains in the ‘Matched’ state, otherwise the ‘new’ document replaces the ‘old’ Trade Confirmation document in each of the dialogues in which the ‘old’ document was active and the ‘old’ document is removed from further processing and set to the ‘Amended’ state. If the amendment is to a ‘Matched’ trade Confirmation document then the status for the ‘old’ Trade Confirmation document is not changed to ‘Amended’ until after the ‘re-match’ of the new counterparty Trade Confirmation documents.
If the original Trade Confirmation document
has established a ‘Preliminary Match’ with a Broker Confirmation document,
optionally including a Broker Fee Information document, in the Broker leg of
the Trilateral Matching dialogue then the amendment of the matched Trade
Confirmation document will cause the respective Broker Confirmation (and
optionally the Broker Fee Information) document(s) to be set to the ‘Pending’
state along with the new Trade Confirmation document. Any ‘Preliminary Match’ between
the original Trade Confirmation document and the Broker Confirmation is rolled
back since the trade details in the Trader’s ETRMS for the trade have changed
and the matching with Broker must be started again. A Broker Match Notification
document is issued to the Broker by the Trader to convey the change of state
back to ‘Pending’, although this is not required for the case where Trader and
Broker are tenants of the same shared process instance.
Note that no Broker Match
Notification is issued in the case of an amendment to a Trade Confirmation
matched with a Broker Confirmation.
A ‘Box Result’ document is returned from the process to each of the parties providing a status update to the ETRMS and Broker back end system as appropriate.
High Level Broker Confirmation
Amendment Processing
A Broker Confirmation document in the Broker
Confirmation Matching dialogue is in an amendable state if it has not yet fully entered the process or if it has fully entered the
process and is in the ‘Pending’, ‘Matched’ or ‘Preliminary Match’ state. There will be no limit placed on this functionality within the process
but business users must consider the relevance of the dialogue for a document that
refers to an underlying trade that has passed its maturity date or other major
lifecycle event.
The successfully submitted ‘new’ Broker Confirmation document is assigned to the ‘Pending’ state. If the ‘old’ Broker Confirmation is matched then it remains in the ‘Matched’ state, otherwise the ‘new’ document replaces the ‘old’ Broker Confirmation document which is removed from further business processing and set to the ‘Amended’ state.
If the Broker Confirmation document has
established a ‘Preliminary Match’ with a Trade Confirmation document,
optionally including a Broker Fee Information document, in the Broker leg of
the Trilateral Matching dialogue then the amendment of the matched Broker
Confirmation document will cause the respective Trade Confirmation (and
optionally the Broker Fee Information) document(s) to be set to the ‘Pending’
state along with the new Broker Confirmation document. Any initial match
between the original Broker Confirmation document and the Trade Confirmation is
rolled back since the trade details in the Broker’s back end system have
changed and the matching with the Trader must be started again. A Broker Match
Notification document is issued to the Broker by the Trader to convey the
change of state back to ‘Pending’, although this is not required for the case
where Trader and Broker are tenants of the same shared process instance.
A ‘Box Result’ document is returned from the instance of the process to each of the parties providing a status update to the ETRMS and Broker back end system as appropriate.
High Level Broker Fee Information
Amendment Processing
A Broker Fee Information document in the
Broker Confirmation Matching dialogue is in an amendable state if has not yet fully entered the process or if it has fully entered the
process and is in the ‘Pending’ or ‘Matched’ state. There will be no limit placed on this functionality within the process
but business users must consider the relevance of the dialogue for a document
that refers to an underlying trade that has passed its maturity date or other
major lifecycle event.
The successfully submitted document is assigned to the ‘Pending’ state. If the ‘old’ Broker Fee Information document is matched then it remains in the ‘Matched’ state, otherwise the ‘new’ document replaces the ‘old’ Broker Fee Information document is removed from further business processing and set to the ‘Amended’ state.
If the Broker Fee Information document has,
with the associated Trade Confirmaiton, established a ‘Preliminary Match’ with
a Broker Confirmation document in the Broker leg of the Trilateral Matching
dialogue then the amendment of the matched Broker Fee Information document will
cause the respective Trade Confirmation and Broker Confirmation documents for
be set to the ‘Pending’ state along with the new Broker Fee Information
document. Any preliminary match between the original Broker Confirmation
document and the Trade Confirmation and Broker Fee Information is rolled back
since the trade details in the Trader’s ETRMS relating to the brokerage for the
trade have changed and the matching with Broker must be started again. A Broker
Match Notification document is issued to the Broker by the Trader to convey the
change of state back to ‘Pending’, although this is not required for the case
where Trader and Broker are tenants of the same shared process instance.
Note that the Broker Fee Information
document can be amended according to this dialogue independently of the state
of the Trade Confirmation document in the Counterparty ‘leg’ of a Trilateral
Matching dialogue. If the Counterparty ‘leg’ is ‘Matched’ but the Broker ‘leg’
remains in ‘Pending’ due to a discrepancy in the brokerage the Counterparty can
still amend the Broker Fee Information to achieve a full ‘Match’ with the
Broker.
A ‘Box Result’ document is returned from the instance of the process to each of the parties providing a status update to the ETRMS and Broker back end system as appropriate.
High Level Business Document Cancellation Processing
Documents submitted for match processing can be cancelled by the document ‘owner’ if the originally submitted document is in a cancellable state, otherwise the Cancellation document will be rejected by the eCM process. The Cancellation document is described in 5.5 Cancellation Document. The high level processing of the cancellation for each eCM business document in each matching dialogue is described below.
High Level Trade Confirmation Cancellation
Processing
A Trade Confirmation document may be participating
in the Counterparty Trade Confirmation Matching dialogue, the Broker
Confirmation Matching dialogue or in both these dialogues as part of the
Trilateral Matching dialogue.
A Trade Confimation Document in the
Counterparty Trade Confirmation Matching or in the Broker Confirmation Matching
dialogue can only be ‘Cancelled’ if it is awaiting match processing and in the
‘Pending’ state or if it has not fully entered the dialogue.
A Trade Confimation Document in the
Trilateral Matching dialogue can be ‘Cancelled’ from the Broker leg or from both
of the legs of the dialogue; for reasons of backward compatibility with earlier
versions of the standard it cannot be cancelled only from the Counterparty leg other
than through cancellation of the Trade Confirmation document (from both legs)
and resubmission just to the Broker Matching dialogue.
The document can only be ‘Cancelled’ from a leg if it is awaiting match processing and in the ‘Pending’ state in the leg or if it
has not fully entered the dialogue in the leg.
The successfully
submitted Cancellation document is assigned to the ‘Finished’ state and the ‘Cancelled’
Trade Confirmation document is removed from further business processing and set
to the ‘Cancelled’ state in the process and in the case of the Trilateral
Matching dialogue, leg(s) of the trilateral match from which it has been
cancelled.
If the Trade Confirmation document has
established a ‘Preliminary Match’ with a Broker Confirmation document,
optionally including a Broker Fee Information document, in the Broker leg of
the Trilateral Matching dialogue then the cancellation of the matched Trade
Confirmation document will cause the respective Broker Confirmation (and
optionally the Broker Fee Information) document(s) for be set to the ‘Pending’
state. Any initial preliminary match between the original Trade Confirmation
document and the Broker Confirmation is rolled back since the trade details in
the Trader’s ETRMS for the trade have changed and the match with Broker no
longer exists. A Broker Match Notification document is issued to the Broker by
the Trader to convey the change of state back to ‘Pending’, although this is
not required for the case where Trader and Broker are tenants of the same shared
process instance.
A Broker Fee Information document associated
with a ‘Cancelled’ Trade Confirmation document will also be cancelled.
A ‘Box Result’ document is returned from the instance of the process to each of the parties providing a status update to the ETRMS and Broker back end system as appropriate.
High Level Broker Confirmation
Cancellation Processing
A Broker Confirmation document in the Broker
Confirmation Matching dialogue can only be ‘Cancelled’ if it is awaiting match
processing and in the ‘Pending’ state or if it has not fully entered the
dialogue.
The successfully submitted document is assigned to the ‘Finished’ state and the ‘Cancelled’ Broker Confirmation document is removed from further business processing and set to the ‘Cancelled’ state.
If the Broker Confirmation document has established
a ‘Preliminary Match’ with a Trade Confirmation document, optionally including
a Broker Fee Information document, in the Broker leg of the Trilateral Matching
dialogue then the cancellation of the matched Broker Confirmation document will
cause the respective Trade Confirmation (and optionally the Broker Fee
Information) document(s) for be set to the ‘Pending’ state. Any initial preliminary
match between the original Broker Confirmation document and the Trade
Confirmation and Broker Fee Information is rolled back since the trade details
in the Broker’s back end system for the trade have changed and the matching
with Trader no longer exists. A Broker Match Notification document is issued to
the Broker by the Trader to convey the change of state back to ‘Pending’,
although this is not required for the case where Trader and Broker are tenants
of the same shared process instance.
A ‘Box Result’ document is returned from the instance of the process to each of the parties providing a status update to the ETRMS and Broker back end system as appropriate.
High Level Broker Fee Information
Cancellation Processing
A Broker Fee Information document cannot be
cancelled independently but only as a result of cancellation of the associated
Trade Confirmation document.
High Level Deal Tear-Up Request
Cancellation Processing
A Deal Tear-Up Request document in the ‘Finished’
state can only be ‘Cancelled’ if the relevant Trade Confirmation or Broker
Confirmation document is in the ‘Tear-Up Requested’ state.
The successfully submitted Cancellation document is assigned to the ‘Finished’ state and the relevant business document is moved from the ‘Tear-Up Requested’ state back to the ‘Matched’ state.
High Level Matched Document Tear-Up Processing
The eCM v4.0 process introduces the ability for parties to ‘tear up’ matches between business documents. If an underlying deal is made void, or a fundamental change is required that cannot be achieved through amending the matched documents, such as changing a counterparty, then the change to the separate Trader and/or Broker backend systems can be reconciled using Tear-Up processing supported by the eCM process. Traders may configure this dialogue on or off. If the dialogue if configured ‘off’ then the Tear-Up Request will be rejected from the process, otherwise it will be processed.
High
Level Counterparty Match Tear-Up Dialogue
Either Trader can initiate this dialogue by
submitting a Tear-Up Request document referencing their matched Trade
Confirmation document. There will be no limit placed on this functionality
within the process but business users must consider the relevance of the
dialogue for a document that refers to an underlying trade that has passed its
maturity date or other major lifecycle event.
The successfully submitted document is assigned to the ‘Finished’ state.
If the counterparty’s Trade Confirmation document is in the ‘Matched’ state then the Trader’s own Trade Confirmation document is moved to the ‘Tear-Up Requested’ state whilst the matched counterparty’s Trade Confirmation document remains in the ‘Matched’ state.
If the counterparty’s Trade Confirmation document is in the ‘Tear-Up Requested’ state then the Trader’s own Trade Confirmation document and the Counterparty’s Trade Confirmation document are both moved to the ‘Cancelled’ state.
If the Counterparty Confirmation moved to the ‘Cancelled’ state was one leg of a Trilateral Match then the Broker Confirmation document is also moved to the ‘Cancelled’ state since the Broker Confirmation Match leg of the Trilateral Match is no longer valid if the Counterparty Confirmation Match leg has been ‘torn-up’. A Broker Match Notification document is issued to the Broker by the Trader to convey the change of state to ‘Cancelled’, although this is not required for the case where Trader and Broker are tenants of the same shared process instance.
In summary the matched Trade Confirmation documents are only moved to the ‘Cancelled’ state once an audited request has been received from both parties to the original match.
A ‘Box Result’ document is returned from the instance of the process to each of the parties providing a status update to the Traders’ ETRMS and Broker’s backend system.
High Level Broker Match Tear-Up
Dialogue
Only the Trader can initiate this dialogue
by submitting a Tear-Up Request document referencing their matched Trade
Confirmation in the Broker dialogue. There will be no limit placed on this
functionality within the process but business users must consider the relevance
of the dialogue for a document that refers to an underlying trade that has
passed its maturity date or other major lifecycle event.
The successfully submitted document is assigned to the ‘Finished’ state.
If
the Trader successfully submits the Tear-Up
Request then the Trade Confirmation document and
associated Broker Fee Information document, if one exists, and the Broker
Confirmation document are set to the ‘Cancelled’ state. The consent of the
Broker is not required since the authority to break the Broker match resides
with the Trader. A Broker Match Notification
document is issued to the Broker by the Trader to convey the change of state to
‘Cancelled’, although this is not required for the case where Trader and Broker
are tenants of the same shared process instance.
If the Broker Confirmation Match was one leg of a Trilateral Match then the Counterparty Confirmation Match leg remains unaffected by this dialogue unless the Trader submits a Tear-Up Reqest for both legs of the Trilateral Match rather than just the Broker leg, in which case the High Level Counterparty Match Tear-Up Dialogue applies.
In summary the Broker cannot submit a Tear-Up Request since they can neither initiate a Tear-Up dialogue, nor can they participate in a Tear-Up dialogue initiated by the Trader. If a Broker wishes to initiate a tear-up then they must contact the Trader outside the eCM process and ask the Trader to conduct the tear-up.
A ‘Box Result’ document is returned from the instance of the process to each of the parties providing a status update to the Trader’s ETRMS and Broker’s back end system.
High Level Broker Fee Information
Tear-Up Processing
A Broker Fee Information document cannot be
referenced by a Deal Tear-Up Request document and will only be set to the ‘Tear-Up
Requested’ or ‘Cancelled’ state if the associated Trade Confirmation document
is set to one of these states.
High Level Business Document Submission and Result Process
Submission and Results processing is concerned with defining how the various business documents must be submitted to the eCM process by the backend systems of the Trader and Broker and how status information about the progress and results of processing the various documents must be returned. This information can be used by backend systems to update their own status information for each business document submitted to the eCM process. In earlier versions of the eCM Standard this process was left undefined since the interaction was internal to each organisation and not considered to be within the scope of standardisation; however, with the ‘multi-tenancy’ deployment option the Submission and Result dialogues become ‘externalised’, allowing Traders and Brokers to submit their documents to a shared process instance, external to their organisations, bringing the interaction within the scope of the eCM Standard.
High Level Document Submission Dialogue
The Trader or Broker submits a business
document to the process and receives a ‘Box Result’ message in return. On
successful submission the Box Result for the relevant document will return the
initial status of the document within the process e.g. ‘Pending’. In case of an
invalid submission the Box Result for the relevant document will contain the
status ‘Failed’.
High Level Document Result Dialogue
The eCM process issues a Box Result message to the Trader or Broker (as appropriate) each time a successfully submitted document is moved to a new non-transient state within the eCM process e.g. ‘Matched’.
High Level Time Out Dialogue
Time Out processing has been removed in V4.0 of the process in favour of implementation specific reports highlighting ‘aged’ documents that have not be progressed to a resolved state.
Note that implementers must address this non-backwardly compatible change within their implementations of the process.
Role of the ‘Multi-Tenant’ Process Implementation in Peer-to-Peer Matching
A ‘mult-tenant’ implementation of the eCM process will be operated in common on behalf of several Traders and/or Brokers by a third party service provider. In this deployment configuration the service provider undertakes the ‘Trader’ or ‘Broker’ role in the case of peer-to-peer matching on behalf of the trading organisations and brokers that are using the service. In this case the service provider acts on behalf of the Trader or Broker and in particular:
· Electronically signs the documents exchanged according to the peer-to-peer dialogue, as described in [1], on behalf of the Trader or Broker
· Receives and processes the documents issued by the other party according to the peer-to-peer matching dialogue.
Peer-to-peer users must be aware that their Trade Confirmation data will be sent to the service provider to permit the service provider to complete a peer-to-peer match on behalf of the Traders and Brokers on whose behalf it is acting as a matching agent.
4.3 Detailed Business Document Flows
Detailed Business Document Match Processing
Table 1 Possible matching scenarios supported by eCM v4.0 identifies all supported configurations of the eCM v4.0 matching dialogues described in 4.2 High Level Business Document Flows, High Level Business Document Match Processing for each actor in each role: that is the Trader and Broker as either a ‘Multi-Tenant’ or ‘Peer-to-Peer’ user of the process.
|
|
Scenario |
Multi-Tenant Trader 1 |
Multi-Tenant Trader 2 |
P2P Trader 1 |
P2P Trader 2 |
Multi-Tenant Broker |
P2P Broker |
|
Trader vs. Trader |
1 |
x |
x |
|
|
|
|
|
|
2 |
x |
|
x |
|
|
|
|
Trader vs. Broker |
3 |
x |
|
|
|
x |
|
|
|
4 |
x |
|
|
|
|
x |
|
|
5 |
|
|
x |
|
x |
|
|
Trader vs. |
6 |
x |
x |
|
|
x |
|
|
Broker vs. |
7 |
x |
x |
|
|
|
x |
|
Trader |
8 |
x |
|
x |
|
x |
|
|
|
9 |
x |
|
x |
|
|
x |
|
|
10 |
|
|
x |
x |
x |
|
Table 1 Possible matching scenarios supported by eCM v4.0
Note that for simplicity the Submission and
Result processing is not shown in each of the following sections but is
described in its own section Detailed Submission and
Results Processing.
Detailed Business Document Match
Processing: Scenario 1
Figure 3 Counterparty Confirmation Matching dialogue
with tenant Traders shows the detailed document flows for the Counterparty Confirmation
Matching dialogue for the scenario in which both Traders share a multi-tenant
implementation of the eCM process operated by a third party service provider.
Figure 3 Counterparty Confirmation Matching dialogue with tenant Traders
Detailed Business Document Match
Processing: Scenario 2
Figure 4 Counterparty Confirmation Matching dialogue
with tenant 'buyer' and peer-to-peer 'seller' and Figure 5 Counterparty Confirmation Matching dialogue
with tenant 'seller' and peer-to-peer 'buyer' show the detailed document flows for the Counterparty Confirmation
Matching dialogue for both cases of the scenario in which a tenant Trader is
matching through a service provider with a peer-to-peer Trader in both ‘buyer’
and ‘seller’ roles.
Figure 4 Counterparty Confirmation Matching dialogue with tenant 'buyer' and peer-to-peer 'seller'
Figure 5 Counterparty Confirmation Matching dialogue with tenant 'seller' and peer-to-peer 'buyer'
Detailed Business Document Match
Processing: Scenario 3
Figure 6 Broker Confirmation Matching dialogue with tenant Trader and Broker (incl. Broker Fee
Information) shows the detailed document flows for the Broker Confirmation Matching
dialogue for the scenario in which a tenant Trader and Broker share a
multi-tenant implementation of the eCM process operated by a third party
service provider.
Figure 6 Broker Confirmation Matching dialogue with tenant Trader and Broker (incl. Broker Fee Information)
Detailed Business Document Match
Processing: Scenario 4
Figure 7 Broker Confirmation matching dialogue with
tenant Trader and peer-to-peer Broker (incl. Broker Fee Information) shows the detailed document flows for the Broker Confirmation Matching
dialogue for the scenario in which a tenant Trader is matching through a
service provider with a peer-to-peer Broker.
Figure 7 Broker Confirmation matching dialogue with tenant Trader and peer-to-peer Broker (incl. Broker Fee Information)
Detailed Business Document Match
Processing: Scenario 5
Figure 8 Broker Confirmation Matching dialogue with
tenant Broker and peer-to-peer Trader (incl. Broker Fee Information) shows the detailed document flows for the Broker Confirmation Matching
dialogue for the scenario in which a tenant Broker is matching through a
service provider with a peer-to-peer Trader.
Figure 8 Broker Confirmation Matching dialogue with tenant Broker and peer-to-peer Trader (incl. Broker Fee Information)
Detailed Business Document Match
Processing: Scenario 6
Figure 9 Trilateral Matching dialogue with tenant
counterparties and Broker (incl. BFI) shows the detailed document flows for the Trilateral Matching dialogue
for the scenario in which two tenant Traders and a Broker are matching through
a service provider.
Figure 9 Trilateral Matching dialogue with tenant counterparties and Broker (incl. BFI)
Detailed Business Document Match
Processing: Scenario 7
Figure 10 Trilateral Matching dialogue with tenant
Traders and peer-to-peer Broker (incl. BFI) shows the detailed document flows for the Trilateral Matching dialogue
for the scenario in which two tenant Traders are matching through a service
provider with a peer-to-peer Broker.
Figure 10 Trilateral Matching dialogue with tenant Traders and peer-to-peer Broker (incl. BFI)
Detailed Business Document Match
Processing: Scenario 8
Figure 11 Trilateral Matching dialogue with tenant
Trader, tenant Broker and peer-to-peer Trader (incl.BFI) shows the detailed document flows for the Trilateral Matching dialogue
for the scenario in which a tenant Trader and Broker are matching through a
service provider with a peer-to-peer Trader.
Figure 11 Trilateral Matching dialogue with tenant Trader, tenant Broker and peer-to-peer Trader (incl.BFI)
Detailed Business Document Match Processing:
Scenario 9
Figure 12 Trilateral Matching dialogue with
peer-to-peer trader and Broker and a tenant Trader (incl. BFI) shows the detailed document flows for the Trilateral Matching dialogue
for the scenario in which a tenant Trader is matching through a service
provider with a peer-to-peer Broker and Counterparty.
Figure 12 Trilateral Matching dialogue with peer-to-peer trader and Broker and a tenant Trader (incl. BFI)
Detailed Business Document Match
Processing: Scenario 10
Figure 13 Trilateral Matching dialogue with tenant
Broker and peer-to-peer Traders (incl. BFI) shows the detailed document flows for the Trilateral Matching dialogue
for the scenario in which a tenant Broker is matching through a service
provider with two peer-to-peer Traders.
Figure 13 Trilateral Matching dialogue with tenant Broker and peer-to-peer Traders (incl. BFI)
Detailed Business Document Amendment Processing
The following sections show all the document flows involved in amending business documents. Not all permutations of role and deployment option have been shown however the combinations required to demonstrate all document flows for each deployment option have been included.
Trade Confirmation Amendment -
Counterparty Dialogue
Figure 14 Document flows for amendment of a Trade
Confirmation in the Counterparty Matching dialogue shows the submission of an amendment to a Trade Confirmation document
and includes the flows for both deployment options: via the service provider
and between the service provider and a Trader acting as peer-to-peer
counterparties.
Figure 14 Document flows for amendment of a Trade Confirmation in the Counterparty Matching dialogue
Trade Confirmation Amendment -
Broker Dialogue
Figure 15 Document flows for amendment of a Trade
Confirmation in the Broker Matching dialogue shows the flows for submission of an amendment to the Trade
Confirmation and the Broker Fee Information document for a multi-tenant Trader.
Since matching is local to the Trader in both deployment options no documents
are issued to the Broker.
Figure 15 Document flows for amendment of a Trade Confirmation in the Broker Matching dialogue
Trade Confirmation Amendment -
Trilateral Dialogue
Figure 16 Document flows for amendment of a Trade
Confirmation document in a Trilateral Matching dialogue shows the flows when the Trade Confirmation is part of a trilateral
matching dialogue with the counterparty Trade Confirmation and the Broker
Confirmation, including the Broker Fee Information. The peer-to-peer and
multi-tenant deployments for the Broker are included as alternative flows to
ensure that examples of all the flows for each deployment option are shown,
including the case where a ‘Prelininary Match’ with a Broker Confirmation is
reversed as a result of amendment to ensure the integrity of the trilateral
match.
Figure 16 Document flows for amendment of a Trade Confirmation document in a Trilateral Matching dialogue
Broker Confirmation Amendment -
Trilateral Dialogue
Figure 17 Document flows for amendment of the Broker
Confirmation in the Trilateral Matching dialogue shows the flows for amendment dialogue with both Traders, one a
peer-to-peer deployment and one a multi-tenant deployment. The reversal of the
‘Preliminary Match’ between the Broker Confirmation and the Trade Confirmation
and Broker Fee Information documents is explicitly shown for the multi-tenant
Trader.
Figure 17 Document flows for amendment of the Broker Confirmation in the Trilateral Matching dialogue
Detailed Business Document Cancellation Processing
The following sections show all the document flows involved in cancellation of business documents. Not all permutations of role and deployment option have been shown however the combinations required to demonstrate all document flows for each deployment option have been included.
Trade Confirmation Cancellation -
Counterparty Dialogue
Figure 18 Document flows for the cancellation of a Trade Confirmation document in the Counterparty Matching dialogue shows the cancellation of a multi-tenant Trader’s Trade Confirmation document and the peer-to-peer flows between the service provider and the peer-to-peer Trader.
Figure 18 Document flows for the cancellation of a Trade Confirmation document in the Counterparty Matching dialogue
Trade Confirmation Cancellation -
Broker Dialogue
Figure 19 Document flows for the cancellation of a
Trade Confirmation document in the Broker Matching dialogue shows the flows between the multi-tenant Trader and the service
provider, since the broker match is local to the Trader’s shared process
instance no communication is necessary with a peer-to-peer deployment of the
Broker. The affect on the Broker Fee Information document of cancelling a Trade
Confirmation is shown through the status updates coming back from teh process
to the multi-tenant Trader.
Figure 19 Document flows for the cancellation of a Trade Confirmation document in the Broker Matching dialogue
Trade Confirmation Cancellation –
Trilateral Dialogue
Figure 20 Document flows for the cancellation of a
Trade Confirmation dcoument in the Trilateral Matching dialogue shows the flows when the Trade Confirmation is part of a trilateral
matching dialogue with the counterparty Trade Confirmation and the Broker
Confirmation, including the Broker Fee Information. The peer-to-peer and
multi-tenant deployments for the Broker are included as alternative flows to
ensure that examples of all the flows for each deployment option are shown,
including the case where a ‘Prelininary Match’ with a Broker Confirmation is
reversed as a result of cacnellation to ensure the integrity of the trilateral
match.
Figure 20 Document flows for the cancellation of a Trade Confirmation dcoument in the Trilateral Matching dialogue
Broker Confirmation Cancellation -
Trilateral Dialogue
Figure 21 Document flows for the cancellation of a
Broker Confirmation in the Trilateral Matching dialogue shows the flows for cancellation dialogue with both Traders, one a
peer-to-peer deployment and one a multi-tenant deployment. The reversal of the
‘Preliminary Match’ between the Broker Confirmation and the Trade Confirmation
and Broker Fee Information documents is explicitly shown for the multi-tenant
Trader.
Figure 21 Document flows for the cancellation of a Broker Confirmation in the Trilateral Matching dialogue
Detailed Matched Document ‘Tear-Up’ Processing
The following sections show all the document flows involved in tearing-up an existing match between documents. Not all permutations of role and deployment option have been shown however the combinations required to demonstrate all document flows for each deployment option have been included.
Tear-Up of a Counterparty Match
Figure 22 Document flows for the tear-up of a pair of
matched Trade Confirmation documents shows the flows for two counterparties agreeing to tear-up a match
between two Trade Confirmation documents with one Trader using a service
provider and the other using the peer-to-peer deployment.
Figure 22 Document flows for the tear-up of a pair of matched Trade Confirmation documents
Tear-Up of a Broker Match
The tear-up of a match between a Trade
Confirmation and a Broker Confirmation document can only be initiated by the
Trader. Figure 23
Docuemnt flows for the tear-up of a match between a Trade Confirmation and a
Broker Confirmation initiated by the Trader shows the flows for the dialogue when it is initiated by the Trader,
note that the agreement of thee Broker is not required and the BCN is set
directly to the Cancelled state. The dialogue alternative is included to show
the document flow in the two deployment options for the Broker.
Figure 23 Docuemnt flows for the tear-up of a match between a Trade Confirmation and a Broker Confirmation initiated by the Trader
Tear-Up of a Trilateral Match
Figure 24 Document flows for reconciling the tearing-up of a previously matched deal shows the flows for the tear-up of a trilateral match between the Trade Confirmations for the two Traders and the resulting cancellation of the two matches (one for each Trader) with the Broker Confirmations for each side of the deal. The alternative flow is included to show what happens in both deployment options for the Broker.
Figure 24 Document flows for reconciling the tearing-up of a previously matched deal
Detailed Submission and Results Processing
Figure 25 Document flows for the submission and
receipt of results between the actors and the process shows the interface between the backend systems for the actors in the
eCM process: Trader and Broker, and the process itself encapsulated as a ‘Service’
that can be deployed outside the organisation.
Note that the communication between the ‘Service
User’ and the ‘Service’ must comply with the EFET electronic Communication
Standard [1] and Profile [2].
Figure
25 Document flows for the submission and receipt of results between
the actors and the process
Legal and Confidentiality Issues
For the legal validity of the electronic documents, EFET refers to the Master Agreement in place between participants for the legal issues. The Master Agreement will typically describe the legal specifications of electronic transactions.
Similarly the Master Agreement should contain a confidentiality clause applying to the trade confirmation data sent over to counter parties.
4.4 Business Document Processing
‘Suggested Match’ Processing
The Buyer is responsible for identifying Suggested Matches by correlating documents from within the set of Buyer and Seller side Trade Confirmation documents. The process is continuous whilst Trade Confirmation documents with the status of ‘Pending’ exist within the document set.
If an earlier version of a ‘Pending’ document is in the ‘Matched’ state then the set of Buyer and Seller side documents is further constrained to comprise only new versions of the current matching pair of counterparty documents.
Note that the mandatory, key fields used in the matching algorithm are defined by this standard as sufficient to adequately distinguish an underlying trade for the purposes of confirmation matching.
The following specific rules define when two documents may be considered identical for business purposes:
1. Two Trade Confirmation document field values (XML attributes or elements) are called identical if they consist of the same sequence of characters. Leading and trailing blanks are not accepted within document fields. Should the values be based on a numeric data type, the respective formatting rules apply. I.e., 1.0 matches with 1 or 100 matches 10E2. Equality of values is given if two numeric values are considered equal according to the XML Schema standard (http://www.w3.org/TR/xmlschema-2/).
2.
Two Trade Confirmation document
sections are called identical if the
respective values of all key fields are identical. A section is defined as a
sequence of XML elements. Such a sequence may either be the header part of a
document or a repeatable section.
Optional document fields (e.g. "TradeTime") and
substructures (e.g. "OptionDetails") count as part of the
section.
3. Independent of the cardinality of an XML section, a repeatable section may be ordered or unordered. If a repeatable section is ordered, the order of the sections is defined by their sequential appearance.
4. Two lists of an ordered repeatable Trade Confirmation document section are called identical if both lists contain the same number of sections and if the n-th section of the one list is identical to the n-th section of the other list where n is between 1 and the length of the sequences.
5. Two lists of an unordered repeatable Trade Confirmation document section are called identical if there exists a one-to-one mapping between the sections of the one list and the sections of the other list such that each pair of sections is identical and all sections can be mapped.
6. Two different Trade Confirmation documents are considered identical if there exists
· a one-to-one mapping between all corresponding lists of ordered repeatable sections of the two documents such that each pair of sequences is identical,
· a one-to-one mapping between all corresponding lists of unordered repeatable sections of the two documents such that each pair of sequences is identical,
· a one-to-one mapping between the two sets of remaining sections of the two documents such that each pair of sections is identical.
‘Suggested Match Acceptance/Refusal’ Processing
The Seller is responsible for validating Suggested Matches received from the Buyer with the aim of confirming a ‘Match’, as defined by the eCM Standards, between two documents with the set of Buyer and Seller side Trade Confirmation documents.
The Seller shall use information in the Match Suggestion document, received from the Buyer, uniquely identifying two documents. The Seller shall issue a MatchSuggestionAcceptance if the two documents are found to conform to the eCM Standard rules for identification of identical documents, otherwise a MatchSuggestionRefusal shall be issued by the Seller.
If the Seller issued a MatchSuggestionRefusal document, a related ReasonCode must be provided to the Buyer. Any further agreement will have to be done directly between the respective back office staff members.
Note that the matching dialogue between ‘tenants’ of the same shared process instance can be optimised to dispense with ‘Suggested Match Acceptance/Refusal’ Processing since the Seller and Buyer use the same and not independent instances of the process and document set, thereby limiting the the value of the ‘independent’ verification by the Seller of the ‘suggested match’ proposed by the Buyer. Conversely, the processing must be applied in the case of a distributed match as it is fundamental to the peer-to-peer processes that the Seller validate the proposal made by the Buyer.
‘Trade Data’ and Broker ‘Match’ Processing
Within the context of the Broker Confirmation dialogue two phases of match processing occur:
1. Trade Data Match processing, which compares trades data information held within the Trade and Broker Confirmation documents takes place first;
And optionally depending on the Trader’s preference setting,
2. Broker Match Processing, which compares the Broker Fee Information document from the Trader with the brokerage fee fields within the Broker Confirmation document and which follows on from the successful pairing of a Trade Confirmation document with a Broker Confirmation document through the Trade Data Match processing
Trade Data Match processing is concerned with correlating Trade/Broker Confirmation documents based on mandatory, key fields that are defined by this standard as sufficient to adequately distinguish an underlying trade for the purposes of confirmation matching, from within the set of Trader and Broker side Confirmation documents.
The Trade Data Match process is similar to the ‘Suggested Match’ process but uses a subset of the mandatory, key fields as the broker does not hold all the information that a counterparty to the trade has and match processing is continuous whilst Trade/Broker Confirmation documents with the status of ‘Pending’ exist within the Trader/Broker document set.
If an earlier version of a ‘Pending’ document is in the ‘Matched’ state then the Trader/Broker document set is further constrained to comprise only new versions of the current matching pair of documents.
Broker Match processing is similar to ‘Suggested Match Acceptance/Refusal’ processing insofar as it is contingent on Trade Data Match processing and uses the unique DocumentID of the Trader Confirmation document output from that process to optionally retrieve the Broker Fee Information document which is then compared with the brokerage fee related data contained within the Broker Confirmation document.
Recommendations for ‘Potential Match’ Processing
Implementers are strongly advised to provide support to the user in the task of finding matching documents when a discrepancy has occurred. This standard therefore forsees the that ‘potential match(es)’ should be proposed when a ‘Match’ according to the algorithms defined in ‘Suggested Match Acceptance/Refusal’ Processing and ‘Trade Data’ and Broker ‘Match’ Processing cannot be established by the process.
The for a ‘potential match’ to exist between two documents the following key fields must match exactly (as described above) but other key fields need not match precisely.
· Buyer,
· Seller,
· Market,
· Commodity,
· TransactionType,
· DeliveryPoint,
· TradeDate,
· BrokerID,
· TotalVolumeUnit,
· Currency
Avoiding Race Conditions between two EFET Boxes
The states “Pending”, “Potential Match”, “MatchSuggested”, and “Matched” reflect the processing sequence alongside the execution of the eCM protocol as defined in Section 4.3. This approach also avoids race conditions introduced by intermediate amendments that would lead to intermediate version changes and could spoil a match.
Moreover, whenever an Amendment is sent the new document must fully enter the process which in the case of the peer-to-peer processes includes entering the local and counterparty instance of the process before any later document is transferred that occurs later in the process. If the sending of an Amendment crosses the sending of a MatchSuggestion, the Seller will not respond to the MatchSuggestion unless a response for the Amendment is received. The Buyer, however, will reject this Amendment since the MatchSuggestion was sent before. Therefore, the Match will be processed based on the second-last version of the Seller’s document.
5 Electronic Business Processes – by Document Types
This section has
to be read in conjunction with the appendix Definition of eCM Types and Codes.
Said appendix provides the reference to the
list of all the types and codes that are valid within the eCM. Wherever this
document is referenced the codes associated with the attribute referenced must
be obtained from this source. In particular the code lists contained in the
appendix may evolve independently from this section.
5.1 Naming and Typing Conventions
Document rules check the validity of data within a given document against the document type definition.
Agreed abbreviations for document types:
- “CNF” for Trade Confirmation
- “REJ” for Rejection
- “MSU” for Match Suggestion
- “MSA” for Match Suggestion Acceptance
- “MSR” for Match Suggestion Refusal
- “CAN” for Cancellation
- “ACK” for Acknowledgement
- “BFI” for Broker Fee Information
- “BMN” for Broker Match Notification
- “BCN” for Broker Confirmation
- “TUR” for Tear-Up Request
- “BRS” for the Box Result
1.
Partner Identification
The IDs used in Trade Confirmation, Match Suggestion, Match Suggestion Acceptance, Match Suggestion Refusal, Cancellation, Rejection and Acknowledgement documents will be globally unique IDs (EIC Codes).
2.
Document IDs
Often, documents are listed in reporting tools, as XSL stylesheets, etc. To provide a common syntax that is comprehensible and maintains uniqueness, a rule for creating unique Document IDs is defined as follows:
A composition of the following components:
- Document type abbreviation (e.g. “CNF” for Trade Confirmation)
- DateCode (8 characters, in yyyymmdd format),
- Locally & daily unique TradeID (min. 10 characters) of the sender side
- “@”
- Sender identification, i.e. domain name or EIC Code of the sender.
Examples:
CNF_20040610_1234567890@electrabel.com
MSA_20040610_1234567890@11XELECTRABEL--Z
This document ID shall correspond with the MessageID of the ebXML Message Service and should be comprehensible for human users.
N.B. This is a convention but it is mandated for compliancy with the eCM Standard and must be used for document types as it is believed that it makes document tracking easier.
3.
Document Types
There is no DocumentType field any more since document types can be derived from the XML Schema reference in a document instance. Moreover, the root element can be used to derive the document type.
5.2 Trade Confirmation
Overview
Each field in a Trade Confirmation document is either a key or an informational field.
· Key fields are those fields that play a role in the definition of a match between two trade confirmation documents.
· Information fields are for information only and not used in matching.
All key fields used in matching are either mandatory or conditional, informational fields are optional
· Mandatory fields must always be included in a compliant document
· Conditional fields are mandatory only under certain circumstances which depend on the values of other data elements within an XML schema. Rules either within the following table or in a separate business rules section after the table are used to express the conditions.
Trade Confirmation – Document Root
Table 2: Specification of Trade Confirmation Elements
|
Name |
Mandatory/ Optional/
Conditional |
Type |
Key/ Information |
Business Rule |
|
Section: Document Header |
||||
|
DocumentID |
Mandatory |
The sender generates this
ID that must be a unique reference
compliant with naming standard defined in 5.1 Naming and
Typing Conventions. When a party receives a trade confirmation with an ID unknown to the
receiver then the receiver must treat this document as the initial version of
a new trade confirmation document. Otherwise the receiver must treat this
document as an amendment of an already sent Trade Confirmation document (see
field “Document Version”). |
||
|
Document Usage |
Mandatory |
UsageType |
Information |
“Test” or “Live” |
|
SenderID |
Mandatory |
PartyType |
Information |
EIC Code of Sender |
|
ReceiverID |
Mandatory |
PartyType |
Information |
EIC Code of Receiver, brokerID in case only Broker is involved. |
|
Receiver
Role |
Mandatory |
RoleType |
Information |
Trader role applies if the
document is being sent to the other party involved in the trade Agent role applies if the document is in effect a carbon copy of the
main confirmation document. |
|
Document Version |
Mandatory |
|||