Financial Contract Example

(moved from ChallengeSixVersusFpDiscussion)

However, here's an example of practical application of functional ideas to real (and non-trivial ) business problems http://citeseer.ist.psu.edu/jones00composing.html . The ideas from that paper materialized in a real product with a real company behind, see http://www.lexifi.com/faq.html#wosdmro (they state that their product is based on Caml) -- AnonymousDonor

The paper presents what is actually a rather interesting domain specific language, so here's an intro to what that paper says (cut and paste didn't work, this is all re-typed by hand, and severely paraphrased in parts for brevity; may have lots of errors):

Set of combinators usable to create a domain specific language for contracts. Combinators can describe a contract, process a contract, find the value of a contract. Lazy evaluation is critical. Domain entities include: contract, observable, date, time, currency, dimensionless real value, value process, random variable. example: zero-coupon discount bond ("receive 100 pounds on 1st January 2010") Translation:

  c1 :: contract
  c1 = zcb t1 100 GBP

The combinator zcb has type:

  zcb :: date -> double -> currency -> contract

ML-languages use CurrySchoenfinkling?, so functional type signatures don't behave quite the same way as in most other kinds of languages. But as a first approximation in non-ML languages, that's roughly:

  contract zcb(date, double, currency);

...being called as:

  example_contract = zcb(t1, 100, GBP);

t1 is therefore a date, e.g.

  t1 = date "1200GMT 1 Feb 2010"

  t1 = date("1200GMT 1 Feb 2010");

The date type supports subtraction, yielding a floating-point number in the units of Days.

Contracts can be combined into larger contracts, e.g. with combinator and:

   and :: Contract -> Contract -> Contract

E.g. with the above contract c1 and a new c2:

  c2 = zcb t2 200 GBP
  c3 = c1 `and` c2     (Backquotes allow a func to be used as infix operator)

I.e. the holder of contract c3 will benefit from a payment of 100 pounds at time t1, and another payment of 200 pounds at time t2.

In general contracts are between two parties, the "holder" of the contract and the "counter-party". By default the contract owner receives the payments and makes choices specified in the contract. This can be reversed with the give combinator:

  give :: Contract -> Contract

E.g.

  c4 = c1 `and` give c2

The holder of contract c4 receives 100 pounds at time t1 but pays 200 pounds at time t2.

New combinators (functions that build contracts) can be created:

  andGive :: Contract -> Contract -> Contract
  andGive c d = c `and` give d

...so that c4 could instead be defined

  c4 = c1 `andGive` c2

Contracts have an acquisition date, and a horizon. If a contract is acquired after it has already made a payout, the payout naturally will not be duplicated. Horizon is the last date on which a contract can be acquired; may be finite or infinite. Options are contract clauses that allow a choice, e.g. "the right to decide on or before 1 Jan 2001 whether to have contract C".

Combinator one is a primitive that yields immediate payment:

  c5 = one GBP

...means you immediately receive one pound. Has infinite horizon.

Combinator truncate t c is a contract that trim's c's horizon to date t.

Combinator get c is a contract that, upon acquisition, acquires the underlying contract c at c's horizon.

Combinator skaleK is used to scale up or down an amount, it has type

  skaleK :: double -> contract -> contract

To acquire (scaleK x c) is to acquire c, but all payments and receipts in c are multiplied by x.

The above-mentioned non-builtin combinator zcb can thus be defined:

  zcb :: date -> double -> currency -> contract
  zcb t r k = scaleK x (get (truncate t (one k)))

Other combinators: zero (contract with no rights and infinite horizon), ''or and then (to go alone with and), anytime, and combinators on observables: konst, lift, lift2, instance, time (see paper).

Given this excerpt, it seems pretty clear that top's stuff below is unrelated to what the paper is saying -- was it supposed to be related? -- DougMerritt

It is entirely possible I misinterpreted it. That is why I would like to see descriptions of the requirements and/or use-cases devoid of terms from a specific computer-language. (See below).

My interpretation is that the user is trying to evaluate either the value of a portfolio of contracts/investments or trying to decide which set of options are the most lucrative. I imagine there will be fiddle-able parameters, such as changes in the market interest rates or exchange rates. Thus, one should be able to evaluate the choices based on different parameters.

-- top

I see no reason why a declarative approach cannot be taken for most of it. Here is a set of tables that can be used to define contract trees and describe contracts and their parameters. Algorithms are not defined here, only referenced. The parameters that are specified are dependent on the needs of the particular algorithm. (If one wants to implement pre-run parameter validation, they can.)

Note that one does not necessarily have to enter the information as tables, for a nice front-end can be developed. This just defines the model and not the presentation. The presentation can be tables, trees, notation, etc.

I feel that this approach makes it easier to provide different views as needed. The linguistical approach unnecessarily hard-wires a presentation. The only advantage I can see is perhaps machine performance.

table: contracts ---------- contractID // may be name or number descript parentRef // parent contract (if applic.) algorithmRef // foreign key to algorithm

table: contractParams ---------- contractRef paramName paramValue valueType // optional

To "execute" the model, one just traverses the tree using standard tree-traversal algorithms, adding up the components along the way. One can start at a particular node on the tree if they just want to evaluate part of the tree.

But you don't have lazy evaluation, which the paper said was important. Nor other ways of varying the traversal order, do you?
Would a priority weighting on each node help? The high-ranking children would be evaluated before the low-ranking children. And/or, we could have an "operation" that stopped further tree transversal. By the way, what is a use-case where lazy evaluation is needed?

The algorithm determines what is done with the children. At first, I thought about making an operation column, but realized that may have been too limiting. Thus, I pushed that responsibility off onto the algorithm.

In some cases, we may want to use variables instead of values. Thus, parameters should perhaps allow some notation for variables, such as "&cir" for "current interest rate". The evaluator would see the "&" at the start of the token and substitute the variable the user sets for "cir".

Maybe we will need a "constants" or "scenario" table so that different scenarios can be evaluated. For example, one can try different bond and stock return rates and give a name to the set of assumed constants.

We may also want to store intermediate values for later analysis. If there is only one user, then we can perhaps have a result value holder in the contract table above. If there are multiple users, then a separate table to hold the calculated values can be created with a format similar to:

 table: results
 ------------
 contractRef
 runRef
 userRef
 theResult

-- top

Top, the above is handwaving. Please read the paper again and come up at least with something that can do what is described in the paper. And after that you can handwave your conclusions. -- Costin

Whatever SubLanguage you create in Caml can be turned into an AbstractSyntaxTree instead. In my experience this usually makes things easier because most users don't want to deal with a goofy language syntax. Plus, this approach does not rule out a syntax view if some users want it. We can have a tree-browser, table-browser, and syntax for same meaning and perhaps interchangeable. If you do it in Caml, then the other options are much more difficult. I am simply following the grand principle of SeparateMeaningFromPresentation.

What that has to do with anything? You presented an awfully incomplete schema that is good for nothing and no code, so what is it that you're trying to say and how do you come with such bold conclusions. Lots of talk and nothing to show for it. Come back when you have something to talk about.

Are you denying that you are not separating meaning from presentation? My approach less dictates syntax. The customer way want to use a tree browser, spreadsheet-like view, and/or textual syntax. I am better able to provide all those options without overhauling the system because I divorce the two. If you reject the goal of separation and/or dismiss the value of a declarative approach, I would like to know why regardless of whether my start appears rough.

Maybe I'll whip something out in ExBase next week. By the way, do you have a better PDF version? That one is highly blocky. (God, I hate PDF)

The Postscript version is better.

My PS reader keeps complaining about a missing part.

That document appears to mostly show an implementation, and not a specification. I suspect such is not available because it is a commercial company who generally want to protect their hard-gained domain knowledge. The best we can probably do is guess based on the one paper.

It shows what amounts to a domain-specific language for implementing contracts, gives examples of its use (toy examples, admittedly, but what else is new?), and explains it well enough that anyone could do the same thing starting from scratch, so what is the specification that you find lacking?

Ideally it would be worded in terms of requirements, not in terms of a specific syntax. Some testing/illustrative scenarios would be nice too (input and outputs).

Yeah, and IwantaPony. Seriously, though, "would be nice" is irrelevant. This isn't an ISO standard, it's an abstract notion, that can potentially take many forms. The paper in question showed one approach, using an ML-family language. That doesn't mean that the abstract concepts are inherently limited to languages in that family. Syntax is not the issue, not at all.

And it's bizarre to talk about requirements, when the topic is brainstorming new solutions in new domains using new primitives. That's PointyHairedBoss thinking: "I order you to have a new idea!" The "requirements" here are "solve the problem of modeling financial contracts".

If there are not solid requirements, then perhaps provide say 5 to 10 detailed UseCase or UserStory scenarios. A word of warning, though: comparisons of coded examples based on open-ended or fuzzy requirements can lead to problems down the road. This happened with the "payroll" example before. (I cannot find the topic name. IIRC, it forked off from EmployeeTypes and turned into a nasty thread-mode, so it may have been deleted.) I created some hypothetical requirements and somebody balked, claiming they were unrealistic assumptions. -- top

Don't people use spreadsheets for this kind of thing? Financial scenario analysis was one of the motivations to invent the electronic spreadsheet to begin with. As developers we would probably prefer something more programmer-friendly, but spreadsheets are TuringComplete such that they can do just about any calculation needed, and business analysts are quite familiar with them. See MsAccessSyndrome.

CategoryExample, CategoryBusinessDomain