<h2>Creating an instance and lifecycle<aclass="headerlink"href="#creating-an-instance-and-lifecycle"title="Permalink to this headline">¶</a></h2>
<p>There are two valid operations on an IRS. The first is to generate via the <codeclass="docutils literal"><spanclass="pre">Agree</span></code> command (signed by both parties)
and the second (and repeated operation) is <codeclass="docutils literal"><spanclass="pre">Fix</span></code> to apply a rate fixing.
To see the minimum dataset required for the creation of an IRS, refer to <codeclass="docutils literal"><spanclass="pre">IRSTests.kt</span></code> which has two examples in the
function <codeclass="docutils literal"><spanclass="pre">IRSTests.createDummyIRS()</span></code>. Implicitly, when the agree function is called, the floating leg and fixed
leg payment schedules are created (more details below) and can be queried.</p>
<p>Once an IRS hase been agreed, then the the only valid operation is to apply a fixing on one of the entries in the
<codeclass="docutils literal"><spanclass="pre">Calculation.floatingLegPaymentSchedule</span></code> map. Fixes do not have to be applied in order (although it does make most
sense to do them so).</p>
<p>Examples of applying fixings to rates can been seen in <codeclass="docutils literal"><spanclass="pre">IRSTests.generateIRSandFixSome()</span></code> which loops through the next
fixing date of an IRS that is created with the above example function and then applies a fixing of 0.052% to each floating
event.</p>
<p>Currently, there are no matured, termination or dispute operations.</p>
</div>
<divclass="section"id="technical-details">
<h2>Technical Details<aclass="headerlink"href="#technical-details"title="Permalink to this headline">¶</a></h2>
<p>The contract itself comprises of 4 data state classes, <codeclass="docutils literal"><spanclass="pre">FixedLeg</span></code>, <codeclass="docutils literal"><spanclass="pre">FloatingLeg</span></code>, <codeclass="docutils literal"><spanclass="pre">Common</span></code> and <codeclass="docutils literal"><spanclass="pre">Calculation</span></code>.
Recall that the platform model is strictly immutable. To further that, between states, the only class that is modified
is the <codeclass="docutils literal"><spanclass="pre">Calculation</span></code> class.</p>
<p>The <codeclass="docutils literal"><spanclass="pre">Common</span></code> data class contains all data that is general to the entire swap, e.g. data like trade identifier,
valuation date, etc.</p>
<p>The Fixed and Floating leg classes derive from a common base class <codeclass="docutils literal"><spanclass="pre">CommonLeg</span></code>. This is due to the simple reason that
they share a lot of common fields.</p>
<p>The <codeclass="docutils literal"><spanclass="pre">CommonLeg</span></code> class contains the notional amount, a payment frequency, the effective date (as well as an adjustment
option), a termination date (and optional adjustment), the day count basis for day factor calculation, the payment delay
and calendar for the payment as well as the accrual adjustment options.</p>
<p>The <codeclass="docutils literal"><spanclass="pre">FixedLeg</span></code> contains all the details for the <codeclass="docutils literal"><spanclass="pre">CommonLeg</span></code> as well as payer details, the rate the leg is fixed at
and the date roll convention (ie what to do if the calculated date lands on a bank holiday or weekend).</p>
<p>The <codeclass="docutils literal"><spanclass="pre">FloatingLeg</span></code> contains all the details for the CommonLeg and payer details, roll convention, the fixing roll
convention, which day of the month the reset is calculated, the frequency period of the fixing, the fixing calendar and
the details for the reference index (source and tenor).</p>
<p>The <codeclass="docutils literal"><spanclass="pre">Calculation</span></code> class contains an expression (that can be evaluated via the ledger using variables provided and also
any members of the contract) and two schedules - a <codeclass="docutils literal"><spanclass="pre">floatingLegPaymentSchedule</span></code> and a <codeclass="docutils literal"><spanclass="pre">fixedLegPaymentSchedule</span></code>.
The fixed leg schedule is obviously pre-ordained, however, during the lifetime of the swap, the floating leg schedule is
regenerated upon each fixing being presented.</p>
<p>For this reason, there are two helper functions on the floating leg. <codeclass="docutils literal"><spanclass="pre">Calculation.getFixing</span></code> returns the date of the
earliest unset fixing, and <codeclass="docutils literal"><spanclass="pre">Calculation.applyFixing</span></code> returns a new Calculation object with the revised fixing in place.
Note that both schedules are, for consistency, indexed by payment dates, but the fixing is (due to the convention of
taking place two days previously) not going to be on that date.</p>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">Payment events in the <codeclass="docutils literal"><spanclass="pre">floatingLegPaymentSchedule</span></code> that start as a <codeclass="docutils literal"><spanclass="pre">FloatingRatePaymentEvent</span></code> (which is a
representation of a payment for a rate that has not yet been finalised) are replaced in their entirety with an
equivalent <codeclass="docutils literal"><spanclass="pre">FixedRatePaymentEvent</span></code> (which is the same type that is on the <codeclass="docutils literal"><spanclass="pre">FixedLeg</span></code>).</p>
Built with <ahref="http://sphinx-doc.org/">Sphinx</a> using a <ahref="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <ahref="https://readthedocs.org">Read the Docs</a>.
