Some thoughts on the new XSDs:
Deal:
Extends IdentifiedAsset directly rather
than reusing the previously defined DealSummary. Should Deal simply extend
/ include a DealSummary instead?
Guarantor and AdditionalBorrowers are
included as optional fields. Should these also be added to
FacilityDetails.model?
Instead of the optional choice structure,
would an explicit dealCurrency /
originalDealAmount be more clear?
Include syndication lead as optional
field?
Include credit agreement restrictions
(pro-rata only, restricted parties, restricted industries, etc.)?
Include agent contacts for deal?
Facility
Extends IdentifiedAsset directly rather than
reusing the previously defined FacilitySummary. Should Facility simply extend
/ include a FacilitySummary instead?
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.
Instead of just a defaultFlag, maybe have
a PerformingStatus section also to track history?
Include minimum constraints? (minimum
holding, minimum assignment, etc.)
Exceptions to the above (minimum waived if
selling entire position or assigning to eligible party, etc).
Include Consent types?
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
Include optional expiryDate (last date a draw
can be made) and terminationDate (facility cancelled before published maturity
date) fields?
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?
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.
Trade
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.
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?
From:
Sent: Monday, August 10, 2009 6:27
PM
To:
Subject: Next WG Meeting: 18
August 2009, 1000-1100EST (
Dial-in details:
US: + 1 (888) 481 - 3032
Intl: + 1 (617) 801- 9600
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
+44.(0).7780.808732
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
From:
Sent: Tuesday, August 04, 2009
11:43 AM
To:
Subject: RE: Loan WG Meeting: 4
August 2009, 1000-1100EST (
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
+44.(0).7780.808732
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