wilmott.com

A kick off post:1. What are the main categories?2. What are their requirements?3. How do they use software?A good group imo is Model Validation. I think <<flaxibel and accurate software>> is the most important for them. This is the group that needs to test many kinds of model. So, loose coupling and design patterns. And tools to visualisation and reporting.A common data model as well? e.g. Contract that can be used by MC, PDE, etc.AFAIK no open s/w can do this. But micro optimised code also not. What about FO, traders?Brainstorming ideas? I don't think it is rocket science to determine what people need.

Hi - Please ignore if this is not on the lines of what you have in mind for thsi thread - here is my take on the features (Software+docs) that may be commonly usable across all teams (FO, MO, MV, Risk, quant, tech etc)1) Clear, valuation-worthy product details - esp. for the standardized products, along with their commonly used bells/whistles (such as amortizers, embedded calls/puts etc). This may be more of a docs job, but a standardized C/C++ interface to access the product features may be a good idea.2) Product market quote mechansims, and clear mathematical descriptions on how to go from one quote format to the other (incluing other market parameters that could be used).3) Product RV measures (like referenced in the other thread for bonds - http://www.wilmott.com/messageview.cfm? ... adid=90092)4) Standard valuation techniques for the standard products - again like the other three, this may be more of a documentation issue.

QuoteOriginally posted by: l7nk37Hi - Please ignore if this is not on the lines of what you have in mind for thsi thread - here is my take on the features (Software+docs) that may be commonly usable across all teams (FO, MO, MV, Risk, quant, tech etc)1) Clear, valuation-worthy product details - esp. for the standardized products, along with their commonly used bells/whistles (such as amortizers, embedded calls/puts etc). This may be more of a docs job, but a standardized C/C++ interface to access the product features may be a good idea.2) Product market quote mechansims, and clear mathematical descriptions on how to go from one quote format to the other (incluing other market parameters that could be used).3) Product RV measures (like referenced in the other thread for bonds - http://www.wilmott.com/messageview.cfm? ... adid=90092)4) Standard valuation techniques for the standard products - again like the other three, this may be more of a documentation issue.Yes, I think so. In general, specifying the kinds of financial products qfcl should address and then let the developers how they wish to implement these products.

We kind of discussed here.

and here