- Category: CTM Workflows
CTM provides two workflows for the submission and matching of trades - the Block Allocation Confirmation Workflow (BACW) and the Allocation Confirmation Workflow (ACWF).
BACW is the most commonly used workflow and is used in the average price markets where the executing broker will average all the street side prices and inform the investment manager in the block of the average price. The BACW requires matching of both the block and the underlying allocations.
ACWF enables clients to take advantage of the benefits of central matching without the requirement to submit or match a block component. This process is used for the submission and matching of only allocation and confirmation information.
Below you can find further information about these two workflow in the form of FAQs.
Allocation Confirmation Workflow FAQs
ACWF is a process for submitting and matching only on allocation and confirmation information. In this workflow, the CTM service does not accept a separate block submission from either party - block-type information must be provided on the allocation or confirmation message. Fro example, in the direct XML interface, a TradeLevel (block) submission is rejected.
ACWF is a viable solution for clients who trade in an execution or tick-by-tick market.
ACWF supports debt and equity asset classes.
Yes. When you review your business requirements, ensure that you subscribe to CTM Allocation Confirmation Workflow (ACWF).
Yes. Your counterparty must be a CTM user and subscribe to the CTM Allocation Confirmation Workflow (ACWF).
If I subscribe to the CTM Allocation Confirmation Workflow, can I also use the block-level workflow with my counterparties?
That depends on which side of the trade you are on:
- Investment managers can only subscribe to a single workflow for a given BIC.
- Broker/dealers can subscribe to CTM Allocation Confirmation Workflow (ACWF) and the block-level workflow subscription option, CTM Block Allocation Confirmation Workflow (BACW). This means that they are able to submit and match trades for both workflows using the same BIC.
The CTM service enforces matching rules on the same fields. However, since an allocation or confirmation constitutes an entire trade side, it applies all minor changes to the three major matching statuses.
The below table describes those statuses for ACWF trades.
|Status||Description||XML Field||Trade Blotter Field|
|Match||If the TradeDetails have a status of MATCH, then the trade sides are automatically MATCH AGREED.||TDMatchStatus||
Investment Managers: Alloc Status
Broker/Dealers: Confirm Status
|Complete||The CTM service persistently sets the trade side value to COMPLETE.||CompleteStatus||Both trade sides: Complete|
|Match Agreed||CTM processes the TradeDetail as an entire trade side so that a MATCH AGREED trade is the end point for a successful trade.||MatchAgreedStatus||Both trade sides: Match Agrd|
Price is a potential L1 pairing field, L1 tie-breaker, or eligible L2 matching field. See the L1 Pairing FAQs for further details.
You and your counterparty include block type information in the TradeLevelInformation composite of each allocation or confirmation (TradeDetail). This composite provides the CTM service with all of the information required to perform L1 pairing and L2 matching.
Matching does not occur on the following fields for ACWF trades:
See the Matching Process FAQs for the complete list of available matching fields.
Because a TradeDetail represents your entire trade side, the CTM service uses the allocation or confirmation fields and block-type fields listed in the table below equally:
|Allocation or Confirmation Fields (TradeDetail)||Block Fields (TradeLevel)|
If you require block type identifiers, use the following guidelines when you submit XML messages:
- New Trades - When you submit a new ACWF trade, such as a TradeDetail where FunctionOfTheMessage = NEWM, follow these trade identifier guidelines:
- The best practice is to sumbit a MasterReference that is identical to the ClientAllocationReference. Similarly, if you submit a ClientAllocationReference, submit an identical MasterReference.
- If you do not submit a MasterReference, then do not submit a ClientAllocationReference. Conversely, if you do not submit a ClientAllocationReference, do not submit a MasterReference
- If you do not want to submit a MasterReference or ClientAllocationReference, omit both fields from the TradeDetail.
- Existing Trades - When you submit a message for an existing trade, such as a TradeDetail where FunctionOfTheMessage = REPC, follow these guidelines:
- Submit a MasterReference or CTMTradeSideId or
- Submit a ClientAllocationReference or CTMTradeDetailID or a combination of the following:
- Submit a MasterReference or CTMTradeSideId and
- Submit a ClientAllocationReference or CTMTradeDetailID
CTM investment managers can match on execution (fill) or average price for TradeDetails. The below diagram shows an example of execution (fill) price matching.
The table below describes the workflow steps in the diagram above, which is an example and not intended to represent all ACWF implementations.
|1||Before the CTM service enters the workflow, an investment manager places an order for 100,000 shares of ABC Security.|
|2||The broker/dealer responds with two Notices of Execution (NOEs). In thie example, the broker/dealer provides the execution (fill) price for each NOE. The broker/dealer can also provide NOEs for average price.|
On the trade side's internal systems:
Broker/dealers can use both an allocation-confirmation workflow and block-level workflow, but investment managers can only use one of the workflows.
The investment manager submits four allocations (TradeDetails) to the CTM service, each representing a single allocation. The TypeOfPrice field is set to EXEC to indicate executing price (not average price).
When combined, the allocations satisfy the broker/dealer's two NOEs.
The broker/dealer learns about the investment manager's allocations by the following actions:
The broker/dealer reviews the AccountID, MatchingSecurityCode, MatchAgreedStatus, and other trade data. The broker/dealer responds to each allocation with a confirmation (TradeDetail) for each allocation that the investment manager submits.
Yes. As long as you do not require separate matching on block type information, the CTM service provides linking of allocations or confirmations. To link each of the allocations or confirmations, set the following fields in the TradeDetailLinkages composite:
- TDReferenceType = COMM
- TDReferenceValue = Same identifier in each linked allocation or confirmation
The below visual shows the TDReferenceType and TDReferenceValue elements for one linked allocation (TradeDetail). You will need to provide the same values on all allocations or confirmations that you would like to be linked.
Yes. Settlement instruction enrichment in ACWF is the same as enrichment for the block-level workflow, except enrichment is on the allocation. The direct XML interface provides enrichment on information you provide in the TradeDetail.
Include settlement instructions in TradeDetail messages so that the financial and settlement information is together in one message. Settlement information includes standing settlement instruction (SSI) enrichment from the ALERT platform. See the pdf Settlement Services Reference: SWIFT MT541/543 and CSV Mapping (4.25 MB) for more information about how to supply settlement instructions on your trades.
DTCC recommends against using broker matching groups for ACWF trades. Using broker matching groups prevents the executing broker from viewing an investment manager's alleged allocation. Instead, the best practice is for investment managers to submit trades using the broker/dealer's CTM BIC.
All of the XML messages, except the following, are available for ACWF trades:
- TradeLevel (block message)
Yes. The below table lists the locations in the pdf XML Message Specification: Debt/Equity and Common Messages (1.93 MB) where you can learn more about exception processing.
|TradeDetail Message and Action||Message Category|
|Cancel, CloseError, ForceMatch, RejectCancel, RejectComponent||Management messages|
|HistoryRequest, HistoryResponse||Query and response messages|