Composing Contracts: An Adventure in Financial Engineering

Interesting reading (via a colleague):

Financial and insurance contracts do not sound like promising territory for functional programming and formal semantics, but in fact we have discovered that insights from programming languages bear directly on the complex subject of describing and valuing a large class of contracts.

We introduce a combinator library that allows us to describe such contracts precisely, and a compositional denotational semantics that says what such contracts are worth. We sketch an implementation of our combinator library in Haskell. Interestingly, lazy evaluation plays a crucial role.

Video

Advertisement

~ by mdavey on December 23, 2010.

2 Responses to “Composing Contracts: An Adventure in Financial Engineering”

  1. The Functional Payout Framework is a working implementation of the ideas in the Simon Peyton-Jones paper: http://lambda-the-ultimate.org/node/3331

    (I worked with these guys a while back and what they were doing looked pretty great)

  2. I recently wrote a risk service in F# requiring extensive calculations involving many instruments. The data for the collection of instruments (such as price, theo val, etc.) in each calc must be temporally consistent and static for the duration of the calculation. Thus, a “snapshot” is taken before each such calculation. This is fine, it allows for an implementation using pure functions and all the goodness that comes with this. The downside is that the full snapshot must be passed around to even the most primitive of the functions and this often requires a “lookup” in the snapshot to acquire some price or other value – i.e., no reference to some updateable latest value can be retained between calculations.

    I looked at the ideas in the Elliot – Hudak paper on FRAN: http://conal.net/papers/icfp97/icfp97.pdf. Incidentally, Elliot was at Microsoft Graphic Research Group at that time. Their ideas of Behaviors is cited as the basis for Observables in the Peyton Jones – Eber paper. I haven’t digested it all just yet, but I suspect that these ideas will help me resolve some of the nagging conflicts between reactivity, immutability, and pure functions in my F# financial apps… or not.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

Join 273 other followers