Abstract:
Post creation of debt products, if holidays are announced and calendars are accordingly modified, a manual update is done across all the products if any of current dates falls on the new holiday dates. Thus, while it might be relatively easy during a creation of debt instrument to verify that the proposed or the actual dates scheduled on the calendar is not concurrent with the holiday data set, it can be both, difficult and time-consuming to ensure that an unexpected holiday is accounted for and adapted in the associated calendar. Accordingly, systems and methods are disclosed for automatically managing the impacted dates of debt products upon the occurrence of unexpected holiday(s).

Description:
FIELD OF THE INVENTION 
       [0001]    The present disclosure relates, in general, to the field of financial instruments and, in particular, to methods and systems for improving the efficiency of communicating information pertaining to debt instruments. 
       BACKGROUND OF THE INVENTION 
       [0002]    Electronic information processing and communication systems are playing an increasingly important role in coordinating business operations among various participants in a financial community. Banks are significant investors in local currency debt in developing economies and one of the significant participants in domestic bond markets. Debt instruments are complex investment products, the performance of which depends on several basic characteristics. It is a long-term commitment to debt holders since the issuers have to meet the obligations for as long as the bond is outstanding. A bond is a type of debt instrument which is a contract to pay interest and repay principal. It is both, a financial instrument and a legal obligation, enforceable in court. Information relating to a bond that will be issued can include, for example, the bond&#39;s issue date, payment periods, its maturity, redemption features, coupons, type of coupon involved, the bond&#39;s yield calculation method, amortization, or other information descriptive of the bonds to be issued. The ongoing responsibly of managing debt instrument, for example, bonds, falls on the issuer as regards the debt payments and to ensure the timely delivery of such payments. The bond offering will require the issuer to ensure compliance with the bond terms as per the executed documents. The issuers of debt instruments and the debt holders will depend on the legally enforceable document and the corresponding applicable interest rates to calculate amounts such as interest amount, principal amounts, among other things. The conditions might depend on such factors as the calendar day, that is, on whether it is a workday, weekend day or public holiday. This can affect the way interest is calculated on a given calendar day. 
         [0003]    In general, while scheduling the dates pertaining to a bond, the calendar is checked against a holiday data set, specific for a particular region, territory or country of the world. These           data sets may also be inclusive of the unofficial holidays pertaining to a particular region, territory or country (for example, the week between Christmas and January 1 st ) which can impact the completion of the business transaction or action to be completed on that particular that. This is primarily due to the reason that a large number of businesses may remain closed and due to employee vacations occurring on this date. Therefore, when the financial institutions or the companies schedule dates pertaining to debt instruments, for example, bonds, it is important for them to consider the national, state, bank and corporate holidays in countries that use the currencies involved in the transactions. Most countries have their own set of holidays, of which only a few are observed in other countries around the world. For example, in India, a business action date may not be scheduled for August 15 th  and this may not apply to other countries across the world. In United States, typically, banks will be closed for July 4 th . One of ordinary skill will appreciate that a holiday is not limited to national holidays or holidays declared by a corporate. Generalizing, a holiday should be broadly construed to cover any given type of event that may be designated by an administrator or a third party, to have local significance (even though the event may not have significance in some other locale in which the managed region is supported). For example, a specific locale may designate certain days of the calendar for carrying out the operations. When debt instruments are created using software, such as a wealth management system, for example, the cash flows generated based on the currency calendars may be mapped to the product. As used herein, the terms ‘currency calendar’, ‘currency holiday calendar’, currency settlement holidays&#39; are used somewhat interchangeably. In order for a date to be a valid settlement date, the banks for that currency must be open for settlements. If either currency has a holiday on the target settlement date, settlement is deferred until the next valid business day for both currencies. However these currency calendars may not have holidays maintained for           uration of the debt instrument as the holiday calendars for different currencies may not available beyond two to three years. When a bank creates financial products using these calendars, the holidays for future years are not taken into account. Issuers maintain various future dates where business actions are proposed to happen. In addition to this, the dates maintained need to be valid business days. The term ‘business day’, as used herein, means any day on which the financial institutions are open for business. 
         [0004]    It is seen that post creation of debt products, when the holidays are announced and calendars are modified; a manual update is done across all the products, if any of current dates falls on the new holiday dates. When holidays are added to the calendar, there is a need for a provision to change all the cash flow dates, determination dates, amongst other dates, across all the debt products in the system. This needs to be done with proper checks and controls in place as it involves a debt holder&#39;s money. Hence, the data maintained in system needs to be changed as and when holiday data is maintained in system. For example, in the case of bonds, the dates which are primarily impacted based on the holiday data set include adjusted cash flow dates, adjusted call dates, adjusted put dates, determination date, reference rate dates. The above set of dates needs to be changed based on the changes introduced in the relevant calendars. Changes in calendar can be addition of a new holiday, making a previous marked holiday as working day. This can also be used to track all changes and update the products based on new, unexpected holidays. It will also allow banks to simulate, track and do a mass update across products with proper system checks. 
         [0005]    Thus, while it might be relatively easy during a creation of debt instrument to verify that the proposed or the actual dates scheduled on the calendar is not concurrent with the holiday data           can be both, difficult and time-consuming to ensure that an unexpected holiday is accounted for and adapted in the associated calendar. This is required to be taken care of, as it can impact the scheduling of the business actions and thus there lies a need to adopt an approach which accounts for such variability. There may be a need to manage these ‘unexpected holidays’ and these may need to be accordingly added, modified or deleted from the holiday data set. 
         [0006]    Disclosed herein are systems and methods for managing unexpected holidays pertaining to the issued debt instruments. 
       SUMMARY OF THE INVENTION 
       [0007]    Aspects of the disclosure relate to a system and method for managing unexpected holidays of issued debt products. 
         [0008]    It is therefore one object of the present disclosure to provide systems and methods for automatically managing the impacted dates of debt products upon the occurrence of an unexpected holiday. 
         [0009]    It is another object of the present disclosure to manage the impacted dates across several debt products as one process. 
         [0010]    It is yet another object of the present disclosure to generate reports of the debt products impacted with the occurrence of the unexpected holiday. 
         [0011]    The above as well as additional aspects and advantages of the disclosure will become it in the following detailed written description 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0012]    The aspects of the disclosure will be better understood with the accompanying drawings. 
           [0013]      FIG. 1  is a block diagram of a computing device to which the present disclosure may be applied. 
           [0014]      FIG. 2  shows an exemplary architecture of unexpected holiday(s) management system. 
           [0015]      FIG. 3  shows an exemplary process with the flow of steps for managing unexpected holiday(s). 
           [0016]      FIG. 4  shows an exemplary process with the flow of steps for calculation of determination date and reference rate dates. 
       
    
    
       [0017]    While systems and methods are described herein by way of example and embodiments, those skilled in the art recognize that systems and methods disclosed herein are not limited to the embodiments or drawings described. It should be understood that the drawings and description are not intended to be limiting to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the appended claims. Any headings used herein are for organizational purposes only and are not meant to limit the scope of the description or the claims. As used herein, the word “may” is used in a           ve sense (i.e., meaning having the potential to) rather than the mandatory sense (i.e., meaning must). Similarly, the words “include”, “including”, and “includes” mean including, but not limited to. 
       DETAILED DESCRIPTION 
       [0018]    Disclosed embodiments provide computer-implemented methods, systems, and computer-readable media for managing unexpected holidays of issued debt products. The embodiments described herein are related to bond products; however, such usage is not intended to limit the present disclosure to bond products. To facilitate a clear understanding of the present disclosure, illustrative examples are provided herein which describe certain aspects of the disclosure. However, it is to be appreciated that these illustrations are not meant to limit the scope of the disclosure, and are provided herein to illustrate certain concepts associated with the disclosure. 
         [0019]    It is also to be understood that the present disclosure may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. Preferably, the present invention is implemented in software as a program tangibly embodied on a program storage device. The program may be uploaded to, and executed by, a machine comprising any suitable architecture. 
         [0020]      FIG. 1  is a block diagram of a computing device  100  to which the present disclosure may be applied according to an embodiment of the present disclosure. The system includes at least one processor  102 , designed to process instructions, for example computer readable           ions (i.e., code) stored on a storage device  112 . By processing instructions, processing device  102  may perform the steps and functions disclosed herein. Storage device  112  may be any type of storage device (e.g., an optical storage device, a magnetic storage device, a solid state storage device, etc.), for example a non-transitory storage device. Alternatively, instructions may be stored in one or more remote storage devices, for example storage devices accessed over a network or the internet. The computing device also includes an operating system and microinstruction code. The various processes and functions described herein may either be part of the microinstruction code or part of the program (or combination thereof) which is executed via the operating system. Computing device  100  additionally may have memory  104 , an input controller  108 , and an output controller  110 . A bus (not shown) may operatively couple components of computing device  100 , including processor  102 , memory  104 , storage device  112 , input controller  108 , output controller  110 , and any other devices (e.g., network controllers, sound controllers, etc.). Output controller  110  may be operatively coupled (e.g., via a wired or wireless connection) to a display device (e.g., a monitor, television, mobile device screen, touch-display, etc.) in such a fashion that output controller  110  can transform the display on display device (e.g., in response to modules executed). Input controller  108  may be operatively coupled (e.g., via a wired or wireless connection) to input device (e.g., mouse, keyboard, touch-pad, scroll-ball, touch-display, etc.) in such a fashion that input can be received from a user. Of course,  FIG. 1  illustrates computing device  100  with all components as separate devices for ease of identification only. Each of the components may be separate devices (e.g., a personal computer connected by wires to a monitor and mouse), may be integrated in a single device (e.g., a mobile device with a touch-display, such as a smartphone or a tablet), or any combination of devices (e.g., a computing device operatively coupled to a touch-screen display device, a           of computing devices attached to a single display device and input device, etc.). Computing device  100  may be one or more servers, for example a farm of networked servers, a clustered server environment, or a cloud network of computing devices. 
         [0021]    The disclosure herein proposes systems and methods for managing unexpected holidays for debt instruments. The term ‘unexpected holiday’, as used herein, refers to a public holiday, which is not a ‘known public holiday’ and is not maintained in the holiday data set at the time when bonds were issued. The term ‘known public holiday’ refers to any gazette holiday, which is known at the time the bond issued. 
         [0022]    Referring now to  FIG. 2 , which is an exemplary architecture  200  for managing unexpected holidays for the issued debt instruments.  200  is illustrates a system in which the information processing of the various bond attributes take place. The system can include a computerized server accessible via a distributed network such as the internet. A user can use the computerized system or the network access device to receive data, input data, transmit or view information processed relating to the bonds issued, for example. The user can receive, input, transmit or view information using banking software, for instance, via the input interface  202 . The GUI (not depicted in figures) can be presented on the computerized system or a network access device or any other type of terminal capable of creating a display pursuant to an electronic signal. The banking software can have a module, for instance, a ‘bonds master’ (BM)  204  to manage the details of the issued bonds  204   a . A portion of the display (not depicted in figures) can display information descriptive of the bond issued, such as for example, the bond&#39;s issue date, settlement date, price, yield, from the bonds master (hereinafter may also be referred as ‘BM’). The ‘bonds master’  204  can maintain the bond code which is the unique code that is           to a bond being defined in the system. This field can act as the primary key for all the tables where the bond details would be available. The choice of currency in which the bonds will be denominated is market driven and information regarding this can be captured in the ‘bonds master’. The details of the issued bonds can include information which includes payment periods, maturity date, redemption features, coupons, type of coupons involved, the business convention adopted or other information descriptive of the bonds to be issued. Once a bond is offered, an issuer maintains some dates related to the bond and these are scheduled on the system. The issuer needs to maintain these future dates where business actions specific to the issued bonds are scheduled to happen. These future dates correspond to ‘actual dates’ i.e. the dates on which the business transaction pertaining to the bond is scheduled to happen. The actual dates are determined by the system based on the agreed terms in the contract and does not take into account the business day convention. The ‘bonds master’ can maintain the business day convention selected to be applied for the bonds issued in a transaction. It is obvious for one skilled in the art that the selection for business day convention determines how non-business days are treated. The conventions are distinguished by the manner in which they adjust the date from which the interest starts accruing till the settlement date. Each convention has a set of rules directing the adjustments. The type of conventions include Actual/360, Actual/365(fixed), Actual/360 and 30/360, each with a set of rules directing the adjustments If any of these dates fall on a known public holiday, the system reschedules the actual date(s) to an ‘adjusted date’ which will be the next working date as per the currency calendar. This date will be derived from the actual date by checking it for holidays against ‘Payment City Calendars’ and applying business day conventions. If the actual date does not fall on a holiday then the adjusted date remains the same as the actual date. The adjusted dates, unless used otherwise, refer to the following: 
         [0023]    Determination Date—The term ‘determination date’ refers to the date on which the interest will be calculated. The term ‘first determination date’  204   b  refers to the adjusted determination date by verifying the date against the known public holiday, on the system. 
         [0024]    Reference Rate Date—The term ‘reference rate date’ refers to the date when the rate for the underlying coupon base must be considered for coupon rate determination. The term ‘first reference rate date’  204   c  refers to the adjusted reference rate date by verifying the date against the known public holiday, on the system. 
         [0025]    Call Date—The term ‘call date’ refers to the date when an issuer has the option to redeem all or part of a bond issue before maturity, at a specified price. The term ‘first call date’  204   d  refers to the call date adjusted by verifying the actual date against the known public holiday set. 
         [0026]    Put Date—The term ‘put date’ refers to the date when a bond can be redeemed at the option of the bond holder for face value plus accrued interest. The term ‘first put date’  204   e  refers to the put date adjusted on the system by verifying the actual date against the known public holiday set. 
         [0027]    Cash-flow Dates—The term cash-flow dates refers to the date when the cash, which includes the interest and the principal, is repaid in part or whole, to the bond holder. The term ‘first cash-flow date’  204   f  refers to the date adjusted on the system by verifying the actual date against the known public holiday set. 
         [0028]    Coupon Event Date—The term ‘Coupon Event Date’  204   f   1  refers to the date when the bond holder is obliged to pay interest to the bond holder. The coupon event date occurs at periodic intervals based on the type of coupons. Coupons are normally described in terms of the coupon rate, which is calculated by adding the total amount of coupons paid per year and dividing the bond&#39;s face value. 
         [0029]    Amortization Date—The term ‘Amortization date’  204   f   2  refers to the date when part of the principal is repaid, before maturity of the bond. 
         [0030]    Principal Repayment Date—Principal refers to the cost of a bond multiplied by the number bonds issued in a transaction. The principal repayment date  204   f   3  refers to the date when the principal is repaid to the bond holder. 
         [0031]    The ‘bonds master’ can also maintain other details of the bond which are necessary for fully defining the bond attributes. For example, the coupon feature of a bond may require that additional attributes be specified for fully defining the bond&#39;s coupon feature. These additional attributes may include, by way of non-limiting example, whether the coupons are periodic coupons, detailed coupons or perpetual coupons. 
         [0032]    The ‘bonds master’ can communicate with a calendar module  206  for referring to the payment city calendar and the reference city calendar. The adjusted dates are scheduled after checking the actual dates against payment city calendars and applying business day conventions. As used herein, the term payment city calendar corresponds to the country calendar which is to           red. The ‘bonds master’ can store the details of the one or more currency calendars to be referred. The payment dates i.e. coupon event date  204   f   1 , amortization date  204   f   2 , principal payment date  204   f   3 , first call date  204   d  and the first put date  204   e  are scheduled after checking for holidays across the payment city calendars. The first determination date  204   b  and the maturity date are validated against these payment city calendars. The words ‘electronic calendar’ or ‘calendar’ are used somewhat interchangeably. The reference city calendar  206   b  indicates the calendar to be referred for checking the market rate of an index, for example, for LIBOR, the London calendar would be observed. 
         [0033]    The ‘bonds master’ can also maintain the flag values  204   g  of the dates related to the issued bond product. The flag values denote the permission to make changes to date entered in the system while creating the bond product. The values can correspond to ‘activated’ and ‘deactivated’. The term ‘activated’ herein permits the system to make a modification to the initial date and the term ‘deactivated’ does not permit any modification. 
         [0034]    According to the present disclosure, if the holiday data maintained on the system is changed, the above impacted dates need to be rescheduled based on the introduced changes. Changes in the holiday data set can include addition of a new holiday or making a marked holiday as working day. The processor  208  recalculates the impacted dates and stores it in a rescheduling module  210 . If a first scheduled date is not impacted with the change in the holiday data set, the second rescheduled date remains the same as the first scheduled date. The rescheduled dates can be updated in the ‘bonds master’. According to one embodiment of the disclosure, the rescheduled dates can be shown to the user in an output interface  212 . Alternatively, the rescheduled dates can be sent to a reporting module which can generate a report of the impacted dates to the user.           orts can include a success or a failure report and include the bond codes, impacted date types, previously maintained dates and new dates. In one embodiment of the disclosure, a calendar can be displayed in the GUI to show the impacted dates. 
         [0035]      FIG. 3 . is a flowchart  300  showing the functioning of the rescheduling module  208 . The flow is triggered once an unexpected holiday is included or modified in the holiday data set  302 . The user can be given an option to select the bonds, single or a group of bonds, for which the impacted dates are to be rescheduled. Accordingly single or batch bond accounts can be selected by the system  304 . The scheduled dates  306  can be retrieved from the ‘bonds master’  204 . These include the ‘first determination date’  204   b , the ‘first reference rate date’  204   c , the ‘first call date’  204   d , the ‘first put date’  204   e  and the ‘first cash-flow dates’  204   f . The dates are checked against the one or more selected payment city calendars and reference city calendars  206 , in the ‘bonds master’  204 . The ‘bonds master’ can check the flag values  308  from the ‘flag values’ module  204   g . If the flag value is set as deactivated then the system retains the original dates  310  and no changes are made to the impacted dates. Alternatively, if the flag value is set as activated, the system can proceed to check the impacted dates. If the ‘first call date’ and/or the ‘first put date’ and/or the ‘first cash-flow dates’ coincides with the unexpected holiday  310  entered in the holiday data set, then the business day subsequent to the first scheduled date to be rescheduled is selected as the second rescheduled date  314 . The calculation of the second rescheduled dates can be based on the business day convention selected in the ‘bonds master’. The subsequent business days will be selected based on the respective payment city calendars. The system also checks for the ‘first determination date’ (hereinafter also referred to as the ‘first DD’) and for the ‘first reference rate date’ (hereinafter also referred to as the ‘first RRD’)  316 . If           ys fall on a business day then no changes are made and the original dates are retained as the second rescheduled dates  310 . If these dates fall on an unexpected holiday included in the holiday data set  8  for the first determination date and the first reference rate date is checked to determine whether the ‘bonds master’ has the value set as activated or deactivated. If the flag value is set as activated then the system recalculates the first DD and the first RRD to a second rescheduled date  320 . If the flag value is set as deactivated then a business day subsequent to the first scheduled date to be rescheduled is selected as the second rescheduled date  310 . 
         [0036]      FIG. 4 . shows how determination date and reference rate date is calculated. Determination date is the date when the system will attempt to determine the rate of the underlying coupon base. Determination lag is the number of days before the adjusted coupon event date to determine the determination date. This is the date the coupon rate will be determined. If this field is left blank the determination lag is automatically set to zero. Determination lag is used to determine the determination date for bonds based on whether the bonds are fixed in arrears or in advance. For bonds&#39; fixed in arrears, determination date is calculated based on the following formula: 
         [0000]      Determination Date=(Actual Coupon Event Date/Adjusted Coupon Event Date)−Determination Lag
 
         [0037]    For bonds&#39; fixed in advance, determination date is calculated based on the following formula: 
         [0000]      Determination Date=(Actual Coupon Event Date/Adjusted Coupon Event Date of Previous Coupon)−Determination Lag
 
         [0038]    Typically, determination date would be calculated using the adjusted event date, if the interest payout is adjusted  402 ,  404 . Calculation based on actual coupon event date would happen if the interest payout is unadjusted  406 . Reference rate date determines the date when the rate for the underlying coupon base must be considered for coupon rate determination. Reference city calendars are used to identify business days while calculating reference rate date. Reference rate date to be used to perform reference date calculation for various cash flows will be done based on parameterization done at ‘bonds master’. Reference lag is the number of days before the determination date the reference rate value needs to be picked. In case the reference rate is not maintained for that day then the latest available reference rate can be taken. If this field is left blank the reference lag is set to zero. Typically, for adjusted coupon bonds (adjusted interest payouts), the reference rate lag is quoted from the adjusted event date  402 ,  404 . For unadjusted coupon bonds, reference date lag is quoted from actual coupon event date  406 . 
         [0000]    Illustrative example to calculate determination date and reference rate dates:
       Bond Code in ‘bonds master’—B1   Value Date—Jan. 10, 2010   Holidays on Payment City Calendar—Jan. 9, 2011, Jan. 10, 2011 and Jan. 11, 2011   Holidays on Reference City Calendar—Jan. 8, 2011, Jan. 9, 2011, Jan. 11, 2011   Payout Schedule on System:       
 
         [0000]    
       
         
               
               
               
             
           
               
                   
                   
               
               
                   
                 Actual Coupon Event Date 
                 Adjusted Coupon Event Date 
               
               
                   
                   
               
             
             
               
                   
                 10 th  Jan. 2011 
                 12 th  Jan. 2011 
               
               
                   
                 10 th  Jan. 2012 
                 10 th  Jan. 2012 
               
               
                   
                   
               
             
          
         
       
     
       Determination Date &amp; Ref Date Calculation 
     Case I: 
       [0000]    
       
         
           
             Interest Payout—Adjusted 
             Interest Fixed in—Arrears 
             Determination Lag—1 
             Ref Rate Lag—2 
           
         
       
     
       Determination Date (DD) 
       [0048]      
         [0000]    
       
         
               
               
               
             
           
               
                   
               
               
                 Event Date 
                 Adjusted Event Date 
                 First Determination Date 
               
               
                   
               
             
             
               
                 10 th  Jan. 2011 
                 12 th  Jan. 2011 
                 8 th  Jan. 2011 
               
               
                 10 th  Jan. 2012 
                 10 th  Jan. 2012 
                 9 th  Jan. 2012 
               
               
                   
               
             
          
         
       
     
       Reference Rate Date (RRD) 
       [0049]      
         [0000]    
       
         
               
               
               
               
               
             
           
               
                   
               
               
                   
                   
                 RRD based 
                 RRD based 
                   
               
               
                   
                 Adjusted 
                 on actual 
                 on adjusted 
                 RRD Based 
               
               
                 Event Date 
                 Event Date 
                 event date 
                 event date 
                 on DD 
               
               
                   
               
             
             
               
                 10 th  Jan. 2011 
                 12 th  Jan. 2011 
                 6 th  Jan. 2011 
                 7 th  Jan. 2011 
                 6 th  Jan. 2011 
               
               
                 10 th  Jan. 2012 
                 10 th  Jan. 2012 
                 8 th  Jan. 2012 
                 8 th  Jan. 2012 
                 7 th  Jan. 2012 
               
               
                   
               
             
          
         
       
     
       Case II: 
       [0000]    
       
         
           
             Interest Payout—Unadjusted 
             Interest fixed in advance 
             Determination Lag—0 
             Ref. Rate Lag—2 
           
         
       
     
       Determination Date (DD) 
       [0054]      
         [0000]    
       
         
               
               
               
             
           
               
                   
               
               
                 Event Date 
                 Adjusted Event Date 
                 Determination Date 
               
               
                   
               
             
             
               
                 10 th  Jan. 2011 
                 12 th  Jan. 2011 
                 10 th  Jan. 2010 
               
               
                 10 th  Jan. 2012 
                 10 th  Jan. 2012 
                 10 th  Jan. 2011 
               
               
                   
               
             
          
         
       
     
       Reference Rate Date (RRD) 
       [0055]      
         [0000]    
       
         
               
               
               
               
               
             
           
               
                   
               
               
                   
                   
                 RRD based 
                 RRD based 
                 RRD based on 
               
               
                   
                 Adjusted 
                 on actual 
                 on adjusted 
                 determination 
               
               
                 Event Date 
                 Event Date 
                 event date 
                 event date 
                 date 
               
               
                   
               
             
             
               
                 10 th  Jan. 2011 
                 12 th  Jan. 2011 
                 8 th  Jan. 2010 
                 8 th  Jan. 2010 
                 8 th  Jan. 2010 
               
               
                 10 th  Jan. 2012 
                 10 th  Jan. 2012 
                 6 th  Jan. 2011 
                 7 th  Jan. 2011 
                 8 th  Jan. 2011 
               
               
                   
               
             
          
         
       
     
       Case III: 
       [0000]    
       
         
           
             Interest Payout—Adjusted 
             Interest fixed in advance 
             Determination Lag—0 
             Ref Rate Lag—2 
           
         
       
     
       Determination Date (DD) 
       [0060]      
         [0000]    
       
         
               
               
               
             
           
               
                   
               
               
                 Event Date 
                 Adjusted Event Date 
                 Determination Date 
               
               
                   
               
             
             
               
                 10 th  Jan. 2011 
                 12 th  Jan. 2011 
                 10 th  Jan. 2010 
               
               
                 10 th  Jan. 2012 
                 10 th  Jan. 2012 
                 12 th  Jan. 2011 
               
               
                   
               
             
          
         
       
     
       Reference Rate Date (RRD) 
       [0061]      
         [0000]    
       
         
               
               
               
               
               
             
           
               
                   
               
               
                   
                   
                 RRD based 
                 RRD based 
                 RRD based on 
               
               
                   
                 Adjusted 
                 on actual 
                 on adjusted 
                 determination 
               
               
                 Event Date 
                 Event Date 
                 event date 
                 event date 
                 date 
               
               
                   
               
             
             
               
                 10 th  Jan. 2011 
                 12 th  Jan. 2011 
                 8 th  Jan. 2010 
                 8 th  Jan. 2010 
                 8 th  Jan. 2010 
               
               
                 10 th  Jan. 2012 
                 10 th  Jan. 2012 
                 6 th  Jan. 2011 
                 7 th  Jan. 2011 
                 7 th  Jan. 2011 
               
               
                   
               
             
          
         
       
     
         [0062]    These embodiments may be implemented with software, for example modules executed on computing devices such as computing device  100  of  FIG. 1 . Of course, modules described herein illustrate various functionalities and do not limit the structure of any embodiments. Rather the functionality of various modules may be divided differently and performed by more or fewer modules according to various design considerations. 
         [0063]    Having described and illustrated the principles of the disclosure with reference to described embodiments and accompanying drawings, it will be recognized by a person skilled in the art that the described embodiments may be modified in arrangement without departing from the principles described herein.