May 15, 2002

Summary

MDDL has been working with the Bond Market Association (BMA) to define an XML standard vocabulary and distribution format for fixed income/bond instruments. MDDL Version 2.0 for fixed income is targeted for Beta release by the second week in June. The vocabulary (terms, definitions and hierarchical relationships) is targeted for completion by May 31. BMA has agreed in principle to use MDDL as the content and schema for their Security Master Database Project.

There have been active discussions among SWIFT, 15022/WG10, FIX (fixed income working group), XBRL, RIXML and BMA to coordinate XML-related activities. The objectives are to ensure communication among the various groups and to make sure there is no duplication of activities. All groups are in agreement that one of the primary objectives is the creation of a repository of complete and precisely defined terms. A single repository (ISO 15022 Data Dictionary) should simplify the process of normalization, maintenance and acceptance of both terminology and definition.

Timeline of MDDL 2.0 Development

Global Review of MDDL Vocabulary

The Vocabulary Committee has completed their proposed taxonomy for MDDL 2.0. The Debt Terms spreadsheet represents the proposed elements (independent of the XML schema implementation) that have been modeled in the area of debt securities. In essence, this spreadsheet should be looked at as the proposed taxonomy for the debt securities domain.

The Vocabulary Committee is now ready to have the proposed taxonomy reviewed by FISD members and other interested parties for completeness, accuracy, terminology and definitions (prior to May 31 please). Comments and questions can be submitted to MDDL in two ways:

• Send your comments/questions via e-mail to Michael Atkin to forward to the Vocabulary Committee for review.
   
• Post your comments/questions on the MDDL Yahoo Group. Sign-up should be self-explanatory. If you have problems, contact Tom Andresen (202.789.4452). We encourage you to sign up for the automatic e-mail notification option.

The Debt Terms Spreadsheet

The Debt Terms spreadsheet has been created by Mike Bennett at London Market Systems. The primary objective of this Terms Spreadsheet is to provide a means for people knowledgeable in the debt domain to review the terms and ensure they are complete, correctly structured and exhaustive. It should be possible to do this with no knowledge of XML.

The spreadsheet is broken down into sections based on separate kinds of data about a bond. Please remember, the vocabulary drives the MDDL schema. If we get the vocabulary and relationships right, designing a workable schema should be much easier.

How it works:

Each line of the spreadsheet defines a term that has a unique meaning within the context of debt securities information. The meaning of a term is defined in two separate and complementary ways:

1. The terms are indented in such a way that the position of a term on a line defines it in relation to the terms nested above it.
    
2. There is a column for conventional verbal definitions.

These two mechanisms provide independent means by which the semantic value of a unique meaningful point is defined. Many of the terms nested within any given term are not themselves debt terms, but are either basic types of data (such as numbers, dates or periods) or terms relating to other types of market data (such as an index).

What to review

The different sections of the spreadsheet should be reviewed for completeness, accuracy and consistency. The review should cover:

1. Definitions -- are they defined completely, accurately and adequately
    
2. Reality -- are there potential changes in what might happen in the marketplace that would "break" the structure represented in this spreadsheet (and therefore break the XML which this exists)?
    
3. Terminology -- have we identified the best and most common (and internationally recognized) term for the item?

Content Type

This column in the spreadsheet shows what the contents of a particular piece of information can be. Sometimes these contents are the lines that follow, these being indented to indicate this. If so the Content Type column will try to indicate whether these are:

• An exhaustive list
• An open-ended (inexhaustible) list
• A binary either / or contents
• A free text (this is the last preferred option when the above options cannot be applied)

Schedules

This column in the spreadsheet identifies whether there are payment schedules or other date series information pertaining to the term in question. Schedules cannot be easily modeled in the indented terms format, and so are outlined on a separate worksheet (which is also to be reviewed).

Vocabulary / Alternative Terms

These columns aim to identify all the terms that may be semantically equivalent to the term in question. Are there other terms by which the item in the line under review can also be known?

• in English
• in other languages
• English equivalent terms in other markets
• Is this on another line already when it is only an alternative term?

Definition

This column is for the formal verbal definition of the term. We are in the process of adding terms to the spreadsheet and expect to have it completed shortly. Where applicable these have already been populated from the following hierarchy of sources:

• The ISO 15022 Standard
• The BMA Securities Master Database/Portal Project
• Pre-existing MDDL terms
• Our own working definitions

These should be reviewed for correctness and completeness, and also to ensure they are international definitions and not tied in to any one market or jurisdiction (unless otherwise indicated in the term itself). Any additional definitions should give a source to assist in further review. A personal definition from one's own understanding is fine - simply accredit yourself or your company.

Notes

Any notes to assist in the understanding of a term or in the implementation of the MDDL XML Schema to implement these. These notes will be acted on by the technical team implementing the MDDL Schema.

Review Queries

Any queries or uncertainties around the review of these items. These notes are for others in this review community.

BMA Terms / ISO15022 Terms

These do not need to be reviewed at this time - this is part of the history of how this taxonomy came about, and is used to obtain the relevant definitions from those sources.

MDDL Terms

These do not need to be reviewed by industry experts - this is the working area for identifying and proposing MDDL terms to implement the terms in each line entry.

Details of Terms Spreadsheet

The MDDL Debt Terms Spreadsheet is broken down into the following sections:

• New Issue data
• Market derived information
• History and events
• Tax and regulatory
• Relationships
• Price / Yield / Accrued Interest
• Analytics

Some of these groupings may be implemented as separate sets of terms in MDDL while some may not. This need not concern reviewers at this stage. They are distinguished at this point simply to define the nature of the different meanings concerned.

New Issue Data
Information that is provided in the Prospectus for a new bond issue. Anything that can be defined uniquely about a bond or other debt security at the time of issue and would be provided in a Prospectus, should have an equivalent representation in this section. This includes coupon terms, options for the issuer and the holder (such as calls and puts), and what happens to the redemption proceeds. It also includes all the "birthright" information about a bond such as the issuer(s), underwriters and other parties to the issue.

Market Derived Information
Information that applies to a bond at issue but is "inherited" from the marketplace or other circumstances about the bond rather than being defined uniquely for that bond. For example settlement terms are defined by the market not the bond, but are still a feature of that bond.

History and Events
Information about past events in the life of a bond that become part of the standing information about that bond, such as redemption payment history. Also events in the marketplace such as Euro reconventioning and redenomination.

Tax and Regulatory
Information on the taxation and regulatory status of a bond. Note that where this information is set in the prospectus or is inherited from the market the bond finds itself in, this information should be in those sections rather than separately here. This section may involve a certain amount of review and change as the design implementation progresses.

Relationships
This section is not unique to the Debt domain. Any relationship that may exist between the instrument being described / communicated about and any other instruments is defined here. Debt instruments have many such relationships (for example fungibility) and the full scope of these will be used to enhance the existing MDDL design with regard to instrument relationships. For this review we only need to know about relationships particular to bonds and other dept instruments, though other information is always welcome for the future.

Price / Yield / Accrued Interest
In trading a bond or other debt security, the information about the three interrelated characteristics of price, yield and accrued interest due to the holder needs to be communicated between parties. This information will vary according to the date, interest rates and so on. The MDDL implementation of these elements of the data will be used in different business contexts to the static or historical sets of data indicated above and is therefore listed separately in this taxonomy.

Analytics
For any data feed that needs to represent more detailed analytics about a bond, the terms in this section will be needed. These will include things like duration and convexity, as well as different kinds of yield. The inclusion of these terms in MDDL will allow market data vendors to enrich basic information about the debt security. Most of this information is derived from other features of a bond along with local variables such as the current date and current interest and index values.

For the MDDL 2.0 release only a limited sub-set of analytics is needed. At this stage the review of this section should ensure that these terms provide the basic information that might be used by a fund manager to form a view of his or her portfolio and exposures.

Note that there is no requirement to model any of the differing relationships and underlying calculations that go into these analytics - all that a user of MDDL will need to do is transport the contents of these terms from one machine or application to another - so for instance it does not matter to MDDL how Average Life is calculated for different types of security. It may help to think of the MDDL terms as buckets into which the information is poured by the data provider.

Technical / Development Notes

In development lifecycle terms, the Terms spreadsheet is roughly equivalent to a Requirements Specification, in that it specifies the requirements against which the MDDL schema is to be built. In fact it only specifies a part of those requirements, the rest being defined by business relationships and transactional relations in a way that lends itself to modeling in UML or other modern requirements modeling techniques.

Because of the nature of fixed income, there is not an immediately clear way to use UML or similar object-based modeling for the whole of the MDDL XML Schema requirements, other than as attributes of an object. This spreadsheet then provides a structured view of those attributes.

Turning the Terms into XML Schema Material

Against each term is a column defining the nature of the data which that term may take - for instance, is it a date, a period, a currency and so on. In many cases the "content" of a term is the set of terms nested within it. The MDDL dialect of MXL already provides a means whereby these "sets" of terms is defined. The purpose of the Terms spreadsheet at this point is to identify what those terms are and whether an exhaustive list of these is possible or not.

Debt instruments, and in particular bonds, are very variable, and not a few system developers have come to grief by building assumptions into their data model, where those assumptions would appear reasonable on the basis of bonds already viewed by the developer or analyst.

Since MDDL is not an application but something that is used to develop and interface into applications it is doubly important to ensure that there are no assumptions or unnecessary restrictions built into the schema. One important role of the spreadsheet therefore has to be to identify (with input from those who know the business domain well) what definitions or sets of terms are immutable and which rules can be changed by someone issuing a new security at some time in the future. That is, for MDDL to work there has to be a clear distinction between definitions that are fundamental to the nature of the instrument, and definitions which are a matter of industry practice or are specific to a particular market, country or sector.

The overriding consideration at the design phase has to be to ensure that the relationships and their nature are defined clearly, in a manner that can be reviewed by people who know the business, in such a way that they can be unambiguously implemented by the technical team responsible for creating the MDDL schema.