The present application relates to a method for use in a so-called Central Securities Depository, commonly abbreviated as CSD, by means of which method financial instruments can be organized in the CSD-system. The invention also discloses a computerized system for carrying out the method.
Traditionally, centralized institutions have been used mainly for storing gold which belongs to different nations in the same location. When transferring assets from one nation to another, all that needs to be done is to simply transfer gold from the “pile” which belongs to the paying nation to the “pile” which belongs to the nation that is to receive the payment. The principles of centralized institutions greatly facilitates the processing of payments, and for this reason, there is an interest in using such centralized solutions for commodities other than gold, in principle for any kind of commodity or instrument that can be imagined in the financial market, e.g., bonds, shares, etc.
In such an “expanded” centralized system there would be a plethora of instruments. The gathering of all instruments in one place (physical or virtual) is advantageous for those using the system, e.g., issuers, investors, and the operator of the system. Such a system is referred to as a Centralized Securities Depository, abbreviated as CSD.
Each kind of financial instrument in such a system would be defined by attributes, which are specific for each individual instrument. According to contemporary solutions and systems, the attributes for each individual instrument comprised in a system are “hard coded”. Due to, inter alia, the vast amount of instruments which the system needs to be able to handle, this “hard coding” makes the system difficult and cumbersome to handle, for example, due to the fact that new financial instruments can appear in existing markets, or when it is desired to adapt the system to new markets, or exchange information between the markets.
There is thus a need for a method to add new instruments in an easy manner to an existing CSD-type system. The method should also facilitate making amendments to existing instruments in the system.
This need is met by the present method for organizing financial instruments in a CSD-system where the instruments can be traded. Attributes are assigned to the instruments which define the instruments. The instruments are organized in a hierarchic multi-level structure as follows:
Preferably, each instrument is only linked to one other instrument on a level above it. Any amendment to an attribute in an instrument causes the same amendment in the same attribute of those instruments which are linked to the amended instruments and which are on lower levels in the hierarchy than the amended instrument. In this way, amendments to existing instruments are greatly facilitated, since amendments need only be made on the highest level common to the instruments which are to be amended, and the amendment will then “trickle down” to the instruments in question.
The technology greatly facilitates the adding of new instruments to the system. When there is a need or desire to add a new instrument to the system, an existing instrument in the CSD-system is found which has at least all of the attributes of the instrument to be added. The new instrument is then placed on a level in the hierarchy of the system which is below said existing instrument, and a link is created between the instrument to be added and the existing instrument.
A computerized CSD-system is described, which comprises a register of instruments. The register is organized along the principles described above.
In a CSD-system where various financial instruments are traded, the instruments are defined by attributes. Examples of attributes include the identity of the issuer of the instrument in question, the ISIN code, or some other code which identifies the instrument, e.g., CUSIP, the date of issue of the security, the interest rate, etc.
In addition to the objectives described above, additional desirable objectives for instruments in the register of a CSD-like system include:
A multi-level hierarchical system is provided for organizing a register of financial instruments in a CSD-system. The number of levels preferably is not restricted by an upper limit.
With reference to
The instruments (AB) at the top level of the hierarchy are suitably not instruments which can be traded as such, but are rather generic “templates” for the instruments on the lower levels (ABBB, ABCC; ABBB123, ABCC456) that are “real” instruments that can be traded, e.g., government bonds or mortgage-backed securities and shares. A template in a system organized can either serve as a template on the next level, or as a template for an instrument on the next level. Although
As can be seen from the group shown in
When organizing the group in
The steps described above are also outlined in the accompanying flowchart in
If, at a later stage, a new instrument needs to be added to the register, the following steps could be used:
These three steps are also outlined in the accompanying flowchart in
Naturally, all attributes can be made mandatory to inherit according to the principle of linkage explained previously, but the principle of
However, the attributes which were optional from the first level to the second may have different properties of inheritance when going from the second level to the third level in the hierarchy. This is indicated in
In
A group of instruments is organized in three levels. At the top level, there is an instrument template known as “Government bonds”. The exact attributes of that template will not be enumerated here, as they should be well known to those working in the field. However, one attribute which Government Bonds have is that they generate an interest. In this particular case, interest can be generated in two ways: fixed or floating. Thus, at the top level, the template is provided with two attributes: one for fixed interest and one for floating interest.
On the next level, there are two templates, one for each of the more specific cases of bonds, which have fixed interest rates, and bonds with floating interest rates. One of these templates will inherit the attribute “fixed interest” and the other template will inherit the attribute “floating rate”. This is done by both of the interest attributes (fixed and floating) at the top level being designated as optional for the next level, i.e., the second level. Then, on the second level, in the template for fixed interest bonds the attribute for “floating interest” will be designated as excluded from the following levels. In a corresponding manner, the template for floating rate bonds will exclude the attribute “fixed interest” from the following levels.
In addition to having a characteristic property, for example, fixed or floating interest, an attribute can also have a value. By way of example, in the case of the attribute being “interest,” the value could be the interest rate.
In order to make the system even more flexible and easy to organize, the inheriting of the value of an attribute from a higher level to a lower level can also be made mandatory or optional regardless of whether the attribute was optional or mandatory to inherit. How a value is to be inherited would be set by, for example, the operator of the system.
If the inheritance of the attribute is mandatory and the inheritance of the value is optional, the instrument inherits a value as an example for the attribute (e.g., interest). A value needs to be set for the attribute in question since the attribute, i.e., the interest rate, is mandatory. The value could be either the inherited (“example”) value, or a new defined value. Naturally, other ways of setting a value could not be used, for example, using some kind of automated information retrieval system. If the inheritance of the interest attribute is optional, and that option is chosen, the interest needs to be set, which can suitably be done in the manner just described.
Number | Name | Date | Kind |
---|---|---|---|
5327559 | Priven et al. | Jul 1994 | A |
5918052 | Kruskal et al. | Jun 1999 | A |
5930778 | Geer | Jul 1999 | A |
5987423 | Arnold et al. | Nov 1999 | A |
6115719 | Purdy et al. | Sep 2000 | A |
6134706 | Carey et al. | Oct 2000 | A |
6141658 | Mehr et al. | Oct 2000 | A |
6278981 | Dembo et al. | Aug 2001 | B1 |
6366922 | Althoff | Apr 2002 | B1 |
6513152 | Branson et al. | Jan 2003 | B1 |
6564209 | Dempski et al. | May 2003 | B1 |
6691282 | Rochford et al. | Feb 2004 | B1 |
7177839 | Claxton et al. | Feb 2007 | B1 |
20010005888 | Abdelkrim | Jun 2001 | A1 |
20010025264 | Deaddio et al. | Sep 2001 | A1 |
20010044766 | Keyes | Nov 2001 | A1 |
20020073078 | Ku et al. | Jun 2002 | A1 |
20020078115 | Poff et al. | Jun 2002 | A1 |
20020091621 | Conklin et al. | Jul 2002 | A1 |
20030110112 | Johnson et al. | Jun 2003 | A1 |
20030172192 | Carey et al. | Sep 2003 | A1 |
20040216087 | Wilson et al. | Oct 2004 | A1 |
20040236668 | Toffey | Nov 2004 | A1 |
20050209940 | Lea et al. | Sep 2005 | A1 |
Number | Date | Country |
---|---|---|
10198735 | Jul 1998 | JP |
A-2001-92879 | Apr 2001 | JP |
A-2003-30213 | Jan 2003 | JP |
Number | Date | Country | |
---|---|---|---|
20040267653 A1 | Dec 2004 | US |