MBS

, ,
1

Imported from previous forum

2

Hi,

I am using the TradeCapureReport for MBS trades and I am wondering if anyone knows how best to map the following values: Agency, Current Face, and Factor Date.

Thanks

3

[ original email was from Edward Hoffman - edward.hoffman@bofasecurities.com ]
> Hi,

I am using the TradeCapureReport for MBS trades and I am wondering if
anyone knows how best to map the following values: Agency, Current Face,
and Factor Date.

Thanks

Andy,

You can lookup current FIX 4.4 plus errata tags at:
www.fixtionary.com

You may want to try searching through custom tags at:

http://www.fixprotocol.org/specifications/fields/5000-9999

Ed

4

In FIX 4.4 Current Face and Factor Date is not supported at this time. Current Face is to be derived from Factor and original face. The agency issuing the MBS would be reported in the Issuer field. Factor and Issuer are both in the Instrument component block. For example, in an IOI message the IOIQty would be the original face value of the MBS and the Factor would be specified (defined as conditionally required when factor <> 1, but good practice to put it in anyway).

However, you indicated that you’re using TradeCaptureReport message - since you’re reporting a trade that is done wouldn’t the traded quantity be all you need in the LastQty field?

Hi,

I am using the TradeCapureReport for MBS trades and I am wondering if
anyone knows how best to map the following values: Agency, Current Face,
and Factor Date.

Thanks

5

[ original email was from Andrew Thompson - anthomps@blackrock.com ]
> In FIX 4.4 Current Face and Factor Date is not supported at this time.

Current Face is to be derived from Factor and original face. The agency
issuing the MBS would be reported in the Issuer field. Factor and Issuer
are both in the Instrument component block. For example, in an IOI
message the IOIQty would be the original face value of the MBS and the
Factor would be specified (defined as conditionally required when factor
<> 1, but good practice to put it in anyway).

However, you indicated that you’re using TradeCaptureReport message -
since you’re reporting a trade that is done wouldn’t the traded quantity
be all you need in the LastQty field?

Hi Lisa,

I think I follow what you’re saying above - so e.g. in a message relating to a trade, one could do this:

LastQty(32) =
Factor(228) =

Then implicitly
orig face = current face / factor ?

I’m surprized to see 465 (QuantityType) was deprecated. Given 465 had ORIGFACE and CURRENTFACE for values wouldn’t it be much clearer if this tag were still included?

I note that the entry for “supported approach” in Appendix 6E is actually missing for tag 465, which seems to be a bug in the spec. Can you shed some light on why this decision was made as there actually doesn’t seem to be anything in OrdQtyData to replace 465, which is where I would have expected to find the replacement.

6

Andrew,
The brief history around deprecating QuantityType is that it is unambiguous and inherent in the asset that you’re trading. Secondly, through the GFIC and BMA effort during the FI gap analysis it was agreed (and there was much debate on this) that there is only one par value on the face of the bond. The amount you’re trading is this par value. The principal or gross trade amount of the trade is derived using par, factor and price (par * factor * price = principal).

In FIX 4.4 Current Face and Factor Date is not supported at this time.
Current Face is to be derived from Factor and original face. The
agency issuing the MBS would be reported in the Issuer field. Factor
and Issuer are both in the Instrument component block. For example, in
an IOI message the IOIQty would be the original face value of the MBS
and the Factor would be specified (defined as conditionally required
when factor <> 1, but good practice to put it in anyway).

However, you indicated that you’re using TradeCaptureReport message -
since you’re reporting a trade that is done wouldn’t the traded
quantity be all you need in the LastQty field?

Hi Lisa,

I think I follow what you’re saying above - so e.g. in a message
relating to a trade, one could do this:

LastQty(32) = Factor(228) =

Then implicitly orig face = current face / factor ?

I’m surprized to see 465 (QuantityType) was deprecated. Given 465 had
ORIGFACE and CURRENTFACE for values wouldn’t it be much clearer if this
tag were still included?

I note that the entry for “supported approach” in Appendix 6E is
actually missing for tag 465, which seems to be a bug in the spec. Can
you shed some light on why this decision was made as there actually
doesn’t seem to be anything in OrdQtyData to replace 465, which is where
I would have expected to find the replacement.

7

[ original email was from Andrew Thompson - anthomps@blackrock.com ]
> Andrew, The brief history around deprecating QuantityType is that it is

unambiguous and inherent in the asset that you’re trading. Secondly,
through the GFIC and BMA effort during the FI gap analysis it was agreed
(and there was much debate on this) that there is only one par value on
the face of the bond. The amount you’re trading is this par value. The
principal or gross trade amount of the trade is derived using par,
factor and price (par * factor * price = principal).

OK. That makes sense. So just to be 100% sure I understand what you mean, you’re recommending that fields like OrderQty, LastQty, CumQty and similar fields always contain the original face value (the “par”) and the current face is derived on demand?

8

Yes, quantity fields expressed as par amount to be traded or have traded.

Andrew, The brief history around deprecating QuantityType is that it
is unambiguous and inherent in the asset that you’re trading.
Secondly, through the GFIC and BMA effort during the FI gap analysis
it was agreed (and there was much debate on this) that there is only
one par value on the face of the bond. The amount you’re trading is
this par value. The principal or gross trade amount of the trade is
derived using par, factor and price (par * factor * price =
principal).

OK. That makes sense. So just to be 100% sure I understand what you
mean, you’re recommending that fields like OrderQty, LastQty, CumQty and
similar fields always contain the original face value (the “par”) and
the current face is derived on demand?

9

Yes, quantity fields expressed as par amount to be traded or have
traded.

Andrew, The brief history around deprecating QuantityType is that it
is unambiguous and inherent in the asset that you’re trading.
Secondly, through the GFIC and BMA effort during the FI gap analysis
it was agreed (and there was much debate on this) that there is only
one par value on the face of the bond. The amount you’re trading is
this par value. The principal or gross trade amount of the trade is
derived using par, factor and price (par * factor * price =
principal).

OK. That makes sense. So just to be 100% sure I understand what you
mean, you’re recommending that fields like OrderQty, LastQty, CumQty
and similar fields always contain the original face value (the “par”)
and the current face is derived on demand?

Everyone needs to understand that the trade amount is different within the MBS market, depending on the kind of MBS you are trading. If you are trading a TBA, the amount you agree to is a round amount, with the specific amount To Be Announced later, when the pools are specified. When you trade a specified pool, or a CMO, the amount agreed to in the trade is the original face, with the actual settlement face amount to be calculated later, when the factor is known. Thus the settlement face amount for a TBA will be within 1% of the trade amount, but the settlement face amount in a specified pool trade may be many percent different from the amount agreed to. That may require a different FIX treatment for each type.