Financial Contracts

  • Robert Mamayev


To provide a foundation for the rest of this book, this chapter defines the terminology and discusses the basics of financial contracts.


Business Strategy Contract Type Business Rule Physical Asset Financial Contract 

Each problem that I solved became a rule, which served afterwards to solve other problems.

—René Descartes, Le Discours de la Méthode

To provide a foundation for the rest of this book, this chapter defines the terminology and discusses the basics of financial contracts.

What Is a Contract?

A contract is a binding agreement between two or more parties to exchange specified goods or services on specified terms. At least two parties must be engaged if there is to be a valid contract: a party that proposes something and a party that accepts that something (Figure 3-1). An agreement to sell and buy a particular product or service at a certain point in time and at a particular price is an example of a simple contract. Besides the offeror and the offeree, additional parties may participate in a given contract in various capacities, such as joint offerees, agents, receivers, referenced subsidiaries, and executors. For instance, one party may draft a particular contract and another party may supervise it. Your organization will identify the participants it wants to store and maintain well in advance, most likely based on the roles these parties play in the underlying contract.
Figure 3-1.

Model of a basic contract

A party may play multiple roles in any given contract. The CONTRACT entity, the way it is modeled in Figure 3-1, must be associated with at least two other PARTIES (identified by the “offers service” and “consumes service” relationships), with the “endorser of” relationship being optional. One limitation of this model is immediately obvious: it cannot be easily extended in terms of role specification. For instance, a PARTY may play the role of a “legal advisor” or a “contract draftee” for the underlying CONTRACT, and the model may need to account for this. Remember that a contract (especially a financial one) may contain a significant number of details; it is a legal document, and each aspect of it may need to be represented in the model. Faced with such a need, it is reasonable to consider extending (or widening) the CONTRACT entity by appending attributes to it, but this solution is not very elegant and is highly rigid. By resorting to this approach, we are limiting ourselves to extending our model only through a data definition language (DDL), which eventually might require us to alter our programming logic. Anyone who has attempted this approach will tell you that it is a nightmare for both project architects and code developers.

Another feature the plain vanilla model in Figure 3-1 lacks is the ability to create party roles dynamically. Your organization may identify a pool of roles they are interested in storing and maintaining. Even if this pool is approved by upper management, there is no guarantee that the list won’t be altered. One option would be to hard code these party roles; another option would be to introduce a new entity, a ROLE TYPE, resulting in an elegant and creative solution to the problem (Figure 3-2).
Figure 3-2.

Model of contract participation

Note the solid (mandatory) relationship line between the CONTRACT and CONTRACT PARTICIPATION. Typically, you should approach mandatory-on-both-ends relationships (including one-to-many relationships) with caution. This doesn’t mean that such configurations don’t exist or that they should always be avoided. Mandatory-on-both-ends relationships do exist, albeit not very often, and they serve a particular purpose and emphasize a unique business rule.

In our example, the mandatory-on-both-ends relationship emphasizes a business rule which states that the entries in the CONTRACT and CONTRACT PARTICIPATION entities must be populated within the same transaction. For instance, your programming logic will have to ensure that for each contract you have at least two contract participants, with one playing the buyer and one playing the seller role. Note that a given contract may be associated with other roles (and not solely those of buyer and seller), and a business rule should be developed that clearly specifies the role types that are critical within the context of a given contract.

Note that the CONTRACT PARTICIPATION entity has not been designed to store and maintain historical data. As mentioned previously, modelers are often obligated (from a legal perspective) to maintain and keep track of every alteration to the contract’s data. To maintain an accurate contract participation history, I suggest creating a new entity called HISTORICAL CONTRACT PARTICIPATION, discussed next.

Maintaining a Contract Participation History

The diagram in Figure 3-3 models a solution to the problem posed in the preceding section: how to create and maintain a proper contract participation history. The purpose of the HISTORICAL CONTRACT PARTICIPATION entity in this example is to maintain and store all of the changes (insertions, updates, and deletions) that were made to the CONTRACT PARTICIPATION records. Typically, in a large database one will find a set of “HIST_” prefixed tables that are intended to store and maintain the history of the underlying tables. Whenever a record gets altered in the source table, a database trigger fires and propagates the necessary changes to the underlying “HIST_” tables. A database trigger is a piece of code that is attached to a table and executed in response to certain predefined events.
Figure 3-3.

Example of a properly maintained contract participation history

Differentiating between a Contract and a Contract Type

The model in Figure 3-4 introduces another entity called a CONTRACT TYPE. A CONTRACT TYPE represents a catalog or blueprint of all available contracts. A CONTRACT, on the other hand, represents a legal entity—a physical embodiment of a contract type—to which at least two parties have agreed and signed on a particular date. If we adopt the object-oriented (OO) terminology, we say that a CONTRACT TYPE A (a subtype of a CONTRACT TYPE) is a base class that can be instantiated. An instance of a CONTRACT TYPE A base class is the actual CONTRACT.

Another important concept that often confuses novice modelers is the notion that a given contract type implicitly embeds within it a discrete set of business rules. These underlying business rules are usually quite familiar to the subject matter experts, and our job as modelers is often to explicitly associate a given contract with a proper contract type. For instance, assume that a financial company will deal with two contract types: contract types A and B. Contract type A requires participants to exchange physical assets up front; contract type B is the more typical type, whereby which physical assets are only exchanged on contract expiration. As you can see, associating a given contract with the wrong contract type will result in multiple inconsistencies and ambiguities. Imagine what would happen if a particular contract is linked to the wrong contract type (for the sake of our example, let's say contract type A). A relationship between our example contract and contract type A would imply that the underlying physical assets are to be exchanged at the start of the contract. However, this is clearly wrong, and our resulting data model would only further confuse our subject matter experts. A tarnished data model immediately loses credibility and suffers the consequences of being branded irrelevant. Learn to correctly associate your model types with the physical embodiment of those types and you will protect yourself from these unnecessary ­ambiguities and misunderstandings.
Figure 3-4.

Differentiating between a contract and a contract type

Assets and Asset Types

The core difference between an asset and an asset type is similar to the difference between a contract and contract type (see Figure 3-5). An asset type is a blueprint—something that exists only on paper, which you cannot hold or touch. An asset, on the other hand, is something that holds a value and you can physically hold and touch. This distinction between an asset and asset type is especially crucial within the context of a financial contract. The important thing to remember is this: if you don’t hold it, you don’t own it. Unfortunately, some business people treat assets and asset types as one and the same and learn the difference the hard way. Train yourself to separate and differentiate between paper (an asset type) and physical assets, and model them accordingly.

The Importance of Ownership Recognition

Things that are owned with a recognized level of ownership are considered assets. Examples of assets include stocks and precious metals held in an individual's possession. Even though you may have a printout confirming a level of ownership, a stock certificate or a grant of deed are legally binding indications of ownership. Paper assets are things that you don’t own, at least not in this sense.

For instance, consider a debt coupon. Here, someone has borrowed a physical asset (in this case, cash) and made a promise to return payment via a debt coupon (a paper asset, at this point). Unfortunately, a debt coupon is just a piece of paper that confirms a debt. Try taking it to a grocery store and offering it to a store clerk in exchange for groceries. In all likelihood, the sales clerk may not even understand what you are offering. You can bet that he will refuse to let you leave with your groceries. The debt coupon will remain yours to deal with until your counterparty pays back the owed amount.

A stock option is another example of an asset that points to a paper asset. An option is the paper record of a promise to allow the bearer to buy a stock at some point in the future (a paper asset) at a specific price. Unless you exercise your right to buy the specified stock, you don’t own the stock and it cannot be counted toward a portfolio of physical assets.

These examples demonstrate the notion that physical assets and asset types are different and shouldn’t be confused. Each performs a separate function and should be used in a proper context. In most cases (there are a few exceptions, of course), financial contracts will point to paper assets (or asset types) to signify that the contractually promised things are to be viewed as promises.
Figure 3-5.

Model of asset and asset type

Modeling Contract Asset Allocations

The diagram in Figure 3-6 models a CONTRACT ASSET ALLOCATION entity and the associated relationships. As you can see, a physical asset is not even displayed in the starter data model. The reason for this is that each asset listed in the underlying financial contract is a paper asset (or an asset type). Paper assets refer to things that can be held but are held by someone else. The primary on the contract merely has a claim to a promise that someone else has made. When someone promises to deliver a ton of aluminum in one month, the actual asset type under consideration is a paper asset (an aluminum asset type). As everybody knows, promises are meant to be broken. Don’t treat contractually promised things as assets, because they are paper assets (or asset types). Only once your counterparty delivers the assets will those assets be counted toward (or against) a physical asset inventory.
Figure 3-6.

Model of the relationships between contract and asset type

A CONTRACT ASSET ALLOCATION specifies which paper assets each PARTY is responsible for within the context of the financial CONTRACT. Financial contracts typically involve two assets. For example, if an investor promises a delivery of copper in exchange for a specific amount of cash, two asset types come into play: a copper asset type and a cash asset type. This brings us to an interesting point: a financial contract can be viewed as a mechanism that transforms, upon completion of delivery, one asset into another. In the copper-for-cash example, one asset (cash) is transformed on completion of the delivery into another (copper). Consider a hypothetical example of how a CONTRACT ASSET ALLOCATION is used.


Assume that today is January 1, 2014. Investor A signs a contract with investor B and agrees to purchase 10 tons of aluminum for US$10,000 on July 1, 2014. The result is a very simple contract involving two parties—investor A and investor B—with a contract expiration date of July 1, 2014. Note that the contract in question involves two asset types: a CASH ASSET TYPE (for the sake of simplicity we assume here that investor A will pay with cash) and an ALUMINUM ASSET TYPE. Inasmuch as a contract is a promise, its underlying assets should be treated as paper assets. Thus, we need to store two records in the CONTRACT ASSET ALLOCATION: one associating investor A with the CASH ASSET TYPE (a subtype of the FINANCIAL asset type) and a set amount equal to $10,000; the other record will associate investor B with an ALUMINUM ASSET TYPE (a subtype of the COMMODITY ASSET TYPE) and set the quantity equal to 10 tons.

The model in Figure 3-6 provides no means of specifying units of measure (here, tons). The diagram in Figure 3-7 clarifies this issue and shows how to associate a UNIT OF MEASURE with a CONTRACT ASSET ALLOCATION. Note that the relationship between the CONTRACT ASSET ALLOCATION and the UNIT OF MEASURE is nonmandatory on both sides. This is done by design, because not every asset type will have a true unit of measure.
Figure 3-7.

Model of the relationship between contract asset allocation and unit of measure

Once the two records are stored in the CONTRACT ASSET ALLOCATION, you can always return and reconstruct the terms of your contract to list all of the involved parties and their corresponding roles, the asset types involved, and the parties responsible for them.

Contract Structure and Contract Type Structure

Often, your requirements may call for the creation of a complex contract—one that is made up of other contracts. For instance, the underlying business strategy may involve entering into one contract at time T1, then entering into another contract at time T2, and finally entering into a third contract to offset the first two contracts at time T3. Sound complicated? They can be, but these brain-teasing data structures (Figure 3-8) occur quite frequently in practice; it would be wise to familiarize yourself with them at this early stage. One way of interpreting the meaning of the CONTRACT TYPE STRUCTURE entity is to think of the numerous ways that various contract types can be combined with one another to create something more complicated than the basic contract type would allow. The ability to combine various physical contracts into a well-defined pattern leads to a CONTRACT STRUCTURE, which may be specified by a CONTRACT TYPE STRUCTURE.

In financial engineering, a given financial contract is often combined and packaged with other contracts to create a financial instrument with a specific payoff function. This combination makes the underlying business rules more complex. However, once you are familiar with the basic building blocks and understand the meanings of these complex structures, you will be able to apply your knowledge without confusion or hesitation.
Figure 3-8.

Contract structure and contract type structure

According to your model, the CONTRACT STRUCTURE may or may not depend on the CONTRACT TYPE STRUCTURE. You can, in fact, make this relationship mandatory to enforce the rule that each CONTRACT STRUCTURE must be specified by one and only one CONTRACT TYPE STRUCTURE. Typically, your business requirements will guide you on how to shape your resulting data model to fit the needs of your client.

The following hypothetical example will help clarify the difference between CONTRACT STRUCTURE and CONTRACT TYPE STRUCTURE. Imagine that your organization has published an official list of allowed contract types and a corresponding specification that describes exactly how these contract types should be combined, including their specific order. This list is a perfect candidate for storage in the CONTRACT TYPE STRUCTURE. Now consider an investor who decides to enter into a number of physical contracts to create some specific payoff function. The list of physical contracts that our investor enters into should be stored in the CONTRACT STRUCTURE. If this investor is to be forced to consult with the CONTRACT TYPE STRUCTURE data before entering into a physical contract, the relationship between the CONTRACT STRUCTURE and the CONTRACT TYPE STRUCTURE should be altered to be mandatory (on the CONTRACT STRUCTURE side).

Contract Variables and Their Assignment

Quite often modeling derivative contracts involves associating those contracts with a variety of parameters or variables. The importance of these variables is immense; often they almost single-handedly decide the outcome of a given financial contract. Maintaining these variables is of paramount importance to financial data modelers, and their design should be approached with great care. For instance, the following variables may be of use:
  • Particular geographic region precipitation level

  • Particular geographic region average weekly, monthly, or daily temperature

  • Implied volatility values

  • LIBOR1 and risk-free interest rate

You may be wondering why an investor would be interested in knowing temperature and precipitation levels. If the investor is involved in an agricultural contract, he or she will be very interested to know whether a drought is expected in a particular region and what percentage of his or her crop may be affected.

As an alternative to hard coding these variables into the application code, the model depicted in Figure 3-9 solves this problem with a more elegant, dynamic approach.2 The many-to-many relationship between a given CONTRACT and a VARIABLE is resolved with the help of a VARIABLE ASSIGNMENT intersection entity. Here we can dynamically specify the variables to be used to valuate our contract and determine its outcome.

A SUGGESTED VARIABLE ASSIGNMENT intersection entity resolves the many-to-many relationship between a VARIABLE and a CONTRACT TYPE. The purpose of this entity is to suggest variables that a given contract type might require. You can treat the entity as a suggestion because the relationship between the SUGGESTED VARIABLE ASSIGNMENT and the VARIABLE ASSIGNMENT is nonmandatory on both sides. Your requirements will direct you on how to model this relationship. If necessary, you may make this relationship a mandatory one to enforce the business rule that each variable assignment must be suggested by a suggested variable assignment. A VARIABLE OBSERVATION entity stores the actual variable observations recorded at a specific date and time. The two relationships coming out of the VARIABLE OBSERVATION are mutually exclusive, as you may only physically observe either a contract-assigned variable (via a VARIABLE ASSIGNMENT) or a variable specified via a SUGGESTED VARIABLE ASSIGNMENT.
Figure 3-9.

Modeling variables

Business Strategy

This section considers an entity called BUSINESS STRATEGY (see Figure 3-10). A business strategy outlines a set of actions directed toward maintaining a given company’s competitive advantage. Alternatively it may be viewed as a method a company might use to improve its bottom line. Quite often, practitioners must model a business strategy within the context of a particular financial contract. A SETTLEMENT STRATEGY and a CONTRACT MARKET ASSESSMENT are two examples of business strategies. The set of action items required to execute a particular BUSINESS STRATEGY are outlined in the BUSINESS STRATEGY ACTION ITEMS. These rules often become a set of standard operating procedures (SOPs) that guide businesses on how to proceed and which steps to take under certain conditions.

Consider the SETTLEMENT STRATEGY. BUSINESS STRATEGY ACTION ITEMS may outline the necessary steps an organization must perform to terminate a particular contract, including the steps required to accept an inbound delivery. Accepting a delivery is an extremely complicated process, requiring the cooperation of numerous parties. For instance, to accept delivery from a counterparty, an organization must:
  • Arrange the transportation of assets to a final destination.

  • Identify the individuals who are to be responsible for certain activities.

These details must be outlined well in advance to prepare the organization to accept deliveries from outside sources.

As a critical piece of every business, a business strategy must be authorized before it is implemented. The BUSINESS STRATEGY AUTHORIZATION lists the parties who have authorized a particular BUSINESS STRATEGY and the dates corresponding to when such authorizations took place.
Figure 3-10.

Introducing business strategy and business strategy action items


To minimize the risk of a default, parties participating in a financial contract are usually required to make a collateral deposit with a third party. A collateral deposit is not a requirement, however, and both parties have to agree to it. Sometimes only one party, the party with the lower credit rating, will be obligated to make a deposit. Who makes a deposit and the amount and form of that deposit will be negotiated by the parties entering into the contract. Collateral is used to protect contract participants against a default. The simplest collateral schema obliges contract participants to deposit money only once, on the contract start date, without any additional deposits required. A more complicated collateral schema may involve measuring market fluctuations and requiring the contract participants to make additional deposits, sometimes even daily, to reflect any market shifts.

Figure 3-11 depicts a basic collateral data model. To keep it focused and simple, this figure lists only those entities that contribute meaning to the current discussion. The important thing to note is that the COLLATERAL is related to the actual physical assets. The relationship between the PARTY and the COLLATERAL helps us identify any third party who might be temporarily holding any physical assets referenced in the contract. According to our model, the third party may be either a PERSON or an ORGANIZATION.

Consider the following hypothetical example. Two companies, A and B, have agreed to enter into a financial contract and make collateral deposits. The terms of this contract are as follows:
  • Company A agrees to purchase a ton of copper from company B for US$10,000.

  • The contract start date is June 1, 2014, and the contract expiration date is December 1, 2014.

  • Both companies agree to deposit US$10,000 each (the collateral deposit) with a third company, C, for the time period between June 1, 2014, and December 1, 2014.

In this case the simplest collateral schema is chosen, and the collateral payments are deposited only once.
Figure 3-11.

Model of forward contract collateral

Contract Delivery

Modeling contract delivery (Figure 3-12) involves the DELIVERY entity and its associated subtypes, including the following:



Figure 3-12.

Subtyping delivery

Whenever one delivers an asset to fulfill a given contract (either fully or partially), one makes an outbound delivery. Whenever one receives an asset that fulfills (either fully or partially) a given contract, one accepts an inbound delivery . Cash settlement is another subtype of delivery that plays an important role in settling financial contracts. A large percentage of financial contracts can only be settled in cash. Note that in all of these cases (whether cash settlements or inbound/outbound deliveries), at least one physical asset is received.

The most important reason for subtyping the delivery entity is legal. The association of a given contract with a delivery subtype is pertinent when questions arise regarding the legality of certain delivery methods. All contracts, especially financial ones, may have legal repercussions. Models should reflect and enable reconstruction of every legal nuance, no matter how minor. Delivery subject area is a critical piece of the legal puzzle, and great care should be taken to describe and model it properly.

Another interesting aspect of the delivery subject area is the concept of partial deliveries. Partial deliveries occur when the buyer receives only a part of the agreed-upon quantity of items. For example, investor A might expect to receive 10 tons of aluminum bars by a certain date. The counterparty, investor B, may only be able to deliver nine tons of aluminum bars by that date. In most cases, investor A will hold off paying investor B until the full quantity (10 tons) has been delivered.

Your underlying business rule may allow for partial deliveries, in which case you may be called on to model them. The model in Figure 3-13 shows you how partial deliveries may be modeled by using what should by now be the familiar one-to-many recursive relationship. (Note that the CASH SETTLEMENT subtype from this model is removed to keep things simple.) The main reason partial deliveries are not that common in practice is that warehouse and transportation costs are high. Modern economic theory teaches that there’s no such thing as a "free lunch" and someone always has to pick up the resulting tab (and most financial contract participants are reluctant to do so).
Figure 3-13.

Modeling partial deliveries

Figure 3-14 models the contract’s delivery subject area. (For clarity and simplicity, entities not related to the current discussion are not included in the figure.) Those activities executed on behalf of a given contract are stored in the CONTRACT ACTIVITY. These contract activities are specified by BUSINESS STRATEGY ACTION ITEMS, which in turn are identified by a BUSINESS STRATEGY. The SETTLEMENT STRATEGY, a subtype of the BUSINESS STRATEGY, is explicitly dedicated to dealing with the contract’s settlement, and outlines the necessary steps to effectuate that settlement. SETTLEMENT RELATED ACTIVITY, a subtype of the CONTRACT ACTIVITY, groups together all of the settlement activities performed on behalf of the given CONTRACT.
Figure 3-14.

Contract delivery

SETTLEMENT RELATED ACTIVITIES may result in the actual DELIVERY of the physical assets. Delivery, within the context of a given contract, may mean a number of things. The most familiar example is when an exchange of assets takes place: one party delivers a ton of copper (an asset) and receives another asset in return (cash, for instance). Sometimes a given contract results in a cash settlement. Under a cash settlement, one party pays its counterparty a certain amount of cash based on the price difference between the amount agreed upon in the contract and asset’s current market price (called the asset’s spot price).

A SITE associated with a DELIVERY may be a physical address (thus specifying a delivery address). For example, when a party delivers corn to a particular warehouse, the SITE will identify its location (or a physical address).

Contract Regulations

A contract is a promise, and promises are often broken. A potential end result of a broken promise is a lengthy lawsuit (Figure 3-15).
Figure 3-15.

Modeling contract regulations

Consider the following scenario. Farmer A decides to purchase a cow from farmer B, and they sign a contract. Farmer A inspects farmer B's cattle and both farmers agree on a particular cow. Moreover, both farmers agree that the cow in question is sterile and settle in writing on the following terms:
  • Method of payment (cash)

  • Payment amount ($0.90 per pound)

  • Delivery date

On the delivery date, farmer B realizes that the cow in question is actually pregnant and refuses to deliver it unless farmer A pays more for it. Farmer A refuses and files a lawsuit. Even though this is a relatively straightforward contract breach, the lawsuit outcome may not be so certain. For instance, if both farmers have subscribed in the contract to the mistaken material fact that the cow in question is barren, the court may consider this fact and side with farmer B.3

A contract may violate some type of REGULATION (subtyped into a STATE REGULATION or a FEDERAL REGULATION). For example, investor A may have violated federal law in the past and is now prohibited from entering into any type of financial contract until time T2. If this investor then enters into a financial contract before T2, the contract may be invalidated by federal regulators. You may be called on to model such situations (Figure 3-15).4


This chapter introduced basic concepts of financial contracts that the subsequent chapters on financial engineering data modeling will continually draw on.

Recommended Readings

Hay, David C. Data Model Patterns: Conventions of Thought. Dorset House, 1995.

______. Data Model Patterns: A Metadata Map. Morgan Kaufmann, 2006.


  1. 1.

    The London Interbank Offered Rate (LIBOR) is the rate of interest at which one bank is prepared to deposit money into another bank.

  2. 2.

    Figure 3-9 evokes David C. Hay’s work on modeling variables in various industries set forth in his pioneering books on modeling patterns listed in the “Recommended Readings” section of this chapter.

  3. 3.

    This hypothetical case is based on Sherwood v. Walker (66 Mich. 568, 33 N.W. 919, 1887), which was seminal in the evolution of the doctrine of mutual mistake in U.S. contract law.

  4. 4.

    Figure 3-15 draws on David C. Hay’s work on modeling patterns for “loss events” and regulations in the context of work orders set forth in his books on modeling patterns listed in the “Recommended Reading” section of this chapter.

Copyright information

© Robert Mamayev 2013

Authors and Affiliations

  • Robert Mamayev
    • 1
  1. 1.NYUS

Personalised recommendations