I deal with a number of FX execution platforms (mostly using ExecutionReport and TradeCaptureReport), all of whom represent FX and FXNDF trade capture in different ways. Much of the confusion arises from the use of “Currency(15)”,“SettlCurrency(120)” and “Symbol(55)” to represent the FX pair being traded.
The problems I encounter with the above are:
The Symbol(55) field is free text, so the Currency Pair is represented in whatever format the sender likes, e.g. ‘USDTWD’, ‘USD/TWD’, ‘USD-TWD’
The Currency(15) and SettlCurrency(120) are used to represent not only the Notional and Settlement currencies, but also the FX pair being traded in many cases.
a. This means that an NDF trade which settles in the Notional Currency (e.g. USD/TWD settled in TWD) cannot be clearly represented with these 2 fields
The FX Rate is often set in the LastPx(31) field. This is generally accepted to follow market conventions, but that is always open to interpretation.
I would propose the creation of an ‘FXDetail’ component to encapsulate all of the FX specific information as well as the FX Fixing information in your proposal. I would suggest adding these fields:
As well as providing clarity on the overall TradeCapture/Execution Report, this component could also be used anywhere that an FX Price is required, to make it abundantly clear what the FX price is (base vs quote or quote vs rate).
Any thoughts/criticisms on this?
Perhaps there is a clear example already available for representing FX and FXNDF on FIX, would very much appreciate if I was pointed that way too.
Please have a look at Extension Pack EP273. The primary context is digital asset trading but it extends FIX to be able to be more explicit about FX currency pairs. It does not answer all of your questions but it may be a start.
@beirtipol
The Symbol field should take the form of CCY1/CCY2 (EBS style)
Currency(15) is the dealt currency of the values/amount expressed in quantity fields
For NDF when you settle in a 3rd currency, the SettlCurrency(120) is used to express that 3rd settlement currency.
LastPx for FX has always been the rate for the ccy pair. If it is a forward contract it’s spot+fwd points included, if spot contract then just spot rate.
If you go here and download Vol. 7 and review the FX section you’ll see the guidelines around these fields, and additional fields like CalculatedCcyLastQty(1056)
Another component of interest is the RateSource component which allows to identify the sources for fixing rate.
There are some gaps in FX NDFs which have become much more electronically traded since Vol 7 was written. If the responses so far haven’t answered your questions then you can join the FX working group where a few initiatives are underway for NDFs and reject codes.
My issue with the Symbol field is that it is rarely used as it ‘should’ be. As there’s no built in validation on the format or ordering of currencies, you have to rely on a bilateral agreement with whomever is sending the message. Of the platforms I work with that send FX trade capture, I’ve seen the following formats
'USDTWD’, ‘USD/TWD’, ‘USD-TWD’.
In cases of market data or quote transmission, this is possibly acceptable. However, in trade capture, we’re required to extract multiple pieces of information from a 7 character strong (base ccy, quote ccy, which directionthe price is quoted in etc).
I think a top level “RiskCurrency” or “QuoteCurrency”, whatever the name, would greatly reduce trade capture errors.
Thanks for the link, I’ll have more of a read through that.
Direction the price is quote can be signaled via the PriceType(423) field, values 20 and 21. I need to find a cheat sheet I have on this and will post once I find it.