Next Loan FpML WG Meeting: 22 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

1. Continue reviewing feedback points.

2. We are hoping to have some offline meetings to discuss some of the detailed feedback from GS and BofA this week and will be sending updated to the working group.

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: Tuesday, September 08, 2009 1:01 PM
To: loanwg@xxxxxxxx
Subject: RE: Loan FpML WG Meeting: 8 September 2009, 1000-1100EST (London Time: 3-4pm)

Minutes from 8 September 2009:

Based on the feedback items in the Agenda (we covered points 1-5), we have the following actions:

1. Add two new flags to the Repayment Notice. Scheduled/Unscheduled & Mandatory/Voluntary. Define any business validations that should be defined around these new flags. Ideally we want to make these fields required in which case the working group and the standards committee would need to approve.

2. Similar to the LoanContract structure, it has been proposed that the participationAmount should be introduced within the Letter of Credit. The amount field would change to a required choice block. The choice block would contain two elements: ‘amount’ and ‘participationAmount’.

3. Proposal to add a required ‘Prior Amount’ to the LC Termination message structure. This would be a backwardly incompatible change in which case the working group and the standards committee would need to approve.

4. The Prior LC and Post LC fields are full descriptors of the LC structure. This message was left purposely open ended. The message structure allows any change in the underlying LC to be denoted. No change or action pending regarding this message structure.

5. GS have made some recommendations around the rollover notice structure. Since these design proposals are quite detailed it makes sense to discus these offline and then present any structural changes back to the working group.

6. The working group had a discussion around market practices and it was agreed that we need a separate forum which is comprised of both business and technical members. This forum would work on the standardization of business processes. The example discussed: during the life cycle of a facility, in what situations should a new loan contract be defined vs amendment of an existing loan contract…? There are many of these issues which should be documented, discussed and hopefully standardized. The actions going forward:

a. Define the ‘working group’.

i. Business members from large institutions.

ii. Technology vendors and designers.

iii. US and European involvement.

b. Define a Standardized Business Process requirements/issues/resolutions document.

i. Include a list of business processes from both the Loan Servicing and Loan Trading spaces.

ii. Document should define the different variations (either by region, institution or both) of a given business process that exist today and a proposal for a standardized business process that all should endeavor to follow.

iii. A standardized legal framework (or the issues around having different frameworks) should be included within the document.

c. The FpML initiative is somewhat dependent on this document (especially in cases where many different permutations of a business process exist in the market today).

d. The FpML working group should be kept up-to-date on items discussed in this working group (via the loanwg@xxxxxxxx distribution list).

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, 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,

cid:image001.jpg@01CA1F8E.41C64390

Would an explicit dealCurrency / originalDealAmount be more clear?

cid:image002.jpg@01CA1F8E.41C64390

[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)…?

cid:image003.jpg@01CA1F8E.41C64390

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.
cid:image004.jpg@01CA1F8E.41C64390

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.

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: 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.

www.tendelta.com

+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.

www.tendelta.com

+1.917.582.4574 new york

+44.(0).7780.808732 london

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

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/08/09 06:48:00