After a match is designed, the user must understand the outcome and what the results represent. In the most basic and traditional sense, a trade is either matched or not matched. Accounts, funds, or valuations are either consistent within the data universe or they are not.
Legacy matches, or matches constructed by hand, might be as simple as a list of trades and a status to indicate whether the trade is matched or not.
Although simple, such matches can be limiting because there is no indication of why the trade is not matched; in most cases, it is assumed that the trade has yet to be booked but there is no way of knowing. For this reason, the current best practice in matching is to present both firm and counterparty activity on the same report:
In the figure above, we see the same results, but adding the counterparty’s data to the match offers a better idea of why no match is reported. If we look closely, we can see that our price is 1950.1, but the counterparty has booked 1950.2.
Of course, an even better solution would be for the match to do the work for us and determine the problem. To eliminate noise, choose to view a report that removes the trades that have matched. There is no reason to view trades that are not problems.
The exact look and feel of the match process, file, or report varies by the solution selected (or built) and its limitations. At the very least, your trade match should include the following standard practices
Want to learn more about what it means to implement a best-in-class trade match process. Download the one and only resource on Trade Matching you’ll ever need. To get started, simply provide us your name and email: