Author: Louise Pryor

Newsletter Mar 2005

Post author By Louise Pryor
Post date 31 March 2005

News update 2005-03: March 2005
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe@louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe@louisepryor.com.
Newsletter archived at http://www.louisepryor.com/newsArchive.do.

In this issue:
1. There’s a little man inside the box…
2. Somebody else’s problem
3. FSA update
4. Count on failure
5. Newsletter information

===============
1. There’s a little man inside the box…

The clocks changed in the UK at the weekend, as they do twice a
year. So you’d think that computer systems would be able to cope,
and that there would be no major disruption. And, on the whole,
you’d be right, though you wouldn’t necessarily know it from the
press coverage.

About 1,500 Barclays ATMs (out of a total of about 4,000) were out
of action for over 12 hours on Sunday. We were told that a manager
put the clocks back rather than forward, and that this mistake had
caused the problems. The Daily Telegraph carried a leader opining
on the lessons that Barclays could learn from its employee’s
blunder.

But hang on a minute: A real live person, changing the clocks in
the data centre at 01:00 on Sunday morning? It just doesn’t make
sense. Why on earth wouldn’t the time change be automated? After
all, it is in just about every other computer in the world. Did you
have to change the time on your PC this weekend?

And in fact, Barclays say that it was a hardware fault, and not
related to the time change at all. This is much more plausible, and
is what I heard a Barclays person say on the radio. But if it’s
true, where did the story of the error-prone manager come from? The
Telegraph said that they had it from customer services staff.

I imagine it happened something like this: The ATMs go down. (And,
it appears, the online banking too). Calls pile into the call
centre. Nobody at the call centre knows what the problem is. (And
why should they know? They are not omniscient, and these things
often take time to track down.) They are talking to each other
about what is going on. Someone says that it must be something to
do with the clocks changing, as that’s something that doesn’t
happen every day. And someone else says “Yeah, I bet that’s
it. Some stupid person changed them in the wrong direction!” And
before you know where you are, an off the cuff remark (probably
made in jest) has spread around the call centre and becomes the
official version.

People are very unwilling to believe in coincidences. They also
have mental models of how things work. And surprisingly often,
those mental models boil down to a little man in the box (or, in
this case, in the data centre). So when they were told that the
problem arose because a person made a mistake, they didn’t stop to
think about whether the story really made sense.

http://news.zdnet.co.uk/hardware/0,39020351,39193138,00.htm
http://makeashorterlink.com/?M170229CA
http://www.forbes.com/facesinthenews/2005/03/28/0328autofacescan05.html
http://edition.cnn.com/2005/BUSINESS/03/28/barclays.machines/

===============
2. Somebody else’s problem

There have been a number of stories about outsourcing and its
problems recently, though they are rarely expressed as such. To
mammothly over-simplify, the trouble with outsourcing is that you
lose control, the benefit is that you offload the problems onto
someone else. The risk is that there are gaps: the outsourcer
doesn’t deal with the problems, and you no longer can.

Computer security is a prime candidate for outsourcing. Specialists
can do a much better job of keeping up with all the latest threats
and how to deal with them. But a number of organisations recently
lost whole tranches of email messages because there was a bug in a
system that an outsourcer used for email scanning. When the update
mechanism tried to install the updates on the customer networks,
the system started to delete all emails by default. Oops! At least
one customer claimed that someone at the outsourcer said that the
update hadn’t been tested, but this was denied.

http://news.zdnet.co.uk/internet/security/0,39020375,39189933,00.htm

Internet hosting is also outsourced. There are comparatively few
organisations that have the expertise or funds to run a full data
centre themselves; it’s a field in which there are very definitely
economies of scale. Interestingly, there are often two or three
layers of outsourcing: the end customer uses an ISP, who in turn
uses one of the big data centres (or may bulk buy from another ISP,
who uses…). So if anything goes wrong in one of the big data
centres, the effects are widely felt.

Which is just what happened recently. A routine test was being
carried out when a fault developed in a switchgear panel (whatever
that is). This caused a short circuit in the UPS (uninterruptible
power supply) modules, so everything moved to battery power. The
fire alarms also went off (I can’t make out whether this was
connected, or just a coincidence), the building was evacuated and
everyone stood around outside while the batteries ran down.
Customers suffered hours of downtime, and a number of them had
equipment destroyed by a power surge that occurred at some point
during the episode.

One of the problems here for the end customer is that they may not
even know where the chain ends for them, and so have next to no
chance of really being able to manage the risks. I believe that the
physical bits and bytes that make up my web sites currently live in
Calgary, for example, but when I chose my hosting company I was at
least as interested in the software they supported as the historic
uptimes. And I didn’t do any work on finding out whether I expected
future performance to reflect historic, or whether there were
special factors that should have caused me to be wary. (In fact, I
haven’t had any trouble since my last move 18 months ago).

http://makeashorterlink.com/?G3B0219CA
http://news.zdnet.co.uk/business/0,39020645,39190518,00.htm

A recent Gartner survey has pointed out another problem with
outsourcing: it can raise costs. Apparently outsourced customer
service operations can cost almost a third more than those retained
in-house.

http://makeashorterlink.com/?H221249CA

According to Jamie Oliver, this applies to school meals, too.

===============
3. FSA update

The FSA’s new web site appears to have outgrown some of its
teething problems. Many of the old links now work again, which
makes life easier.

New issues of both the General Insurance and Life Insurances
newsletters have appeared. Both of them contain information on the
FSA’s current thinking on various aspects of the ICAS process,
including confidence levels and time horizons.

http://www.fsa.gov.uk/pubs/other/gi_newsletter5.pdf
http://www.fsa.gov.uk/pubs/other/li_newsletter3.pdf

New consultation and discussion papers out this month:
—————————————————–

CP05/4 FSMA 2 Year Review: Financial Ombudsman Service

DP05/1 Integrated Regulatory Reporting (IRR) for: Deposit
takers, principal position takers, and other investment
firms subject to the Capital Requirements Directive

Feedback published this month:
—————————–

PS05/3 Implementation of the Market Abuse Directive

A list of current consultations is available at
http://www.fsa.gov.uk/Pages/Library/Policy/CP/current/index.shtml

===============
4. Count on failure

One of the reasons for Google’s success is that the folk there
count on bad things happening. It’s well known that they use
large numbers of cheap machines for the heavy computations that are
involved in indexing so many web pages, instead of buying expensive
supercomputers. A normal PC might fail once in three years (that
seems a bit optimistic to me), so if you have thousands of them you
can expect on the order of one failure a day. So they assume that
failures will happen, and develop systems to handle them.

http://makeashorterlink.com/?V2A1149CA

It’s obvious when you put it like that: clearly you should allow
for anything that happens as often as once a day. But where do you
draw the line? And how can you tell how often failure is likely to
occur? Consider spreadsheets, for example (I had to get there
eventually…) How often are you likely to get something going
wrong in a spreadsheet? An optimistic estimate is that about 1% of
unique formulae will have errors in them. A spreadsheet only has to
have about 69 unique formulae to be more likely than not to contain
an error. And that’s not a particularly large spreadsheet. So what
do you do about it? Testing, reviewing, good development
processes… If you want to know more, do get in touch!

I discussed banks, robberies and phishing in the last issue. This
month it came to light that key logging software was used in an
attempt to steal £220 million from a Japanese bank in the
city. Arrests have been made. The bank’s security worked well, in
that it was internal security officers who first spotted the
attempt.

http://www.timesonline.co.uk/article/0,,2-1529429,00.html

===============
5. Newsletter information

This newsletter is issued approximately monthly by Louise Pryor
(http://www.louisepryor.com). Copyright (c) Louise Pryor 2005. All
rights reserved. You may distribute it in whole or in part as long
as this notice is included. To subscribe, email
news-subscribe@louisepryor.com. To unsubscribe, email
news-unsubscribe@louisepryor.com. All comments, feedback and other
queries to news-admin@louisepryor.com. Archives at
http://www.louisepryor.com/newsArchive.do.

Newsletter Old site

Newsletter Feb 2005

Post author By Louise Pryor
Post date 28 February 2005

News update 2005-02: February 2005
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe@louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe@louisepryor.com.
Newsletter archived at http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Where the money is
2. Is it risky?
3. FSA update
4. Is testing worth it?
5. Newsletter information

===============
1. Where the money is

Apparently Willie Sutton, the bank robber, said when he was asked
why he robbed banks, “because that’s where the money is”. It’s a
statement of the blooming obvious, and holds true even today, when
the mechanics of robbing banks have moved on from the tried and
tested methods used 50 or a hundred years ago (although the old
methods are still used: the Northern Bank robbery in Belfast in
December involved huge amounts of cash–see
http://news.bbc.co.uk/2/hi/uk_news/northern_ireland/4117219.stm).

Nowadays, you don’t actually have to physically break in to a bank
vault to get your hands on money that isn’t yours. Instead, you can
commit some sort of cybercrime. The problem (if you are a
fastidious bank robber) is that in most cases you are no longer
targeting a large anonymous institution, but are stealing directly
from the bank’s customers. However, few bank robbers have many
scruples, and there are now several more options open to such
people: interfering with ATMs, so as to get card details which you
can then use fraudulently; phishing, or trying to get people to
give you their personal details such as account numbers and
passwords (ditto); and using some kind of spy-ware to log their key
strokes, thus letting you listen in on the personal details which
you can then use in the usual way.

All these methods take advantages of weaknesses in the overall
security systems of the banks. ATM fraud is based on physical
weakness: it is possible to interfere with the actual, physical ATM
machines. The other two are based on targeting the weakest link in
the whole system, the bank’s customers and their computer system. I
call this the weakest link because it is an area over which the
bank has no control. It can try to improve security in this area by
educating its customers, and by introducing security procedures and
authentication mechanisms that make it harder for fraudsters to
impersonate genuine customers, but there are huge difficulties in
making these measures effective.

There may, however, be new incentives for the banks to take these
issues even more seriously than they do at present (and although I
am using banks as an example, the issues are the same for any
online service provider). A Miami business man is suing his bank,
because he claims the bank is liable for the losses he suffered
through fraud. Apparently his computer was infected with a virus
that logged his keystrokes, enabling someone to steal $90,000 from
his account. He says that the bank should have told its customers
about the virus and the dangers it posed.

http://outjacay.notlong.com

This whole area raises a number of tricky questions:

– To what extent should banks (or other online service providers)
be responsible for educating their customers in computer security
matters? It seems to be generally accepted that they should warn
customers about not disclosing passwords and PINs, being wary of
unsolicited emails that could be phishing scams, and so on, but
what about specific viruses? Should they encourage their
customers to use spy-ware detectors, virus protection software and
firewalls? What about using public access computers, in libraries
or internet cafes? Or security measures for their home wifi
networks?

– If online service providers try to improve their security
measures, especially as far as user authentication is concerned,
their sites are often perceived as being more difficult to use,
so they lose customers. Where should the balance lie? Is it again
a question of educating the user to accept more complex
procedures?

– Would biometric authentication mechanisms help? Or could packet
sniffing software be used to mimic fingerprints or iris patterns?
And in any case would users be prepared to invest in the
necessary hardware?

As a footnote, it appears that Willie Sutton never actually made
the smart alec remark that is attributed to him. Also, he was
usually known as Bill, not Willie. He actually said “Why did I rob
banks? Because I enjoyed it. I loved it. I was more alive when I
was inside a bank, robbing it, than at any other time in my life. I
enjoyed everything about it so much that one or two weeks later I’d
be out looking for the next job. But to me the money was the chips,
that’s all.”

http://www.banking.com/aba/profile_0397.htm

===============
2. Is it risky?

The latest “Banana Skins” survey has identified regulatory overkill
as the biggest risk facing banks today. The survey covered 440
respondents from 56 countries.

http://www.csfi.org.uk/Banana%20Skins%20Press%20Release.pdf
http://munrippi.notlong.com

When I first read about this, I was amazed. Regulation the biggest
risk? You mean *regulation* is going to make banks go bust? And
surely the major thrust of most current regulation is to reduce
risk–have the regulators really got things so horribly wrong? Then
I realised that we weren’t being given the full context. Risk is
not a concrete entity, sitting out there in glorious isolation
waiting to be identified. There are only risks in relation to
goals, or other desirable outcomes.

The respondents to the survey were probably thinking of the risks
to their profits. Heavier regulatory requirements undoubtedly
result in heavier costs to those who are regulated. However, they
may reduce the risks of customers losing their money, and the risks
of the regulatory bodies failing to achieve their objectives. For
instance, the FSA make it vary clear that the risks they are
worried about are the risks to their statutory objectives;
inasmuch as these risks coincide with risks to the profits or
shareholder value of the firms that they regulate, all well and
good, but that’s really a side effect.

When you are discussing the riskiness or otherwise of various
courses of action it’s important to be very clear about the
context. The risk to what? Often, it is assumed that all parties to
the conversation share the same context, which is never made
explicit. This can lead to quite violent disagreements, which turn
out to be based on problems of definition rather than on
fundamental differences.

I’ve been at a couple of gatherings of actuaries recently at which
the discussion turned to the topic of whether cash is more or less
risky as an investment than equities. This is a question to which
there is no correct answer. Whether cash is more or less risky
depends on what you are trying to do. If you are investing in order
to meet future outgoings as they fall due, it obviously depends on
what the outgoings are. For fixed monetary amounts in the short
term, cash is beautifully risk free. For real amounts in the longer
term, especially if the inflationary outlook is uncertain, cash
starts to look much more dodgy.

In the investment world volatility is often used as a synonym for
risk. And indeed, a highly volatile investment is risky if you are
interested in getting a pay-out defined in nominal terms on a
specific date. Over a longer term, especially when you can choose
when to disinvest based on circumstances at the time, volatility
becomes less of an issue. Again, the context is all-important.

===============
3. FSA update

The FSA have a new web site. I haven’t used it enough yet to be
able to tell whether it’s an improvement or not (I had no
particular gripes about the old site), but I do find it annoying
that a number of my bookmarks no longer work. For example, there
used to be a handy page that listed current consultations, with
dates by which responses should be received by the FSA. I haven’t
been able to track down the new version of this, if it exists. In
addition, the URLs for all existing documents have changed. The
listing of publications by date is less comprehensive than before,
as it no longer includes press releases, Dear CEO letters or
speeches.

I found the Dear CEO letter on credit derivatives somewhat
interesting (I never thought I’d hear myself say those words, or
maybe I mean see myself write them…) It turns out that insurance
companies are not years behind the banks on all risk management
issues. It’s been known for some time in the insurance world that
the habit of not finalising contracts is a risky one, and there has
been a bit of a push on to try to improve practice in this
area. Well, apparently traders in credit derivatives have the same
problem. Some transactions remain unconfirmed for months. The risks
are obvious.

http://www.fsa.gov.uk/pubs/ceo/derivatives_22feb05.pdf

New consultation and discussion papers out this month:
—————————————————–

None

Feedback published this month:
—————————–

PS05/02 Insurance regulatory reporting: changes to the publicly
available annual return for insurers – Feedback on CP202
and CP04/1 and made text

===============
4. Is testing worth it?

In my last newsletter I rather glibly said that, with hindsight,
the Huygens team got their cost benefit analysis completely wrong
when deciding whether to subject every system to a simulation of
the exact signals and conditions it would experience during
flight. Alan Chaplin quite rightly pointed out that this was an
over simplistic comment. As he says, it’s likely that this wasn’t
the only test that was omitted. He also gave a very succinct
summary of how the analysis should be performed:

The cost benefit analysis on the test runs something like:

Cost of test = m
Probability of finding a problem = x
Cost of fixing problem = n
Value of fixing a problem found by test = b

So cost = m + (n * x)
Benefit = (b * x)

Carry out test if benefit > cost

So if x is very small the cost benefit analysis says don’t do
it. The fact that the error did turn out to exist does not
necessarily mean that the probability a priori was wrong.

This is absolutely right. The difficulty is estimating x, n and
b. It’s difficult to know what information the Huygens team had
available at the time, and so whether they made the right decision
or not.

In my view x, the probability of finding a problem, is especially
difficult. It depends on so many things, including the coverage of
the tests you’ve done so far – and on the whole I think we tend to
overestimate the efficacy of our tests and underestimate the a
priori likelihood of mistakes.

n, the cost of fixing a problem, is not easy either, as it varies
so much depending on what the problem is. In this case they were
pretty lucky that it turned out to be possible to fix it at all, it
seems. And if you have no idea of what sort of problems, if any,
may be uncovered by your tests, how can you possibly tell what it
will cost to fix them?

And of course b, the value of fixing a problem, depends on what the
problem is. In some cases this is very high indeed: if the problem
means that the whole mission fails, for example. This is subject to
many of the same issues as estimating the cost of fixing a problem.

I have no really good answers to this. Through experience on
numbers of similar projects one gets a reasonable feel for the
centres of the distributions — ie, typical numbers and sizes of
problems found. But on a one-off project, or out in the tail of the
distributions, it’s not easy at all.

===============
5. Newsletter information

——————————————————————–
The Edinburgh Bach Choir will be performing Bach’s St Matthew Passion
at St Cuthbert’s Church, Lothian Road on Saturday March 12th. See
http://www.edinburghbachchoir.org.uk for more details. Tickets from
the Usher Hall or members of the Choir.

Newsletter Old site

Newsletter Jan 2005

Post author By Louise Pryor
Post date 31 January 2005

News update 2005-01: January 2005
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe@louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe@louisepryor.com.
Newsletter archived at http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Safety nets can be dangerous
2. Rocket science
3. FSA update
4. Disastrous IT projects
5. Newsletter information

===============
1. Safety nets can be dangerous

A good way to prevent a bad thing happening is to add more ways of
stopping it, right? Wrong. Adding more redundancy often increases
the risk. The following four factors may come into play:

– Redundancy only works if the different methods (systems,
procedures, or whatever) are truly independent. If they are not,
and sometimes the failure of one can make the others fail too,
the redundancy is more apparent than real. For example, you
might think that adding more engines to an air-plane would make
crashes from engine failures less likely. In fact, this is only
true up to a certain limit, depending on the plane and the
engines concerned. If you have more engines it is more likely
that one of them will fail; and if the failure is likely to be
catastrophic, such as by starting a fire that destroys all the
other engines, the risks of having more engines may outweigh the
possible benefits.

– There is a well know psychological phenomenon known as bystander
apathy. The more witnesses there are to an accident, the less
likely each individual witness is to call an ambulance.
Similarly, the more people responsible for performing a check,
the less thorough each will be. Each thinks “there are n other
people doing this – if there is anything wrong, one of them is
bound to spot it”. If everybody is responsible then nobody takes
the responsibility.

– If a system is believed to be safer, people are likely to take
more risks with it. They drive faster if they are wearing seat
belts. Add two levels of warning to a system and people will
ignore the first level.

– Dedicated workers will bypass safety systems if they interfere
with what they see as their primary responsibilities. If it’s
important to get a report out on time, people will not bother to
password protect it or update the security systems on their
computer. Software developers will code all night, but not bother
with backups, source control or systematic testing. Fire doors
are propped open.

The basic arguments are set out in an excellent paper by Scott
Sagan. He is discussing the problems of making nuclear
installations more secure against terrorism, but of course the
principles apply to all types of risk management systems and
processes. Further discussion and some great examples were provided
by Don Norman and Geoffrey Newbury in the Risks forum.

As Norman points out, three of these four factors are psychological
rather than technical. They should be taken seriously when devising
any method of risk control.

http://cisac.stanford.edu/publications/20274/
http://catless.ncl.ac.uk/Risks/23.63.html#subj11.1
http://catless.ncl.ac.uk/Risks/23.64.html#subj10.1

===============
2. Rocket science

Wasn’t the Huygens landing a great way to start the year! The
pictures were stunning, even though there were fewer of them than
expected.

As you probably recall, Huygens was dropped onto Titan from the
Cassini interplanetary probe. Signals from Huygens were received by
Cassini and then transmitted back to earth; direct transmission was
not possible because of the limited power available to Huygens.
There was redundancy built into the design, with two radio channels
being used for the communications, so that if one failed the data
would still get through on the other. In the event, one of the
channels did fail (a software error: Cassini’s receiver was never
told to turn on). But guess what? The two channels weren’t fully
redundant. Channel A, the one that failed, was the only one
carrying data that would help measure wind speeds. And half the
pictures taken during the descent were sent only over channel A,
and the other half only over channel B.

Redundancy only works if it’s genuine (see above), and it can
sometimes be subverted by people trying to do their job (in this
case, trying to get as much information back from Titan as
possible).

However, it turns out we were lucky to get any pictures at all.

When Cassini was launched in 1997, the team were pretty confident
that things would go well. Cassini and Huygens had been thoroughly
tested on the ground, both separately and together. But there was
one test that had been omitted: they decided not to subject every
system to a simulation of the exact signals and conditions it would
experience during flight, because this would have meant
disassembling some of the communications components. It would have
been time consuming and expensive to do this, then reassemble,
retest and recertify them. It was a simple cost-benefit analysis,
which in hindsight was completely wrong.

A couple of the team in Darmstadt were worried that this test had
not been performed, and eventually persuaded mission control that
it would be possible to perform a similar test during Cassini’s
long trip out to Saturn. They devised a test to send a signal from
Earth to Cassini to simulate the signals that Cassini would receive
from Huygens during the landing. Cassini could then echo the
information back to Earth, where the team could tell whether it had
been received and deciphered correctly.

The test failed. It turned out that the reception mechanism on
Cassini had not been designed to account correctly for the Doppler
shift in the signal caused by the high relative acceleration
between Cassini and Huygens. Rather annoyingly, the problem could
have been fixed by some trivial parameter changes in the firmware,
but once Cassini had left Earth these changes could no longer be
made.

Eventually they worked out a way of changing the trajectory of
Huygens so that the Doppler shift would be reduced. This is why the
landing wasn’t until this January, instead of late 2004 as
originally planned.

There are some obvious morals to this story. However much testing
you do, it may always be the next test you do that uncovers the
problem. And the problem may be a big one. Just because you’ve done
99% of the testing it doesn’t mean that the system is 99% likely to
work.

Moreover, thorough review is no substitute for testing. The problem
was spotted by none of the design reviews of the communications
link. An issue that was overlooked by the design team was also
overlooked by the reviewing team. There are some hints in some of
the published accounts that the reviewing team didn’t imagine that
the design team could possibly overlook the effects of the Doppler
shift: so don’t make unwarranted assumptions, and do check up on
any assumptions you make.

The full IEEE Spectrum article on this episode contains all the
details.
http://www.spectrum.ieee.org/WEBONLY/publicfeature/oct04/1004titan.html

Wikipedia has a useful summary, while the ESA site is the horse’s
mouth.
http://en.wikipedia.org/wiki/Huygens_probe
http://www.esa.int/SPECIALS/Cassini-Huygens/index.html

===============
3. FSA update

The FSA have just issued their annual Financial Risk Outlook and
Annual Plan. If you want to know what is on their mind, these two
documents are vital reading.

http://www.fsa.gov.uk/pubs/plan/financial_risk_outlook_2005.pdf
http://www.fsa.gov.uk/pubs/plan/pb2005_06.pdf

New consultation and discussion papers out this month:
—————————————————–

CP05/01 Quarterly Consultation (No 3)
CP05/02 Regulatory fees and levies 2005/06
CP05/03 Strengthening capital standards. Including feedback on
CP189

Feedback published this month:
—————————–

PS04/28 Lloyd’s: Integrated prudential requirements and changes to
actuarial and auditing requirements – Including feedback
on CP04/7, CP04/13 (part) and CP04/15 (part) and ‘made
text’
PS05/01 Treating with-profits policyholders fairly – Feedback on
CP04/14 and made text

Current consultations, with dates by which responses should be
received by the FSA, are listed at
http://www.fsa.gov.uk/pubs/2_consultations.html

===============
4. Disastrous IT projects

We often hear about disastrous IT projects. Stories recently have
included:

– A new system for keeping track of the MoT status of cars is
running two and a half years late. The budget (in 2003) was
£230m. I haven’t been able to find out what the budget overrun
is.

– The computer systems at the Child Support agency don’t work and
are about £29m over a £456m budget.

– An FBI system intended to be an important tool in fighting
terrorism may be scrapped because it doesn’t work and may never
work. So far it has cost $170m.

http://www.theregister.co.uk/2004/12/30/pcs_slams_mot_system_delays/
http://www.pcw.co.uk/news/1160762
http://news.bbc.co.uk/1/hi/uk_politics/4205221.stm
http://www.cnn.com/2005/US/01/13/fbi.software/

The amounts of money involved in spreadsheet errors are sometimes
comparable. For example, the state of New Hampshire has recently
had to find an extra $70m in its budget.

http://www.theunionleader.com/articles_showfast.html?article=50185

It seems to me that the press coverage of both types of problem
gives a misleading impression. Although a number of IT projects are
spectacular disasters, there are many others that are extremely
successful. And the disasters are rarely caused entirely by IT
factors; they often go hand in hand with more general management
problems. On the other hand, there are probably far more problems
arising from spreadsheets than we ever hear about. But spreadsheets
don’t count as IT. They probably should.

===============
5. Newsletter information

——————————————————————–
The Edinburgh Bach Choir will be performing Bach’s St Matthew Passion
at St Cuthberts Church, Lothian Road on Saturday March 12th. See
http://www.edinburghbachchoir.org.uk for more details. Tickets from
the Usher Hall or members of the Choir.

Newsletter Old site

Newsletter Dec 2004

Post author By Louise Pryor
Post date 22 December 2004

News update 2004-12: December 2004
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe@louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe@louisepryor.com.
Newsletter archived at http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Year end
2. Certified models
3. FSA update
4. Seasonal greetings
5. Newsletter information

===============
1. Year end

The end of another year, and what an end it is for some! The first
ICAS for UK insurance companies as well as the first year end for
reporting under Sarbanes-Oxley for many organisations. All the new
requirements are creating huge amounts of extra work for the
auditors and consultants. There are occasional reports of how tough
it all is, and how some large(ish) number of companies are not
going to comply with the Sarbanes-Oxley section 404 deadline (75
days after their year end date, for the the auditor to identify
‘any material internal control weakness’ or ‘significant
deficiency’, in verifying that management has sufficient
operational command to produce reliable and compliant financial
reports). I saw one report that said that 300 companies have
already warned the SEC of their likely non-compliance.

So what’s going on? Why is it so difficult for companies to satisfy
the auditors that they can produce reliable and compliant financial
reports? The obvious answer is that a number of companies really
do lack the requisite internal controls, and that they are not
necessarily producing reliable results. In many cases the results
probably are reasonably OK, but it’s more a matter of luck than
judgement. And we’ve seen some cases in which the results weren’t
OK (SunTrust Banks last month, for example).

http://www.computing.co.uk/news/1159434
http://ryanjors.notlong.com

In a company of any size the process of producing financial reports
is incredibly complex, and is only as reliable as its weakest
link. Add in the effects of changes to requirements, which often
lead to people patching the gaps using manual procedures or ad hoc
spreadsheets, and the risks are obvious. Regular readers may
recognise that I am getting on to a familiar hobby horse here. One
aspect of the problem is that you have large, complex software
systems being built by people with no software engineering
expertise. Systems fail and have bugs in even when they are built
by professionals; when built by people who don’t even realise what
they are doing, they are even less likely to be foolproof.

===============
2. Certified models

Steve Rowley sent an interesting response to my piece last month
about the case where the parties concerned had to accept the
result of a spreadsheet error. Steve is a bio-informatics
researcher in the USA.

He says:

There’s an interesting twist on this in the pharma industry.

Particularly in the regulated part of the business (preparing
FDA/EMEA submissions), it’s important that the results you
derive from your data are (a) correct and (b) reproducible.
That leads to 2 tactics: extreme conservatism in study design,
and standardization of tools. Both are along the lines of “use
only what’s known to work”.

The latter is what bears on your case: good laboratory practices
(GLP) or good manufacturing practices (GMP). These are
mind-numbingly complex, rather bureaucratic specifications of
How Things Are Done. They specify every lab technique, every
software package, every bit of computer hardware, documentation
for anybody who wants to repeat the experiment step-by-step, and
so on. If you use ANYTHING else in the process, then you’re not
compliant. (There’s federal regulation in the US, known by the
charming sobriquet “21 CFR Part 11”.)

On the good side, once software has been GLP certified,
everybody trusts it. So the loan calculation story couldn’t
happen, because they’d be using certified software on certified
data. (Well, other things could happen, but not that particular
blunder.)

On the bad side, GLP procedures are completely stultifying.
It’s impossible to do research under such conditions. So often
companies split into 2 parts, only one of which is GLP/GMP
compliant (the government submission part), and one which is not
(the research part).

In fact, there are entire companies whose business is to repeat
your experiments, but this time guaranteeing and documenting
that it’s all GLP/GMP throughout. That is, it’s better to pay
for the experiment TWICE.

Most days, that even makes sense to me. You have one group of
weird, lawless researchers (hey, that’s me!) who figure out new
stuff and another group of button-down careful folk who nail
down every aspect of reproducibility for regulatory submission.

I guess we can bear that expense in pharma, when people’s lives
will depend on the result. It’s slightly unclear how that would
apply to financial services, except that I’m surprised there
aren’t standard, well-trusted, certified packages of software to
calculate things like interest.

There are some interesting comparisons that can be made with
financial services regulation in the UK.

First, the FSA is explicitly not going down the route of approving
specific models.

Also, even if a model has been certified it can still produce the
wrong results. Take the example of calculating loan interest. The
model would presumably make various assumptions about timings of
payments and the interest rate frequency (an annual rate; daily
rate annualised; or whatever). If the assumptions don’t agree with
the actual loan agreement (either because they are hard coded in
the model or someone gets the inputs wrong) then the model will not
produce the correct results. It’s not just the model that matters,
it’s the correspondence of the model to the real world as well.

Second, the division into creative but lawless scientists doing the
actual work and conforming bureaucrats producing the certified
recorded results isn’t an obvious one for financial
reporting. Though it’s a nice image… the actuary with wild hair
and staring eyes stooping over a test tube… the evil laugh… and
the mild mannered accountant clearing up the mess… No, it would
never work.

For a start, while developing a drug and getting regulatory
approval for it is essentially a large, one-off project which may
take several years, financial reporting is not. Financial reporting
has hard deadlines, which come round with horrifying frequency. The
strategy of doing everything twice, once to see what the answer
should be and the second time to prove it, is unrealistic.

It’s clear, though, that financial modelling for reporting purposes
(and probably for other purposes too) has to move more down the
tried-and-trusted, totally-reproducible route, with all processes
documented and all decisions recorded. In practice, this means more
planning ahead and much less last minute “we need these extra
results by yesterday”. It’s all going to have to be less reactive,
and so will seem less flexible.

===============
3. FSA update

At least three quarterly newsletters are issued by the FSA. The
latest issues are as follows:

Financial Crime, December 2004
http://www.fsa.gov.uk/pubs/other/fc_newsletter1.pdf

Life Insurance, December 2004
http://www.fsa.gov.uk/pubs/other/li_newsletter2.pdf

General Insurance, September 2004
http://www.fsa.gov.uk/pubs/other/gi_newsletter3.pdf

All of them include information on how to receive them regularly
(although past history, of which there is admittedly little,
indicates that the “quarterly” is perhaps more of a goal than an
achievement).

Two reports on cost benefit analysis (CBA) have been issued as part
of the N2+2 review (I can’t work out whether my predominant feeling
is “goodness, only two years,” or “goodness, two years
already?”). One is on CBA methodologies
(http://www.fsa.gov.uk/pubs/other/nera_cba_report.pdf) and the
other is on embedding CBA more deeply in the FSA
(http://www.fsa.gov.uk/pubs/other/howell_report.pdf). Before I
looked at them I was hoping to be able to say something along the
lines of “even if you don’t care about how the FSA do things, read
these reports for their more generally applicable comments.” I
haven’t read them very thoroughly, I admit, but so far haven’t come
across many particularly juicy nuggets.

However, I did like the FSA’s comment that “we recognise that
cumulative CBA, in the pure sense of the term, is in practical
terms impossible. This reflects the extreme difficulty of
modelling, with any reasonable certainty, what the net cost-benefit
effect of regulation on UK’s financial services markets would now
be like, compared with a position prior to regulation.”

New consultation and discussion papers out this month:
—————————————————–

None

Feedback published this month:
—————————–

PS04/28 Lloyd’s: Integrated prudential requirements and changes to
actuarial and auditing requirements – Including feedback
on CP04/7, CP04/13 (part) and CP04/15 (part) and ‘made
text’

Current consultations, with dates by which responses should be
received by the FSA, are listed at
http://www.fsa.gov.uk/pubs/2_consultations.html

===============
4. Seasonal greetings

No feeble jokes about the risks of the holiday season – just my
wishes for an enjoyable and relaxing holiday and a peaceful 2005.

===============
5. Newsletter information

This newsletter is issued approximately monthly by Louise Pryor
(http://www.louisepryor.com). Copyright (c) Louise Pryor 2004. All
rights reserved. You may distribute it in whole or in part as long
as this notice is included. To subscribe, email
news-subscribe@louisepryor.com. To unsubscribe, email
news-unsubscribe@louisepryor.com. All comments, feedback and other
queries to news-admin@louisepryor.com. Archives at
http://www.louisepryor.com/newsArchive.do.

Newsletter Old site

Newsletter Nov 2004

Post author By Louise Pryor
Post date 29 November 2004

News update 2004-11: November 2004
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe@louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe@louisepryor.com.
Newsletter archived at http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Model risk
2. More spreadsheet woes
3. FSA update
4. Time constraints
5. Newsletter information

===============
1. Model risk

A couple of weeks ago one of the big US banks, SunTrust Banks,
announced a restatement of earnings for the first two
quarters. This followed problems they had found with their loan
loss allowances, or more specifically, with the model they were
using for their loan loss allowances. Part of their press release
says: “There were numerous errors in the loan loss allowance
calculations for the first and second quarters, including data,
model and formulaic errors.” In other words, they are saying that
the data that went into the model was wrong, the model itself was
not a good fit to reality, and on top of that they hadn’t even
implemented this faulty model properly. That covers pretty much
everything that can go wrong with a model, if you count data as
including parameters (see my article and slides on how to believe
your models,
http://www.louisepryor.com/papers/actuary_04_08_08.pdf
http://www.louisepryor.com/papers/believeModelsGIRO2004.pdf).

The fall out from the modelling problem was definitely non
trivial. Q1 earnings were restated by 1%, Q2 earnings by 6%. In Q2,
the loan loss allowances changed by 90%. The loan loss allowances
had been overestimated, so this means that in the second quarter
they were out by an order of magnitude. Three people lost their
jobs as a result of the problem, including the Chief Credit
Officer. The Financial Controller was reassigned to a position
“with responsibilities that involve areas other than accounting or
financial reporting” – ie, neither finance nor control.

Moreover, SunTrust’s directors will be unable to sign off under
section 404 of Sarbanes-Oxley at the coming year end. They say that
they will likely “not be able to conclude that the Company’s
internal control over financial reporting was effective at such
date.”

So why did all this happen? Well, apparently they were bringing in
new processes and a new model in order to comply with
Sarbanes-Oxley. This evidently proved more difficult than they
anticipated. They say “The Company’s implementation of a new
allowance framework in the first quarter was deficient. The
deficiencies included inadequate internal control procedures,
insufficient validation and testing of the new framework,
inadequate documentation and a failure to detect errors in the
allowance calculation.” They also point to deficiencies in
spotting the problem, and then in doing something about it. In
particular, “certain members of the Company’s management did not
treat certain matters raised by the Company’s independent auditor
with an appropriate level of seriousness.”

The morals are fairly obvious. First, models matter, and mistakes
in models can be significant. Second, change is risky. It can be
very risky. (On the other hand, not changing also has its
risks). Thirdly, take problems seriously.

http://www.suntrust.com/common/AboutST/NewsRoom/news/20041110.asp

As a footnote to this episode, I note that many of the phishing
spams I’m getting at the moment purport to come from SunTrust. I
hope this email gets through your spam filters.

===============
2. More spreadsheet woes

While I’m on the topic of model errors, let’s get a bit more
specific about spreadsheet errors. There have been good ones
recently – Patrick O’Beirne maintains a good list at
http://www.eusprig.org/stories.htm. Just read it if you don’t
believe that there are large numbers of spreadsheet errors, and
remember these are only the ones that have both come to light and
been made public.

The one that really struck home to me was the one where the judge
said that you can’t undo mistakes. In other words, getting it right
does matter. Two parties had a disagreement about the interest on a
loan (one party failed to pay it, and the other wanted it). They
reached a settlement based on a spreadsheet prepared by one of the
parties. The settlement went through the legal process (something
called a Tomlin Order) and that should have been that.

However, some hours later a mistake was discovered in the
spreadsheet – so the parties had agreed the settlement on the basis
of information that turned out to be incorrect. However, they had
both accepted the spreadsheet and its results earlier, and the
judge ruled that the settlement was for a specific sum, regardless
of how that sum had been reached.

There are now a couple more people in the world who will always
check their spreadsheets.

http://tinyurl.com/6lzct

===============
3. FSA update

Those FSA folk continue to make speeches, some of which are well
worth reading. They are all available on the FSA web site, at
http://www.fsa.gov.uk/pubs. Last month I highlighted a speech that
had been made on financial fraud; this month a report has come out
on Countering financial crime risks in information security
(http://www.fsa.gov.uk/pubs/other/fcrime_sector.pdf). It’s worth
reading on at least two counts. First, it’s pretty interesting;
second, it contains a lot of useful information on resources you
can use to deal with financial crime. Apparently a big problem
among smaller firms is that they don’t know who to report problems
to: this report contains names and addresses.

New consultation and discussion papers out this month:
—————————————————–

CP04/18 Implementation of the Simplified Prospectus requirements
in the UCITS Management Company Directive

Feedback published this month:
—————————–

DP25 Feedback Statement on DP25 – Development of transaction
monitoring systems
CP176 PS04/23: Bundled brokerage and soft commission
arrangements
CP204 PS04/24: Insurance groups – Supplementary feedback on
CP204 and made text
CP04/3 PS04/27: Reforming Polarisation: Implementation – Feedback
on CP04/3 (A menu for being open with consumers) and made
text
CP04/10 PS04/26: Child Trust Funds – Feedback on CP04/10 and made
text
CP04/11 PS04/22: A basic advice regime on the sale of stakeholder
products – Feedback on CP04/11 and near-final text
CP04/13 PS04/25: Amendments to switch on the Integrated Prudential
sourcebook as it applies to insurers – Feedback to CP04/13

Current consultations, with dates by which responses should be
received by the FSA, are listed at
http://www.fsa.gov.uk/pubs/2_consultations.html

===============
4. Time constraints

There never seems to be enough time. The observant amongst you will
have noticed that this newsletter only just qualifies as the
November issue, and that it is shorter than usual. The two are not
unrelated: any longer and it definitely wouldn’t be November any
more. I only hope that not too many unintended errors have crept
in as I rush to write it (the intended errors are, of course, meant
to be there).

Looking at the two stories I wrote about above, SunTrust and the
wrong spreadsheet that the judge said had to stand, you have to
wonder about the role that time pressures played.

SunTrust obviously had a hard deadline; they had to comply with
Sarbanes-Oxley, and that means conforming to the time limits that
it sets. I can certainly imagine that there was a lot of pressure
to get things done quickly, and that possibly testing and review
were skimped as a result. Of course in the end the deadline won’t
be met at all.

In the second case, time pressures probably played a part, but I
bet that over-confidence did too. I can imagine someone thinking
“It’s only a simple little spreadsheet… calculating loan interest
isn’t that hard…” But mistakes can be and are made in simple
spreadsheets too, especially if you are not expecting to make them.

I always think that it’s a pity we don’t learn more about these
mistakes that come to light. Of course we can’t, because it’s all
commercially sensitive information, but it would be really useful
to know what really went wrong and why.

===============
5. Newsletter information

Newsletter Old site

Newsletter Oct 2004

Post author By Louise Pryor
Post date 28 October 2004

News update 2004-10: October 2004
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe@louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe@louisepryor.com.
Newsletter archived at http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Spitzer risk
2. Getting rid of risk
3. FSA update
4. You don’t have to be a rocket scientist
5. Newsletter information

===============
1. Spitzer risk

There is a new component of operational risk: Spitzer risk, the
risk that Eliot Spitzer will launch an investigation into your
industry, attacking widely accepted ways of doing business.

A simplified summary of the current investigation: Some insurance
brokers accept contingent commissions from the insurers with whom
they place business. These are based on the volume of business they
place with that insurers. The brokers therefore have an incentive
to place business with insurers who offer these commissions, even
if they are not offering the best rates. Their interests are thus
not fully aligned with those of their clients. Moreover, it is
claimed that at least one broker asked insurers to submit dummy
quotes, so that the quote that would give them the incentive
commission would appear to be the cheapest.

The effects of Spitzer’s investigation are being felt much more
widely than the particular brokers against whom a suit has been
filed. A number of firms have said that they will stop accepting
contingent commissions. Share prices in brokers have fallen. Credit
ratings have been cut. Share prices in some insurers have fallen,
at least partly due to the fear that they will have to bear
extensive legal costs. The scope of the investigation is
broadening.

These effects aren’t limited to the USA; insurance broking is a
global business and there are fears that abuse may be present in
the UK market as well. The FSA don’t regulate insurance brokers
until 1st of January; there is no indication as to whether they
will launch an investigation in this country.

Potential losses to individual firms from Spitzer risk include
legal costs, potential fines, loss of revenue (no more juicy
contingent commissions in this case), losses due to lower credit
ratings and opportunity costs of spending management time on coping
with the fall-out or on developing new business models. There may
also be more general reputational damage. Many of these costs are
incurred by firms that are not directly involved as well as those
that are.

How should firms manage Spitzer risk? It’s tricky. Once it
happens, ie once Spitzer (or someone else) has launched an
investigation into some aspect of your industry, or one closely
connected with it, you should add it to your risk register and try
to handle the fall-out as best you can. Hence those brokers who
have said that they will stop accepting contingent
commissions. Even in this case you have to be aware of the
potentially widespread effects.

But how do you identify a Spitzer risk before it happens? There you
are, doing business in the normal way, just like everyone else in
your industry: how can you tell if some part of normal business
practice is likely to be considered worthy of investigation by a
regulator? And not necessarily your own regulator, either? You
really have to think outside the box. Is there any aspect of your
business that you wouldn’t like to have to explain and justify to a
hostile journalist? (Or other interrogator). Or any aspect that can
be described as “just the way things are done”, but isn’t how you’d
do it if you were starting from scratch?

But it’s very difficult to step back and see things as an
outsider. And how can you tell which aspects somebody else might
pick up on? It’s all part of coping with a changing context. What
was accepted 50 or even 20 years ago may not be acceptable now,
with the increased emphasis on openness and transparency.

===============
2. Getting rid of risk

Outsourcing, both explicit and implicit, will always be a source of
risk. Sometimes you just don’t have a choice of whether to
outsource or not, but the risk is still there.

For example, it’s not really practical to compile your own real
time market data. You have to use one of the major suppliers, such
as Reuters. But that means you depend on them, and if something
goes wrong you suffer. A couple of weeks ago a circuit breaker
failed at the Reuters Global Technical Centre in London (GTC-L). It
caused disruption to about 25% of the systems supported from the
building riser that was affected. An hour or so after the
first incident a second riser failed due to overloading, which
meant that two out of the four risers supporting GTC-L lost
power. The data feed was eventually down for about 10 hours. There
was nothing that Reuters’ customers could do about it.

http://www.finextra.com/fullstory.asp?id=12678
http://www.computerweekly.com/Article134316.htm

There has been a steady stream of scare stories about the risks of
outsourcing call centres offshore: operators offering unauthorised
credit to customers, and criminal gangs organising operators to
commit fraud against customers. Apparently some call centres are
not fully complying with the Data Protection Act, either.

However, the outsourcer is the party that is subject to the Data
Protection Act, as the Data Controller, so it’s the outsourcer’s
duty to ensure compliance. If there are problems, they will come
home to roost with the outsourcer, either as specific losses or as
reputational damage, and quite possibly both. You just can’t get
rid of the risk.

http://tinyurl.com/3p2ln

Here’s another risk that you can’t evade. Apparently many managers
are worrying about the increasing use of instant messaging
(IM). People use it to avoid the content filtering and monitoring
that is applied to email, believing that it is exempt from
compliance regulations such as Sarbanes-Oxley and Basel II. Of
course it’s not: it’s a communication just as much as emails and
telephone conversations are.

Many companies have banned it, as a security and compliance risk,
but the ban is extremely difficult to enforce. (From the technical
point of view it’s hard to distinguish IM traffic from other,
authorised, web traffic).

So whatever you do, you are still left with the risk. You ban IM,
people use it, you run into compliance problems… it’s no use
saying “not my fault guv.”

http://news.zdnet.co.uk/internet/security/0,39020375,39170374,00.htm

===============
3. FSA update

Back in December 2003 the FSA issued a Discussion Paper on fraud –
DP26: Developing our policy on fraud and dishonesty. It is
available at http://www.fsa.gov.uk/pubs/discussion/26/index.html.
In a recent speech Philip Robinson outlined the conclusions that
have been reached, and described the FSA’s new approach, called
Fighting Fraud in Partnership. The speech is available at
http://www.fsa.gov.uk/pubs/speeches/sp208.html.

From a risk management point of view, fraud is a significant
component of operational risk. Apart from the rare, high profile,
high loss cases such as BCCI and Barings, there is a great deal of
high frequency, low impact fraud. The ABI estimates that fraud
losses account for 3.7% of all insurance premiums, for example.

Robinson said that firms are not taking fraud as seriously as they
might. “But even when fraud mitigation is good business, it doesn’t
always follow that a firm will do it well. A project that we did
recently on insurance claimant fraud threw this into sharp relief
for me. In thirty small and medium-sized firms who responded to our
survey, every £1 they spent on fraud prevention yielded £3.80 in
savings; and yet fraud budgets were tight, with 71% of the firms
having no earmarked fraud budget at all.”

New consultation and discussion papers out this month:
—————————————————–

CP04/15 Quarterly consultation (No. 2)
CP04/16 The Listing Review and implementation of the Prospectus
Directive – Draft rules and feedback on CP203

Feedback published this month:
—————————–

CP203 See CP04/16 above
PS04/21 Regulatory fees relating to mortgage and insurance
mediation regulation – Feedback on CP04/4 and CP04/9 and
made text

Current consultations, with dates by which responses should be
received by the FSA, are listed at
http://www.fsa.gov.uk/pubs/2_consultations.html

===============
4. You don’t have to be a rocket scientist

Maybe you remember all the excitement back in September about the
Genesis space probe, which was going to be grabbed by stunt pilots
as it parachuted to earth. Unfortunately the parachutes didn’t
open. We now know that the switches that were to trigger the
parachute were installed upside down. It appears that the design
drawings were faulty.

http://www.newscientist.com/news/news.jsp?id=ns99996541

This is a superb example that everything has to be right for things
to work: in this case, the implementation was OK but the
specification was wrong. This principle applies to financial models
as well as spacecraft. I gave a talk at the GIRO conference (annual
convention of general insurance actuaries in the UK) a couple of
weeks ago about how to believe your models. The slides are
available from http://www.louisepryor.com/show.do?page=articles.

You may not have to be a rocket scientist to operate a fax machine,
but it seems that being a lawyer isn’t always good enough. A lawyer
put a 100 page document in the fax machine the wrong way up,
and so faxed 100 blank pages through to the destination. The
document wasn’t received by a deadline, and an appeal succeeded
against fines worth 100m euros.

http://news.zdnet.co.uk/business/legal/0,39020651,39170375,00.htm

A new version of the World Bank Technology Risk Checklist is
out. From the introduction: “The World Bank Technology Risk
Checklist is designed to provide Chief Information Security
Officers (CISO), Chief Technology Officers (CTO), Chief Financial
Officers (CFO), Directors, Risk Managers and Systems Administrators
with a way of measuring and validating the level of security within
a particular organization.”

It’s available from
http://www.infragard.net/library/pdfs/technologyrisklist.pdf
Strangely, I haven’t been able to track it down at the World Bank
site. Maybe it’s a fake. But it looks as if it may be useful,
anyway.

===============
5. Newsletter information

Newsletter Old site

Newsletter Sep 2004

Post author By Louise Pryor
Post date 30 September 2004

News update 2004-09: September 2004
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe@louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe@louisepryor.com.
Newsletter archived at http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Actuaries and financial modelling
2. Financial web sites
3. FSA update
4. Portable risks
5. Newsletter information

===============
1. Actuaries and financial modelling

What do actuaries do? A question that has often been asked, and
sometimes even been answered. We now have a new answer from
Australia, where it appears that there is growing actuarial
involvement in project finance. A paper was recently presented to
the Institute of Actuaries of Australia Financial Services Forum on
“Financial Modelling of Project Financing Transactions”. It’s well
worth a read if you are involved in any sort of financial
modelling, whether or not you are an actuary and whether or not you
are modelling project financing.

The paper includes an analysis of the risks of models and some
ideas for managing the risks, gives a clear introduction to Monte
Carlo simulation and why you might use it, and has a section on why
actuaries might be good people for modelling project financing.

It also includes some statistics on the error rates the authors
have found in spreadsheet models of project financing. The authors
say “Research has shown that error rates in project financing
models can be as high as 10%. Section 5 of this paper provides
some statistics on error rates collected by Mercer Finance & Risk
Consulting. Out of the thirty highest value projects reviewed
during the 2004 financial year, nine (that is, 30%) exceeded the
10% threshold; four exceeded the 15% threshold; and one exceeded
the 20% threshold.”

The wording may be misleading here. They are not saying that, for
example, 10% of the models have errors. In fact, all the models
(100%) that they reviewed contained errors. They are saying that in
four of the models they reviewed over 15% of the unique spreadsheet
formulae contained errors, and that one model had errors in over
one in five of the formulae. This model was one of the smaller
ones, too, so it’s no use saying “it’s only a small model, so it’ll
be OK”.

Although the spreadsheets they reviewed were all modelling project
financing, there is absolutely no reason to suppose that the high
error rates are peculiar to the project finance field. Financial
models of any sort are complex, and it’s hard (but not impossible)
to write a spreadsheet that doesn’t contain errors.

So let me say, once again, that it’s important to get the process
right when developing financial models (whether using a spreadsheet
or specialist modelling software). Be clear what it is that you
want the model to do: write a specification that is detailed enough
to test against. Use appropriate techniques when building the
model: something that looks like a really cool way of doing things
may be difficult for other people to understand. Document the
design decisions you make. Use a good change control process to
keep track of what’s going on. Test the implementation against your
specification. Record the tests, so that other people have some
reason to believe you when you say the system has been tested. And,
above all, don’t trust yourself. You are bound to make mistakes in
the coding, and if you don’t look for them you won’t find them.

http://tinyurl.com/67aot

===============
2. Financial web sites

Phishing is big business. A recent survey says that US consumer
losses as a result of phishing scams have reached approximately
$500m (I always long to know how they come up with these
numbers). Apparently 70% of respondents had visited a spoofed
web site and 15% had disclosed sensitive information.

http://www.theregister.co.uk/2004/09/29/phishing_survey/

Obviously phishing is a risk to the consumer but it’s also a risk
to the financial institution that’s being spoofed. This is widely
recognised now, and many web sites warn their users of the
dangers. The trouble is that people don’t read the warnings (I only
read them myself from a professional point of view, because I’m
interested in risk management issues).

Another survey (it appears to be survey season at the moment)
claims that 90% of commercial web sites have security flaws that
make them vulnerable to online hackers and phishing attacks. So
maybe the dangers aren’t recognised quite as widely as they should
be. However, this figure is based on the web sites that a security
consultant was asked to audit, so there may well be an element of
self-selection here.

http://www.finextra.com/fullstory.asp?id=12548

All in all, the user experience of financial web sites is sometimes
distinctly sub optimal. An Australian bank found that customers who
had installed Windows XP Service Pack 2, the update from Microsoft,
wouldn’t be able to use their online services.

http://www.finextra.com/fullstory.asp?id=12435

Often, you can only use the online services if you use
InternetExplorer on a Windows machine. Admittedly the proportion of
people who use different browsers or different operating systems is
small, but the absolute numbers are quite large, and there’s a lot
of ill will involved. This is especially the case when the users
are using another browser because they have impaired sight or
another disability.

Sometimes sites are unusable for other reasons: recently an online
payment site was down because of a denial of service attack.

http://www.finextra.com/fullstory.asp?id=12538

So the risks involved in running a web site providing online
services can be significant. On the other hand, the risks of not
doing so can’t be ignored either. What is a poor bank to do?

===============
3. FSA update

For the first time since I started this newsletter in December
2002, we have gone for a full month without either consultation
papers or feedback being published. The supply of final notices
shows no sign of abating, though. And those FSA folk keep on making
speeches. The range of newsletters is growing: this month we had
the third General Insurance Newsletter
and the first
Life Insurance Newsletter
.

There has been fairly full press coverage of the FSA’s views on
what’s happening in closed funds, but I haven’t seen many comments
on a speech John Tiner made recently, entitled “Ambiguity of
Contracts: Lessons learned from Equitable Life”
. Interestingly
enough, this speech was actually made in Denmark. Go figure.

From a risk management perspective, one of the most important
lessons to learn is that the world doesn’t stay the same. Changes
in social attitudes, which tend to have a fairly long time scale,
affect both legal interpretations and the regulatory
environment. Moreover, courses of action that are reasonable in
some circumstances become perceived as unreasonable in others. All
these changes take place gradually and continuously. It’s difficult
to pinpoint the exact moment at which attitudes and circumstances
make a course of action untenable.

This kind of risk is extremely difficult to manage. It’s hard to
step back and see the long term trends. It’s often hard even with a
moderate degree of hindsight. As so often in risk management, a
creative imagination is a huge advantage.

New consultation and discussion papers out this month:
—————————————————–

None

Feedback published this month:
—————————–

None

Current consultations, with dates by which responses should be
received by the FSA, are listed at
http://www.fsa.gov.uk/pubs/2_consultations.html

===============
4. Portable risks

What do you do if you are a consultant from an identity management
firm and your laptop is stolen while you are at a security show? Go
very red indeed?

http://tinyurl.com/4p3ok

We aren’t told whether there was sensitive data on the laptop, and
if so whether it was encrypted or protected in any way.

Yet another survey by yet another security firm has discovered that
PDAs are a big security risk. It comes as no surprise to me that
many people store the names and addresses of corporate customers on
their PDAs with no encryption. “As well as using their PDAs to
store company information, many users store valuable personal
information such as PIN numbers, bank account details, social
security numbers and even lists of passwords, many of which can be
accessed – ironically – without a password.”

This isn’t news. We’ve seen similar surveys in the past, and anyway
it’s obvious that this is what’s happening.

http://www.theregister.co.uk/2004/09/01/pda_sec/

Every so often we see a scare story about such and such an
establishment banning iPods, or Palms, or something else from their
premises on the grounds that they are a security risk, because you
can download data to them. Of course you can. And yes, in that
sense they probably are a (small) security risk. However, if I
wanted to download data I personally would choose a USB flash
drive. Much smaller, no special cables or docks required, and you
can get them with pretty large capacities nowadays (1 gig for 100
pounds plus VAT at Crucial ).

In the good (or bad) old days, corporate PCs would have their
floppy drives disabled, no CD drives, and all other unnecessary
ports blocked. Nowadays, when the keyboard and mouse use USB
instead of PS2, you can’t block all USB ports. A flash drive
doesn’t need any special software to be installed, either.

===============
5. Newsletter information

Newsletter Old site

Newsletter Aug 2004

Post author By Louise Pryor
Post date 26 August 2004

News update 2004-08: August 2004
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe@louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe@louisepryor.com.
Newsletter archived at http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Spreadsheets on the way out?
2. Mandelbrot
3. FSA update
4. Summer risks
5. Newsletter information

===============
1. Spreadsheets on the way out?

A recent survey of “business leaders” indicates that many companies
would like to reduce their reliance on spreadsheet based accounting
processes. 80% of the respondents said that spreadsheets should not
be the foundation for critical accounting processes.

“When asked what major risks are associated with spreadsheet-based
processes, 63 percent pointed to the fact that they are prone to
errors, 58 percent cited the lack of audit trail and 56 percent
said they lacked internal controls. Only 5 percent claimed that no
risks existed.” I’d say that 5% of the respondents are living on
another planet. However, the implication that the more automated
processes that may replace spreadsheets are risk free is
unwarranted. Moreover, it is possible (though difficult) to
construct spreadsheet based systems that have effective controls.

We also have to wonder how the view that spreadsheets should play a
smaller role in accounting processes will actually translate into
action. The road to hell is paved with good intentions, and
spreadsheets are notoriously addictive. I am willing to bet that
even as new automated systems are introduced to replace existing
spreadsheets, further spreadsheets will emerge to supplement the
new system. And that’s supposing that the new systems are actually
introduced.

http://www.revenuerecognition.com/article/1,5738,282||S,00.html

===============
2. Mandelbrot

You’re probably familiar with the name Mandelbrot in connection
with fractals, especially the Mandelbrot set. Over his career he
has shown that fractals can be found in many places in nature,
leading to entirely new fields of exploration in chaos theory.

He’s been looking at the variation of financial prices since 1960:
see http://www.math.yale.edu/mandelbrot/webbooks/wb_fin.htm. In his
latest book he uses fractal geometry to propose a “new, more
accurate way of describing market behavior.” The description goes
on to say that “With his fractal tools, Mandelbrot has gotten to
the bottom of how financial markets really work, and in doing so,
he describes the volatile, dangerous (and strangely beautiful)
properties that financial experts have never before accounted
for. The result is no less than the foundation for a new science of
finance.” Don’t you just love the understated elegance of book
blurbs? And the respect they show to other practitioners?

He’s also called for some of the money set aside for “independent
research” in the April 2003 settlement to be spent on fundamental
research into financial markets. He says “Let the Wall Street
settlement help to fund an international commission for systematic,
rigorous, and replicable research into market dynamics.”

The (Mis)behavior of Markets: A Fractal View of Risk, Ruin and
Reward by Richard L. Hudson, Benoit B. Mandelbrot

http://www.wired.com/wired/archive/12.08/view.html?pg=2

===============
3. FSA update

Although the rate of publication of consultation papers and policy
statements has slackened off, there are plenty of other
publications. Sometimes research is published as an Occasional
Paper, sometimes as part of a consultation paper, but this month
saw a Dear CEO letter outlining the results of a review of credit
risk management in life insurance firms. This builds on the paper
issued in October 2003: “Review of UK insurers’ risk management
practices”. The Dear CEO letter outlines a number of areas in which
weaknesses were found, although it does say that the project
findings generally indicated that credit risk is well managed in
the life insurance sector. Some of the weaknesses are very specific
to credit risk, though others can be generalised to other areas of
risk.

http://www.fsa.gov.uk/pubs/ceo/credit_risk_9aug04.pdf
http://www.fsa.gov.uk/pubs/other/review_ins_risk.pdf

New consultation and discussion papers out this month:
—————————————————–

CP04/13 Quarterly consultation (No. 1)
CP04/14 Treating with-profits policyholders fairly – Further
consultation, feedback on CP207 and near-final text

Feedback published this month:
—————————–

None – but see CP04/14.

Current consultations, with dates by which responses should be
received by the FSA, are listed at
http://www.fsa.gov.uk/pubs/2_consultations.html

===============
4. Summer risks

This newsletter is shorter than usual because it’s a reasonably
effective way to mitigate the risk of not having enough time to
write it. On this occasion I can’t quote Pascal, who wrote “I have
only made this letter rather long because I have not had time to
make it shorter.” Or maybe Pascal was quoting someone else – see
http://berbenar.notlong.com .

===============
5. Newsletter information

Newsletter Old site

Newsletter Jul 2004

Post author By Louise Pryor
Post date 28 July 2004

News update 2004-07: July 2004
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe@louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe@louisepryor.com.
Newsletter archived at http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Upgrade has knock-on effects
2. Fraud prevention
3. Gene databases corrupted by Excel
4. FSA update
5. Other sources of information
6. Newsletter information

===============
1. Upgrade has knock-on effects

Citibank UK have been having problems with their current
accounts. Apparently there was a large systems upgrade which
caused a number of problems, resulting in an increase in the volume
of calls to their call centre, recently transferred to India from
Spain. The centre couldn’t handle all the calls without delays,
resulting in further complaints from customers.

Yet again we see one problem triggered by another. The call centre
probably would have been fine without the high volume of
calls. From the sound of it, the problems causing the calls were
pretty significant: direct debits changing their value to
&poound;999,999.99 (that would certainly send me into overdraft), debits
happening twice, and ten year old addresses being used.

I know how difficult it is to test every last detail, but you would
really think that they would have ironed out the major problems
before going ahead with the upgrade.

The situation probably wasn’t helped by the letter of apology that
was sent out to some of the customers who complained. It said that
it was only a very small group of customers who were significantly
affected. The implication is that the problem is less serious
because few people were affected. If I was one of those people,
this would not go down particularly well. The problems may not be
serious for the bank, but they are extremely serious for the
individual customers concerned.

http://dotkised.notlong.com
http://rewhaite.notlong.com

===============
2. Fraud prevention

Another bank, who shall remain nameless, appears to be doing little
to prevent fraud. About six weeks ago I received a call asking me
if I had recently used my Switch card at a petrol station in the
Isle of Dogs. I hadn’t, and answered accordingly. I was told that
there was a fraud operating and that I should go to my branch to
report it. I did that and they destroyed the Switch card and said
that they would issue a new one which duly arrived. There had been
about three fraudulent uses of the card, to a total value of about
£60. Apparently the fraudster had somehow got hold of my card
details; I couldn’t work out how, as it’s not a card very much. It
was annoying, but not serious, and I assumed that once the bank
credited my account for the fraudulent transactions the episode
would be over.

The other day I received my bank statement. It had the expected
credit, but also included three more purchase at the same petrol
station. These were all dated well after the original report of the
fraud. I haven’t actually used the new card that I was sent yet. So
I trotted off to the branch again to report the fraud. I was told
that the fraudsters were probably still using the old card number.

This appears to mean that stopping the old card made no difference
whatsoever. Surely a bank can spot a transaction that uses an
invalid card number? The only other explanation is that the new
card details were used, in which case the only possible source was
the bank itself. Either way, the bank isn’t doing much to prevent
fraud. The amounts involved aren’t large, but it doesn’t really
give me much confidence in the bank’s ability to get other things
right.

It’s a pity I can’t just tell the bank that I will never use the
card to buy petrol in the Isle of Dogs (given that I live 400 miles
away, and don’t have a car, this shouldn’t be a difficult promise
to keep).

===============
3. Gene databases corrupted by Excel

Apparently some long standing problems with Excel are wreaking
havoc in the world of bioinformatics. Well, causing a few problems,
anyway.

As many Excel users know to their cost, it tries to be very clever
when importing data by recognising dates and converting them to
date values. So if the string “1 Dec 2004” is encountered, it is
converted into a date serial number (in this case 38322) and
formatted as a date (for example, as 01-Dec-04, or 1/12/2004). This
conversion is irreversible: the original string is completely
replaced by the new date.

There are about 30 standard gene names that Excel interprets as
dates. If data sets that include these names are loaded into Excel,
the names are garbled and the data sets corrupted.

Excel also automatically converts strings that it believes are
floating point numbers. For example, the string “2310009E13” is
converted to the number 2.31E+13. Again, the conversion is
irreversible. There are approximately 2,000 commonly used
identifiers that fit this pattern.

It is possible, although not easy, to avoid these automatic
conversions, but you have to remain vigilant. You can’t turn them
off, but have to take special steps each time you import data. Some
solutions are described by Microsoft in
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q214233.
There is further discussion in the paper that describes the
problems, which is available at
http://www.biomedcentral.com/1471-2105/5/80#B5

The problems are not, of course, limited to the world of
bioinformatics.

===============
4. FSA update

For many readers of this newsletter, the biggy this month was the
release of PS04/12, which gives feedback on CP190, CP195 and
CP202. I’m sure you’ve all read it!

There’s a new occasional paper out this month: What determines how
much capital is held by UK banks and building societies? It’s
available at http://www.fsa.gov.uk/pubs/occpapers/op22.pdf. The
title pretty much describes what it’s about. Many banks and
building societies in the UK hold levels of capital significantly
in excess of the minimum regulatory requirements, and the paper
discusses why this might be so. Although as a generalisation
insurance companies are not currently as well capitalised as banks,
it seems to me that much of the discussion might apply to them too.

New consultation and discussion papers out this month:
—————————————————–

CP04/12 FSMA 2 Year Review: Financial Ombudsman Service July 2004

Feedback published this month:
—————————–

PS04/16 Integrated Prudential sourcebook for insurers
PS04/17 The Market Risk Module – Feedback on CP206 and ‘made’ text
PS04/18 Changes to the FSA’s Complaints Scheme – Feedback on CP04/6
and made text
PS04/20 Financial groups – Feedback on CP204 and made text

Current consultations, with dates by which responses should be
received by the FSA, are listed at
http://www.fsa.gov.uk/pubs/2_consultations.html

===============
5. Other sources of information

The availability of information is one of the really good things
about the internet. However, if you don’t know it’s there you can’t
use it. Here are a number of web sites, mailing lists and
newsletters that I use. Some newsletters are chatty, like this,
others include only headlines that point to fuller
discussions. Whether you find these interesting will probably
depend on how much your interests overlap with mine.

If you know of any other sites that I might be interested in, do
let me know.

European Spreadsheet Risks Interest Group. Includes an archive of
spreadsheet horror stories.
web site http://www.eusprig.org
mailing list http://groups.yahoo.com/group/eusprig
or send email to eusprig-subscribe@yahoogroups.com

B2-ORM is an international email user group focused on the sharing
of information on the implementation of Basel II compliant
Operational Risk Management solutions in the Financial Services
industry.
mailing list http://finance.groups.yahoo.com/group/b2-orm/
or send email to B2-ORM-subscribe@yahoogroups.com

Risks digest. Forum On Risks To The Public In Computers And Related
Systems. Long running newsletter (since 1985).
web site http://catless.ncl.ac.uk/Risks
newsletter http://www.csl.sri.com/users/risko/risksinfo.html

The Register. “Biting the hand that feeds IT”. General IT
news. Daily and weekly newsletters available.
web site http://www.theregister.co.uk/

The Opera operational risk open discussion group. Allows users to
debate and discuss any aspects of operational risk with other
professionals.
mailing list http://finance.groups.yahoo.com/group/operationalrisk/
or send email to
operationalrisk-subscribe@yahoogroups.com

News on legal and IT issues from Masons. Weekly email update
available.
http://www.out-law.com/php/news.php?area=news

Systems Modelling Ltd. Patrick O’Beirne’s site, mainly covering
spreadsheets and risk management
web site http://www.sysmod.com/
newsletter http://finance.groups.yahoo.com/group/EuroIS/
or send email to EuroIS-subscribe@yahoogroups.com

Banking risk. Weekly email update available.
http://www.bankingrisk.com/

Financial technology issues. Daily and weekly email updates
available.
http://www.finextra.com/

Erisk risk briefings. Monthly email update available.
http://www.erisk.com/

Langalist. Twice weekly newsletter covering hardware and software
for PC users.
web site http://www.langa.com/newsletter.htm

ZDnet. “Where Technology Means Business”. A wide range of
newsletters available.
web site http://www.zdnet.co.uk/

===============
6. Newsletter information

Newsletter Old site

Newsletter Jun 2004

Post author By Louise Pryor
Post date 29 June 2004

News update 2004-06: June 2004
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe@louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe@louisepryor.com.
Newsletter archived at http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Bank computer system fails (again)
2. Costs of compliance
3. FSA update
4. Bits and pieces
5. Newsletter information

===============
1. Bank computer system fails (again)

We hear about major computer failures in banks once or twice a
year. The latest one was in Canada, where the victim (or culprit)
was the Royal Bank of Canada. As the Globe and Mail put it “the
accounts of 10 million customers were rendered inaccessible in a
nanosecond by a monster computer glitch.”

The bank’s technology chief explained the whole thing. “It was a
program change. The guy made some mistakes. I mean, he made some
mistakes with respect to how he went through the testing process
with respect to it. It appears, as we’re going through this, that
it didn’t get tested as fully as it should have been and, as a
result, it created the problem. So, essentially, what you have is a
piece of code that ends up having a character in a field that it
shouldn’t be in. That change ends up setting off a sequence of
events.”

As I understand it, a change was made to one of the programs
comprising the system. There was a bug in the change, which was not
caught by testing. The bug showed up during the nightly batch
runs. After fixes, they then tried to run two days worth of
transactions in the same batch run. This didn’t work because the
system couldn’t cope with two different dates in the same run. It
took days to catch up; and meanwhile customers were getting more
and more upset.

I’ve said it before, and I’ll say it again, you can’t rely on only
one thing going wrong at a time. The problem with running a batch
job containing two dates was lying in wait: only when something
else had already gone wrong would it leap into action. As a
correspondent recently said in another context, relying on Murphy’s
Inverse Law (that everything that can go right WILL go right) is a
common error of judgement.

As is often the case, an operational loss was compounded by
reputational issues. It apparently took several days for the bank
to admit that there was a problem, and members of senior management
set off on pre-arranged holidays and business trips even after the
scale of the crisis had become apparent. Now it may well be that
there was nothing useful they could have done, but it just doesn’t
look good. This point is also becoming a regular theme in these
newsletters.

Finally, and this really wasn’t the bank’s fault, there was a major
phishing scam targeting their customers just as the whole
imbroglio was finally sorted out. Did I mention that it’s never
only one thing that goes wrong at a time?

Globe and Mail coverage is at the following URLs:
http://tinyurl.com/227ln
http://tinyurl.com/2bbzd
http://tinyurl.com/39qls

There’s an interesting write up at
http://www.bankingrisk.com/analysis/archives/2004/06/18/testing_times

===============
2. Costs of compliance

I work mainly in the insurance industry, and am aware of just how
much effort is going into complying with the new regulatory regime.
Many firms are making major investments in new models or bringing
old ones up to scratch. Others (or the same ones) are looking at
how they use their models, and whether they can really trust the
results. Are the systems and controls for maintaining and updating
the model adequate? What about data and assumptions? What do they
do about specification and testing?

There is a view that it’s about time too, and that the benefits to
management of having more accurate and reliable models will
outweigh the costs (and remember, there are opportunity costs as
well as the money that has to be spent). Others think that it’s all
pointless box ticking. The truth, as usual, probably lies somewhere
between the two (closer to the first, I believe), but those who
think it’s pointless will probably see fewer of the potential
benefits.

Not surprisingly insurance firms aren’t the only ones affected.
Apparently 40% of Barclays’ IT investment spend goes on regulatory
compliance programmes for Basel II and Sarbanes-Oxley. A recent
survey indicated that two-thirds of banks with assets over US$100
billion project costs of more than 50 million euros for Basel
II. The same survey claims that most banks see significant benefits
from Basel II and that they are planning to adopt the advanced
regulatory approaches for both credit and operational risk.

Sarbanes-Oxley is spreading its net widely, as it applies to many
non-US companies by virtue of relationships they have to US
corporations. Its main effect is in the area of systems and
controls and directorial responsibility, so adding to the weight of
pressure in that direction. At least one head has already rolled,
or is about to roll, as a result of Sarbanes-Oxley. A large US
corporation’s internal auditors were unhappy with the controls in
the IT department, which they viewed as not meeting the
requirements of Section 404, which is starting to take effect this
year. The CIO is now paying the price.

The whole question of systems and controls is a hot issue, both in
IT departments and elsewhere. After all, IT systems are developed
in many parts of the organisation, not only in IT departments.
Which brings us back to the beginning; what are actuarial models,
if not IT systems? And just think of all those spreadsheets…

The IT Governance Institute (ITGI, http://www.itgi.org/) has a
useful document entitled “IT Control Objectives for
Sarbanes-Oxley”. Although primarily intended for IT specialists,
others may well find it useful.

http://www.louisepryor.com/papers/confident.pdf
http://www.computerweekly.com/articles/article.asp?liArticleID=131260
http://revveday.notlong.com
http://www.it-director.com/article.php?articleid=11982

===============
3. FSA update

The FSA and HM Treasury have issued a joint consultation document
on the UK Implementation of the EU Market Abuse Directive
(Directive 2003/6/EC). This is available at
http://www.fsa.gov.uk/pubs/other/eu_mad.pdf.

The supply of consultation papers and feedback is definitely drying
up; this is only to be expected as the FSA is no longer a new kid
on the block. One would definitely hope that the major regulatory
changes had been mapped out by now. It is interesting to note that
the two largest categories of publication this month are Final
notices and Other FSA publications. Again, it’s not unexpected to
see more disciplinary activity as the system matures. And who gets
a filing system absolutely right at the beginning?

New consultation and discussion papers out this month:
—————————————————–

CP04/10 Child Trust Funds
CP04/11 A basic advice regime for the sale of stakeholder products

Feedback published this month:
—————————–

None

Current consultations, with dates by which responses should be
received by the FSA, are listed at
http://www.fsa.gov.uk/pubs/2_consultations.html

===============
4. Bits and pieces

You may have noticed that I’ve used two different URL shortening
services in this newsletter: notlong and tinyurl. I really have no
particular view on which is better, but one of them was unavailable
while I was writing one of the articles, so I used the other. I
only hope they are both working when people try to click through on
the links.

Why use them at all, I hear you ask. Well, when a URL is too long
to fit on one line there are two possibilities. Either your mail
reader wraps it round, which looks messy, or it automatically
inserts a line break, which means that it won’t work as a link. And
some URLs are very long indeed. They have long, long code numbers
embedded in them, which often carry useful information (such as the
date of the article they refer to), on top of deep directory
trees. I always include the URL as plain text because this is a
plain text newsletter.

This is a plain text newsletter for a number of reasons. Everybody
can read plain text. There are still some people out there who do
not have html mail readers, for one reason or another. Because most
spam uses html, some people simply block all html mail. Many more
people read their email as plain text, even if it is sent as html
(I do this myself). Again, this is an anti-spam measure; spammers
often include spy-ware in the html mark-up of their mail, so that
they can tell who has read it and keep them on the list. Finally,
I’m just a plain text sort of person, concentrating on content
rather than form.

Talking of spam, we all know how much of a problem it is, but do
you know what problems anti-spam and other security measures can
create? Some ISPs do hidden spam blocking; they just dump messages
that they think are spam, without telling you about it. So you
don’t even know about the false positives. There have been a couple
of occasions recently when a client tried to send me a spreadsheet
for review, but the firewall at his end blocked the email without
telling either him or me. It’s this silent operation which is
dangerous.

===============
5. Newsletter information