Loan FpML WG: PIK and Fee Tier Modelling

Updated Agenda:

1. Deliverables for the 5.x series… what do we need to get done by the next release…?

a. Two streams of development (i) updated designs for existing released notifications and (ii) continue work on trading messages.

2. Review where we were as of the last meeting. Any feedback…?

a. Feedback on LC’s from December

i. The annotation description should be potentially changed: Currently it reads "The number of calendar days before the end of the LC that the borrower must state whether they would like to extend the LC." but it should potentially be "The number of calendar days before the end of the LC that the borrower must state that they would not like to extend the LC."

ii. extensionPeriod: This should state by how much the LC should be extended. This is of type decimal but should be of type Period.

b.      Utilization Fee Pricing Change. There is the concept of a rate band that applies to utilization fee rates and needs to be communicated when a re-pricing occurs. We’ve not modeled this so far from what I can see. For example:
Utilization Fee Rate:
Percentage From: 33.3%               Percentage To: 66.7%                    Fee Rate: .075000
Percentage From: 66.7%               Percentage To: 100%                      Fee Rate: .150000
As such I think we need to enhance the OnGoingFeeRateChange structure to have the optional bands. We could therefore add following:
rangeStartPercent – Leverage ratio percentage for the start of this band
rangeEndPercent – Leverage ratio percentage for the end of this band

c. Paydown Interest. We have the ability to process paydown interest using the InterestPaymentNotice. However, I was wondering whether we should have a flag that allows us to distinguish that it is Paydown Interest.

d. PIK Interest. PIK really consists of 3 concepts and we need to decide how this is modelled by our messages.
- PIK calculation needs to be specified showing accrual over the contract
- We need to upsize an existing contract or create a new contract for the PIK amount (same level of detail as a drawdown notice)
- We need to increase the commitment on facility by the PIK amount.
Our current messages address some of this but we still have a lot to consider. The thing that makes this complex is that contract being upsized can be different to the one being accrued over, and could be on a different facility altogether. Our messages currently only allow 1 contract and facility to be referred to.
The scenarios we need to handle are PIK increase being applied to:
- Existing contract on same facility
- New contract on same facility
- Existing contract of different facility
- New contract on different facility
It almost seems to me like we need to do PIK in 2 steps. 1 to detail accrual, and the other to have a drawdown which is of type PIK and therefore does not result in any cash but does result in commitment increase.
Finally we may also need the ability to mark the PIK event as PIK Toggle. Not sure about this one.

3. Business validation rules – volunteers…? Also, some feedback regarding published rules:

a. Most recently distributed “FpML LoanValidations Rules spreadsheet v1.6” has a tab v4-5 with business validations for PriceChangeNotice and Letter of Credit Notices. However, I could not find these rules posted on the fpml website in the latest recommended version FpML 4-6 Build 7. Were these rules finalized by the loan business working group…?

b. Moreover, in the spreadsheet, rules ln-30 and ln-31 are for the OnGoing Fee Notice but on the fpml website these rules are different. I think the spreadsheet rules were substituted sometime ago by what is posted on the site ( Facility Notice/facilityCommitmentPosition...). Please confirm which one is correct.

4. Next steps, in terms of design.

Regards,

Bhavik Katira

CEO

TenDelta™

Fresh insight. Pure logic.

www.tendelta.com

+1.917.582.4574 new york

+44.(0).7780.808732 london

TenDelta™ provides business process consulting, technology design & education services; specializing in the Syndicated Loan Market. Entrusted with engineering innovative & logical solutions; we endeavor to deliver timely, robust, cutting-edge solutions.

From: loanwg@xxxxxxxx [mailto:loanwg@xxxxxxxx] On Behalf Of Bhavik Katira
Sent: Monday, January 25, 2010 11:58 AM
To: loanwg@xxxxxxxx
Subject: Loan FpML WG Meeting: 26 January 2010, 1000-1100EST (London Time: 3-4pm)

Dial-in Details

US: + 1 (888) 481 - 3032

Intl: + 1 (617) 801- 9600

UK: 0800 904-7961

Participant Code: 28413758

Agenda

5. Deliverables for the 5.x series… what do we need to get done by the next release…?

a. Two streams of development (i) updated designs for existing released notifications and (ii) continue work on trading messages.

6. Review where we were as of the last meeting. Any feedback…?

7. Business validation rules – volunteers…?

8. Next steps, in terms of design.

Regards,

Bhavik Katira

CEO

TenDelta™

Fresh insight. Pure logic.

www.tendelta.com

+1.917.582.4574 new york

+44.(0).7780.808732 london

From: loanwg@xxxxxxxx [mailto:loanwg@xxxxxxxx] On Behalf Of Bhavik Katira
Sent: Wednesday, December 09, 2009 12:10 PM
To: loanwg@xxxxxxxx
Subject: Further updates on 9-Dec-2009

Some further updates based on business group feedback today and also further design input. This is only a proposal, please try and review and provide feedback…

- CashFlowPayment(s) renamed to CashFlow(s). Since these are actually cash flows and not necessarily payment per say…

- GenericCashFlow.model added. This is now used on the header section of the FacilityNotice and appears on all notices. The business group stated that although netting occurs, it does not happen all the time, so having a standard cash flow section on all notices makes sense. The GenericCashFlow.model contains a flag and an optional set of cash flows. The flag is supposed to denote whether there will be an explicit payment associated with the notice or whether there will be a separate payments (based on a cash flow notice which will be sent separately).

- I am unsure whether we should make the cash flow section optional on the facility notice header i.e. it will only get populated when there is a payment associated with the notice…?

- CashFlowNotice renamed to NetCashFlowNotice. This makes sense since it will be used to designated net cash flows only (if we keep the cash flow as part of the standard notices).

The fpml-loan.xsd has also been re-organized into separate sections like abstract types, notices, loan instruments and re-usable concrete types. Eaqch section is ordered alphabetically (by name of the object). Please let me know if this makes sense or if you have any other ideas about making the overall schema easier to navigate.

Regards,

Bhavik Katira

CEO

TenDelta™

Fresh insight. Pure logic.

www.tendelta.com

+1.917.582.4574 new york

+44.(0).7780.808732 london

From: loanwg@xxxxxxxx [mailto:loanwg@xxxxxxxx] On Behalf Of Bhavik Katira
Sent: Tuesday, December 08, 2009 11:48 PM
To: loanwg@xxxxxxxx
Subject: RE: Loan FpML WG Meeting: 8 December 2009, 1000-1100EST (London Time: 3-4pm)

Minutes & Update

All changes reviewed and agreed. See attached schemas for further updates.

Additional design changes:

- Rate set notice (Drawdown Notice), the drawdown payment structure has been made optional. This will allow the rate set notice to be used on a stand-alone basis (e.g. multiple re-pricings on a related to a rollover).

- Cash flow notice

o Business events section introduced. Expanded with a business event type – do we agree this would be useful…? Combination of business event id and message id assures that we are referring to the correct version of the underlying message/event.

o Cash flow payments section introduced. Multiple cash flow sections allow for multi-direction payments to occur. Is this necessary…?

- PIK documentation to be provided by Ann Taylor

- Discussion about whether we should have a more explicit relationship between old and new loan contract during a rollover. We currently do not. Agreed that maybe we should have this discussion with the business group but for now we are keeping the design as is (decoupled loan contracts during rollover).

With respect to release timings, the FpML organization is currently working on 4.7 and 5.0 in parallel. As a result of the amount of changes we have made during the last design iteration (some of which are backwardly incompatible), it seems prudent for us to release in the 5.x series. 5.0 is currently at the 4^th working draft stage (as of mid-December) and may move to Last Call Working Draft by mid-Jan.

The Loan Working Group decided that we will review where we are by mid-Jan, if we are not ready then there will be NO LOAN schema included in 5.0. It is important for us to ensure that the code released in the 5.x series is properly tested and reviewed and will not require further incompatible updates/changes as we progress through the 5.x versions.

For 5.0, we will be looking at a Q1 recommendation and 5.1 will be a Q2 recommendation.

Regards,

Bhavik Katira

CEO

TenDelta™

Fresh insight. Pure logic.

www.tendelta.com

+1.917.582.4574 new york

+44.(0).7780.808732 london

From: loanwg@xxxxxxxx [mailto:loanwg@xxxxxxxx] On Behalf Of Bhavik Katira
Sent: Tuesday, December 08, 2009 12:06 AM
To: loanwg@xxxxxxxx
Subject: Loan FpML WG Meeting: 8 December 2009, 1000-1100EST (London Time: 3-4pm)

Dial-in Details

US: + 1 (888) 481 - 3032

Intl: + 1 (617) 801- 9600

UK: 0800 904-7961

Participant Code: 28413758

New schema attached.

Agenda

1. AmountAdjustment introduced.

a. Used in the currentContracts section of the Rollover Notice.

b. Used in the Commitment Adjustment Notice.

c. Used in L/C Balance Change Notice. Removed Prior Amount to be consistent with other notices.

2. Created a new MarginRateChangeTypeEnum. Introduced into the MarginRateChange Notice to define whether the margin rate change is associated with the Cash or PIK margin.

3. Rate Set Notice with respect to Rollovers. If we make the drawdownPayment section optional then it only leaves the actual event types as a required field on the entire notice. Discuss design options…

4. Combination messages in a single structure. It is essential that any combinational messages are designed for the purposes of when the resulting message is a valid business scenario rather than for ‘volume’ reasons – discuss. E.g. If there are 10 interest payments then what is the value associated with combining the messages in a single ‘structure’ (if the header is not too ‘heavy’)…?

5. Cash flow message types. Initial design idea presented containing a standalone message which contains references to other business events. Let’s discuss this potential design.

a. Should we capture the individual business event amounts, together with the overall ‘net’ payment amount…?

b. Should there be multiple payments in multiple directions…? Party A pays X to Party B and Party B pays Y amount to Party A.

c. Should there be other parties involved in the payment/cash flow itself…?

We also need to discuss the next steps with respect to release timings. The FpML group is working towards 4.7 and simultaneously a 5.0 release. We are at a stage where we have made many changes to many notices (some of which are backwardly incompatible). It seems this would be a good point for us to move across to a 5.x release.

Regards,

Bhavik Katira

CEO

TenDelta™

Fresh insight. Pure logic.

www.tendelta.com

+1.917.582.4574 new york

+44.(0).7780.808732 london

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.716 / Virus Database: 270.14.107/2564 - Release Date: 12/14/09 14:40:00

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.730 / Virus Database: 271.1.1/2643 - Release Date: 01/25/10 02:36:00