How do you specify the contract, and then link it into the systems such that all this boring paper disappears? One answer is the domain specific encoding approach, another is the natural language approach. An example of the latter is Ricardian Contracts, and here is an example of the former, domain specific encoding, method by a company called LexiFi .
Lexifi have created a language that allows specification of an entire set of contract possibilities within one narrow market. For example, if one considers the trades that occur between traders in an institutional options market, each trade can only have a score or so paramaters.
The language developed by this company, MLFi, claims to reduce such contracts down to 20 elements, and from there it is possible to compose the full set of contracts.
This seems to work well in a market where one contract is easily relatable to another - perhaps where these contracts are fungible by some measure or other. But, I wonder if it works outside a specific domain? When I see an example of a contract itself I might be able to answer that question.
( another cousin is Risla which finds this entry in
citeseer which says this:
"The Risla project has met its targets: the time it costs to introduce a new product is down from an estimated three months to two or three weeks. Moreover, financial engineers themselves can use the questionnaire [tool] to compose new products. Furthermore, it has become much easier to validate the correctness of the software realization of the interest rate products. In addition to that, the component library appears to be useful for other product families, such as insurances or options."
)
Posted by iang at January 24, 2004 03:51 PM | TrackBack