/
Single-Event vs. Multi-Event Swap Trade Processing Notes

Single-Event vs. Multi-Event Swap Trade Processing Notes

Single-Event trade processing was introduced for Interest Rate Swaps (IRS) and Total Return Swaps (TRS) in V17 R2.27 to allow additional lot selection methods on close trades. It was expanded to Cross Currency Swaps (CCS) in V17 R2.49 and Zero-Coupon Inflation Swaps (ZCIS) in V17 R2.51. Single-Event does not currently support Inflation-Linked Asset Swaps where one leg uses the SWLEIF Processing Security Type.

There are no differences in security setup or the resulting positions between the two methods; both produce separate positions for the contract and each leg. When using the Single-Event method, all data is provided on the contract (IRS, CCS, ZCIS) or return leg (TRS) only, and the engine spawns the transactions for the other legs. Single-Event closes can be processed against Multi-Event opens, and Multi-Event closes can be processed against Single-Event opens, if needed. You can identify if a trade was booked as Single-Event or Multi-Event using tag 17940 on the open lots. If the tag is present with a value of Y, the trade was booked as Single-Event. If the tag is not present, the trade was booked as Multi-Event.

While the Multi-Event method continues to be supported, Single-Event is our best practice. New functionality is being added to the Single-Event method only. The following is a comparison of the two methods.

Method

Pros

Cons

Method

Pros

Cons

Single-Event

  • Full range of lot selection methods available.

  • Support for non-deliverable swap (NDS) trades.

  • The contract and legs are always processed together (the whole trade succeeds or the whole trade fails).

  • Batch ID can be generated by Eagle for all trade methods.

  • All new multi-leg derivatives enhancements will utilize Single-Event.

  • Minor remapping may be required for automation. In most cases a Single-Event message is a subset of a Multi-Event message, but new tags were added to support certain use cases (sending traded interest instead of allowing Eagle to calculate it, for example).

  • Limited history of usage in production.

Multi-Event

  • Long history of usage in production.

  • Limited lot selection methods available (FIFO, LIFO, IDLOT).

  • Limited support for NDS trades.

  • Can result in “broken legs” (the contract and pay leg succeed, but the receive leg fails, for example).

  • Batch ID must be provided on the inbound message for CSV trades.

  • New enhancements will not be added.