To provide a foundation for the rest of this book, this chapter defines the terminology and discusses the basics of financial contracts.
KeywordsBusiness 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 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.
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
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.
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.
Modeling Contract Asset Allocations
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.
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.
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
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.
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.
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.
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.
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.
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.
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).
Method of payment (cash)
Payment amount ($0.90 per pound)
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.
Hay, David C. Data Model Patterns: Conventions of Thought. Dorset House, 1995.
______. Data Model Patterns: A Metadata Map. Morgan Kaufmann, 2006.
The London Interbank Offered Rate (LIBOR) is the rate of interest at which one bank is prepared to deposit money into another bank.
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.
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.
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.