component-orientationmeets financial modeling · 2006. 9. 29. · adding a cap adding the upper...

Derivative Contracts as Active DocumentsComponent-Orientation meets Financial Modeling

Markus Reitz∗University of KaiserslauternSoftware Technology Group

P.O. Box 3049, 67653 KaiserslauternGermany

r

Ulrich Nögel∗Fraunhofer ITWM

Department of Financial MathematicsFraunhofer-Platz 1, 67663 Kaiserslautern

Germanye

Abstract: Derivative contracts represent a very important and constantly growing financial segment of local andworld-wide markets. To assure or even improve one’s position in an environment characterised by permanentlyshortening product life and time to market cycles, global as well as local market players have to optimise theoverall product design process. The inherent flexibility of derivatives creates both: nearly unbounded opportunitiesfor new and innovative contracts and the pressure to use efficient methods for contract composition, processing,management and valuation. Techniques based on the concept of an A D, a component-orientedapproach, are able to offer novel solutions for these problems. This paper discusses A D in thecontext of derivatives, sketches possible benefits when compared to state of the practice techniques and outlinesnew scenarios for ingenious usage of the added value of A D systems.

Key–Words: Active Documents, Derivative Contracts, Component-Orientation, Financial Engineering, Java, XML

1 IntroductionTo cope with the problems resulting from permanentlyshortening product development cycles, financial en-gineers need new design methodologies and software-based supportive technologies. CDC1 aims atproviding means to generically compose, check andstore derivative contracts, using an A Dbased representation technique whose level of ab-straction is above that of plain mathematical formu-lae. Based on this abstraction, structural as well assemantical consistency checks are available, freeingthe financial engineer from mind-numbing tasks, let-ting him concentrate on the really creative aspects ofthe design process. Besides those checks, the addi-tional information provided by this abstraction maybe used to automatically construct effective valuationalgorithms for derivative contracts, too. Depending onthe specific contract, the supporting framework is ableto select the best matching valuation algorithm for fairprice calculations. To be of practical relevance, theapproach has to offer both:

1. Backwards Compatibility, i.e. existing deriva-

∗Supported by the cluster of excellence Dependable AdaptiveSystems and Mathematical Modeling (DASMOD) of Rhineland-Palatinate, Germany.

1Composable Derivative Contracts, a subproject of DASMOD(http://www.dasmod.de).

tives should be expressible in terms of the ap-proach, and

2. Openness, i.e. properties and features of nextgeneration derivatives should be modelable ef-fectively.

Component-oriented technologies, manifested inthe A D framework, are applied to thedomain of financial modeling, transferring their im-manent flexibility to derivative contracts. Any deriva-tive contract may be expressed in terms of such a doc-ument, whereas in this context, the term active refersto

• the ability to automatically check and enforceconsistency constraints, i.e. avoid invalid ormeaningless contracts.

• the ability to automatically perform context-specific adaptations, e.g. find the best-matchingvaluation algorithm.

This paper introduces the overall concepts ofCDC, gives an overview of the project andsketches questions that will be investigated in forth-coming working packages.

Proceedings of the 7th WSEAS International Conference on Mathematics & Computers in Business & Economics, Cavtat, Croatia, June 13-15, 2006 (pp13-18)

2 Related WorkAD are an evolutionary continuation ofcompound document technologies. Introduced withMicrosoft OLE and further refined in COM [1], acompound document is able to combine different me-dia data types and allows for in-place editing. Apple’sOpenDoc [2] aimed at providing a multi-platformframework, but the attempt was not crowned with suc-cess. Starting with Mac OS X, OpenDoc has been de-clared a deprecated technology and is no longer sup-ported. Minerva [3] introduced the notion of an A- D in the context of e-Learning during theEasycomp project [4]. CDC as well as the un-derlying framework for general-purpose A D- are based on the insights and results of thisEU-funded research.

3 A DWhen modeling derivative contracts, the general-purpose framework is specialised towards a specificvariant, Hierarchical A D, which isused for contract representation by the runtime sys-tem. Being hierarchical, derivative contracts and theircorresponding A D representation maybe expressed in a XML-based format.

Example 1 Figure 1 represents a derivative contractC having a payoff of

PC(t) =

{min(max(FOO(t) − 12, 10), 20) t = 7unknown otherwise

The transformation from PC to P̂C , so

∀t ≤ MATURITY(C) : P̂C(t) � unknownholds, is performed by an appropriate valuation pro-cess whose internals are described in Section 4.

For Hierarchical A D, additionalconstraints for the principal entities environment andcomponent have to be taken into account:

• An environment embeds at most one componentand an arbitrary number of environments.

• Environments enforce the local messages onlyconstraint, i.e. only intra-environmental mes-sages may pass environmental boundaries.

Using XML as an intermediate representation,document interchanging and transformation could beperformed using standard technologies, e.g. XMLSchema or XSL. Besides graphical derivative develop-ment environments, simple text editors may be used tohandle contracts, because of a textual representation.

Mathematical Assembler Implementing a contractwith the help of mathematical formulae is similar toprogramming in low-level assembler, missing all thebells and whistles of modern programming languages,e.g. types. Moving from a hard-coded implementa-tion based on pure mathematical descriptions to A- D is comparable to the transition fromassembly language to a high-level programming lan-guage. The supporting framework provides similaror analogous features a conventional IDE offers to itsusers2.

3.1 AdvantagesFor decades, financial engineers have designed andanalysed derivative contracts using plain mathemati-cal formulae and have done well using straightforwarddescription techniques - so why switch over to AD? The answer is quite simple: With in-creasing complexity and decreasing turnaround time,current low-level description techniques do not scaleup well, limiting the set of handleable contracts andusage scenarios.

Being a loosely coupled system, A D- offer a high degree of flexibility and extensibil-ity. For example, to support smoothing based on thegeometric mean besides the already available smooth-ing using the arithmetic mean, adding a specific com-ponent is sufficient. All parts of the system, e.g. val-uation and composition facilities, are made aware ofthe improved feature set automatically.

Because of component-orientation, every user isable to configure the system according to specificneeds by adapting the general-purpose system ade-quately. Reinventing the wheel for every contract byspecifically developing composition and valuation fa-cilities for each category is unnecessary because of theprovided genericity. System adaptation according toindividual user requirements is therefore simple.

Structural and semantical checking facilities opti-mise the design process and help to evaluate a contractin its early design stage using explorative compositiontechniques.

3.2 From simple to complex contractsAny derivative contract can be defined by its payoffand additional information concerning the conditionsthat allow to exercise it, e.g. european or americanstyle derivatives. Because of the tremendous high de-gree of flexibility3, a payoff may be as simple as in

2From the perspective of a general-purpose A Dframework, an IDE is a special kind of A D, too.

3"With derivatives you can have almost any payoff pattern youwant. If you can draw it on paper, or describe it in words, someone


< c o n t r a c t>

< c o n s t a n t i d=" upperBound " v a l u e=" 20 " / >< f l o o r u s i n g=" lowerBound ">< c o n s t a n t i d=" lowerBound " v a l u e=" 10 " / >< d e r i v a t i v e>< s e l l>< c o n d i t i o n>< a t t i m e s t e p=" 7 " />

< / c o n d i t i o n>

< / s e l l>

< c o n d i t i o n>< a t t i m e s t e p=" 0 " />

< / c o n d i t i o n>< c o n s t a n t i d=" s t r i k e " v a l u e=" 12 " / >

< / a c q u i r e>< / d e r i v a t i v e>

< / f l o o r>< / cap>

< / c o n t r a c t>

cap

contract

constant

floor

......

Figure 1: A serialised contract representing a derivativebased on the underlying FOO, whose value is limited by anupper bound of 20 and a lower bound of 10 monetary units.The underlying is acquired virtually at timestep 0 and soldvirtually at timestep 7.

Figure 2: Instantiation of the contract on the left (boxesrepresent environments). Because of the local messagesonly constraint, a specific message propagation scheme,e.g. only messages from the contract component reach thecap component, is guaranteed by the runtime system.

the case of a plain vanilla european call option havinga strike of K and maturity T

P(T ) = max(S (T ) − K, 0)or as complex as in the case of a globally capped andfloored cliquet (0 ≤ t1 ≤ t2 · · · ≤ tn = T )

P(T ) =

n∑

i=1

max

(min

(S (ti) − S (ti−1)

S (ti), F

),C

)+

Cliquet options belong to the class of structuredoptions, being part of a new generation of highly com-plex OTC4 products, whose importance will increasein the future. Construction and pricing of this andother classes of options are complex and tedious tasksthat are simplified by A D technologies.

3.3 Contract CompositionA D may be instantiated from a validXML description, but when designing new contracts,interactive and feedback-driven design techniques aresuperior to their non-interactive counterparts. An ex-plorative design style is supported and enforced, cre-ating the need for a (at least) three-valued classifica-tion scheme in contrast to non-interactive design pro-cesses.

Consistent States represent all circumstances, whichare valid according to the composition specifica-tion.

can design a derivative that gives you that payoff." (Fischer Black,1995)

4Over The Counter, i.e. a derivative is specifically tailoredaccording to individual customer requirements.

Transitional States represent all situations, in whichthe composition specification is violated, but cer-tain constructive, i.e. additive, operations per-formed by the A D would result ina consistent state.

Inconsistent States represent all circumstances,which are invalid according to the compositionspecification. In inconsistent state, only destruc-tive operations, i.e. operations that remove partsof the A D, are allowed, as theselead to transitional or consistent states.

As the runtime system enforces the compositionspecification, it is impossible to transform a valid,i.e. consistent or transitional A D intoan inconsistent one (see Figure 3). Directly manip-ulating serialised contracts, i.e. circumventing con-straint checking, is the only possibility to create incon-sistent A D, leading to constraint viola-tions during the instantiation phase.

3.3.1 Composition Constraints

By letting only reasonable contracts pass, composi-tion constraints inhibit invalid and counterproductivecomposition attempts. Using higher level descriptiontechniques, many kinds of inconsistencies can be eas-ily detected.

Example 2 The payoff of a contract based on thegiven example with values of upper and lower boundaccidently interchanged would be

PC(T ) = min(max(FOO(T ) − 12, 20), 10) = 10


DerivativeContract Component

Repository

Addin

g a ca

p

Adding the

upper bound

Figure 3: A contract in a consistent state is signaled by a green background (depending on the context, an empty conditiondefaults to timestep T or 0). Starting from a floored contract, e.g. made available by a contract repository, a cap componentis added using an appropriate drag and drop gesture. The resulting contract is in transitional state, indicated by a yellowbackground. By defining the cap’s upper bound, the contract is completed, leading to a consistent state again.

which is independent from the underlying’s perfor-mance and in almost any case not the intended design.

Example 3 An unintentionally double-floored con-tract could be detected and marked as erroneous ortransformed to the optimised version

lowerBound = max(lowerBound1, lowerBound2)

Keep in mind that these examples are simple forillustration purposes only; real world contracts mayexhibit a high degree of complexity, making general-purpose semantic checking facilities a valuable prop-erty of A D. With CDC also tar-geting the non-expert user as a contract designer (seeSection 5), semantic checking becomes an essentialaspect of the composition tool-chain.

3.4 Component RepositoryThe lynchpin of a derivative contract composition sys-tem is its component repository, which subsumes allbuilding blocks available for contract design. By com-bining these pieces, the user is able to create consis-tent and semantical meaningful derivative contracts.As an essential aspect of an A D sys-tem is its openness with respect to future extensions,it is impossible to provide static composition specifi-cations. Instead, a derivative contract component hasto provide modular specification information, whichdescribe the component’s relation to other entities in alocal as well as in a system-wide manner.

By combining these results, the runtime system isable to create a finalised document specification outof all available specification fragments. It should beobvious that the result of this process is dependent onthe current component repository configuration, i.e. acustomised specification is created.

4 Contract ValuationFair price calculations in conjunction with risk man-agement decisions for derivative securities representtwo of the most important topics in modern finance.Common mathematical approaches for solving thepricing problem can be assigned to one of three cat-egories.

1. Closed-form Solutions provide analytical fairprice formulae for a limited set of types of deriva-tives and models (see e.g. [5]). The lack of ageneral-purpose framework of closed-form solu-tions is compensated by the fact that only a min-imal amount of computational resources is usu-ally required.

2. Monte Carlo Simulations represent a nearlygeneral-purpose and easy to understand approachfor pricing a large amount of types of derivatives.Unfortunately, simulation is computationally in-tensive and does not provide a straightforwardpossibility to price american style derivatives.

3. Tree-based Algorithms allow for price calcu-lations for european and american style deriva-tives, therefore offering a general-purpose frame-work for contract valuation. In contrast to MonteCarlo simulations, tree algorithms usually showup fast convergence, but in multi-dimensionalsettings, the memory footprint may impose limi-tations.

Categorisation scheme To provide a flexible andefficient valuation engine, a categorisation scheme,which is able to detect the applicability of closed-formsolutions when appropriate, use tree-based algorithmsin the common case and provide Monte Carlo simu-lations as an additional method, has to be developed.


Interact ValuationEngine

ModelRepository

AlgorithmRepository

ComponentRepository

ContractRepository

TemplateRepository

Specification

Active Document Runtime System

Composition Facilities

Con

trac

t

Compos

e

Check

Instantiate

Check

ConstraintRepositoryDefin

eEnforce

Check

Figure 4: A conceptual overview of the software system that is developed as part of CDC. The AD runtimesystem acts as a kind of middleware, providing the necessary services to support composition and valuation.

The meta-information necessary to perform this adap-tation process is provided by the A Drepresenting the financial contract.

Multi-dimensional tree algorithms Because thesketched usage scenario allows for derivatives basedon multiple underlyings, computationally efficientmulti-dimensional tree algorithms have to be in-vented. This development is based on the results of[6] which are derived from [7], providing efficient andfast converging algorithms.

4.1 ModelsModeling an european plain vanilla option by assum-ing the applicability of geometric brownian motionwith constant volatility σ for its underlying by Black& Scholes [8] (respectively Merton [9]) in 1973 ledto the first closed-form solution. Until now, ongoingresearch has come up with closed-form solutions fora large amount of types of derivatives (see e.g. [5]).Albeit being used as a market standard, the famousBlack-Scholes model reaches its limits in case of com-plex derivative contracts (see [10], [11] and referencestherein) and is therefore only one of a plethora of mod-els a general-purpose pricing engine has to provideand handle. In addition to the Black-Scholes model, atleast local and stochastic volatility models will haveto be integrated into the core valuation engine.

4.2 Component-Oriented ValuationComponent-oriented design principles, the founda-tion of the A D system, are dominat-ing the valuation engine architecture, too. In con-trast to the common approach of hard-coding all imag-inable meaningful combinations of derivatives andmodels, resulting in large refactoring and reimple-mentation efforts in case of feature enhancement re-quests, the flexible generic pricing engine allows foreasy extensions using components. Componentised

algorithms and models are subsumed in the engine’srepository. As the pricing engine is able to select thebest-fitting modus operandi for fair price calculationsfrom its repository according to the meta-informationprovided by the A D system, it is able tocope with almost arbitrary complex contracts.

Combining both, A D technologyfor easy composition of contracts and component-oriented valuation for efficient and flexible fair pricecalculations, provides all ingredients for the next gen-eration tool chain for derivative contract construction.

5 Towards new horizons

A D technology enhances standardderivative design processes, which represent a largepart of everyday work of any financial engineer. Theimpact of A D is not limited to theworkflow of CDC’s primary audience - the fol-lowing paragraphs present a selection of applicationsbeyond this use case.

5.1 Personalised Derivative ContractsWith derivatives being a traditional OTC product, theparticipating parties are formed by financially stronginvestors, e.g. institutional or hedgefond managers,because usual OTC is only cost-effective in case oflarge-scale financial investments. During the lastyears, the growing interest of small and medium in-vestors for alternatives to shares and bonds has beenblocked by the financial barrier formed by the high de-sign costs of individual designed products, preventingOTC to become an option for small and medium-scaleinvestments.

With CDC, the financial barrier is loweredsignificantly, making OTC a realistic alternative toalready available semi-individual financial products.The customer’s phase of influence is expanded into thecontract design process, because the customer him-


self is able to design autonomously5. The AD system used to implement CDC su-pervises the design process by providing the set ofcomposition operators and components for contractconstruction, additionally enforcing composition con-straints. Effects of contract changes are instantaneous,enabling easy composition of contracts until completeconformance to individual demands is reached. Con-tract negotiation and design become interactive andexplorative because of the user-guiding facilities of anA D framework. Next generation elec-tronic financial services will allow customers to addindividually designed derivatives to their portfolios inreal-time, even if the customer is not an expert in thefield.

5.2 Computer-Aided TrainingUsing CDC as flexible electronic learning mate-rials, interactive and feedback-driven training lessonshelp to improve knowledge about derivatives inshorter periods of time when compared to tradi-tional training methods6. By interactively composingderivative contracts based on the company’s compo-nent repository, employees are able to participate inlearning lessons according to their individual learninghabits instead of being forced to follow predeterminedlearning paths. In-house training lessons may substi-tute expensive third party offerings.

5.3 Smart Contract RepositoriesAfter introducing a CDC based approach, thecompany’s repository grows with every new con-tract, accumulating knowledge and therefore beinga valuable asset. Before CDC, there were justmathematical formulae, possibly enriched with meta-data, often using some kind of free-form markup.CDC introduce structural information above thepure implementation description based on plain for-mulae, making each contract a queryable entity by us-ing specialised languages, e.g. "List all contracts hav-ing a stop loss of X and smoothing".

6 ConclusionsA D technology combined with acomponent-oriented pricing engine provides the toolsnecessary to tackle the increasing design demands ofcurrent and future contract design workflows. Being

5Currently, the customer is billed (in)directly for the designprocess carried out by a financial engineer, making an arbitrarynumber of iteration steps illusory.

6CDC could provide services which are comparable tobut more flexible than those of Minerva.

highly interactive, an explorative and feedback-drivendesign process, both the financial engineer and thenon-expert customer may profit from, becomes real-ity. The increased level of abstraction allows for en-hanced supportive technologies that help to decreasethe overall design time and reduce or even avoid po-tential errors or problems by shifting them towardsvery early stages of the design process. The tradition-ally strictly separated entities Factsheet and Imple-mentation are unified by this approach, leading to in-creased knowledge reuse, financial engineers as wellas customers may benefit from.

References:

[1] Box, D.: Essential COM. Addison Wesley Pub-lishing Company Incorporated. 1999

[2] Apple Computers Inc.: Inside Macintosh: Open-Doc Programmer’s Guide. Addison Wesley Pub-lishing Company Incorporated. 1996

[3] Reitz, M. & Stenzel, C.: Minerva: A component-based framework for Active Documents. Pro-ceedings of the Software Composition Workshop(SC 2004). ENTCS 114. Elsevier. 2005

[4] EASYCOMP (IST Project 1999-14191). EasyComposition in Future Generation ComponentSystems. http://www.easycomp.org

[5] Korn, R. & Korn, E.: Option Pricing and Portfo-lio Optimization. AMS. Rhode Island. 2001

[6] Müller, S.: Multi-Dimensional Trees for Op-tion Valuation. Diploma Thesis. University ofKaiserslautern. March 2006

[7] He, H.: Convergence from Discrete to Contin-uous-Time Contingent Claim Prices. WorkingPaper, University of California, Berkeley

[8] Black, F. & Scholes, M.: The pricing of op-tions and corporate liabilities. Journal of Polit-ical Economy, 81, 637–659. 1973

[9] Merton, R.: The theory of rational option pric-ing. Bell Journal of Economics and ManagementScience, 4, 141–183. 1973

[10] Nögel, U. & Mikhailov, S.: Heston’s stochas-tic volatility model. Implementation, calibrationand some extensions. WILMOTT Magazine, 74–79. July 2003

[11] Nögel, U.: Option Pricing using StochasticVolatility Models. Progress in Industrial Math-ematics at ECMI 2002. Springer Verlag. Heidel-berg. 2004
