Bond Duration & Convexity


#1

Hi all, Can someone help me with FIX tag for Bond Duration, Convexity and Bond Modified Duration?


#2

Thank you for your inquiry. Some definitions:

  • Bond Duration on Coupon Date Calculator - Duration is a measure of the length of time it will take the bond’s cash flows to repay the investor the price he or she paid for the bond.

  • Modified Duration is a formula that expresses the measurable change in the value of a bond in response to a change in interest rates.

  • Convexity is a measure of the curvature in the relationship between bond prices and bond yields that demonstrates bond changes.

There is no currently support for these bond analytics in FIX but the place where they would go is the RelativeValueGrp component with new enumerations for RelativeValueType(2530). The component currently lives in ExecutionReport(35=8), IOI(35=6) and Quote(35=S). If you are drafting an ROE then extend RelativeValueType(2530) with enumerations 100 and above and add the component to any message you need it in.

Growth of the FIX standard is member-driven, so we would welcome a proposal from your firm to extend the standard with your requirements. We would be glad to help get you started with this effort.


#3

Thanks for the reply. However, business is not Ok to use RelativeValueGrp Component. We are thinking to go with StipulationType with our custom defined values


#4

@carmianleslie You give a good example of how standards are perceived, in this case by “business”. I am quite familiar with this dilemma where “business” wants to pick FIX fields. Standards should not only be followed in cases where one likes to do so, especially when it is not about performance but only about semantics of fields and valid values. I am not saying that FIX always only has a single way of expressing given semantics. But it is a problem for the community if some implement bond duration & convexity with RelativeValueGrp and some with StipulationType.

As Dean points out, it is not part of the standard yet but, given Dean’s FIX expertise, it would probably become part of RelativeValueType(2530) and not StipulationType, causing your implementation to suddenly become non-standard. By the way “business” specifies business requirements and is not responsible for detailed design which includes messages, fields and valid values used to meet the requirements :slight_smile:


#5

@carmianleslie: I agree with @hanno.klein – you should solicit feedback from your business why exactly they want to have these fields. Maybe there is another way and you can get compliant with the way @deankauffman suggests. This was my first thought as I read your message but @hanno.klein made a more elaborate point which I fully support.