Data Model 521

Infinity Platform™ v5.
2
Infinity Data Model
Developer’s Guide
CONFIDENTIAL
© Copyright 1997 Infinity Financial Technology, Inc.

Infinity Platform v5.2 Data Model Developer’s Guide
September 1997
Notice
Infinity Financial Technology, Inc. (Infinity) reserves the right to make changes to this publication at any time
and without notice. Infinity makes no warranties, expressed or implied, in this publication. In no event shall
Infinity be liable for any indirect, special, incidental or consequential damages arising out of purchase or use
of this publication or the information contained herein.
Copyright
Unpublished work, Copyright Infinity Financial Technology, Inc. ("Infinity"). This publication and the soft-
ware described within it ("Materials"), constitute proprietary and confidential information of Infinity and its
suppliers. The Materials (and any information or material derived therefrom) may not be reproduced or used,
and may not be disclosed or otherwise made available to any person, in whole or in part, except in accordance
with a written agreement with Infinity or as otherwise expressly authorized in writing by Infinity.
Licenses and Trademarks

Infinity, the Infinity logo, Fin++, FinEx, Infinity Platform, Infinity Derivatives, Infinity/FX, Infinity App-
Works and Infinity RiskView are registered trademarks or trademarks of Infinity Financial Technology, Inc. in
the United States and foreign countries. RiskMetrics is a trademark of J.P. Morgan & Co. All other company
or product names are trademarks or registered trademarks of their respective holders.
Infinity Technical Support

If you wish to contact Infinity’s technical support staff, use the appropriate e-mail address from the list below.
These addresses ensure that your query is sent to both your local representative and to the main Help Desk in
Mountain View.
Americas ny_helpdesk@infinity.com
Asia, Australia, Pacific tokyo_helpdesk@infinity.com
Europe, Middle East, Africa emea_helpdesk@infinity.com
If you wish to reach the Help Desk via telephone, please contact your local Infinity representative. When your
local office is closed, please call the main Help Desk at (415) 940-6100.
Manual written by Arley Lewis, David Mael, and Christopher Gales

Technical assistance provided by David Hyatt
Infinity website: http://www.infinity.com

Table of Contents
Chapter 1: Infinity Data Model Overview
Warehouse for Infinity Applications 1-1

Infinity System Schematic 1-2
About This Manual 1-3
Chapter 2: Understanding Relational Data Models
Database Management Systems 2-1

Relational Models 2-1
Data Tables 2-2
Key and Non-key Attributes 2-4
Primary Keys 2-4
Foreign Keys 2-5
Parent-Child Relationships 2-5
Cardinality 2-5
Indentifying and Non-identifying Relationships 2-5
Associative Entities 2-7
Role Names 2-8
Recursive Relationships 2-9
Normalization 2-9
Denormalization 2-10
Chapter 3: Data Model Organization
Functional Areas of the Database 3-1

Datatypes 3-3
Naming Conventions 3-4
Indexes 3-8
Unique Index 3-8
Clustered Index 3-8
Non-Clustered Index 3-8
Composite Index 3-8
Chapter 4: Modeling Employees and Organizations
Modeling employee/organization relationships 4-1

An entity-level employee/organization relationship 4-1
Modeling a many-to-many relationship 4-4
Other organization relationships captured in the Infinity Data Model 4-7
Modelling legal or non-legal status 4-7
Modelling “us” versus “them” 4-8
Modelling the processing org 4-8
Modelling relationships between organizations 4-9
The auth_b and auth_id table columns 4-9
Chapter 5: Foundation Tables
A note on domain and list tables 5-1

Providing Domain Data 5-1
Columns in the infsys_montage_domains and
infsys_montage_lists tables 5-2
Specific domain purposes 5-2
Using domain values to maintain data integrity 5-10
Providing List Data 5-11
Modifying an existing list value 5-14
Using list values to maintain data integrity 5-14
Quote Tables 5-14
Providing unique identification numbers for saved entities 5-15
Seed tables in v5.2 5-15
Overview of the v5.2.1 changes 5-15
Impact of the new seed structure in v5.2.1 5-16
Why Infinity has consolidated the seed tables 5-17
Performance gain from the consolidated seed generation structure 5-20
Seed bucket generation algorithms in v5.2.1 5-21
Seed Tables in v5.2 5-22
Extending the Infinity Data Model 5-24
Chapter 6: Holiday Tables
Defining Holidays with the hol_header Table 6-1

Attributes of the hol_header table 6-2
Offset Days 6-2
The hol_data Table 6-3
Querying the hol_data and hol_header Tables 6-3
Defining a New Holiday Rule 6-4
Removing a Holiday 6-6
The hol_type_domain 6-7
Chapter 7: Transaction and Trade Tables
Transactions, Trades, and Trade Legs 7-1

portfolio / trans / trade / sec / flow 7-2
The Difference Between Transactions and Portfolios 7-3
Tables Discussed in this Chapter 7-3
The transaction table 7-4
The trade table 7-5
Creating the two trade_leg tables for this trade 7-7
Modeling an Organization’s Participation 7-8
At the trade level 7-8
At the trade leg level 7-9
Assigning each trade leg to a book 7-9
Recording pricing information for a trade 7-11
Assigning settlement instructions to a trade 7-11
Other useful trade-related tables 7-12
Chapter 8: Security Tables
About This Chapter 8-1

The Security Tables’ Three-tiered Structure 8-1
sec and related tables 8-2
Security header tables 8-3
Flow tables 8-5
The sec Table 8-6
The columns of the sec table 8-6
Example using the sec table: a vanilla swap 8-8
Security Tables Related to sec 8-8
The sec_hol_city table 8-8
The sec_quote table 8-10
Examples of the sec_quote table: 8-11
The sec_recalc_lock table 8-12
The sec_relative table 8-13
Swaps and the swap_leg_header table 8-14
General identification fields in the swap_leg_header table 8-17
Amortization (amort_) fields in the swap_leg_header table 8-19
Payment (payment_) fields in the swap_leg_header table 8-19
Compounding (compound_) fields in the swap_leg_header table 8-20
Flow Calculation (flow_calc_) fields in the swap_leg_header table 8-21
Reset (reset_) fields in the swap_leg_header table 8-22
Reference index (ref_index_) fields in the swap_leg_header table 8-23
Simple Swap Structures in the swap_leg_header table 8-25
Index Amortizing Swaps and the swap_leg_index_amort_header table 8-29
Bonds and the bond_attribute and bond_header tables 8-31
Caps and Floors and the cap_floor_header table 8-34
Exchange-traded Securities and the exchange_header table 8-37
Money Markets and the money_market_header table 8-42
OTC Options and the otc_option_header table 8-44
Bond Repurchase Agreements and the repo_header table 8-47
Chapter 9: Flow Tables
The flow Table 9-2

General identification flow fields 9-3
Interest rate and index-related flow fields 9-4
Option-related flow fields 9-5
Using the flow_calc_reset table 9-6
Using Flow Tables 9-6
Simple Principal Flows 9-7
Fixed Interest Flows 9-8
Exchange Flows 9-9
Floating Interest Flows 9-10
Option-related Flows 9-12
Chapter 10: Reference Index Tables
The infsys_montage_lists Table 10-2

ref_index_list 10-2
ref_index_source_list 10-2
The ref_index_attribute Table 10-3
The ref_index_hol_city Table 10-4
The ref_index_term_source Table 10-4
The ref_index_quote Table 10-5
Reference Index Relationships 10-6
Chapter 11: Curve Tables
Curve Definitions and Representations 11-1

Separating Data From Definitions 11-2
The curve Table 11-3
Attributes of the curve table 11-3
Curve Header Tables 11-5
Interest curves and the curve_interest_header table 11-5
Basis curves and the curve_basis_header table 11-7
Volatility curves and the curve_volatility_header table 11-9
Repo curves and the curve_repo_header table 11-10
Curve Data 11-13
Curve Definitions: Simple, Derived, and Dependent 11-15
The curve_def_simple table 11-15
The curve_def_dependent table 11-17
The curve_def_derived_sec table 11-18
The curve_def_derived_curve table 11-20
Curve Holidays 11-20
Chapter 12: Volatility Surface Tables
Volatility Surface Definitions 12-1

Storing volatility surfaces in the tables 12-2
Chapter 13: Portfolio Tables
Portfolio Definitions: Dynamic and Static 13-1

Using the Portfolio Tables 13-3
Using the portfolio table to define a portfolio 13-3
Using the portfolio_def table to define a portfolio 13-4
Storing portfolio definitions in the portfolio tables 13-4
Application Interaction 13-5
Chapter 14: Risk Report Tables
Overview 14-1
Purpose 14-1
Sybase / isql 14-1
Further documentation 14-1
A note on Data Model versions 14-1
Running Scenario Builder from the command line 14-2
Purpose 14-2
Command line mode 14-2
Output 14-4
Basic queries 14-5
The risk_batch_run_id number 14-5
Looking for a risk report 14-5
Looking for the parameters used in report generation 14-8
Looking for the curves used in report generation 14-8
Scenario definitions 14-8
risk_batch_def 14-8
Custom development 14-9
Changing portfolio names in a scenario 14-9
Changing base counterparties 14-10
Changing risk parameters 14-11
Chapter 15: Access Permission Tables
Granting an Infinity application login to a new user 15-1

Assigning a user to a group 15-1
Specifying the password policy for a user 15-2
Assigning permissions to a group 15-3
Appendix A: Data Model Changes in the 5.2.1 Release
Changes to Index and Key Definitions in v5.2.1 A-1

Removal of unused indexes in v5.2.1 A-2
Redefinition of the primary key on sec_hol_city in v5.2.1 A-2
Setting a limit on the number of rows per page for sec_hol_city A-3
Appendix B: Data Model Administration
Purpose and contents B-1

Versions B-1
Infinity version B-1
RDBMS version B-2
Other resources B-2
SQL debugging flag B-2
Static Data Manager B-2
Database tables included in the GUI B-3
The auth_status table B-3
The w_sec_denormal table B-3
The trader_book_authorization table B-4
Speed buttons: trader_accel and exchange_blotter_accel B-5
Database tables excluded from the GUI B-6
primary_business_entity B-6
FX settlement term: sec_settle_sec_city_spot B-7
FX quote precision: sec_settle_sec_tick_size B-7
The trading_book table B-9
Customer Information Manager: Classification, Account Manager
District, Internal SIC Code, SIC Code B-9
Back office configuration tables B-10
Front office database tables to prune B-10
Curve-related tables B-10
Trade and transaction-related tables B-12
Security-related tables B-14
Volatility surface-related tables B-15
Risk report tables B-16
Back office tables to prune B-17
expected_xfer B-17
general_ledger_post B-17
Sample scripts B-17
Deleting non-end-of-day security quotes B-17
Appendix C: Suggested Reading
Other Infinity Books C-1

Books on Relational Data Modelling C-1
Appendix D: Glossary of Relational Modeling Terms
Index
Chapter 1
Infinity Data Model Overview
The Infinity Data Model is the foundation of Infinity’s family of products for
derivatives trading. The Infinity product family is based on a client-server architecture
that combines object-oriented programming techniques and relational database
technology.
The Data Model is designed to expand easily to accommodate new financial

instruments. In-house systems developers can use the existing data tables or add new
tables to the Data Model to house new derivative instruments.
The extensibility of the Infinity Data Model gives clients the ability to expand the
scope of their trading system as new financial instruments are created and as business
moves into new areas.
Warehouse for Infinity Applications

The Infinity Data Model serves as a warehouse for data created through Infinity’s suite
of applications and the C++ Financial Class Libraries (“Fin++”). These are programs
that provide dealer support, risk management, and operations processing for swaps,
caps, floors, FRAs, bonds, repos, futures, money markets, options, swaptions, and FX.
They include:
• Structuring, pricing, and hedging interest rate derivative transactions
such as swaps, caps, bonds, FRAs, money markets, swaptions, and
FX arbitrage;
• Building and managing interest rate curves;
• Building and managing volatility surfaces;
• Measuring and consolidating risk management across multi-
instrument, multi-currency portfolios;
• Managing rate resetting and payment calculations;
• Creating and amending holiday information;
• Managing organization and counterparty information for a full range
of back office applications.
version 5.2 Warehouse for Infinity Applications 1-1

Infinity System Schematic
Infinity currently ships on the SYBASE and Oracle relational database management
systems (RDBMS). The following schematic outlines the relationships between the
RDBMS, the Infinity Data Model, the Fin++ Class Library, the Infinity applications,
existing systems, and any new custom applications an institution may wish to build.
Infinity’s applications use the Fin++ Class Library to interact with the Data Model.
Custom application development can be done using Fin++ or any other development
tools encapsulating methods of database interaction. The Data Model can also store
data from existing systems for use in Infinity applications and custom applications.
Figure 1-1 Infinity’s system
1-2 Infinity Data Model Overview Infinity Data Model Developer’s Guide
About This Manual
The Infinity Data Model Developer’s Guide describes the use and design of the tables
and relationships in the Infinity Data Model. It does not provide step-by-step
instructions for building applications.
We strongly recommended that every developer read, at a bare minimum, the chapters
concerned with the database organization and the foundation tables before delving
into the modeling of securities. It would be difficult for anyone to simply start
populating or altering tables without understanding the conventions used in the
database and the accompanying documentation.
The chapters are organized in the following order:
• Chapter 1, Infinity Data Model Overview, provides an introduction

to the Data Model and explains its function within the Infinity system.
• Chapter 2, Understanding Relational Data Models, explains the

fundamental concepts of relational data modeling. Those experienced
with relational data models may want to skip this chapter.
• Chapter 3, Data Model Organization, explains the design of the

Infinity Data Model, detailing the different functional areas of the
database and showing how they relate to one another.
• Chapter 4, Modeling Employees and Organizations, steps through

the development of one section of the database: the employee and
organization tables. The fine level of detail makes this chapter useful
for relational model novices.
• Chapter 5, Foundation Tables, explains the use of the foundation

tables: the domains, lists, quote tables, and seed tables. This chapter
also lists some important issues to keep in mind when customizing
the Data Model.
• Chapter 6, Holiday Tables, shows how the holiday schedules for

different financial centers are modeled in the database.
• Chapter 7, Transaction and Trade Tables, describes the modeling of

financial transactions in the Infinity Data Model, detailing the tables
which are used to store information on transactions, trades, and trade
legs.
• Chapter 8, Security Tables, describes the tables of the Data Model

used to store the properties which characterize each security.
• Chapter 9, Flow Tables, shows how securities are broken down and
modeled as collections of cash flows.
version 5.2 About This Manual 1-3

• Chapter 10, Reference Index Tables, describes the tables used to
store information about interest rate indexes and past index values.
• Chapter 11, Curve Tables, shows how curves of all types — discount
factor, yield, forward, zero, volatility, and basis — are modeled in the
database.
• Chapter 12, Volatility Surface Tables, explains the use of the vs_
tables to model simple volatility surfaces and tenor spread surfaces.
• Chapter 13, Portfolio Tables, explains how groups of trades are

modeled in the database for risk analysis.
• Chapter 14, Risk Report Tables, explains how to retrieve risk reports
from the Data Model after you have generated and stored the reports
using the Infinity Risk Manager application or the Infinity Scenario
Builder application.
• Chapter 15, Access Permission Tables, explains how to user access

to Infinity application functions is governed in the Data Model.
• Appendix A, Data Model Changes in the 5.2.1 Release, explains

how and why Infinity changed a number of index and key definitions
and set a limit on the number of rows per page for the sec_hol_city
table in v5.2.1.
• Appendix B, Data Model Administration, outlines the maintenance

and manipulation of some Infinity database tables for installations
that use the Infinity applications. This chapter also gives suggestions
for efficient pruning of Infinity databases in order to hold down
database size and increase general performance.
• Appendix C, Suggested Reading, lists suggested readings for further

information about relational data modeling.
• Appendix D, Glossary of Relational Modeling Terms, defines many

of the commonly used terms in this book.
This manual concludes with an index.
1-4 Infinity Data Model Overview Infinity Data Model Developer’s Guide
Chapter 2
Understanding Relational Data Models
This chapter introduces you to relational database technology and data modeling. It
explains relational syntax, the construction of entity-relationship diagrams, and the
representation of information in the Infinity Data Model.
Database Management Systems

Database management systems (DBMS) control the physical storage, retrieval and
updating of data. A DBMS links the physical implementation of a database (numbers
on a disk) to more useful representations of data, such as tables, records, and pointers.
A DBMS interface allows database designers to focus on logical models for their data,
without worrying about the physical encoding of the data in computer hardware and
software. With a DBMS interface, there is no need for a database designer to worry
about address pointers or disk drive allocations.
Relational Models
Relational models are characterized by their simplicity, their high-level language
interfaces, and their ease of modification. Relational models are suited for the
development of neutral conceptual views of information. Many different users,
regardless of their organizational perspective, can make use of the stored data.
Relational models allow efficient access to data. The relational model encodes
relationships implicitly by using what are called shared keys in tables. While other
systems must navigate through pointer structures to find data, relational systems use
more efficient algebraic operations to make database queries.
By implicitly storing relationships between data tables, the relational model gains
data independence — the data model does not need to be altered to suit different
applications.
Maintenance of the relationships between pieces of data is known as referential

integrity. Tables of data referring to other tables must be consistently matched. If one
table is deleted, it is possible that another table, dependent on data found in that first
table, might also need to be deleted. Referential integrity must be verified each time
data is inserted, replaced, or deleted in the database; otherwise there is the possibility
of data loss or error.
version 5.2 Database Management Systems 2-1

Data Tables
Within a relational data model, data is grouped in tables. Each table is formally known
as an entity. What data are grouped into entities? By definition, an entity is any person,
place, thing, event, or concept about which information is kept, like “customer,”
“security,” or “employee.” Entities are simply nouns.
The columns of these tables are called the attributes of the entity. For an entity called
“employee,” typical attributes might be “last_name,” “first_name,” “SSN,”
“street_address,” “city,” “state,” “zip,” and “home_phone.” For an entity called
“security,” typical attributes might be “sec_id,” “description,” “sec_name,” and
“currency_code.” Attributes are thought of as adjectives.
An instance is a single occurrence of a given entity. Each instance is stored as a row in

a table. The row consists of a series of values, one for each attribute. Each instance
must have an identity distinct from all other instances.
The team table (Figure 2-1) has three columns of attributes, and there are four rows of
instances of the team entity. For the remainder of this manual, entity and attribute
names will be identified in helvetica font.
Table name: team
team_name year team_city

Mets 1989 New York
Yankees 1989 New York
Dodgers 1989 Los Angeles
Red Sox 1989 Boston
Figure 2-1. A sample table of values for a team entity, with four rows.
The attributes in this table are team_name, year, and team_city. There are four rows:
one for the instance of the 1989 New York Mets, one for the instance of the 1989 New
York Yankees, one for the instance of the 1989 LA Dodgers, and one for the 1989
Boston Red Sox instance.
All the data values in a table must be atomic; you cannot store lists of values in a
single row. If you wanted to add the fact that the Mets played in New York in 1990,
you could not simply append “1990” to “1989” in the existing row for the Mets. You
2-2 Understanding Relational Data Models Infinity Data Model Developer’s Guide
would have to create another separate row with the information Mets, 1990, New
York, adding that information as a separate instance:
Table name: team
team-name year team-city

Mets 1989 New York
Mets 1990 New York
Yankees 1989 New York
Dodgers 1989 Los Angeles
Red Sox 1989 Boston
Figure 2-2. A sample table of values for a team entity, with another row added for the 1990 Mets.
Suppose we wanted to extend this sample model to include two entities, team and
player. Information you would want to store about a player might include a team, a
year, a name, a uniform number, and a batting average. The entity-relationship model
below depicts these two entities, with boxes summarizing their structure, and a
relationship, “has,” between them. It is read as “A TEAM <has> many PLAYERs.”
The box shapes, black circles, and horizontal lines are all significant; they will be
explained shortly.
Entity names should always be singular. This reminds you that each entity is a single
set of information. It also facilitates “reading” a diagram.
PLAYER
TEAM year (FK)

team_name (FK)
team_name
player_name
year has
player_number
team_city
batting_average
Figure 2-3. A simple relationship between two entities: a TEAM <has> many PLAYERs.
Within the Infinity Data Model, entity relationships are not specifically labeled with
verbs. In conceptualizing data models, the verbs are important features. In actual
implementation, the exact verbs are much less important. Most of the time, the verb
“has” would be appropriate.
version 5.2 Data Tables 2-3

Relational data models are made up, then, of three main building blocks: entities,
attributes, and relationships. Entities are the nouns (team and player), attributes are the
adjectives or modifiers (batting_average, year, etc.), and relationships are the verbs
(“has”).
Key and Non-key Attributes

Within a data model diagram, an entity box is divided by a line into two sets of
attributes: keys and non-keys. The key area is above the line, and the non-key area is
below the line. When viewing data in a tabular format, as in the team table in Figure
2-2, and for the rest of this manual, keys and non-keys are separated by double lines.
Keys are attributes which, either by themselves or in combination with other key
attributes, can uniquely identify an instance of an entity. For an entity like employee, a
single attribute, employee_number, would uniquely identify each employee (assuming
all employees have employee numbers). A last_name attribute might not be a good
key, because many employees could share a last name.
In our previous example, in the team entity, team_name and year are key attributes;
team_city is a non-key attribute. Why is this? Together, each combination of
team_name and year uniquely identifies one baseball team; there was only one 1969
Mets team, only one 1980 Astros team, etc. The team_city is not needed as a key
attribute; once 1969 Mets or 1987 Giants are specified, the respective team_city values
are already known.
In the case of a derivatives-related entity like security, there might not be a ready-
made unique attribute. Creating a unique key is up to the data modeler. Infinity uses
the sec_id attribute as a key attribute in its security table. The sec_id is an integer code
created specifically to uniquely identify each instance of a security.
Primary Keys
Several types of keys are used in relational modeling. Instances are usually identified
by a primary key, abbreviated (PK). An employee row could be identified uniquely by
an attribute called employee_number (or social_security_number). The attribute
employee_number would be a primary key, and it goes in the entity’s key area, with
the (PK) abbreviation.
If an attribute is not marked with any abbreviation, but shown in the key area, it is a
primary key.
Foreign Keys
Whenever entities are connected by a relationship, one entity contributes a key (or set
of keys) to another entity. These are called foreign key attributes (explained below) in
the child table. These keys are said to migrate. They are designated by an (FK)
following the attribute name in the child entity. In Figure 2-3, team_name and
team_year both migrated to the player entity, where they are both foreign keys.
Parent-Child Relationships
Entities are further defined as parent entities and child entities. Parent entities
contribute keys to their child entities. In the preceding example, the team entity would
be the parent entity, and player would be the child entity.
Child entities are also known as dependent entities. Entities that do not get foreign key
data from anywhere else are known as independent entities. Dependent entities are
drawn with rounded corners, and independent entities are drawn with square corners.
Cardinality
The black dot in Figure 2-3 indicates a one-to-many cardinality. A relationship’s
cardinality tells how many instances of the parent entity contribute to how many
instances of the child entity. Sometimes a letter or number may appear next to that dot.
‘Z’ stands for one-to-zero-or-one, ‘P’ means one-to-one-or-more, and a number N
means one-to-exactly-N. The term “many” always means zero or more.
Indentifying and Non-identifying Relationships

A relationship is called identifying when the keys of the parent form part of the
identity of the child; the child is dependent on the parent for its identity. These
relationships are drawn with a solid line connecting the entries.
In the example below (Figure 2-4), employee is a dependent entity (with round
corners), because it took the value of its primary key, employee_number, from a
parent entity. The attribute employee_number would then be a foreign key in the
employee table. The employee number key of the employee entity migrates from a
separate entity, job_applicant.
Note in Figure 2-4 that there are two attributes called employee_number; this
redundancy could be eliminated with the use of role names, as shown later.
Identifying relationships are those in which a part of the parent entity becomes part of
the primary key of the child entity. Non-identifying relationships (drawn with dashed
version 5.2 Foreign Keys 2-5

EMPLOYEE
JOB-APPLICANT employee_number (FK)
resume_number
employee_name
when_received_resume Z employee_gender
becomes
hired_or_not_hired employee_hire_date
employee_number employee_birth_date
employee_bonus_amount
Figure 2-4. A foreign key, employee_number, in a zero-to-zero-or-one identifying relationship.
lines and a hollow diamond at the parent end) exist when a key from a parent migrates
to the data area of the child. There, it is still labeled as a foreign key to indicate that the
data migrates from elsewhere, but that attribute is shown in the non-key area. The
child is not identified by the parent, but it gets non-key data from it.
Sometimes this foreign key data can be NULL in the child entity. This NULL
characteristic is important when maintaining referential integrity. If a foreign key can
be NULL, and if the parent in that non-identifying relationship is deleted, then the
child can still exist. The child does not need the parent for existence or identification.
Suppose, for example, that employee in the example above got its value for
employee_gender from another table, gender_domain, which listed valid options for
gender (‘MALE’, ‘FEMALE’). The relationship between these two tables would be
non-identifying, because the foreign key, employee_gender, is not a primary key.
Instances of employee would still be uniquely identifiable, even if the values of
employee_gender had not yet been entered and were NULL.
Another example of a non-identifying relationship would be one between a passenger

entity and a seat entity (Figure 2-5). A seat gets data from passenger, but instances of
seat still exist even if no passenger has been assigned to them. Contrast this with the
identifying relationship between job_applicant and employee (Figure 2-4). No one can
be an employee without first having been a job applicant.
PASSENGER SEAT
PASSENGER_NAME SEAT_NUMBER
1
FLIGHT_NUMBER (FK)
is
FARE_PAID assigned
PASSENGER_NAME (FK)
Figure 2-5. A non-identifying one-to-one relationship.
Associative Entities
We have seen one-to-many, one-to-zero-or-one, and one-to-one relationships. You can
also model many-to-many relationships, as depicted in Figure 2-6. They are drawn
with dots on both ends of the relationship line. They can be ambiguous, and they often
don’t actually tell you what you want to know. Many-to-many relationships have been
eliminated in the Infinity Data Model.
enrolls in / is taken by
STUDENT COURSE
Figure 2-6. A many-to-many relationship.
From this model, you know that a student enrolls in many courses and that a course is
taken by many students. But even with attributes added to these simplified entities,
there still is no way to know exactly which students are taking which courses and
which courses are taken by which students. This is a non-specific relationship.
Many-to-many relationships are eliminated with associative entities. Suppose we are

modeling people’s addresses. Each person may have many different addresses, each
used for a different purpose: one for billing, one for vacation mail, one for office
deliveries, one for personal mail, etc. Each address might apply to more than one
person; many people might live in the same family or share the same office space.
PERSON ADDRESS
person_id address_id
person_name street_address_detail
may use used by
ADDRESS_USAGE
address_id (FK)
person_id (FK)
usage_type
use_start_date
Figure 2-7. An associative entity, address_usage.
Initially, we might want to model person to address as a many-to-many relationship.

Instead, we create an associative entity, address_usage, as shown above in Figure 2-7.
A person <may use> many address_usages, and an address is <used by> many
version 5.2 Associative Entities 2-7

address_usages. Each address_usage would record why a person might use such an
address, and other details, such as when that address becomes active. Address_usage
would be a record of each instance of the use of an address by a person. The
ambiguous many-to-many relationship is eliminated.
Choosing proper associative entity names can be very important. Why is the entity
called address_usage? One might be inclined to call it person_address. But this
entity is not a person, nor is it an address — what it really represents is the use of an
address by a person and information about that usage. An even clearer name might be
person_address_usage.
In the Infinity Data Model, associative entities include org_org_relation,

ref_index_index_relation, and many others. From these names, you know that the
entities in question are associative entities relating two organizations or two indexes.
Role Names
Role names are new names for foreign key attributes. They simply give new names to
foreign keys; they define the role that the attribute plays in the entity. Role names are
useful for keeping track of the specific role of a piece of data in a given entity, and
they are also needed to organize recursive data structures. They are defined in the
schema with the form: role-name.base-name.
In the example in Figure 2-8, the relationship between team and player is an
identifying one-to-many relationship. The attribute team_id migrates to the key area
of the player entity, where it is a foreign key. There it is given the role name
player_team_id. This role name clarifies the purpose of that attribute; the data in that
field is not the name of just any team, it is the name of that player’s team.
PLAYER
TEAM player_team_id.team_id (FK)

player_name
team_id
has
team_name player_number
batting_average
Figure 2-8. A model of a dependent entity, player, using a role name, player_team_id.
Recursive Relationships
An entity can have a recursive relationship with itself. For example, a company could
be an entity with subsidiaries of more companys. Recursive relationships must be non-
identifying; otherwise, the top company, lacking a parent company, could never exist.
Recursive relationships used to be known as “fish hooks,” because dots used to be

drawn as arrows. Pictures of recursive models then looked like hooks. The arrows
were misleading because they tempted people to interpret relational diagrams as
“flow” diagrams, which they aren’t. Data model diagrams are static representations of
relationships.
COMPANY
company_id
company_name
parent_id.company_id (FK)
Figure 2-9. A recursive model.
Note that you must use role names when defining recursive relationships. Without the
role name parent_id in the example in Figure 2-9, the attribute company_id would be
difficult to track from subsidiary to subsidiary.
In the Infinity Data Model, there are a few recursive relationships. For example, the
cash flow entity, flow, is the parent to other underlying flow entities. In the flow table,
the flow is identified with a flow_id number, and the underlying flow identification
numbers are given the role name underlying_flow_id.
The sec_quote table, used to model the exchange of one security for another, also
contains a recursive relationship. The sec_id identifies the security being traded, and
the settlement_sec_id identifies the security for which it is being exchanged.
Normalization
Normalization guarantees that there is no redundant information in the model. This
characteristic is very important to those who will be using the model to build an
application.
version 5.2 Recursive Relationships 2-9

There are different proper “forms” for data models. Every entity must be in what is
called first normal form. An entity is in first normal form if each of its attributes has a
single meaning, and there is not more than one value for each instance. Listing “1989,
1990” under the year attribute for our old team entity (Figure 2-2) would have been a
violation of first normal form.
An entity additionally follows second normal form if non-key facts can only be
determined by knowing the whole key of the entity. If you only need to know part of
an entity’s key to determine one of the non-key attributes, there is too much
information — a second normal form violation.
If a non-key fact can be known only by looking at another one of an entity’s non-key
facts, there is a third normal form violation. If birthday and age were both non-key
attributes of a person entity, there would be a third normal form violation because you
could know a person’s age by simply knowing their birthday. This case amounts to
indirectly storing the same information twice.
In short, every non-key attribute of an entity should depend on the key, the whole key,
and nothing but the key.
Denormalization
Formal normalization is important, but verifying that the model actually means
something is probably more important. There are other normal forms (fourth, fifth,
etc.) but these are often violated in favor of performance in particular cases. These
violations cause redundancy in the structure, but it can be worth it. Intentionally
violating normal forms in favor of performance is called denormalization.
The table w_sec_denormal is an example of a denormalized table in the Infinity Data

Model. The table violates normal form by duplicating information that has already
been stored in the sec, trade_leg, bond_header, swap_leg_header, and
exchange_header tables. The w_sec_denormal table exists to reduce the time needed
to perform risk analysis (see page 8-2).
Chapter 3
Data Model Organization
This chapter explains how the Infinity Data Model is structured to accommodate the
different types of data used to model trades and groups of trades in a derivatives
trading operation. You will see how portfolios, transactions, trades, and securities fit
together, and you will learn more about Infinity Data Model conventions.
Functional Areas of the Database

The Infinity Data Model can be broken down into the following functional areas:
Address tables store address information to be applied to

organizations and people
Back office tables record the results of back office processing
Configuration tables contain user-configured information that

direct the behavior of some of the Infinity
applications
Curve tables capture discount factor, yield, forward, zero,

volatility, and basis curves
Flow tables model cash flows as organized in securities
Foundation entities entities such as lists, domains, seed tables,

and other static data tables used to store data
pre-packaged by Infinity
Holiday tables list the rules and actual holiday dates for
cities worldwide
Instrument tables record the actual instrument traded
Organization tables store the addresses, payment instructions,

and interrelationships for organizations
Person tables store names, contact information, and

interrelationships for employees
Portfolio tables store definitions of groups of trades
version 5.2 Functional Areas of the Database 3-1

Risk tables tables used to store the parameters for risk
analysis and the resulting risk reports
Security tables store access permissions and other required

security data
System tables tables used for specialized purposes in the

database, not common with any other
functional area
Transaction and trade tables record trades of securities, i.e., “who trades
what with whom”
Working tables denormalized tables used by the Infinity

applications when processing data
3-2 Data Model Organization Infinity Data Model Developer’s Guide

The following diagram (Figure 3-1) is an abstract representation of the Data Model,
radically stripped down to show the relationships between the main tables used to
model a trade. Since this abstraction depicts only a few tables and attributes, it is not
intended for use as an accurate reference guide; it is meant only to introduce some of
the basic relationships.
trans portfolio flow

sec_id
curve_basis_header
trans_id portfolio_name
flow_id curve_interest_header
curve_volatility_header
money_market_header curve
SQL portfolio definition
trade otc_option_header curve_id
swap_leg_header
trade_id
etc...
trade_leg sec
trade_leg_id curve_datetime
sec_id
trade_id curve_id
curve_datetime
trade_leg_org_partic infsys_seed_base_buckets
sec_seed
trade_id sec_id
trade_leg_id
curve_data
partic_type_code curve_id
curve_datetime
curve_offset_day
org
org_id
curve_hol_city
addr city list (from infsys_montage_lists)
city_list curve_id
addr_id city_code city_code
hol_city_code
Figure 3-1. A simplified functional diagram of the Infinity Data Model.
Datatypes
The data in each field of the database must conform to a particular datatype. Building
on the system datatypes char, varchar, int, float, and bool, Infinity scripts construct a
number of Infinity datatypes. The Infinity datatypes can be found in the Infinity Data
Model Quick Reference. For example, the Quick Reference entry:
curve description 1 Description:varchar(50)
tells you that the datatype Description is a string of up to fifty characters, and the word
“varchar” indicates that the datatype is of the Sybase datatype “varchar.” For
version 5.2 Datatypes 3-3

information on system datatypes like “varchar,” consult the documentation supplied
with your database management system.
Keep track of datatypes to avoid invalid database insertions and inappropriate

operations (e.g., multiplying strings).
Naming Conventions
In the Infinity database, the table, column, and datatype names were designed to
provide specific information about what entities are and how they are used. Standard
naming conventions improve the readability of the database and provide guidelines for
the naming of any tables you may add later.
All column and table names use strictly lower case letters. The underbar character “_”
delimits words within a name. These names are printed in helvetica font throughout
this guide.
Infinity datatypes use names of mixed case, to distinguish them from the tables and
columns. They, too, use underbars to delimit words in the name.
The lengths of the names were dictated by limitations of the database system. Some
standard abbreviations are used in table names:
abbreviation description
accel accelerator
act actual
addr address
adv advice
agg aggregate
agmt agreement
alloc allocation
amort amortization
auth authorization
calc calculation
coll collection
config configuration
confirm confirmation
corr correlation
cov coverage
cpty counterparty
db database
def definition
doc document
emp employee
exer exercise

exp expiry
ex_div ex_dividend
frq frequency
func function
fx foreign exchange
gl general ledger
hol holiday
ident identifier
inf Infinity
info information
init initalize
int interest
inst institution
instruct instruction
lang language
mtm mark to market
notl notional
num number
oper operation
org organization
otc over the counter
param parameter
partic participation
p primary
pbe primary business entity
pdh partial differential hedge
perm permission
perturb perturbation
pnl profit and loss
prod product
proj projected
prsn person
rc UNIX configuration file
recalc recalculation
repo bond repurchase agreement
ref reference
reval revaluation
rpt report
sec security
sensitiv, sens sensitivity
stlmt, settle settlement
str string
sys system
version 5.2 Naming Conventions 3-5

temp temporary
tmpl template
trans transaction
unauth unauthorized
val valuation
var value at risk
vol volatility
vs volatility surface
w working table
xfer transfer
ytm yield to maturity
Figure 3-2. Standard abbreviations for database entities.
Table names use a standard set of prefixes and suffixes. Prefixes usually indicate the
general area of table function. In most cases, the meaning is obvious:
table name prefix general function

bond_ bond tables
cap_floor_ cap floor tables
curve_ curve tables
exchange_ exchange tables; refers to futures and exchange-traded
options when used in the exchange_header table, but refers
to places of trade (like CBOT) in the exchange_list table
emp_ employee tables
flow_ cash flows
hol_ holiday data
infsys_ Infinity system tables that govern database operations
money_market_ money market tables
option_ option tables
org_ organization data
prsn_ person data
ref_index_ reference index tables
risk_ risk tables
sec_ security tables
swap_leg_ swap tables
trade_ trade tables
w_ working tables
Figure 3-3. Table prefixes indicating a table’s general function.

There is also a standard set of table suffixes, which also follows a set of rules. These
rules allow you to understand a table’s purpose:
table name suffix purpose; to hold what kind of data?

_attribute attribute data common to a set of entities
_data data derived from header information
_default user-defined default information
_domain domain of appropriate selections (applies to views; not
tables)
_header header or parameter information
_list list of available choices (applies to views; not tables)
_quote quote history of price/yield
Figure 3-4. Table suffixes indicate what kind of data a table may hold.
Attribute suffixes follow sets of rules to help you anticipate the types of data stored in
fields. In Figure 3-5 below, each suffix (or entire column name) is matched with its
corresponding Infinity datatype, as well as the system datatype used to build that
Infinity datatype.
column suffix Infinity datatype system datatype

_amount Amount float
_b Bool bit
_code Code char or varchar
_date Date datetime
_datetime Datetime datetime
_enum Enum int
_id Id int
_name Name varchar
_offset_day Offset_day int
_percent Percent float
_price Price float
_rate Rate float
_recalc_lock Recalc_Lock bit
_term Term int
_value Value float
Figure 3-5. Standard column suffix names (and column names) indicate what kind of data to expect.
version 5.2 Naming Conventions 3-7

Indexes
When attributes are indexed, access to the tables is usually much more efficient when
those attributes are used as search keys. Indexed database searches are binary, rather
than sequential.
The scripts used to create the indexes are listed in the “Scripts: Tables, Primary Keys,
and Indexes” chapter of the Infinity Data Model Reference Guide.
Unique Index
A unique index is one in which no two rows are permitted to have the same index
value.
Clustered Index
In a clustered index, instances of the tables are sorted so that their physical order is the
same as their indexed order. There can only be one clustered index per table, and it is
created on the primary key(s).
Non-Clustered Index
The Data Model provides for a few non-clustered indexes in the database. In these
indexes, the physical order is not the same as the indexed order. The non-clustered
index creates an extra level of data between the index structure and the data itself,
filled with pointers to the rows of data.
For example, a phone book is physically indexed by last names. The last name would
be the primary key, and it would also be the clustered index. If an additional index let
you search by street address, pointing you to the correct pages in the directory, then
street addresses would be a non-clustered index.
Composite Index
The Infinity Data Model specifies some composite indexes, where two or more
column names must be used to search. You would search a phone book file with a
composite index made up of two primary keys, last name and first name.
To see information about a particular table’s indexes, use the SQL command:
sp_helpindex <tablename>

Chapter 4
Modeling Employees and Organizations
In order to model securities and trades of securities, it is first necessary to have some
basic information concerning the organizations and people who are involved in
trading the securities. This information is contained in the organization and person
tables in the Infinity Data Model. Discussing these tables first will lay the groundwork
for understanding the tables dealing with securities and cashflows. It will also provide
a case study showing the logical design underlying the data modeling process.
This chapter traces the development of a relational data model derived from real world
business rules. It should clarify some nuances of relational design and Infinity’s own
design philosophy. After reading this chapter, you should be able to read the Data
Model diagrams and tables, and you should understand how tables are populated with
data.
The other chapters of this manual include fewer details concerning how to populate
tables and why these tables exist; instead, they focus on what information the different
tables and data fields are used to model.
Even if you are confident with relational database technology, you should not ignore
this chapter; it is this manual’s only discussion of employee and organization tables. It
will also further familiarize you with Infinity’s database vocabulary.
Modeling Employee/Organization Relationships

An entity-level employee/organization relationship
A data model is merely a representation of constraints and rules for business behavior.
To model employee/organization relationships, you need to decide exactly what about
these relationships you want to record. Ultimately, for generality, we will model a
more general type of relationship — a person/organization relationship — to take
account of the fact that there may be people related to organizations of which they are
not necessarily employees.
To model relationships between employees and organizations, we will start with the
business rule that an organization employs many employees. There are four basic
parts to this simple rule: organizations, employees, the employment relationship, and
the fact that one organization might be related to more than one employee. In a
relational model, the nouns “employee” and “organization” become entities. The verb
“employ” describes the relationship between the nouns, and the one-to-many aspect of
version 5.2 Modeling Employee/Organization Relationships 4-1

the relationship is modeled with a large black dot on the “many” side of the
relationship.
At a high level of abstraction, this general employee/organization relationship could

initially be modeled like this, in a one-to-many relationship:
organization employs
employee
Figure 4-1. A simple employee/organization relationship.
The model above simply states that an organization employs many employees. To get
beyond this elementary level of abstraction, think about what you specifically want to
know about the employees and organizations. Much of this data, such as addresses or
phone numbers, serves to define a given employee or organization. These are the
descriptors, or adjectives, that could serve as attributes in our employee and
organization tables. However, the fact that addresses and phone numbers can apply
equally well to organizations and people suggests that, in fact, address information
should be broken out into a separate table.
To go further, suppose that we know we want to store, for each employee, a first, last,
and middle name, as well as an employee identification number and a job type
designation. Employee tables could be populated with this information.
However, it could be difficult to generalize these data. For example, what should be
done for people who are entered into the database, but are not employees? They, too,
would need to have their names entered and would need to be tracked by some type of
unique id (In this book and in the Infinity Data Model, the term “id” refers to a unique,
integral identification number assigned to each instance of an entity). This suggests
that the employees should first be entered in a more general person table before being
entered in a more specific employee-person table.
These are the types of logical considerations that lead to the development of the
Infinity Data Model schema. In the case of employees, these considerations are
resolved by creating two tables, a prsn table, and an emp_prsn table. The table prsn
will contain all people in the database, along with their names and a unique prsn_id
providing a retrieval key. For those people who happen to be employees, they will also
be entered in the emp_prsn table, where they will be retrieved by the same key, here
called the emp_prsn_id. A person that is not an employee such as a counterparty
contact would be listed in the prsn table, with a unique prsn_id, but not in the
emp_prsn table. Thus, there will be less rows in the emp_prsn table than there are in
the prsn table.
Because the emp_prsn table only contains information about employees, it can be
used to store information that we do not need to store for every person in the database,
4-2 Modeling Employees and Organizations Infinity Data Model Developer’s Guide
such as an employee identification number (emp_num in Figure 4-2 below) and a job
type designation (emp_type_code below).
prsn emp_prsn
prsn_id (PK) emp_prsn_id (PK)

first_name org_id (PK)
middle_name emp_type_code
last_name emp_num
Figure 4-2. Attributes of the prsn and emp_prsn tables.
As an aside, note that the above figure and all figures in this chapter do not include
every column included in the corresponding table in the Infinity Data Model. For
example, the prsn table has a few more columns than noted above. To include every
column might clutter the figures needlessly. For completeness, later in this chapter we
list every column in every table depicted here. Also, the Infinity Data Model Quick
Reference gives a complete listing of every table described here and elsewhere in this
book.
Organizations are modeled in the org table, where each record is identified by a unique
identification number. The org_id constitutes the entire primary key (also referred to
as “PK”) of the table. The org table also includes several attributes to store the
organization’s name plus a short name (an abbreviated name short enough to fit in the
selection menus displayed by the Infinity applications).
Since we have created the emp_prsn table to house employee-related information, we

no longer need to make every prsn a child of the org table. Instead, each person who
happens to be an employee has his or her employee-related information modeled in an

instance of the emp_prsn table, which is a child of an org instance. A first cut at
modeling the relationships that we have spelled out will look like this:
prsn
prsn_id (PK)
first_name
middle_name
last_name
emp_prsn
org
emp_prsn_id (PK)
org_id (PK) employs
org_id (PK)
name
emp_type_code
short_name
emp_num
Figure 4-3. Relationships between the organization, emp_prsn, and prsn tables.
Looking at the preceding diagram, we can see that the emp_prsn table performs
another task in addition to modeling employee-related information. It also helps to
resolve the dilemma of associating many prsn instances with many org instances.
Since the primary key of the emp_prsn table is made up of the key attributes from the
org table and the prsn table, the emp_prsn table records which persons work for which
organizations.
Modeling a many-to-many relationship
As mentioned at the beginning of this chapter, we also want to model other types
relationships between persons and organizations, even if these relationships cannot be
characterized as employment. Figure 4-3 above shows how the emp_prsn table helps
to resolve the many-to-many relationship between persons and organizations, but the
emp_prsn table handles only employment relationships.
You saw in the previous chapter that many-to-many relationships are vague and non-
specific. With a many-to-many relationship, it would be impossible to tell which
person is related to which organization, and which organization is related to which
person. To avoid modeling such a relationship, we create an associative entity called
prsn_org_relation:
prsn
prsn_id (PK)
first_name
middle_name
last_name
prsn_org_relation
org
prsn_id (PK)
org_id (PK)
org_id (PK)
name
short_name prsn_org_relation_code (PK)
job_func_code
job_title_str
Figure 4-4. An associative entity (prsn_org_relation) models the relationships between persons and
organizations.
To identify the person and organization involved, the prsn_org_relation table includes
the prsn_id, a foreign key migrating from an instance of the prsn table, and the org_id,
a foreign key migrating from an instance of the org table. The table also includes a
code word to indicate the nature of the relationship. This attribute is called the
prsn_org_relation_code and migrates from a list of valid types of person-organization
relationships. The prsn_org_relation_code also contributes to the primary key,
enabling the Data Model to handle multiple relationships between a person and an
organization.
To summarize the relationships described above: all persons have unique ids, and each
person would have a corresponding row in the prsn table. A person’s unique id is the
primary key in that table, stored in the column prsn_id. Persons who are also
employees will also be listed in the emp_prsn table. Their unique id will be the
primary key in the emp_prsn table, stored in the column emp_prsn_id. Persons who
are not employees will not be listed in the emp_prsn table.
Organizations have unique ids, and each organization has a corresponding row in the
org table. An organization’s unique id is the primary key in the org table, and it is
stored in the column org_id. The relationship between an organization and a person is
identified in the prsn_org_relation table.
The following excerpt from the Infinity Data Model Quick Reference offers a more
complete look at the prsn, org, emp_prsn, and prsn_org_relation entities.

Table name
Column name Null Datatype PK FK:Parent Table
prsn
prsn_id 0 Prsn_Id:int(4) PK
first_name 0 Prsn_Name:varchar(30)
middle_name 1 Prsn_Name:varchar(30)
last_name 0 Prsn_Name:varchar(30)
prefix_str 1 Prefix_Str:char(12)
suffix_str 1 Suffix_Str:char(12)
auth_b 0 Bool:bit(1)
auth_id 1 Auth_Id:int(4)
org
org_id 0 Org_Id:int(4) PK
org_ref_str 1 Org_Ref_Str:char(20)
org_name 0 Org_Name:varchar(255)
short_name 0 Org_Short_Name:varchar(20)
trading_unit_b 0 Bool:bit(1)
sequence_number 0 Sequence_Number:int(4)
emp_prsn
emp_prsn_id 0 Prsn_Id:int(4) PK prsn
org_id 0 Org_Id:int(4) PK org
emp_type_code 0 Emp_Type_Code:char(12)
emp_num 0 Emp_Num:varchar(20)
prsn_org_relation
prsn_id 0 Prsn_Id:int(4) PK emp_prsn
org_id 0 Org_Id:int(4) PK emp_prsn
prsn_org_relation_code 0 Prsn_Org_Relation_Code:char(12) PK
job_func_code 0 Job_Func_Code:char(20)
job_title_str 1 Job_Title_Str:varchar(30)
active_b 0 Bool:bit(1)
Figure 4-5. The prsn, org, emp_prsn, and prsn_org_relation tables excerpted from the Data Model Quick Reference.
The preceding excerpt from the Data Model Quick Reference lists all of the attributes
(columns) for each of the four entities (tables) being discussed. For each attribute,
Figure 4-5 lists four types of information:
• a boolean value indicating whether the attribute is allowed to be NULL (0

meaning it cannot, 1 meaning it can). Primary keys cannot have NULL values
in the database, and some non-key attributes might require non-nullable val-
ues. Therefore it is important to recognize the NULL rules when adding new
tables to the database; the non-nullable attributes must be populated with data
when the table is created. These rules are also important when deciding in
what order to create instances of tables; to maintain data integrity, you should
not create a table which takes data from a table which does not yet exist.
• a datatype designation specifying the type and size of data the attribute may
contain. All attributes are datatyped with Infinity types, as well as the native
Sybase types. This contributes to relational integrity and portability.
• the notation “PK” if the attribute contributes to the primary key of the entity.
• the name of the parent table if the attribute is a foreign keys attribute. This is
useful in maintaining relational integrity.
The names of most attributes indicate the information they are intended to store. On
reading the attribute names above, other types of information may come to mind
which do not fit into the available attributes. Additional information concerning
persons and organizations will be stored in separate entities, linked to the prsn or org
entity by foreign key attributes. Separating out this kind of data, which is likely to be
repeated many times, makes the database more flexible and more efficient.
Other organization relationships captured in the Infinity Data Model
Modelling legal or non-legal status
Every organization is either a legal entity or a non-legal entity. Legal entities have a
legal country of residence, and a legal standing as an exchange, a financial institution
or a non-financial institution. Non-legal entities are subsidiaries of legal entities, and
hence have a ‘parent’ organization. Non-legal entities can have non-legals as parents,
provided there exists one non-legal in the organization hierarchy that has a legal
parent.
An example organization structure:
Legal Organization
Legal Child Non-Legal Child
Non-Legal Child Non-Legal Child
The database table legal_entity stores information about legal organizations. The
database table non_legal_entity stores information about non-legal organizations.
version 5.2 Other organization relationships captured in the Infinity Data Model 4-7
Every organization has an entry in the table org, and then also one in either
legal_entity or non_legal_entity.
Modelling “us” versus “them”
The organization tables listed so far are used to model all entities, regardless of
whether they lie internal to your organization, or represent counterparties to it. For
front office activity, this information would suffice. For back office activity, however,
we need a way to distinguish “us” from “them”.
To capture this information, the Infinity Data Model includes the concept of a primary
business entity. The primary business entity, or pbe, is a legal entity within your
organization that has no parents. All entities internal to your organization are
descendents of the primary business entity.
The organization representing your pbe is stored in the table primary_business_entity.

This table has one column, the pbe_org_id. This is a foreign key, migrating from the
org table. As the pbe is also a legal entity, the organization listed in the
primary_business_entity table is also listed in the legal_entity table.
Besides the pbe, some of the other tables in the Infinity Data Model need to
distinguish “us” from “them”. These tables usually contain two columns, one headed
subject_org_id and the other headed object_org_id. With a few exceptions, the
organization listed as subject is an organization within the pbe hierarchy. The
organization listed as object is an organization outside of the pbe hierarchy. All
organization ids in these other tables are foreign keys migrating from the org table.
Modelling the processing org
The processing organization is another concept of interest mainly in back office

processing. A processing organization is responsible for advice generation. A
particular environment may have 1 processing organization, or one organization per
product
The processing organization is stored in the table process_org. Like the pbe_org_id,
the process_org_id is a foreign key, migrating from the org table. This organization
may be either a legal or a non-legal entity.
As there can be multiple processing organizations, each one processing advices for
different products or different child organizations within the pbe hierarchy, we need
some way to capture the relationship between processing organizations and the
organizations they support. This relationship is captured in the table
process_org_coverage.
Modelling relationships between organizations
Some of the organizations contained in the org table have specific relationships to
each other. One organization can be a counterparty to another, a broker for another, or
a nostro agent for another.
If two organizations have any relationship between them, there will be an entry in the
table cpty for which the subject_org_id, object_org_id pair will be identical to the
org_ids of the two organizations. There will also be one or more entries in the table
cpty_role -- one entry to describe each type of relationship. In other words, if one
organization is a nostro agent and also a trading counterparty to another organization,
there will be one entry in cpty and two entries in cpty_role.
The auth_b and auth_id table columns

Most of the tables listed above each contain two columns, one called auth_b, the other
called auth_id. These columns are used to identify whether the corresponding rows in
the table contain authorized information. These same two column headings appear in
most of the other tables that store customer information.
The column auth_b will be a 1 or a 0, depending on whether the information in that

row is authorized or not. Authorized information will be recognized by the Infinity
deal capture and back office applications. Unauthorized information will not. If you
are using the Infinity applications, consult the manuals Customer Information
Manager Reference Guide and Rate Calc Manager Reference Guide for information
on authorizing user-entered data.
The column auth_id identifies a unique row in another table, auth_status. In other
word, auth_id is the primary key in auth_status. The table auth_status stores
authorization information -- who entered the information and when, who authorized it,
and when. As with the separation between prsn and emp_prsn, the Infinity Data
Model has separated the information to be authorized from information about the
authorization itself.
version 5.2 The auth_b and auth_id table columns 4-9

Chapter 5
Foundation Tables
Many tables in the database exist primarily to store data for other tables. These are
called foundation tables and include the domain table, list tables, quote tables, and
seed tables.
Some of the foundation tables come with data pre-loaded by Infinity. All pre-loaded
data is reproduced in the Infinity Data Model Reference Guide.
This chapter also includes a short section on issues you should be aware of when
customizing the Infinity Data Model.
A note on domain and list tables

In previous releases, each domain table and each list table was a separate table.
Beginning with v5.2, however, all domain tables have been collapsed into a single
table, infsys_montage_domains. Similarly, nearly all the list tables have been
collapsed into infsys_montage_lists. Views have been created for backward
compatibility, permitting a table browser to examine, for example, the view
currency_list instead of the table infsys_montage_lists, retrieving only those entries
where list_name = ‘currency_list’. In other words, your old ‘select * from
currency_list” query will still work!
For simplicity, this chapter refers to the domain and list tables individually, instead of
referring to the single infsys_montage_lists or infsys_montage_domains.
Providing Domain Data

Domain data are the valid entries or code values that other tables and applications
understand. Each set of domain values represents the set of all possible codes that can
populate a column. Storing these codes in domains improves the readability of the
database, guarantees data integrity, and facilitates organized extension of the database.
The domains store codes and ranges of acceptable numerical values. The primary key
for each table is a _code value. For example, the primary key of the
curve_usage_domain is curve_usage_code.
version 5.2 A note on domain and list tables 5-1

Columns in the infsys_montage_domains and infsys_montage_lists tables
The infsys_montage_domains table contains five columns: domain_name,

domain_code, montage_group_code, description, inf_enum. The primary key is the
combination of domain_name, domain_code.
The infsys_montage_lists table contains the same columns as the

infsys_montage_domains table, with the exception of the inf_enum table. That is,
there are four columns in infsys_montage_lists.
The domain_name is the historical name of the table where each row in
infsys_montage_domains came from.
The name of the _code column is always based on the domain_name, with the word
“code” replacing “domain.” The _code column contains a word or abbreviation which
identifies the code. This is the value which users see when choosing from a domain in
the Infinity applications.
The montage_group_code column contains a code designed to let you and Infinity
know which instances of the domain table were created by whom. When Infinity ships
the database, every montage_group_code is ‘INFINITY.’ When you start creating
your own codes, you will give them your company’s unique group code. This group
code should be stored in the table infsys_montage_group_code.
The Infinity applications, on start-up, will load all static domain and list data for
which the montage_group_code is INFINITY. To get Infinity applications to load data
for other group codes, the entry in the table infsys_montage_group_code
corresponding to your group code should have infsys_action_code = Load.
Assignment of these codes is helpful for troubleshooting and for guaranteeing

compatibility with any C++ class libraries. Each list table (see page 5-11) also
contains a montage_group_code column.
The description column contains an explanation of that specific code, running up to 50

characters in length.
The inf_enum column contains an integer representation of the code, which can be
used within applications as an enumerated type. The integer representation is designed
to speed application execution, and is used in particular by the Infinity Fin++ Class
Libraries. Be sure not to duplicate inf_enum values when adding your own instances
of domains.
Specific domain purposes
All domains are shipped with pre-loaded data. This data represents the range of code
values that Infinity applications understand. Any changes to the contents of the
_domain table should be done extremely carefully, since the Infinity applications
5-2 Foundation Tables Infinity Data Model Developer’s Guide

depend upon this data. The Domain Table chapter of the Infinity Platform Data Model
Reference Guide reproduces all the domain values shipped by Infinity.
Note that the term_domain is an exception to the rule that you should not add data to
the domain table. Applications users can add instrument maturity terms to the
term_domain table as needed using the Define Term window of Infinity Curve
Manager. Consult the Infinity Curve Manager Reference Guide for information on
using the window.
version 5.2 Providing Domain Data 5-3

The table below describes all the domains. To see the full set of _code values for each
_domain, you would use the SQL statement:
select * from <domain table name>
Table name purpose of the _code stored within
account_type_domain Is used by Back Office processing to indicate types

of bank accounts.
act_notl_domain Specifies whether principal is notional or actually

exchanged.
admin_type_domain Determines user access to tables based on level of

system administrator responsibilities.
advice_status_domain Indicates the status of a trade advice, such as

issued, pending, etc.
analysis_date_type_domain Differentiates fixed analysis dates from relative

analysis dates for risk reports.
auth_status_domain Shows whether or not a record entry is authorized.
auth_type_domain Shows possible types of database activities

requiring authorization.
avg_calc_method_domain Describes the method used to calculate averages:

the actual average, the weekly average, or an
average of the end dates.
bond_type_domain Categorizes foreign government bonds, corporate

bonds, U.S. Treasury bonds, etc.
business_type_domain Differentiates the type of business in which an

organization is engaged.
cap_floor_domain Indicates cap or floor.
compound_type_domain Specifies which compounding method is used for

compounding interest.
curve_archive_domain Determines the historic status of a curve as

erasable or archived.
curve_curve_operator_domain Indicates operation (add, subtract, multiply, or

divide) used to combine two curves.

curve_data_domain Indicates type of data on which the curve is based.
curve_def_domain Describes the method of curve generation.
curve_instance_domain Indicates whether a curve’s data represent the

day’s opening or closing, or intraday values.
curve_int_algorithm_domain Shows whether a derived interest rate curve is

created using the bootstrap, enhanced, or custom
algorithm method.
curve_level_type_domain Defines outright and spread curve.
curve_side_domain Indicates whether curve represents bid, mid, or

offer values.
curve_status_domain This domain is not used; it has been replaced by

the curve_status_list table.
curve_type_domain Indicates what the curve is used for: interest,

volatility, basis, or fx.
curve_usage_domain Describes whether a curve is used for discounting,

forecasting, or measuring volatility.
date_roll_domain Describes date roll convention.
day_count_domain Describes day count basis convention, such as 30/

360, ACT/365, etc.
exercise_domain Describes whether an option is an American-style

or European-style option.
expectation_domain Indicates allowed types of expected transfers: PAY

or RECEIVE. Used by Back Office processing.
expected_xfer_state_domain Indicates state of expected transfer: BOOKED,

UNBOOKED, RESET, or CANCELLED. Used by
Back Office.
expected_xfer_status_domain Indicates status of expected transfer, such as

known or not. Used by Back Office.
expected_xfer_timing_domain Indicates timing of expected transfer: initial or final,

bullet or interim payment. Used by Back Office.

expected_xfer_type_domain Indicates type of expected transfer: simple interest,

compound interest, principal, fee, etc. Used by
Back Office.
flow_calc_domain Indicates how a flow is calculated, e.g. simple

interest, etc.
flow_calc_timing_domain Indicates the timing of a flow calculation, e.g. at the

beginning of a period, in arrears, etc.
flow_rate_calc_domain Indicates how a flow rate is calculated, e.g. from an

index, average of an index, etc.
flow_timing_domain Indicates if the flow is paid at the beginning or end

of a period.
flow_type_domain Indicates if the flow is interest, principal, etc.
frq_domain Describes frequency interval, which may range

from none to per-annum.
fx_swap_type_domain Describes period of a foreign exchange swap.
greek_calc_method_domain Indicates whether option pricing calculations are

done analytically or numerically.
hol_type_domain Indicates whether a holiday calendar applies to

payment or rate-setting.
info_data_type_domain Shows type of descriptive information attached to

an organization: string or integer. Used by Back
Office.
info_db_table_domain Indicates associated relevant table for interpreting

information attached to organizations.
interp_domain Indicates interpolation method: linear, log-linear, or

spline.
lag_day_type_domain Indicates whether to measure time lag in business

days or calendar days.
lang_domain Indicates language used for documents.
loan_event_type_domain Is used to describe types of events in repo trades.

money_market_type_domain Describes kind of money market instrument: LIBOR

note, T-Bill, etc.
month_cycle_domain Specifies monthly cycle for exchange traded

instruments.
option_type_domain Describes kind of options: average, lookback, etc.
otc_option_underlying_domain Indicates whether the underlying instrument is a

security or a portfolio of securities.
partic_side_domain States whether a party to a legal agreement is a

counterparty or the primary business entity.
partic_type_domain Describes participation in a payment, i.e., pay or

receive.
password_use_domain Indicates state of an assigned password: new or

used.
payment_direction_domain Determines if a payment event is payed or

received.
payment_engine_oper_domain Determines the operation of the payment engine

program, when configured based on conditions that
must be satisfied (e.g., hold, activate, etc.). Used by
Back Office.
payment_engine_state_domain Determines the state of the payment engine

program for specific payment actions: pending,
release, terminate, etc. Used by Back Office.
payment_notif_domain Indicates status codes for sending payment

notifications. Includes error codes. Used by Back
Office.
payment_status_domain Indicates status code of payment itself. Typically

corresponds to a state of a payment in the payment
engine: pending, release, terminate, etc. Used by
Back Office.
pnl_decomp_item_domain Identifies the origin of each item in the profit and

loss decomposition report.
pnl_decomp_sequence_domain Describes the sequence used in the profit and loss

decomposition report.
pnl_trade_leg_status_domain Indicates status of a trade leg used in a profit and

loss report.

portfolio_criterion_domain Indicates type of criteria to be used in selecting

trades for a portfolio.
post_operation_domain Indicates type of gll posting: DEBIT or CREDIT

currently the only allowed operations. Used by
Back Office general ledger posting application.
post_state_domain Indicates state of gll posting: POST, REVERSAL, or

REVERSE_POST are only allowed states. Used by
Back Office general ledger posting application.
post_type_domain Indicates type of gll posting. Currently always to the

general ledger. Used by Back Office general ledger
posting application.
proj_flow_date_domain Tells if a projected flow report is done for payment

date or reset date.
put_call_domain Differentiates options, put or call.
quote_history_domain Specifies how frequently you want to store quotes

for a given reference index.
quote_method_domain Stores the method for quoting prices, such as basis

points, 1/32s, etc.
ref_index_relation_domain Defines how two reference indexes might be

combined (averaged, interpolated, etc.) in the
ref_index_index_relation table.
repo_roll_method_domain Used by repo trades to determine whether to roll

principal only or principal and interest.
repo_type_domain Used by repo trades to determine if OPEN, TERM,

etc.
reset_calc_align_domain When averaging rates, tells whether the averaging

period matches the accrual period.
risk_analysis_domain Indicates type of risk analysis, e.g. mark-to-market,

profit/loss, etc. See risk_rpt_domain.
risk_rpt_domain Indicates type of risk analysis report, from the

range of those that can be saved to the database.
See risk_analysis_domain.
risk_rpt_instance_domain Indicates when a risk report was generated, relative

to open or close of a day.

risk_rpt_instruct_domain States how a risk report is dealt with external to the

database: printing, etc.
sec_def_domain Tells how a security is defined and used: as

relative, specific or default.
sec_product_domain Indicates type of security, bond, cap, floor, etc., for

use in setting persistence.
sec_type_domain Indicates type of security, bond, cap, floor, etc., for

use in analytics.
sec_val_domain Differentiates between the forecast and floating rate

note methods of pricing.
settlement_method_domain Tells whether the security is settled in the physical

instrument or cash equivalent.
spread_type_domain Defines whether the spread is a spread to price or

spread to yield.
stlmt_bank_domain Types of banks allowed in settlement instructions.

Used in Back Office.
structure_domain Describes the payment structure of a security:

annuity, bullet, zero coupon, etc.
swap_leg_domain Describes whether a swap leg is the fixed leg,

floating leg, or the present value of a fixed leg.
term_domain Indicates the maturity term of the instrument. This

table is an exception to the rules governing domain
tables since applications users can add instrument
maturity terms to this table as needed, via the
Define Term window of Infinity Curve Manager.
tick_size_domain Describes how large a tick value is, from one unit to
one-1,000,000th.
trade_info_domain Describes the type of trade at the trade level, e.g.

Swap, Bond, etc.
trade_leg_type_domain Tells whether a trade leg is considered the primary

leg or settlement leg for purposes of pricing.
trade_partic_type_domain Describes the role of a participant in a trade,

broker, assignor, assignee, etc.
trade_sec_relation_domain Not currently supported.

trade_trade_relation_domain Shows relation between two associated trades,

such as a buy out or exercised option.
trans_info_domain Gives information on the nature of a complete

transaction, such as spot foreign exchange.
unit_time_domain Describes whether to use a 360 day year or a 365

day year in day counting.
user_acct_status_domain Status of an account: enabled or disabled.
val_delta_calc_domain Indicates whether one-way or two-way shifts are

used in calculating numerical derivatives.
volatility_type_domain Distinguishes flat from forward volatilities.
vs_def_domain Describes the type of volatility surface.
weekday_domain Indicates the day of the week as an abbreviation.
weekend_domain Indicates the weekend convention used for a

trading center, such as Sat. only; Sat. & Sun.; etc.
Figure 5-1. Domain tables and the purposes of the domain codes
Using domain values to maintain data integrity
Note that these domains also serve as the parent tables for foreign keys in many other
tables within Infinity. These foreign key relationships indicate that when you insert or
modify a value in the child table, you must check it against the parent domain table for
a matching value.
For example, the swap_leg_header table includes a column day_count_code. When

inserting or modifying a record in the swap_leg_header table, you must match the
value of the day_count_code column with an entry in one of the day_count_domain
tables. Otherwise, you will lose data integrity.
It is important to remember that there is nothing in the Infinity Data Model to

guarantee data integrity, or to prevent you from violating it. Thus, it is a good idea for
you to put controls in place to ensure no integrity violation occurs.

Providing List Data
The database contains two tables that simply provide lists of data. These list tables are
quite similar to the domains in that they provide the valid set of values that may be
used to populate a given column. However, list values differ from domain values in
that they are not enumerated and can be changed much more freely. Like domain
values, list values are used within Infinity applications, but the usage of a list value
depends solely on its character representation. There are no inf_enum values in the list
tables.
As in the domains, the list data is also represented as character codes. For example,
the city_list table contains codes for various cities: ‘NYC’, ‘LON’, etc.
The list tables are shipped with pre-loaded data. This data represents the range of code
values pre-defined within Infinity. The purposes given below are the purposes of the
codes as they are shipped by Infinity; you may want to add your own codes that
expand on these purposes. Consult the List Tables chapter of the Infinity Data Model
Reference Guide for a complete list of the List Table values shipped by Infinity.
List table purpose of the _code stored within
access_func_group_list Indicates Infinity application to which user access is

controlled.
addr_type_list Describes an address usage: e.g. CHIPS, SWIFT,

mailing address, etc.
advice_type_list Indicates type of advice: payment, trade_ticket, etc.
business_event_list Indicates the type of event affecting a trade:

cancelled, new trade, payment, etc.
city_list Gives a 3-letter abbreviation for the financial center.
contact_type_list Indicates whether a confirmation is to be made by

phone or in writing.
contract_series_list Indicates contract series name for exchange-traded

future or option.
country_list Indicates the country.
cpty_role_list Indicates the role of a counterparty in a trade:

broker, exchange, customer, etc.
cpty_type_list This table is empty when shipped.
version 5.2 Providing List Data 5-11

currency_list Indicates currency, as an abbreviation.
curve_interpretation_list Indicates whether the curve is a base curve or a

spread curve.
curve_status_list Indicates whether the curve is open or locked, for

security purposes.
data_group_list This table is empty when shipped. It is used in Back

Office configuration.
doc_index_list Indicates index criteria for finding and producing

different document types.
doc_tmpl_group_list Indicates allowed templates for automated

document production.
doc_type_list Indicates allowed types of documents to be

produced; e.g., payment advices, trade tickets, etc.
emp_type_list Indicates the employee’s role in an organization.
error_list Indicates type of error in advice handling.
error_severity_list States if recognized error is critical or not.
exchange_list Indicates the exchange on which a transaction

occurs: CBOT, IMM, LIFFE, etc.
info_type_list Indicates type of information associated with an

organization. It is used by Back Office.
infsys_action_list Indicates the actions an application can take with

values keyed to montage_group_codes on start-up
-- load them or ignore them.
issuer_inst_list Indicates issuer of a particular instrument.
job_func_list Indicates job function within an organization.
legal_agmt_clause_list Indicates type of clause added to a standard legal

agreement.
legal_agmt_list Indicates type of legal agreement.

org_addr_relation_list Links the address to an organization by use and

function (e.g., the address used for processing).
org_book_relation_list Indicates the function of a book used by an

organization.
otc_option_sec_usage_list This table is empty when shipped.
payment_type_list Indicates payment type, e.g. SWIFT.
printer_list Indicates printer used for output.
product_type_list Indicates a financial product that may be traded at

the organization.
prsn_org_relation_list Shows the relation between a person and an

organization: e.g. employee.
quote_type_list Describes type of quote: close, high, low, open, etc.
rating_source_list Indicates credit rating service used.
rating_type_list Indicates type of credit rating for an organization.
ref_index_list Indicates interest rate index used: AIBOR, LIBOR,

LUXOR, PRIME, etc.
ref_index_source_list Indicates source supplying interest rate index

quotes.
rtd_mdds_list Indicates the real time feed source.
sec_ident_list Indicates identification code for the instrument:

CUSIP, ISIN, or MLNUM.
status_list Indicates whether a portfolio is OPEN or LOCKED.
trade_attention_list Indicates type of internal attention a trade should

receive.
trade_keyword_list Indicates keyword used to distinguish a trade.
trade_status_list Indicates the status of the trade: assigned, booked,

pending, pricing, etc.
version 5.2 Providing List Data 5-13

trade_type_list Indicates whether trade is a market trade or an

inter-desk trade.
transmission_list Indicates means used to send advice: mail, phone,

fax, SWIFT, etc.
user_group_list Used in configuring user groups for Infinity

applications.
Figure 5-2. List tables and the purposes of the list codes within these tables
Modifying an existing list value
Special care should be taken when changing (and deleting) values in the list tables, in
order to maintain the integrity of the data which has already been entered into the
database. As with domains, there is no check in the data model to ensure data
integrity.
Using list values to maintain data integrity
Note that these list tables serve as the parent tables for foreign keys in many other
tables within Infinity. These foreign key relationships indicate that when you insert or
modify a value in the child table, you must check it against the parent list table for a
matching value.
For example, the hol_header table includes a column city_code. When inserting or
modifying a record in the hol_header table, you must match the value of the city_code
column with an entry in the city_list table. Otherwise, you will lose data integrity.
Quote Tables
Two tables provide histories of quotes pertaining to securities and reference indexes.
These tables end in _quote. The sec_quote table stores a quote history for securities.
Similarly, the ref_index_quote table maintains a history of quotes for reference
indexes. These tables can be populated directly, through Infinity applications, or
through third-party live feeds.
Live feed population of quote tables through the Infinity application Middleman,
available beginning with Infinity v5.2 products, requires configuration of the
corresponding _address table. Specifically, to set up a live feed for specific reference
index values, you need to add rows to the table ref_index_address. To set up a live

feed for specific security values, you need to add rows to the table
sec_quote_address.
Providing unique identification numbers for saved entities

Many entities that are stored in the Infinity Data Model are assigned integer
identification numbers for quick and easy look-up. These identification numbers are
always stored in a database column that ends in _id. For instance, a trade record gets a
trade_id number, a curve record gets a curve_id number, and so on.
Prior to v5.2.1, these id numbers were provided by a set of seed tables, each of which
furnished instances of an entity with unique, sequential numbers. Beginning with
v5.2.1, these seed tables have been dropped, and a different approach for generating
unique numbers has been implemented. Nevertheless, the concept of generating
unique numbers remains the same. If you are using v5.2 of the Infinity Data Model,
see page 22. If you are using v5.2.1 or later, read on.
Seed tables in v5.2
Some database systems build the function of sequential record numbering into their
database engines. However, such a design precludes the portability found in the
Infinity design. The Infinity Data Model provides unique numbering by using
bucketed sequential numbers as identification numbers for database records.
In order to ensure the integrity of the data within Infinity, take care when altering the
tables that implement the number generation scheme in Infinity. These tables include
infsys_dist_seed_bases, infsys_seed_base_buckets, infsys_seed_bases, and
infsys_seed_partitions.
Overview of the v5.2.1 changes
This section explains the details and outcomes of changes made to the seed tables in
version 5.2.1 to address a known deadlocking problem in the Sybase version of the
Infinity Data Model. To this end, Infinity consolidated the seed tables into a more
compact structure and created a stored procedure that provides seed values. Further
measures taken to address this problem included removing and redefining indexes and
by redefining a table, as explained in Appendix A.
Seed Tables Replaced
The seed tables that have been replaced are

account_seed
addr_seed
advice_error_seed
version 5.2 Providing unique identification numbers for saved entities 5-15
advice_init_rule_seed
advice_seed
auth_seed
book_seed
curve_seed
expected_xfer_seed
general_ledger_action_seed
general_ledger_post_seed
general_ledger_rule_seed
hol_seed
legal_agmt_seed
login_failure_seed
model_interface_seed
org_seed
payment_engine_action_seed
payment_engine_rule_seed
payment_request_action_seed
payment_seed
prsn_seed
repo_group_seed
reval_action_seed
reval_rule_seed
risk_batch_run_seed
risk_batch_sec_reval_seed
risk_batch_seed
risk_curve_group_seed
risk_hedge_group_seed
risk_hedge_vehicle_seed
risk_perturb_group_seed
risk_perturbation_seed
risk_rpt_seed
sec_seed
sec_val_data_seed
stlmt_seed
trade_seed
trans_seed
valid_access_func_seed
var_data_seed
vs_seed
Impact of the new seed structure in v5.2.1
The impact of this change in 5.2.1 is minimal. Ultimately, however, there could be
some incompatibilities with work clients have done independently.
In the general scheme, the seed values may no longer be sequential. Any code written
to make use of sequential ids being assigned to consecutive requests will have to be
changed to remove this dependency. In version 5.2.1, however, the ids remain
sequential, because of the existence of sequential id dependencies in some of Infinity’s
code. When this type of dependency is removed from Infinity’s code, some of the ids
will lose their sequential characteristic. This will occur in a release subsequent to
5.2.1.

Of course, all existing client-generated data will still be sequential and will be placed
in the first seed bucket by a future upgrade process. See below for a discussion of seed
buckets.
All Infinity supplied static data has had any relevant seed values reassigned to be
above two billion. All locations in the Infinity Data Model where these values
occurred have been updated accordingly. If a client, however, defined new tables that
contain references to Infinity static data, such as through a sec_id, that data will have
to be updated.
Last, if clients have written their own software making use of the old seed tables, that
code will have to change to make use of the stored procedure, infsp_getseed, that
performs the appropriate steps to obtain the next seed value for a seed base.
Furthermore, it is recommended that any additional seed tables clients have created be
merged into this paradigm, although that is not strictly necessary.
Why Infinity has consolidated the seed tables
Prior to release 5.2.1, a significant deadlocking problem existed in Sybase

implementations among the tables sec, flow, trade, trade_leg, and sec_hol_city. In internal
tests, five concurrent processes were started. Each process submitted hundreds of
transactions typical of a front office production environment, with no pauses between
transactions. These processes are referred to subsequently as the TransDup processes.
In a non-audited environment, the following characteristics were observed:

• Percentage of transactions deadlocked: 57%
• Average time to execute transaction: 18 seconds
To correct this situation, a two-pronged approach was taken. The first tack was to
investigate the deadlocked transactions and determine where the deadlocks were
occurring, i.e. specific data and index pages. To address this part of the problem,
Infinity changed a number of index and key definitions and set a limit on the number
of rows per page for the sec_hol_city table. These changes are detailed in Appendix A.
The second tack involved a redesign of the seed tables. Consider that after the index,
key, and row limit changes, there were still performance and deadlock issues. The
reason is that the primary keys of the affected tables contain an id value from a seed
table. In all of the tables, the primary key was the seed value, or contained a seed
value. These seed values are sequential, which is not good for clustering, and so all the
transactions were serialized, waiting for the transactions ahead to complete.
After consideration of the Sybase white paper, “How Surrogate Primary Key
Generation Affects Concurrence and the Cache Hit Ratio,” (see http://www.sy-
base.com/Offerings/Whitepapers/) several approaches were considered.
One was to take the seed value and reverse the bit order before using it as a seed.
Another was to generate random seed values. Both these approaches were dropped,
however, in favor of using the simpler concept of seed buckets.
Summary of changes to Infinity’s seed generation structure
In essence, what has been done in 5.2.1 concerning seed values is

[1] All the seed tables were consolidated into three tables.
[2] Obtaining the next seed value for a given seed base has been encapsulated into a
stored procedure called “infsp_getseed”.
[3] Each seed base can have an arbitrary number of buckets assigned to it. Note that
for v5.2.1, only one bucket has been assigned to each seed base. Multiple seed
buckets will be introduced in a future release, as explained on page 20.
[4] Each seed base and set of buckets is assigned to a partition.
[5] Ranges of values in consecutive buckets can be optimized to be the maximum dis-
tance apart, set to be adjacent, or customized, within certain constraints.
To see what this means, consider the following three tables with sample data.
infsys_seed_partitions
The first table, infsys_seed_partitions, simply maintains data describing the defined
partitions. The partition_id is used as part of the primary key in the other two tables.
This table is self-explanatory. Note that the zero partition is used for Infinity Static
Data and describes a range of values of seed_bases. This is discussed more below. The
inclusion of the partition concept was done to facilitate the use of replication.
Table name: infsys_seed_partitions
partition_id partition_state partition_description

0 RESERVED Reserved for Infinity Static Data
1 ACTIVE Infinity Default Initial Partition
(In this document, column names to the left of the double line are primary key fields.)
infsys_seed_bases
The next table, infsys_seed_bases, is basically the header table for the various seed
bases within a partition. The example data shown below include entries for ‘sec’
which has multiple buckets and for ‘vs.’ which does not. The number_of_seed_buckets
field, of course, specifies the number of buckets assigned to a seed base. The interval
field is used by the algorithm that produces the variations in the bucket_start field in the
infsys_seed_base_buckets table, and is discussed in Section below. The initial_bucket_id
specifies the bucket to be used first; it is initialized to one. The active_bucket_id is the
most recently used bucket. It is initially zero, but after the first seed value is assigned,
it will cycle repeatedly from one to the number of seed buckets for that seed base. The
bucket_length is the length of the bucket or buckets associated with a seed base within a

partition. Note that the bucket_length for zero apparitions is 147,483,647, which
reserves all values above two billion for Infinity static data for each seed base.
Table name: infsys_seed_bases
number_of_ initial_ active_

seed_base partion_id interval bucket_length
seed_buckets bucket_id bucket_id
sec 0 1 1 1 0 147483647
sec 1 11 6 1 0 10000000
vs 0 1 1 1 0 147483647
vs 1 1 1 1 0 100000000
infsys_seed_base_buckets
The third table is the detail table for the seed bases within a partition. For each bucket
associated with a seed base and partition, the initial seed value in the bucket and the
current seed value in the bucket are specified.
Note the value of 2,000,000,963 for the current bucket value for the zero partition for
the sec seed base. This means there are 963 static data values for sec.
Of more importance are the bucket_start values for the eleven buckets for sec. The
difference in values between any two adjacent buckets is either 50,000,000 or
60,000,000. This is the maximum difference achievable, and is generated by the
Optimal Interval Algorithm using the number_of_seed_buckets and interval values from
the infsys_seed_bases table. The three supported algorithms for generating these
records are given in Section below.
Table name: infsys_seed_base_buckets
seed_base partition_id bucket_id bucket_start bucket_current

sec 0 1 2000000000 2000000963
sec 1 1 0 0
sec 1 2 60000000 60000000
sec 1 3 10000000 10000000
sec 1 4 70000000 70000000
sec 1 5 20000000 20000000
sec 1 6 80000000 80000000
sec 1 7 30000000 30000000
sec 1 8 90000000 90000000
sec 1 9 40000000 40000000
sec 1 10 100000000 100000000
sec 1 11 50000000 50000000
vs 0 1 2000000000 2000000000
vs 1 1 0 0
Implementation schedule for bucketed seeds
In 5.2.1, all seed bases are given a single bucket of length two billion in partition one.
The above example shows eleven buckets for the sec_id. This bucketing will be
implemented in a subsequent release, once the Infinity applications have been
converted. Other ids that will have multiple buckets are curve_id and trade_id, and
possibly others. Each of these will have their bucket ranges determined by the Optimal
Interval Algorithm.
In the future, clients may alter the values after doing an installation by looking at the
populate.csh shell script in $INFINITY_INSTALL/montage/schema/bin. This script
generates the appropriate INSERT statements based on the number of buckets selected
and the interval algorithm chosen. Alterations of the default on an upgrade are much
more difficult and should be done with caution. In version 5.2.1, however, these values
should not be altered.
The stored procedure, infsp_getseed, that the Infinity DBAPI (database application
programming interface) executes to obtain the next seed value for a given seed base,
automatically cycles through all the available buckets. Thus, in the case of sec, in the
above example, consecutive sec_id values will differ by at least fifty million. This
distributes both the data and the indexes across pages rather than having consecutive
transactions store values on the same data and index pages.
Note that clients who have implemented different schemes independently can easily
incorporate their work into this framework. All they need do is convert their method
into a stored procedure called infsp_getseed, give it the same signature as Infinity’s
infsp_getseed, and then replace the provided copy of infsp_getseed with their own.
Of course, no such scheme should be implemented until after the Infinity applications
no longer depend on ids being sequential.
Performance gain from the consolidated seed generation structure
After implementing both strategies, in a non-audited environment, the following

characteristics were observed:
• Percentage of transactions deadlocked: 1-2%
Again, this was with five TransDup processes, each running hundreds of transactions
as fast they could.
In an audited environment, the characteristics look like:

• Percentage of transactions deadlocked: 5.8%

Clearly, both measures were worsened in an audit database environment. This comes
as a result of serialization that occurs in an audited system because the audit tables
have no indexes. It should be kept in mind that this result was obtained on a severely
stressed system. Most production environments should see far fewer deadlocks and
faster performance.
Note, however, that a redesign of the audit database system has been completed and a
prototype implemented. With this in place, the characteristics on the severely stressed
system look like:
• Percentage of transactions deadlocked: 2.4%
This audit database redesign will be incorporated into a release subsequent to 5.2.1.
Seed bucket generation algorithms in v5.2.1
First we define a sequence. For 1 < I < N, let
a1 = 1
ai =
{ I +ai-1, if I + ai-1 <= N
I + ai-1 - N, if I + ai-1 > N
In this definition, N corresponds to the number of buckets and I corresponds to the

Interval.
If N and I have No Common Factors, i.e. common factors other than one, then
{1,...,N} = {ai / i = 1,...,N}.
So, for example, if N = 10 and I = 7:

a1 = 1
a2 = 8
a3 = 5
a4 = 2
a5 = 9
a6 = 6
a7 = 3
a8 = 10
a9 = 7
a10 = 4
Of course, a11 = 1, and the cycle repeats.
Note, regardless of the algorithm chosen, the database is populated according to the
rule:
bucket_starti = (ai-1) * bucket_length
Sequential Interval Algorithm
I=1
Clearly, for I = 1, N and I have no common factors and the definition of the sequence
implies
ai = i for i = 1, ..., N.
Custom Interval Algorithm
Select I and N such that I and N have no common factors. Then calculate the ai’s based
on the sequence definition. See the example of N = 10 and I = 7, above.
Optimal Interval Algorithm
if N is even then
if N = 2 then I = 1
else
if N/2 is even then
I = (N/2) + 1
else
I = (N/2) + 2
endif
else
I = ceil(N/2)
endif
This algorithm guarantees that N and I have no common factors and that the ai’s are as
far apart as possible.
Documentation of Proofs
Proofs of the above statements are contained in the file $INFINITY_INSTALL/

montage/doc/WHATSNEW shipped with the 5.2.1 release.
Seed Tables in v5.2

Version 5.2 and earlier of the Infinity Data Model uses a set of seed tables to provide
each new instance of an entity with a unique, sequential identification number.
In order to ensure the integrity of the data within Montage, the seed tables should not
be altered without the assistance of Infinity Technical Support. In order to enforce this,
all seed tables have a trigger to prevent insertion or deletion.

The v5.2 seed tables all share the same table structure. Each contains only one column
and one row. This column has the same name as the table, with the word _id replacing
_seed (e.g. the curve_id column in the curve_seed table). NOTE: This single record
represents the last used id number, not the next available id number.
In v5.2, there are 27 seed tables in the Data Model, each one corresponding to a table
whose records will be keyed off of its id value (i.e. the trade table will be keyed off
trade_id, which will be taken from the trade_seed table).
Retrieving a unique seed id
If two users simultaneously access a seed table and retrieve that current id, then
neither of the users will have a unique value. This is a problem referred to as
concurrency.
The problem of concurrency requires a specific method of interaction to prevent

multiple users from getting the same id value. In order to guarantee the uniqueness of
an id value, you must retrieve id values like this, using Transact-SQL:
begin tran
update <seed table> set <id name>=<id name> + 1
select <id name> from <seed table>
commit tran
The syntax above applies only to v5.2 and earlier databases. The first and last
commands delimit the commands to the database, grouping them in a transaction in
order to avoid concurrency problems. The second command increments the id value in
the table. The third command retrieves the id, and the final command concludes the
transaction. Locking and unlocking by using a database transaction is critical to
guarantee uniqueness for the retrieved id value. If you lock a table, other users must
wait until the lock is removed before they can query the table. (Note: you should
therefore consider handling this query on a separate database connection from other
routine database queries.)
You must use the above method when creating new records that use an id value as a
primary key. In order to create a new set of curve tables, you would first increment and
retrieve the curve_id from the curve_seed table. Having done this, you would then use
that one curve_id to insert data into all of the appropriate curve tables. If, for some
reason, the transaction fails, its particular id will be lost, and there necessarily will be
gaps in the id order of the records for those tables. Deleting old records also creates
gaps in the id sequence. This is not an issue for a relational database, but the user
should be aware of it.
version 5.2 Seed Tables in v5.2 5-23

Extending the Infinity Data Model
One of the advantages of a relational data model is the ease with which you can make
additions to the model itself. Adding additional tables and datatypes to your database
should not cause any database interaction problems for existing applications or class
libraries. For example, to add a new security type, you would add a new header table
(if necessary) which used sec_id as its primary key.
However, you should avoid changing existing components of the Data Model. For
example:
• Dropping tables from the database would cause major problems for
Infinity applications and classes.
• Dropping or modifying Infinity datatypes could also cause major

problems.
• Renaming columns in the database will adversely effect the

performance of applications.
• Changing the order of columns will cause datatype compatibility

errors. If the datatypes of the switched columns happen to match, then
data will be stored in the wrong columns.
Contact Infinity Technical Support before making any changes to the Data Model.

Chapter 6
Holiday Tables
The holiday section of the database stores holiday rules and actual holiday dates for
world financial centers. The hol_header table stores the rules for the holiday, while the
hol_data table stores the actual holiday dates.
Included with Infinity are Infinity’s holiday calendars for a predefined set of cities.
These calendars are listed in the Data Model Reference Guide. This chapter reviews
the methods used to store those holidays and shows how to define new ones.
As always, it is important to make the distinction between the parametric definition of

a holiday, and the actual dates associated with it. The data model will store actual
holiday dates generated from holiday rules, but this generation must take place in an
external application (for example, Infinity’s Holiday Manager). This chapter assumes
that the user has such an application in place that can translate the header information
into calendar dates.
Defining Holidays with the hol_header Table

All holiday rules for a particular city are stored in the hol_header table. This table has
the following structure:
Table name: hol_header

hol_id 0 Hol_Id:int(4) PK
specific_weekday_code 1 Weekday_Code:char(3)
city_code 0 City_Code:char(3)
easter_related_b 0 Bool:bit(1)
easter_offset_day 1 Offset_Day:int(4)
final_year 1 Year:int(4)
hol_name 1 Hol_Name:varchar(25)
day 1 Day:int(4)
month 1 Month:int(4)
sat_roll_offset_day 1 Offset_Day:int(4)
start_year 1 Year:int(4)
sun_roll_offset_day 1 Offset_Day:int(4)
Figure 6-1. Structure of the hol_header table.
version 5.2 Defining Holidays with the hol_header Table 6-1

Attributes of the hol_header table
hol_id
uniquely identifies an instance of a holiday in a city.
specific_weekday_code
specifies on which day of the week this holiday occurs, using a weekday_code value
from infsys_montage_domains with domain_name = “weekday_domain”.
city_code
holds the three-letter city code where that holiday applies, using a code from the
infsys_montage_lists table with list_name = “city_list”.
easter_offset_day
tells how many days from Easter Sunday this holiday occurs (if applicable).
easter_related_b
a “1” indicates that the holiday is calculated with respect to Easter.
final_year
the final year for the celebration of this holiday, as stored in the database.
hol_name
the holiday’s name.
day
the day of the month of the holiday.
month
the month of the holiday.
sat_roll_offset_day
indicates on which day the holiday is observed when that holiday falls on a Saturday.
start_year
the first year for the celebration of this holiday, as stored in the database.
sun_roll_offset_day
indicates on which day the holiday is observed when that holiday falls on a Sunday.
Offset Days
Offset days are designed to track a holiday’s behavior when it falls on a weekend. If a
holiday occurs on a Saturday, check the sat_roll_offset_day entry. If that value is -1,
the holiday is observed on the Friday before. If that value is 2, the holiday is observed
two days later, on the next following Monday.
6-2 Holiday Tables Infinity Data Model Developer’s Guide

Similarly, sun_roll_offset_day holds values of 1 and -2. A 1 indicates that a Sunday
holiday would be observed on Monday, and -2 would indicate that the holiday is
observed on the preceding Friday.
For example, if Christmas were to fall on a Saturday, it would be observed at the New
York markets on the Friday before. You could query the database to find that the offset
value is -1.
The hol_data Table

The hol_data table is used to store the specific dates on which a particular holiday will
be celebrated in a particular city. These numbers can be derived from the hol_header
rules. The primary keys for hol_data are the date and id of the holiday. The id comes
from the hol_header table, and uniquely identifies the holiday as, for example,
Christmas in New York. The date must also be present in order to specify the year. The
hol_data record for Christmas 1998 in New York is:
Table name: hol_data
hol_date Dec 25 1998 12:00AM
hol_id 12
city_code NYC
Figure 6-2. Sample hol_data values for Christmas 1998 in New York.
This table is denormalized in that the city_code is stored in both the hol_data and
hol_header tables. Given a hol_id number, you could get the city_code from the
hol_header table. However, this denormalization speeds database queries.
Querying the hol_data and hol_header Tables

You can query the hol_data tables to list all of the holiday dates for a specific holiday.
To find out what days holiday 270 (Whit Monday in Copenhagen) will be celebrated,
you could execute the following sql statement:
select hol_date from hol_data where hol_id = 270
To find out all the hol_id numbers for all the instances of Whit Monday around the
world, you would execute:
select hol_id from hol_header where hol_name =’Whit

Monday’
version 5.2 The hol_data Table 6-3

To find out the hol_id number for Whit Monday in Copenhagen:
select hol_id from hol_header where (city_code =’COP’ and

hol_name =’Whit Monday’)
Be sure to use the exact spellings for each of the holidays as found in the Holiday
Rules section of the Data Model Reference Guide.
Defining a New Holiday Rule

To define a new holiday for a city, you must insert values into a new hol_header
record. Three different types of holidays can be stored in hol_header. These include
absolute date holidays, specific weekday holidays, and Easter-related holidays. The
definitions for each type of holiday are:
Holiday Rule Example

Absolute date Specific calendar dates that may roll forward or backward
during weekend instances (New Year’s day in NYC)
Easter-related Easter-related events (Good Friday)
Specific weekday Specific weekday (Thanksgiving in the NYC is always the
fourth Thursday in November)
Figure 6-3. Holiday rules and examples of each.

The values in the table below show some sample hol_header entries for each type of
holiday:
Table name: hol_header
Absolute date Easter-related Specific weekday
hol_id 2 221 11
specific_weekday_code THU
city_code NYC AMS NYC
easter_related_b 0 1 0
easter_offset_day NULL -2 NULL
final_year 2030 2030 2030
hol_name New Years Day Good Friday Thanksgiving Day
day 1 0 22
month 1 0 11
sat_roll_offset_day 2 0 0
start_year 1980 1980 1980
sun_roll_offset_day 1 0 0
Figure 6-4. Three sample instances of the hol_header table, one for each type of holiday: absolute (New
Year’s), Easter-related (Good Friday), and specific weekday (Thanksgiving).
Note that Thanksgiving is celebrated on the fourth Thursday of November. The day
value of 22 indicates that Thanksgiving will be observed on the first Thursday after
November 21.
While offsets from Easter are stored in the database, Easter Sunday itself is not. The
database comes populated with data for such holidays as Easter Monday and Good
Friday, but it is up to the application programmer to determine the dates for Easter
Sunday itself. The Infinity Static Data Manager application will do this. If you need to
perform the calculation directly, the following simple program can be used (this
example is written in standard C++ code):
// easter.cxx
// calculate easter offset, given year
#include <iostream.h>
int
main()
{
int year;
version 5.2 Defining a New Holiday Rule 6-5

cout << "Enter Year: ";
cin >> year;
int tmp1 = (19 * (year%19) + 24) % 30;

int tmp2 = (2 * (year%4) +
4 * (year%7) + 6 * tmp1 + 5) % 7;
int easter = 22 + tmp1 + tmp2;
if (easter > 31)

{
cout << "Easter: April " << (easter-31) << endl;
}
else
{
cout << "Easter: March " << easter << endl;
}
return 0;
}
If you add a holiday through the Infinity Static Data Manager, the application will add
the holiday rules to hol_header, generate dates and add these dates to hol_data.
You do not need to use the Infinity Static Data Manager to add a holiday, but if you
don’t, remember to keep the two tables hol_header and hol_data synchronized. The
Infinity Data Model doesn’t have the ability to keep any pair of tables synchronized.
Removing a Holiday
The procedure of removing a holiday from the database requires interaction with both
the hol_data and hol_header tables. They have a dependent relationship.
Consequently, in order to completely remove a holiday, you need to execute two SQL
statements:
delete from hol_data where hol_id = <##>
delete from hol_header where hol_id = <##>
If you delete a holiday through the Infinity Static Data Manager, the application will
automatically execute these two statements. If you use another application, make sure
the application deletes the holiday from both hol_data and hol_header.

The hol_type_domain
The hol_type_domain is one of the domain entries collected into the table
infsys_montage_domains. It stores the list of hol_type_code values which are used to
indicate what type of business event will be affected by a given holiday calendar.
The hol_type_code values migrate to a number of security tables. These tables include
sec_hol_city, curve_hol_city, ref_index_hol_city, money_market_attribute_hol_city,
exchange_attribute_hol_city, bond_attribute_hol_city, and sec_hol_default.
Currently, the hol_type_domain comes populated with two hol_type_code values,

PAYMENT and RESET. Holiday calendars assigned to a security with the
hol_type_code PAYMENT will affect payments, while calendars assigned to a
security with the hol_type_code RESET will affect the security’s rate settings.
version 5.2 The hol_type_domain 6-7

Chapter 7
Transaction and Trade Tables
Within the Infinity database there is a set of tables that share the prefixes trade_ or
trans_. These tables are designed to handle the information involved in actually
trading a security.
Transactions, Trades, and Trade Legs

The fundamental data modeling philosophy embodied in the Infinity Data Model is
that a trade represents an exchange of an arbitrary number of financial instruments or
securities. This logical representation is embodied in three main tables: trans, trade
and trade_leg.
A transaction is a potentially unlimited grouping of trades which are assembled for a

particular financial purpose, while a trade is a specific exchange between two or more
counterparties. Information pertaining to tracking a transaction is maintained in the
trans table, whose primary key is the trans_id.
The trade tables contain information pertaining to the collections of trade legs. The
trade table has a trans_id number, which is a foreign key, that identifies trades as part
of a transaction. This table’s primary key is the trade_id. The trade represents the
actual exchange of instruments, and hence has information (such as dates and strings)
for tracking purposes. The trade is also typically connected to some relevant legal
information.
The pivotal table in the transaction/trade section of the database is trade_leg. This
table relates transaction and trade information to the security tables of the database.
Many trade legs can be involved in a given trade; most commonly there are two.
Instances of trade_leg pertaining to the same trade are given common trade_id
numbers, and a sequential trade_leg_id is added to make up the primary key
combination. Each trade_leg contains a sec_id corresponding to the actual financial
instrument which is being exchanged as part of this particular trade.
One example of a trade would be an exchange of a USD LIBOR cap for a premium
paid in USD. This one trade would foster two records in the trade_leg table: one for
the USD cap side and one for the USD currency side. The securities themselves (the
cap and the currency payment) are defined separately in the security tables.
version 5.2 Transactions, Trades, and Trade Legs 7-1

trade_leg security
table
trans trade
trade_leg security
table
trade
more trade legs
Figure 7-1. Table diagram relating trans, trade, and trade_leg tables.
portfolio / trans / trade / sec / flow

As depicted in Figure 7-1, the Infinity Data Model stores information about trades by
breaking them up into their most basic units: cash flows. If you trace the diagram, you
can see that a portfolio consists of many trades, and that a transaction is also made up
of many trades. A portfolio would typically define a set of like trades, such as USD
swaps or JPY bonds. A transaction would typically define a set of related trades,
grouped together with a common financial purpose.
Trades then consist of many trade legs. Each trade leg is associated with a security,
which points to the actual cash flows, and is organized through header tables.
For example, suppose you managed a portfolio of one hundred plain vanilla, fixed-for-
floating swaps. Using a stored SQL statement, a portfolio instance would define one
hundred trade records as members of that portfolio. Each of these trades might be the
child of a different transaction instance.
Each trade table would be the parent to two trade_leg instances; one for the floating
side of the swap, and one for the fixed side. Each trade_leg would then have one sec
(security) record storing general information about that fixed or floating leg (such as
when it was created, who created it, etc.).
The characteristics of each swap leg (timing, rates, fixed or floating, etc.) are then
stored in swap_leg_header tables. These header records are the parents to many flow
records, each of which models a payment related to the trade leg. Figure 7-2 illustrates
the tables used to model a fixed-for-floating swap in the Infinity Data Model, as well
as the relationships between these tables.
7-2 Transaction and Trade Tables Infinity Data Model Developer’s Guide
trade_leg sec swap_leg flow
header
fixed
transaction trade
floating
trade_leg sec swap_leg flow

header
Figure 7-2. Infinity table diagram modeling a fixed-for-floating swap.
Currencies themselves are also defined as securities (see page 9-3). A purchase of a
government bond in return for a payment of US dollars would be modeled in two
trade_leg tables: one for the bond, and one for the dollars used to buy the bond.
The Difference Between Transactions and Portfolios

A transaction is a set of trades grouped together for any financial purpose. One
transaction might be the purchase of an option today, along with the purchase of the
underlying instrument at some later date. Another transaction might be a swap
combined with a hedging cap.
A portfolio of trades would typically be those you would want to analyze in a group,
especially for risk analysis purposes. You might want to define a portfolio of JPY
swaps so you could calculate your exposure to that currency. For more information on
defining and using portfolios in the Data Model, see Chapter 13, Portfolio Tables.
Tables Discussed in this Chapter

This chapter will focus on those tables that form the “core” of the trade structure
portion of the Infinity Data Model. These include the trans, trade, trade_leg,
trade_leg_partic, trade_commision, trade_leg_org_partic, trade_leg_book_alloc,
trade_leg_val, trade_stlmt, trade_info, trade_keyword and trade_attention tables.
The use of these tables will be illustrated by the following simple trade: Bank_A buys
US$100,000 face value of 10-year US Treasury bonds (when issued on the secondary
market) from Bank_B at a price of 98.00. The example on the following pages will
version 5.2 The Difference Between Transactions and Portfolios 7-3

show the tables as they would be populated by the Infinity Trader application in order
to model this bond purchase.
The transaction table
The first thing you must do when creating a new transaction in the trans table is to get
a unique trans_id. Once you have this unique trans_id, use it for identifying your
transaction when inserting and retrieving records.
Sample values for the trans table:
Table name: trans
trans_id 523
entered_user_code fodev_user_1
update_datetime Jun 22 1995 4:41PM
Figure 7-3. The trans table, populated with sample data.
The trans_id of 523 is a sample value; the entered_user_code is the current user’s
login name; the update_datetime is the current time, using the Sybase function
getdate().
If you are using the Infinity applications, or if you are using another application built
using the Fin++ Class Libraries, the values in the trans table are automatically set.
The trades involved in this transaction can then get the same trans_id number as a
foreign key to be identified as part of the same transaction.
The trade table
Having populated the trans table, you must then create a trade to represent the bond
purchase. The trade will also need a unique trade_id.
Once you have a valid trade_id, create a new trade record. The following entries
correspond to the current example:
Table name: trade
trade_id 530
entered_user_code fodev_user_1
quote_price 0.980000
remark trade before issue
reference_str NULL
indentification_str NULL
settlement_date Jun 23 1995 12:00AM
trade_date Jun 22 1995 12:00AM
trade_status_code BOOKED
trade_type_code MARKET
trader_prsn_id 4
trans_id 523
verified_user_code NULL
entered_datetime Jun 22 1995 4:41PM
verified_datetime Jun 22 1995 4:41PM
update_user_code NULL
process_org_id 3
subject_org_id 1
sales_prsn_id NULL
sequence_number 1
Figure 7-4. The trade table, populated with sample data to model a US Treasury bond purchase.
The trade_id of 530 is a sample value. Typically this will be greater than or equal to
the trans_id.
version 5.2 Tables Discussed in this Chapter 7-5

The quote_price is the price, if the instrument is market traded.
The remark is a text field where you can enter a description of the trade.
The reference_str and identification_str attributes are both fields you can use to record
any in-house numbering schemes for this trade. For example, you could use these
fields to record numbering schemes leftover from old systems.
The settlement_date is the date on which the trade actually begins. The trade_date is
the date on which the trade was agreed to by both parties.
The trade_status_code gives the organizational status of the trade (such as whether it
is booked or pending). The trade_status_code is a foreign key, migrating from
infsys_montage_lists with list_name = trade_status_list.You can add other statuses if
necessary, but if you do so, and if you use the Infinity application Trader, you will also
have to modify the access permission tables or no user will have permission to save
trades with your new status. See Chapter 15 on access permissions. Note that the
Infinity risk management applications are configured to only recognize trades that
have at least pending status. The Infinity back office applications are configured to
only recognize trades that have at least booked status.
The trade_type_code is also a foreign key, migrating from infsys_montage_lists with

list_name = trade_type_list. It describes whether the trade is an internal trade or a
market trade. In an internal trade, by definition, the two counterparties lie within the
same primary business entity hierarchy. The Infinity application Trader will enforce
this criteria. If you add to the database through another application, take care to keep
to this definition.
The trader_prsn_id is the identification number of the trader responsible for this trade.
It is not required that the trader be a user of the system; this person only needs a
person identification number, not a user name. This value migrates from a prsn table;
trader_prsn_id is a role name.
The trans_id is the id of the parent transaction. The identification number migrates
from the trans table as a foreign key. The update_datetime records the current time.
The subject_org_id is the organization id (from the org table) of the primary
organization involved in the trade. This is kept separate from the counterparty
organization in order to allow the trade to be viewed from any party’s perspective.
(These counterparty organization id’s will be logged in the trade_leg_org_partic
table.)
The sequence_number is used by Back Office applications to ensure integrity

between data in the database and data in the event server cache. Every time a trade is
saved, the sequence_number increments by 1.
Creating the two trade_leg tables for this trade
In our US Treasury example, this trade will be modeled with two trade_leg table
records: one for the bond (sec_id 2006) and one for the cash (sec_id 1011) that is used
to purchase it (see the chapter on security, Chapter 8, for information on modeling
cash securities in the sec table).
Table name: trade_leg
values for bond leg values for cash leg
trade_id 530 530
trade_leg_id 1 2
sec_id 2006 [the bond] 1011 [the cash]
trade_leg_type_code PRIMARY SETTLE
accrued_interest_amount 0 0
trade_amount 100000 98000
Figure 7-5. Two instances of the trade_leg table, one for each leg of a US Treasury bond purchase.
Notice that prior to creating this trade, the traded securities must have already been
defined. In this case, those securities are the US Treasury bond (sec_id 2006) and US
dollar currency (sec_id 1011). The assignment of a sec_id to a trade_leg record
represents the link between the trading portion and the security definition portion of
the Infinity Data Model.
The primary key for the trade_leg table is made up of the trade_id and the
trade_leg_id. The trade_id comes from the trade table, and the trade_leg_id is
sequential, starting at 1.
The trade_leg_type_code is a foreign key, migrating from infsys_montage_domains,

with domain_name equal to trade_leg_type_domain. Values in that domain include
codes to distinguish those legs which are priced from those legs for which price is
denominated. The PRIMARY leg is priced in terms of the SETTLE leg. For this
example, a US Treasury bond was exchanged for dollars; the dollars are the settlement
leg, and the bond is the primary leg, priced in dollars.
The trade_amount is the amount of the security represented by the trade leg. In the
case of a bond, this is the total principal amount of the bond(s) in the trade leg. Our
$100,000 bond is entered as a trade_amount of 100,000 in the PRIMARY leg.
The trade_amount for the SETTLE leg was calculated by taking the amount for the
PRIMARY leg times 0.98 (the price of the bond as a percent of par). Please note that
version 5.2 Tables Discussed in this Chapter 7-7

this calculation is done by external analytics and then stored in the database; the
database is not capable of doing the calculation itself.
In general, the total value of a trade leg is determined by multiplying the

trade_amount by the principal of the security, if specified independently in a header
table. When not specified, this principal (as in the case of the bond) is assumed to be 1
unit of the currency in which the security is denominated.
In the case of a swap, the trade_amount is one, indicating that the trade_leg represents
one swap leg valued at the principal amount specified in the corresponding
swap_leg_header entry.
Modeling an Organization’s Participation

An organization may be involved with a trade or with a trade leg. A broker is involved
at a trade level; a counterparty is involved with a single trade leg. The Infinity Data
Model models the two types of relationships separately.
At the trade level
If an organization is involved with the trade as a whole, the organization is identified

in the trade_org_partic table. This table has three columns: trade_id,
trade_partic_type_code, and partic_org_id.
The trade_id identifies the trade. The trade_partic_type_code is a foreign key

migrating from infsys_montage_domains; it identifies whether the organization is a
broker, a calculation agent, an assignor or an assignee. The partic_org_id is a foreign
key migrating from the org table, and it identifies the organization having the
relationship specified.
In our example, if we assume a broker has org_id 6, the table trade_org_partic

for this trade_id would look like:
Table name: trade_org_partic
trade_id trade_partic_type_code partic_org_id
530 BROKER 6
Figure 7-6. The trade_org_partic table, showing that org 6 acts as broker on trade 530.
If there is a broker with a non-standard commission, the broker fee and broker
currency would be stored in the table trade_commission. For our example, we assume
the broker fee is standard and thus there would be no entry in trade_commission for
trade_id 530.
At the trade leg level
For each leg of a trade you must identify how the organizations involved participated
in the trade_leg_org_partic table. These organizations are recorded by their org_id,
allowing them to be identified by their records in the org table. They have participant
codes, indicating whether they are the payers (deliverers) or receivers of the
instrument associated with that trade leg.
In this example, as Bank_A buys the bond (leg 1), it will be the receiver, and Bank_B
will be the payer of this leg. Assuming that Bank_A has org_id “1” and Bank_B has
org_id “14” in the org table, then the trade_leg_org_partic entries would be:
Table name: trade_leg_org_partic
trade_id trade_leg_id partic_type_code partic_org_id
530 1 PAY 5
530 1 RECEIVE 1
530 2 PAY 1
530 2 RECEIVE 5
Figure 7-7. The trade_leg_org_partic table, showing that org 1 receives leg 1 in return for payment of
leg 2.
You can also record any number of additional participants to the trade_leg as paying
agents, legal agents, etc. You could add new codes to the infsys_montage_domains,
where domain_name = partic_type_domain, to include any kind of participation. It is
important that you accurately record which institutions are involved in every
trade_leg, because this information is used for portfolio analysis and operations
functions. You must have accurate participation records to calculate exposure to the
risk of counterparty default.
Assigning each trade leg to a book

If you entered your trade to the database using the Infinity applications, you cannot
save a trade in booked status unless you first assign each trade leg to a book. If you
entered your trade through some other means, you do not need to assign each trade leg
to a book, but you probably will want to do so, anyway, so you can support reporting
on the book level, or risk management by book.
version 5.2 Assigning each trade leg to a book 7-9

In our example, the bond, we will assign both legs to the same book, BOND_BOOK.
The table trading_book maps the book name to a unique book_id. The table
trade_leg_book_alloc maps each trade leg to one or more book ids.
Note that the table trade_leg_book_alloc permits a user to allocate a percentage of

the trade leg to multiple books. The Infinity Trader application does not support
anything less than 100% of a book to a trade leg. If you populate this table via another
means, make sure all rows for the same trade leg add up to exactly 100%.
The table trading_book for our example environment might look like this:
Table name: trading_book
book_id 1
book_name BOND_BOOK
acct_org_id 1
remark NULL
auth_b 1
auth_id 123
Figure 7-8. The trading_book table, showing the book_id for the book named BOND_BOOK.
In the table trading_book, the field acct_org_id identifies the organization that owns
the book listed. It is a foreign key, migrating from the org table.
Given the above, for our bond example, the table trade_leg_book_alloc would then
look like:
Table name: trade_leg_book_alloc
trade_id 530 530
trade_leg_id 1 2
book_id 1 1
percent 100 100
remark NULL NULL
Figure 7-9. The trade_leg_book_alloc table for the bond example.
Recording pricing information for a trade
For each leg of a trade, it is possible to record the pricing curve or curves that were
used to calculate the price of that leg at the time when the trade was saved. It is
important to note that this information should be associated with the trade leg and not
with the security itself, since a security may be multiply traded (in different legs) and
priced off of different curves each time. The details of the curve (in particular, its id
and its usage) are recorded in the trade_leg_val table. In order to find out more about
the curve, it will be necessary to query the curve tables for the corresponding curve_id
and curve_datetime.
Note the field sec_id in the trade_leg_val table. This field is required so that
underlying securities, such as the swap legs that underlie a swaption, can be priced
independently from the primary security. The primary security is stored in the table
trade_leg.
Table name: trade_leg_val
trade_id 530
trade_leg_id 1
sec_id 2006
curve_usage_code DISCOUNT
curve_id 36
curve_datetime Jun 22 1995 12:00AM
curve_matrix_id NULL
interp_code LINEAR
curve_side_code MID
curve_basis_shift 0
volatility_type_code NULL
Figure 7-10. The trade_leg_val table, showing that curve 36 was used to
discount the cashflows associated with trade leg 1.
Assigning settlement instructions to a trade

The Infinity Data Model captures information for back office processing as well as
front office deal capture and middle office risk management. For back office
processing, you need to identify the payment settlement instructions for each trade.
This information is stored in the table trade_stlmt.
version 5.2 Recording pricing information for a trade 7-11

The table trade_stlmt has one entry for each settlement instruction applicable to that
trade. The subject_org_id and object_org_id migrate from the org table. The stlmt_id
migrates from the table stlmt_detail.
Table name: trade_stlmt
trade_id 530 530 530 530
subject_org_id 5 5 1 1
payment_direction_code PAY RECEIVE PAY RECEIVE
object_org_id 1 1 5 5
currency_code USD USD USD USD
stlmt_id 36 37 52 53
auth_b 1 1 1 1
auth_id 222 223 224 225
Figure 7-11. The table trade_stlmt, showing the instructions for the bond example.
Other useful trade-related tables

The table trade_info stores a code that describes the type of trade (Swap, Cap, Floor,
etc.) The Infinity applications will store an entry in this table when you save a trade,
ensuring that the table trade_info is synchronized with the table trade. If you use
another means to input information to the Infinity Data Model, be careful not to
violate this data integrity.
Trade info codes migrate from infsys_montage_domains. Like other domain codes, if
you add a trade info code, you have to recompile the applications to get your code
recognized by Infinity applications. Also, trade info codes are added automatically by
Infinity applications; that is, an end-user using the Infinity applications cannot specify
a particular trade info code for a particular trade.
In contrast, the table trade_keyword stores extra codes that a user can define and attach
to particular trades. These keywords can be used to drive back office processing, risk
management, or grouping of trades for reporting purposes.
Trade keywords are just that: keywords. They do not permit a user to attach extra
comments alongside. For that purpose, use the table trade_attention. This table
permits you to attach a trade attention code and a remark for that code.
You can write applications that permit end-users to specify values you will store in the
table trade_info, but we don’t advise this practice. Instead, keep the distinction
enforced by the Infinity applications: use trade_info to store information
automatically; use trade_keyword to store user-specified information without adding
comments; use trade_attention to store user-specified information with comments.
version 5.2 Other useful trade-related tables 7-13

Chapter 8
Security Tables
The security tables within the Infinity Data Model store the parameters for the
derivative securities (also known as instruments) exchanged by a trading desk. The
tables contain the information needed to characterize and price derivatives
instruments.
About This Chapter

This section first covers the general structure of all the security tables. The description
of the sec table begins on page 8-6, and the sec-related tables are described starting on
8-8.
A field-by-field description of the swap_leg_header table begins on page 8-14.

These fields are common to many of the other _header tables, so they are covered with
a fairly exhaustive level of detail. The discussion of the
swap_leg_index_amort_header table begins on 8-29. A few of the other _header
tables (bond_header, cap_floor_header, exchange_header, money_market_header,
otc_option_header, and repo_header) are described beginning on page 8-31, with
examples showing techniques used to model each kind of security.
In the interest of brevity, this chapter does not attempt to describe every security, and
every header table. In particular, the header tables for asset options, bond futures,
equities and equity derivatives, spreads, and when issued bonds are not described here.
For a description of the information stored in these tables, contact Infinity support
personnel.
The Security Tables’ Three-tiered Structure

Within the Infinity Data Model, securities are modelled in a three-tiered hierarchy.
The first tier is made up of the tables common to all securities (the sec table and some
related tables), the second tier contains the security-specific header tables (_header
tables), and the third tier comprises the flow tables, which model security cashflows.
This chapter discusses the first two tiers. For information on the third tier of tables,
consult Chapter 9, Flow Tables.
version 5.2 About This Chapter 8-1

sec and related tables
The sec table contains general descriptive information that characterizes a security.
Every security in the Infinity Data Model requires a record in the sec table. The
primary key for the sec table is the sec_id.
Along with the sec table itself, there are other tables that store information common to
most or all securities. Following is a brief listing of those tables which will be
discussed in this chapter, and their functions:
Table name Purpose
sec stores general descriptive information that uniquely identifies each

security
sec_fees stores security-related fees according to when they are to be paid

over the life of the instrument
sec_hol_city stores the holiday cities associated with a given security
sec_quote stores the market-quoted prices for a security
sec_relative if a security’s start and maturity dates are defined relative to a given
date, this table stores those offset terms
Figure 8-1. The sec-related tables of the Infinity Data Model.
8-2 Security Tables Infinity Data Model Developer’s Guide

Security header tables
The _header tables make up the second tier of the security table hierarchy. There is
one _header table for each type of security. A _header table stores the information
that characterizes a specific security (e.g. maturity date, coupon frequency, fixed rate,
floating rate index, compounding parameters).
For each row in the sec table, there is one row in the appropriate _header table. The
Infinity Data Model includes the following _header tables:
Table name Characterizes which security
asset_option_header asset options
bond_future_header bond futures
bond_header bonds
cap_floor_header caps and floors
equity_dr_header equity derivatives
equity_header equities
exchange_header futures and exchange-traded

options
money_market_header money market securities
otc_option_header over-the-counter option securities
repo_header bond repurchase agreements
spread_header spreads
swap_leg_header swaps and FRAs
swap_leg_index_amort_ index amortizing swaps

header
wi_settle_sec_header when issued bonds
Figure 8-2. The _header tables of the Infinity Data Model.
version 5.2 The Security Tables’ Three-tiered Structure 8-3

Security attribute tables
Since bonds, futures, exchange-traded options, and money market securities are issued
in series with standard features common to each series, the common features of each
series are modelled in a set of security attribute tables rather than in the header tables.
Each _attribute table may be the parent to many _header table instances, with each
_header table instance storing the information for an individual instrument in the
series.
The Infinity Data Model includes the following _attribute tables:
Table name Characterizes which security
bond_future_attribute bond futures
bond_attribute bonds
exchange_attribute futures and exchange-traded

options
money_market_attribute money market securities
Figure 8-3. The _attribute tables of the Infinity Data Model.
Currency Securities
Currencies are modelled as securities, using the sec table. For example, in the
purchase of a government bond in return for a payment of US dollars, the dollar
currency payment would be modelled as a trade_leg with a sec_id identifying the
security of the trade leg as US dollar currency.
Each national currency is modelled only once in the sec table, with a sec_type_code
of ‘CURRENCY’ and a currency_code identifying the currency being modelled. The
currency_code value migrates from the infsys_montage_lists table with list_name =
currency_list.
To create a currency security using the Infinity applications, use the Spot FX Rates
window and select the command ‘Add Cur Pair’ (the Spot FX Rates window can be
accessed via the Utilities menu in the FX Arbitrage module of Trader). Currencies
must be added in pairs, with a cross rate saved to the sec_quote table listing the value
of the secondary currency in terms of the primary security. The Currency Pair window
allows you to create currency securities for any supported currency_code in the
infsys_montage_lists table, and the Spot FX Rates window allows you to enter
currency cross rates.
Foreign Exchange
The Infinity Data Model does not include a foreign_exchange_header table. This is
because FX trades are the simple exchange of one currency for another on a date. The
currencies of these transactions are modelled in the database as separate securities
with a sec_type_code of ‘CURRENCY.’ If the US dollar security is sec_id 1 and the

Japanese yen security is sec_id 2, a dollar/yen trade is simply recorded in the
transaction tables as sec_id 1 exchanged for sec_id 2. The settlement date is stored in
the trade table, and the trade amount for each leg is stored in an instance of the
trade_leg table.
Since currencies are saved to the database in pairs, each currency saved using the
applications will have an entry in the fx_quote_style table for each other currency for
which cross rates are stored. Before an FX trade may be modelled, the currencies to be
traded must be specified as a valid currency pair in the fx_quote_style table, and a
cross rate for the pair must exist in the sec_quote table. See the preceding section on
currency securities for information on using the applications to add currency pairs and
cross rates.
Spreads
The spread_header table is an operational table designed to allow spreads to be added
to bonds using Infinity’s applications. It is not intended as a means for defining spread
securities. The structure of the spread_header table is documented in the Data Model
Quick Reference.
To apply a spread to a security, use the spread-related fields in the _header table
associated with that security. For example, to apply a spread to a swap you would use
the compound_spread_rate and ref_index_spread_rate fields in the swap_leg_header
table.
Flow tables
The third tier of the security tables consists of the flow tables. The tables flow and
flow_calc_reset characterize the cashflows generated by securities. There is one row in
the flow table for each cashflow generated by a security. The sec_id migrates to the
flow tables from the corresponding _header table. Securities that generate cashflows
include swaps, caps/floors, and bonds. See Chapter 9, Flow Tables, for more
information.
version 5.2 The Security Tables’ Three-tiered Structure 8-5

The sec Table
All securities in the Infinity Data Model have an entry in the sec table. It is at the top
layer of the security tables.
Table name: sec

sec_id 0 Sec_Id:int(4) PK
sec_def_code 0 Sec_Def_Code:varchar(25)
entered_datetime 1 Datetime:datetime(8)
entered_user_code 1 User_Code:varchar(30)
currency_code 1 Currency_Code:char(3)
description 1 Description:varchar(50)
reference_str 1 Ref_Str:varchar(30)
sec_name 1 Sec_Name:varchar(40)
sec_type_code 0 Sec_Type_Code:char(12)
source 1 Sec_Source:varchar(12)
verified_user_code 1 User_Code:varchar(30)
update_datetime 1 Datetime:datetime(8)
sec_product_code 0 Sec_Product_Code:varchar(50)
leg_type_code 0 Leg_Type_code:varchar(36)
Figure 8-4. The structure of the sec table.
The columns of the sec table
The sec_id field is the primary key of the sec table. When creating a new security in
the Infinity database, at least five fields must be populated with data to identify it:
sec_id, sec_def_code, sec_type_code, sec_product_code, and leg_type_code.
The sec_id field

The sec_id field stores a unique integer value. The sec_id field is the primary key of
the sec table and the _header tables. Each security added to the database is numbered
consecutively.
The sec_def_code field

This field indicates whether the security is defined in terms of relative dates or a set of
specific dates. The values for this field are defined in the infsys_montage_domains,
with table_name = sec_def_domain. If the security is ‘SPECIFIC,’ this means the
actual start and maturity dates are known. If the security is ‘RELATIVE,’ these dates
are not known, so an entry in the sec_relative table is required to indicate the relative
offset terms of the start and maturity dates.
The entered_datetime field

This field stores the date and time that the security was originally entered in the
Infinity database.

The entered_user_code field
The entered_user_code field records the login name of the user who defines the
security in this table. The code should be the same as the database user name
registered in the Infinity applications.
The currency_code field

This field identifies the denomination of the security. Valid entries for this table are
stored in the infsys_montage_lists table, with list_name = currency_list.
The description field

Use this field to store a description of the security up to fifty characters in length.
The reference_str field

This field can be used to enter custom identification numbers for securities.
The sec_name field

Users may use this field at their discretion to give a security a short name.
The sec_type_code field

Store an identification code for the security in this field. The domain of valid entries is
stored in the infsys_montage_domains, with domain_name = sec_type_domain. The
value stored in this field should be consistent with the _header table that defines the
security (i.e. a security with an entry of ‘SWAP_LEG’ in this field should have an
entry in the swap_leg_header table). The value entered in this field will direct you to
the correct header table to find the parametric definition of the security.
The source field

If the security is defined by another software system, one can use this field to note the
source. If the security is entered through an Infinity application, this field will be
blank.
The verified_user_code field

This field can be used to provide an additional layer of scrutiny when entering new
securities into the database. This field is not currently used by Infinity applications.
The update_datetime field

This field records the date and time that this table was last updated by a user of the
system, for a given security.
The sec_product_code field

This field records the sec_product_code for the security. Security types drive front
office processing, but security products drive back office processing. This code
migrates from infsys_montage_domains with domain_name = sec_product_domain.
The leg_type_code field

This field contains denormalized information that describes the trade leg. It
accelerates the loading and sorting of trade legs. For instance, a floating swap leg
paying USD 3-month LIBOR would be tagged "USD LIBO 3MO," and a put option
on a Eurodollar future would be labelled "IMM EUROUSD3M PUT."
version 5.2 The sec Table 8-7

Example using the sec table: a vanilla swap
As an example of an entry in the sec table, consider a standard vanilla swap: 2-year
US dollar fixed 4% for 6-month US dollar LIBOR.
Assume that the sec_id of the fixed leg of the swap is 2329 and the sec_id of the
floating leg is 2330.
The fixed leg and floating leg would be recorded in the sec table as follows:
Table name: sec
sec_id 2329 2330
sec_def_code SPECIFIC SPECIFIC
entered_datetime Jul 5 1995 3:58PM Jul 5 1995 3:58PM
entered_user_code fodev_user_1 fodev_user_1
currency_code USD USD
description NULL NULL
reference_str NULL NULL
sec_name NULL NULL
sec_type_code SWAP_LEG SWAP_LEG
source NULL NULL
verified_user_code NULL NULL
update_datetime Jul 5 1995 3:58PM Jul 5 1995 3:58PM
sec_product_code SWAP_LEG SWAP_LEG
leg_type_code FIXED USD/LIBOR
Figure 8-5. Entries in the sec table for the fixed leg and floating leg of a vanilla swap.
Security Tables Related to sec
The sec_hol_city table
Worldwide holiday data is needed to insure that each security’s payment and reset
dates coincide with the banking calendar(s) of the trading center(s) in which it is
traded. This information is stored in the sec_hol_city table. See the Holiday Tables
chapter for details about defining holidays in the Infinity database.
The sec_hol_city table is structured so that a security can be associated with multiple
cities. The structure of the table is as follows:

Table name: sec_hol_city

city_code 0 City_Code:char(3) PK
sec_id 0 Sec_Id:int(4) PK sec
hol_type_code 0 Hol_Type_Code:varchar(7) PK
filler 0 char:char(187)
Figure 8-6. The structure of the sec_hol_city table.
Notice that the primary key consists of the first three fields. Therefore, a given sec_id
value can appear in multiple rows of the table. One security can have zero, one or
many holiday cities, and the holidays can apply to payment dates, reset dates, or both.
The hol_type_code field

The hol_type_code field indicates whether the business calendar prevailing in the
selected city should be applied to the security’s payment dates (‘PAYMENT’) or rate
resetting events (‘RESET’).
The filler field

The filler field is used to improve performance. It permits the Data Model to
restrict the number of rows per page for the table. It is required because Sybase
System 10 does not permit the database administrator to restrict the number of rows
automatically for a table.
Infinity is planning to stop support for Sybase System 10 with v5.3. Starting with that
release, the filler field will be removed and max_rows_per_page will be implemented
in its place.
sec_hol_city example: assigning payment holidays

Suppose that the payment dates of the fixed and floating legs of our sample swap
should be tied to the business calendars in New York, and that the LIBOR reset for the
floating leg should only be subject to London holidays:
Table name: sec_hol_city
sec_id city_code hol_type_code filler

2329 NYC PAYMENT
2330 LON RESET
2330 NYC PAYMENT
Figure 8-7. Entries in the sec_hol_city table applying holidays to the swap legs.
version 5.2 Security Tables Related to sec 8-9

The sec_quote table
The sec_quote table stores the historical prices of individual securities. Because the
quote_datetime field is part of the primary key of the table, new price quotes for
securities can be appended to sec_quote and uniquely identified by their time stamp.
The sec_quote table has the following structure:
Table name: sec_quote

sec_id 0 Sec_Id:int(4) PK sec_settle_sec_tick_size
settlement_sec_id 1 Sec_Id:int(4) PK sec_settle_sec_tick_size
quote_datetime 0 Datetime:datetime(8) PK
quote_type_code 1 Quote_Type_Code:char(12)
bid_value 1 Value:float(8)
offer_value 1 Value:float(8)
settlement_term 1 Term:int(4)
quote_method_code 0 Quote_Method_Code:char(12)
Figure 8-8. Structure of the sec_quote table.
Since the sec_quote table stores the quoted prices for each security over the entire
history of each security, the table will grow to contain a very large number of records.
Database administrators should monitor the size of the table and delete unwanted
records in order to enhance database performance.
The settlement_sec_id field

A quote models the exchange of one security for another. The settlement_sec_id field
holds the identification number of the second security of the quote. This is currently
only used for foreign exchange trades. For example, if the quote was for a US dollar
for Japanese yen exchange, the sec_id field would be the identification number for US
dollar currency, while the settlement_sec_id field would be the sec_id number for
Japanese yen currency.
The table sec_settle_sec_tick_size identifies the tick_size_code that would be used in

calculating the exchange rate for the pair of currencies listed as sec_id and
settlement_sec_id in sec_quote.
The quote_datetime field

The quote_datetime field timestamps the quotes stored in the sec_quote table.
The quote_type_code field

The quote_type_code field allows you to identify the significance of the quote. The
values for the quote_type_code field migrate from the infsys_montage_lists table with
list_name = quote_type_list. Some of the values refer to a time in the trading day:
‘OPEN,’ ‘INTRADAY’ and ‘CLOSE.’ Other values compare the amount of one price

to others: ‘HIGH’, ‘LOW’. Two other values specify whether the quote applies to a
‘MARKET’ price or a ‘SETTLE’ price (the official closing price for exchange
instruments).
The bid_value field

This field stores the quoted bid for the security. The bid is quoted in the format
identified in the quote_method_code field.
The offer_value field

This field stores the quoted offer for the security. The format of the offer quote is
identified in the quote_method_code field.
The settlement_term field

This field stores the settlement term for the trade being quoted.
The quote_method_code field

The quote_method_code field stores a value from the infsys_montage_domains table
with domain_name = quote_method_domain. It identifies the convention used to
represent the quoted value.
The update_datetime field

The update_datetime field stores the date and time that the quote was last updated.
Examples of the sec_quote table:
To demonstrate the use of the sec_quote table for foreign exchange, take the example
of a US-dollar-for-Canadian-dollar exchange. An entry in the sec_quote table might
be as follows (where security 1011 is USD and security 1013 is CAD):
sec_id 1011
settlement_sec_id 1013
quote_datetime May 24 1994 11:59PM
quote_type_code MARKET
bid_value 1.60
offer_value 1.60
settlement_term NULL
quote_method_code PRICE
update_datetime NULL
Figure 8-9. Entries in the sec_quote table for exchanges of USD for CAD.

There might be several entries on the same day. The next example shows a 3-month
Eurodollar contract.
sec_id 55 55
settlement_sec_id NULL NULL
quote_datetime Nov 10 1994 3:42PM Nov 14 1994 8:43AM
quote_type_code MARKET MARKET
bid_value 92.00 92.50
offer_value 92.05 92.55
settlement_term NULL NULL
quote_method_code MM_FUTURE MM_FUTURE
update_datetime NULL NULL
Figure 8-10. Entries in the sec_quote table showing bid and offer values for a futures contract.
In the above entries, the quote values were entered by hand via an Infinity application;
however, the database could be linked to a live quote feed to have prices automatically
entered in the table.
The sec_recalc_lock table
The sec_recalc_lock table is used by Infinity’s applications. It indicates which flow-

based securities have been customized from their standard header definitions. For
example, in a customized amortizing swap, the principal_recalc_lock is set to true,
implying that the principal structure of the swap has been manually edited and should
not be changed if the swap is open in a front end application. The structure of the
sec_recalc_lock table is:
Table name: sec_recalc_lock

date_recalc_lock 0 Recalc_Lock:bit(1)
fee_recalc_lock 0 Recalc_Lock:bit(1)
interest_amount_recalc_lock 0 Recalc_Lock:bit(1)
interest_rate_recalc_lock 0 Recalc_Lock:bit(1)
principal_recalc_lock 0 Recalc_Lock:bit(1)
Figure 8-11. Structure of the sec_recalc_lock table.

None of the fields in the sec_recalc_lock table can be NULL. If the lock for a
security’s parameter is set, the Recalc_Lock bit should be set to 1; otherwise the bit
should be set to 0.
The sec_relative table
The sec_relative table provides a way to define all over-the-counter securities in terms
of relative dates (a specified term but no specified start and end dates) instead of
absolute dates. In the sec_def_code field of the sec table, a security is defined as
‘RELATIVE’, ‘SPECIFIC’, ‘ONLY_UNDERLYING_RELATIVE’, or
‘ONLY_UNDERLYING_SPECIFIC’. If the security is to be defined relatively, an
entry in the sec_relative table is needed for that security.
Infinity applications require the use of relatively defined securities for the generation
of some interest curves. For example, to generate a CP-LIBOR spread curve, the
Infinity Curve Manager application prices relatively defined CP and LIBOR swap legs
against market quotes.
Table name: sec_relative

start_term 1 Term:int(4)
maturity_term 1 Term:int(4)
Figure 8-12. Structure of the sec_relative table.
Note that the terms used here are taken from the infsys_montage_domains table, with
table_name = term_domain. The term codes give number of days according to the 30/
360 day count basis, and hence must be interpreted by application code according to a
specified day count convention. For example, a maturity_term value of 180 means 6
months, but the actual number of days will be calculated at the time when a specific
start date and day count are designated.
The settlement_term field

The settlement_term field measures time from the trade date to the settlement date as
a term.
The start_term field

The start_term measures the term from the settlement date to the start date.
The maturity_term field

The maturity_term is the maturity or expiration of the instrument as a term after
settlement.

sec_relative example: defining a spot start, 3-month Eurodollar loan
Assume that sec_id 1003 corresponds to a 6-month US dollar LIBOR money market
security defined in the sec table and the money_market_header table. Its relative
parameters in the sec_relative table would be indicated as follows:
Table name: sec_relative
sec_id 1003
settlement_term 2 a two day settlement
start_term 0 the security starts with settlement
maturity_term 180 the security matures 6 months after settlement
Figure 8-13. Defining the relative term of a 6-month money market instrument with the sec_relative
table.
Swaps and the swap_leg_header Table

The swap_leg_header table defines the parameters of a swap leg security. From the
information in the swap_leg_header table, cashflows are generated by the application
for the swap leg and inserted into flow tables.
In the explanation that follows, the swap_leg_header table will be dissected in detail.
Since many attributes in the swap_leg_header table are common to other _header
tables, these attributes will be discussed in detail only in the section on the
swap_leg_header table. Thereafter, only the unique features of each subsequent
_header table will be highlighted.
The swap_leg_header table consists of forty-nine fields. These fields define the
essential aspects of both fixed and floating swap legs.
Below, you will find the columns of the swap_leg_header table listed in the order in
which they physically appear in the database. In the excerpt from the Data Model
Quick Reference below, each column is assigned a number between 1 and 49,
displayed to the left of the column name. In the column descriptions starting on page
8-17, the number of each field appears next to its name to help you cross-reference the
table structure below.
Navigating the forty-nine fields of the swap_leg_header table by their physical order
will not allow you to see the interrelationships between the fields. Therefore, the
columns have been massed into functional groups, as detailed in the chart on page 8-
16.

Table name: swap_leg_header
# Column name Null Datatype PK FK:Parent Table

(1) sec_id 0 Sec_Id:int(4) PK sec
(2) reset_calc_align_code 1 Reset_Calc_Align_Code:char(7)
(3) reset_weekday_code 1 Weekday_Code:char(3)
(4) flow_timing_code 1 Flow_Timing_Code:char(7)
(5) swap_leg_code 1 Swap_Leg_Code:char(7)
(6) structure_code 0 Structure_Code:char(12)
(7) flow_calc_timing_code 1 Flow_Calc_Timing_Code:char(7)
(8) ref_index_currency_code 1 Currency_Code:char(3)
(9) ref_index_code 1 Ref_Index_Code:char(12)
(10) ref_index_source_code 1 Ref_Index_Source_Code:char(12)
(11) ref_index_term 1 Term:int(4)
(12) amort_frq_code 1 Frq_Code:char(3)
(13) act_notl_code 1 Act_Notl_Code:char(8)
(14) amort_start_date 1 Date:datetime(8)
(15) compound_type_code 1 Compound_Type_Code:char(12)
(16) compound_spread_rate 1 Rate:float(8)
(17) payment_date_roll_code 1 Date_Roll_Code:char(12)
(18) day_count_code 1 Day_Count_Code:char(12)
(19) initial_exchange_amount 1 Amount:float(8)
(20) final_exchange_amount 1 Amount:float(8)
(21) fixed_rate 1 Rate:float(8)
(22) flow_calc_frq_code 1 Frq_Code:char(3)
(23) flow_rate_calc_code 1 Flow_Rate_Calc_Code:char(12)
(24) legal_agmt_code 1 Legal_Agmt_Code:char(20)
(25) maturity_date 1 Date:datetime(8)
(26) payment_start_date 1 Date:datetime(8)
(27) payment_lag_day_type_code 1 Lag_Day_Type_Code:char(3)
(28) payment_lag_term 1 Term:int(4)
(29) payment_frq_code 1 Frq_Code:char(3)
(30) principal_amount 1 Amount:float(8)
(31) ref_index_spread_rate 1 Rate:float(8)
(32) flow_calc_date_roll_code 1 Date_Roll_Code:char(12)
(33) reset_frq_code 1 Frq_Code:char(3)
(34) flow_calc_lag_day_type_code 1 Lag_Day_Type_Code:char(3)
(35) flow_calc_lag_term 1 Term:int(4)
(36) flow_calc_start_date 1 Date:datetime(8)
(37) start_date 1 Date:datetime(8)
(38) reset_period_term 1 Term:int(4)
(39) accrual_date_roll_code 1 Date_Roll_Code:char(12)
(40) manual_reset_b 0 Bool:bit(1)
(41) reset_cutoff_term 1 Term:int(4)
(42) amort_pay_amount 1 Amount:float(8)
(43) ref_index_factor 1 Ref_Index_Factor:float(8)
(44) accrual_day_count_code 1 Day_Count_Code:char(12)
(45) reset_day_of_month 1 Day:int(4)
(46) flow_calc_code 1 Flow_Calc_Code:char(12)
(47) compound_calc_timing_code 1 Flow_Calc_Timing_Code:char(7)
(48) flow_calc_weekday_code 1 Weekday_Code:char(3)
(49) reset_convert_before_average 0 Bool:bit(1)
Figure 8-14. The structure of the swap_leg_header table.
version 5.2 Swaps and the swap_leg_header Table 8-15

The fields of the swap_leg_header table can be grouped under these general headings:
Heading Function of the fields Constituent fields
General to store the parameters that identify accrual_date_roll_code

identification and distinguish swap leg securities accrual_day_count_code
fields act_notl_code
day_count_code
final_exchange_amount
fixed_rate
initial_exchange_amount
legal_agmt_code
maturity_date
principal_amount
sec_id
start_date
structure_code
swap_leg_code
Amortization to define the amortization structure of amort_frq_code

fields the swap legs amort_pay_amount
amort_start_date
Payment fields to define the details of the payment flow_timing_code

structure of the swap legs payment_date_roll_code
payment_frq_code
payment_lag_day_type_code
payment_lag_term
payment_start_date
Compounding to store the compounding compound_calc_timing_code

fields characteristics of the swap legs compound_spread_rate
compound_type_code
Flow calculation to store the parameters that govern the flow_calc_code

fields calculation of swap leg cashflows flow_calc_date_roll_code
flow_calc_frq_code
flow_calc_lag_day_type_code
flow_calc_lag_term
flow_calc_start_date
flow_calc_timing_code
flow_rate_calc_code
flow_calc_weekday_code
Reset fields to store the parameters that govern the manual_reset_b

resetting of a rate from the reference reset_calc_align_code
index for a floating swap leg reset_cutoff_term
reset_day_of_month
reset_frq_code
reset_period_term
reset_weekday_code
reset_convert_before_average
Reference index to describe the reference index used to ref_index_code

fields fix floating rates ref_index_currency_code
ref_index_factor
ref_index_source_code
ref_index_spread_rate
ref_index_term
Figure 8-15. A functional grouping of the fields of the swap_leg_header table.

General identification fields in the swap_leg_header table
The sec_id field (1)

The sec_id value migrates from the sec table to the swap_leg_header table. It is the
primary key of the swap_leg_header table. This field cannot be left NULL.
The swap_leg_code field (5)

The swap_leg_code field specifies whether the swap leg is a fixed leg (‘FIXED’), a
floating leg (‘FLOAT’), or the present value of a fixed or FRA leg (‘PVFIXED’).
For a swap leg with a swap_leg_code of ‘FIXED’, the reset fields and the reference
index fields are not applicable; they should contain a NULL value. For a floating leg,
the only field that does not apply is the fixed_rate field.
The structure_code field (6)

The structure_code field is populated with a value from the structure_domain. This
code identifies the principal and interest payment structure of the swap leg.
A structure_code value of ‘ANNUITY’ signifies that the payment of a swap leg’s

principal and interest will proceed in a series of equal payments for the duration of the
swap. In an annuity payment structure, the total of the principal and interest remain
constant. This payment structure is only applicable to fixed swap legs. Modeling an
annuity in the Infinity Data Model necessitates the use of the amortization fields,
payment fields, and flow calculation fields. Because reset fields and reference index
fields only apply to floating swap legs, for an annuity structure they should be NULL.
An annuity structure does not make use of compounding, so the
compound_type_code should be ‘NONE’; the other compounding fields should be
NULL.
A structure_code of ‘ZERO_CPN’ is specific to fixed-rate swap legs. In a zero coupon

swap, no principal or interest payments are made until the maturity of the swap. At
periodic intervals, interest flows are calculated but not paid. They are compounded
until the maturity date of the swap. Because a zero coupon swap is fixed to a known
rate, the reset and reference index fields do not apply. A zero coupon swap does not
exhibit amortization characteristics, so the amortization fields should be NULL. To
model a zero coupon swap, populate the payment fields, compounding fields, and flow
calculation fields.
Swap leg structures of ‘CUSTOM’ and ‘EQ_PRIN’ refer to the amortization of both
the fixed and floating legs. To model these swap legs, use the amortization fields,
payment fields, compounding fields, and flow calculation fields. If the swap leg is a
floating leg, characterize its rate resetting schedule and reference index parameters
with the appropriate fields.
The ‘BULLET’ and ‘FULL_CPN’ structures are non-amortizing fixed and floating
legs; leave the values of the amortization fields NULL. For fixed legs with these
structures, reset and reference index fields do not apply.

The act_notl_code field (13)
The act_notl_code field indicates whether the principal is exchanged (‘ACTUAL’) or
used only for interest calculation (‘NOTIONAL’). For a notional exchange of
principal, the initial_exchange_amount and final_exchange_amount fields do not
apply; leave them NULL.
The principal_amount field (30)

The amount of the principal (whether actual or notional) is stored in the
principal_amount field.
The initial_exchange_amount field (19)

This field contains the amount of principal exchanged initially. This is applicable to
swaps involving actual principal flows. For notional principal, the
initial_exchange_amount should be zero.
The final_exchange_amount field (20)

This field contains the amount of principal to be exchanged at the completion of the
swap. This field is only involved when the principal is actually exchanged. For a
notional principal deal, the final_exchange_amount is zero.
The start_date field (37)

This field stores the date on which the swap takes effect.
The maturity_date field (25)

This field specifies the date that the swap leg matures.
The fixed_rate field (21)

The fixed_rate field stores the rate for a fixed swap leg. The amount is expressed as a
floating point number (e.g. ‘0.055’ represents a fixed rate of 5.5%).
The day_count_code field (18)

This field specifies the convention used for counting days in calculating the amounts
of interest flows. The possible entries in this field (such as ACT/360, 30/360, etc.) are
stored in the day_count_domain.
The accrual_date_roll_code field (39)

This field specifies the convention used for deciding how period begin and end dates
roll. The possible entries in this field (such as FOLLOW, MOD_FOLLOW, etc.) are
stored in the date_roll_domain.
The accrual_day_count_code field (44)

If interest is accrued using a day count basis different from the basis used to determine
payment dates, this field stores that accrual day count code. See day_count_code,
above.

Amortization (amort_) fields in the swap_leg_header table
The amortization fields are only needed to describe swap legs in which the principal
amount is amortized.
The amort_start_date field (14)

The amort_start_date field specifies the date of the first amortization event. It
corresponds to the payment of the first amortized cashflow, not the start date of the
first amortization period.
The amort_frq_code field (12)

This field specifies the frequency with which the amortization events occur.
The amort_pay_amount field (42)

If amortization is by equal payments, then the amort_pay_amount field stores the
amount of principal in each payment. This field only applies if the structure_code of
the swap leg is ‘EQ_PRIN’ or ‘CUSTOM’. Otherwise, the value in this field should be
zero.
Payment (payment_) fields in the swap_leg_header table
The payment fields in the swap_leg_header table characterize the payment structure
of a swap leg. The payment fields differ from the flow fields of the swap_leg_header
table in that the payment fields describe the actual exchange of monies. The flow fields
store the parameters needed to calculate the payments.
The payment_start_date field (26)

The payment_start_date field specifies the first payment date for the swap leg. This is
useful for defining legs with stub (short) periods at the beginning of the swap. For
example, on a floating swap leg with the floating rate calculated every three months,
the first interest payment could be set to occur in one month. This first period is
considered a stub period, and may use a reference index term different from the rest of
the swap.
The payment_frq_code field (29)

The payment_frq_code gives the frequency of the payments (‘MTH,’ ‘QTR,’ etc.).
The set of acceptable values is stored in the frq_domain table. The payment frequency
should always be equal to or less than the calculation frequency stored in the
flow_calc_frq field. Flows can be calculated more frequently than they are paid,
resulting in compounding.
The flow_timing_code field (4)

The flow_timing_code field indicates when in the period the payment of the flow
occurs. The possible values are listed in the flow_timing_domain. It can either be paid
at the beginning of the period (‘BEG_PER’) or the end of the period (‘END_PER’).

The payment_date_roll_code field (17)
The payment_date_roll_code field states the date roll convention that the swap leg
payments will follow. The values for this table migrate from the date_roll_domain.
The payment_lag_day_type_code field (27)

The payment_lag_day_type_code indicates whether the payment_lag_term is
measured in business days (‘BUS’) or calendar days (‘CAL’). The former adjusts for
weekends and holidays. The latter does not check for valid business days when
counting, but if a date roll convention is specified, it will roll to a business day for the
end date.
The business counting convention is equivalent to the calendar convention with a
flow_calc_date_roll of ‘FOLLOWING’.
The payment_lag_term field (28)

The payment_lag_term permits you to specify the actual payment as an offset from
the period begin or end date as specified in the flow_timing_code. For example, if the
value of this term is 2 and the flow_timing_code is ‘END_PER,’ then the actual
payment will occur two days after the end of the period. To express that the actual
payment occurs two days before the end of the coupon period, use a
payment_lag_term of (-2).
Compounding (compound_) fields in the swap_leg_header table
Compounding fields apply to cases where the flows in a swap leg are calculated more
frequently than they are paid, e.g. calculated quarterly and paid semiannually. Stated
another way, whenever flow_calc_frq_code is more frequent than the
payment_frq_code, compounding occurs. Three fields in the swap_leg_header table
define the compounding characteristics of the swap leg interest flows:
The compound_type_code field (15)

The compound_type_code indicates how interim interest payments are handled.
Three values are possible. If compound_type_code is ‘NONE’, no compounding
occurs; a value of ‘FLAT’ means the payment for the previous period is compounded
at the reference index rate set for the current period. ‘SPREAD’ means the payment is
compounded at the index plus a spread.
The compound_spread_rate field (16)

The compound_spread_rate specifies the spread applied to the compounding rate.
The value in this field is expressed as a floating point number. If the
compound_type_code value is ‘NONE’ or ‘FLAT’, the compound_spread_rate is 0.
The compound_calc_timing_code field (47)

This field is not implemented in version 5.0 of the Infinity applications.

Flow Calculation (flow_calc_) fields in the swap_leg_header table
The flow fields in the swap_leg_header table govern the calculation of a swap’s
cashflows. Most of the flow_ fields are populated with values from the domain tables.
The flow_calc_start_date field (36)

The flow_calc_start_date field specifies the date of the beginning of the calculation
period of the first compounding flow. The value of this field is NULL for a fixed leg
without compounding. Because zero coupon swaps compound, they would have a
flow_calc_start_date.
The flow_calc_frq_code field (22)

The flow_calc_frq_code field stores a code that reflects the frequency with which
floating flows are calculated. Fixed swap legs without compounding have a
flow_calc_frq_code of ‘NON’, meaning no frequency interval. The range of codes is
stored in the frq_domain table.
The flow_calc_timing_code field (7)

The flow_calc_timing_code field indicates at what point during the period the swap leg
flows are calculated. Three values (as listed in the flow_calc_timing_domain table) are
possible. A ‘BEG_PER’ flow calculation is made on the beginning date of the flow.
An ‘ARREAR’ flow calculation is made at the end of the period. An ‘ADVANCE’
flow calculation is made in the previous period.
The flow_calc_code field (46)

The flow_calc_code field describes the method used for calculating the amount of the
flow (‘SIMPLEINT,’ or ‘PVSIMPLEINT’), simple interest or the present value of a
simple interest payment. The flow_calc_domain stores the possible codes.
The flow_rate_calc_code field (23)

The flow_rate_calc_code describes the method used to calculate the floating rate. The
Infinity Data Model allows three choices: an unweighted average (‘AVG_UNWT’), a
weighted average (‘AVG_WT’) and a single reset index on the posted date (‘INDEX’).
The codes migrate from the flow_rate_calc_domain.
The flow_calc_date_roll_code field (32)

The flow_calc_date_roll_code defines how the rate calculation date should roll if it
lands on a non-business day. The typical behavior is to roll to the preceding business
day (‘PRECEDING’). The full range of possible values is stored in the
date_roll_domain.
The flow_calc_lag_term field (35)

The flow_calc_lag_term field indicates the number of days prior to a period that the
rate is calculated for that period. For example, a flow_calc_lag_term of 2 means that
each floating rate is calculated 2 days prior to the beginning of the period.
The flow_calc_lag_day_type_code field (34)

The flow_calc_lag_day_type_code indicates whether business days or calendar days
are counted when applying lag days to rate resets. The choices for the code are ‘BUS’

for business days, and ‘CAL’ for calendar days. Following the convention for business
days means that weekends and holidays are not counted; only business days are
considered.
The flow_calc_weekday_code field (48)

The flow_calc_weekday_code indicates whether a flow will be calculated on a specific
weekday (on or following the reset). This is commonly used for constant maturity
swaps.
Reset (reset_) fields in the swap_leg_header table
Resets apply only to floating rates. For the fixed leg of a swap, the reset fields should
be left NULL. A reset occurs when a floating rate is set from a reference index. In the
standard floating rate swap leg, each flow calculation requires only one reset.
Common structures in the market are reset quarterly and calculated quarterly and reset
and calculated semiannually. The table design permits more complicated structures.
Indexes may be reset daily, then averaged for a payment calculation made quarterly,
for example.
The reset_frq_code field (33)

The reset_frq_code field indicates the frequency with which rates are sampled (reset)
for the swap leg. The reset_frq_code should be at least as frequent as the
flow_calc_frq_code and payment_frq_code. In some cases, rates can be reset much
more frequently than flows are calculated or paid.
The frequency of rate resetting is also related to the value in the flow_rate_calc_code
field. If the flow_rate_calc_code is ‘INDEX,’ then the flow rate is calculated from a
single index quote on a posted date; the reset_frq_code should be the same as the
flow_calc_frq_code. If the flow rate is calculated from an average
(flow_rate_calc_code of ‘AVG_UNWT’ or ‘AVG_WT’) of resetting events, then the
reset frequency should be more frequent than the flow_calc_frequency.
The reset_calc_align_code field (2)

For floating swap legs with averaging rates, the reset_calc_align_code field indicates
whether the beginning of the reset period coincides with the beginning of the accrual
period. If the flow calculation period and reset begin dates coincide, the value in the
field is ‘MATCH’; ‘NOMATCH’ signifies that the dates do not align. For fixed legs
and for non-averaging floating legs, this field will contain a NULL value.
The reset_period_term field (38)

The reset_period_term indicates the length of the period in days if the reset period is a
relative period longer than one day.
The reset_day_of_month field (45)

The reset_day_of_month field is used with a monthly reset frequency to specify the
day of the month on which the reset occurs when there is averaging. For example, if a

rate were reset by an average over three months of the quote on the 15th of each
month, the value in this field would be 15.
The reset_weekday_code field (3)

The reset_weekday_code is used with a weekly reset frequency to specify the day of
the week on which the reset occurs. For example, if a rate were reset by an average
over one month of Monday quotes, the value in this field would be MON.
The manual_reset_b field (40)

This field is not implemented in v5.0 Infinity applications.
The reset_cutoff_term field (41)

The reset_cutoff_term expresses the number of days before each reset event that the
sampling of the reference index is stopped. This comes into play if a floating rate is
determined from an average of samples of the reference index. For example, consider
a reset with a reset_frq_code of ‘DLY’ (daily) and a reset_cutoff_term of 3. This
indicates that the daily sampling of the reference index will be stopped three days
prior to the resetting of the floating rate.
The reset_convert_before_average field (49)

For daily averaging CP rates, the system can convert the CP rate to yield and then
average, or it can average them and then convert the average. This field is 1 if
conversion is to happen before averaging, and 0 otherwise.
Reference index (ref_index_) fields in the swap_leg_header table
The ref_index_ fields describe the index against which a floating leg of a swap is set.
For a fixed swap leg, these fields do not apply; leave them NULL. The values in the
reference index fields must be consistent with the entries in the
ref_index_term_source table.
The ref_index_currency_code field (8)

The ref_index_currency_code specifies the currency in which the index is
denominated.
The ref_index_code field (9)

The ref_index_code specifies the name of the index, e.g. ‘LIBOR’, ‘BA,’ etc. The full
list of choices is found in the ref_index_list table. As with other list tables, additional
reference indexes may be added to the ref_index_list table as needed.
The ref_index_term field (11)

The ref_index_term gives the tenure of the index, e.g. 1-month, 3-month, etc.,
expressed as a number of days. The term is expressed in the 30/360 daycount
convention.

The ref_index_spread_rate field (31)
The ref_index_spread_rate is the amount, if any, that is to be added to the reference
index to calculate the actual rate to be used in the payment calculation.
The ref_index_factor field (43)

The ref_index_factor specifies a multiplier to be applied to the value of the reference
index. Note: If both a spread and a multiplier are applied to the reference index,
multiply by the factor and then add the spread to calculate the rate for that period.
The ref_index_source_code field (10)

The ref_index_source_code identifies the source of the reference index quote, e.g.
‘ISDA’, ‘LIBO’, and ‘T3750’. See the ref_index_source_list e for a listing of the
possible reference index sources. As with other lists, additional reference indexes may
be added to the ref_index_source_list as needed.

Simple Swap Structures in the swap_leg_header Table
The following two examples are for a simple fixed-for-float interest rate swap. As
mentioned before, each side of the swap represents a separated “swap leg” and hence
is a separate record in the swap_leg_header table.
The fixed side is 2-year, semiannual, 4% (this record was generated using the Infinity
Trader application):
sec_id 2329
reset_calc_align_code NULL
reset_weekday_code NULL
flow_timing_code END_PER
swap_leg_code FIXED
structure_code BULLET
flow_calc_timing_code NULL
ref_index_currency_code NULL
ref_index_code NULL
ref_index_source_code NULL
ref_index_term NULL
amort_frq_code NON
act_notl_code NOTIONAL
amort_start_date NULL
compound_type_code NONE
compound_spread_rate 0.00
payment_date_roll_code MOD_FOLLOW
day_count_code ACT/360
initial_exchange_amount 0.00
final_exchange_amount 0.00
fixed_rate 0.04
flow_calc_frq_code NON
flow_rate_calc_code NULL
legal_agmt_code NULL
maturity_date Sep 20 1996
payment_start_date Mar 20 1995
payment_lag_day_type_code BUS
version 5.2 Simple Swap Structures in the swap_leg_header Table 8-25

sec_id 2329
payment_lag_term 0
payment_frq_code SA
principal_amount 1000000.00
ref_index_spread_rate 0.00
flow_calc_date_roll_code NULL
reset_frq_code NON
flow_calc_lag_day_type_code NULL
flow_calc_lag_term 0
flow_calc_start_date NULL
start_date Sep 20 1994
reset_period_term 0
accrual_date_roll_code MOD_FOLLOW
manual_reset_b 0
reset_cutoff_term 0
amort_pay_amount 0.00
ref_index_factor NULL
accrual_day_count_code ACT/360
reset_day_of_month 0
flow_calc_code SIMPLEINT
compound_calc_timing_code NULL
flow_calc_weekday_code NULL
reset_convert_before_average 1
Figure 8-16. The swap_leg_header table populated with sample data for a simple fixed swap leg.

The following floating leg is more complex. It is a 2-year swap paying semiannually,
with an index based on the formula: (1.2 x 6-month USD LIBOR) + 50 basis points,
non-compounding (again, this was entered using the Trader application). Notice that
the fields pertaining to the reference index and flow calculation (which were null in
the fixed leg) now contain data:
sec_id 2330
swap_leg_code FLOAT
flow_calc_timing_code BEG_PER
ref_index_currency_code USD
ref_index_code LIBOR
ref_index_source_code T3750
ref_index_term 180
amort_frq_code NON
act_notl_code NOTIONAL
compound_type_code NONE
compound_spread_rate 0.00
initial_exchange_amount 0.00
final_exchange_amount 0.00
fixed_rate 0.00
flow_calc_frq_code SA
flow_rate_calc_code INDEX
maturity_date Sep 20 1996
payment_start_date Mar 20 1995
payment_lag_term 0
payment_frq_code SA
version 5.2 Simple Swap Structures in the swap_leg_header Table 8-27

sec_id 2330
flow_calc_date_roll_code PRECEDING
reset_frq_code SA
flow_calc_lag_day_type_code BUS
flow_calc_lag_term -2
flow_calc_start_date Mar 20 1995
start_date Sep 20 1994
reset_period_term 0
manual_reset_b 0
reset_cutoff_term 0
ref_index_factor 1.20
accrual_day_count_code ACT/360
Figure 8-17. A floating swap leg stored in the swap_leg_header table.

Index Amortizing Swaps and the swap_leg_index_amort_header table
An index amortizing swap leg is saved as a row in both the swap_leg_header and the
swap_leg_index_amort_header tables. The swap_leg_index_amort_header table
defines those additional parameters of an index amortizing swap leg which are not
included in the swap_leg_header table.
Table name: swap_leg_index_amort_header

ref_index_currency_code 0 Currency_Code:char(3)
ref_index_code 0 Ref_Index_Code:char(12)
ref_index_term 0 Term:int(4)
ref_index_source_code 0 Ref_Index_Source_Code:char(12)
ref_index_factor 0 Ref_Index_Factor:float(8)
ref_index_spread_rate 0 Rate:float(8)
base_rate 1 Rate:float(8)
clean_up_call 1 Amount:float(8)
lockout_period 1 Amount:float(8)
amort_from_original_b 0 Bool:bit(1)
interest_curve_spread_rate 1 Rate:float(8)
interest_index_spread_rate 1 Rate:float(8)
amort_curve_spread_rate 1 Rate:float(8)
amort_index_spread_rate 1 Rate:float(8)
amort_calc_date_roll_code 1 Date_Roll_Code:char(12)
amort_calc_lag_term 1 Term:int(4)
amort_calc_lag_day_type_code 1 Lag_Day_Type_Code:char(3)
amort_calc_timing_code 1 Flow_Calc_Timing_Code:char(7)
Figure 8-18. Structure of the swap_leg_index_amort_header table.
The base_rate is used to determine the amortization schedule, which is defined in

terms of changes in relation to the base rate. The clean_up_call is the percent fraction
of the original notional principal such that if the principal falls below this fraction it
will automatically be reduced to zero. The lockout_period defines the period during
which there is no amortization, given in years. The amort_from_original_b setting
indicates whether the amortization is from the original principal or the outstanding
principal.
The interest_curve_spread_rate indicates the spread applied to the forecast/discount

curve in a floating leg. The interest_index_spread_rate is the spread applied to the
reference index in a floating leg.
The amort_curve_spread_rate indicates the market spread between the rate of the
curve underlying the index used for amortization and the rate of the discount curve.
The amort_index_spread_rate is the contractual spread on top of the reference index
used for amortization.
version 5.2 Index Amortizing Swaps and the swap_leg_index_amort_header table 8-29
The amort_calc_date_roll_code defines how the amortization calculation date should
roll if it lands on a non-business day. The full range of possible values is stored in the
date_roll_domain. The amort_calc_lag_term indicates the number of days prior to a
period that the amortization rate is calculated for that period. The
amort_calc_lag_day_type_code indicates whether business days or calendar days are
counted when applying lag days to rate resets. The amort_calc_timing_code indicates
at what point during the period that index amortizing swap leg flows are calculated.
Three values (as listed in the flow_calc_timing_domain) are possible. A BEG_PER
flow calculation is made on the beginning date of the flow. An ARREAR flow
calculation is made at the end of the period. An ADVANCE flow calculation is made
in the previous period.
The following example is an index amortizing swap leg with a base rate of 3%, a
clean-up call of 1%, an amortization curve spread of 1%, and an amortization index
spread of 2%.
This record was generated using the Infinity Trader application:
Table name: swap_leg_index_amort_header
sec_id 2055
ref_index_term 180
ref_index_source_code ISDA
base_rate 0.0300
clean_up_call 0.0100
lockout_period 1.002740
amort_from_original_b 1
interest_curve_spread_rate 0.0000
interest_index_spread_rate 0.0000
amort_curve_spread_rate 0.0100
amort_index_spread_rate 0.0200
amort_calc_date_roll_code NULL
amort_calc_lag_term 0
amort_calc_lag_day_type_code NULL
amort_calc_timing_code BEG_PER
Figure 8-19. The swap_leg_index_amort_header table populated

with sample data for an index amortizing swap leg.

Bonds and the bond_attribute and bond_header Tables
The tables supporting bonds are different in several ways from those discussed so far.
First, the bond tables include a bond_attribute table. This table exists because bonds
within certain categories often have characteristics in common. For example, US
Treasuries are always quoted in percent of par in 32nds, whereas Japanese government
bonds have a tick size of 1/1000th, and so on. These characteristics are captured in the
bond_attribute table so that they do not have to be repeated for every bond in the
bond_header table.
The fields in the bond_attribute table are:
Table name: bond_attribute

bond_type_code 0 Bond_Type_Code:char(12) PK bond_type_default
issuer_inst_code 0 Inst_Code:char(12) PK
currency_code 0 Currency_Code:char(3) PK
tick_size_code 1 Tick_Size_Code:char(12)
base_trade_amount 1 Amount:float(8)
interest_tax_rate 1 Rate:float(8)
principal_tax_rate 1 Rate:float(8)
Figure 8-20. Structure of the bond_attribute table.
The following table shows the entries for US Treasury bonds and Japanese
government bonds:
Table name: bond_attribute
bond_type_code JGB UST
issuer_inst_code JPGVT USGVT
currency_code JPY USD
tick_size_code TICK_1000 TICK_32
quote_method_code PCPAR PCPAR
base_trade_amount 0.00 0.00
interest_tax_rate NULL NULL
principal_tax_rate NULL NULL
Figure 8-21. UST Bonds and JGBs defined in the bond_attribute table.
version 5.2 Bonds and the bond_attribute and bond_header Tables 8-31
Attributes apply to groups of bonds. The individual bonds themselves are defined in
the bond_header table. As in the case of the swap_leg_header table, the bond_header
table has one record for every bond defined in the database, and hence must have
fields to accommodate all types of bonds. Therefore, depending on the bond type,
many fields may be zero or null.
Table name: bond_header

announce_date 1 Date:datetime(8)
auction_date 1 Date:datetime(8)
bond_name 1 Bond_Name:char(15)
bond_type_code 0 Bond_Type_Code:char(12)
interest_rate 1 Rate:float(8)
maturity_date 1 Date:datetime(8)
payment_frq_code 1 Frq_Code:char(3)
payment_start_date 1 Date:datetime(8)
start_date 1 Date:datetime(8)
issuer_inst_code 0 Inst_Code:char(12)
redemption_amount 1 Amount:float(8)
payment_date_roll_code 1 Date_Roll_Code:char(12)
accrual_date_roll_code 1 Date_Roll_Code:char(12)
payment_day_count_code 1 Day_Count_Code:char(12)
accrual_day_count_code 1 Day_Count_Code:char(12)
penultimate_pay_date 1 Date:datetime(8)
accrual_start_date 1 Date:datetime(8)
ex_div_offset_day 0 Offset_Day:int(4)
issue_price 1 Price:float(8)
minimum_trade_amount 1 Amount:float(8)
minimum_increment_amount 1 Amount:float(8)
ytm_at_issue 1 Yield:float(8)
tax_reclaim_offset_day 1 Offset_Day:int(4)
Figure 8-22. The structure of the bond_header table.
In addition, there is a table bond_type_default, which is used in conjunction with the

Fin++ class libraries. Like the bond_attribute table, this table gives additional default
values, such as day count, which are relevant to sovereign debt.

Table name: bond_type_default
Column name NULL Datatype PK FK: Parent Table

bond_type_code 0 Bond_Type_Code:char(12) PK
payment_day_count_code 1 Day_Count_Code:char(12)
accrual_day_count_code 1 Day_Count_Code:char(12)
ex_div_offset_day 0 Offset_Day:int(4)
Figure 8-23. The structure of the bond_type_default table.
The following example shows sample bonds as entered through Infinity’s Trader
application.
sec_id 1038 1955
announce_date May 26 1995 Jun 20 1995
auction_date May 26 1995 Jun 20 1995
bond_name NULL NULL
bond_type_code UST CANADA
interest_rate 0.075 0.10
maturity_date May 26 2005 Jun 20 2005
payment_frq_code SA SA
payment_start_date Nov 26 1995 Dec 20 1995
start_date May 26 1995 Jun 20 1995
issuer_inst_code USGVT AUSTRIAGVT
redemption_amount 1.00 1.00
payment_date_roll_code FOLLOWING FOLLOWING
accrual_date_roll_code FOLLOWING FOLLOWING
payment_day_count_code ACT/ACT ACT/365
settlement_term 1 0
accrual_day_count_code ACT/ACT ACT/365
penultimate_payment_date Nov 26 2004 Dec 20 2004
accrual_start_date May 26 1995 Jun 20 1995
ex_div_offset_day 0 0
issue_price 1.00 1.00
version 5.2 Bonds and the bond_attribute and bond_header Tables 8-33
sec_id 1038 1955
minimum_trade_amount 0.00 0.00
minimum_increment_amount 0.00 0.00
ytm_at_issue 0.00 0.00
tax_reclaim_offset_day 0 0
Figure 8-24. Sample bonds entered in the bond_header table.
Caps and Floors and the cap_floor_header Table

The cap_floor_header table is similar to the swap_leg_header table. Since a cap is an
option, however, the parametric data will generate a set of option flows.
Table name: cap_floor_header

reset_calc_align_code 1 Reset_Calc_Align_Code:char(7)
reset_weekday_code 1 Weekday_Code:char(3)
flow_calc_code 1 Flow_Calc_Code:char(12)
flow_timing_code 1 Flow_Timing_Code:char(7)
structure_code 1 Structure_Code:char(12)
flow_rate_calc_code 1 Flow_Rate_Calc_Code:char(12)
amort_frq_code 1 Frq_Code:char(3)
amort_start_date 1 Date:datetime(8)
cap_floor_code 1 Cap_Floor_Code:char(5)
day_count_code 1 Day_Count_Code:char(12)
flow_calc_frq_code 1 Frq_Code:char(3)
legal_agmt_code 1 Legal_Agmt_Code:char(20)
payment_lag_day_type_code 1 Lag_Day_Type_Code:char(3)
payment_lag_term 1 Term:int(4)
payment_start_date 1 Date:datetime(8)
principal_amount 1 Amount:float(8)
flow_calc_lag_day_type_code 1 Lag_Day_Type_Code:char(3)
flow_calc_lag_term 1 Term:int(4)
flow_calc_date_roll_code 1 Date_Roll_Code:char(12)
reset_frq_code 1 Frq_Code:char(3)
flow_calc_start_date 1 Date:datetime(8)
flow_calc_timing_code 1 Flow_Calc_Timing_Code:char(7)
strike_price 1 Price:float(8)

manual_reset_b 0 Bool:bit(1)
ref_index_factor 1 Ref_Index_Factor:float(8)
reset_cutoff_term 1 Term:int(4)
reset_period_term 1 Term:int(4)
amort_pay_amount 1 Amount:float(8)
compound_calc_timing_code 1 Flow_Calc_Timing_Code:char(7)
reset_day_of_month 1 Day:int(4)
flow_calc_weekday_code 1 Weekday_code:char(3)
binary_payoff_amount 1 Amount:float(8)
reset_convert_before_average 0 Bool:bit(1)
Figure 8-25. The structure of the cap_floor_header table.
The data fields that govern the structure of the options are the cap_floor_cod, the
strike_price, and the binary_payoff_amount. The cap_floor_code determines whether
the security is a cap or a floor. The owner of a cap is compensated as rates raise above
a certain level; a floor owner is compensated as rates fall below a certain level. The
strike_price determines the level. In a standard cap or floor, the compensation equals
the difference between the strike price and the rate. If the cap is a binary cap or floor,
however, the compensation is a fixed amount. This fixed amount would be stored in
the field binary_payoff_amount.
Except for cap_floor_code, strike_price, and binary_payment_amount, the fields and

the groups of fields function the same as those used to model a swap. They define a
series of floating flows which become fixed in the future according to a reference
index. If the security is a floor, the cap_floor_code in the header table would be
FLOOR and put_call_code in the corresponding flow table would be PUT. If the
security is a cap, CAP goes in the cap_floor_code field and CALL goes in the
put_call_code field of the flow table.
This table structure offers flexibility in defining caps. You can construct an amortizing
cap by editing the principal_amount field in the flow table. Similarly, the term of the
index can be changed from flow to flow. This makes possible caps with short
underlying periods in the first or last flow, as well as caps where the term varies for
some other reason. For example, you can construct a 3-year cap which caps a 3-month
index for the first year and a 6-month index for the rest of the life of the deal. You can
also change the level of protection from flow to flow by changing the strike_price field
in the flows themselves. This makes it possible to construct a five-year cap, for
example, which begins with a strike price of 10%, and, over the life of the instrument,
moves to 14%.
Note: a structure_code of ‘BULLET’, ‘EQ_PRIN,’ or CUSTOM’ may be used, but

‘ANNUITY’ may not, since it refers to interest amounts which cannot be known in an
option such as a cap. In addition, certain types of caps, such as compounding or binary
caps, which can be structured in the data model, are not yet supported in Infinity v5.0
applications.
version 5.2 Caps and Floors and the cap_floor_header Table 8-35
As an example of this flexibility, the following shows a 2-year, semiannual, 6% cap on
3-month USD LIBOR, on a principal of $1,000,000:
sec_id 1533
ref_index_source_code ISDA
ref_index_term 90
flow_rate_calc_code INDEX
amort_frq_code NON
cap_floor_code CAP
flow_calc_frq_code NON
maturity_date Jul 7 1997
payment_frq_code SA
payment_lag_term 0
payment_start_date Jan 7 1996
flow_calc_lag_day_type_code BUS
flow_calc_lag_term 0
flow_calc_date_roll_code PRECEDING
reset_frq_code SA
flow_calc_start_date NULL
flow_calc_timing_code BEG_PER
start_date Jul 7 1995

sec_id 1533
strike_price 0.06
manual_reset_b 0
reset_cutoff_term 0
reset_period_term 0
binary_payoff_amount NULL
Figure 8-26. A 2-year, semiannual, 6% cap on 3-month USD LIBOR stored in

the cap_floor_header table.
Exchange-traded Securities and the exchange_header Table

The exchange tables are designed to handle exchange-traded instruments, specifically
money market futures, options on money market futures, bond futures, and options on
bond futures. As in the case of money market instruments and bonds, there are two
tables to capture data, the exchange_attribute table for generic data pertaining to
series of instruments, and the exchange_header table for records relating to specific
contracts. The contract_series_sec_type table is used to differentiate between money
market futures and bond futures.
version 5.2 Exchange-traded Securities and the exchange_header Table 8-37

Table name: exchange_attribute

exchange_code 0 Exchange_Code:char(12) PK
contract_series_code 0 Contract_Series_Code:char(12) PK contract_series_sec_type
sec_type_code 0 Sec_Type_Code:char(12) PK contract_series_sec_type
future_underlying_sec_id 1 Sec_Id:int(4)
future_settlement_sec_id 1 Sec_Id:int(4)
future_payout_sec_id 1 Sec_Id:int(4)
contract_size_amount 1 Amount:float(8)
minimum_move_price 1 Price:float(8)
month_cycle_code 1 Month_Cycle_Code:char(12)
settlement_method_code 1 Settlement_Method_Code:char(12)
strike_interval_price 1 Price:float(8)
tick_value_amount 1 Amount:float(8)
contracts_traded 1 Contracts_Traded:int(4)
Figure 8-27. Structure of the exchange_attribute table.
Futures and options are securities defined in terms of a trade that may take place in the
future. In the case of a futures contract, the future exchange of instruments is modelled
in the exchange_attribute table.
In the exchange_attribute table, the future_underlying_sec_id,

future_settlement_sec_id, and future_payout_sec_id fields lists the securities to be
traded in the future in exchange for the currency of the contract. There are three fields
to model physical settlement into one security (stored in future_underlying_sec_id) or
two securities (stored in future_underlying_sec_id and future_settlement_sec_id), or a
future payout into cash (and the currency of the payout would be modelled as a
security and stored in future_payout_sec_id).
The contract_size_amount field gives the amount of the underlying security to be

traded. The settlement_method_code field determines whether settlement of the
contract is by actual delivery of the underlying or in cash.
Table name: exchange_header

exercise_code 1 Exercise_Code:char(12)
contract_series_code 0 Contract_Series_Code:char(12)
exchange_code 0 Exchange_Code:char(12)
last_trade_date 1 Date:datetime(8)
first_trade_date 1 Date:datetime(8)
first_notif_date 1 Date:datetime(8)
last_notif_date 1 Date:datetime(8)
first_ex_delivery_date 1 Date:datetime(8)

last_ex_delivery_date 1 Date:datetime(8)
put_call_code 1 Put_Call_Code:char(4) put_call_domain
option_underlying_sec_id 1 Sec_Id:int(4) sec
contract_name 1 Contrace_Name:char(12)
Figure 8-28. Structure of the exchange_header table.
In the exchange_header table, the first_trade_date and last_trade_date fields define

the range of dates on which the contract may be traded.
If the settlement method for the contract is by delivery of the underlying (this is
referred to as physical settlement), then the first_notif_date and last_notif_date define
the range of dates within which the seller must notify the buyer as to what actual
security is to be delivered. The fields first_ex_delivery_date and last_ex_delivery_date
define the ranges within which that delivery must occur.
The maturity_date is the date the obligations or rights associated with the contract
expire. If the settlement method is cash, then this is the last_trade_date, since no
physical delivery takes place. If physical delivery does occur, the maturity date is the
last exercise or delivery date ( last_ex_delivery_date).
In the exchange_attribute table, options on futures are modelled by entering the

sec_id of the underlying futures contract in the future_underlying_sec_id column.
The following table shows the exchange_attribute entries for the 3-month Eurodollar
money market futures series and the 3-month Eurodollar options series (based on
contracts in the futures series). Here the underlying security 1012 is a relative LIBOR
money market with a 3-month maturity term.
exchange_code IMM IMM
contract_series_code EURODOLLAR3M EURODOLLAR3M
sec_type_code FUTURE EXCH_OPTION
future_underlying_sec_id 1012 NULL
future_settlement_sec_id NULL NULL
future_payout_sec_id NULL NULL
contract_size_amount 1000000.00 1000000.00
minimum_move_price 1.00 1.00
month_cycle_code MJSD_QTR MJSD_QTR

sec_type_code FUTURE EXCH_OPTION
settlement_method_code CASH CASH
settlement_term 1 1
strike_interval_price 0.00 0.25
tick_value_amount 25.00 25.00
contracts_traded 40 20
quote_method_code MM_FUTURE MM_FUTURE
Figure 8-29. The 3-month Eurodollar futures series and options series stored in the
exchange_attribute table.

As reproduced below, the exchange_header table shows records for actual March
1995 contracts based on the above futures series and options series. In the
exchange_header entry for the option contract, note the option_underlying_sec_id
value of 53, showing that the futures contract depicted to the left is used as the
underlying.
Table name: exchange_header
sec_id 53 1386
exercise_code NULL AMERICAN
last_trade_date Mar 13 1995 Mar 13 1995
first_trade_date Jun 23 1992 Jan 1 1994
first_notif_date NULL NULL
last_notif_date NULL NULL
first_ex_delivery_date NULL NULL
last_ex_delivery_date NULL NULL
maturity_date Mar 13 1995 Mar 13 1995
put_call_code NULL CALL
strike_price 0.00 98.00
option_underlying_sec_id NULL 53
contract_name NULL NULL
Figure 8-30. Entries in the exchange_header table for March 1995 contracts on the 3-month
Eurodollar futures series and options series.
In summary, the method for entering exchange-traded futures or options is to first

define the futures or options series in the exchange_attribute table and then define
each contract in the exchange_header table.

Money Markets and the money_market_header Table
This category of securities covers a variety of short-term instruments, including
discounts and interest bearing securities. The issuers range from governments
(Treasury bills) to large corporations (CD’s, commercial paper, etc.). As with bonds,
money markets have an attribute table to capture the characteristics that are common
to all instruments within a given category. The principal for money market securities is
defined, as with bonds, to be unity.
The structures of the attribute and header tables are:
Table name
money_market_attribute
money_market_type_code 0 Money_Market_Type_Code:char(12) PK
money_market_header
money_market_type_code 0 Money_Market_Type_Code:char(12)
fixed_rate 1 Rate:float(8)
issuer_inst_code 1 Inst_Code:char(12)
Figure 8-31. The structures of the money_market_attribute and money_market_header tables.

The table below shows two sample entries in the money_market_attribute table:
Table name: money_market_attribute
money_market_type_code LIBOR TBILL
day_count_code ACT/360 ACT/360
payment_date_roll_code MOD_FOLLOW FOLLOWING
payment_frq_code NON NON
quote_method_code SMPL_INT DISCOUNT
settlement_term 2 0
accrual_date_roll_code MOD_FOLLOW FOLLOWING
Figure 8-32. money_market_attribute table entries for USD LIBOR instruments and T-Bills.
For the money_market_header, the entry is as follows:
Table name: money_market_header
sec_id 1488
money_market_type_code LIBOR
fixed_rate 0.063750
issuer_inst_code NULL
maturity_date Jun 13 1995
start_date Mar 17 1995
Figure 8-33. money_market_header entry for a 3-month LIBOR instrument.
version 5.2 Money Markets and the money_market_header Table 8-43

OTC Options and the otc_option_header Table
The otc_option_header table is designed to handle a generally defined over-the-
counter option. This table is designed to be flexible enough to accommodate many
different types of options by separating the definition of the option from the definition
of the underlying instrument. The underlying is identified only by its security id, and
its parameters are defined in the tables appropriate to that underlying instrument. The
otc_option_header table also allows a settlement security to be defined, so as to allow
an option on an existing trade.
Table name: otc_option_header

otc_option_underlying_code 1 Otc_Option_Underlying_Code:char(9)
exercise_code 1 Exercise_Code:char(12)
put_call_code 1 Put_Call_Code:char(4)
settlement_method_code 1 Settlement_Method_Code:char(12)
option_event_price 1 Price:float(8)
option_type_code 1 Option_Type_Code:char(12)
first_exercise_date 1 Date:datetime(8)
settlement_sec_id 1 Sec_Id:int(4)
underlying_sec_id 1 Sec_Id:int(4)
rebate_amount 1 Amount:float(8)
isexercisable 0 Bool:bit(1)
exercise_schedule_id 1 Sec_Id:int(4)
Figure 8-34. Structure of the otc_option_header table.
The settlement_method_code indicates, if the option is exercised, whether the

settlement is accomplished through cash settlement or physical delivery of the
underlying. The settlement_term is the time from the exercised date to the actual
settlement. The option_event_price holds the price that triggers an event related to the
option, for example the knock out price for a down-and-out option. The
underlying_sec_id is the security on which the option is written and the
settlement_sec_id is the security exchanged for the underlying security if the option is
exercised. If the option can only be exercised after a certain date, that date is recorded
in the first_exercise_date field.
Both rebate_amount and isexercisable apply to barrier options only. isexercisable

indicates whether the option has come into (or gone out of) existence, relative to a
barrier that has been hit. rebate_amount is the rebate you receive on your premium if
the option is knocked out, or is never knocked in.

Some otc options, like Bermuda Options, only permit exercising the option on select
dates. For these options, the exercise schedule will be stored in two other tables,
option_exercise_schedule and option_exer_schedule_dates. The
exercise_schedule_id in the otc_option_header represents the primary key in the
exercise schedule tables.
The following example is for a swaption. It represents a 3-year European swaption

(maturing on June 12, 1998) to enter into a 5-year, semiannual, fixed for 6-month
LIBOR swap. The option type is European, as the start and maturity dates of the
underlying swap are known. The tables below show the entry for the swaption in the
otc_option_header table. The entries for the swap legs would be in the
swap_leg_header table.
Table name: otc_option_header
sec_id 2043
otc_option_underlying_code SECURITY
exercise_code EUROPEAN
put_call_code PUT
settlement_method_code PHYSICAL
settlement_term 0
strike_price 0.00
option_event_price 0.00
option_type_code SWAPTION
maturity_date Jun 12 1998
first_exercise_date Jun 12 1995
settlement_sec_id 2042
underlying_sec_id 2041
rebate_amount NULL
isexercisable 1
exercise_schedule_id NULL
Figure 8-35. An entry for a swaption in the otc_option_header table.
For bond options, the bond_spread_benchmark table is used to price an underlying

bond as a benchmark bond plus a spread.
version 5.2 OTC Options and the otc_option_header Table 8-45

Table name: bond_spread_benchmark

spread_set_name 0 Spread_Set_Name:varchar(30) PK
benchmark_sec_id 0 Sec_Id:int(4) PK sec
update_datetime 0 datetime:datetime(8) PK
bid_spread 1 Rate:float(8)
offer_spread 1 Rate:float(8)
spread_type_code 1 Spread_Type_Code:char(5) spread_type_domain
Figure 8-36. Structure of the bond_spread_benchmark table.
The spread_set_name column contains the name of the bond/spread set. The sec_id
refers to the bond to be priced, using a benchmark plus a spread; the
benchmark_sec_id identifies the benchmark bond itself.
update_datetime indicates what time the spread value was entered or changed.
The spread_type_code can be either YIELD or PRICE.
Table name: bond_spread_benchmark
benchmark_ bid_ offer_ spread_type_

spread_set_name sec_id update_ datetime
sec_id spread spread code
SPREADS 1420 1038 Jun 5 1995 0.03 0.03 YIELD
3:35 PM
2:20 PM
10:46 AM
10:59 AM
2:36 PM
SPREADS 2506 2461 Jul 12 1995 0.04 0.05 YIELD
4:00 PM
Figure 8-37. A bond/spread set in the bond_spread_benchmark table.

Bond Repurchase Agreements and the repo_header table
The repo_header table is used to define bond repurchase agreements. The collateral
bond is not defined in the repo_header table, since it can change over the life of the
repo. It is held in the loan_event table (see 8-48), and its parameters are defined in the
bond_attribute and bond_header tables.
Table name: repo_header

repo_type_code 0 Repo_Type_Code:char(20)
repo_day_count_code 0 Day_Count_Code:char(12)
repo_date_roll_code 0 Date_Roll_Code:char(12)
repo_roll_method_code 0 Repo_Roll_Method_Code:char(20)
cum_dividend_b 0 Bool:bit(1)
haircut 0 Rate:float(8)
repo_term 0 Term:int(4)
Figure 8-38. Structure of the repo_header table.
The repo_type_code indicates whether the repo is rolled on a basis of O/N

(overnight), OPEN, or TERM. The repo_day_count_code indicates the daycount used
when calculating the interest on the repo and when determining the deal’s ending
price. The repo_date_roll_code is unused in version 5.0 of the Infinity Data Model;
the date roll for the repo is taken from the underlying bond.
The repo_roll_method_code indicates how interest will be paid and/or accumulated

when rolling the trade: either rolling principal only while paying out interest
(PRINCIPAL), or rolling both principal and interest (PRINCIPAL_INTER).
cum_dividend_b indicates whether a coupon is to be paid or received during the term

of the repo. This field is not used in version 5.2.1 of the Infinity Data Model. The
haircut is the percentage value that will be deducted from the standard market price of
the bond. The repo_term indicates the number of days that the repurchase agreement
lasts.
The ref_index_currency_code, ref_index_code, ref_index_source_code, and

ref_index_term fields are not used for repos in version 5.2.1 of the Infinity Data
Model.
version 5.2 Bond Repurchase Agreements and the repo_header table 8-47
The following example is for an overnight repo, rolling principal only, with a 1%
haircut. This record was generated using the Infinity Repo Manager application.
Table name: repo_header
sec_id 2750
repo_type_code O/N
start_date Jul 31 1995 12:00 AM
maturity_date Aug 1 1995 12:00 AM
repo_day_count_code ACT/360
repo_date_roll_code Unknown
repo_roll_method_code PRINCIPAL
cum_dividend_b 0
haircut 0.0100
repo_term 1
ref_index_currency_code NULL
ref_index_code NULL
ref_index_source_code NULL
ref_index_term NULL
Figure 8-39. The repo_header table, populated with sample data

for a bond repurchase agreement.
The loan_event table, along with loan_event_flow_relation and

loan_event_type_domain, defines the collateral bond in a repurchase agreement.
Table name: loan_event
Column name Null Datatype PK FK:Parent table

loan_event_id 0 Loan_Event_id:int(4) PK
loan_event_type_code 0 Loan_Event_Type_Code:char(12)
event_date 0 Date:datetime(8)
repo_rate 0 Rate:float(8)
collateral_id 0 Collateral_Id:int(4)
collateral_amount 0 Amount:float(8)
collateral_price 0 Rate:float(8)
principal_amount 0 Amount:float(8)
accrued_interest 0 Amount:float(8)
Figure 8-40. Structure of the loan_event table.

The sec_id refers to the repo itself. There can be multiple entries with the same sec_id
in the loan_event table. The loan_event_id distinguishes individual events. Along with
the sec_id, this makes up the primary key. For each new security, the initial
loan_event_id will be one, and additional events will be numbered sequentially.
The loan_event_type_code is taken from the loan_event_type_domain, and defines

the nature of the loan event (ROLL, REPRICE, REDEEM, etc.).
The event_date is the date the event takes effect. The repo_rate is the loan rate for the
repurchase agreement. The collateral_id is the sec_id of the collateral bond. The
collateral_amount is the face value of the collateral bond. The collateral_price is the
value of the collateral bond after repricing. The principal_amount is the initial
principal used in repo valuation. accrued_interest is the total accrued interest on the
trade.
Table name: loan_event
sec_id 3324 3324 3324 3324
loan_event_id 1 2 3 4
loan_event_type_code CREATE ROLL ROLL CLOSE
Aug 30 1995 Aug 31 1995 Sep 1 1995 Sep 5 1995

event_date
12:00 AM 12:00 AM 12:00 AM 12:00 AM
repo_rate 0.050500 0.050500 0.051250 0.051250
collateral_id 2506 2506 2506 2506
collateral_amount 1000000.00 1000000.00 1000000.00 1000000.00
collateral_price 0.798266 0.798266 0.798266 0.798266
principal_amount 813184.754349 813184.754349 813184.754349 813184.754349
accrued_interest 0.000000 114.071750 228.143501 691.207041
Figure 8-41. The loan_event table, populated with sample data for a bond repurchase agreement.
The loan_event_flow_relation table connects a flow_id from the flow table with the
sec_id and loan_event_id combination, allowing you to determine which loan event
generated a specific flow.
version 5.2 Bond Repurchase Agreements and the repo_header table 8-49
Chapter 9
Flow Tables
In the Infinity Data Model, securities that contain cashflows (such as swaps or bonds)
store their cashflows separately in the flow table. This table identifies individual flows
by a combination primary key made up of both the sec_id and a sequential flow_id, so
that the flows can easily be identified with their security.
Once flows have been generated from the parametric definition of a security, they can
be analyzed separately from the security itself. However, it should be noted that if the
flows are edited directly, the connection to the security definition may be lost. It is also
important to note that the analytics necessary to compute cashflows are contained in
the applications or class library, and not in the Data Model.
All flows, regardless of type, are stored in the flow table. The types of allowed flows
are listed in the infsys_montage_domains, with domain_name = flow_type_domain.
The flow types include simple flows, such as principal, exchange, or fee flows,
calculated flows, such as interest or compound flows, and option flows. Therefore,
depending on the type of flow, many of the fields for a given record may be zero or
null. The application ensures that the correct fields are used for a given flow type.
The Infinity applications maintain a consistent model in terms of the flow_amount

entered for a flow: unknown amounts are listed as zero. This means that for option
flows or floating rate flows which have not been set, the flow_amount is zero until it
becomes known.
version 5.2 9-1

The flow Table
The following description of the flow table divides the fields into three functional
categories: general flow fields, index-related (i.e. floating rate) flow fields, and option-
related flow fields. In the list of attributes which follows, the letters g, i, and o indicate
general, index-related, and option-related flows respectively.
Table name: flow
Column name g, i, or o Null Datatype PK FK:Parent Table

sec_id g 0 Sec_Id:int(4) PK sec
flow_id g 0 Flow_Id:int(4) PK
exercise_code o 1 Exercise_Code:char(12)
put_call_code o 1 Put_Call_Code:char(4)
flow_amount g 1 Amount:float(8)
flow_date g 1 Date:datetime(8)
flow_term g 1 Term:int(4)
flow_type_code g 0 Flow_Type_Code:char(10)
flow_calc_code i 1 Flow_Calc_Code:char(12)
flow_calc_date i 1 Date:datetime(8)
flow_calc_rate i 1 Rate:float(8)
flow_discount_rate i 1 Rate:float(8)
flow_rate_calc_code i 1 Flow_Rate_Calc_Code:char(12)
manual_reset_b i 0 Bool:bit(1)
official_b i 0 Bool:bit(1)
maturity_term i 1 Term:int(4)
option_maturity_date o 1 Date:datetime(8)
option_maturity_term o 1 Term:int(4)
period_maturity_date i 1 Date:datetime(8)
period_start_date i 1 Date:datetime(8)
principal_amount i 1 Amount:float(8)
ref_index_term i 1 Term:int(4)
reset_group_id i 1 Reset_Group_Id:int(4)
ref_index_spread_rate i 1 Rate:float(8)
start_term i 1 Term:int(4)
underlying_flow_id i 1 Flow_Id:int(4)
strike_price o 1 Price:float(8)
ref_index_factor i 1 Amount:float(8)
payment_release_b g 0 Bool:bit(1)
sequence_number g 0 Sequence_Number:int(4)
binary_payoff_amount o 1 Amount:float(8)
Figure 9-1. The structure of the flow table. The “g, i, or o” column is not part of the database; it indicates whether a field is
designed for general identification, for index-related flows, or for option-related flows.
9-2 Flow Tables Infinity Data Model Developer’s Guide

General identification flow fields
sec_id
The sec_id identifies the security with which the flow is associated, using a value from
the sec table. Note that cashflows cannot exist independently of their security.
flow_id
The flow_id distinguishes individual cashflows. Along with the sec_id, this makes up
the primary key. For each new security, the initial flow_id will be one, and additional
cashflows will be numbered sequentially.
Note that when the Infinity applications are used to regenerate a security’s cashflows,
the old cashflows are deleted from the flow table, and the new cashflows are numbered
starting with an initial flow_id that would have been the next number in the security’s
old flow_id sequence.
For example, if one regenerates the cashflows for a security whose cashflows have the
flow_ids 1-8, the flow table will contain cashflows with flow_ids 9-16 after
regenerating. The entries in the flow table for the combination of the security’s sec_id
and flow_id numbers 1-8 will have been deleted.
flow_amount
This field stores the amount of money in the flow. If the amount of the flow is still
undetermined, this field is 0.
flow_date
The flow_date is the date on which the flow occurs.
flow_term
This field is not implemented in version 5.2.1.
flow_type_code
This code migrates from the flow_type_domain. Flows of notional principal, for
example, are indicated as NOTL_PRIN; actual principal is encoded ACT_PRIN;
INTEREST indicates interest flows. This field is not allowed to hold a NULL value;
for each flow, you must identify a type.
sequence_number
This code is used to ensure integrity between the database and back office
applications.
version 5.2 The flow Table 9-3

Interest rate and index-related flow fields
The following fields of the flow table are designed specifically to capture flows
originating from securities tied to interest rates or floating indexes. When modeling
flows unrelated to rates or indexes, these fields would remain NULL or zero (except
where noted otherwise in the Infinity Data Model Quick Reference).
flow_calc_code
The flow_calc_code indicates the method used to calculate an interest payment
amount.
flow_calc_date
The flow_calc_date is the date on which the flow is determined.
flow_calc_rate
The flow_calc_rate refers to the rate used to calculate the flow.
flow_discount_rate
If the flow is a present value of an interest flow, the discount rate is given here.
flow_rate_calc_code
The flow_rate_calc_code determines the way the rate is calculated (as an average, a
single set, etc.).
manual_reset_b
If this boolean value is true (1), the rate for this flow has been manually adjusted from
what might have been automatically generated by an application.
official_b
If this boolean value is true (1), the flow amount has been set based on an officially set
rate.
maturity_term
period_maturity_date
This field gives the maturity date for flows that are defined for an absolute time period.
period_start_date
This field gives the start date for flows that are defined for an absolute time period.
principal_amount
When a flow is an interest payment, the principal_amount field records the principal
amount from which the flow is calculated.
ref_index_term
This field represents the term of the reference index for the flow, i.e., 6-month LIBOR
would be represented with a value of 180.

reset_group_id
When a set of flows share reset dates, this field allows them to be grouped with a
common reset_group_id number. For example, if there were two simultaneous flows
related to a compounding instrument (one flow being interest and the other being the
compounding of previous interest), you could give these two flows a common
reset_group_id. This attribute is not a key of the flow table, so you do not need to
assign unique reset_group_id numbers to reset groups in different instruments.
ref_index_spread_rate
This field records any spread over the reference index for this flow.
start_term
underlying_flow_id
If a flow represents the compounding of a previously calculated interest payment, the
underlying_flow_id field contains the flow_id of that previously calculated interest
payment.
ref_index_factor
This is a multiplier for the reference index. A value of 1 indicates that the reference
index is used as is.
Option-related flow fields
The flow table is also used to store option-related flows, such as those generated by
caps and floors.
exercise_code
The exercise_code describes the convention for exercising an option. An
AMERICAN option is exercised at any time up to its expiration date. A BERMUDA
option can be exercised at select dates. A EUROPEAN option can only be exercised at
the expiration date. Since cap and floor flows have known dates, only EUROPEAN
type exercises are supported in the flow table.
put_call_code
The put_call_code is a string literal that identifies whether an option is a PUT option
or CALL option. For caps, this value is ‘CALL’ and for floors, it is ‘PUT.’
option_maturity_date
This field contains the date on which the option expires, for an option defined with
absolute dates.
option_maturity_term
version 5.2 The flow Table 9-5

strike_price
This field contains the strike interest rate for the option flow. Note that this will be
equal to the strike rate for the cap or floor when the flows are generated, but can be
manually edited later.
binary_payoff_amount
This field indicates the payout amount for this flow in a binary cap.
Using the flow_calc_reset table
When a floating rate flow is stored in the flow tables, the dates on which the rate is
sampled are stored in the flow_calc_reset table. This table has four columns.
Table name: flow_calc_reset

reset_group_id 0 Reset_Group_Id:int(4) PK
reset_date 0 Date:datetime(8) PK
calc_weight_rate 0 Rate:float(8)
Figure 9-2. The structure of the flow_calc_reset table.
The primary key of the flow_calc_reset table consists of three fields: reset_group_id,
reset_date and sec_id. If one set of reset dates applies to a set of flows, the flows
should be grouped as a reset group. The flow_calc_reset table stores the reset date
information for all calculations in a single reset group.
The last field in the flow_calc_reset table is the calc_weight_rate. In the case of
averaging transactions, this field records the relative weight which applies to each rate
sampling when you calculate an average.
Using Flow Tables

This section contains several examples concerning the specific usage of the flow
tables. The principal and interest flows below are taken from the 4% fixed leg of a
simple, semiannual, 2-year swap. The option flows, starting on page 9-12, are taken
from a simple, semiannual cap on 6-month LIBOR.

Simple Principal Flows
The following shows the initial and final principal for a notional 2-year swap on
$1,000,000. Notice that, aside from the flow and security ids (which make up the
combination primary key), the only fields which are not null or zero are the
flow_amount, flow_date, and flow_type_code. These are simple flows.
Table name: flow
sec_id 2329 2329
flow_id 9 10
exercise_code NULL NULL
put_call_code NULL NULL
flow_amount -1000000 1000000
flow_date Sep 20 1994 Sep 20 1996
flow_term 0 0
flow_type_code NOTL_PRIN NOTL_PRIN
flow_calc_code NULL NULL
flow_calc_date NULL NULL
flow_calc_rate 0 0
flow_discount_rate 0 0
flow_rate_calc_code NULL NULL
manual_reset_b 0 0
estimated_b 0 0
maturity_term 0 0
option_maturity_date NULL NULL
option_maturity_term 0 0
period_maturity_date NULL NULL
period_start_date NULL NULL
principal_amount 0 0
ref_index_term 0 0
reset_group_id NULL NULL
ref_index_spread_rate 0 0
start_term 0 0
underlying_flow_id NULL NULL
strike_price 0 0
version 5.2 Simple Principal Flows 9-7

Table name: flow
ref_index_factor 0 0
payment_release_b 0 0
Figure 9-3. Entries in the flow table for the initial and final principal flows of a swap.
Fixed Interest Flows

The following shows the interest payments for the fixed leg of a semiannual, 2-year
swap on $1,000,000 at 4%. In contrast to the simple principal flows, the fields
flow_calc_code, flow_calc_rate, period_start_date, period_maturity_date,
principal_amount, and reset_group_id are additionally filled in. The flow amount is
not zero because all the fixed interest flows are known at the beginning of the swap. It
is also important to note that these amounts were not automatically filled in by the
database itself; they were calculated externally by the Infinity Trader application.
These flows are the ones that were generated for the fixed swap leg in Chapter 9.
Table name: flow
sec_id 2329 2329 2329 2329
flow_id 13 14 15 16
exercise_code NULL NULL NULL NULL
put_call_code NULL NULL NULL NULL
flow_amount 20111.11 20444.44 20222.22 20444.44
flow_date Mar 20 1995 Sep 20 1995 Mar 20 1996 Sep 20 1996
flow_term 0 0 0 0
flow_type_code INTEREST INTEREST INTEREST INTEREST
flow_calc_code SIMPLEINT SIMPLEINT SIMPLEINT SIMPLEINT
flow_calc_date NULL NULL NULL NULL
flow_calc_rate 0.04 0.04 0.04 0.04
flow_discount_rate 0 0 0 0
flow_rate_calc_code NULL NULL NULL NULL
manual_reset_b 0 0 0 0
estimated_b 0 0 0 0
maturity_term 0 0 0 0
option_maturity_date NULL NULL NULL NULL
option_maturity_term 0 0 0 0
period_maturity_date Mar 20 1995 Sep 20 1995 Mar 20 1996 Sep 20 1996

Table name: flow
period_start_date Sep 20 1994 Mar 20 1995 Sep 20 1995 Mar 20 1996
principal_amount 1000000 1000000 1000000 1000000
ref_index_term 0 0 0 0
reset_group_id 2 2 2 2
ref_index_spread_rate 0 0 0 0
start_term 0 0 0 0
underlying_flow_id NULL NULL NULL NULL
strike_price 0 0 0 0
ref_index_factor 0 0 0 0
payment_release_b 0 0 0 0
Figure 9-4. Entries in the flow table for semiannual interest payments from the fixed leg of a 2-year swap.
Exchange Flows
For swaps, we also show exchange flows, which contain the actual amount of
principal exchanged. Exchange flows are primarily used in FX swaps. For a notional
interest rate swap, exchange flows are zero.
Table name: flow
sec_id 2329 2329
flow_id 11 12
exercise_code NULL NULL
put_call_code NULL NULL
flow_amount 0 0
flow_date Sep 20 1994 Sep 20 1996
flow_term 0 0
flow_type_code INITIAL_EX FINAL_EX
flow_calc_code NULL NULL
flow_calc_date NULL NULL
flow_calc_rate 0 0
flow_discount_rate 0 0
flow_rate_calc_code NULL NULL
manual_reset_b 0 0
version 5.2 Exchange Flows 9-9

Table name: flow
estimated_b 0 0
maturity_term 0 0
option_maturity_date NULL NULL
option_maturity_term 0 0
period_maturity_date NULL NULL
period_start_date NULL NULL
principal_amount 0 0
ref_index_term 0 0
reset_group_id NULL NULL
ref_index_spread_rate 0 0
start_term 0 0
underlying_flow_id NULL NULL
strike_price 0 0
ref_index_factor 0 0
payment_release_b 0 0
Figure 9-5. Entries in the flow table for the initial and final exchange flows of a swap.
Floating Interest Flows

The following example shows the interest payments for the floating leg of a
semiannual, 2-year swap on $1,000,000. Interest flows for this floating leg are based
on the following formula: (six month LIBOR × 1.2) + 50 basis points. This floating
leg would be paired with the fixed leg from the previous example to form a swap (the
swap shown in Chapter 9). Note the matching period_start_date,
period_maturity_date, and principal_amount values for the fixed and floating legs.
At the time the floating leg is saved, the flow_amounts are zero because the floating
interest flows are not yet known. Each flow amount will be calculated by the Infinity
Trader application when the floating rate for that flow is reset. Likewise, the
flow_calc_rate field contains a zero value until the rate is reset from the index.
The flow_calc_date field, which was NULL for the fixed leg, contains the date on
which the floating rate flows will be calculated. In the flow_rate_calc_code field, the
value of INDEX specifies that the flow amount will be calculated based on the index
rate posted on the calculation date.
The ref_index_term field specifies the term of the reference index in days. In the
example, the value of 180 indicates a six-month index. To find out that the index is
six-month LIBOR, we must query the ref_index_quote table.

The value in the reset_group_id field points to an entry in the flow_calc_reset table.
The calc_weight_rate field in the flow_calc_reset table lists the weighting value for
the index rate, which will be 1 in this case, since the leg is not an averaging rate leg.
The ref_index_spread_rate field contains the spread which is added to the index rate.
This value is stored as a decimal, so the 50 basis point spread in this example is
entered here as 0.005. The ref_index_factor field stores the factor by which the Infinity
Trader application will multiply the index rate before adding the spread and
calculating the flow.
Table name: flow
sec_id 2330 2330 2330 2330
flow_id 5 6 7 8
exercise_code NULL NULL NULL NULL
put_call_code NULL NULL NULL NULL
flow_amount 0 0 0 0
flow_date Mar 20 1995 Sep 20 1995 Mar 20 1996 Sep 20 1996
flow_term 0 0 0 0
flow_type_code INTEREST INTEREST INTEREST INTEREST
flow_calc_date Sep 16 1994 Mar 16 1995 Sep 18 1995 Mar 18 1996
flow_calc_rate 0 0 0 0
flow_discount_rate 0 0 0 0
flow_rate_calc_code INDEX INDEX INDEX INDEX
estimated_b 0 0 0 0
option_maturity_date NULL NULL NULL NULL
period_maturity_date Mar 20 1995 Sep 20 1995 Mar 20 1996 Sep 20 1996
period_start_date Sep 20 1994 Mar 20 1995 Sep 20 1995 Mar 20 1996
principal_amount 1000000 1000000 1000000 1000000
ref_index_spread_rate 0.005 0.005 0.005 0.005
start_term 0 0 0 0
version 5.2 Floating Interest Flows 9-11

Table name: flow
sec_id 2330 2330 2330 2330
flow_id 5 6 7 8
strike_price 0 0 0 0
ref_index_factor 1.2 1.2 1.2 1.2
Figure 9-6. Entries in the flow table for semiannual interest payments from the floating leg of a 2-year
swap.
Option-related Flows
The following example shows the four option flows for a 2-year, semiannual, 6% cap
on 3-month LIBOR on a principal of $100 million. Notice that now the reference
index and option-related fields have been filled in. A value of zero is stored in the
flow_amount column for flow values that are not yet known. Currently these flows are
only used for option flows in caps.
Table name: flow
sec_id 1533 1533 1533 1533
flow_id 12 13 14 15
exercise_code EUROPEAN EUROPEAN EUROPEAN EUROPEAN
put_call_code CALL CALL CALL CALL
flow_amount 0.00 0.00 0.00 0.00
flow_date Jan 8 1996 Jul 8 1996 Jan 7 1997 Jul 7 1997
flow_term 0 0 0 0
flow_type_code OPTION OPTION OPTION OPTION
flow_calc_date Jul 7 1995 Jan 8 1996 Jul 8 1996 Jan 7 1997
flow_calc_rate 0.00 0.00 0.00 0.00
flow_discount_rate 0.00 0.00 0.00 0.00
flow_rate_calc_code INDEX INDEX INDEX INDEX
estimated_b 0 0 0 0

Table name: flow
option_maturity_date Jul 7 1995 Jan 8 1996 Jul 8 1996 Jan 7 1997
period_maturity_date Jan 8 1996 Jul 8 1996 Jan 7 1997 Jul 7 1997
period_start_date Jul 7 1995 Jan 8 1996 Jul 8 1996 Jan 7 1997
principal_amount 100000000.00 100000000.00 100000000.00 100000000.00
ref_index_spread_rate 0.00 0.00 0.00 0.00
start_term 0 0 0 0
strike_price 0.06 0.06 0.06 0.06
ref_index_factor 1.00 1.00 1.00 1.00
Figure 9-7. Entries in the flow table for semiannual option flows from a 2-year cap on 3-month LIBOR.
version 5.2 Option-related Flows 9-13

Chapter 10
Reference Index Tables
The reference index tables store information about the interest rate reference indexes
used to determine cashflows in floating rate securities. Common examples of these
indexes include the US-dollar LIBOR, the US commercial paper rate (CP), and
Japan’s TIBOR.
Ten tables model reference indexes, their sources, and their values:
• The infsys_montage_lists table with list_name = ref_index_list establishes
the range of valid names for the reference indexes used in security
transactions.
• The infsys_montage_lists table with list_name = ref_index_source_list
establishes the range of valid sources which provide reference index
quotes.
• The ref_index_attribute table contains information about the date roll, day
count, rounding and other conventions related to a reference index.
• The ref_index_hol_city table stores a city code which designates the
holiday calendar used for a given reference index.
• The ref_index_term_source table holds the valid source or sources for
each defined combination of currency, reference index and index term.
• The ref_index_quote table stores all reference index quotes. Since the
date and time of the quote are part of the table’s primary key, the
ref_index_quote table provides a history of quoted interest rates for each
reference index. If a real time feed has been set up, the ref_index_address
table stores the real time address for quotes. In an environment without a
real time feed, the ref_index_address table would be empty.
• The infsys_montage_domains table with domain_name =
ref_index_relation_domain stores the range of codes that describe the
ways reference indexes can relate to one another.
• The ref_index_index_relation table stores records for reference indexes
(defined by a unique combination of currency, index, source, and term)
that are related to each other.
• The ref_index_relation_def table uses a ref_index_relation_code to define
each reference index relationship.
The following example demonstrates the procedure of adding USD LIBOR to the
Infinity Data Model as a new reference index. For the purposes of this example,
suppose that USD LIBOR has not been established in the database as a reference
version 5.2 10-1

index, and no real time feed is needed. In reality, Infinity ships the Data Model with
USD LIBOR pre-loaded as a valid reference index, although it does not ship any real
time addresses pre-loaded.
The infsys_montage_lists Table

There are two additions to infsys_montage_lists, one for list_name = ref_index_list,
the other for list_name = ref_index_source_list.
ref_index_list
To add USD LIBOR to your database, you would first need to add the name LIBOR as
a value within the ref_index_list, which lists abbreviations for all the reference
indexes.
Table name: infsys_montage_lists
list_name ref_index_list
list_code LIBOR
montage_group_code INFINITY
description London interbank offered rate
Figure 10-1. The record in the infsys_montage_lists table establishing LIBOR as a ref_index_code.
Selecting other values stored in the infsys_montage_lists table with list_name =

ref_index_list reveals the pre-loaded reference indexes in the database such as CP,
PRIME, BA, etc.
ref_index_source_list
The infsy_montage_lists table with list_name = ref_index_source_list establishes the
range of valid sources (e.g., ISDA, BBA) which provide reference index quotes.
If more than one source will provide LIBOR quotes, adding LIBOR as a reference
index will require making several entries in this table, one for each source of USD
10-2 Reference Index Tables Infinity Data Model Developer’s Guide

LIBOR rate quotes. The montage_group_code value of INFINITY indicates codes
which were entered by Infinity.
Table name: infsys_montage_lists

ref_index_ ref_index_ ref_index_
list_name
source_list source_list source_list
list_code ISDA BBA LIBO
montage_group_code INFINITY INFINITY INFINITY
Reuters Screen Telerate Page Reuters Screen

description
ISDA 3750 LIBO
Figure 10-2. Three records in the infsys_montage_lists table, establishing ISDA, BBA, and LIBO as
valid sources for reference index quotes.
As with the previous values, a number of reference index sources are pre-packaged
data, shipped with the Data Model.
The ref_index_attribute Table

The ref_index_attribute table contains information about the date roll, day count,
rounding and other conventions related to a reference index.
To define the conventions for USD LIBOR reference index quotes, the
ref_index_attribute table would be populated as illustrated below. Note that these
specifications are being assigned only to LIBOR rates for US dollars, since the
ref_index_currency_code column, part of the primary key, contains the value USD.
Table name: ref_index_attribute
quote_method_code SIMPL_INT
payment_date_roll_ code MOD_FOLLOW
settlement_term 2
rounding_convention_code ISDA_RATE
settlement_date_roll_code FOLLOWING
Figure 10-3. Adding USD LIBOR to the ref_index_attribute table.
version 5.2 The ref_index_attribute Table 10-3

Most of the columns in the ref_index_attribute table are code values taken from
infsys_montage_lists and infsys_montage_domains. For further information on the
range of possible code values for a given column, look up the corresponding list or
domain in the Infinity Data Model Reference Guide.
The ref_index_hol_city Table

The ref_index_hol_city table stores a city code which designates the holiday calendar
used for a given reference index. To specify that the USD LIBOR reference index will
observe London holidays, assign the ‘LON’ holiday calendar to the index using the
ref_index_hol_city table.
Table name: ref_index_hol_city
city_code LON
hol_type_code PAYMENT
Figure 10-4. The entry in the ref_index_hol_city table specifying London PAYMENT holidays for the
USD LIBOR reference index. All four columns contribute to the primary key.
The ref_index_term_source Table

The ref_index_term_source table holds the valid source or sources for each defined
combination of currency, reference index, and index term. The quote_history_code
value will be either “DAILY” or “NULL”. A value of “DAILY” means that the Infinity
Rate Calc Manager application will query for a reference index quote every day, and a
value of “NULL” means that the application will issue a query only when a quote is
needed.
The USD LIBOR reference index will have an entry in this table for each combination
of term and source. The following two entries are included as examples.
Table name: ref_index_term_source
ref_index_currency_code USD USD
ref_index_code LIBOR LIBOR
ref_index_source_code ISDA ISDA

Table name: ref_index_term_source
ref_index_term 30 90
quote_history_code DAILY DAILY
Figure 10-5. Two entries in the ref_index_term_source table, specifying that ISDA will be a source for
1-month and 3-month USD LIBOR quotes.
The ref_index_quote Table

The ref_index_quote table stores all reference index quotes. Since the date and time of
the quote are part of the table’s primary key, the ref_index_quote table provides a
history of all quoted interest rates for each reference index.
A USD 3-month LIBOR quote for June 12, 1995, would be recorded:
Table name: ref_index_quote
ref_index_term 90
ref_index_source_code T3750
quote_datetime Jun 12 1995 12:00AM
quote_value 0.055
estimated_b 0
auth_b 1
auth_id 803
Figure 10-6. A USD 3-month LIBOR quote in the ref_index_quote table.
Note the two fields: auth_b and auth_id. These fields allow back office applications to
ensure that quotes are official and authorized. See chapter 4 on organization
information for more information about these two fields.
If a real time feed has been set up, the real time address for each quote is stored in
ref_index_address.
version 5.2 The ref_index_quote Table 10-5

Reference Index Relationships
In cases where an index is an average of or an interpolation from other indexes, the
ref_index_index_relation table establishes a relationship between two indexes, and the
ref_index_relation_def table uses a ref_index_relation_code to define the method used
to average or interpolate an index quote from other quotes.
The infsys_montage_domains with domain_name = ref_index_relation_domain

provides the range of ref_index_relation_code values that may be entered in the
ref_index_relation_def table. The Data Model is shipped with three
ref_index_relation_code values: AVERAGE, EX_HI_LO_AVG, and INTERP. An
AVERAGE index quote is the average of a set of index quotes; an EX_HI_LO_AVG
quote is the average of a set of index quotes, excluding the highest and lowest quotes
in that set; and an INTERP quote is a value interpolated from a set of index quotes.
The methods used to generate averaged and interpolated quotes are part of the Infinity
applications and are not resident in the Data Model.

Chapter 11
Curve Tables
The pricing of securities requires calculations based on interest curves, including

discount factor, yield, forward, zero, volatility, and basis curves. This chapter
discusses the set of tables in the Infinity Data Model which are used to store and
organize curve data.
Curve Definitions and Representations

The general representation of each interest curve is stored in the curve table. For each
interest curve there is a single record in the curve table. This table contains
information common to all types of curves, including curve_id number, name and
currency, type of curve, data interpretation rules, and so on.
Each date and time for which a curve is defined represents an instance of a curve.
Each such instance is identified in the curve_datetime table by a combination of its
curve_id and the date and time for which the curve is valid. This table also uses a
curve_instance_code to specify the time of day which the curve’s data represent
relative to the market’s opening and closing. The rates which make up a specific curve
are stored in the table curve_data. This table holds both bid and offer rate values, as
well as the offset, in days, for the observation date.
The curve header tables store parameter values for the four different types of curves.
The curve_interest_header, curve_volatility_header, curve_basis_header, and
curve_repo_header tables contain information more specific to interest, volatility,
basis, and repo curves, respectively. For a given curve, only one of these tables will
contain a record, since the curve types are mutually exclusive. Additional data about
repo curve groups is contained in the curve_repo_group and
curve_repo_group_special tables.
Curves can be defined in three ways: simple curves are defined as a set of data points
and offset terms; derived curves are defined based on a set of underlying securities and
curves; and dependent curves are defined as a function of other curves. These
definitions are stored in the curve_def_simple, curve_def_derived_sec,
curve_def_derived_curve, and curve_def_dependent tables.
The curve_hol_city table designates the different holiday calendars associated with a
curve.
version 5.2 Curve Definitions and Representations 11-1

For every curve, the following tables would normally be populated:
• one record in the curve table
• one curve_[type]_header record (where “type” is interest, volatility, or
basis)
• if the curve is defined merely as a set of points, one curve_def_simple
table entry; otherwise, there may be multiple records in another kind
of curve_def_ table (_derived_curve, _derived_sec, or _dependent)
• many rows in the curve_datetime and curve_data tables
• curve_hol_city rows, if holidays apply to payment or reset schedules
Each of these tables uses many curve-related codes found in either

infsys_montage_lists or infsys_montage_domains. There are several entries in each of
these tables that store codes specifically relating to curves; you may wish to refer to
the Domain and List Tables sections of this manual and the Infinity Data Model
Reference Guide for more information about a given code.
Separating Data From Definitions

In the database, a curve is treated as a relationship between time and two variables
(typically a bid and an offer). It is measured in days going forward from the date the
curve is constructed. The following data would describe a discount factor curve for
dollars:
Days offset Bid Offer

0 1 1
1 .9990 .9992
9 .9982 .9984
31 .9821 .9819
90 .9805 .9807
Figure 11-1. A 5-point discount factor curve, plotting 90 days into the future.
This discount factor curve says that a dollar today (day count 0) is worth $1. For a
dollar in nine days, the owner of the curve is willing to buy it (bid) for $0.9982 today
or sell it (offer) for $0.9984. Most curves (yield curves, discount factor curves,
forward curves, and volatility curves) used in derivative products trading can be
expressed in this way: days offset from the current date, with bid and offer values. The
numbers in the table above would be stored in the curve_data table; the fact that it is a
discount factor curve would be stored in the curve table itself. The table curve_data
11-2 Curve Tables Infinity Data Model Developer’s Guide

does not have the information that specifies what the datapoints represent (discount
factors, yields, zero rates, etc.).
The curve Table

The curve table holds general definitions, such as “US dollar volatility curve” or
“Japanese yen LIBOR discount factor curve.”
Table name: curve

curve_id 0 Curve_Id:int(4) PK
curve_level_type_code 1 Curve_Level_Type_Code:varchar(10)
curve_interpretation_code 1 Curve_Interpretation_Code:char(6)
curve_status_code 1 Curve_Status_Code:char(12)
curve_def_code 0 Curve_Def_Code:char(12)
curve_data_code 0 Curve_Data_Code:char(12)
curve_name 0 Curve_Name:char(12)
curve_type_code 0 Curve_Type_Code:char(12)
interp_code 1 Interp_Code:char(12)
description 1 Description:varchar(50)
user_code 0 User_Code:varchar(30)
class_name 0 Class_Name:varchar(80)
Figure 11-2. Table structure for the curve entity.
Attributes of the curve table
curve_id
This field contains a seed number taken from curve_seed. The rest of the values in
curve, other than curve_name and description, are codes taken from domain and list
tables used to describe the curve.
curve_level_type_code
curve_interpretation_code
curve_status_code
This field tells whether a curve is open or locked. You might want to lock a curve to
prevent the list of underlying securities from being accidentally changed. This is used
in conjunction with the Infinity applications to restrict access to certain curves.
version 5.2 The curve Table 11-3

curve_def_code
This field describes whether a curve is defined as a simple curve, a dependent curve, or
a derived curve. These are the three different methods of curve definition used in
Infinity’s Market Environment Manager application. For more on these methods, see
the section below on curve definitions.
curve_data_code
This field describes what kind of curve data are being described: zero rate data,
forward rate data, discount factor data, or yield data.
curve_type_code
This field describes whether a curve is an interest rate curve, a repo curve, a volatility
curve, a foreign exchange curve, or a basis curve.
currency_code
This field states the currency for which the data are meaningful.
interp_code
This filed describes the interpolation type: Linear, Spline, Log-linear, or Time-
weighted-linear.
description
This field contains additional descriptive information which is not directly available
through Infinity applications.
user_code
This field names the user who entered the curve.
class_name
This field lists the Fin++ class that was used to save this curve.
As an example entry in the curve table, consider a locked zero rate pricing curve for
swaps, based on LIBOR instruments, named LIBORTEST.
Table name: curve
curve_id 6
curve_level_type_code NULL
curve_interpretation_code NULL
curve_status_code LOCKED
curve_def_code DERIVED
curve_data_code RATE
curve_name LIBORTEST
curve_type_code INTEREST

Table name: curve
currency_code USD
interp_code LINEAR
description NULL
user_code login_1
class_name InfCurveZeroSql
Figure 11-3. Table values for a sample curve table.
Curve Header Tables

While a curve table models the more fundamental attributes of a curve, more specific
data is stored in _header tables. There are four curve _header tables, one for each
curve_type_code. These tables are: curve_interest_header (for interest curves),
curve_basis_header (for basis curves), curve_fx_header (not currently supported),
curve_volatility_header (for volatility curves), and curve_repo_header (for repo
curves). Every curve should have an entry in only one of these header tables.
Interest curves and the curve_interest_header table
Table name: curve_interest_header

curve_id 0 Curve_Id:int(4) PK curve
compound_frq_code 0 Frq_Code:char(3)
sec_term 1 Term:int(4)
bond_relative_b 0 Bool:bit(1)
Figure 11-4. Structure of the curve_interest_header table.
All interest curves represent the time value of money by plotting interest rates against
time, but the type of interest rates being used must be noted so that the resulting curve
can be applied appropriately.
The curve table uses a curve_data_code value to specify the type of the datapoints
used to plot the curve : discount factors, zero rates, yields, or forwards. For all interest
curves, the curve_interest_header table contains more detailed information on the
version 5.2 Curve Header Tables 11-5

interest rates that the curve represents, as well as the method used to generate the
curve.
In the curve_interest_header table, the day_count_code and compound_frq_code

help to further specify how to interpret the datapoints. If the curve_data_code is DF,
then no other information is necessary since discount factors are dimensionless values.
In the case of zero rates and yields (RATE and YIELD), it is necessary to specify both
the compounding frequency and the day count. In the case of forwards, it is necessary
to specify the day count as well as the term of the forwards (sec_term).
The values of ref_index_code and ref_index_term provide further textual description

as to the interest rate index that the curve represents. This is used by the Infinity
Market Environment Manager application to group curves, such as 6-month LIBOR,
3-month BA, etc.
The values of bond_relative_b and interp_code are used in the process of generating
the interest curve. The bond_relative_b is used to determine if the bonds used to build
the curve are to be treated as if they were to mature on their actual or relative maturity
dates.
The following example shows the curve_interest_header entry for a 6-month LIBOR
curve, with linear interpolation, actual/360 daycount and semiannual compounding.
Table: curve_interest_header
curve_id 6
bond_type_code UST
compound_frequency_code SA
sec_term 0
bond_relative_b 1
ref_index_term 180
Figure 11-5. A sample instance of the curve_interest_header table.

Basis curves and the curve_basis_header table
Table name: curve_basis_header

underlying_curve_side_code 1 Curve_Side_Code:char(4)
result_curve_id 0 Curve_Id:int(4)
underlying_curve_id 0 Curve_Id:int(4)
curve_curve_operator_code 0 Curve_Curve_Operator_Code:char(4)
underlying_curve2_side_code 1 Curve_Side_Code:char(4)
underlying_curve2_id 1 Curve_Id:int(4)
fx_rate 1 Rate:float(8)
Figure 11-6. Structure of the curve_basis_header table.
Basis curves also plot rates against time. A basis curve might be calculated from
spread rates and then subtracted from an index rate curve, such as LIBOR, to calculate
another curve, such as the commercial paper (CP) rate curve.
Basis curves are modeled in the curve_basis_header table as dependent curves which,
when subtracted from a standard index curve such as LIBOR, produce a resulting
index curve such as the CP curve. In the curve_basis_header table, the curve_id is the
identification number of the basis curve, the underlying_curve_id is the identification
number of the standard index curve (e.g., LIBOR), and the result_curve_id is the
identification number of the resulting index curve (e.g., CP). The
curve_curve_operator_code identifies the mathematical operation which is used to
apply the basis curve to the underlying curve in order to arrive at the result curve.
The basis curve could be single currency or cross currency. In the cross currency
scenario, there would be two underlying curves, one for each currency. The fields
underlying_curve2_id and underlying_curve_side_code store information about the
cross currency curve. The field fx_rate stores the rate of exchange between the two
currencies.
In the following example, curve 77 is a basis curve which is subtracted from

underlying curve 29 (a LIBOR curve) to produce resulting curve 32 (a CP curve). The
operation can be written as CP = LIBOR - BASIS.
Table: curve_basis_header
curve_id 77
underlying_curve_side_code NULL
result_curve_id 32

Table: curve_basis_header
underlying_curve_id 29
curve_curve_operator_code SUB
underlying_curve2_side_code NULL
underlying_curve2_id NULL
fx_rate 1.000000
Figure 11-7. Modeling a basis curve (77) which is subtracted from a LIBOR curve (29) to produce the CP
rate curve (32).
The underlying, basis, and result curves would appear in the curve table as follows.
Table: curve
curve_id 29 32 77
curve_level_type_code NULL NULL NULL
curve_interpretation_code NULL NULL NULL
curve_status_code OPEN OPEN OPEN
curve_def_code DERIVED DEPENDENT DERIVED
curve_data_code RATE RATE RATE
curve_name CHM_LIBOR CHM_CP CHM_CP_BS2
curve_type_code INTEREST INTEREST BASIS
currency_code USD USD USD
description NULL NULL NULL
user_code login_1 login_1 login_1
class_name InfCurveZeroSql InfCurveBasisSql InfCurveZeroSql
Figure 11-8. Instances of the curve table for a LIBOR curve (29), a CP curve (32), and the basis curve
(77) used to arrive at the CP curve.
Since the underlying, basis, and result curves are related by a mathematical operator,
they will also have an entry in the curve_def_dependent table.

Volatility curves and the curve_volatility_header table
A volatility curve matches standard deviations against daycounts. The structure of

curve_volatility_header is depicted below.
Table name: curve_volatility_header

sec_id 1 Sec_Id:int(4)
sec_maturity_term 1 Term:int(4)
settlement_sec_id 1 Sec_Id:int(4)
unit_time_code 0 Unit_Time_Code:char(12)
Figure 11-9. Structure for the curve_volatility_header table.
Volatility curves normally track standard deviations in the price of a specific

instrument, identified by the sec_id attribute. The term of this security is identified in
the sec_maturity_term attribute. A volatility curve may also be defined to track
standard deviations in specific indexes, identified with a ref_index_code (LIBOR, etc.)
and a ref_index_term in days (e.g. 90 for 3-month LIBOR).
You can assign a strike price for each volatility curve with the strike_price attribute.
The settlement_sec_id identifies the security you would be trading for the underlying
instrument. In the Infinity Market Environment Manager application, the strike price
and security id’s do not affect the curve generation algorithm and are for tracking
purposes only.
Valid values for unit_time_code are 360_DAY_YEAR or 365_DAY_YEAR. The

value of the unit_time_code determines whether a actual or 360 day count will be used
in the generation algorithm. Valid values for the unit_time_code are specified in
infsys_montage_domains, with domain_name = unit_time_domain.
As another example, imagine a curve tracking volatilities for 1-year options on a 3-

month LIBOR index with a 10% strike price. This curve would have the following
curve_volatility_header entry.
curve_id 20
sec_id NULL

ref_index_term 90
sec_maturity_term 360
strike_price .10
settlement_sec_id NULL
unit_time_code 360_DAY_YEAR
Figure 11-10. Sample table values for curve_volatility_header to model a volatility curve for an option
on 3-month LIBOR.
Repo curves and the curve_repo_header table
A repo curve is a simple curve charting rates for bond repurchase agreements. The
structure of curve_repo_header is depicted below.
Table name: curve_repo_header

issuer_inst_code 0 Issuer_Inst_Code:char(12)
sec_id 1 Sec_Id:int(4)
Figure 11-11. The table structure of curve_repo_header.
Each curve is associated with a particular bond on special, which is identified by its
sec_id in the curve_repo_header table. The bond_type_code characterizes the bond
for which the repurchase agreement has been made. The issuer_inst_code specifies
the issuer of the bond. The sec_id also refers to the bond.
The following example shows the curve_repo_header table for a UST repo curve.
curve_id 130
bond_type_code UST
issuer_inst_code USGVT

curve_id 130
sec_id 1983
Figure 11-12. Sample table values for curve_repo_header.
Groups of repo curves are used to obtain repo rates for the Infinity Repo Manager and
Bond Options Trader applications. Information about repo curve groups is contained
in two additional tables. A repo curve group consists of a General Collateral Curve (a
repo curve saved as General Collateral) and, typically, a group of other repo curves,
each associated with a particular bond on special. The curve_repo_group_special
table identifies the repo curves that make up an instance of a repo curve group. The
group is identified by its repo_group_id and by the date and time it was last saved. The
curve is identified by its curve_id.

Table name: curve_repo_group_special

repo_group_id 0 Repo_Group_Id:int(4) PK curve_repo_group
instance_date 0 Date:datetime(8) PK
Figure 11-13. The table structure of curve_repo_group_special.
The following example illustrates the curve_repo_group_special table for the curve
data in the previous table. Note that all three attributes contribute to this table’s
primary key.
Table name: curve_repo_group_special
curve_id repo_group_id instance_date
130 2 Jun 26 1995 12:00AM

130 11 Jun 22 1995 12:00AM
130 11 Jun 29 1995 12:00AM
130 13 Jul 13 1995 12:00AM
130 16 Jul 28 1995 12:00AM
Figure 11-14. The curve_repo_group_special table.
The curve_repo_group table establishes a repo curve group in the database by giving
it a name (repo_group_name) and id number (repo_group_id). The login name of the
user who created the curve group is stored in the user_code column.
Table name: curve_repo_group

repo_group_id 0 Repo_Group_Id:int(4) PK
repo_group_name 0 Repo_Group_Name:char(12)
Figure 11-15. The table structure of curve_repo_group.

Selecting the instance for the curve in Figure 11-12 provides the following example:
Table title: curve_repo_group
repo_group_id 11
user_code fodev_user_1
repo_group_name REPO-KE
Figure 11-16. The curve_repo_group table.
Curve Data
Once a curve has been defined in the curve header tables and a specific instance of the
curve has been specified in the curve_datetime table, the rate data used to plot the
curve can be entered in the curve_data table.
The curve_datetime table contains the dates for which data exist in the curve_data
table. The intermediary step of the curve_datetime table is designed to improve the
performance of very large historical curve databases.
Table name: curve_datetime

curve_datetime 0 Datetime:datetime(8) PK
datetime_curve_status_code 1 Curve_Status_Code:char(12)
curve_instance_code 1 Curve_Instance_Code:char(12)
Figure 11-17. The table structure of curve_datetime.
The datetime_curve_status_code indicates whether this particular datetime instance

is locked or unlocked. The curve_instance_code indicates the time of day (with
respect to markets) which the curve’s data represent: closing, opening, or intraday.
The table curve_data contains the same curve_id and curve_datetime primary keys as
curve_datetime, plus attributes for the daycount, the numerical bid and offer rate
values, and the time that the data point was updated. While curve_datetime contains
exactly one record for each saved instance of a curve, curve_data contains as many
records as there are data points for an instance of a curve.
version 5.2 Curve Data 11-13

Table name: curve_data

curve_id 0 Curve_Id:int(4) PK curve_datetime
curve_datetime 0 Datetime:datetime(8) PK curve_datetime
curve_offset_day 0 Offset_Day:int(4) PK
Figure 11-18. The table structure of the curve_data table.
A curve defined once in the curve header table can foster many instances in
curve_datetime — one for each time the curve was generated and saved to the
database. To select a particular instance of a curve, you must query both
curve_datetime and curve_data.
The following example entries in the curve_data table show the data points generated
for a zero rate curve covering about 10 years (note: for convenience of display, the
update_datetime field is not shown, as it is always the same as the curve_datetime for
curves generated by the Infinity Market Environment Manager application).
Table: curve_data
curve_id curve_datetime curve_offset_day bid_value offer_value
6 Mar 21 1995 1:25PM 1 0.060904 0.060904
6 Mar 21 1995 1:25PM 2 0.060904 0.060904
6 Mar 21 1995 1:25PM 9 0.061681 0.061681
6 Mar 21 1995 1:25PM 31 0.062801 0.062801
6 Mar 21 1995 1:25PM 90 0.063470 0.063470
6 Mar 21 1995 1:25PM 92 0.063485 0.063485
6 Mar 21 1995 1:25PM 181 0.063985 0.063985
6 Mar 21 1995 1:25PM 182 0.063991 0.063991
6 Mar 21 1995 1:25PM 272 0.064499 0.064499
6 Mar 21 1995 1:25PM 363 0.065265 0.065265
6 Mar 21 1995 1:25PM 454 0.066025 0.066025
6 Mar 21 1995 1:25PM 455 0.066034 0.066034
6 Mar 21 1995 1:25PM 545 0.066872 0.066872
6 Mar 21 1995 1:25PM 546 0.066881 0.066881
6 Mar 21 1995 1:25PM 636 0.067588 0.067588

Table: curve_data
6 Mar 21 1995 1:25PM 727 0.068283 0.068283
6 Mar 21 1995 1:25PM 1098 0.073622 0.073622
6 Mar 21 1995 1:25PM 1829 0.079862 0.079862
6 Mar 21 1995 1:25PM 2561 0.082119 0.082119
6 Mar 21 1995 1:25PM 3655 0.085328 0.085328
Figure 11-19. The curve_data table, containing zero rates extending 10 years into the future.
Curve Definitions: Simple, Derived, and Dependent

The simplest curves are those for which data points are immediately available and can
be directly entered into curve_data. These points would not need to be derived from
underlying securities or curves. They might be data points from a curve generation
application different from Infinity’s Market Environment Manager. Information about
these simple curves is stored in the curve_def_simple table.
Other curves are not directly known; they must be constructed from market data. For
example, an interest curve could be pieced together using prices of short-term
currency instruments, medium-term futures instruments, and long-term spreads or
bond instruments. Curves constructed in this manner are known as derived interest
rate curves. The curve_def_derived_sec table uses sec_id numbers to point to the
securities which underlie a derived curve.
The curve_def_derived_curve table is like the curve_def_derived_sec table, except

that it uses curve_id numbers to point to specific underlying curves. It is used for
derived volatility curves. For example, you might be using a USD/LIBOR curve to
generate a USD/LIBOR volatility curve. The curve_def_derived_curve would store
the curve_id number of that original USD/LIBOR curve.
Lastly, some curves are functions of other curves. Such a curve might be built as the
sum of a LIBOR interest curve and a basis curve. In the database, these are known as
dependent curves, and they are stored in curve_def_dependent tables. These curve
dependencies are expressed as a curve_curve_operator_code for addition (ADD),
subtraction (SUB), multiplication (MUL), or division (DIV).
The curve_def_simple table
The curve_def_simple table gives only a curve_offset_term, in days, for a given

curve_id. The offset term is a key to store the term periods on which this curve will
have data.
version 5.2 Curve Definitions: Simple, Derived, and Dependent 11-15

Note: curves use both terms (a domain) and actual days (integers). For a curve
definition, the curve_offset_term is used, and must be interpreted in light of the day
count convention of the curve and the curve’s starting date. For example, a
curve_offset_term of 180, which means 6 months, must be calculated to be 6 months
from the start date of the curve, and could, in fact, lead to a curve_offset_day in the
curve_data table of 181 or 182.
The following example entries in the curve_def_simple table show a simple LIBOR
curve made up of terms though 10 years. The corresponding curve_data table records
are shown as well. Note that the database does not perform the conversion from terms
to dates; this must be done by the corresponding application.
Table: curve_def_simple
curve_id curve_offset_term
2 1
2 7
2 14
2 21
2 30
2 90
2 180
2 360
2 720
2 1080
2 1800
2 3600
Figure 11-20. The curve_def_simple table, defining offset

terms extending 10 years into the future.
The associated entries in the curve_data table:
Table: curve_data
2 Nov 8 1994 2:31PM 1 0.050 0.050
2 Nov 8 1994 2:31PM 7 0.051 0.051
2 Nov 8 1994 2:31PM 14 0.052 0.052

Table: curve_data
2 Nov 8 1994 2:31PM 21 0.053 0.053
2 Nov 8 1994 2:31PM 30 0.053 0.053
2 Nov 8 1994 2:31PM 92 0.054 0.054
2 Nov 8 1994 2:31PM 181 0.055 0.055
2 Nov 8 1994 2:31PM 365 0.056 0.056
2 Nov 8 1994 2:31PM 731 0.057 0.057
2 Nov 8 1994 2:31PM 1098 0.058000 0.058000
2 Nov 8 1994 2:31PM 1826 0.059000 0.059000
2 Nov 8 1994 2:31PM 3653 0.060000 0.060000
Figure 11-21. The curve_data table, containing rates for a simple curve extending 10 years into the
future.
The curve_def_dependent table
The database permits you to define curves as functions of other curves. If you wanted
to define a CP basis curve as the difference of two other curves, such as a CP curve
and a LIBOR curve, you would store this relationship in the curve_def_dependent
table.
The shift_rate, slope_rate, and square_rate fields relating a dependent curve to a

polynomial transformation of an underlying curve are not implemented in version
5.2.1 of the Infinity Market Environment Manager application.
When the curve_def_dependent table is used to record the addition, subtraction,

multiplication, or division of two curves (related_curve_1 and related_curve_2), the
curve_curve_operator_code (‘ADD’, ‘SUB’, ‘MUL’, or ‘DIV’) specifies the
mathematical operation used to relate the two curves.
For example, curve 108 is the resultant curve of the sum ( curve_curve_operator_code
‘ADD’) of curve 6 (a LIBOR curve) and curve 74 (a flat LIBOR spread curve).
Table name: curve_def_dependent
curve_id 108
related_curve1_side_code NULL
related_curve1_id 6
shift_rate NULL
slope_rate NULL

Table name: curve_def_dependent
square_rate NULL
related_curve2_id 74
curve_curve_operator_code ADD
related_curve2_side_code NULL
Figure 11-22. The curve_def_dependent table, specifying that curve 108 is the sum of curve 6 and
curve 74.
The curve_def_derived_sec table
The curve_def_derived_sec table is designed to store sec_id numbers for the

securities used to build a derived curve. In the following example, the curve is built up
from money markets, futures, and swap legs. There are 16 of these instruments in
total, and hence 16 records in the curve_def_derived_sec table.
Table: curve_def_derived_sec
sec_id curve_id def_datetime settlement_sec_id
54 6 Mar 21 1995 1:25PM NULL
55 6 Mar 21 1995 1:25PM NULL
56 6 Mar 21 1995 1:25PM NULL
57 6 Mar 21 1995 1:25PM NULL
58 6 Mar 21 1995 1:25PM NULL
59 6 Mar 21 1995 1:25PM NULL
60 6 Mar 21 1995 1:25PM NULL
1008 6 Mar 21 1995 1:25PM NULL
1009 6 Mar 21 1995 1:25PM NULL
1010 6 Mar 21 1995 1:25PM NULL
1011 6 Mar 21 1995 1:25PM NULL
1012 6 Mar 21 1995 1:25PM NULL
1016 6 Mar 21 1995 1:25PM NULL
1017 6 Mar 21 1995 1:25PM NULL
1018 6 Mar 21 1995 1:25PM NULL
1019 6 Mar 21 1995 1:25PM NULL
Figure 11-23. The curve_def_derived_sec table, containing the sec_id

numbers of the securities underlying derived curve 6.

In order to determine which types of securities were represented, you could query the
sec table, producing the values show below.
Table: sec
sec_id currency_code sec_type_code
54 USD FUTURE
55 USD FUTURE
56 USD FUTURE
57 USD FUTURE
58 USD FUTURE
59 USD FUTURE
60 USD FUTURE
1008 USD MONEY_MARKET
1016 USD SWAP_LEG
1017 USD SWAP_LEG
1018 USD SWAP_LEG
1019 USD SWAP_LEG
Figure 11-24. Records in the sec table displaying the

sec_type_code of each security underlying derived curve 6.
Additionally, the actual market quotes for these securities would be found in the
sec_quote table, indexed by sec_id.
Keep in mind that the Infinity Data Model does not perform the calculations to
actually derive the curves; it only stores the data used to generate the curves and the
resulting curve data. A curve generation application such as Infinity’s Market
Environment Manager is required in order to derive curves.

The curve_def_derived_curve table
The curve_def_derived_curve table stores data about the underlying curves used to
generate a derived curve. It is used for generating volatility curves. For each instance
of this table, there is a curve_id, an underlying_curve_usage_code (used to specify
whether the curve is used for discounting or forecasting), the underlying_curve_id,
and the underlying_curve_side_code (not implemented in the Infinity Market
Environment Manager application).
The following sample entries show the curve_def_derived_curve table being used to
model a USD 3-month LIBOR volatility curve (curve_id 91) built from an underlying
USD 3-month LIBOR interest curve (curve_id 88).
Table name: curve_def_derived_curve
curve_id 91 91
underlying_curve_usage_code FORECAST DISCOUNT
underlying_curve_id 88 88
underlying_curve_side_code NULL NULL
Figure 11-25. Entries in the curve_def_derived_curve table, identifying curve 88 as the underlying
curve for derived curve 91.
Curve Holidays
The curve_hol_city table organizes information about the holiday schedules that affect
a curve’s rate data. For example, a LIBOR curve would be subject to London holidays,
and a PRIME rate curve would be subject to New York holidays.
The instance of the curve_hol_city table below shows that New York holidays apply to
curve 10.
Table name: curve_hol_city
curve_id 10
city_code NYC
hol_type_code PAYMENT
Figure 11-26. The curve_hol_city table, specifying New York holidays for curve 10. All three attributes
contribute to the primary key.
Chapter 12
Volatility Surface Tables
Within the Montage Data Model, there is a group of tables that allow you to create and
store volatility surfaces. These tables all begin with the prefix vs_.
Volatility Surface Definitions

As is the case with the curve tables, the general representation of each volatility
surface is stored in the vs table. For each surface, there is only a single record in this
table. The table also contains a vs_def_code value, specifying the type of surface
being modeled. The infsys_montage_domain table, with domain_name =
vs_def_domain, lists the range of supported vs_def_code values. Currently, these are
SIMPLE and TENOR_SPREAD. A simple surface is a three-dimensional set of
volatility points (as decimal values) plotted versus expiration date, tenor (of the
underlying instrument), and strike rate. Expiration dates can be represented either as
specific dates or as terms relative to the date on which the surface has been defined.
For a tenor-spread, the points along the tenor axis are represented as a spread relative
to the base tenor of the surface.
Each surface is uniquely identified by a vs_id. A volatility surface may be regenerated

for new dates after its original definition date. Each time the surface is regenerated and
saved, there will be an entry in the vs_datetime table and a corresponding complete
set of data points stored in the vs_data table (note that regenerating does not produce a
new entry in the vs table). In addition, depending on the definition of the surface, there
may be entries in the various vs_def_ tables.
The attributes of the vs table and related tables are detailed below.
Table name: vs

vs_id 0 VS_Id:int(4)0 PK
vs_name 0 VS_Name:char(12)
vs_def_code 0 VS_Def_Code:char(12)
remark 1 Remark:varchar(250)
strike_quote_method_code 1 Quote_Method_Code:char(12)
maturity_date_roll_code 1 Date_Roll_Code:char(12)
unit_time_code 0 Unit_Time_Code:char(12))
version 5.2 Volatility Surface Definitions 12-1

Figure 12-1. Table structure for the vs entity.
Table name
vs_def_exp_relative
vs_id 0 VS_Id:int(4) PK vs_datetime
def_datetime 0 Datetime:datetime(8) PK vs_datetime
exp_term 0 Term:int(4) PK
vs_def_exp_specific
exp_date 0 Datetime:datetime(8)) PK
vs_def_strike
strike 0 Value:float(8) PK
vs_def_tenor
tenor 0 Term:int(4) PK
vs_tenor_spread
bid_spread 0 Value:float(8)
offer_spread 0 Value:float(8)
Figure 12-2. Table structures for the vs, vs_def_exp_relative, vs_def_strike, vs_def_tenor, and vs_tenor_spread
entities.
Storing volatility surfaces in the tables
The following example shows an entry in the vs table for a tenor spread surface. Most
of the parameters are descriptive, as in the case of curves: the surface is for USD
LIBOR instruments, which are likely to be based on money market futures (quote
method) and hence have a 2 day settlement period and a modified following date roll.
Table name: vs
vs_id 21
user_code login_1
currency_code USD
12-2 Volatility Surface Tables Infinity Data Model Developer’s Guide

Table name: vs
vs_id 21
vs_name generic
vs_def_code TENOR_SPREAD
remark basic example
strike_quote_method_code MM_FUTURE
settlement_term 2
maturity_date_roll_code MOD_FOLLOW
unit_time_code 360_DAY_YEAR
Figure 12-3. An entry in the vs table listing the general specifications for tenor spread surface 21.
This surface is a tenor-spread, so we would expect to have an entry in the

vs_tenor_spread and vs_def_tenor tables as well. The vs_def_tenor table entry shows
that the base tenor for this surface is a term of 30, or 1 month.
Table name: vs_def_tenor
vs_id 21
def_datetime Feb 15 1995 4:29PM
tenor 30
Figure 12-4. An entry in the vs_def_tenor table specifying that the base tenor for
surface 21 is 30 days.
In order to indicate the spread for the points relative to the base tenor, we enter the
spreads (as a function of tenor) in the vs_tenor_spread table. Note that the base tenor
of 30 shows up in this table as well, and, as expected, has a spread of zero. Also note
that tenors are represented as terms measured in days (e.g. a term of 360 is one year).
Table name: vs_tenor_spread
vs_id def_datetime tenor bid_spread offer_spread
21 Feb 15 1995 4:29PM 7 -0.010 -0.010
21 Feb 15 1995 4:29PM 30 0.000 0.000

Table name: vs_tenor_spread
vs_id def_datetime tenor bid_spread offer_spread
21 Feb 15 1995 4:29PM 180 0.010 0.010
21 Feb 15 1995 4:29PM 360 0.015 0.015
21 Feb 15 1995 4:29PM 540 0.020 0.020
21 Feb 15 1995 4:29PM 1800 0.025 0.025
Figure 12-5. Entries in the vs_tenor_spread table showing the spreads for terms
of up to five years.
The remaining axes for the surface are the expiration period of the option and the
strike price. This information is contained in the tables vs_def_strike and either
vs_def_exp_relative or vs_def_exp_specific. The vs_def_strike table gives the range
of strike rates:
Table name: vs_def_strike
vs_id def_datetime strike
21 Feb 15 1995 4:29PM 0.04
21 Feb 15 1995 4:29PM 0.05
21 Feb 15 1995 4:29PM 0.06
21 Feb 15 1995 4:29PM 0.07
21 Feb 15 1995 4:29PM 0.08
Figure 12-6. Entries in the vs_def_strike table

listing strike rates for surface 21.

The vs_def_exp_relative table specifies expiration dates as terms relative to the
creation date and time of the surface (had these expiries been specific dates, they
would have been saved to the vs_def_exp_specific table instead, with a fixed exp_date
value in place of an exp_term value):
Table name: vs_def_exp_relative
vs_id def_datetime exp_term
21 Feb 15 1995 4:29PM 7
21 Feb 15 1995 4:29PM 30
21 Feb 15 1995 4:29PM 180
21 Feb 15 1995 4:29PM 360
21 Feb 15 1995 4:29PM 720
21 Feb 15 1995 4:29PM 1080
21 Feb 15 1995 4:29PM 1440
Figure 12-7. Entries in the vs_def_exp_relative

table specifying expiration dates for surface 21.
The structure of the vs_data and vs_datetime fields are as follows:
Table name
vs_data
vs_datetime 0 Datetime:datetime(8) PK vs_datetime
exp_offset 0 Offset_Day:int(4) PK
strike 0 Value:float(8) PK
vs_datetime
vs_id 0 VS_Id:int(4) PK vs
vs_datetime 0 Datetime:datetime(8) PK
vs_instance_code 0 Instance_Code:char(12)
vs_status_code 0 Status_Code:char(12)
Figure 12-8. Table structures for the vs_data and vs_datetime entities.
Once the parameters of the volatility surface have been set, the surface points
can be generated. Each instance will be date and time stamped and recorded in

the vs_datetime table (note the analogy to the curve_datetime
table):0.000000000000000
Table name: vs_datetime
vs_id 21
vs_datetime Feb 15 1995 4:29PM
vs_instance_code CLOSE
vs_status_code OPEN
Figure 12-9. An entry in the vs_datetime table stating that an instance of surface 21
has been generated for February 15, 1995, at 4:29.

In a similar analogy to the curve_data table, the actual datapoints for volatility
surfaces are stored in the vs_data table. Note that expiration is given as actual offset
days relative to the start date of the surface. Five primary keys are required to describe
a point on the surface: vs_id, vs_datetime, exp_offset, strike, and tenor.
Table name: vs_data
exp_
vs_id vs_datetime strike tenor bid_value offer_value
offset
21 Feb 15 1995 4:29PM 9 0.04 30 0.17 0.17
21 Feb 15 1995 4:29PM 9 0.05 30 0.17 0.17
21 Feb 15 1995 4:29PM 9 0.06 30 0.17 0.17
21 Feb 15 1995 4:29PM 9 0.07 30 0.17 0.17
21 Feb 15 1995 4:29PM 9 0.08 30 0.17 0.17
21 Feb 15 1995 4:29PM 30 0.04 30 0.17 0.17
21 Feb 15 1995 4:29PM 30 0.05 30 0.17 0.17
21 Feb 15 1995 4:29PM 30 0.06 30 0.17 0.17
21 Feb 15 1995 4:29PM 30 0.07 30 0.17 0.17
21 Feb 15 1995 4:29PM 30 0.08 30 0.17 0.17
21 Feb 15 1995 4:29PM 183 0.04 30 0.17 0.17
21 Feb 15 1995 4:29PM 183 0.05 30 0.17 0.17
21 Feb 15 1995 4:29PM 183 0.06 30 0.17 0.17
21 Feb 15 1995 4:29PM 183 0.07 30 0.17 0.17
21 Feb 15 1995 4:29PM 183 0.08 30 0.17 0.17
21 Feb 15 1995 4:29PM 370 0.04 30 0.17 0.17
21 Feb 15 1995 4:29PM 370 0.05 30 0.17 0.17
21 Feb 15 1995 4:29PM 370 0.06 30 0.17 0.17
21 Feb 15 1995 4:29PM 370 0.07 30 0.17 0.17
21 Feb 15 1995 4:29PM 370 0.08 30 0.17 0.17
21 Feb 15 1995 4:29PM 734 0.04 30 0.17 0.17
21 Feb 15 1995 4:29PM 734 0.05 30 0.17 0.17
21 Feb 15 1995 4:29PM 734 0.06 30 0.17 0.17
21 Feb 15 1995 4:29PM 734 0.07 30 0.17 0.17
21 Feb 15 1995 4:29PM 734 0.08 30 0.17 0.17
21 Feb 15 1995 4:29PM 1098 0.04 30 0.17 0.17

Table name: vs_data
exp_
vs_id vs_datetime strike tenor bid_value offer_value
offset
21 Feb 15 1995 4:29PM 1098 0.05 30 0.17 0.17
21 Feb 15 1995 4:29PM 1098 0.06 30 0.17 0.17
21 Feb 15 1995 4:29PM 1098 0.07 30 0.17 0.17
21 Feb 15 1995 4:29PM 1098 0.08 30 0.17 0.17
21 Feb 15 1995 4:29PM 1463 0.04 30 0.17 0.17
21 Feb 15 1995 4:29PM 1463 0.05 30 0.17 0.17
21 Feb 15 1995 4:29PM 1463 0.06 30 0.17 0.17
21 Feb 15 1995 4:29PM 1463 0.07 30 0.17 0.17
21 Feb 15 1995 4:29PM 1463 0.08 30 0.17 0.17
Figure 12-10. Entries in the vs_data table describing the February 15, 1995, instance of tenor spread
surface 21.
The above data are for a flat 17% surface. It has 35 points which corresponds to the
matrix of 7 expiries times 5 strike values. The third dimension is given by the 6 tenor-
spreads. Consequently, had this been a simple surface, there would have been 210
records in the vs_data table. Just as modeling curves can require many instances of
the curve_data table, modeling volatility surfaces can require many instances of the
vs_data table.
Chapter 13
Portfolio Tables
Within the Infinity Data Model, there is a group of tables that allow you to group
trades into sets called portfolios.
A portfolio of trades would typically be those you would want to analyze in a group.
You might want to define a portfolio of JPY swaps, a portfolio of trades engineered by
a certain trader, or a portfolio of bonds that mature before a certain date.
Each portfolio is saved as a set of selection criteria which will be used to retrieve
trades from the database. The flexibility of portfolio definitions in the Data Model is
designed to facilitate risk management.
Trades can also be assigned to transactions, and they can be assigned to accounts. A
transaction would typically be a set of related trades, done together for a common
financial purpose, such as a cross-currency swap and a related currency hedge. To see
how trades are assigned to transactions or accounts, see Chapter 7, Transaction and
Trade Tables.
Portfolio Definitions: Dynamic and Static

The database permits you to define portfolios both statically and dynamically.
Dynamic portfolios are those defined by broad definitions, like “USD/JPY swaps.” A
static portfolio definition can be used to specifically enumerate the trades to be
included in a portfolio, like “trades 31, 45, and 56.”
Dynamic portfolio definitions can be saved to the portfolio tables, with search criteria
saved to the portfolio_def table and structured query language (SQL) statements (if
any) saved to the portfolio table. If a portfolio has been saved as a set of search criteria,
the application retrieving the trades will create SQL statements from those criteria at
the time the trades are retrieved. If the portfolio has been saved as a set of SQL
statements, the application will apply the SQL statements at runtime to retrieve a set
of trades from the database.
Dynamic portfolio definitions only set guidelines for the types of trades to be included
in a portfolio. As trades are added to the database, they are not automatically included
in any dynamic portfolios. Instead, applications which use portfolios will retrieve
trades matching the portfolio definition only when instructed to do so.
A typical dynamic portfolio would be defined to include all USD caps. Within the
Data Model, this portfolio could be defined with an SQL statement saved to the
version 5.2 Portfolio Definitions: Dynamic and Static 13-1

portfolio table of the database. The SQL statement for a USD cap portfolio might look
like the following:
SELECT trade.trade_id, trade_leg.trade_leg_id
FROM trade_leg, trade, w_sec_denormal
WHERE trade.trade_status_code IN (’PENDING’,’BOOKED’)
AND w_sec_denormal.sec_type_code IN (’CAP’)
AND w_sec_denormal.currency_code IN (’USD’)
AND trade_leg.sec_id = w_sec_denormal.sec_id
AND trade_leg.trade_id = trade.trade_id
The database entry for this portfolio, called “MTM_CAP”, is shown in Figure 13-2.
Each time an application needs to update the portfolio this SQL statement is issued,
and all of the USD caps with a “pending” or “booked” trade status are retrieved from
the database to populate the portfolio.
Retrieving trades for portfolios involves querying the trade, trade_leg, and
w_sec_denormal tables. The trade and trade_leg entities are discussed in Chapter 7,
Transaction and Trade Tables. The w_sec_denormal table is a denormalized table
used in Infinity’s Risk Manager and Scenario Builder applications to accelerate
portfolio selection. The table duplicates information that would otherwise have to be
retrieved from the sec, trade_leg, bond_header, swap_leg_header, and
exchange_header tables.
SQL statements stored in the portfolio table may also be used to define static
portfolios. A static portfolio definition specifies the identification numbers of the
trades in the portfolio. Using SQL, the following portfolio definition extracts trades
with ids from 10 through 34:
SELECT trade.trade_id, trade_leg.trade_leg_id

FROM trade_leg, trade
WHERE trade.trade_status_code IN
(’PENDING’,’BOOKED’, ’PRICING’)
AND trade.trade_id >= 10
AND trade.trade_id <= 34
The database entry for this portfolio, named “FIRST34TRANS”, is shown in Figure
13-3, on page 13-5.
13-2 Portfolio Tables Infinity Data Model Developer’s Guide

Using the Portfolio Tables
There are two portfolio tables: portfolio and portfolio_def.
Table name
portfolio
portfolio_name 0 Portfolio_Name:varchar(50) PK
portfolio_status_code 0 Status_Code:char(12)
select_clause 1 Sql_Clause:text(16)
from_clause 1 Sql_Clause:text(16)
modified_b 0 Bool:bit(1)
where_clause 1 Sql_Clause:text(16)
portfolio_def
portfolio_criterion_code 0 Portfolio_Criterion_Code:varchar(50) PK
portfolio_name 0 Portfolio_Name:varchar(50) PK
portfolio_criterion_choice 1 Portfolio_Criterion_Choice:varchar(50) PK
Figure 13-1. Structure of the portfolio, portfolio_criterion_domain, and portfolio_def tables.
Each portfolio definition is saved as one record in the portfolio table and one or more
records in the portfolio_def table. Any SQL statements in the definition will be saved
in the portfolio table, and there will be one record in the portfolio_def table for each
search criterion in the definition.
Using the portfolio table to define a portfolio
The portfolio table contains the three attributes used to store SQL portfolio definitions.
The table also specifies whether a portfolio may be modified.
The portfolio_status_code attribute defines whether the portfolio is OPEN or

LOCKED. Portfolios with an OPEN status may be modified and deleted using the
Infinity Risk Manager application, while LOCKED portfolios may not.
The modified_b value is a boolean variable indicating whether the portfolio uses a
custom SQL definition. Set the value of this variable to 0 if your definition is based
only on criteria saved to the portfolio_def table. If the portfolio is defined using SQL
statements, set this variable to 1.
The select_clause, from_clause, and where_clause columns contain the SQL

statements used to retrieve the trades in the portfolio.
version 5.2 Using the Portfolio Tables 13-3

Using the portfolio_def table to define a portfolio
The portfolio_def table contains the non-SQL portion of the portfolio definition. A
unique record in the portfolio_def table is made up of a portfolio_criterion_code
identifying the attribute of the trade being used as a search criterion, paired with a
portfolio_criterion_choice value specifying the desired quality for that attribute. The
list of valid codes for portfolio_criterion_code come from the
infsys_montage_domains table, with domain_name = portfolio_criterion_domain.
Along with the portfolio_name, these values constitute a unique record in the
portfolio_def table. Most portfolio definitions will require a number of records in the
portfolio_def table.
Storing portfolio definitions in the portfolio tables
The following tables show the entries in the portfolio and portfolio_def tables for the
examples described above.
Table name: portfolio
portfolio_name MTM_CAP
portfolio_status_code OPEN
select_clause SELECT trade.trade_id, trade_leg.trade_leg_id
from_clause FROM trade_leg, trade, w_sec_denormal
modified_b 0
(’PENDING’,’BOOKED’)
AND w_sec_denormal.sec_type_code IN (’CAP’)
where_clause
AND w_sec_denormal.currency_code IN (’USD’)
AND trade_leg.sec_id = w_sec_denormal.sec_id
Figure 13-2. The entry in the portfolio table for an SQL-defined portfolio which includes all USD caps
with a trade_status of PENDING or BOOKED.

Table name: portfolio
portfolio_name FIRST34TRANS
portfolio_status_code OPEN
select_clause SELECT trade.trade_id, trade_leg.trade_leg_id
from_clause FROM trade_leg, trade
modified_b 1
(’PENDING’,’BOOKED’, ’PRICING’)
where_clause AND trade_leg.trade_id = trade.trade_id
AND trade.trade_id >= 10
AND trade.trade_id <= 34
Figure 13-3. The entry in the portfolio table for an SQL-defined portfolio which includes all trades with
an identification number from 10 through 34.
These examples would have corresponding entries in the portfolio_def table. Each
would be the child of a portfolio instance and a portfolio_criterion instance. The
portfolio_def entries for portfolio “MTM_CAP” only are displayed below.
Table name: portfolio_def
portfolio_criterion_code CURR SEC_TYPE USE_INDEX_TERM
portfolio_name MTM_CAP MTM_CAP MTM_CAP
portfolio_criterion_choice USD CAP 0
Figure 13-4. The entries in the portfolio_def table for a portfolio defined to include all USD caps.
Application Interaction
To further understand the structure of the portfolio tables, it helps to observe their
interaction with the Infinity Risk Manager application. In the application’s Portfolio
Definition window, the user is given the option of creating a portfolio definition using
the given criteria codes or by writing custom SQL statements. When a user writes
custom SQL to define a portfolio, that information is stored in a single record in the
version 5.2 Application Interaction 13-5

portfolio table. When the user selects from the provided lists of criteria, that
information is stored as records in the portfolio_def table.
portfolio_criterion_code values
potential
portfolio_
criterion_
choice
values
Custom SQL
statements
would be
inserted
in one
record in
the portfolio
table.
Figure 13-5. Risk Manager’s Portfolio Definition window, displaying the definition of a portfolio
including all USD caps.
The portfolio menus in Figure 13-5 (currency, security type, leg type code, etc.) are all
portfolio_criterion_code values. Any of the values selected in these menus (BOND,
CAP, USD, FIXED, etc.) will be saved as a portfolio_criterion_choice value, creating a
record in the portfolio_def table for each criterion value saved. The portfolio definition
based on these menu selections (USD currency and CAP security type) would be
stored in two records in the portfolio_def table. The bottom third of the window
displays the SQL definition of the portfolio. SQL definitions are optional, but once a
portfolio has been saved as a set of SQL statements, only the SQL definition will be
used to populate the portfolio. The definition entered in the Custom SQL window is
stored in one record in the portfolio table, in the select_clause, from_clause, and
where_clause fields.

Chapter 14
Risk Report Tables
Overview
Purpose
This chapter is written to assist users who want to retrieve risk reports from the
Infinity Data Model after they have generated and stored the reports using the Infinity
Risk Manager or Infinity Scenario Builder application.
Sybase / isql
This chapter was created for users of the Sybase version of the Data Model. Oracle
and other database users may have to adjust some queries, but the basic table structure
is the same.
Sample queries given in this chapter are designed to run using Sybase’s Transact-
SQL. Users may also employ other commercially available query tools (e.g. Microsoft
Access, Bluestone’s dbViewer) to query the tables.
This chapter assumes basic familiarity with SQL, as well as basic familiarity with
usage of Infinity’s Risk Manager application.
Further documentation
Consult the risk table diagrams in the Infinity Data Model Reference Guide for an
overview of the tables discussed here.
For more information about using Infinity Risk Manager and Infinity Scenario
Builder, please refer to the Infinity Risk Manager and Scenario Builder Reference
Guide.
A note on Data Model versions
The basic risk table structure remains the same from version to version of the
database. However, since some report-related attributes and some risk parameter
version 5.2 Overview 14-1

attributes may change with new versions of the Data Model, your custom report-
writing scripts may require minor updates, but their overall structure should remain
valid across Data Model versions.
Running Scenario Builder from the command line
Purpose
Scenario Builder allows users to automate evaluation and risk analysis of large groups
of trades. Each scenario, or “process,” is a set of instructions defining the group of
trades to be analyzed, the type of analysis to be done, the assumptions and methods
with which the analysis will be done, and the means by which the resulting risk
reports will be output.
A scenario is built by combining portfolios, parameter settings, curves, and report

instructions into a sequence of events. Each scenario can be run many times,
generating a new batch of reports each time.
While the application provides a graphical user interface, Scenario Builder can also be
run in a command line mode. The command line interface, combined with the ability
to save generated reports to the Infinity database, allows your organization to integrate
Scenario Builder with existing risk reporting systems.
Command line mode
This mode requires the user to supply the name of the scenario (risk_batch_name), the
valuation_date, and login information. Before it can be run in command line mode,
the scenario must already have been defined using Scenario Builder in its normal,
graphical user interface mode.
Scenarios run from the command line must save their output to the Infinity database,
so each step of the scenario definition must include the output instruction to
SAVE_TO_DB only.
Running Scenario Builder from the command line also requires that all the necessary
Infinity environment variables have been set in the shell from which the command is
invoked. If these settings are buried in a script, rather than in the user’s .cshrc or .login
file, then these environment variables will need to be set by hand before running the
application. Even though running the application from the command line does not
invoke any application windows, it is still necessary to set the ND_PATH environment
variable for the application to run.
14-2 Risk Report Tables Infinity Data Model Developer’s Guide

When Scenario Builder is run in command line mode, the only output to the screen is
the risk_batch_run_id number of the scenario process (printed to standard output).
This number is the key to retrieving the batch of risk reports which the process has
saved to the database. This number can also be used to access the Error Log file,
which is saved in the user’s home directory or in the error log directory specified using
the Preferences command in Scenario Builder’s Process menu.
To invoke Scenario Builder from the command line, first change directories to the
Scenario Builder application directory. Then type the command “scenario” with the
following arguments:
scenario <risk_batch_name> <valuation_date>
<risk_batch_name> is the name (case sensitive) of the previously defined

scenario. If the scenario name contains spaces, the name must be enclosed in double
quotes (“ ”).
The <valuation_date> must be entered in the format MM/DD/YYYY.
For example, to run the scenario “END OF DAY” for May 26, 1995, change
directories to the Scenario Builder directory and type:
scenario “END OF DAY” 5/26/1995
After you issue this command, the application will automatically search for login
information in a file called “infLogin.scenario” in the home directory of the user
running the scenario.
An infLogin file may also be saved to the application’s executable directory for use as
the default infLogin file for all users; the application will read this default infLogin file
only for those users who have no infLogin file in their home directory.
If the application fails to find an infLogin file in either your home directory or the
application’s executable directory, the standard Infinity login dialogue box will
prompt you to enter the server name, database name, user name, and password.
To make an “infLogin.scenario” file, create a text file listing the server name, database
name, Infinity user login name, and Infinity user password on separate lines. For
example, for user j_trader on SERVER_1, database_4, with password “tintin,” the file
would read:
SERVER_1
database_4
j_trader
tintin
To prevent unauthorized users from using the login and password, put the UNIX
security template “r-x------” on the file.
version 5.2 Running Scenario Builder from the command line 14-3
Note that the user login name and password stored in the infLogin file are the Infinity
application login and password, not the Sybase server isql login and password.
A csh script may be used to simplify running of Scenario Builder from the command
line. The script could be written as follows:
!#/bin/csh
cd /infinityDir/apps/scenario
setenv ND_PATH ../oit-lib
scenario "BatchName" 5/26/1995
Output
When running Scenario Builder from the command line, the application generates the
desired reports, saves them to the risk_rpt_ tables of the database, and returns a
risk_batch_run_id number to the screen.
Scenario Builder also writes an error log file to the user’s home directory (or to the
directory specified using the Preferences command in Scenario Builder’s Process
menu). Each error log file is named “error_log.n”, where “n” is the risk_batch_run_id
number of the scenario.
The remainder of this chapter assumes that the scenarios ran properly, with no errors.
Errors should be corrected by using Scenario Builder running in normal GUI mode to
redefine curve groups or portfolio definitions as required.

Basic queries
The risk_batch_run_id number
The risk_batch_run_id number is a primary key in the risk_batch_run table. The

risk_batch_run table contains four important identification numbers as primary keys.
• risk_batch_run_id: identifies a batch of reports saved to the database

by a single running of a scenario
• risk_batch_id: identifies a scenario (also known as batch) definition.
This attribute migrates from the risk_batch table, where the scenario
is defined.
• risk_batch_def_id: identifies a step within a scenario definition. This
attribute migrates from the risk_batch_def table, which contains one
row for each step in the scenario.
• risk_rpt_id: assigned to each report created by the batch. Use this
number to find the report you are looking for.
Looking for a risk report
Use SQL database queries to find the risk reports produced by your scenario. Retrieve
the entries in the risk_batch_run table which match the returned risk_batch_run_id
number. The table will contain an entry for each report produced by the scenario you
have just run, identifying that report by its risk_rpt_id.
select risk_rpt_id from risk_batch_run

where risk_batch_run_id = <id number>
Different types of risk reports are saved to different risk_rpt_ tables in the database.
For example, a mark-to-market by trade report with NPV values for 20 trades would
be saved as 20 rows in the risk_rpt_mtm table.
From your query of the risk_batch_run table, you know the risk_rpt_id of the report
you need, but you still do not know which of the risk_rpt_ tables contains your report.
A table called risk_rpt identifies the type of the report you have produced, keyed by
the report’s risk_rpt_id. Use the risk_rpt_id (retrieved previously from the
risk_batch_run table) to query the risk_rpt table. The report type is listed in the
risk_rpt_code column of the risk_rpt table.
select risk_rpt_code from risk_rpt

where risk_rpt_id = <the risk_rpt_id returned above>
version 5.2 Basic queries 14-5

The report itself is saved in the risk_rpt_ table which corresponds to that
risk_rpt_code. The table below lists the valid risk_rpt_codes and the names of their
corresponding risk_rpt_ tables.
Infinity table used

risk_rpt_code to store report output description
CASH risk_rpt_cash cash report
CASHFLOW_PRJ_DETAIL risk_rpt_projected_flow detailed cash flow projection

report
CASHFLOW_PRJ_SUMMARY risk_rpt_projected_flow summary cash flow projection

report
DIRECT_PERTURB_HEDGE risk_rpt_perturbation Direct perturbation
HEDGE_AGG risk_rpt_pdh_aggregate aggregate hedge report
HEDGE_DETAIL risk_rpt_pdh_detail detail hedge report
LADDERS_AGG risk_rpt_ladders_agg aggregate risk ladders report
LADDERS_DETAIL risk_rpt_ladders_detail detailed risk ladders report
MTM_BY_POSITION risk_rpt_mtm_by_position mark-to-market by security
MTM_BY_TRADE risk_rpt_mtm standard mark-to-market report
MTM_FIXING risk_rpt_mtm_fixing End-of-day fixing report
OPTION_AGG risk_rpt_option_aggregate aggregate option report
OPTION_DETAIL risk_rpt_option_detail detailed option report
OPTION_EXERCISE risk_rpt_option_exercise valuation report: option trades at

exercise date
PNL_DECOMP risk_rpt_pnl_decomp P & L decomposition report
PNL_DETAILED risk_rpt_profit_loss_detail Detailed P & L report
PNL_SUMMARY risk_rpt_profit_loss_detail Summary P & L report
PROFIT_LOSS_DETAIL risk_rpt_profit_loss_detail detailed profit and loss report

(obsolete in the Infinity Risk
Manager application)
RATE_RESET_AGG risk_rpt_rate_reset_aggregate aggregate rate reset report
RATE_RESET_DETAIL risk_rpt_rate_reset_detail detailed rate reset report
SENSITIV_DISCRETE_FORWARD risk_rpt_sensitiv_discrete discrete sensitivity report:

shifting forward curve

Infinity table used
risk_rpt_code to store report output description
SENSITIV_DISCRETE_YIELD risk_rpt_sensitiv_discrete discrete sensitivity report:

shifting yield curve
SENSITIV_DISCRETE_ZERO risk_rpt_sensitiv_discrete discrete sensitivity report:

shifting zero curve
SENSITIV_GROSS_CUSTOM risk_rpt_sensitiv_gross gross sensitivity report: custom

shifting
SENSITIV_GROSS_PARALLEL risk_rpt_sensitiv_gross gross sensitivity report: parallel

shifting
SENSITIV_GROSS_POLYNOMIAL risk_rpt_sensitiv_gross gross sensitivity report:

polynomial shifting
SENSITIV_VOLATILITY risk_rpt_sensitiv_discrete sensitivity to volatility points:

surface & curves
SENS_VOL_GROSS_PARALLEL risk_rpt_sensitiv_gross gross sensitivity report: parallel

volatility shift
SENS_VOL_GROSS_POLYNOMIAL risk_rpt_sensitiv_gross gross sensitivity report:

polynomial volatility shift
VALUE_AT_RISK risk_rpt_var RiskMetrics Value at Risk
Figure 14-1. The risk_rpt_code values and their corresponding tables in the Infinity Data Model
Once you know the risk_rpt_id number and the name of the appropriate table, you can
access your report. For a mark-to-market by trade report, the query would be as
follows:
select * from risk_rpt_mtm

where risk_rpt_id = <id>
Data is saved by row in the risk_rpt_ tables, but not tabulated into totals. So, if you
wanted to recreate an entire mark-to-market report, including a total NPV, you might
do the following (assuming a risk_rpt_id number of 20):
select * from risk_rpt_mtm

where risk_rpt_id = 20
select “Sum of NPV: ”, sum(npv) from risk_rpt_mtm
The first query returns all the rows in the report, each listing the NPV of a trade leg.
The second query returns the sum of all the NPV values. (Each NPV value is stored in
the “npv” column of the risk_rpt_mtm table.)
version 5.2 Basic queries 14-7

Looking for the parameters used in report generation
The parameters used for a particular risk report would be found in the risk_rpt_param
table, keyed again by risk_rpt_id. These parameters include the valuation date,
valuation method, time buckets, and other parameters which you might want to
include in your own custom reports. Most of these parameters are set using the Risk
Parameters window of Risk Manager. Consult the Infinity Risk Manager and Scenario
Builder Reference Guide for details.
Looking for the curves used in report generation
The curve assignments used in the generation of reports are stored in risk_rpt_curve_
tables. For example, to find the curves used to discount all CURRENCY securities in
risk report number 20, try:
select * from risk_rpt_curve_currency

Scenario definitions
risk_batch_def
The most important table in the definition of a scenario is the risk_batch_def table. It
includes a row for each analysis step in the scenario. The attributes of the
risk_batch_def table include:
• risk_batch_id: the id number for the whole scenario definition.
• risk_batch_def_id: the id number for the single step in the scenario.
• portfolio_name: the name of the portfolio to be analyzed in the single

step. Note that this attribute is of type “varchar”.
• risk_curve_group_id: the id number of the curve group used to price
the trades in the portfolio. This id number is matched with a name in
the risk_curve_group table.
• risk_param_group_name: the name of the group of parameters to be
used in risk analysis. The parameters themselves are saved in the
risk_param_group table. Note that this value is of type “varchar”.
• risk_analysis_code: the type of analysis to be done in the step.

Options are listed in infsys_montage_domains with domain_name =
risk_analysis_domain and include the following:
CASH,
CASHFLOW_PRJ_DETAIL,CASHFLOW_PRJ_SUMMARY,

DIRECT_PERTURB_HEDGE, HEDGE_AGG, HEDGE_DETAIL,
LADDERS_AGG, LADDERS_DETAIL, MTM_BY_POSITION,
MTM_BY_TRADE, MTM_FIXING, OPTION_AGG,
OPTION_DETAIL, OPTION_EXERCISE, PNL_DECOMP,
PNL_DETAILED_CUSTOM, PNL_DETAILED_DAILY,
PNL_DETAILED_MONTH_TO_DATE,
PNL_DETAILED_QUARTER_TO_DATE,
PNL_DETAILED_YEAR_TO_DATE,
PNL_SUMMARY_CUSTOM, PNL_SUMMARY_DAILY,
PNL_SUMMARY_MONTH_TO_DATE,
PNL_SUMMARY_QUARTER_TO_DATE,
PNL_SUMMARY_YEAR_TO_DATE, PROFIT_LOSS_DETAIL,
RATE_RESET_AGG, RATE_RESET_DETAIL,
SENSITIV_CUSTOM, SENSITIV_FORWARD,
SENSITIV_PARALLEL, SENSITIV_POLYNOMIAL,
SENSITIV_VOLATILITY, SENSITIV_YIELD, SENSITIV_ZERO.
The last four attributes in the bullet list above correspond to the first four columns
listed in the Scenario Builder application’s Scenario Definition window.
The contents of the Actions column, on the right side of Scenario Builder’s Scenario
Definition window, are stored in the risk_batch_rpt_instruct table. Instructions saved
from the Actions column direct the scenario’s output to the desired medium. For
command line scenarios, the Actions value must be “SAVE_TO_DB”.
Custom development
Changing portfolio names in a scenario
A single scenario definition may include instructions to produce as many reports as

you wish and instructions to analyze as many portfolios as you wish. However, since
each combination of a portfolio name and a report type must be defined on a separate
line in Scenario Builder’s main window, this method can become impractical if you
wish to run a standard battery of reports on a large or changing group of portfolios.
If you wish to perform the same analysis on multiple portfolios, you can gain
flexibility by creating a single scenario and running it repeatedly, changing only the
portfolio name each time. To do this, you will update the portfolio_name attribute in
the appropriate row(s) of the in the risk_batch_def table before each run of the
scenario.
Since the scenario will be run from the command line, the definition must specify that
the results of the analysis will be saved to the database (the risk_rpt_instruct_code in
the risk_batch_rpt_instruct table should be “SAVE_TO_DB”).
version 5.2 Custom development 14-9

To run the same scenario across a range of portfolios, implement the following
structure:
• use Scenario Builder to define a scenario specifying the analysis you
wish to perform. Include a dummy portfolio_name, which will be
replaced below
• read a new portfolio name from a flat file list of names
• use an SQL script to update the risk_batch_def table, setting the
portfolio_name = <new portfolio name>, taking care that this update
occurs in the row where the risk_batch_def_id and risk_batch_id
match those of the scenario you defined above
• run Scenario Builder from the command line using the
risk_batch_name of the scenario defined above
• select a new portfolio name from the flat file list and loop back to
update the risk_batch_def table.
Note that such a structure requires the use of a curve group which includes
assignments for all the securities in all the portfolios you intend to evaluate.
Changing base counterparties
Because each risk parameter group may be associated with more than one base
counterparty, risk parameters are defined in one table (risk_param_group) and then
linked to counterparties using a separate table (risk_param_group_base_cpty).
Note that if you run a risk report defining every single counterparty involved in the
portfolio as a base counterparty, the net exposure in all the risk reports will be zero.
To run the same analysis repeatedly, substituting a base counterparty each time,
implement the following structure:
• read a new counterparty name string from a file

• map the counterparty name to its org_id via the org table.
• use an SQL script to update the risk_param_group_base_cpty table,
matching the desired parameter group name
(risk_param_group_name) with the base_cpty_org_id (the org_id
returned in the previous step).
• run Scenario Builder from the command line without changing the
risk_batch_def table
• read a new counterparty name and loop back.
Note that in some cases the steps for using multiple base counterparties might have to
be combined with the steps for using multiple portfolios into a single script (if, for

instance, you are creating a script to automatically value every portfolio with respect
to a varying set of counterparties).
Changing risk parameters
The strategy outlined above could also be used to alter risk parameters directly in the
database, allowing the use of different parameters for each run of Scenario Builder. To
do this, you could implement the following structure:
• read a new value for a particular set of parameters

• update the risk_param_group table, keyed by
risk_param_group_name
• run Scenario Builder without changing the risk_batch_def table

• read new parameter values and loop back.
version 5.2 Custom development 14-11

Chapter 15
Access Permission Tables
The access permissions tables in the Infinity Data Model were created specifically to
support the Infinity security scheme specified via the Infinity Access Manager
application and enforced throughout the other applications. Thus, this chapter is not
useful to those who do not use the Infinity applications.
Granting an Infinity application login to a new user

A user must first exist in the system as an employee before he can be given permission
to run the Infinity applications. In terms of the Data Model, this statement implies that
there exists a row in prsn and a row in emp_prsn for the user getting access. These
tables are described in the chapter on organizations.
The table emp_prsn_login_name maps the login name to the emp_prsn_id and the
org_id. This table has the following structure:
Table name: emp_prsn_login_name

login_name 0 Login_Name:varchar(30) PK
emp_prsn_id 1 Prsn_Id:int(4)
org_id 0 Org_Id:Int(4)
Figure 15-1. Structure of the emp_prsn_login_name table.
The Infinity applications will track this user every time he attempts to log in to the
system, expiring his password when appropriate, according to the password policy set
up for the user. The table user_system_info stores this tracking.
Assigning a user to a group

Access permissions to Infinity applications are granted to groups, not individuals,
although a group could be 1 user. A user could be in several groups, too. The table
user_group identifies the login names for all users in a particular group. For a given
group, there would be 1 row in this table for each user assigned to that group.
version 5.2 Granting an Infinity application login to a new user 15-1

This table has the following structure:
Table name: user_group

user_login_name 0 Login_Name:varchar(30) PK emp_prsn_login_name
user_group_code 0 User_Group_Code:char(20) PK
auth_status_code 0 Auth_Status_Code:char(20)
entered_login_name 0 Login_Name:varchar(30)
entered_datetime 0 datetime:datetime(8)
authorized_login_name 1 Login_Name:varchar(30)
authorized_datetime 1 datetime:datetime(8)
Figure 15-2. Structure of the user_group table.
Valid user_group_code values are listed in infsys_montage_lists, with list_name ‘=

user_group_list. Users can add to this list by creating new groups using the Infinity
application Access Manager.
Note that assigning users to groups has to be authorized; the columns

authorized_login_name and authorized_datetime note the authorizing login and time
this authorization was performed.
Specifying the password policy for a user

Password policy is defined by user group, not user. If a user is in two groups, the user
obtains the more restrictive password policy.
The Infinity application Access Manager permits a user group to have a unique
password policy. Alternatively, a user group may take a default policy. If a user group
has a unique password policy, information about the policy is specified in the table
password_policy_info. The default password policy is specified in the table
default_password_policy_info. A user group that is using the default policy would not
have an entry in password_policy_info that matched its user_group_code.
15-2 Access Permission Tables Infinity Data Model Developer’s Guide

Table name: password_policy_info

user_group_code 0 User_Group_Code:char(20) PK
first_use_expiry_duration 0 Duration:int(4)
regular_expiry_duration 0 Duration:int(4)
max_failed_login_num 1 Max_Failed_Login_Num:int(4)
unused_expiry_duration 0 Duration:int(4)
auto_logoff_duration 0 Duration:int(4)
Figure 15-3. Structure of the password_policy_info table.
The default_password_policy_info table has the same columns as the

password_policy_info table, with the exception of the user_group_code column.
Assigning permissions to a group

The table valid_access_func_info lists every function supported by the Infinity
applications. This table is shipped with pre-loaded data. This table is read by Infinity
application Access Manager to determine the policy matrix displayed.
For each user group, the set of functions granted to that user group are listed in
access_perm_policy_matrix. There is one row in this table for each function granted.
This table is updated by the Infinity application Access Manager; in terms of the GUI,
there is one row in this table for every specified ‘Y’, for each user group.
You can add values to valid_access_func_info to get new functions recognized by the
Infinity application Access Manager. Note that the Infinity applications will only
recognize the functions that are in the pre-shipped table, so adding functions to our
applications will have no effect. Nevertheless, you can add entries to this table to have
Access Manager control functions in externally developed applications.
The table valid_access_func_info migrates information from the table

access_func_tmpl. If you add to valid_access_func_info, make sure you also add to
access_func_tmpl, or you may lose referential integrity.
version 5.2 Assigning permissions to a group 15-3

Appendix A
Data Model Changes in the 5.2.1 Release
Changes to Index and Key Definitions in v5.2.1

Prior to release 5.2.1, a significant deadlocking problem existed in Sybase
implementations among the tables sec, flow, trade, trade_leg, and sec_hol_city. In internal
tests, five concurrent processes were started. Each process submitted hundreds of
transactions typical of a front office production environment, with no pauses between
transactions. These processes are referred to subsequently as the TransDup processes.
In a non-audited environment, the following characteristics were observed:

• Percentage of transactions deadlocked: 57%
To correct this situation, a two-pronged approach was taken:

• The first tack was to investigate the deadlocked transactions and determine where
the deadlocks were occurring, i.e. specific data and index pages. To address this
part of the problem, Infinity changed a number of index and key definitions and
set a limit on the number of rows per page for the sec_hol_city table. These
changes are detailed below.
• The second tack involved a redesign of the seed tables, described in Chapter 5.
This investigation uncovered the following. First, a number of indexes were ill-
formed. They were defined on fields, such as code fields, whose data values are
severely clustered on a particular value. For example, consider the index XIE2sec
defined on currency_code in the table sec:
1> SELECT currency_code, count(*)

2> FROM sec
3> GROUP BY currency_code
4> go
currency_code
------------- -----------
ATS 1
AUD 22
BEF 1
CAD 32
CHF 88
DEM 183
DKK 1
ESP 1
FIM 1
version 5.2 Changes to Index and Key Definitions in v5.2.1 A-1

FRF 40
GBP 178
HKD 1
ITL 106
JPY 30
LUF 1
MXP 1
NKR 1
NLG 1
NZD 1
PTE 1
SEK 1
USD 6117
XEU 1
The value of 6117 for USD means that the large majority of code values are
equivalent, thereby negating the effectiveness of the index on that field.
Removal of unused indexes in v5.2.1
Checking the query plans, it was found that none of these indexes were used by any
query. These indexes were dropped from the data model. Specifically, the removed
indexes are
sec.XIE1sec
sec.XIE2sec
sec.XIE3sec
sec_hol_city.XIE1sec_hol_city
sec_hol_city.XIE2sec_hol_city
trade.XIE1trade
trade_leg.XIE1trade_leg
flow.XIE1flow
flow.XIE2flow
Redefinition of the primary key on sec_hol_city in v5.2.1
The primary key for sec_hol_city was redefined, rearranging the order of the fields to
match the query in the TransDup processes. Originally, the primary key was defined
on city_code, sec_id, and hol_type_code, but retrieval never specified a city_code. So, the
primary key was redefined to be on sec_id, hol_type_code, and city_code. In this way the
queries could make use of the index.
A-2 Data Model Changes in the 5.2.1 Release Infinity Data Model Developer’s Guide
Setting a limit on the number of rows per page for sec_hol_city
The sec_hol_city table remained a hotspot for contention. In Sybase System 11, the
max_rows_per_page parameter was set to the value 11. In System 10, however, this is
not available, so the sec_hol_city was given an additional character field of length 187
with blank as the default value to simulate this storage feature. This field is called
“filler” and will be removed once Infinity discontinues support for Sybase System 10.
version 5.2 Changes to Index and Key Definitions in v5.2.1 A-3

Appendix B
Data Model Administration
Purpose and contents

This chapter outlines the use of some Infinity database tables which are automatically
maintained by the Infinity applications, but which administrators may also want to
manipulate directly. This chapter also outlines the use of database tables which are
accessed by the Infinity applications but are not currently maintained via a GUI and
may require periodic maintenance.
This chapter gives suggestions for efficient pruning of the Infinity database in order to
hold down database size and thus increase general performance. It is intended to serve
as an introduction to the referential integrity issues an administrator would face when
designing a pruning strategy. The database does not require pruning. It has been
Infinity’s experience, however, that the performance of databases which reach large
sizes (0.5 gigabytes and up for front-office application installations) can benefit from
deleting or archiving certain unused records.
This chapter does not cover the topics of performance tuning or server configuration.
It only discusses the data itself.
Versions
Infinity version
This chapter is written to accompany Infinity Data Model version 5.2.1, but much of
the information here also applies to earlier versions of the Data Model. Note that the
version numbers of the Infinity Data Model and the Infinity applications do not always
match one another.
The current version number, release date, platform, and database type are stored in the
infsys_db_version_history table.
version 5.2 Purpose and contents B-1

RDBMS version
This chapter uses examples appropriate to the Sybase RBDMS version System 11.
Oracle and Sybase System 10 administrators may have to adjust some of the sample
queries, but the structure and usage of the Infinity data should still apply.
All code segments in this chapter were created using Sybase’s Transact-SQL and the
isql character-based interface.
Other resources
This chapter is focused on the contents of the Infinity Data Model tables. Database
administrators should refer to their Sybase or Oracle documentation for information
about data server performance tuning.
SQL debugging flag

The SQL debug flag can be an administrator’s best friend.
To view all the database interaction occurring in an application, put a one-line file
named “infDebugFlags” in the user home directory. This line should have one line of
text in it: “SQL”.
This flag will echo every database query to the standard output. Unless it is redirected,
this will be the terminal from which you invoke the application.
You should be sure to remove or comment out (with a # character) the debug flag once
you are finished using it, because it will significantly slow down performance for other
users who start the application while the flag is active.
For more information about the use of debug flags, see the Infinity paper Useful
Debug Flags.
Static Data Manager

The Infinity Static Data Manager application presents a GUI interface for assisting in
the maintenance of the following tables:
• reference index tables

• all _list tables
• contract_series_sec_type
• user_default
B-2 Data Model Administration Infinity Data Model Developer’s Guide

• relative securities (sec_relative)
• trading templates (sec_template)
• holiday tables (hol_data and hol_header)
Please refer to the Infinity Static Data Manager Reference Guide for information on
the modules of this application.
Database tables included in the GUI

This section outlines the usage of some tables which are automatically maintained by
the Infinity applications, but which administrators may also want to manipulate
directly.
The auth_status table
The auth_status table does not require any maintenance, but database administrators
should be keenly aware that if they write any scripts to manually change any tables
which have an auth_id and auth_b column, they must be sure to add rows to the
auth_status table.
For example, if an administrator writes a script to automatically populate the

organization tables, the scripts’ job is not finished once auth_id values are assigned to
the new organizations. Each auth_id value requires a row in the auth_status table to
let the applications know that the most recent authorization was given a “NEW”
auth_type_code and not a “DELETE” auth_type_code. Also note that the last used
auth_id value is stored in the auth_seed table. If you add auth_id values to the
database directly, be sure to increase the auth_seed table as well.
See the chapter on organizations for examples of the use of the auth_id in the Infinity
Data Model.
The w_sec_denormal table
When you first install the Infinity database, a stored procedure scans all the security
and header tables and populates w_sec_denormal with information from the these
security header tables.
This procedure should not need to be run again. The w_sec_denormal table is a
denormalized view of the security tables. Every time you insert, delete, or update a
record in a security or security header table, the corresponding action occurs on
w_sec_denormal via triggers such as sec_ti and swap_leg_header_ti.
version 5.2 Database tables included in the GUI B-3

The w_sec_denormal table must be properly maintained in order for the Risk
Manager application to successfully create portfolios of trades. The Risk Manager
application queries this table when looking for, for example, all USD LIBOR
3MONTH swap legs. This search is much faster than a join of the necessary security
tables.
There should always be the same number of rows in w_sec_denormal as in sec. An

administrator may want to check these totals periodically to make sure the triggers are
properly executing.
The trader_book_authorization table
The trader_book_authorization table keeps a record of which traders are allowed to

trade which products different currencies and trading books. The table is directly
maintained via the Trader Manager application.
Some administrators may prefer to circumvent the application and populate the table
directly in the database, particularly if they are adding large numbers of users.
The following Sybase SQL script populates the table to give every user the rights to
trade every product in every trading book for seven particular currencies. An
administrator would probably want to be a bit more selective than this, especially
because the script, as written below, does a five-way join. Administrators should thus
be careful with a large number of users, currencies, or trading books.
Note that the script uses view product_type_list and view currency_list instead of
infsys_montage_lists.
DELETE trader_book_authorization
go
INSERT INTO trader_book_authorization

SELECT DISTINCT
primary_business_entity.pbe_org_id,
emp_prsn_login_name.login_name,
product_type_list.product_type_code,
currency_list.currency_code,
trading_book.book_id
FROM
primary_business_entity,
emp_prsn_login_name,
product_type_list,
currency_list,
trading_book
WHERE
currency_list.currency_code IN
("USD", "CAD", "GBP", "NLG", "DEM",

"FRF", "AUD")
go
Speed buttons: trader_accel and exchange_blotter_accel
In Trader, Futures Trader, and Futures Options Trader, each user may create his or her
own “speed buttons” to create a default set of frequently-traded securities. These
buttons are defined directly through the applications and the definitions are unique to
each user.
When a user defines a speed button in the Trader application, this populates a row in
the trader_accel table. When a user defines a speed button in the Futures Trader or
Futures Options Trader application, this populates a row in the
exchange_blotter_accel table.
New application users may prefer to copy speed buttons from other users rather than
go through the trouble of defining their own. In this case, a database administrator
could assist their new user by adding rows to the exchange_blotter_accel and
trader_accel tables.
For example, if a new user with the login name “archie” wanted to copy the Futures
Trader and Futures Options Trader speed buttons defined by the user with the login
name “jughead,” an administrator might do the following to update the
exchange_blotter_accel table:
1> select * from exchange_blotter_accel where

user_login_name = ’jughead’
2> go
user_login_name button_index
product_type_code
button_label exchange_code
currency_code
contract_series_code contract_name
option_contract_name
cpty_short_name broker_short_name
book_name
trade_status_code put_call_code strike_price
------------------------------ ------------ ------------
-----
jughead 0 FUTURE
SEP 95 CME USD
EURODOLLAR3M SEP 95 NULL
BANKA BROKER GLOBAL
PENDING NULL 0.000000
jughead 1 FUTURE
DEC 95 CME USD
EURODOLLAR3M DEC 95 NULL
BANKA BROKER GLOBAL
version 5.2 Database tables included in the GUI B-5

jughead 2 FUTURE
MAR 96 CME USD
EURODOLLAR3M MAR 96 NULL
BANKA BROKER GLOBAL
jughead 3 FUTURE
JUN 96 CME USD
EURODOLLAR3M JUN 96 NULL
BANKA BROKER GLOBAL
(4 rows selected)
1> select * into #temp_blotter from

exchange_blotter_accel where
user_login_name = ’jughead’
2> go
(4 rows affected)
1> update #temp_blotter set user_login_name = ’archie’

2> go
(4 rows affected)
1> insert into exchange_blotter_accel

select * from #temp_blotter
2> go
(4 rows affected)
Database tables excluded from the GUI

This section outlines the use of Infinity database tables which must periodically be
maintained wholly outside the Infinity applications.
primary_business_entity
A Infinity application installation requires that one or more of the trading

organizations in the database be designated as a primary business entity (abbreviated:
PBE).
A primary business entity is the main legal unit for the bank. In transactions, the PBE
establishes perspective, in that the PBE side is always the “us” side of the transaction.
For example, if you work at Bank Q, and all the users of the system work for divisions
of Bank Q, your PBE will probably be Bank Q. In all except internal trades, the
counterparties with which Bank Q trades are not primary business entities. Consult the
Infinity publication Infinity Customer Information Manager Reference Guide for
information on modeling organizational structures.

There is no GUI for adding or removing this designation. The installation scripts
create one PBE (with org_id 1), but you may want to create another. To make an
organization a PBE, use the stored procedure inf_add_pbe.
The stored procedure requires one parameter, the org_id of the organization you wish
to designate as a PBE. This org_id number can be found in the org table.
Sample usage:
1> exec inf_add_pbe 12

2> go
This procedure adds data to, among other tables, primary_business_entity.
As with any stored procedure, the complete text of the inf_add_pbe procedure may be
found with the sp_helptext command (Sybase only).
FX settlement term: sec_settle_sec_city_spot
The FX Trader application references the sec_settle_sec_city_spot table to determine

the number of settlement days required when trading one currency for another.
For example, if, in your trading location, there is a two-day settlement on FX trades of
USD vs. CAD, an administrator should:
1. determine the sec_id numbers for USD and CAD currency securities. These can
be found using the following query:
select sec_id from sec

where sec_type_code = ‘CURRENCY’
and currency_code in (’USD’,’CAD’)
2. use the sec_id numbers to populate sec_settle_sec_city_spot. If the two sec_id

numbers are 1001 and 1002, and you are trading in New York City, and the
settlement gap should be 2 days, one should insert into the table:
insert into sec_settle_sec_city_spot

values (1001, 1002, ’NYC’, 2)
The city_code value must be a valid code listed in the infsys_montage_lists table, with
list_name = city_list.
FX quote precision: sec_settle_sec_tick_size
The FX Trader application references the sec_settle_sec_tick_size table to determine

the number of digits of precision used in FX spot rate quotes.
version 5.2 Database tables excluded from the GUI B-7

The default precision is four decimal places, e.g., 1.2345. The FX Trader application
would break this quote into two pieces: a 1.23 spot rate and .0045 “small figure.” This
distinction is made in the application code and is neither determined in the database
nor saved to the database. When an FX trade is retrieved from the database, the
exchange rate is determined based on the trade_amount numbers in the trade_leg
table.
Suppose you wanted to change the precision of the USD-CAD currency pair from four
to five digits. You would:
1. determine the sec_id numbers for USD and CAD currency securities. These can
be found using the following query:
select sec_id from sec

where sec_type_code = ‘CURRENCY’
and currency_code in (’USD’,’CAD’)
2. use the sec_id numbers and the desired tick_size_code to populate

sec_settle_sec_tick_size. In this case, you want accuracy out to the ten-
thousandths decimal place, so you would use tick_size_code TICK_10000.
insert into sec_settle_sec_tick_size

values (1001, 1002, ’TICK_10000’)
The tick_size_code value must be a valid code listed in the infsys_montage_domains

table, with domain_name = tick_size_domain.

The trading_book table
To book trades using the applications, you must first define one or more trading books
to which the trades will be assigned.
The stored procedure inf_add_trading_book adds trading books to the database. The
stored procedure accepts two arguments, the name of the trading book and the org_id
of the organization that trades it. The stored procedure then populates the tables
trading_book, org_book_relation, and auth_status.
Names of trading books can have up to 12 characters. Spaces are not permitted (use an
underscore “_” instead). The Infinity applications require that the trading book name
be expressed in CAPITAL letters only.
Execute the stored procedure with the “EXEC” command, providing the name of the
trading book and org_id of the org that owns it. You do not have to put the name of the
trading book in quotes unless it is also a Sybase or Oracle reserved word:
1> EXEC inf_add_trading_book <BOOK_NAME>, <org_id>

2> go
You can execute the stored procedure repeatedly to add more trading books.
As with any stored procedure, the complete text of the inf_add_pbe procedure may be
found with the sp_helptext command (Sybase only).
Customer Information Manager: Classification, Account Manager District,

Internal SIC Code, SIC Code
The Counterparty Information screen in Infinity Customer Information Manager

(ciMan) has several drop down list boxes for selecting values. The lists of available
values for the Account Manager District and Classification fields originate in the
info_value_str table; to make new values available in these list boxes, you must insert
values into that table directly.
The lists of available values for the Internal SIC code and SIC code fields come from
the info_value_num table. You must insert values directly into that table to have them
appear in the corresponding list boxes.
If you make changes to the info_value_str and info_value_num tables, you must
recompile ciMan.
You can modify the contents of the other list boxes in ciMan by using Infinity Static
Data Manager to add values to infsys_montage_lists. Inserting values to this table
does not require that you recompile ciMan.
version 5.2 Database tables excluded from the GUI B-9

Back office configuration tables
There are several database tables that you may periodically alter, to configure the back
office engines and applications. The use of these tables will be explained in
forthcoming documentation on the back office engines. Contact your Infinity
representative regarding the availability of these documents.
The physical network communications port used by the ffServer and eventServer must
be stored in event_rc_config. The directory where the eventServer object code resides
must be stored in event_server_home_config.
The physical network communications port used by the infTalkServer must be stored
in inftalk_rc_config.
Advice document production requires setting up several database tables:

trade_advice_matrix, advice, advice_format, control_advice_format, doc_type_info,
doc_rule, doc_index_info, doc_paragraph, doc_tmpl_group_info, doc_tmpl_info,
org_info_str. Refer to the advice production maintenance documentation for more
information.
Payment processing requires setting up the payment_engine_action,

payment_engine_rule, and payment_request_action tables.
General ledger postings require setting up the general_ledger_action and

general_ledger_rule tables, as well as any other external data tables you wish to
supply. Similarly, reval postings require setting up the reval_action and reval_rule
tables.
Front office database tables to prune

This section of this chapter outlines the considerations one should make when
devising a data pruning strategy for front-office tables.
Curve-related tables
Curve tables will grow through time, and it is possible to eliminate unneeded
historical curve data without sacrificing any referential integrity or pricing
capabilities.
Administrators should determine a policy for curve data preservation. Of course, some
institutions’ data preservation policies may be more or less conservative than others’.
One such policy might be to eliminate (or archive) all curve data:
• not related to any curve instance being used to price a trade;

• not used to generate any risk reports;
• associated with derived interest rate curves (not simple or dependent
curves)
• not related to the last instance of a curve on any day; and
• not less than two months old.
The tables subject to pruning would be those large tables keyed by a particular
curve_id number and a curve_datetime time stamp. In a version 5.2.1 database, these
would be the tables curve_datetime, curve_data, curve_def_derived_sec, and
curve_int_algorithm. A related (and very large) table, sec_quote, could also be
attacked in a curve-data pruning script.
A basic pruning script strategy might be to first create a temporary table filled with
curve_id numbers and curve_datetime time stamps meeting the chosen criteria. Then,
scripts would delete or archive instances of curve_datetime, curve_data,
curve_def_derived_sec, and curve_int_algorithm which use the same curve_id
numbers and curve_datetime time stamps.
To check to see if a curve instance is being used to price a trade, check against the
trade_leg_val table.
To check to see if a curve instance has been used to generate a risk report, check the
table risk_rpt_curve.
To check to see if a curve is a derived interest rate curve, check the values of
curve_def_code and curve_type_code in the curve table. The columns will read
“DERIVED” and “INTEREST,” respectively, for a derived interest rate curve.
Once you have determined which curve_datetime time stamps are no longer needed in
the database, you could also use this information to prune the sec_quote table. Rows
are added to sec_quote each time a user saves a derived interest rate curve. If a curve
instance no longer exists, the sec_quote values for that time stamp are no longer
required. To make sure you are deleting only the quotes for securities used to build a
particular curve, check the curve_def_derived_sec table.
You should never delete sec_quote values with a SETTLE quote_type_code. These
quotes are not related to curves; they reflect closing prices of exchange-traded
securities.
When initially tackling a large, bloated database, it would be wise to prune the curve
tables by joining and deleting only a few months of time stamps at a time. Otherwise
one risks filling the server transaction log.
You will probably find that you are able to delete a significant percentage of your
curve_data (over 25%) by using the criteria suggested above. This number would
depend most directly on the curve- and risk report-saving behavior of your users.
version 5.2 Front office database tables to prune B-11

Trade and transaction-related tables
Maintenance of the trade and transaction tables requires two steps:
• changing the status of matured trades to MATURED

• deleting or archiving old MATURED trades
Administrators should develop scripts to periodically change the trade_status_code of

matured trades to MATURED. Maturing old trades will help the applications run
faster, because some of the more time-consuming table joins in the applications will
exclude trades with a MATURED status.
Additionally, trades of exchange-traded instruments should be changed to MATURED

immediately once those instruments have matured. Otherwise, these securities and
trades may incorrectly appear in traders’ trade blotters and position worksheets.
To change a trade’s status to MATURED, add a line to the trade_status table

indicating the trade_id number, the new status, and a time stamp. Also, change the
trade_status_code attribute of the trade table to MATURED.
To determine which trades of different securities have matured, refer to the table
below. The sec_type_code attribute is taken from the sec table. You can tell which
kinds of securities are involved in a trade by looking in the trade_leg table, which lists
a sec_id for each trade leg.
sec_type where to check
ASSET_OPTION maturity_date in asset_option_header
BOND maturity_date in bond_header
BOND_FUTURE maturity_date in exchange_header

(schedule this task regularly based on the contracts)
BOND_FUT_OPT maturity_date in exchange_header

(but check to make sure the option is not in-the-money)
BOND_OPTION maturity_date in otc_option_header
CAP maturity_date in cap_floor_header
CURRENCY does not apply
DISCOUNT maturity_date in money_market_header
EQTY_FUTURE maturity_date in exchange_header
EQUITY does not apply

sec_type where to check
EQUITY_DR does not apply
EXCH_OPTION maturity_date in exchange_header

FLOOR maturity_date in cap_floor_header
FRA_LEG maturity_date in swap_leg_header
FUTURE maturity_date in exchange_header

(schedule this task regularly based on the contracts)
FX_OPTION maturity_date in otc_option_header
IA_SWAP_LEG maturity_date in swap_leg_header
LOAN event_date in loan_event where loan_event_type_code

= ‘CLOSE’
MONEY_MARKET maturity_date in money_market_header
OPTION maturity_date in exchange_header
OTC_OPTION maturity_date in otc_option_header
REPO maturity_date in repo_header
SIMPLE_FLOW does not apply
SPREAD does not apply
SWAPTION maturity_date in otc_option_header

SWAP_LEG maturity_date in swap_leg_header
WI_SETTLE maturity-date in wi_settle_sec_header
For exchange-traded options (BOND_FUT_OPT and EXCH_OPTION) and some

over-the-counter options (SWAPTION), you must be careful not to indiscriminately
mature trades once their maturity date is reached. For options, those that are “in the
money” on their maturity date should be exercised, not matured. In the Infinity
applications, the exercise must be performed using the applications. This will
automatically create the resulting trade of the underlying security. You can tell which
exchange-traded options are in- or out-of-the-money by looking at strike_price in the
exchange_header table. It would be best to exercise swaptions by looking at them
individually, marked-to-market in the application.

If your application users are trading exchange-traded instruments, then on an
exchange’s maturity dates you should be aware of the need to change trades of
matured securities to a MATURED status. For the frequently-traded IMM futures and
futures options, these contracts settle on the third Wednesday in March, June,
September, and December.
Before maturing, deleting, or archiving a trade, you may want to check against the
flow table to make absolutely sure all the flows relating to this trade are in the past.
When deleting or archiving trades, you might be tempted to delete the security
definitions in the sec table as well. NEVER do this for exchange-traded instruments,
bonds, or currency securities. The only “safe” securities and _header tables to delete
would be matured swap legs, FRAs, caps, floors, and swaptions. For more on deleting
the securities themselves, see the section on security-related tables below.
You may also want create different archiving or deleting strategies for trades with a
PRICING, CANCELLED, NO_TRADE, or VANISHED status. Users may leave
forgotten PRICING trades sitting in the database long after they have been created.
You would probably want to remove all the PRICING trades where the
update_datetime attribute of the trade table indicates that no one has changed the
trade for a few months.
Of course, if you delete a trade, you would probably also want delete the
corresponding trans and trans_info rows.
Security-related tables
As more over-the-counter securities are traded, the sec and _header tables will fill up.
While trades of exchange-traded instruments trade one frequently-traded sec_id for
another (usually currency), OTC trades such as swaptions each create their own
securities specifically for use in that single trade. As trades are deleted or archived,
these one-time-use securities are no longer useful.
Therefore, the only “safe” securities and _header tables to delete would be matured
swap legs, FRAs, caps, floors, and swaptions.
When deleting or archiving the entries in the sec, cap_floor_header, and

swap_leg_header tables, you can also delete or archive entries in other tables which
key off an ill-fated sec_id number. The most important and largest of these tables
would be flow and flow_calc_reset.
Before maturing, deleting, or archiving a security, you may want to check against the
flow table to make absolutely sure all the flows relating to this trade are in the past.
Additionally, in an otc_option_header table representing a swaption, you will find an

underlying_sec_id and settlement_sec_id. These sec_id numbers represent the fixed
and floating sides of the underlying swap. If you are deleting or archiving a swaption,

you should delete or archive the underlying swap as well, along with those securities’
flows.
Do not delete securities which are being used as templates or which are being used to
generate curves. Before deleting a security, be sure to check the sec_template table to
make sure no one is using it as a template. Check in curve_def_derived_sec to make
sure it is not being used as a relative security for generating curves.
The deletion of security quotes is discussed in the section on curve-related tables

above. The superfluous quotes you would want to delete most likely would be quotes
for exchange-traded securities, relative securities, and bonds. Definitions of these
securities should always be preserved in the database.
Deleting relative securities is handled in the Static Data Manager application. It is

recommended that you use the integrity checks built into that application for
eliminating superfluous relative securities.
Volatility surface-related tables
The procedure for pruning unneeded volatility surface data would be similar to that
used for eliminating unneeded curve data.
One procedure might be to eliminate (or archive) all surface data:
• not being used to price a trade;

• not used to generate any risk reports;
• not related to the last instance of a surface on any day; and
• not less than two months old.
As with curves, you can tell if a volatility surface is being used for trade pricing by
looking in trade_leg_val.
Also as with curves, surface timestamps which have been used to generate risk reports
are recorded in the risk_rpt_curve table In the risk_rpt_curve table, the curve_id
column may refer to a curve or surface, and the curve_usage_code specifies whether
the referenced id number was a curve or a surface.
The timestamps for a surface are stored in vs_datetime, and the points for a particular
timestamp are stored in vs_data.
Once you have selected unused surfaces and timestamps, you would want to delete or
archive data keyed by a particular vs_id and vs_datetime. These tables would be
vs_datetime, vs_data, vs_def_exp_relative, vs_def_exp_specific, vs_def_strike,
vs_def_tenor, and vs_tenor_spread.

Risk report tables
Risk report tables can occupy large amounts of space if their growth is left unfettered.
Most likely an institution would want to archive old reports rather than simply delete
them.
Large risk report tables do not significantly slow down the Infinity applications,
because the applications only write to these tables and do not read from them. If you
are using your own query tools to read from these tables after they have been created,
then risk table size will be a more important issue for you.
Every time a risk report is saved to the database, a row is added to the risk_rpt table.
This is the table an administrator would use to determine the age of a report, using the
risk_rpt_id key and datetime attribute.
Completely archiving all the data about a particular risk report would require
archiving the rows in all tables using that particular risk_rpt_id as a key. While over
forty tables key off a risk_rpt_id number, only a handful would be appropriate for any
particular report.
For example, if you wanted to archive all the data associated with a mark-to-market
report, you would archive:
• risk_rpt_mtm, for the mark-to-market information itself. There would

be one row for every trade leg in the portfolio.
• risk_rpt, for the information about who ran which report when and on
what portfolio
• risk_rpt_curve, all rows in which that risk_rpt_id appears, for
information about which curves were used to price which securities in
the portfolio
• risk_rpt_param, for information about the parameters used to run the
report
• risk_rpt_param_cpty, for the list of base counterparties used for the
analysis
Other reports might require the archiving of a different risk_rpt_ table, as well as:
• risk_rpt_param_base_curve [for ladders reports only]

• risk_rpt_param_book [to specify hedging books for partial
differential hedge reports only]
In general, it is safest to make sure you archive enough of data to recreate the analysis
completely, assuming you still have the market data and trade data needed to price the
trades. Note that in the pruning recommendations made above for curve data, it was
recommended that you preserve curve data timestamps which had been used to
generate risk reports.

Back office tables to prune
expected_xfer
The expected_xfer table keeps track of every expected transfer sent through the
system. For trades that have matured, vanished, or been cancelled, you can safely
remove all expected transfers related to that trade_id.
general_ledger_post
This table lists all postings made by an expected transfer. For expected transfers
purged from the expected_xfer table, you can safely remove the general_ledger_post
entries related to that expected_xfer_id.
Sample scripts
Deleting non-end-of-day security quotes
The following script deletes all non-last-quote-in-day quotes from the sec_quote
table. Be sure to back up your sec_quote table before running this (as a backup
measure).
This script has been tested for effectiveness but not for performance. It may create a
rather large transaction log. It has not been tested on very large databases. An
administrator may want to cut the data table into smaller views representing smaller
time slices.
Market Environment Manager can still call up mid-day curves from the database after
this script has been run. If users ask for new security quotes on that day, Market
Environment Manager will load end-of-day security quotes from the previous day.
Risk Manager always calls up the last quotes for a given day when doing historical
analysis. Thus this script should have no effect on Risk Manager or Scenario Builder.
If a user calls up a trade in Trader, the curve saved along with the trade would still be
loaded as long as the curve_data table still exists. However, a user would be unable to
hedge the trade from within the Trader worksheet.
Note that this data pruning strategy is much more reckless than the strategies outlined
earlier in this chapter. This less conservative strategy is designed to preserve only the
ability to reprice trades as the curves existed at the end of a trading day. The script is
version 5.2 Back office tables to prune B-17

included here not as a pruning recommendation, but to instruct administrators how
one might select non-end-of-day quotes.
The quote_type_code attribute in the sec_quote table does not necessarily reflect the
time of day at which a quote was saved. You may have, for instance, a 16:00:00
“CLOSE” instance and then a 16:01:30 “OPEN” instance of the same security quotes.
The Market Environment Manager, Trader, and Risk Manager applications select the
last curve timestamp on a given day regardless of the quote_type_code values of the
security quotes.
Nevertheless, you would probably always want to preserve “SETTLE” quotes

regardless of their time stamp. This restriction is not coded into the script below.
Administrators should first test this script by changing all the “DELETE” statements
to “SELECT” statements and making sure the unneeded quotes are the only ones
being erased.
This script is broken into two parts—the first part deletes instances where
sec_quote.settlement_sec_id values are NULL, and the second part deletes where
they are not NULL. The script is broken up this way to provide more control and to
more precisely cover different possible cases. This value is NULL for quotes which
are simply prices (such as a price for a future) and the value is non-NULL where one
security is quoted in terms of another (such as an FX quote).
This script was initially written for Sybase version 4.x, which does not allow the use
of cursors. This script would be more efficient in Sybase System 10 or 11 if it were
rewritten to use cursors.
/* PART ONE -- deleting sec_quote rows with no

settlement_sec_id */
print ’Number of total rows in sec_quote:’

select count(*) from sec_quote
print ’’
print ’Deleting the quotes for single securities...’

go
DELETE sec_quote
WHERE convert(varchar(10),sec_id)+
convert(varchar(10),settlement_sec_id) +
convert(varchar(25), quote_datetime)
/*concatenating all the primary key values into a string

for comparison purposes */
IN
(SELECT convert(varchar(10),sec_id)+

FROM sec_quote sq1

/* the outer select maintains one "version" of sec_quote
called sq1 */
WHERE quote_datetime <
(SELECT max(quote_datetime)
FROM sec_quote sq2
/* the inner select has its own version of sec_quote
called sq2 */
WHERE
sq1.sec_id = sq2.sec_id
AND
sq1.settlement_sec_id = NULL
AND
sq2.settlement_sec_id = NULL
AND
convert(varchar(15),sq1.quote_datetime, 101) =
convert(varchar(15), sq2.quote_datetime, 101)
)
)
AND quote_datetime < ’9/1/94’

/* default is to delete quotes before September 1, 1994 */
go
print ’’
print ’New number of rows in sec_quote:’
print ’’
go
/* PART TWO -- deleting rows with settlement_sec_id val-

ues */
print ’Deleting the quotes with settlement securities...’

go
DELETE sec_quote
WHERE convert(varchar(10),sec_id)+
/*concatenating all the primary key values into

a string for comparison purposes */
version 5.2 Sample scripts B-19

IN
(SELECT convert(varchar(10),sec_id)+
FROM sec_quote sq1

/* the outer select maintains one "version" of
sec_quote called sq1 */
WHERE quote_datetime <
(SELECT max(quote_datetime)
FROM sec_quote sq2
/* the inner select has its own version of
sec_quote called sq2 */
WHERE
sq1.sec_id = sq2.sec_id
AND
sq1.settlement_sec_id != NULL
AND
sq2.settlement_sec_id != NULL
AND
sq1.settlement_sec_id = sq2.settlement_sec_id
AND
convert(varchar(15),sq1.quote_datetime, 101) =
convert(varchar(15), sq2.quote_datetime, 101)
)
)
AND quote_datetime < ’9/1/94’

/* default is to delete quotes before September 1, 1994 */
go
print ’New number of rows in sec_quote:’

print ’’
go

Appendix C
Suggested Reading
Other Infinity Books

This manual should be used in conjunction with the following Infinity Data Model
documentation.
The Infinity Data Model Reference Guide, versions 5.2 and 5.2.1, includes diagrams
of the various areas of the Infinity Data Model, lists all static data shipped in the Data
Model, and lists the contents of foundation and holiday tables.
The Infinity Data Model Quick Reference, versions 5.2 and 5.2.1, contains an
alphabetical listing of every table and attribute in the database. Also available is the
Data Model Quick Reference and List of Modifications. For each release, this
document points out the changes in the Data Model from the previous version. The
Quick Reference is shipped on the Infinity release CD in Adobe Acrobat and
FrameMaker formats.
The Infinity Data Model Quick Reference—On-Line Version, is an ASCII text version
of the Quick Reference described above. This document is shipped on your Infinity
release CD. The file is called
/online-docs/acrobat/data_model/quickref/quickref.txt
Books on Relational Data Modelling

Bruce, Thomas A. Designing Quality Databases with IDEF1X Information Models. Dorset
House Publishing, 353 West 12th Street, New York, NY 10014. This book presents a
thorough discussion of relational data modeling concepts, techniques and
representation systems.
Date, C.J. Relational Database: Selected Writings. Addison-Wesley, Reading, Massachusetts,

1986. This is a plain-language collection of articles about relational modeling theory
and practice. Recommended: Chapter 19, “A Practical Approach to Database
Design.”
Elmasri, Ramez and Navathe, Shamkant. Fundamentals of Database Systems. Benjamin/

Cummings, 390 Bridge Parkway, Redwood City, CA 94065. This is an exhaustive
source of information about relational modeling and database systems.
Nath, Aloke. The Guide to SQL Server. Addison-Wesley, Reading, Massachusetts, 1990. This
volume discusses the implementation of a relational database using the Sybase SQL
Server RDMS and isql.
version 5.2 Other Infinity Books C-1

Appendix D
Glossary of Relational Modeling Terms
All examples, unless specified, are taken from the Montage Data Model.
ALTERNATE KEY A candidate key that has not been chosen as the primary key.
ASSOCIATIVE ENTITY An entity that inherits its primary key from two or more other entities.
For example, prsn_org_relation is an associative entity; it more
effectively models a many-to-many relationship between prsn and
org.
ATTRIBUTE A property of an entity; a column of a table. For example, last_name

is an attribute of the prsn entity.
BASE ATTRIBUTE An attribute for which a role name is assigned. See also role name.
BUSINESS RULE A policy or characteristic of real-world business that must be taken

into consideration when modeling data.
CANDIDATE KEY An attribute or group or attributes that might be chosen as a primary

key.
CARDINALITY A statement of the number of entity instances that participate at each

end of a relationship. A relationship can have a one-to-zero-or-one
cardinality, a one-to-many cardinality (the most frequent), or a one-
to-n cardinality.
CASCADE A procedure for ensuring that the deletion of an entity instance causes
the simultaneous deletion of all other entity instances dependent on it
for existence.
CHILD ENTITY The entity to which a relationship contributes a foreign key; found on
the ‘many’ end of the one-to-many relationship.
CODE A standard abbreviation in the Montage database. For example, USD

is the currency_code meaning U.S. Dollar. The codes usually
originate in domain and list tables.
COMPOSITE KEY A primary key that contains two or more attributes, possibly foreign
keys.
DATATYPE Specifies what kind of information each column will hold and how
the data will be stored. An attribute can be represented using an
version 5.2 D-1

integer datatype, a string datatype, a boolean datatype, etc.
DENORMALIZATION The intentional transformation of a model to a lower level normal

form; normally done to tune a database toward a particular type of
physical access or to enhance performance.
DEPENDENT ENTITY An entity that depends on one or more other entities for its
identification. Its primary key contains foreign keys.
DERIVED ATTRIBUTE An attribute which can be determined from the values of other
attributes.
DESCENDENT An entity that is identification-dependent on one or more other

entities; a dependent entity is said to be a descendent of each entity
that provides foreign keys.
DOMAIN A set of values that an attribute may take. In the Montage database,
these sets of values are stored in _domain tables.
ENTITY A distinguishable person, place, thing, event, or concept about which

information is kept. For example, sec, flow, curve, and prsn are all
entities.
FIELD A single item of information contained in a record. The logical

equivalent of a column.
FIRST NORMAL FORM A standard for relational database design in which repeating fields or
repeating groups of fields are removed.
FOREIGN KEY A primary key of a (parent) entity that is contributed to another

(child) entity across a relationship. For example, prsn_id, a primary
key of the prsn entity, is a foreign key in the prsn_org_relation entity.
A foreign key value is required to match a primary key in some other
table.
INDENTIFIER The name of a database object (table, view, index, procedure, trigger,
column, default, or rule). An identifier can be from 1 to 30 characters
long. The first character must be a letter or either the # or _ symbols.
IDENTIFYING
RELATIONSHIP A relationship in which all primary key attributes of the parent entity
become part of the primary key of the child entity.
INDEPENDENT
ENTITY An entity that does not depend on any other entity for identification.
For example, the seed tables are all independent entities.
INDEX Indexes are created on columns to speed data retrieval. Clustered
D-2 Glossary of Relational Modeling Terms Infinity Data Model Developer’s Guide
indexes sort primary key attributes in order. Non-clustered indexes
create an extra level of pointers to data.
INSTANCE A single occurrence of an entity; a row or record in a table. For

example, data about one employee in the prsn table would comprise
one instance of the prsn entity.
KEY A field used to identify a record, also often used as the index field for
an index. In entity-relationship diagrams, key attributes are those
shown above the key line. See also non-key.
LIST In the Montage database, a table (ending in _list) storing code values
to describe any particular entity.
MANY Used in describing cardinality to indicate zero or more.
NONIDENTIFYING
RELATIONSHIP A relationship in which the child entity gets data from the parent
entity, but the primary key of the parent entity only becomes a non-
key attribute of the child entity.
NON-KEY An attribute which is not a primary key, usually used to simply

describe a given instance of an entity. Entity diagrams are divided by
a line into key and non-key areas. Foreign key attributes can appear in
the nonkey area if the entity is not dependent on that attribute for
identification. For example, montage_group_code is a foreign key in
every _list table, but that attribute is shown in the nonkey areas
because it does not assist in the identification of the _list tables.
NORMALIZATION A process of removing inaccurate, inconsistent, and/or overly

complex assertions from an information model.
NULL Having no explicitly assigned value. NULL is not equivalent to zero

or blank. A value of NULL is not considered to be greater than, less
than, or equivalent to any other value, including another value of
NULL. In the Quick Reference, ‘0’ in the NULL column indicates
that an attribute cannot be NULL, and ‘1’ indicates that it is allowed
to be NULL.
PARENT ENTITY The entity from which a foreign key migrates; found on the ‘one’ end
of a ‘one-to-many’ relationship.
PRIMARY KEY An attribute or group of attributes that has been chosen as the unique
identifier of an entity.
RECORD A group of related fields (columns) of information treated as a unit;

the logical equivalent of a row. Also can be called an instance.
version 5.2 D-3

RECURSIVE
RELATIONSHIP A nonidentifying relationship in which the same entity is both the
parent and the child.
REFERENTIAL
INTEGRITY The rules governing data consistency, specifically the relationships
among the foreign keys of tables. Foreign key data must always be
matched to maintain referential integrity.
RESTRICT A process to ensure that deletion of an entity instance will not occur
unless there are no other instances dependent on it for existence.
ROLE NAME A new name for a foreign key attribute that defines the role it plays in
the child entity. For example, related_org_id is a role name in the
org_org_relation entity. Its domain must be a subset (which can
include the entire set) of the domain of the foreign key.
ROW A set of related columns that describes a specific entity; also called a
record or instance.
SECOND NORMAL
FORM A standard for relational database design that involves tables that
have composite primary keys (i.e., primary keys that consist of two or
more concatenated secondary or foreign keys). This standard requires
that all columns in such a file be dependent upon the entire primary
key expression rather than upon any part thereof.
SEED TABLE In the Montage database, a single-instance table containing only one
column: an identification number. Seed tables are necessary to
guarantee unique id numbers for such entities as org, curve, and sec.
STRUCTURED QUERY
LANGUAGE (SQL) A data definition and manipulation language developed for use in
relational database management systems.
TABLE A collection of rows (records) that have associated columns (fields).
THIRD NORMAL FORM A standard for relational database design that requires the elimination
of any nonkey field dependent upon any other fields except the
primary key.
TRIGGER A special form of a stored procedure that goes into effect when a user
gives a change statement such as INSERT, DELETE, or UPDATE to a
specified table or column. Triggers are used to enforce referential
integrity.
USER-DEFINED
DATATYPE A definition of the type of data a column can contain, created by the
user and defined in terms of the existing system datatypes.
D-4 Glossary of Relational Modeling Terms Infinity Data Model Developer’s Guide
Index avg_calc_method_domain 5-4
B
base tenor 12-3
base_rate 8-29
basis curves 11-7
A benchmark_sec_id 8-46
Access (Microsoft) 14-1 bid_value 8-11
access_func_group_list 5-11 binary_payoff_amount 9-6
Account Manager District B-9 Bluestone dbViewer 14-1
account_type_domain 5-4 bond on special 11-10
accrual_date_roll_code 8-18 bond options 8-45
accrual_day_count_code 8-18 bond/spread set 8-46
accrued_interest 8-49 bond_attribute 8-4, 8-31
act_notl_code 8-18 bond_future_attribute 8-4
act_notl_domain 5-4 bond_header 8-31
active_bucket_id 5-18 bond_spread_benchmark 8-45
adding applications users B-4 bond_type_code 11-10
adding trading books B-9 bond_type_domain 5-4
addr_type_list 5-11 bonds 8-31
admin_type_domain 5-4 book-based user authorization B-4
advice_status_domain 5-4 books B-9
advice_type_list 5-11 bucket_length 5-19
amort_calc_date_roll_code 8-30 bucket_start 5-18, 5-19
amort_calc_lag_day_type_code 8-30 business_event_list 5-11
amort_calc_lag_term 8-30 business_type_domain 5-4
amort_calc_timing_code 8-30
amort_curve_spread_rate 8-29
amort_from_original_b 8-29 C
amort_frq_code 8-19 calc_weight_rate 9-6
amort_index_spread_rate 8-29 cap_floor_code 8-35
amort_pay_amount 8-19 cap_floor_domain 5-4
amort_start_date 8-19 cap_floor_header 8-34
analysis_date_type_domain 5-4 maintaining B-14
applications users: adding B-4 cardinality 2-5
archiving data B-1 cash securities 8-4
_attribute tables 8-4 child organization 4-7
attributes 2-2 child tables 2-5
audit database city_list 5-11
performance 5-21 Classification field in CiMan B-9
auth_b 4-9 clean_up_call 8-29
auth_id 4-9 closing prices: saving B-11
auth_seed B-3 _code 5-1
auth_status 4-9 collateral bond 8-47
maintaining B-3 collateral_amount 8-49
auth_status_domain 5-4 collateral_id 8-49
auth_type_domain 5-4 collateral_price 8-49
authorization B-4 columns
changing order 5-24
compound_calc_timing_code 8-20 curve_hol_city 11-2, 11-20
compound_spread_rate 8-20 curve_id 11-3
compound_type_code 8-20 curve_instance_code 11-13
compound_type_domain 5-4 curve_instance_domain 5-5
compounding 8-20 curve_int_algorithm B-11
concurrency 5-23 curve_int_algorithm_domain 5-5
contact_type_list 5-11 curve_interest_header 11-5
contract_series_list 5-11 curve_interpretation_code 11-3
contract_series_sec_type 8-37 curve_interpretation_list 5-12
contract_size_amount 8-38 curve_level_type_code 11-3
country_list 5-11 curve_level_type_domain 5-5
CP rate 10-1 curve_offset_term 11-15
cpty 4-9 curve_repo_group 11-12
cpty_role 4-9 curve_repo_group_special 11-11
cpty_role_list 5-11 curve_repo_header 11-10
cpty_type_list 5-11 curve_seed 5-23, 11-3
cum_dividend_b 8-47 curve_side_domain 5-5
currency curve_status_code 11-3
modeled as security 7-3, 8-4 curve_status_domain (not used) 5-5
currency_code 8-4, 8-7, 11-4 curve_status_list 5-12
currency_list 5-12 curve_type_code 11-4
currency-based user authorization B-4 curve_type_domain 5-5
curve 11-1, B-11 curve_usage_domain 5-5
and trade legs 7-11 curve_volatility_header 11-5, 11-9
basis 11-7 curve-related tables: maintaining B-10
curve table 11-3 Custom Interval Algorithm 5-22
dependent 11-15 Custom SQL field 13-6
holidays 11-20 Customer Information Manager B-6, B-9
interest 11-5
simple 11-15
used in risk reports B-11 D
volatility 11-9 data independence 2-1
volatility, modeling underlying curves 11-15 data model
curve_archive_domain 5-4 index definitions A-1
curve_basis_header 11-5, 11-7 key definitions A-1
curve_curve_operator_code 11-17 or just look like one
curve_curve_operator_domain 5-4 data model extension 5-24
curve_data 11-1, 11-13 data_group_list 5-12
maintaining B-11 database management systems 2-1
curve_data_code 11-4 datatypes 3-3
curve_data_domain 5-5 dropping or modifying 5-24
curve_datetime 11-1, 11-13, B-11 date_roll_domain 5-5, 8-30
curve_def_code 11-4 datetime_curve_status_code 11-13
curve_def_dependent 11-1, 11-15, 11-17 day_count_code 8-18
curve_def_derived_curve 11-1, 11-15, 11-20 day_count_domain 5-5
curve_def_derived_sec 11-1, 11-15, 11-18, B-11, DBMS 2-1
B-15 dbViewer 14-1
curve_def_domain 5-5 deadlocking fix 5-17
curve_def_simple 11-1, 11-15 debugFlags B-2
curve_fx_header 11-5 denormalization 2-10
description 8-7, 11-4 F
doc_index_list 5-12
filler column in sec_hol_city A-3
doc_tmpl_group_list 5-12
Fin++ class library 1-2
doc_type_list 5-12
final_exchange_amount 8-18
domain codes
first_ex_delivery_date 8-39
data integrity 5-10
first_exercise_date 8-44
domain_name 5-2
fixed_rate 8-18
floor 8-35
E flow 8-49
Easter, see holidays basic relationships 7-2
emp_prsn table 4-2, 4-6 general identification fields 9-3
emp_type_list 5-12 index-related flow fields 9-4
employee maintaining B-14
relationship with organization 4-1 option-related flow fields 9-5
entered_datetime 8-6 flow_amount 9-3
entered_user_code 8-7 flow_calc_code 8-21, 9-4
entity 2-2 flow_calc_date 9-4
associative 2-7, 4-5 flow_calc_date_roll_code 8-21
dependent 2-5 flow_calc_domain 5-6
independent 2-5 flow_calc_frq_code 8-21
names 2-3, 2-8, 3-6 flow_calc_lag_day_type_code 8-21, 8-22
Error Log flow_calc_lag_term 8-21
Scenario Builder 14-3 flow_calc_rate 9-4
error_list 5-12 flow_calc_reset 9-6
error_severity_list 5-12 maintaining B-14
event_date 8-49 flow_calc_start_date 8-21
event_rc_config B-10 flow_calc_timing_code 8-21
event_server_home_config B-10 flow_calc_timing_domain 5-6, 8-30
exchange traded instruments: saving closing prices flow_date 9-3
B-11 flow_discount_rate 9-4
exchange_attribute 8-4, 8-38 flow_id 8-49, 9-3
exchange_blotter_accel flow_rate_calc_code 8-21, 9-4
maintaining B-5 flow_rate_calc_domain 5-6
exchange_header 8-37, B-13 flow_term 9-3
exchange_list 5-12 flow_timing_code 8-19
exchange-traded instruments 8-37 flow_timing_domain 5-6
maturing B-14 flow_type_code 9-3
exercise_code 9-5 flow_type_domain 5-6
exercise_domain 5-5 foreign exchange 8-4
exercising trades B-13 foreign exchange settlement term B-7
expectation_domain 5-5 foreign key 2-5, 2-6
expected_xfer_state_domain 5-5 from_clause 13-3
expected_xfer_status_domain 5-5 frq_domain 5-6
expected_xfer_timing_domain 5-5 FX quote precision B-7
expected_xfer_type_domain 5-6 fx rates 8-4
extending the data model 5-24 FX settlement term B-7
FX Trader application B-7
fx_quote_style 8-5
fx_swap_type_domain 5-6
G infsys_seed_bases 5-15, 5-18
infsys_seed_partitions 5-15, 5-18
greek_calc_method_domain 5-6
infsys_version_history B-1
initial_bucket_id 5-18
H initial_exchange_amount 8-18
instance 2-2
haircut 8-47
interest_curve_spread_rate 8-29
_header tables 8-3, B-12, B-14
interest_index_spread_rate 8-29
maintaining B-14
Internal SIC code B-9
hol_data 6-3
interp_code 11-4
hol_header 6-1, 6-5, 15-1, 15-2
interp_domain 5-6
hol_type_code 6-7, 8-9
interval in infsys_seed_partition 5-18
hol_type_domain 5-6, 6-7
in-the-money B-13
holiday
isexercisable 8-44
absolute, Easter, and specific 6-5
isql 14-1
holiday tables 6-1
issuer_inst_code 11-10
adding values B-3
issuer_inst_list 5-12
defining new holiday rules 6-4
using SQL to query 6-3
holiday, removing 6-6 J
holidays 8-8
job_func_list 5-12
I K
id numbers
keys 2-4
obtaining in 5.2 5-23
normalization rules 2-10
obtaining in 5.2.1 5-17
identification numbers 5-15
identification_str 7-6 L
IMM futures and futures options B-14 lag_day_type_domain 5-6
index amortizing swap 8-29 lang_domain 5-6
indexes 3-8 last_ex_delivery_date 8-39
clustered 3-8 legal entity 4-7
composite 3-8 legal_agmt_clause_list 5-12
non-clustered 3-8 legal_agmt_list 5-12
unique 3-8 legal_entity 4-7
inf_add_pbe stored procedure B-7 LIBOR reference index 10-1
inf_add_trading_book stored procedure B-9 list codes
infLogin.scenario 14-3 and data integrity 5-14
info_data_type_domain 5-6 modifying 5-14
info_db_table_domain 5-6 list tables 5-11
info_type_list 5-12 adding values B-2
info_value_num B-9 live feed address 5-14
info_value_str B-9 loan_event 8-48
infsp_getseed 5-17, 5-20 loan_event_flow_relation 8-49
infsys_action_list 5-12 loan_event_id 8-49
infsys_dist_seed_bases 5-15 loan_event_type_code 8-49
infsys_montage_domains 5-2 loan_event_type_domain 5-6, 8-49
infsys_montage_lists 5-2 lockout_period 8-29
infsys_seed_base_buckets 5-15, 5-19
M org table 4-6
org_addr_relation_list 5-13
manual_reset_b 8-23
org_book_relation B-9
in flow table 9-4
org_book_relation_list 5-13
many-to-many relationship 4-4
organization
matured trades B-12
participation in trade leg 7-8
maturity_date 8-18, B-12
relationship with employee 4-1
maturity_term 8-13, 9-4
organization relationships 4-7
Microsoft Access 14-1
otc_option_header 8-44
Middleman 5-14
maintaining B-14
modified_b
otc_option_sec_usage_list 5-13
in porfolio table 13-3
otc_option_underlying_domain 5-7
money market instruments 8-42
out-of-the-money B-13
money_market_attribute 8-4, 8-42
over-the-counter securities B-14
money_market_header 8-42
money_market_type_domain 5-7
Montage P
abstract table diagram 3-3 parent organization 4-7
functional areas 3-1 parent tables 2-5
system schematic 1-2 partic_side_domain 5-7
month_cycle_domain 5-7 partic_type_domain 5-7, 7-9
partition_id 5-18
N password_use_domain 5-7
payment dates
naming conventions 3-6
holidays 6-7
tables and columns 3-4
payment_date_roll_code 8-20
ND_PATH 14-2
payment_direction_domain 5-7
non_legal_entity 4-7
payment_engine_oper_domain 5-7
non-keys 2-4
payment_engine_state_domain 5-7
non-legal entity 4-7
payment_frq_code 8-19
normal form 2-10
payment_lag_day_type_code 8-20
normalization 2-9
payment_lag_term 8-20
NULL 2-6
payment_notif_domain 5-7
‘0’ and ‘1’ in Quick Reference 4-6
payment_start_date 8-19
number_of_seed_buckets 5-18, 5-19
payment_status_domain 5-7
payment_type_list 5-13
O PBE B-6
pbe_org_id 4-8
object_org_id 4-8
performance gains 5-20
offer_value 8-11
performance of the database B-1
official_b 9-4
period_maturity_date 9-4
offset days 6-2
period_start_date 9-4
one-to-many 2-5
pnl_decomp_item_domain 5-7
Optimal Interval Algorithm 5-22
pnl_decomp_sequence_domain 5-7
option_maturity_date 9-5
pnl_trade_leg_status_domain 5-7
option_maturity_term 9-5
populate.csh shell script 5-20
option_type_domain 5-7
portfolio 13-1
Oracle 14-1
basic relationships 7-2
org
contrasted with transaction 13-1
designating a primary business entity B-7
dynamic and static definitions 13-1
generating risk reports for more than one 14-9 R
Portfolio Definition window 13-6
Rate Calc Manager 10-4
portfolio table 13-3
rating_source_list 5-13
portfolio_criterion_choice 13-4
rating_type_list 5-13
portfolio_criterion_domain 5-8, 13-4
RDBMS 2-1
portfolio_def 13-4
rebate_amount 8-44
portfolio_name 13-4, 14-8
ref_index_address 5-14
portfolio_status_code 13-3
ref_index_attribute 10-1, 10-3
post_operation_domain 5-8
ref_index_code 8-23, 8-47
post_state_domain 5-8
ref_index_currency_code 8-23, 8-47
post_type_domain 5-8
ref_index_factor 8-24, 9-5
prefix naming conventions 3-6
ref_index_hol_city 10-1, 10-4
pre-loaded data 5-1
ref_index_index_relation 10-1, 10-6
PRICING trade status B-14
ref_index_list 5-13, 10-1, 10-2
primary key 2-4
ref_index_quote 5-14, 10-1, 10-5
primary_business_entity 4-8
ref_index_relation_def 10-1, 10-6
maintaining B-6
ref_index_relation_domain 5-8, 10-1, 10-6
principal
ref_index_source_code 8-24, 8-47
actual 8-18
ref_index_source_list 5-13, 10-1, 10-2
notional 8-18
ref_index_spread_rate 8-24, 9-5
principal_amount 8-18, 8-49, 9-4
ref_index_term 8-23, 8-47, 9-4
printer_list 5-13
ref_index_term_source 10-1, 10-4
process_org 4-8
reference index 10-1
process_org_coverage 4-8
adding 10-2
processing org 4-8
maintaining B-2
product_type_list 5-13
reference index relationships 10-6
proj_flow_date_domain 5-8
reference_str 7-6, 8-7
prsn table 4-2
referential integrity 2-1
prsn_org_relation 4-5, 4-6
related_curve_1 and related_curve_2 11-17
prsn_org_relation_list 5-13
relational data model 2-1–2-10
pruning B-1
relationships 2-3
put_call_code 9-5
identifying 2-5
put_call_domain 5-8
recursive 2-9
relative securities 8-13
Q deleting B-15
querying tools 14-1 removing old data B-1
Quick Reference repo_date_roll_code 8-47
column meanings 4-6 repo_day_count_code 8-47
quote precision for FX rates B-7 repo_group_id 11-11, 11-12
quote tables 5-14 repo_group_name 11-12
quote_datetime 8-10 repo_header 8-47
quote_history_code 10-4 repo_rate 8-49
quote_history_domain 5-8 repo_roll_method_code 8-47
quote_method_code 8-11 repo_roll_method_domain 5-8
quote_method_domain 5-8 repo_term 8-47
quote_price 7-6 repo_type_code 8-47
quote_type_code 8-10, B-11 repo_type_domain 5-8
quote_type_list 5-13 reports: from Risk Manager 14-5
reset dates
holidays 6-7 in flow table 9-3
reset group 9-6 sec_ident_list 5-13
reset_calc_align_code 8-22 sec_name 8-7
reset_calc_align_domain 5-8 sec_product
reset_cutoff_term 8-23 maintaining B-14
reset_day_of_month 8-22 sec_product_domain 5-9
reset_frq_code 8-22 sec_quote 5-14, 8-2, 8-10
reset_group_id 9-5 maintaining B-11, B-17
reset_period_term 8-22 used in fx trades 8-4
reset_weekday_code 8-23 sec_quote_address 5-15
Risk Manager 14-1 sec_recalc_lock 8-12
Risk Manager application sec_relative 8-2, 8-13
saving portfolios 13-5 maintaining B-3
risk report sec_settle_sec_city_spot B-7
for multiple base counterparties 14-10 sec_settle_sec_tick_size B-7
retrieval 14-1–14-11 sec_template
risk report tables maintaining B-3, B-15
maintaining B-16 sec_type_code 8-7
risk_analysis_domain 5-8 sec_type_domain 5-9
risk_batch_def 14-8 sec_val_domain 5-9
risk_batch_name 14-2 security tables 8-1
risk_batch_run_id 14-3, 14-5 deleting records B-14
risk_rpt seed bucket generation algorithms 5-21
maintaining B-16 seed buckets 5-17
risk_rpt_ tables 14-1–14-11 seed numbers
risk_rpt_curve_ 14-8, B-11 retrieving 5-24
risk_rpt_domain 5-8 seed tables
risk_rpt_instance_domain 5-8 in v5.2 5-22
risk_rpt_instruct_domain 5-9 in v5.2.1 and later 5-15
risk_rpt_param 14-8 seed values
role name 2-8, 7-6 obtaining in 5.2 5-23
row 2-2 obtaining in 5.2.1 5-17
rtd_mdds_list 5-13 select_clause 13-3
sequence_number 9-3
Sequential Interval Algorithm 5-22
S SETTLE quote_type_code B-11
sat_roll_offset_day 6-2 settlement days required for FX trades B-7
Scenario Builder 14-1 settlement_date 7-6
sec 8-2, 8-6 settlement_method_code 8-38, 8-44
deleting records B-14 settlement_method_domain 5-9
maintaining B-14 settlement_sec_id 8-10
modeling a vanilla swap 8-8 settlement_term 8-11, 8-13
sec_curve_default SIC code B-9
maintaining B-14 simple volatility surface 12-1
sec_def_code 8-6 size of database B-1
sec_def_domain 5-9 source field 8-7
sec_fees 8-2 sp_helptext B-7
sec_hol_city 8-2, 8-8, A-2 speed buttons B-5
sec_id 8-6, 8-17, 8-46, 8-49, 11-10 speed of database B-1
example of primary key 2-4 spread 8-5
spread_set_name 8-46 trade 7-1
spread_type_code 8-46 basic relationships 7-2
spread_type_domain 5-9 diagram with trans and trade_leg 7-2
SQL trans_id 7-6
Transact-SQL 5-23 update_datetime 7-6
SQL debugging flag B-2 trade leg
SQL portfolio definitions 13-1 basic relationships 7-2
start_date 8-18 primary and settlement legs 7-7
start_term 8-13, 9-5 trade table 7-5
static data 5-17 maintaining B-12
Static Data Manager application B-2, B-15 trade_amount 7-7, B-8
status_list 5-13 trade_attention_list 5-13
stlmt_bank_domain 5-9 trade_date 7-6
strike_price 8-35, 9-6, B-13 trade_info_domain 5-9
structure_code 8-17 trade_keyword_list 5-13
structure_domain 5-9 trade_leg 7-1
structured query language 13-1 diagram with trans and trade 7-2
subject_org_id 4-8, 7-6 trade_leg table 7-7
suffixes 3-7 trade_leg_org_partic 7-9
sun_roll_offset_day 6-3 trade_leg_type_code 7-7
Surrogate Primary Key Generation 5-17 trade_leg_type_domain 5-9
swap trade_leg_val 7-11, B-11, B-15
annuity structure 8-17 trade_partic_type_domain 5-9
bullet payment structure 8-17 trade_sec_relation_domain 5-9
custom structure 8-17 trade_status_code 7-6, B-12
equal principal payment structure 8-17 trade_status_list 5-13
full coupon payment structure 8-17 trade_trade_relation_domain 5-10
vanilla swap modeled in sec table 8-8 trade_type_code 7-6
zero coupon structure 8-17 trade_type_list 5-14
swap_leg_code 8-17 Trader Manager application B-4
swap_leg_domain 5-9 trader_accel
swap_leg_header 8-14 maintaining B-5
maintaining B-14 trader_book_authorization
swap_leg_index_amort_header 8-29 maintaining B-4
swaption trader_prsn_id 7-6
exercising B-13 trade-related tables: maintaining B-12
Sybase 14-1 trading_book B-9
system administration trans
customizing or extending the data model 5-24 diagram with trade and trade_leg 7-2
trans table 7-4
maintaining B-12
T trans_id 7-4
tables 2-2 trans_info_domain 5-10
dropping 5-24 trans_seed 7-4
tenor spread surface 12-1 transaction 7-1
term_domain 5-3, 5-9 basic relationships 7-2
them side of trade 4-8 contrasted with portfolio 7-3
TIBOR reference index 10-1 transaction control 5-23
tick_size_code B-8 transaction locking 5-23
tick_size_domain 5-9 transaction log B-11
transaction-related tables: maintaining B-12
Transact-SQL 5-23, 14-1
TransDup 5-17, 5-20
transmission_list 5-14
U
underlying_flow_id 9-5
unit_time_domain 5-10
update_datetime 8-7, 8-11, 8-46
us side of trade 4-8
user authorization B-4
user_acct_status_domain 5-10
user_code 11-4, 11-12
user_default B-2
user_group_list 5-14
users: adding for applications B-4
V
val_delta_calc_domain 5-10
verified_user_code 8-7
volatility surface-related tables: maintaining B-15
volatility surfaces 12-1
volatility_type_domain 5-10
vs table 12-1
vs_data 12-5
maintaining B-15
vs_datetime 12-5
maintaining B-15
vs_def_ tables 12-2
vs_def_code 12-1
vs_def_domain 5-10
W
w_sec_denormal 2-10, 13-2
maintaining B-3
weekday_domain 5-10
weekend_domain 5-10
weighted average rates 9-6
WHATSNEW file on release CD 5-22
where_clause 13-3

Data Model 521

Uploaded by

Data Model 521

Uploaded by

Infinity Platform™ v5.

© Copyright 1997 Infinity Financial Technology, Inc.

Licenses and Trademarks

Infinity Technical Support

Manual written by Arley Lewis, David Mael, and Christopher Gales

Infinity website: http://www.infinity.com

Chapter 1: Infinity Data Model Overview

Warehouse for Infinity Applications 1-1

Chapter 2: Understanding Relational Data Models

Database Management Systems 2-1

Chapter 3: Data Model Organization

Functional Areas of the Database 3-1

Chapter 4: Modeling Employees and Organizations

Modeling employee/organization relationships 4-1

Chapter 5: Foundation Tables

A note on domain and list tables 5-1

Defining Holidays with the hol_header Table 6-1

Chapter 7: Transaction and Trade Tables

Transactions, Trades, and Trade Legs 7-1

Chapter 8: Security Tables

About This Chapter 8-1

Chapter 9: Flow Tables

The flow Table 9-2

Chapter 10: Reference Index Tables

The infsys_montage_lists Table 10-2

Chapter 11: Curve Tables

Curve Definitions and Representations 11-1

Volatility Surface Definitions 12-1

Chapter 13: Portfolio Tables

Portfolio Definitions: Dynamic and Static 13-1

Chapter 14: Risk Report Tables

Granting an Infinity application login to a new user 15-1

Appendix A: Data Model Changes in the 5.2.1 Release

Changes to Index and Key Definitions in v5.2.1 A-1

Appendix B: Data Model Administration

Purpose and contents B-1

Appendix C: Suggested Reading

Other Infinity Books C-1

Appendix D: Glossary of Relational Modeling Terms

The Data Model is designed to expand easily to accommodate new financial

Warehouse for Infinity Applications

version 5.2 Warehouse for Infinity Applications 1-1

Figure 1-1 Infinity’s system

The chapters are organized in the following order:

• Chapter 1, Infinity Data Model Overview, provides an introduction

• Chapter 2, Understanding Relational Data Models, explains the

• Chapter 3, Data Model Organization, explains the design of the

• Chapter 4, Modeling Employees and Organizations, steps through

• Chapter 5, Foundation Tables, explains the use of the foundation

• Chapter 6, Holiday Tables, shows how the holiday schedules for

• Chapter 7, Transaction and Trade Tables, describes the modeling of

• Chapter 8, Security Tables, describes the tables of the Data Model

version 5.2 About This Manual 1-3

• Chapter 13, Portfolio Tables, explains how groups of trades are

• Chapter 15, Access Permission Tables, explains how to user access

• Appendix A, Data Model Changes in the 5.2.1 Release, explains

• Appendix B, Data Model Administration, outlines the maintenance

• Appendix C, Suggested Reading, lists suggested readings for further

• Appendix D, Glossary of Relational Modeling Terms, defines many

This manual concludes with an index.

Database Management Systems

Maintenance of the relationships between pieces of data is known as referential

version 5.2 Database Management Systems 2-1

An instance is a single occurrence of a given entity. Each instance is stored as a row in

Table name: team

team_name year team_city

Table name: team

team-name year team-city

TEAM year (FK)

version 5.2 Data Tables 2-3

Key and Non-key Attributes

Indentifying and Non-identifying Relationships

version 5.2 Foreign Keys 2-5

JOB-APPLICANT employee_number (FK)

Figure 2-4. A foreign key, employee_number, in a zero-to-zero-or-one identifying relationship.

Another example of a non-identifying relationship would be one between a passenger