Fix Message Validator for OSI

, ,
1

Imported from previous forum

2

Do we have any Fix Message Validator for OSI (Option Symbology Initiative) changes. So that we can place the message validator tool in between the Investment Bank and External entities (Exchanges,OCC,etc) to verify the fix message before it goes to the external bodies.

3

I don’t believe you’ll find a general purpose validator for OSI. Each of the external entities (exchanges, ECNs, the OCC) may require a different message model depending on the business function being performed and the FIX version being used. For example: OSI under FIX 4.2 requires Maturity Month Year (tag 200) and Maturity Day (tag 205) to indicate the expiration date. But in FIX 4.4 and greater you would just append the expiration day to the end of Maturity Month Year and not use Maturity Day.
The OCC and most exchanges publish specifications describing their interfaces. If you compare these specs you’ll see the differences. A translation of your Investment Bank’s FIX messages may need to take place in order to match those of the target venue. To perform this translation the message from the Investment Bank must contain:

  • Root option symbol
  • Strike price
  • Call/put indicator
  • Complete expiration date (year, month, day)
    Given this information the symbol supported by the venue can be derived. For example take a look at the April $95 IBM calls which expire on April 17, 2009. They would have an OSI symbol of “IBM 090417C00095000” but when trading this option over a FIX connection the message may look like “8=FIX4.2|22=8|55=IBM|167=OPT|200=0904|201=1|202=95|205=17|…”
    As for validation, you may only want to validate that you have the necessary information in your source message.

I hope this was useful.

-Greg

4

Thanks Greg, it was really helpful.

Regards,
Naresh

I don’t believe you’ll find a general purpose validator for OSI.

Each of the external entities (exchanges, ECNs, the OCC) may require a
different message model depending on the business function being
performed and the FIX version being used. For example: OSI under FIX
4.2 requires Maturity Month Year (tag 200) and Maturity Day (tag 205)
to indicate the expiration date. But in FIX 4.4 and greater you would
just append the expiration day to the end of Maturity Month Year and
not use Maturity Day. The OCC and most exchanges publish
specifications describing their interfaces. If you compare these specs
you’ll see the differences. A translation of your Investment
Bank’s FIX messages may need to take place in order to match those
of the target venue. To perform this translation the message from the
Investment Bank must contain:

  • Root option symbol
  • Strike price
  • Call/put indicator
  • Complete expiration date (year, month, day) Given this information the
    symbol supported by the venue can be derived. For example take a look
    at the April $95 IBM calls which expire on April 17, 2009. They would
    have an OSI symbol of “IBM 090417C00095000” but when trading this
    option over a FIX connection the message may look like
    “8=FIX4.2|22=8|55=IBM|167=OPT|200=0904|201=1|202=95|205=17|…” As
    for validation, you may only want to validate that you have the
    necessary information in your source message.

I hope this was useful.

-Greg

5

I don’t believe you’ll find a general purpose validator for OSI. Each of
the external entities (exchanges, ECNs, the OCC) may require a different
message model depending on the business function being performed and the
FIX version being used. For example: OSI under FIX 4.2 requires Maturity
Month Year (tag 200) and Maturity Day (tag 205) to indicate the
expiration date. But in FIX 4.4 and greater you would just append the
expiration day to the end of Maturity Month Year and not use Maturity
Day. The OCC and most exchanges publish specifications describing their
interfaces. If you compare these specs you’ll see the differences. A
translation of your Investment Bank’s FIX messages may need to take
place in order to match those of the target venue. To perform this
translation the message from the Investment Bank must contain:

  • Root option symbol
  • Strike price
  • Call/put indicator
  • Complete expiration date (year, month, day) Given this information the
    symbol supported by the venue can be derived. For example take a look
    at the April $95 IBM calls which expire on April 17, 2009. They would
    have an OSI symbol of “IBM 090417C00095000” but when trading this
    option over a FIX connection the message may look like
    “8=FIX4.2|22=8|55=IBM|167=OPT|200=0904|201=1|202=95|205=17|…” As for
    validation, you may only want to validate that you have the necessary
    information in your source message.

I hope this was useful.

-Greg

Greg do you have a contact number I had some more questions regarding the OSI format via FIX.

6

I don’t believe you’ll find a general purpose validator for OSI. Each of
the external entities (exchanges, ECNs, the OCC) may require a different
message model depending on the business function being performed and the
FIX version being used. For example: OSI under FIX 4.2 requires Maturity
Month Year (tag 200) and Maturity Day (tag 205) to indicate the
expiration date. But in FIX 4.4 and greater you would just append the
expiration day to the end of Maturity Month Year and not use Maturity
Day. The OCC and most exchanges publish specifications describing their
interfaces. If you compare these specs you’ll see the differences. A
translation of your Investment Bank’s FIX messages may need to take
place in order to match those of the target venue. To perform this
translation the message from the Investment Bank must contain:

  • Root option symbol
  • Strike price
  • Call/put indicator
  • Complete expiration date (year, month, day) Given this information the
    symbol supported by the venue can be derived. For example take a look
    at the April $95 IBM calls which expire on April 17, 2009. They would
    have an OSI symbol of “IBM 090417C00095000” but when trading this
    option over a FIX connection the message may look like
    “8=FIX4.2|22=8|55=IBM|167=OPT|200=0904|201=1|202=95|205=17|…” As for
    validation, you may only want to validate that you have the necessary
    information in your source message.

I hope this was useful.

-Greg

Greg - is there a place where we can find the OSI standard spec as we go to FIXiMate for the FIX spec. I am seeing an issue wherein maturity day (tag 200) is being sent by someone as “01” (they claim OSI standard is DD) but per FIX valid values for 200 is b/w 1-31.

7

It’s true that, in FIX 4.2, MaturityDay (tag 204) has valid values of 1-31. But for OSI there’s a FIX document that says you need to add MaturityDay to the existing fields and it claims the valid values for MaturityDay are 01-31. So there is a conflict.

The document can be found here: http://fixprotocol.org/documents/4213/FIXImplementationGuide_USOptionsSymbology_v1.pdf

I would recommend you prepare for both formats.

-Greg