Single Event vs. Multiple Events Swap Trade Processing Notes

The Single Event trade processing method 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. 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) or return leg (TRS) only, and the engine spawns the transactions for the other legs.

While the Multiple Events method continues to be supported, the Single Event method 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
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.	Minor remapping may be required for automation. In most cases a Single Event message is a subset of a Multiple Events 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.
Multiple Events	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.