RE: Proposals for Loan FpML WG Meeting: 9 March 2010

["Bhavik Katira" <bhavik.katira@xxxxxxxxxxxx>]

Mazhar, thanks for sending out your detailed proposal. I have some
feedback/points/questions. Let's discuss tomorrow.

PRICING CHANGE NOTICE
1. Should we introduce a 'FeeTier' object (if we think this can be
reusable)...?
2. Is it not possible to have a schedule within On-Going Fees...? (Year 1 -
2%, Year 2 - 2.25% etc.) If so then we may want to have a structure which
can handle both tiers and schedules (possibly simultaneously?).

INTEREST PAYMENT
3. Let's discuss the 'optionality' for the accruals.

TRADING NOTICES
4. 'When Issued' - should we capture this flag be on the deal structure
itself rather than the deal trade...?
5. Delayed Comp - So we are suggesting that we should capture a flag at the
deal trade level and also the details within the Facility Trade section...?
6. Can we reuse one-off fees to model Transfer/Assignment fees...? I guess
we have the complexity of who pays whom etc...?
7. Where you state 'utilizedTrade', were you referring to the
'unutilizedTrade' amount (available to draw?)
8. Should we have optional pointers between the TradeCommitmentChange object
and the actual underlying business event...?
9. We might want to introduce an object which contains both traded and
settled amounts (possible a 'model')...?
10. Does it make sense to potentially reuse the Repayment structures from
the Repayment Notice, within the Facility Trade structure...? We could
introduce the concept of a price within the core repayment structure. We may
be able to provide a solution where implementers can reuse parsing code.


A new version (v1.42) of the document will be sent out once we have reached
consensus on the outstanding points.

Regards,

Bhavik Katira
CEO

TenDeltaT
Fresh insight. Pure logic.

www.tendelta.com

+1.917.582.4574 new york
+44.(0).7780.808732 london

TenDeltaT 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 results.

Copyright C2008-2009. TenDeltaT LLC (US), TenDeltaT Limited (UK). All Rights
Reserved.

-----Original Message-----
From: loanwg@xxxxxxxx [mailto:loanwg@xxxxxxxx] On Behalf Of Iqbal, Mazhar
Sent: Friday, March 05, 2010 1:05 PM
To: 'loanwg@xxxxxxxx'
Subject: Proposals for Loan FpML WG Meeting: 9 March 2010

Hi Everyone,
 
I am attaching an updated version of the loans FpML schema for review next
Tuesday on our working group call.  It contains following changes:
 

*	PricingChangeNotice - For the OnGoingFeeRateChange structure I'
ve added a choice between a simple price and a tiered price.  This will
allow support for scenarios such as utilization fee.

 

*	InterestPaymentNotice - Last time we discussed adding choice
between an amount or PIK amount.  We should also consider whether some of
the accrual structures should be choices as well.

 

*	Trading Structures - I am suggesting the following changes to
the trading structure to fully model the trades.

 
 
DealTrade 
 
Added following attributes (don't think we should use the otherTradeTerms
field)

*	actualSettlementDate - Actual date that the settlement takes
place.  Only populated once settlement happens.
*	whenIssuedFlag - Need to identify when issued trades.  i.e.
traded before the credit agreement has been signed. 
*	breakCostsFlag - Need to identify if break costs should apply
*	delayedCompensationFlag - Need to identify if delayed
compensation will apply (since by default it does)

 
Changed following attributes

*	parDistressedFlag - renamed to documentationType and created
DocumentationTypeEnum with values "Par" and "Distressed".  I think this is
better way to model this concept.
*	On buyerCounterparty and sellerCounterparty loanPartyContactType
had attribute pricingChangeReasonScheme which looks like a mistake.  I
renamed to loanContactPartyTypeScheme

 
Additional suggestions

*	Can we abbreviate the AccrualSettlementEnum used by
accrualSettlemenType as follows

*	Settled without Accrued Interest - SWOA
*	Settled with Accrued Interest - SWA
*	Trades Flat - Flat

*	Should we add Transfer Fee information?

 
 
 
FacilityTrade
 
Added following attributes

*	settledCommitmentAmount - The amount that we actually settle.
Due to permanent commitment adjustments/ permanent paydowns this can differ
from the tradedCommitment
*	utilizedTrade - This represents the available to draw component
of revolvers and delayed draw term loans.  This allows us to represent the
amount as well as the contribution to the purchase price.
*	commitmentChanges  - We need to represent permanent commitment
changes  and how they impact the purchase price.  To do this I've added
following:

*	commitmentChange - This represent the permanent change to the
commitment amount
*	permanentReductionCredit - If this is only a change in unfunded
commitment then this represents the credit for the change
*	loanContractRepayment - This represents the permanent principal
repayments and the reductionCredit that results.  Also I identify pikAmount
clearly since that does not get a credit.  Finally paydowns can be done at a
price different to par so I've included the optional field.
*	loanContractCapitalization - Clearly identity the PIK events
that result in commitment increases.  These do not get and credit.

 
Changed following attributes

*	tradeAmount - renamed to tradedCommitmentAmount so we know it is
the original amount traded

        
 
LoanContract
 
Added following attributes

*	pikAmount - Amount of PIK that has capitalised onto the contract
*	contractProceed - Represents the contribution to the purchase
price.

 
Changed following attributes

*	interestAccrualSchedule made optional
*	tradeAmount - This excludes the PIKAmount.  So if you want
entire contract amount the 2 must be summed.

 
Additional suggestions

*	The delayedCompensation structure does not seem to have correct
cardinality.  We'll need to review this.

 
 
LcTrade
 
Added following attributes

*	lcProceed - Represents the contribution to the purchase price.

 
Changed following attributes

*	lcAccrualSchedule made optional
*	lcTradeId made optional

 
 
 
Regards.
Mazhar.
 
 

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2726 - Release Date: 03/06/10
02:39:00