Note: The attachment should be saved
and renamed to .zip, you can then extract the supporting documentation.
Regards,
Bhavik Katira
CEO
TenDelta™
Fresh
insight. Pure logic.
+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.
Copyright
©2008-2009. TenDelta™ LLC (US), TenDelta™ Limited (UK). All Rights Reserved.
From: loanwg@xxxxxxxx
[mailto:loanwg@xxxxxxxx] On Behalf Of Bhavik Katira
Sent: Tuesday, September 08, 2009 1:41 AM
To: loanwg@xxxxxxxx
Subject: Loan FpML WG Meeting: 8 September 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
Agenda
Review feedback from WG
members:
1.
[Repayments (GS)] The Scheduled and Mandatory/Voluntary
repayments use the same message but I don't see anything that allows us to
distinguish between the different types (don't think Refusal Allowed is for
this purpose). Am I missing the flag that is used to differentiate?
[BK] There is no flag currently that differentiates between the two. Is
there a business driver that requires us to be able to differentiate between
the two...? To keep the standard backwardly compatible, we would need to add an
optional flag unless the group agrees that this should be required.
2. [LC
Issuance (GS)] The notice requires a "Original LC Amount" which
is the original at time of issuance. It also requires "Global LC
Amount" which is current value at a global level. Firstly do we need
original amount? Surely that should always remain the same since this is
the issuance notice. Secondly we need the lenders share but don't have a place
for this. To me it seems like we just need 1 amount field and it should
be of type "ParticipationAmount".
[BK] Agreed. Firstly, the business group wanted to define the original
global amount of the LC in the core structure.
The amount field was initially introduced to describe the current global LC
amount. The same argument as to whether we should have participation amounts
was introduced with loan contracts in the last version. Our solution was to
introduce a choice block which allows the sender to choose between stating the
current global amount (as currently designed) vs a participation amount. For
design consistency, I would propose we add this choice block here also…?
3. [LC
Termination (GS)] The requirements document specifies that we should have
the "Prior Amount" on the event. This is important sine the
"Current Amount" will always be 0. However, the 4.6 LCWD
schema does not have this field. Is this an omission on the schema?
[BK] Good catch, there is an inconsistency here. We have an optional
Facility Commitment Position structure in the header (which contains prior and
current participation amounts). We also have an optional current amount in the
body of the message. The requirement states that we should have a required
Prior Amount. Need to confirm whether this still stands…? Also, if the optional
current amount is seen as superfluous then we should mark it as deprecated.
4. [LC
Amendment (GS)] The schema requires the "Prior LC". What is
the reason for this and should it be an optional field instead?
[BK] The business working group agreed that is was important to understand
what has changed during the LC amendment. The mmost generic way to represent
this was to show attributes of the LC before and after an amendment.
5. [Rollover
(GS)]
(i) Roll Into Existing Contracts : On contract maturity roll into an
existing contract. Currently the rollover event only allows rolling over
into a brand new contract. Are we going to support this? Would it
require an additional section on the rollover for "Upsized" contracts
with LoanContractSummaries identifying them?
[BK] The assumption in the rollover design is that the ‘maturingLoanContracts’
and ‘newLoanContracts’ are simply two arrays of loan contracts. I believe the
scenario you mention is possible – there is nothing stopping us from describing
a loan contract in both sections if there were ‘merges’ going on. Maybe the
name ‘newLoanContracts’ is somewhat misleading…?
(ii) Conversion on Rollover : If the rate index of the contract
being rolled into differs from the original then we probably want to flag this
as a conversion. We could have a standard rollover and conversion taking
place if the contract is being split.
[BK] I’m not sure why we need to explicitly tag the rollover as a
conversion…? Also, if we flag it, then it will be interesting to see what we
should flag, since the structure allows many different combinations of rollover
types to be represented. Is there an argument that a ‘conversion’ might be a
separate business event…?
(iii) Mid Contract Conversion : Also a conversion can take place mid
contract which results in some (or all) of the contract principal moving to
another contract. The contract being moved to may already exist or may
need to be newly created and it's the rate index that would differ from the
original contract (e.g. LIBOR to PRIME conversion). In this case we need
to identify the date on which the conversion is taking place since it's not
contract maturity. We also need to know how much is being converted from
the original contract.
[BK] We have a noticeDate, but this represents the date on which the message
is officially sent. It would make sense to include a rolloverDate here – I’m
wondering what the WG thinks of this…?
By listing the full details of all the existing loan contract amounts before
and after the rollover, surely we would know exactly how much has shifted into
the new loan contracts…?
6. [‘Conversion
Notice’ Proposal (GS)]
Conversion Notice : This is to illustrate what I think we may need based
on the points I made in my original email regarding the rollover. In fact
I think we could just have a single structure since the one I've added also
supports the normal rollovers, splits and merges. We would be able to
identify that this is a conversion because the optional conversionAmount field
would be populated. Alternatively we could also add another flag to each
contract saying it's a result of a conversion.
[BK] The structure proposed is attached to this email.
7. [‘Commitment
Adjustment’ Proposal (GS)]
[BK] The structure proposed is attached to this email.
8. [Deal/Facility
(BofA)]
Deal: Extends IdentifiedAsset directly rather than reusing the previously
defined DealSummary. Should Deal simply extend / include a DealSummary instead?
Facility: Extends IdentifiedAsset directly rather than reusing the previously
defined FacilitySummary. Should Facility simply extend / include a
FacilitySummary instead?
[BK] I remember trying to decide between the two options. Do you see a
distinct advantage of extending or embedding the deal/facility summary object.
They are both ‘assets’. The deal summary is really just the identifier (at its
core). Let’s discuss.
9. [Borrower/Guarantor
(BofA)]
Guarantor and Additional Borrowers are included as optional fields. Should
these also be added to FacilityDetails.model?
[BK] Since these scenarios do exist we can certainly add them pending
business/technical working group agreement.
10. [Deal
Currency/Amount (BofA)]
Instead of the optional choice structure,
Would an explicit dealCurrency /
originalDealAmount be more clear?
[BK] The name change would be a non-backward
compatible change but we can request through the FpML committee. I agree that
the structure you suggest is clearer.
11. [Syndication
Lead (BofA)]
Include syndication lead as optional field?
[BK] Can review this requirement with the business working group.
12. [Credit
Agreement Details (BofA)]
Include credit agreement restrictions (pro-rata only, restricted parties,
restricted industries, etc.)?
[BK] We can certainly make a list of these and start to add them to the deal
and/or facility structure. We need to prioritize this work together with everything
else pending.
13.
[Contacts (BofA)]
Include agent contacts for deal?
[BK] The contact capture issue came up with the business working group.
There might be a requirement to have a generic structure to include together
with party information.
14. [Facility
Base Type (BofA)]
Rather than a facility type enum, would a facility substitution group be
better? This would allow for more flexible modeling of elements per
facility type that aren't necessarily common to all facilities. It would
also mean less changes to the base facility type in the future and more easily
allow adding new facility types if market practice changes.
[BK] We can certainly explore this design alternative. I suggest we do this
offline and present back to the working group.
15.
[Default Status (BofA)]
Instead of just a defaultFlag, maybe have a PerformingStatus section also to
track history?
[BK] Is there a business driver for this requirement...? Does it affect
another schedule within our structures…? (e.g. Pricing, Margin levels etc.)
Also, if we were to model this, should we use consistent period definitions
(just like in accruals etc)…?
16. [Minimum
constraints (BofA)]
Include minimum constraints? (minimum holding, minimum assignment, etc.)
Exceptions to the above (minimum waived if selling entire position or assigning
to eligible party, etc).
[BK] Agreed – to be confirmed by the business/technical working group.
17. [Consent
Types (BofA)]
- No Consent Required
- Consent Always Required
- Consent granted if Buyer is already an LOR
- Consent granted if Buyer is an Affiliate of existing LOR
- Consent granted if Buyer is an approved fund of existing LOR
- Consent required from the existing pool of lenders, typically for a new
Letter of Credit or Swing-line lenders
[BK] Agreed – to be confirmed by the business/technical working group. I am
assuming the proposal is to add this as an informational field or are we
suggesting that we perform validation using these values…?
18. [Additional
Facility Dates (BofA)]
Include optional expiryDate (last date a draw can be made) and terminationDate
(facility cancelled before published maturity date) fields?
[BK] Agreed – to be confirmed by the business/technical working group.
19. [Multi-Currency
Flag (BofA)]
Do we need more detail than just multi-currency flag? Do we need to
delineate allowed currencies? do we need a master FX rate back to the
deal currency?
[BK] Agreed. We have discussed this previously but decided that it wasn’t a
priority. If there is a proposed structure we can certainly investigate once
the initial trading structures are defined.
20. [Sublimits
(BofA)]
Sublimits are missing in the facility description. These can be very
informative and should be included as optional fields. We should also consider
including sublimit participations at the lender level as optional fields on the
agent notifications.
[BK] Agreed – to be confirmed by the business/technical working group.
21. [LoanContract/LC
Trade Ids (BofA)]
LcTradeId and LoanContractTradeId - do other implementors currently have
these as discrete ids in the current systems? Not comfortable including
these they're not tracked at this level in the internal trading
application. Not sure about the entire LcTrade and LoanContractTrade structures
to be honest.
[BK] We should pose this question out to the technical working group. I
would have thought that in any assignment transfer, the parties involved would
have to communicate the amount of outstanding contracts within the traded
facility. I guess the question is around whether implementers simply calculate
these values or store the trade-level contract amounts…?
Let’s investigate.
22. [Trade
Structure Design (BofA)]
The trade structures should probably follow the substitution strategy used in
fpml:Trade. fpml:Trade and fpml:Allocations need some modifications to
effectively model loans though. The proposed allocatedMultiFacilityTrade
and TradeAllocation structures get complicated quickly with all the nesting.
They will be difficult to implement. TradeAllocation seems to have a redundant
structure. Is this intentional?
[BK] Actually, I the TradeAllocation object was left in the xsd file but we
shifted to using only the AllocatedMultiFacilityTrade structure.We can
certainly perform a parallel design effort to see how a substitution structure
would compare and then decide which way to go.
23. [Contact/Remittance
Details (BarCap)]
There are some additional data fields which have been requested regarding
contact details and payment instructions. These should be discussed in both the
business and technical working group.
[BK] See attached NoticeExamples.doc and AdditionalNoticeInformation.xls.
24.
[Cancel/Modify Structures (Business Requirement)]
[BK] The business working group agreed to increase the priority of modification
and cancellation messages.
Modification:
- Add a version id to the existing structure…?
- Add a flag to define the message is new/modification…?
Cancellation:
- Lightweight message containing identifiers pointing back to the original
message (event id)…?
Regards,
Bhavik Katira
CEO
TenDelta™
Fresh
insight. Pure logic.
+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.
Copyright
©2008-2009. TenDelta™ LLC (US), TenDelta™ Limited (UK). All Rights Reserved.
From: loanwg@xxxxxxxx
[mailto:loanwg@xxxxxxxx] On Behalf Of Bhavik Katira
Sent: Monday, August 10, 2009 6:27 PM
To: loanwg@xxxxxxxx
Subject: Next WG Meeting: 18 August 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
Agenda
-
Review updated trade structures.
-
Review cancel/modify structures.
-
Review feedback from WG members.
Regards,
Bhavik Katira
CEO
TenDelta™
Fresh
insight. Pure logic.
+1.917.582.4574 new york
+44.(0).7780.808732 london
TenDelta™
provides business process consulting, technology design/implementation &
education services, specializing in the Syndicated Loan Market. Entrusted with
engineering innovative & logical solutions, we endeavor to deliver timely,
robust, cutting-edge solutions.
TenDelta™
Limited is a company registered in England & Wales. The Company registered
number is 06285903. The registered office is 3 Francis Road, Harrow, Middlesex,
HA1 2QZ, United Kingdom.
From: loanwg@xxxxxxxx
[mailto:loanwg@xxxxxxxx] On Behalf Of Bhavik Katira
Sent: Tuesday, August 04, 2009 11:43 AM
To: loanwg@xxxxxxxx; Rosalind.Greener2@xxxxxxxxxxxxxxxxxxx
Subject: RE: Loan WG Meeting: 4 August 2009, 1000-1100EST (London Time:
3-4pm)
Minutes from 4 August 2009
Meeting:
-
Scope & priority
o
Updated to include
modification/cancellation messages earlier. Next steps: discuss the requirements
within the business working group and understand what modifications can be
performed with respect to each of the notification messages that have already
been defined. Document the specific requirements (if any) within the business
requirements document.
o
Cash flow messages.
The concept here was to include a generic structure which basically defines the
overall cash flow which is taking place on any business event. This was
mentioned as something that participants are “unable” to go-live without.
The point of FpML having free-form fields was mentioned – this should allow
participants to still communicate any details which might not have been fully
specified as yet.
-
Review of the
updates to the requirements document (v1.39).
o
Trade structure
presented:
§
Deal Trade
§
AllocatedMultiFacilityTrade
§
MultiFacilityTrade
§
FacilityTrade
§
LoanContractTrade
§
LcTrade
§
DelayedCompensation
o
We should
potentially look to trying to integrate the loan trade structure more closely
with the FpML OTC derivatives generic trade structure.
o
Within the interest
accrual and fee accrual sections of the trade structure we should have a
delayed compensation amount for each accrual. These amounts will correspond to
the overall delayed compensation associated with the facility being traded.
-
Usage of Identifiers
for all message types.
o
We should publish a
document which outlines the usage of the various identifiers within the current
message structures e.g. Message Id, Event Id, Conversation Id.
o
An additional option
was to include a version identifier within a message to enable better tracking
of modifications/cancellations in the future.
Regards,
Bhavik Katira
CEO
TenDelta™
Fresh
insight. Pure logic.
+1.917.582.4574 new york
+44.(0).7780.808732 london
TenDelta™
provides business process consulting, technology design/implementation &
education services, specializing in the Syndicated Loan Market. Entrusted with
engineering innovative & logical solutions, we endeavor to deliver timely,
robust, cutting-edge solutions.
TenDelta™
Limited is a company registered in England & Wales. The Company registered
number is 06285903. The registered office is 3 Francis Road, Harrow, Middlesex,
HA1 2QZ, United Kingdom.
No virus
found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.49/2294 - Release Date: 08/10/09
18:19:00
No virus
found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.83/2352 - Release Date: 09/07/09
18:03:00