Message-ID: <23850612.1075856502959.JavaMail.evans@thyme> Date: Thu, 19 Apr 2001 09:28:00 -0700 (PDT) From: vince.kaminski@enron.com To: vkaminski@aol.com Subject: RE: D&B Contact Names Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: Vince J Kaminski X-To: vkaminski@aol.com X-cc: X-bcc: X-Folder: \Vincent_Kaminski_Jun2001_4\Notes Folders\'sent mail X-Origin: Kaminski-V X-FileName: vkamins.nsf ---------------------- Forwarded by Vince J Kaminski/HOU/ECT on 04/19/2001 04:28 PM --------------------------- From: Iris Mack/ENRON@enronXgate on 04/19/2001 03:22 PM To: Scott Salmon/EU/Enron@Enron, Amitava Dhar/Corp/Enron@ENRON cc: Craig Chaney/HOU/ECT@ECT, Mike Mumford/LON/ECT@ECT, Eric Kirkpatrick/EU/Enron@Enron, Richard Brent/EU/Enron@Enron, Ben Parsons/LON/ECT@ECT, George Albanis/LON/ECT@ECT, Vasant Shanbhogue/ENRON@enronXgate, Vince J Kaminski/HOU/ECT@ECT Subject: RE: D&B Contact Names Hi again, As, I stated is a prior emails, the contact details for the RiskCalc folks are as follows: 1. Marc Brammer Director of Strategic Sales tel: 800.523.2627, x5706 mbrammer@MoodysRMS.com 2. Neal Clark Vice President Tel: 800.523.2627, x5701 nclark@MoodysRMS.com Neal said that he would be willing to set up a meeting between us and their quants to better understand their model, the various inputs and whether or not the model can be tweaked for less than the 17 specified inputs. Let me know if you guys wish to have Neal set up a conference between Moody's quants and Enron folks in Houston and London. Ciao, Iris -----Original Message----- From: Salmon, Scott Sent: Thursday, April 19, 2001 3:00 PM To: Mack, Iris; Dhar, Amitava Cc: Chaney, Craig; Mumford, Mike; Kirkpatrick, Eric; Brent, Richard; Parsons, Ben; Albanis, George Subject: RE: D&B Contact Names Iris/Amitava, I may have already said this, but we've had so many e-mails and telephone calls flying back and forth that I wanted to make sure I at least got this much out to you. Clearly, I would like you to set up the meeting with the RiskCalc gurus to dig deeper into their methodology (as much as they'll tell) and the impact of missing variables and any other idiosyncracies the model may have. Also try to get a better feel for how well they think the model extends to other countries. I know from a previous conversation with Lea Carty and reading about the model that it was calibrated off North American names but they suspect it might extend to other countries. Conversely, I know they are working efforts within Moody's Risk Management Services to develop private (and probably public) firm models specific to regions. One they mentioned was Australia and also within Western Europe. Data, as always, was the issue. See if the quants have any perspective on their success/plan in that area. Lastly, we truly appreciate the aggressive efforts you both have made toward pushing off this private model initiative and I'm very confident we'll be able to nail a firm plan down upon receipt of either D&B and/or Experian data. Cheers, Scott ---------------------- Forwarded by Scott Salmon/EU/Enron on 19/04/2001 20:51 --------------------------- Mike Mumford@ECT 19/04/2001 17:55 To: Scott Salmon/EU/Enron@Enron cc: Subject: RE: D&B Contact Names ---------------------- Forwarded by Mike Mumford/LON/ECT on 19/04/2001 17:59 --------------------------- From: Iris Mack/ENRON@enronXgate on 19/04/2001 09:23 CDT To: Mike Mumford/LON/ECT@ECT cc: Amitava Dhar/Corp/Enron@ENRON Subject: RE: D&B Contact Names Hi, Two RiskCalc sales people made a presentation this week about their product. They stated that they could set up a meeting with their quants and our people to discuss the model input and what happens if we have less than 17 inputs. Regards, Iris -----Original Message----- From: Mumford, Mike Sent: Thursday, April 19, 2001 1:37 AM To: Mack, Iris Subject: RE: D&B Contact Names Ooops... part II. I just threw out 12 as a number for something we might develop... it's really not based on anything. We know 17 will work for pre-packaged programs. We also know there will be a great number of names with less than the full 17... I assume we would pursue another model (internal or external) to provide probably less accurate numbers but at least available for names with fewer inputs. Mike From: Iris Mack/ENRON@enronXgate on 18/04/2001 15:02 CDT To: Mike Mumford/LON/ECT@ECT cc: Amitava Dhar/Corp/Enron@ENRON, Scott Salmon/EU/Enron@Enron, Eric Kirkpatrick/EU/Enron@Enron Subject: RE: D&B Contact Names Hi Mike, Thanks for your email. What do you mean by "buying blind all major data associated with these specific DUNS numbers"? I am puzzled about why you would be looking at 17 vs 12 fields. I know RiskCalc requires 17 inputs and seem to apply that the model does not work for less than 17. Yesterday the RiskCalc sales people could not guarantte that their model would work for less than the required 17 data inputs. They suggested that this would be a question to direct towards their quants who developed the model. Regards, Iris -----Original Message----- From: Mumford, Mike Sent: Wednesday, April 18, 2001 1:20 PM To: Mack, Iris Cc: Dhar, Amitava; Salmon, Scott; Kirkpatrick, Eric Subject: RE: D&B Contact Names Iris, Thanks. After our meeting we stuck around to discuss things a little further. Specifically with respect to global counterparty names... we have DUNS cross-references on about 70 of active names (13k out of 18.5k). We could greatly accellerate purchase of some useful data by buying blind all major data associated with these specific DUNS numbers. Pro - Data gets in on names we know we want to review ASAP, but without resolution on which specific fields are most useful. We also get to test for completeness of data (how many have all 17 fields... how many have only 12 of which fields, etc.). Con - Costs could be significantly higher... buying info we don't know we need (converse of buying only the 17 fields doesn't seem best answer). We would end up buying additional info later... overhead costs and piecemeal buying will increase costs. IT development time would be greatly increased... multiple file formats... developing to unknown maximum size, etc.... redoing when more data is purchased. Any thoughts. Mike