<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Microsoft Excel and Treasury Management</title>
	<atom:link href="http://ozrisk.net/2009/01/15/microsoft-excel-and-treasury-management/feed/" rel="self" type="application/rss+xml" />
	<link>http://ozrisk.net/2009/01/15/microsoft-excel-and-treasury-management/</link>
	<description>Risk Management in Australia</description>
	<lastBuildDate>Wed, 30 Nov 2011 12:41:58 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Jacques Chester</title>
		<link>http://ozrisk.net/2009/01/15/microsoft-excel-and-treasury-management/#comment-26778</link>
		<dc:creator><![CDATA[Jacques Chester]]></dc:creator>
		<pubDate>Mon, 16 Feb 2009 07:35:46 +0000</pubDate>
		<guid isPermaLink="false">http://ozrisk.net/?p=490#comment-26778</guid>
		<description><![CDATA[Just wanted to drop by and say that the link to EuSprig was pure gold.]]></description>
		<content:encoded><![CDATA[<p>Just wanted to drop by and say that the link to EuSprig was pure gold.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: penguinunearthed</title>
		<link>http://ozrisk.net/2009/01/15/microsoft-excel-and-treasury-management/#comment-26739</link>
		<dc:creator><![CDATA[penguinunearthed]]></dc:creator>
		<pubDate>Mon, 26 Jan 2009 02:19:06 +0000</pubDate>
		<guid isPermaLink="false">http://ozrisk.net/?p=490#comment-26739</guid>
		<description><![CDATA[I once had a spreadsheet to review - I was the independent consultantreviewing it for accuracy. It had been built to the edges of spreadsheet performance, and then the person who built it suddenly realised that they had a whole extra piece of calculation to put in.

It ended up being 50 Meg (really!), and excel just couldn&#039;t cope with the amount of data. Somewhere deep in the middle of the main spreadsheet (somewhere around the 20,000th row) the spreadsheet just crashed, and the calcs from that part were complete rubbish.

We ended up making them take bits out and put them in Access before we could sign off, which didn&#039;t make us particularly popular as a reviewer.]]></description>
		<content:encoded><![CDATA[<p>I once had a spreadsheet to review &#8211; I was the independent consultantreviewing it for accuracy. It had been built to the edges of spreadsheet performance, and then the person who built it suddenly realised that they had a whole extra piece of calculation to put in.</p>
<p>It ended up being 50 Meg (really!), and excel just couldn&#8217;t cope with the amount of data. Somewhere deep in the middle of the main spreadsheet (somewhere around the 20,000th row) the spreadsheet just crashed, and the calcs from that part were complete rubbish.</p>
<p>We ended up making them take bits out and put them in Access before we could sign off, which didn&#8217;t make us particularly popular as a reviewer.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Clive</title>
		<link>http://ozrisk.net/2009/01/15/microsoft-excel-and-treasury-management/#comment-26738</link>
		<dc:creator><![CDATA[Clive]]></dc:creator>
		<pubDate>Sun, 25 Jan 2009 12:54:31 +0000</pubDate>
		<guid isPermaLink="false">http://ozrisk.net/?p=490#comment-26738</guid>
		<description><![CDATA[An Excel &quot;war story&quot; of a different type occurred in the early days of data gathering and matching to create longitudinal datasets for analysing credit card default behaviour (and hence to build application, and behavioural, PD models).

To get sufficient time span, it was necessary to exhume some PC-based legacy systems that had captured the info supplied at application time. The data files from these had been exported into Excel and these xls archives were all that was now available.

Unfortunately Excel has weak support for character versus numeric distinction, and all the credit card numbers had been input as numerics i.e. they now appeared as something like 5.220405061387E+15. CC numbers are 16 digits long, but PC double precision only reliably retains about 14 significant digits. So, the key linking field, the CC no., was known certainly for the first 13 digits and almost surely for the 14th but only vaguely for the 15th, and the 16th was random. &#039;Matching&#039; and &#039;record linkage&#039; etc. takes many forms but this particular mode of imperfect data - caused by passing through Excel - was an interesting variation. A bit like having hardcopy records chewed all down the edge by a dog.

[We needed to know the exact CC no. so as to match the application info with the performance data on the core banking system.]

So we had to design a matching algorithm that started out using matches on the first 14 digits and then using some heuristic filtering of multiple matches based on other data fields.]]></description>
		<content:encoded><![CDATA[<p>An Excel &#8220;war story&#8221; of a different type occurred in the early days of data gathering and matching to create longitudinal datasets for analysing credit card default behaviour (and hence to build application, and behavioural, PD models).</p>
<p>To get sufficient time span, it was necessary to exhume some PC-based legacy systems that had captured the info supplied at application time. The data files from these had been exported into Excel and these xls archives were all that was now available.</p>
<p>Unfortunately Excel has weak support for character versus numeric distinction, and all the credit card numbers had been input as numerics i.e. they now appeared as something like 5.220405061387E+15. CC numbers are 16 digits long, but PC double precision only reliably retains about 14 significant digits. So, the key linking field, the CC no., was known certainly for the first 13 digits and almost surely for the 14th but only vaguely for the 15th, and the 16th was random. &#8216;Matching&#8217; and &#8216;record linkage&#8217; etc. takes many forms but this particular mode of imperfect data &#8211; caused by passing through Excel &#8211; was an interesting variation. A bit like having hardcopy records chewed all down the edge by a dog.</p>
<p>[We needed to know the exact CC no. so as to match the application info with the performance data on the core banking system.]</p>
<p>So we had to design a matching algorithm that started out using matches on the first 14 digits and then using some heuristic filtering of multiple matches based on other data fields.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Colin</title>
		<link>http://ozrisk.net/2009/01/15/microsoft-excel-and-treasury-management/#comment-26726</link>
		<dc:creator><![CDATA[Colin]]></dc:creator>
		<pubDate>Mon, 19 Jan 2009 05:34:27 +0000</pubDate>
		<guid isPermaLink="false">http://ozrisk.net/?p=490#comment-26726</guid>
		<description><![CDATA[Andrew I think you are quite right, and you highlight a perhaps little known aspect of the credit crisis.  The bulk of management of the positions in ABCP of all types is managed in Excel, as are the development of business cases in Capital Markets.  There are other problems with Excel for such activities - the opportunity for error is mammoth.  Spreadsheets are created by well-intentioned experts, but the possibility of one cell being incorrect is enormous, with obvious consequences.]]></description>
		<content:encoded><![CDATA[<p>Andrew I think you are quite right, and you highlight a perhaps little known aspect of the credit crisis.  The bulk of management of the positions in ABCP of all types is managed in Excel, as are the development of business cases in Capital Markets.  There are other problems with Excel for such activities &#8211; the opportunity for error is mammoth.  Spreadsheets are created by well-intentioned experts, but the possibility of one cell being incorrect is enormous, with obvious consequences.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ross Gayler</title>
		<link>http://ozrisk.net/2009/01/15/microsoft-excel-and-treasury-management/#comment-26725</link>
		<dc:creator><![CDATA[Ross Gayler]]></dc:creator>
		<pubDate>Fri, 16 Jan 2009 11:07:59 +0000</pubDate>
		<guid isPermaLink="false">http://ozrisk.net/?p=490#comment-26725</guid>
		<description><![CDATA[Identification of the risks in using spreadsheets (not just Excel) for complex tasks is something of a cottage industry among consultants and academics.  For example, see the European Spreadsheet Risks Interest Group (&lt;a href=&quot;http://www.eusprig.org/&quot; rel=&quot;nofollow&quot;&gt;http://www.eusprig.org/&lt;/a&gt;) - especially their zoo of publicly reported spreadsheet errors (&lt;a href=&quot;http://www.eusprig.org/stories.htm&quot; rel=&quot;nofollow&quot;&gt;http://www.eusprig.org/stories.htm&lt;/a&gt;).  For two examples of interesting technical approaches to avoid the risks and retaining the benefits of spreadsheets see http://www.spreadsheet-factory.com/ and http://www.lumina.com/]]></description>
		<content:encoded><![CDATA[<p>Identification of the risks in using spreadsheets (not just Excel) for complex tasks is something of a cottage industry among consultants and academics.  For example, see the European Spreadsheet Risks Interest Group (<a href="http://www.eusprig.org/" rel="nofollow">http://www.eusprig.org/</a>) &#8211; especially their zoo of publicly reported spreadsheet errors (<a href="http://www.eusprig.org/stories.htm" rel="nofollow">http://www.eusprig.org/stories.htm</a>).  For two examples of interesting technical approaches to avoid the risks and retaining the benefits of spreadsheets see <a href="http://www.spreadsheet-factory.com/" rel="nofollow">http://www.spreadsheet-factory.com/</a> and <a href="http://www.lumina.com/" rel="nofollow">http://www.lumina.com/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: AUSQUANT</title>
		<link>http://ozrisk.net/2009/01/15/microsoft-excel-and-treasury-management/#comment-26724</link>
		<dc:creator><![CDATA[AUSQUANT]]></dc:creator>
		<pubDate>Fri, 16 Jan 2009 04:48:33 +0000</pubDate>
		<guid isPermaLink="false">http://ozrisk.net/?p=490#comment-26724</guid>
		<description><![CDATA[While I&#039;ve never worked anyway that was using Excel for compiling its GL, there has always been some tension on the use of it to price deals for P&amp;L purposes. 

While Excel&#039;s shortcomings are numerous, it has the flexibility to enable almost any new and interesting deal to be set up in it and with an add in or two doing the grunt work price any sort of deal you like. Most systems on the other hand don&#039;t allow this kind of flexibility and you quickly wind up either restricting business or doing some rather horrendus fudges.

Personally I feel the best approach is to allow small numbers of deals be doen on this basis to see if it is a profitable business line before proceeding to an expensive system upgrade.]]></description>
		<content:encoded><![CDATA[<p>While I&#8217;ve never worked anyway that was using Excel for compiling its GL, there has always been some tension on the use of it to price deals for P&amp;L purposes. </p>
<p>While Excel&#8217;s shortcomings are numerous, it has the flexibility to enable almost any new and interesting deal to be set up in it and with an add in or two doing the grunt work price any sort of deal you like. Most systems on the other hand don&#8217;t allow this kind of flexibility and you quickly wind up either restricting business or doing some rather horrendus fudges.</p>
<p>Personally I feel the best approach is to allow small numbers of deals be doen on this basis to see if it is a profitable business line before proceeding to an expensive system upgrade.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

