SSL0000129
$SL0000129
Post Office Audio File 13017
(Audio begins mid sentence)
RON:
IAN:
RON:
IAN:
RON:
IAN:
RON:
finished up as 136.
[overspeaking] 150. Some were rejected on various
grounds. The bulk of our work occurred during the
mediation scheme and as we were working towards what
became known as our Part 2 report, the Post Office wound
up the mediation scheme and we were given a relatively
short period to finalise our report, which we then did.
And the Post Office terminated our engagement at that
point.
We were subsequently engaged on a modified basis
to continue work on a small number of cases, which we
continued to do. But that only took a few months and at
that point we were required to destroy all of our
documents, hand in such documents that did exist back to
the Post Office and that was really the end of our
involvement.
The only thing I would add to that, Ian, is that
I think it is rather important -- because you will have
seen in the reports -- mentioned in the Post Office's
reaction to a couple of matters and the progressive
narrowing of the scope, which was initially quite
narrow, then it got wider, then it narrowed down again.
Specifically in regard to criminal matters.
What was abundantly clear from the meetings we had
with the MPs and in particular with Arbuthnot
[overspeaking] what was vital that you know is that the
primary focus of the MPs was to have us look for any
evidence of improper conduct.
But that's outside the scope --
That's outside the scope of today.
We mustn't go there at all.
I'm very clear that the constraints are we mustn't
mention anything to do with criminal prosecutions, civil
cases, cases that aren't in the action and anything to
do with privileged documentation; very clear on that.
But it is vital that you understand that the scope got
wider and then narrowed off very substantially.
IAN:
SSL0000129
$SL0000129
Okay.
ROBERT: (inaudible).
IAN:
Okay. Are you content with that?
ROBERT: I suppose the general question I want to ask before
RON:
IAN:
we go any further is, reading your reports, there is not
a huge emphasis -- like you said the IT was a small part
of it -- and you get the impression from your report
that you kind of drilled down on the IT and you were
talking to these subpostmasters, getting their side of
the story and writing up the circumstances and so forth.
What I expected to hear is kind of an abstraction of
their viewpoint of what happened, rather than anything
behind the scenes in Horizon. Is that correct?
Yes.
I will comment a little on that. There were areas
where we did drill into the technical aspects of Horizon
in quite a lot of detail. However, Post Office and
Fujitsu had difficulty providing some of the data to us.
One of the key meetings that I had was with Gareth
Jenkins at Fujitsu, who was incredibly helpful; was the
architect of really the whole system over many years,
knew it sort of absolutely backwards and was very
helpful to us in terms of explaining the infrastructure
and explaining the control environment and explaining
change control and so on.
One of the things that we did identify at a fairly
early stage was that the -- what we called, and what
Horizon and Fujitsu have called the XML data was at the
heart of really understanding what was going on. We can
perhaps pick this up later on. It is covered in your
list of questions. But one thing that we did identify
was that, even if there was a major issue and
a subpostmaster was calling for all of the data that was
possibly available, they were never given the full XML
data and it was only the full XML data that held all of
the relevant transactions.
Because what became obvious was that a lot was
going on underneath the surface that was not disclosed
to subpostmasters arguably because they didn't need to
know. These were sort of back office processes.
But one of the issues that was raised with us was
so-called mysterious out of hours transactions that were
2
RON:
IAN:
SSL0000129
$SL0000129
changing balances from a subpostmaster's perspective.
We could see via the XML data that there were system
level, let's call them corrections or transactions --
Or reversals, Ian, remember some of them were
reversals? We picked up some --
Well, reversals is a misleading term because of the
way that the XML data was processed. One of the points
that Gareth Jenkins emphasised was that there was
a detailed audit trail, there were sequence checking
controls and what is commonly referred to as a reversal
is actually not a reversal. There would be
a corresponding debit or credit transaction posted by
Fujitsu, by Horizon, but with a completely separate
unique reference number, that had the effect, in
accounting terms, of either cancelling out a transaction
or reversing it or whatever the intended purpose was.
My point is that subpostmasters never got access to that
level of detail.
JASON: Did you get to see XML data that showed those out of
IAN:
RON:
hours transactions?
Yes, and one of the documents, which I think has been
circulated, was a spreadsheet. A so called unreadable
document. A number of those documents in that
spreadsheet were the core XML data transactions that
were disclosed to Post Office by Fujitsu at our request.
We identified a number of branches where issues had
occurred and typically we would ask for a month's worth
of data. That was provided by way of XML files.
Yes, okay.
ROBERT: This is fascinating because to me Horizon started
IAN:
in 1998 and 2000. In those days XML was not on the
scene, XML was just coming in. So my understanding has
been that XML came on the scene in a big way with
Horizon (inaudible) 2010. The question is what time
period is this referring to?
Most of the data that we looked at, partly because of
the retention of data issues, was data that arose fairly
late in the cycle and it may well be that it was
exclusively new Horizon rather than old Horizon.
JASON: It looks like we should be able to get hold of data
that was returned, that you haven't had the opportunity
to look at. Are you able to identify for us where those
3
IAN:
RON:
IAN:
SSL0000129
$SL0000129
particular transactions appear within the XML so we can
go and look at them?
Yes. What you will have to do, quite a lot of what
I would call reverse engineering -- because the XML data
unsurprisingly was quite difficult to decode -- this is
where Gareth Jenkins was -- and he provided us with look
up tables, and other sort of assistance in terms of
helping us to decode the XML data. It took some time.
It probably took two or three months to even begin to
make sense of it. Bearing in mind that at this point we
had, what I like to call, almost sample data, rather
than reeling into specific sort of transactions that
were linked to losses that were identified by claimants.
Unfortunately the way the mediation schemes
developed, at about the point that we thought it had
actually cracked the data problem, the mediation scheme
decided, right, we are going to sort of mediate, almost
put everything on hold, because we have got the case
level reports -- and I'm conscious that we are only
looking at express cases -- we have case level reports
and it was decided that they would attempt mediation on
what was available at that point, rather than us
continue this in-depth deep dive into the data, because
clearly it was agreed it could be reached on that basis
there was no need for any further work.
Ian, as I recall, the availability of the complete XML
data information was pretty well restricted to Fujitsu.
I got this sense, certainly when we were referred to the
ARQ logs, for example, the audit trigger queries. And
whenever we looked at -- if we wanted transactional
history from Post Office, which they were later in the
mediation process generating as part of their POIRs, the
Post Office investigation reports, they would look into
a case and pull transaction details.
What we were seeing there were essentially Excel
spreadsheets which was driven by but was not a complete
record of the underlying transactional data. That's
your recollection too is it Ian?
Not quite. Let me explain that because I sort of took
the lead in terms of the technical data. Fujitsu
developed some scripts that would query the XML sort of
data. So stage one was extracting the raw XML data. If
that was in response either to a request from us, that's
it, they will probably just hand over the data. If it
was in response to a request from Post Office or from
4
SSL0000129
$SL0000129
the subpostmaster or as part of the mediation scheme,
they would then run one or more of these scripts that
produced an Excel spreadsheet that summarised the key
transactions that would have been visible to the
postmaster as part of the branch records.
What we found out later was, when we did
a reconciliation between the two, in other words, the
raw XML data and the Excel spreadsheet that was created
as part of the script, there were huge sort of
differences and this reflected the back office
transactions.
JASON: We had done that only in a very limited form and now
we have filtered data and unfiltered data, so it is the
same transaction period. The filtered data sounds like
the data that would go to the subpostmasters and tidied
up in Excel. We have seen since unfiltered data which
shows, at some level, the almost handshake between the
internal systems, but we still believe that there is
other levels of data -- [overspeaking]
IAN: -- one thing you may want to do is do a sequence check
on the XML data because we found that there were quite
significant sequence gaps, which we had been led to
believe should not occur because the XML data stream was
meant to reflect totality. We never got
an explanation --
ROBERT: Stepping back again to the XML data, which you got,
(inaudible) several years after it had happened. That
presumably was from the audit data, is that right?
[overspeaking]
IAN: That's my understanding.
RON: Sorry, not from the audit team. Okay, yes.
ROBERT: So amongst the audit tools there is a way to pull
back some audit records and examine the XML.
RON: Yes.
ROBERT: Next question is, what sort of time period were you
looking at, was it days or months?
IAN: Typically we would ask for a month's worth of data and
that was sort of a fairly manageable size. There were
a large number of transitions but it was manageable --
ROBERT: This is a bank's branch?
RON: What we would do is look at what we called a hot spot.
We would say a branch is aware of a mysterious shortfall
between that date and that date, sometimes it was as
long as a month, for reasons we are going to get to
later, but normally it would be within a week or several
days. We would add a couple of days either side and
that was our hot spot. And then we would receive the
data on that basis which made sense.
JASON: We now have some of that data which has been
re-extracted. I think we have the ability to have four
months in total, in aggregate across all the cases.
RON: That's indicative of something we came across, which
was that there seemed to have been -- we never saw it --
some contract -- of course there is a contract between
Fujitsu and the Post Office, but we were told many times
that that contract limited the availability of the
underlying data and made it very costly, we were told,
so to seek any more than minimal quantities of raw data.
JASON: We faced exactly that situation and exactly that
argument. I think we are now through that and it has
now become quite a bit easier to get that. Certainly
barriers have moved out the way now, so we now do have
access to the data. We still are not sure whether it is
the true raw data or whether there is any filtering or
not but, it has only just arrived with us.
IAN: If it is the XML data, that was presented to us as raw
data. The one doubt that we had was, when we started
running the sequence checks and we were coming across
gaps, as I say, we never got an explanation for that.
JASON: In the knowledge that you spent a couple of months
doing that and working that out, I'd be keen not to
repeat or reinvent that same wheel that you had
invented, did you keep any or did you hand back any
notes on how you went through that process? Is there
anything I can learn, to short cut my process?
IAN: There may be in some of the raw sort of data that we
handed back to the Post Office, but our instructions at
the time were to destroy everything, notebooks, even
some of the sort of detailed work that we did that was,
for want of a better word, experimental, that probably
has not survived. As I said earlier, we did that in the
so-called unreadable documents list. That includes
6
SSL0000129
$SL0000129
SSL0000129
$SL0000129
a lot of XML data.
CHEVAUGHN: Ian, sorry, earlier you said that if the Excel
IAN:
RON:
sheets were in response to a request from the Post
Office for the mediation scheme and the subpostmaster,
did the subpostmaster get those actual Excel sheets
then?
That was certainly the intention because the sequence
was: subpostmaster suffered the loss, made use of the
various facilities that were available to the
subpostmaster within Horizon, in order to produce sort
of various reports. If they were switched on and
realised that they needed sort of more information, one
of the options open to them, even though this was not
widely known, was to request this more detailed sort of
data, as well as all these sort of mentioned. I think
that was limited to 12 requests per month. That is
certainly what we were told. Over and above that there
were various cost implications and we were also told
that the Post Office refused a number of requests to
provide more detailed data.
Bear in mind that, as far as branch records were
concerned, only 42 days of data was immediately
available. That was then subsequently extended to 60
days. But the business cycle of branch transactions was
such that you could actually -- and bear in mind that
they shifted from weekly to monthly accounting -- you
could quite easily reach those limits and basically run
out of data.
Particularly as regards to TC. TC could come in
moments after the underlying transactional error, and
that could pose a serious problem because if the TC came
in three months after the underlying transaction that
might have caused it, they were pretty well snookered
because they could not draw back even later beyond 60
days and then they had to seek help. And then they
would (inaudible) run into this response: you can't have
help because it costs too much. That was a common
response.
JASON: That's helpful. Robert (inaudible) sensitivity
about getting the right raw data, because if the data
that we have been given and has been extracted from the
(inaudible) database and the extraction has been
filtered to perhaps only include transactions entered at
the branch, then that might show us one view. But if it
is all transactions allocated to that branch account,
7
RON:
SSL0000129
$SL0000129
then that could include transactions that had been
inserted in, potentially the balancing transactions is
probably more like Fujitsu.
You are actually using almost exactly the same words
that we used, in our (inaudible) auditors
[overspeaking]. No auditor worth their life carries out
individual level testing of a population of data until
he or she is assured that the population is complete.
[overspeaking]. So you are exactly -- that's where we
got hung up very quickly. We said, well, we don't
necessarily know that we are looking at the complete
population, why start sampling an incomplete population?
JASON: Of data. And we haven't quite or we haven't yet
IAN:
RON:
IAN:
RON:
cracked that. We have been presented with filtered
data, we have asked for unfiltered data, we have been
given data but we have been told that it is quite not
unfiltered yet. [overspeaking]
One thing that you need to bear in mind was that we
were told that -- and I put this in context slightly --
we were told that had under the contract between Fujitsu
and Post Office, there were financial penalties for --
I use the term transaction corrections, not in the sense
of (inaudible) but adjustments to the data as a result
of, again, using a fairly general sort of term, bugs in
the system.
Errors attributable to Fujitsu.
Yes, because this was felt to be a benefit to Post
Office because it would incentivise Fujitsu to create
robust software and so on. You can understand the
argument. We were told that a substantial number of
Fujitsu employees spent substantial amounts of time
secretly -- again the words that were used to us --
making various adjustments to the data without Post
Office's knowledge, because if they had disclosed this
to the Post Office that would have resulted in financial
penalties. That's -- we were told that on a couple of
occasions.
We never were able to develop that any further but
that's a further possible explanation for some of these
gaps in the audit trail and, again, it is something that
you may wish to fine drill into --
I was told on several occasions by different sources
there is a 30 person team that was working for months on
8
SSLO000129
SSL0000129
end in order to avoid what they said was a £10 per
transaction -- I never validated or verified that --
error charge that would have effectively sort of
(inaudible) Fujitsu.
Now, typical of the sort of error that needed to
be corrected was the calender square issue.
JASON: Which?
RON: There was an error which manifested itself in calendar
square, which was referred to commonly as the calendar
square problem, which, as I understand it -- I'm going
on human recollection here -- a number of payments made
to let's say a water company, finished up in some
Scottish local authority. In other words the payments
went adrift and the reason they went adrift was the data
got mashed. The sort codes of the beneficiary account
numbers of the intended beneficiary --
IAN: Ron, I think it could be misleading if we are doing
this from memory. I would suggest look at the
[overspeaking].
RON: In other words, there was a known problem that Fujitsu
was aware of. They were able to correct it. That I was
told was the sort of transactional adjustment that
needed to take place.
JASON: Certainly one of the documents -- I will send you
a link to the particular document -- but it talks about
Fujitsu making corrections and things like that and they
don't actually need to be brought, those adjustments, to
(inaudible) unless it reaches 100 per day.
ROBERT: You mentioned that.
JASON: So it might well be the case that the Post Office
aren't aware of -- it only hit the high 90s.
IAN: We never saw that.
JASON: But we need help with the context of it because it
talks about up to 100 E/91 errors --
ROBERT: We don't know what the D numbers mean yet.
JASON: We have references to that.
IAN: In the context of that, something which came as a bit
9
RON:
IAN:
RON:
IAN:
of a surprise to us was the fact that, let's call it
live Horizon, new or old it doesn't really matter, we
assumed that the entire sort of population of
subpostmasters would be operating whatever the current
version of Horizon was. At some point we were told, no,
that's not the case. At any point in time there are
multiple -- define multiple -- up to six different
versions of Horizon sort of in operation and that
reflected the sort of maturity of the software, the fact
that it was rolled out incrementally. But it was
a surprise to be told that not everybody was operating
the same version and, therefore, if there were bugs and
errors within a particular software version, it wouldn't
necessarily affect all branches, it would only affect
a subset of branches that had that particular --
Tan, that validated or reinforced the correctness of
the decision we made right at the beginning because the
MPs were saying: we assume you are going to review the
code of (inaudible) and we didn't laugh out loud. We
said, no, I do not think that's going to work.
(inaudible) trial by wire cases and things like that.
We said no, we are not [overspeaking] because there will
be multiple versions of the system and because the
system changes over time --
To be fair we didn't know that at the time. This was
very early on in the scoping negotiations. I think it
was Kayla Nell, who at one point was very keen, raised
the question of the (inaudible) view. Our position was
no -- [overspeaking] look at outputs rather than --
Yes, that was a meeting where she said you guys are
going to do a white wash, you won't be interested in
real current cases that have just occurred and I said,
you are damn --
Ron, we are getting off topic I'm afraid. This is not
about the technical aspects of Horizon, it is more about
our appointment. I think it is outside the scope for
today.
CHEVAUGHN: Did you ever discover whether there was a log
IAN:
which Fujitsu kept of which branches were on what
versions of Horizon?
Yes. One thing Fujitsu I think were very good at was
what I called change control, as you would expect with
their engineering background and so on. My
understanding was they kept very detailed, sort of,
10
SSL0000129
$SL0000129
RON:
IAN:
RON:
SSLO000129
SSL0000129
records as to which versions were deployed when and to
which branches and what the changes were between
versions.
One thing that we thought of doing, but didn't do
in the end, we asked at some point for a dummy system to
be made available so that we could actually test at
desktop level how transactions were processed, what
vulnerabilities existed, if, for example, the phone line
went down. One of the reasons we didn't do that was, it
was at that point that we were told, ah, we need to
decide which version of Horizon you want loaded onto --
Ian, what I was about to say -- you are correct to
interrupt me -- what I was going to say was, right at
the outset, we said it is better to find instances of
allegedly mysterious events and reverse engineer how
they occurred, than to try and look at the totality of
64 million pieces of software.
Yes.
That was all.
JASON: I think our thought process is the same. We have
RON:
got the data, once we can validate that is the right and
full data. We have got a number of reports from
specific, sort of, postmasters about occurrences on
a particular day or week or month. We hope we can trace
back into the reverse engineered data. Then from there,
we hope we can go through Fujitsu's change management
system and find out what version they were on at that
particular point in time. But then I do want to get
that code and find out how that particular thing could
have happened. f[overspeaking].
We envy you Jason because that is the way the
investigation would have gone had it not been for the
mediation scheme, which took it to a slightly, in
a sense, more superficial level.
ROBERT: I personally think, even given a sample case of
RON:
this person had this problem in this year, and even
given the XML and so on, to actual drill down to code
and say this bug did this, I think that is
a tremendously tricky --
Yes. That was fundamental to the whole case. The
Post Office was --
11
IAN:
RON:
IAN:
RON:
SSL0000129
$SL0000129
Ron, don't forget what we said in our report, broadly
accepted by the Post Office, that the majority of errors
were caused by error at the counter and from the
technology perspective, it could be quite difficult to
differentiate between the sort of key-in keyboard type
error and an alleged sort of bug --
And indeed unusual combinations of circumstances,
which it would be very hard to replicate. We might not
even know the circumstances that led to it. Was there
a power cut?
What was quite useful, I think it falls outside the
scope of today, was to look at maybe the controlled
environment at branch level, what system level controls
existed to prevent keying in errors. One thing we were
very conscious of, and saw demonstrated on a number of
occasions was the fact that it was a touch screen and
there was no automatic registration between points on
the screen and icons.
A subpostmaster could think that he was pressing
sort of one icon, but that was actually registering on
the system as something completely different because
there was no automatic sort of screen registration to
deal with that.
That's one of the reasons we made a point about paying
in slips, you probably read it in the report, where we
are saying, when there was a transfer of control of
responsibility from the -- well, to the customer, which
of course is what banks were doing for years, I'm
a retired banker -- when that happened you immediately
subject one party, in this case the subpostmaster, to
the risk that, if the person who has got the sole
control of responsibility happens to have benefited from
the error, it makes it rather less likely that that
person is going to volunteer that information. The Post
Office never got that point. I made that point and said
actually it would be great (inaudible) the control.
They didn't accept that.
ROBERT: Sorry, could you run through that again?
IAN:
Ron, one word of caution, that description falls
outside the scope of today because we are looking solely
at hardware and software issues relating to Horizon.
JASON: We are talking about control measures at the branch
though.
12
SSL0000129
$SL0000129
CHEVAUGHN: Yes, data entry.
IAN:
RON:
Okay.
I will go over it very quickly, (inaudible). In the
old days when one paid in, let's say, £1,000 into your
bank account, you would use a paying in slip and write
£1,000 and get it stamped, £1,000 on a piece of paper
that the bank would process. The Post Office used
exactly the same technique, and I'm talking about
post-Horizon online. This was a Labour change that came
into effect. What they did was say, now you are going
to use cards, swipe your card -- banks do this as
well -- then the counter part keys in the £1,000 and the
customer walks away with a piece of paper. There is no
retained piece of paper in the branch. What that meant
was that the responsibility for picking up an error of
that counter of £1,000 being keyed fell on the customer.
If the customer walked away with (inaudible) with £100
he was okay, because he would come back and say: I paid
in £1,000 and the teller would say, no, you didn't and
so an argument would develop. But in the old days, of
course, that customer would come back with a stamp
paying in slip that said, no, I actually paid in £1,000.
So, in other words, the control degradation for the
customer for the new process but it was worse for the
subpostmaster because the subpostmaster then got
nothing. What had happened before was that there were
controls taking place after the counter transaction,
which were no longer in effect. And so I said, this
is -- I'm a control specialist -- this is a control
degradation. The Post Office in the end said -- first
of all they said, no, it is not and there was a silly
argument. Then they said actually whether it was or
wasn't, it was forced upon us by Santander. We didn't
take that decision. We said, well, what's that got to
do with it?
JASON: That does fall possibly into our number 5. How, if
at all, does the Horizon system itself prepare
transactional data recorded by Horizon against
transactional data sources outside of Horizon? Because
there has to be a reconciliation between the Horizon
system and the amount that the bank had (inaudible) been
withdrawn or paid into an account.
ROBERT: (inaudible) you were talking about (inaudible).
IAN:
It is a point of principle that, certainly, perhaps
I need to understand. I'm looking at the court draft
13
SSL0000129
$SL0000129
order, definition 3, "Purposes of the list of issues":
"The Horizon system shall, for the
purposes of this list of issues, mean Horizon
computer system hardware and software,
communication equipment and financial data to
centers where records of transactions made in
branch were processed."
Now, that is a very narrow sort of definition of
Horizon. I do not think that includes human activity at
branch level other than the example that I have given,
which was keyboard errors, screen errors, icon
registration sort of errors. I do not think that
includes the business processes which actually in our
report we felt were much more significant and were
probably more likely to be the cause of errors, rather
than software bugs in Horizon.
MALE SPEAKER 4: To pick that point up, I think one of the
things you were saying was actually (inaudible) cash in
the branch (inaudible) errors and that comes outside
that.
IAN: This is as very narrow definition. But, as
I understand it, that's the way that the case has
progressed. This trial is looking solely at Horizon
within the scope of this definition, hardware, software
and data processing.
JASON: Yes. I think you are absolutely right what you say
there. So the human handling aspect of it is not
necessarily covered, but we do have a section that talks
about robust controls. So that must include that
validation of the --
IAN: Perhaps we need to understand what you mean by "robust
controls" because that could mean either robust controls
within the software environment or does it take us wider
into business processes?
CHEVAUGHN: I think so because it doesn't specifically say
technical controls.
JASON: So, to what extent is the Horizon system robust and
extremely unlikely to be the cause of shortfalls in
branches?
IAN: As we have said in our report, Horizon's system is
generally speaking robust. The level of errors that
14
SSL0000129
$SL0000129
were identified -- and bear in mind the mediation
process was available to all subpostmasters and former
subpostmasters, 12,000 draft orders or whatever. We had
150 applications. That tends to suggest that the
Horizon system, most of the time, works out as intended
and arguably is a robust system. What we said in our
report was that the -- and I'm conscious that I am
perhaps straying outside this definition -- what we said
in our report was that it was the business processes
that were the cause of many of these sort of problems,
rather than, for argument's sake, software coding
errors.
Even though we did become aware of some
transactions, one was mentioned, sort of calendar and
there were others covered in our reports that did give
rise to some errors, but the biggest problem overall was
the way the Post Office responded to reports of errors,
rather than the causation of errors by this technical
definition of Horizon.
JASON: Yes. I think that latter point is almost certainly
RON:
outside of what we are doing but the other two
aspects --
Jason, this concept of robustness, which is
a comparative phase, how robust is robust? How strong
is a pair of shoes? I spent much of my life designing
and approving bank systems from loans to foreign
exchange and so on; what we observed here was that this
is a system which was used by 68,000 odd users. The
abilities of those users varied enormously. As wide
ranging as you can get. This is like, one wouldn't
expect me to be able to drive a formula 1 racing car and
you certainly wouldn't expect some of the people
operating this system to be able to do that.
This was a system which, in the hands of somebody
that really had huge attention to detail, huge readiness
to work with the (inaudible) shortfalls, was okay. But
for some of the users, particularly those that were
assistants inadequately trained by subpostmasters who
were stumbling around in the dark, the robustness in our
view is not adequate.
We are not here to give our opinion but to recall
what happened. So we found instances where errors would
have been systematically repeated and because the people
didn't know they were making mistakes, they didn't seek
additional training to correct those mistakes. They
15
SSL0000129
$SL0000129
didn't think they were making a mistake. Therefore,
they trained their own staff in that pattern of
processing, which was incorrect, and in some cases
acknowledged by the Post Office as being incorrect. For
example ATMs, Camelot and a number of other issues.
What then happened is, where those errors were
being repeated, and the system wasn't repelling them, we
obviously concluded that the system was -- error
(inaudible) was inadequate for the population using it.
That was all. It doesn't mean to say the entirety of
the system was inadequate. That's why we chose our
words very carefully about determining whether or not
the system was fit for purpose. Most of the time it
was, but for those where it wasn't, there were life
changing consequences.
ROBERT: Do you have in mind cases where the system could
RON:
IAN:
RON:
IAN:
have repelled errors but didn't?
Yes. Well --
Screen calibration. The fact that a SPM would think
he was pressing one icon but the system would actually
register that as a different entry and that was not
necessarily sort of visible to the subpostmaster.
Communication failures. [overspeaking]
An even better example was the recovery process was
awful.
The example we were given where, in some cases,
messages generated by the system were never visible to
the subpostmaster. If there had been a power failure,
for example, the screen would be powered off at the
point that Horizon was displaying a message. It would
be impossible for the subpostmaster to know what that
message was.
Some of the requests generated by the system were
at best ambiguous and were impossible to answer
correctly or in the way that the system intended them to
be answered because the subpostmaster does not have the
necessary information in order to answer.
I think that quite legitimately was a control
failure within the technical aspects of Horizon that had
not been sort of anticipated.
JASON: Certainly a lot of the issues that are noted in
16
SSL0000129
$SL0000129
things like the error log and things like that, relate
to the recovery process of a counter. Lots of --
IAN: Recovery changed pretty fundamentally between old
Horizon and new Horizon. Arguably it was more robust in
new Horizon. In old Horizon there was a polling
exercise between baskets held at various terminals in
a multi-sort of terminal environment and that arguably
was less impacted by communication and, sort of, power
failures because that information was actually held at
the branch.
Under new Horizon that situation didn't occur and
perhaps introduced a different type of vulnerability or
different type of operation.
JASON: So under new Horizon -- sorry to jump in -- what
data, if any, is stored at branch?
RON: Only wild batches [overspeaking] -- been created and
stored and sent. Whereas before, under old Horizon, it
was sent off at the end of each day, so you had a lot of
data being held --
IAN: It wasn't at the end of each day, but there was more
data held locally across multiple sort of terminals.
JASON: Until the polling period kicked in~--
RON: Correct. The other thing, answering Robert's earlier
question on repelling errors earlier on, you will see in
our reports quite a lot about one sided transactions.
This is where we said, if one goes into a bank to put
money in, the totality of the software that the teller
is interacting with is within the bank, whereas we had
this situation where we were encountering situations
where somebody had perhaps paid a tax bill using a debit
card, and one side of the transaction went through and
the other one didn't. In other words, if both sides go
through, that is great, that is the intention. If no
transaction goes through in either system, that's great.
Not as good but not so problematic. But if the customer
gets charged for something that hasn't gone through,
sort of, the water bill doesn't get paid, he finds out
about it. Whereas if the opposite happens and his tax
bill does get paid, but he never sees a debit on his
account, it is less likely that that's going to be
diligently followed up by the customer.
ROBERT: It is a zero sum basket.
17
SSL0000129
$SL0000129
RON: Because the zero sum baskets were in Horizon whereas
the link system was debiting in a separate system. Two
systems running in parallel --
ROBERT: (inaudible) live, isn't it?
RON: So you could get a situation where one side will
[overspeaking]
ROBERT: That is a case of what they call a recoverable
transaction. If you have done something irreversible on
another system and Horizon wants it -- [overtalking].
RON: Yes and no, Rob. (inaudible) if a transaction has
already gone through to the bank, there is no way that
the counter clerk at the Post Office can reverse that.
It is unstoppable. So that transaction has gone
through.
ROBERT: But there is some mechanism for recovering, for
getting to the point where the customer is not screwed.
IAN: Outside of Horizon of course there were
reconciliations and that's a separate area and
[overspeaking]. But under the definition in the order,
that's outside the scope of this trial.
JASON: It can't be, because that has to be covered by how
does Horizon reconcile itself with data --
IAN: Horizon doesn't, is the short answer. [overspeaking].
It is the outputs from Horizon that are reconciled with
other systems, but that's not, as I understand it,
anyway --
ROBERT: I think this comes to the point about the scope of
Horizon, we have to look at that robustness --
RON: You have to. We can do.
JASON: Because in very simplistic terms, if the bank is
saying: you have £10,000 of deposits that were made
today that are due to me, that £10,000 has to go. If
that figure is different to what Horizon says the branch
says has been handed over in cash, there is
a reconciliation --
RON: That's what feeds the suspense accounts. That's where
you get entries in suspense accounts. The simplest
example of this interface between different systems is
18
SSL0000129
$SL0000129
when one looks at ATMs, which is why we concentrated on
them. Taken together, although only as I recall 40 or
so of the cases that we looked at involved ATMs, it may
have been fewer, 36 -- because obviously not all Post
Office branches have an ATM -- the differences, the
discrepancies plus and minus arising from ATMs were,
with the exception of foreign exchange dealings, by far
the largest. They were typically 20,000, 30,000,
40,000. A good example of that we mentioned in our
report that -- Ian pursued this very diligently -- we
wanted to see what the balance was of the Bank of
Ireland suspense account and it was £96 million covering
six months' transactions.
That relates to discrepancies between what the
subpostmasters were saying had been dispensed out of
their ATMs and what Bank of Ireland said had been
dispensed. Now 96 million, assuming 1,000 branches had
ATMs, I don't have the figure, that would be £90,000 per
branch as an average items --
ROBERT: Money gone adrift?
RON:
Yes. It is colossal. Bankers have cleared the suspense
accounts by 7.30 am on the day of the transaction.
That's what I understood. These were six months old and
the point being really that the way -- as we floated the
air gap -- [overspeaking]. Let me refer to the air gap.
This thing that some people have read.
We said isn't it strange that, so there is an ATM,
if you go to Tescos and go to the ATM or Waitrose or
whatever, if you go inside the wall where the ATM is,
there is a brick wall. You can't get to it. It is
serviced by the bank. The bank puts the money in and if
there is a shortfall, the bank suffers the loss. When
the Post Office changed that process, now, the person
responsible for filling the ATM with £144,000 was the
subpostmaster, and the person responsible to count up at
4.30 each day how much was left and to receive from the
ATM its report as to what had happened that day, that
was the responsibility of the subpostmaster.
So there that data had been transmitted
electronically of course to Bank of Ireland. But for
some reason the postmaster had to take the printed
output from the ATM and key it into Horizon and said
today 45,000 was taken out of my ATM or whatever.
What then happened was Bank of Ireland took its
19
SSL0000129
$SL0000129
already supplied (inaudible) reported that to Post
Office, who compared it with what the postmaster said
had happened and in some cases said: you said that
£45,000 was dispensed, we say Bank of Ireland said it
was £65,000.
ROBERT: Are we saying that was a simple transcription error
RON:
IAN:
RON:
IAN:
RON:
IAN:
RON:
in somebody having to read a number and type it?
Could be, there were about four reasons.
[overspeaking] system where completely impossible
numbers were -—
There were billions. There were numbers coming out of
those printouts that were in the billions, completely
daft numbers coming out. Post Office view was, as long
as it was not the cash dispenser figure that was wrong,
it is probably all right. This is where the postmaster
had filled in one of the cassettes, realised he had made
a mistake and put the money in the wrong cassette,
filled it in again, the poor bloody machine didn't know
if it was coming or going and generated false data.
Now, what we said that was --
That wouldn't have produced the errors of the
magnitude that we came --
It did produce some funny numbers, we saw multiple --
The numbers that we saw, that you referred to as
billions, would not have been produced reinserting
cassettes. It is much more likely to be a glitch within
the Bank of Ireland system that was reported by the ATM,
which was never investigated or resolved by
[overspeaking]
What we are saying is [overspeaking]. The way that
was corrected -- and that was the phrase that was used
or regularised -- was that a transaction correction
invoice, a debit transaction TC, would be processed by
Post Office, which was then accepted or otherwise by the
postmaster. If the postmaster, as was many times the
case in the matters we looked at said: I don't know what
you are talking about, that money is not there, I didn't
steal it, so the customers have had it; Bank of Ireland
says, that is not the case; they had to receive that
transaction correction and cover the shortfall. And the
shortfalls typically were 20/30/40,000 or £80,000 in one
instance that we looked at.
20
SSL0000129
$SL0000129
So what we were saying was, it is a bit of
a strained process. Why are you accepting without
question the word of a person from the Bank of Ireland
who you have never met and saying that the person that
is not telling the truth or has made a mistake is the
person who is your appointed agent, who has been there
for 25 years?
I said that is foreign in banking processes
because in a bank -- I know I used to investigate lots
of ATM shortfall cases -- if there is a shortfall in
an ATM, the banks are all over it like a cheap suit
straightaway. And you would say suspicion falls on the
people who had had access to the machine that day. We
would then call other banks in the area and they would
say: funnily enough, we have a shortfall as well. And
they would say: yes we had a shortfall, we thought it
was our teller number 2. If our teller 2 wasn't there
the day another shortfall occurred, so we would
investigate straightaway.
We only came across one case that was investigated
out of all the ATM cases and that we only learned about
after all we had finished our report. In that instance,
a 27,500 pounds ATM shortfall was charged to a very,
very smart, very aggressive, very wealthy person who was
a subpostmaster -- too case specific? Might not be a
claim.
CHEVAUGHN: (inaudible).
RON: Okay. The generality then is that -- I'm only aware
of one case that was investigated in 13 months and the
finding at the end was that the postmaster had not made
a mistake and he was reimbursed.
ROBERT: Can I ask some general questions around that. (1)
when you were investigating ATM problems not to do with
the Post Office, what generally turned out to be the
cause?
RON: External fraud.
ROBERT: Just somebody had some fancy scam?
RON: Yes.
JASON: Whose job it was to refill the ATM --
RON: Sometimes the ATM engineer but most frequently
21
IAN:
RON:
IAN:
SSL0000129
$SL0000129
extraordinarily, elegant hacking cases.
What we could rule out in this case was staff within
Bank of Ireland who realised that whatever numbers they
produced were automatically accepted, were never
challenged by Post Office, because the Post Office's
default position was, if there was a discrepancy, the
subpostmaster was [overspeaking].
If I had been in that process in Bank of Ireland
I would have committed a fraud for sure, I am used to
it. If the fraud can occur it will, and if you can hit
victims that won't be able to retaliate, they get hit.
We said: look, why do you keep believing whatever Bank
of Ireland says has been paid out? And then that, we
would --
This brings us back to [overspeaking]
JASON: It also brings us back to number 5.
IAN:
RON:
IAN:
RON:
Other examples of (inaudible). I have flicked open a
copy of the (inaudible) report. We were aware, as
a result of looking at the XML data and what SPMR told
us, of these mysterious out of hours transactions.
However, the software ignored all of that. The fact
that at 5.30 on a Monday afternoon the branch shut and
then didn't open until 8.30 am the following day, there
was no software control over out of hours transactions.
There wasn't even any sort of error logging or reporting
of those transactions.
And the same person could sign on in two branches at
the same time, for example.
Again another fundamental weakness over the lack of
control over user ids and passwords. We came across
numerous examples of password sharing and a lack of
robustness within the Horizon software that prevented
the same ID being used at multiple locations at the same
time. User IDs were also allocated to the system and
occasionally we would see their system level IDs
appearing in some data stream, but again that was often
not [overspeaking]
That happened in automated reversals, wouldn't it?
Because if the system went down during a recovery
process (inaudible) that processing of a basket of
transactions or a single transaction could not be
completed by Horizon. Perhaps, at 6pm at night, after
22
SSLO000129
SSL0000129
the customer had gone home and the branch had closed,
the system would reverse that transaction, but they
allocated to that reversal the ID of the person that
input the transaction.
CHEVAUGHN: If Fujitsu (inaudible) and doing these secret
amendments, as you referred to earlier, essentially it
would use the ID of the branch manager.
IAN: Even though the branch was shut --
JASON: That is one of the questions.
ROBERT: What Fujitsu have told us is that the audit holds
a record of things done by the person in the branch who
has the password.
JASON: Yes, that does appear in one of the documents.
Something about the 65th something or 75th element or
partition.
ROBERT: Based on an account review Fujitsu -- some of the
guys in Fujitsu could not do that, could not create that
record because he didn't have the password of the
branch.
JASON: Possibly not to be done (inaudible).
CHEVAUGHN: If it was (inaudible) I could access the
[overspeaking] .
IAN: You could generate a transaction with any item.
CHEVAUGHN: -- create a password and then if they phone up
and say this doesn't work I would say, sorry --
[overspeaking]
IAN: At systems level you didn't even need a password.
Within the XML data stream we were seeing transactions
that were allocated to IDs that were not in use and,
therefore, it wasn't a matter of somebody sort of
logging on with a particular password and that data
entry appearing in the transaction stream. These were
system generated transactions. How they were initiated,
we don't know. We just saw the results of those --
ROBERT: You saw examples of this in the audit data?
IAN: Yes.
23
SSL0000129
$SL0000129
ROBERT: That's interesting because that seems to go against
the way Fujitsu described the (inaudible) in the audit
data.
RON: Yes, I think you might find that references to seals
in data and all the rest are references to seals and
controls within the Horizon software. What we were
finding was that there are other pieces of software that
access the data, which may not be subject to the same
control (inaudible). [overspeaking].
ROBERT: I don't think they can change that. What we saw
was the audit data and I'm comparing that with Fujitsu's
description of how the audit data was sealed.
IAN: My understanding is that Fujitsu's position is that
the transaction data, the audit data, is sealed, is
controlled, and whilst they were exceptional processes
that could access that and alter that, that the
authorisation procedures to implement that was such that
there was, in effect, sort of no risk from that. I'm
not sure I agree Ron that there were sort of external
systems that were altering the --
RON: I will tell you what I'm referring to and you remember
how, in a sense, we got worked up about this. I asked
a question, I distinctly remember the wording, we asked
a question because it was so fundamental to this point:
has Fujitsu -- has Post Office or Fujitsu or any of its
agents ever altered branch data without the knowledge or
permission of the postmaster? That was the question.
The answer that came back -- I distinctly remember
every word of it -- was the Horizon system has no
functionality that allows the remote accessing of branch
terminals. And I went mildly ballistic and said where
in the question phrases are the terms branch terminal
remote access and so on? We want to know if the data
for each branch has ever been modified. I don't care
where it might have been done.
IAN: Remember, Ron, their answer again was quite a clever
one because it wasn't that the data was being altered.
What we eventually got out of them was that the
transaction stream -- additional entries were being
injected into the transactional stream which would have
the effect of modifying balances but not amending the
original --
RON: I take issue with you Ian. I love you but it was not
24
SSL0000129
$SL0000129
at all clever. To investigators like us that was
a really stupid response because it was so crafted to
be -- essentially to cause us to say (1) why would you
come up with such a carefully crafted answer. Sorry.
IAN: But it was true. We absolutely established that if
they wanted to modify a balance at branch level, they
would not try and amend the original entry, they would
inject additional entries into the transaction stream.
ROBERT: How do you get that into the audit, that is the
question?
IAN: It was going into the audit trail. It was being
reflected in the XML data.
JASON: We do have it from the document that explains it
quite well. It actually shows you as a screen shot of
the screen that Fujitsu used to inject the transaction.
ROBERT: I think it is one of the ones you sent --
JASON: It has a massive disclaimer at the top saying:
warning, anything you do on this system will have
a direct effect on branch accounts.
RON: We didn't see that. Well done.
IAN: Well, we did, we did get this submission where they
were correcting --
RON: I never saw that screen.
IAN: We referred to it in our Part 2 report because this
was one of the documents we found fairly later in the
day, where they had three options to correct --
RON: That was the internal memo.
IAN: -- a problem and one of the options was accompanied by
this warning that if it doesn't becomes public
knowledge --
RON: It will undermine the confidence in the system and
cause all sorts of --
JASON: Shall we break for some chips?
RON: Fish and chips
25
SSLO000129
SSL0000129
JASON: My only observation (inaudible) the agenda. What we
might do is we will grab something and try and step
through and we will allow ourselves to go in different
directions.
RON: We would prefer you to go through our report and say,
we have highlighted these 25 items, can you give us some
more granularity about that.
IAN: But unfortunately we are constrained by the report and
that's why (interference) straying outside the agreed
definition.
CHEVAUGHN: I think, as Jason said earlier, looking at the
big picture is important. So you are right that the
definition (inaudible). [overspeaking].
There are two cases here, there is protocol and
the Horizon issue. If you are straying outside the
Horizon issue, that's entirely what (inaudible). The
only concern I would ever have [overspeaking].
(Off the record discussion).
MR WARMINGTON: So Ian you experienced the BBC sandwiches
yesterday or the day before?
IAN: Yes, they are good. (inaudible).
MR WARMINGTON: (inaudible) photographic memory of the
stuff.
ROBERT: I was desperate to find this one document.
JASON: It is just the reference number appears in
a (inaudible).
ROBERT: Is it (inaudible)?
JASON: Probably not.
ROBERT: (inaudible) Fujitsu?
JASON: I'm not sure, I mean he has (inaudible).
IAN: I think he may have retired by now because I have
a feeling he was asking to stay on just at about the
time we were wrapping up (inaudible) all the rights.
But he may not be readily available now. But he was
very impressive and I felt that he was the ideal sort of
26
SSL0000129
$SL0000129
engineering sort of person. He was objective, he had
huge technical knowledge and he wasn't sort of
(inaudible).
JASON: I had seen places where he made comments about bugs
not being apparent in the Horizon system, it was part of
the transcript.
IAN: An example is one of the questions I asked him was
about remote access and he immediately said: of course
we have remote access direct into branches; sometimes we
need to (inaudible) to fix it, even though when we
subsequently went on the record about that with the Post
Office rather than Fujitsu, we consistently got the
answer there was no remote access --
RON: They may not have known. [overspeaking].
ROBERT: Between the Post Office and --
RON: Yes. The funniest aspect of this was in following up
on the allegations about Brackwell. We asked the
question: do you have any people in the Brackwell
building in Fujitsu? And the answer was, no. We said:
we think you do. The person we were dealing with was
Simon Baker. Nice chap. Who was our connection to sort
of (interference).
He called me one day and said: I have got good
news and bad news. Good news is we found the department
did have people from Fujitsu in the building and there
were Post Office people. I said: what's the bad news?
He said the bad news is they have apparently been
reporting into me but I didn't know they were there.
MALE SPEAKER 4: I wondered who they were
[overspeaking]. Out of sight. [overspeaking]. I'm
probably pronouncing people's names differently to the
way they do. Is it Chevaughn?
CHEVAUGHN: Some people do say Chevaughn, which is like the
Irish. It depends where you are in Ireland. (Pause).
(Inaudible conversation due to eating and overtalking.)
MR WARMINGTON: Did you make the box car?
JASON: We did. (inaudible). He is obviously not serious.
(inaudible).
27
SSL0000129
$SL0000129
RON: Was that Red Bull --
JASON: The Local (inaudible section).
CHEVAUGHN: Okay.
RON: What happens is you walk across the square (inaudible)
and the family will say: "Hey Ron," and you turn around
and somebody you haven't seen for 25 years and it is
a real memory test.
JASON: Yes.
ROBERT: (inaudible).
RON: Yeah (inaudible).
ROBERT: There is a bunch of us who kept in touch since
college for years. (inaudible).
RON: You were in Logica, weren't you?
ROBERT: Yes.
RON: Were you MD at Logica?
ROBERT: No I was MD at Cambridge for the research branch.
Then Martyn Reed came in and (inaudible).
JASON: Martyn and I worked together in Logica in 1976.
RON: That was the year after I went off to CitiBank. I was
in CitiBank from 75.
ROBERT: When banking was respectable. [overspeaking].
RON: [overspeaking] investment management business.
CHEVAUGHN: (inaudible).
RON: Before heading an investigation which was by far the
most interesting thing. [overspeaking].
JASON: It looks to be a document that talks about how you
access what looks to be a front end form in (inaudible)
and all the elements of a transaction on that and you
can bring something up on the left-hand side and it
basically over types something on the right-hand side or
alternatively you can inject like a balancing
transaction.
28
SSLO000129
SSL0000129
CHEVAUGHN: Yeah, I think this was for the SAP team.
JASON: POL SAP. Quite possibly.
ROBERT: Their accounting.
CHEVAUGHN: Following the manual [overspeaking] they would
fix what was on [overspeaking].
JASON: But that ultimately would then flow into a branch
account.
RON: Yes.
CHEVAUGHN: It would into the -- yes.
ROBERT:
IAN: (inaudible). They did run a separate accounting
system which -- I forget the name -- POL SAP.
ROBERT: They renamed it POL SAP in 2010. Originally named
POL FS in about 2005. What happened before that?
JASON: They probably moved to an SAP (inaudible). When
Horizon first [overspeaking] in the 98 POL FS --
[overspeaking]. What they actually did was they had POL
[overspeaking].
MALE SPEAKER 4: Jason, I think what the history is that POL
FS came in in 2005. SAP ADS had been around and that
was SAP for [overspeaking] in 2010 they merged those
two, called them SAP --
JASON: Right well [overspeaking]. Because the process of
transaction corrections is ultimately started in POL SAP
and then that balancing transaction gets pushed out and
gets accepted by the Postmaster.
ROBERT: The interesting question is whether anything
started in POL SAP has to be pushed out and accepted by
the postmaster before it can --
RON: Yes. That is a good question.
JASON: Following on from this document that we can't find,
one of the suggested requests for information, Robert,
is that we say: how often was this process evoked?
[overspeaking]. It might be a modification to a branch
account that the postmaster has no knowledge of
29
SSL0000129
$SL0000129
whatsoever.
CHEVAUGHN: Yes.
JASON: It is different from the TC process.
RON: In any modification branch account, the ultimate
impact of that is that it changes the amount of cash and
items of value that that branch has to have to balance
the books.
JASON: So if that transaction is auditable, there is two
ways of getting at it, you can either ask Fujitsu how we
follow that process and how many transactions per day or
per month go through or alternatively they tell us how
we identify those transactions and then we can then look
at a branch account, and we might be able to spot the
particular accounts that are -- that have been
(inaudible).
CHEVAUGHN: But I think it is those (inaudible) part of
reconciliation.
JASON: Reconciliation of what with what --
CHEVAUGHN: Client systems to --
ROBERT: I think that's what creates TCs and --
CHEVAUGHN: No, I don't think it is --
RON: That was not the impression we got. The impression we
got was that process that we are talking about invoking,
this sort of secret process, was really Fujitsu trying
to cover up or deal with, in as quiet a way that it
could, the errors that its software had generated, not
had arisen from relationship with clients.
CHEVAUGHN: It could be this scenario, that Barclays have
a record of a transaction and the authorisation code and
it is the amount that's debited but that electronic time
stamp for that transaction is corrupted. So it will be
0. So then the counter will have that transaction that
was requested as a credit, the authorisation code that
was provided from them, with the correct time stamp. So
somebody will literally sit there and manually correct
the time stamps, so the reconciliation against those
(inaudible) .
It is not like it is something that then knocks
30
SSL0000129
$SL0000129
the transaction correction. It is so that the data is
in --
RON: You are both right because the proper procedure, the
disclosed procedure, would be that, if there is
something surfaced, manifested itself by reason of the
reconciliation of a client such as Santander, the same
with investments, Royal Mail, blah, blah, blah, any
reconciliation there threw up something which seemed not
to have been processed correctly or in the same way, in
a matching way, the proper procedure for correcting that
is through the transaction correction process.
So, I would be intrigued to see why they would use
a process other than the TC process to do something that
was the result of --
CHEVAUGHN: Because I think there was simply far too many of
them to issue TCs put forward --
ROBERT: It is a lot of TCs --
CHEVAUGHN: -- I think these are happening on a daily basis.
RON: I'm not going to argue with you on that, you have gone
deeper into it than we have. As Ian agreed, we'll
articulate it, our sort of in-depth technical
penetration of the (inaudible) was virtually terminated
as we got involved in the mediation process.
IAN: The same document talked about the repair cash
account.
RON: Okay. (Coughing) you are not expendable, so be
careful. (Pause). Have you ever been to Tombstone in
Arizona?
~ IRRELEVANT
IRRELEVANT
MALE SPEAKER 4: You went to Tombstone Arizona and bumped
31
SSL0000129
$SL0000129
into him --
RON: (inaudible) thought it was going to change his life
and it did, but it wasn't (inaudible).
JASON: The definition of widespread errors in 100 branches
being affected --
RON: So the key word was systematic versus systemic. We
were very, very reluctant to refer to anything as
systemic. We did in the end because systemic meant to
us something that could occur right across the entirety
of the system as opposed to being occasionally
systematically repeated.
MALE SPEAKER 4: Ian pointed to that with what 16 --
RON: There was a huge volume of transactions going through
that system. It can be pretty robust, pretty reliable.
But if a strange combination of events causes an
individual error, it is the follow up to that individual
error that is consequent (inaudible) if it is a life
changing amount.
JASON: With that number of transactions over an
infrastructure that is relatively complex (inaudible)
across a wide area with a lot of connections, there is
bound to be [overspeaking] a number of those
transactions that are not properly logged or missing or
whatever [overspeaking] .
It is, as you say, it is how that is then dealt
with that to me is (inaudible) the nub of the issue. If
they are all dealt with correctly, then it is not likely
to have any impact. If even some of them are dealt with
incorrectly, then there will be an impact and it depends
whether that impact will ultimately affect particular
branch accounts.
RON: Will this cause you to lose even more hair for jumping
around, the famous paragraph 12.12 of the 144 points
contract, which refers to responsibility for losses,
uses the word "caused" twice in the paragraph. It
basically says caused by, (inaudible) losses caused by
negligence of the postmasters or, worse, caused by their
staff. It doesn't mention (inaudible).
Our responsibility is for the postmasters to
correct. The whole nub of this case is: who determines
who has caused that error? In other words, is there
32
SSL0000129
$SL0000129
an assumption that, if there is an error, it was caused
by the postmaster or the staff? Or is there
an investigation to determine who or what actually
caused the error? That's the whole -- it is the core of
this case.
CHEVAUGHN: Was there ever a response when you -- going back
RON:
IAN:
RON:
to the ATM and said: why are you always trusting what
the Bank of Ireland always say, was there ever
a response where they say: we have an express agreement
where (inaudible).
No, because the same question applied to the trust in
Camelot, the National Lottery, National Saving
Investments, HMRC and all the other clients.
It might have fell into the (inaudible) black hole of
suspense accounts and as soon as we started asking
questions about suspense accounts, that was it --
I said if you have got -- it was the wording that Ian
picked up, which was [overspeaking] in suspense accounts
were either debit or credit. So if it is a credit
entry, it means that the Post Office potentially can
benefit from that credit entry and my position was there
are only four legitimate beneficiaries of entries --
assets in those suspense accounts. One is the customer
who has been short changed. Two is the Post Office
itself. It really was due the amount sitting in its own
suspense account. Three is the client, you shouldn't
have sent them money but it did. The fourth genuine
beneficiary would be the subpostmaster. And my position
was, if you leave entries for considerable periods of
time and then trouser the contents of those suspense
accounts, you are by definition sometimes trousering
money that was due to subpostmasters. And if you are
delaying that process, you are subjecting the
subpostmasters to the temptation to false account
because they are faced with a shortfall, (inaudible)
sitting around in a suspense account that they cannot
recover, and therefore they have to do something about
it. And therefore I think some were tempted to do
something they shouldn't. That was why the suspense
account issue was so hugely significant.
JASON: The other by product for that suspense account,
that, if only one of the possible scenarios shows that
the subpostmaster has done something wrong -- I'm not
sure wrong is the right word.
33
SSL0000129
$SL0000129
ROBERT: Suffered a loss.
JASON: Then that means that the net effect is three out of
RON:
IAN:
RON:
IAN:
RON:
four of the transactions --
That's crude -- sorry. You don't know what the
frequency error was --
The real problem was the suspense account balances
were not disaggregated. There may well have been
billions of transactions which came in total to
25million or whatever it was. We never got a clear
explanation --
It was 96 million on the Bank of Ireland and 66
million on the Santander --
They had a policy of taking credit balances back to
the P&L after three years. We know, for example, when
we looked at it, that something in excess of 100,000 was
credited to --
I was shocked how small that was frankly
[overspeaking].
ROBERT: I have got a misunderstanding about the suspense
RON:
IAN:
RON:
account. I was looking at the monthly balancing process
and there my impression was, if the postmaster
[overspeaking] imbalance, he could either pay it off or
he can shove it into the suspense account.
I can clarify on that easily. Originally each branch
had available to it an in branch suspense account to
which it could post entries.
Ron, I don't want to stop you but there were at least
two types of suspense accounts. What we were talking
about were third parties but what you are talking about
were the [overspeaking] .
I am covering it. What then happened was clearly that
was over used, as it was bound to be destined to be over
used where people said I know (inaudible). The Post
Office said this was getting out of control, so they
actually withdrew that facility to the branch office.
They later reinstated it but for a large amount of time
in relation to the cases we looked at --
JASON: Do you know approximately how long?
34
RON:
SSL0000129
$SL0000129
7 years. I am counting it going from --
JASON: That's fine.
RON:
IAN:
RON:
IAN:
RON:
So let's say that it is in place, so the branch
suspense accounts. That is entirely different from what
we are referring to. When I first said to the Post
Office -- Sir Anthony Hooper posed the question during
the mediation process, he said: is it possible that
a surplus in one branch could manifest itself as
a shortfall in another? And he kept on about this until
he was blue in the face. At every meeting he would
raise this because I would say, yes, and he immediately
(inaudible). That's when I said you will have suspense
accounts and Post Office said we haven't got them. And
I said, don't be daft, you will have suspense accounts.
Post Office said, no, we don't have them. Then Ian
goes -- then they said yeah we have one, we have one
suspense account. I said that will be the overall
suspense account; you will have a suspense account for
every client relationship you have because, when you
have a lot of transactions with any counterparty, there
will always be differences. And therefore eventually
they said: you are right, we found we have got those.
But that was like (inaudible). We then met with
Campbell, the new finance director at that time. He
called in a chap called (inaudible), who was the person
I think in Derbyshire responsible for reconciling the
main suspense account and its subsidiary account and it
was a bit of an eye opener. I don't want to say any
more than that, and that was our last meeting because we
said: it sounds to me as though you are not reconciling
those accounts and that was about it.
But we would have got to that stage much earlier
had we not been diverted off for the mediation. Does
that accord with your recollection?
Yes.
You are looking a bit puzzled.
I was just thinking that the one thing that they
challenged in our Part 2 report, was they wanted us to
change from the wording "in relation to suspense
accounts". But actually what we reported was a quote
from an email from this account, so we said no. It was
interesting that he (inaudible).
I'm not allowed to go into cases. There were
35
SSL0000129
$SL0000129
instances where we really wanted to -- where we knew of
instances where a customer had done something, something
had failed, a cheque had rebounced, the postmaster had
got charged with the effect of that bounced cheque, the
customer then in one case corrected the situation and
made a payment to Inland Revenue, the postmaster never
got reimbursed.
We knew the Revenue got paid twice. Something
happened to that second payment. It either resides
within the national coffers or, more likely, (inaudible)
they would have sent it back to the Post Office, who
would have dropped it into the HMRC suspense account.
But it was never reconciled so it finished up I think,
I suspect -- too far? We don't know. That would have
been worth investigating.
IAN: What I would suggest now is we canter through the --
RON: Yes.
ROBERT: We will try to keep up.
JASON: Number 1. This is the first issue that we will have
to deal with. (inaudible) possible bugs, errors or
defects to cause apparent or alleged discrepancies or
shortfalls in the branch account?
CHEVAUGHN: This is page 4 of the lists of issues.
JASON: So what we are looking to do is find evidence or
evidence to the contrary that there are bugs within
Horizon at various points in time and that by looking at
those bugs, we can determine that they could have caused
a shortfall. Now, we are aware of a system called the
known error log. We have got the data for that. We are
aware of the PEAK system, which is all the (inaudible)
calls, whatever, is determined that a software code
change was required as a result of that.
RON: Is that what PEAK meant?
JASON: Yes, it is.
RON: It is not synonymous with bug?
JASON: It is.
RON: We just wondered why they coined the term.
36
SSL0000129
$SL0000129
JASON: It is the name of the system. What does it stand
for? [overtalking]
RON: I was always intrigued as to why they called the term
PEAK.
JASON: I think PEAK does stand for something. I can't
remember what.
IAN: To answer your question, it includes the word: was it
possible? Of course it is always possible. The only
bugs, errors or defects that we became aware of were the
ones that were disclosed to us, that we refer to in both
our reports, initially in our interim report, and then
some further references in our final report.
CHEVAUGHN: (inaudible).
JASON: How was that small number arrived at? Because
I don't accept that there can only be at that point in
time that number of errors.
IAN: No, but those are the only ones we knew about and we
knew about them because they had been disclosed to us.
We didn't become aware of them as a result of some
fantastic investigative work that we did, other than we
were trawling through large numbers of documents and
certainly in one place I came across references to
correcting these items, and then when you back tracked
we got this further disclosure.
JASON: Do your reports say where you found that reference
that had been corrected?
IAN: Certainly the Part 2 report does go into quite a lot
of detail. The interim report slightly less, but we do
go into quite a lot of detail (inaudible) what the bug
was and the impact on it. And the other thing that we
noted was that, in one case at least, it took at least
12 months for the bug to be detected. So that begs the
whole question -- [overspeaking]
ROBERT: To do with some annual check (inaudible).
RON: Right. Okay.
CHEVAUGHN: There is also Dimensions, that that's supposed
to record all of the documentation. So there ought to
be release notes and things --
37
SSLO000129
SSL0000129
JASON: And it is from Dimensions that we got these
particular documents that talk about correction and
reconciliation processes. I think it is those processes
that reference particular systems to do reconciliations
and things like that.
ROBERT: So it is Fujitsu's files.
JASON: Yes. So we have got the first on the 18th. I think
we get the next drop of documents from Dimensions. So
there's going to be literally thousands of documents
there. We have already got 18 of them, which were based
on a key word search. The (inaudible) at the moment is
following the meeting we had the other day, we have
added some more requests for information to the bottom
of that document. We haven't finished it yet but we are
going to submit it by tomorrow. We will share it with
you anyway but --
IAN: Is that the one I have asked you to stick an extra
column in?
CHEVAUGHN: Yes.
JASON: We will stick the extra column in and there are
extra requests at the bottom. It would be great if you
supported us in asking those questions but if not we are
going to ask them anyway.
IAN: Sure.
JASON: They are all based around trying to determine bugs,
errors and defects.
RON: Presumably you want to know when it was detected,
whether it exists and whether that bug -- how long it is
likely that bug existed prior to being detected and how
many branches and to what extent that bug may have
impacted the branches? What was done about correcting
it? Who was told about it etc?
JASON: Yes.
RON: I can see a spreadsheet.
JASON: The focus at the moment has been the documents that
outline the process of dealing with the impact of the
defect. So, it is sort of like, Fujitsu saying: there's
clearly a problem, we are trying to find out what the
problem is, until we sort out what the problem is, this
38
SSLO000129
SSL0000129
is how we correct it, we have set up a new screen etc.
What we are saying at this stage is: when did that
start? How many of those were you doing a day and the
hope is we can tie it back to a particular (inaudible).
CHEVAUGHN: I found a document this morning which said the
(inaudible) were recorded and QC'd, which is Quality
Centre [overspeaking].
JASON: I think Quality Centre was the tool that was used
before they migrated to PEAK.
CHEVAUGHN: The document refers to all those. (inaudible).
MALE SPEAKER 4: Quality Centres are generally used for
testing, for capturing test scripts and test result.
CHEVAUGHN: It says (inaudible) defects would be recorded in
there. [overspeaking]
ROBERT: They may also record operational defects. I'm not
sure about that.
JASON: Even where the Quality Centre was one of the
document (inaudible) that was mentioned on the
(inaudible).
CHEVAUGHN: Kathy Bick is Fujitsu's internal repository.
RON: Chris, what you just said there is kind of interesting
because in the same way as you would expect and it turns
out to be true, that Fujitsu would keep a list of bugs
detected, ordinarily, what I'm used to, is the
corporation itself, the Post Office would keep a similar
log of operational glitches; things that were not
working.
IAN: (inaudible) didn't want to know, that was the whole
problem. There was a breakdown between the two.
RON: No I'm talking about (inaudible) was keeping a list of
the (inaudible). I'm talking about the Post Office
keeping a list of things that weren't working properly,
such as the ATM, such as the out of sync situation that
arose on Camelot on lottery tickets, where they repaired
processes that were found to be deficient.
JASON: We believe that the Post Office had input into the
known error log because when they were dealing with
their password and the help desk, they would search the
39
RON:
SSL0000129
$SL0000129
known error log to find out whether it was known and if
they couldn't deal with it at a business process or
training level, then it would be passed onto Fujitsu.
Fujitsu would look at it and the systems (inaudible) .
I think the tone of the documents that talk about
issues arising, are very much in the spirit of what you
just mentioned there Ian, that the Post Office don't
really want to know unless it triggers this widespread
issue affecting more than x hundred --
They were clearly extraordinarily concerned about the
brand and the danger to their entire business probably
in the event that Horizon was in any way discredited.
That is abundantly clear. It came out in the
Governmental investigation process.
JASON: The other route that we could take for bugs, errors
IAN:
and defects is to recreate the process that these guys
have been through, looking at the Excel data. We just
(inaudible) yesterday back at base, one month of data,
to try and pass through it and try and recreate, in
a sense, (inaudible) accounts from the raw data. And
then we can look at the specific complaints about that
period and see whether (inaudible) on 14th February
whatever, we have got the 14th February in there --
You could ask for a copy of the script that they ran
to generate the Excel spreadsheet because -- whilst
I was going to provide them with that script, I did get
for the same period the raw XML data and the spreadsheet
and it was actually quite useful to be able to compare
the two.
JASON: Yes, and I think we might have been tripped up
a little bit because there was a discussion about: do
you want filtered or unfiltered? And I said completely
unfiltered and that's what we think we've got but then
we have never been told that actually we might not have
got unfiltered, it might have been filtered. But
I think we will know more about that in the days to
come. Do you have any more we need to ask about item 1?
ROBERT: Not really.
CHEVAUGHN: Sorry, what did you say (inaudible) have you got
any specific logs that anyone is aware of or names that
spring to mind --
JASON: I think what would be good is the data that you have
40
SSLO000129
$SL0000129
already looked at, that we should be able to get hold of
because it has been returned back to Post Office now and
it in disclosure --
IAN: It is not in disclosure because it is in the
unreadable list.
JASON: We can just get the unreadable file and hopefully
just deal with that. Is that disclosable to us?
CHEVAUGHN: Yes, it is.
IAN: But they haven't physically handed it over. The
correspondence I saw said: these documents are
unreadable and (inaudible) not disclose them.
CHEVAUGHN: There could be a number of reasons why they are
unreadable. So it all depends on --
JASON: I'm pretty sure it is because they have put it in
a relativity system, it is not Word, it is not Excel --
CHEVAUGHN: We will just make a request --
RON: I do not think we can make a quality evidence based
opinion, any input on that. Of course it is possible,
it has happened.
IAN: But look at our reports because we have identified all
these -- [overspeaking]
RON: We didn't discover -- we would love to have -- but we
didn't discover any bugs.
JASON: When we get that XML data, it might well be the case
that, once we start to understand it or we get to the
stage where you got to with that data, we might need to
talk again about what I can see from that data and see
whether if we are understanding it in the same way.
RON: I would draw your attention to the fact that it is not
really bugs, errors or defects. The whole business
about running branches that were in sometimes
countryside locations, with very weak or interrupted
telephone connections, sometimes the system reverted.
In one case this lady was running on emergency generator
power and kept turning the system on and off to save
money. [overspeaking]. And the system kept going --
twice a day the system would go down. [overspeaking].
Using mobile phone signals to carry out really quite
41
SSL0000129
$SL0000129
complex multi-operator system just -- there is
a certainty that that was causing defects; it was
a source of defects.
JASON: Number 2: did the Horizon IT system itself alert
subpostmasters of such --
RON: No. The nearest you get to that is the recovery
process that said, "Look, I have gone down and we need
to do something about that." We have reported on that.
There was a false assertion that we had cleared that in
our interim report and said it was okay. We didn't.
IAN: There were some Post Office generated newsletters that
occasionally made reference to [overspeaking] and so on.
JASON: That's interesting.
RON: That's true. We didn't spend a lot of time
(inaudible).
JASON: There wasn't a screen from Horizon in the bottom
saying "you have been migrated to the new version".
IAN: We weren't Horizon users. We went to Horizon training
and we saw various Horizon screens but we didn't spend
a lot of time using Horizon.
RON: Branch Focus was the magazine. Branch Focus
elaborated on the problem with Camelot lottery tickets,
where quite clearly there were a mass of errors and out
of sync situations. Particularly if you are running
a corner shop, the Post Office is only open at
restricted hours, but the (inaudible) are behind the
counters all the time selling lottery tickets that you
can only process the following morning. And they were
getting out of sync. So there were TCs flying around,
always for £160, because that was the price of a lottery
pack. The Post Office twigged that and said clearly
this is not a functional process that worked. So they
put that in Branch Focus and then came up with some
software called PNG, to automatically do something which
historically had to be done by people in the branch and
where they had been consistent in -- or in many cases --
they were getting it wrong to their own detriment, PNG
corrected that. But it took several years for that to
be put in place. They saw the problem, reported it in
Branch Focus, put it in a temporary change and two years
later put in PNG to actually sort it.
42
SSLO000129
SSL0000129
ROBERT: If we look at TCs we will see a bunch of Camelot
ones and [overspeaking].
RON: Yes.
IAN: When we looked at the numbers it was thousands, if not
tens of --
RON: It was serious, very serious.
ROBERT: If you can imagine, if it was impacting on a number
of important branches.
RON: The numbers were pretty dramatic.
IAN: It was the closest we came across to a systemic error
because it was a process failure [overspeaking].
RON: They rolled out a process that's not perfect. Banks
do that all the time. Of course the difference is the
bank -- (inaudible) myself on many occasions -- but we
do that -- but the bank suffers the loss. In this case
the point that we made was that, if a decision to roll
something out saves money to the roller outer, but it
actually bundles risk and cost onto somebody else's
shoulders, it is not necessarily an unimportant
decision.
JASON: With regard to whether the system itself alerted to
any (inaudible).
IAN: Generally, no (inaudible).
RON: So through the robustness question, I have cross
referred all the questions to our report.
JASON: Right okay. [Overspeaking].
RON: I did that on the train this morning. The handwriting
is not very good.
ROBERT: That's okay, we'll figure it out.
JASON: Now number 4, part A of it.
IAN: Again it depends -- this is the errors of major --
JASON: Yes.
RON: It is all over the place depending on the sort of
43
transaction. There were a number of transaction types
that the Post Office processes --
IAN: To cut a long story short, a problem we were told
about quite frequently was the decimal point problem.
Something that was being entered as 10.00 was recorded
by the system as 1000.
JASON: Right. (inaudible) isn't being pressed or isn't --
IAN: Well, isn't being recorded --
RON: You have got 10, 100, whatever, and that
[overspeaking] would cause the wrong number.
IAN: But this was a feature or a function, to a certain
extent, of the touch test screen and the icon
representation, where, if the icon sort of got out of
sync and there was no automatic calibration, frankly,
anything could happen. And since so many discrepancies
were linked to errors of the counter, I think we felt
that data entry errors were a significant part of that.
RON: It is sometimes hard work -- I know this jumps ahead.
For example, although I don't believe for a moment -- we
had no -- the conclusion reached was that postage stamps
and postage labels were not the cause of huge errors,
but they were a cause of numerous errors, not large in
terms of finance. But what was happening there, in many
instances for sure, was somebody would process a parcel
label; Mr Customer that's going to be £12.50, hit the
Horizon terminal, the postage label would get screwed up
or fail or be invisible. So they would have to process
it again. The customer had to see he got his label.
What was meant to happen then is there's meant to be
a process saying, it failed, keep that to one side.
That was frequently going horribly wrong but it was
mainly driven by hardware problems. For example the
label printers. But of course the Post Office was
deeply suspicious or the investigations team was, that
people were abusing this process and some were for sure.
Some were saying actually it didn't print well, when it
actually did.
IAN: They weren't controlling the raw label paper. In
other words [overspeaking] wasn't in --
JASON: Pre-numbered form --
IAN: Yes, it wasn't an accountable item, sitting in
44
SSL0000129
$SL0000129
SSLO000129
SSL0000129
a drawer somewhere [overspeaking] had any value, which
always struck me as a rather strange definition.
Because, again, if I was a fraudster, if I could get
hold of the stock of the raw sort of label, I'm pretty
sure I could write a programme to print something.
RON: We did find a bug on exercise licence because they
don't do it anymore, when you are able to retax your
vehicle. We found one instance where a customer got
a six month tax disk instead of a 12 month one and that
was because the barcode was screwed up [overspeaking].
IAN: [overspeaking] Whoever printed those made a mistake in
the barcode and it was a six month disk which when it
was scanned was registered as a 12 month.
RON: You would have to have the eyes of a peregrin falcon
to notice that sort of thing, so that sort of thing was
occurring, as it is bound to in [overspeaking] products.
JASON: Would that lead to a shortfall?
IAN: It certainly would lead to an error because for
financial purposes it would be treated as one thing, but
physically it was being sold as something else. In
other words, they were selling [overspeaking].
JASON: But only receiving £60 from the customer.
CHEVAUGHN: I think there is detail in your report --
IAN: Another example was -- and again I don't want to get
into the weeds -- but a lot of people would regard
a First Class stamp as a First Class stamp and that was
the end of it.
RON: It was a Christmas stamp.
IAN: The Post Office would then issue these special stamps
and some would sell it as a First Class stamp but
actually on their accounting system it was recorded as
something completely different.
So again that would give rise to discrepancies
because the Post Office sensibly was accounting for it
one way and the branch was selling it on a different
basis.
MALE SPEAKER 4: (inaudible) a six month licence is treated
as a 12 month licence. Does that come out in the wash
45
IAN:
SSL0000129
$SL0000129
in a transaction (inaudible). Does DVLC actually keep
track (inaudible).
Where it should show up is on the reconciliations and
we didn't get into that level of detail.
ROBERT: It should have happened but did the DVLC at the end
of the month, somehow, the gap would get spotted and put
back?
JASON: Yes, in theory it should. The licensing authority
should say it is a six month licence, you have only
collected the cash for a six month licence rather than
a 12 month licence. So therefore we won't pay. You owe
us -- it would be a TC in the value of the net
difference between the two in theory. Some of that is
in your report anyway, so we can have a look at that.
Right. So part B is transfer of data or
processing of data in Horizon. I do not think the
difference matters for this conversation, does it
really?
ROBERT: Not hugely, no.
IAN:
Again, I think that is a level of detail which we
didn't really get into other than suspense accounts and
reconciliations. I'm not sure we really sort of
understood some of the Post Office management accounting
systems and so on and we mentioned POL SAP before.
Whilst we were made aware of those, exactly how they
operated, how they were integrated and generated entries
that ended up in Post Office's financial statements,
again, (inaudible) to look at.
JASON: Yes. Okay. Number 5, we touched on this before.
IAN:
How does Horizon prepare itself ... (inaudible). So its
data within Horizon, comparing itself with transaction
data outside of Horizon. Now, I see this reasonably
simplistically as Horizon comparing itself or, actually,
data that's generated by Horizon or at the counter --
Being reconciled to third parties.
JASON: Yes. The bank, Camelot --
RON:
I wrote the manual intervention.
JASON: At the back end?
46
SSL0000129
$SL0000129
RON: Manual intervention was predominantly manual processes
to compare the results of data entered in the branches
into Horizon, with the transactional summaries or
balances generated by outside clients.
JASON: Now banks will know because of the link system or
whatever it is. So they will know how much they should
be paid. Camelot will do the same. Is that the same
for all of the customers? Will they know how much they
should be paid or --
RON: I think it is a pretty good generalisation --
[overspeaking].
JASON: Sorry?
[overspeaking].
I think that's good that. It makes the argument
simpler, doesn't it really? So none of them trust the
Post Office system, they have their own view of the
world. Horizon has a view that it presumably aggregates
across all branch accounts --
ROBERT: I was interested in your remark that it is manual.
I thought it is always file A, file B. [overspeaking].
RON: [overspeaking] as a result of that comparison trigger
manual processes to generate TCs. There are feeds from
which they arise. [overspeaking].
IAN: I do not think that was happening in Horizon. My
understanding was there was a monthly sort of BACs total
operation that extracted daily totals from Horizon that
then went into POL SAP or some other system and its the
external system that was the starting point for counter
reconciliation.
RON: It is not part of Horizon. There is a process called
Harvester, isn't there?
CHEVAUGHN: I thought that they were in the bucket of
Horizon. [overspeaking]
RON: We never saw any evidence of that reconciliation
process, automatic triggering manual creation of TCs.
We never saw any evidence of that.
IAN: What we were told was Horizon was basically driving
branch accounting, but that was then the end of Horizon
47
SSL0000129
$SL0000129
and the start of all these centralised systems within
the Post Office.
JASON: Because one of the architectural backgrounds I have
seen, it shows that, that you have got all the branches
who have a hundred different types of transactions in
them and there is a process, I don't know whether it is
called Harvester, but it goes on and it takes all of
these and rescans them into customer accounts and then
adds that up. If that reconciles with what the
Bank of Scotland says, happy days and everything goes.
If it says, no, it is £12.50 difference, then you have
to do something with these. Then, at that point in
time, it might be a one to one reconciliation of every
transaction and then there will be one transaction
that's wrong or ten that are wrong or whatever and then
perhaps that's where human eyes get on those ten
transactions and say: what are we going to do with these
ten? And it will have a branch indicator next to it
which says --
IAN: I think they lost the branch (inaudible) at that
point. As such reconciliations were done (a) they were
done fairly late and (b) I vaguely recall being told
that at transaction level they lost the ability to link
it back [overspeaking] transaction.
RON: That's why there was such a delay in the creation of
TCs because had it been entirely automated then TC
related to an ATM shortfall, lottery scratch card
shortfall, would have come out the next day. They
didn't. They came out months later.
ROBERT: I think TCs coming out later may be due to factors
beyond the Post Office control. [overspeaking].
RON: Why did you charge me this amount, I didn't ever get
the goods? I know people said my electricity was cut
off, my phone was cut off but I have got the stamped
receipt from the Post Office, from the postmaster, from
the branch. I just noticed they were never charged for
it. That might occur three months later.
JASON: Right. Okay.
RON: So that was simply because again a one sided
transaction had occurred and in some cases where there
was a power failure or something, the postmaster would
stamp the person's tax bill as having been paid, or his
water bill or rate or council tax, and the customer
48
SSLO000129
SSL0000129
would say: has it gone through? I don't know the system
is down. Well, I got to go, I have got to catch me bus,
has it gone through? I don't know. I have got to catch
the bus and then the system is saying it didn't go
through. Now the customer has gone out with a stamp
receipt, but it hasn't gone through.
ROBERT: And it is three months before it gets sorted.
RON: Yes. The postmaster doesn't know who that customer
was --
IAN: I'm not sure it did. When we started looking at
suspense accounts, we were given the balances that were
still overdue or outstanding at that six month point.
That presumes that much larger amounts were unreconciled
for a shorter period, but very substantial amounts were
still unreconciled after six months.
RON: That tied in with this key phrase we have not
mentioned so far "don't worry it will sort itself out".
The question that arises is -- they were going to answer
is: when will it sort itself out and what am I supposed
to do with a £20,000 shortfall, which I have to make
good today and you are not able to tell me when it is
going to sort itself out? Or am I going to hide that
because otherwise I can't open the accounts or --
JASON: Did you get to the bottom of why some of these
second ones were delayed by six months or more?
RON: No.
IAN: Just that it was a fact that (inaudible).
JASON: I wonder whether that is a -- you said there is
a document somewhere that talks about that process.
I wonder whether that is a Gareth Jenkins type question?
IAN: No, I think this was more POL SAP internal accounting.
[overspeaking].
RON: As in Titanic, the one that was the coward that got on
the boat. If you watched the film or read the book
ROBERT: Never saw the film, I missed the reference.
RON: “Jack, Jack". (inaudible).
JASON: Right. Okay. Number 6: to what extent did measures
49
IAN:
RON:
SSL0000129
$SL0000129
and or control that existed in Horizon prevent, detect,
identify, report or reduce to an extremely low level of
risk data entry errors? Which I think we have covered.
Data packet or system level errors. I do not think --
Again that changed between new and old Horizon.
According to Gareth Jenkins, he was quite proud of some
of the error correction. I mean things that we were
specifically told were user check digits, the ability to
reconstruct failed to (inaudible). And at the system
level, obviously some thought was given to building that
into the design and into the system. The empirical
evidence was that certain things could happen, like
a communications failure or a power failure, and the
system would not recover quite as precisely as Fujitsu
expected it to, in some circumstances.
I'm going to criticise your questions now. You miss
out the word "fraud"
JASON: No, the questions have been handed to us.
RON:
IAN:
When you design systems, financial systems, you not
only have to reduce to as low a level as practicably
feasible the errors; you have to reduce the option of
fraud and I raised this in paragraph 20.15. We say,
again I mentioned it earlier, where you allow customers
the opportunity to commit fraud, perhaps in collusion
with a counter assistant, there is not my point in
stealing from one's own branch because you will have to
make up for the shortfall, unless you run a temporary
loan, but the detection of fraud by counter assistants
is bloody serious because if a customer comes in and
pays £100 and processes £10,000, that immediately
creates --
What we are talking about here is technical error
correction. What I'm saying is Fujitsu designed what,
on the face of it, was quite a sophisticated error
correction procedure but the empirical evidence from
branches was that it didn't work as was sort of -- as
well as Fujitsu sort of claimed that it did, and that
errors did occur as a result of power and communication
failure.
JASON: The evidence of that we can go to your report which
IAN:
references specific (inaudible).
In part, yes. But, again, we were relying on the
evidence from the subpostmasters, not all necessarily
50
SSLO000129
SSL0000129
who are claimants. So you need to be a bit careful.
CHEVAUGHN: Did Gareth Jenkins ever say --
IAN:
Gareth sort of took the party line, we built error
correction into the system and we are satisfied that it
is pretty robust.
CHEVAUGHN: He never said but not always?
IAN:
No.
JASON: We have logged while we were at Fujitsu -- sorry, at
IAN:
the Post Office mobile office and then conversations we
had with Fujitsu since that, I'm pretty content that,
certainly on the new version of Horizon, the
communication between branch and Horizon back office is
pretty robust. It's got (inaudible).
(inaudible).
JASON: The problem is once it gets in Horizon, that's only
RON:
IAN:
in the intermediate area before it goes off to all of
these businesses and it is at that point in time when
all of the control seems to fall away.
We used the phrase, the worst errors were the errors
corrected when correcting errors. We refer to it in
paragraph 12.6 where we say that, time and time again,
we were being told and of course we didn't believe it,
was, you know, I had an error, I had a shortfall, it was
£3,000, I called the help desk they told me to do this
and that, they lost me and I did what they said and now
it was £6,000. Goodness it doubled. They said: don't
do that, do this, this and that and now it is £12,000.
And we heard that so many times. What we --
Ron, that's different from this question. What you
are describing is process failures not technical --
JASON: To be fair it does say measures or controls that
RON:
existed in Horizon and that has to mean and the
operation of Horizon. So I think it is fair to cover
that.
I do concede that it is an extrapolation of the
question to this very serious error issue, which is that
the help desk was trying to help people, clearly; but
the combination of probably not doing exactly what the
technical help desk said or in some cases did what the
51
SSLO000129
SSL0000129
help desk said --
IAN: A common response was: I have done what you said but
my error has doubled.
ROBERT: Did you reach the bottom of that as to why
something happened with a plus rather than a minus?
RON: [overspeaking]
IAN: [overspeaking]
ROBERT: There is not a minor sum somewhere? Is there
a binary thing that you are either positive or negative
[overspeaking].
IAN: In as much as press this, press this again, press this
again [overspeaking]. But actually the system has
[overspeaking].
RON: I did hear, just hearsay, people would say: when
I called them back -- the same thing happened a month
later; I called them back and I said to the person,
“Last time I did this, this, and this" and they say, you
shouldn't have done that. "You didn't seriously do
that, that would have doubled the error". And they say,
“yeah, it did".
So they were saying -- I could not confirm it
because we never got -- the conversations were recorded
but we never got the recordings, so we desperately
wanted to hear some of these conversations and of course
the so-called transcripts, which weren't, they were
simply notes taken by the help desk of what they had
told the people to do -- and when we made the point that
anyone who has ever called the Apple help desk -- and
I do sometimes -- will get an email which says: we had
this conversation, what we asked you to do was x, y, Z
was that satisfactory?
IAN: But they weren't even contemporaneous notes. What
they were was they record sort of issue codes to
categorize the type of issue being raised. It is not
somebody writing down or typing verbatim what happened.
Again, it lost the level of detail.
RON: So we couldn't validate -- attest to the reliability
of those albeit multiple quoted inputs from the help
desk.
52
SSL0000129
$SL0000129
JASON: One of the E codes we were looking at in the
IAN:
RON:
document is duplicate transaction identifiers. That is
to do with the reconciliation on the banking side of it.
So I don't know whether it is saying the
transaction has been entered twice or as a result of
putting the transaction in, and the technical defect, we
have ended up with two transactions.
The impression I got was that because of timing delays
within the system, and it could be linked to
communication problems, subpostmasters at branch level
would think -- would enter something, would get no
response from the system and then they would repeat that
and I'm not sure that there was any effective control
preventing genuine duplicate transactions being --
That was the issuance of a £30,000 saving certificate
for a premium bond --
ROBERT: To me the question about that would be, if the
RON:
postmaster erroneously does something twice and gets
£3,000 out, because it is done in double entry
transaction, zero sum plus, will that come out in the
wash?
No because the customer would only pay in once. In
other words, the customer comes in and says: I want the
biggest investment (inaudible). What about a £30,000
premium bond? That would do nicely, I will use my debit
card.
He will only pay once for sure. But if he gets --
bad example, a premium bond, because a piece of paper
changes hands -- but if it is some other benefit he gets
later or deposit into his account, and he has paid
£1,000 in in cash, but gets three lots of £1,000 in his
account, he is going to keep quiet about that. He is
only going to pay once, the customer will pay once, but
might benefit thrice.
ROBERT: I was thinking of the direction of errors. Is that
RON:
IAN:
the same scenario you are talking about? You know this:
ring the help desk. Is it the same scenario?
The correction of errors ought to be zero sum because
it is solely within Horizon. Then you would be right.
Yes. But the advice from the help desk, to a certain
extent, I felt it was generating single sided
53
SSLO000129
SSL0000129
transactions. Often it was quite a long time after the
originating event. It was often quite late at night.
I think they were told to do various things, but the
results lost were not always reflected immediately in
whatever information was available to the subpostmaster.
At best he might subsequently then have to run some of
the reports after that are available to him. It is not
as if he is looking at a real time live sort of banking
system. He may get told to do some so-called error
corrections, but it would be some time later before he
knows what impact that had on the branch transactions.
JASON: The question is, does it come up (inaudible).
CHEVAUGHN: I thought you were asking then -- so if I -- if
you come to the counter and say: I would like to
withdraw (inaudible).
IAN: No. Somebody ringing the help desk at the end of the
day is not a customer.
CHEVAUGHN: No.
RON: -- is there some sort of gain? Because I can't
imagine any situation or I never came across one where
the help desk would say: in order to do that, you have
got to make a payment through the link system. They
won't, they will just make entries within Horizon. And
I'm pretty confident that that's a reliable process.
No evidence that that process will go wrong, but
there is plenty of testimony that the help desk was
worsening situations and we don't quite know how that
happened yet. Again, we didn't have a test system to
say how would that work?
ROBERT: To test the help desk?
RON: To test the help desk, exactly.
CHEVAUGHN: I think they feed from the (inaudible) so they
look to see if something has been reported in a similar
vein, they reported steps against those and it just
followed --
RON: Yes, because everybody said the help desk was trotting
out script. They said no, no [overspeaking]. Script
waste support.
CHEVAUGHN: If you have two similar tills, where the remedy
54
SSL0000129
$SL0000129
completely breaks things rather than fixes it for the
second one and then that's quite simply (inaudible)
could fall down quite badly.
RON: Yes. I saw lots and lots of printouts from extracts
from the conversations that allegedly took place
involving the help desk, but that was typically a little
paragraph and it would say it was resolved. A little
paragraph that had been typed out by the help desk
person on the phone while in the conversation. It was
pretty superficial stuff.
CHEVAUGHN: I mean --
RON: It didn't say: I told the person to do that and that,
then they made a mistake and I told them to do that
because they pressed the wrong -- it didn't have that
stuff in it.
CHEVAUGHN: I think it is where you are limited to get
through so many calls --
RON: And also you have got to remember that the help
desk -- first of all, the hours the help desk was open
were reduced down and then they realised they had
reduced them too much because, clearly, when they went
to monthly balancing, over a trading period --
originally it was weekly. We said: hang on, why did you
do that? Because by definition you have got four times
as many transactions. If you have got an error, you
could have compensating errors within that month. It is
much more difficult or more risky to check branch
accounting monthly than it is weekly. And if you are
doing it monthly, by definition, you are going to have
lots of people all calling the help desk saying "I have
found I have got problems". So the help desk wasn't
open long enough to pick up the people that were finding
an error in the trading period. They did stagger the
trading period slightly. So not all 11,000 people were
calling the help desk at the same minute, but it was
still a hell of a bottleneck. So I think they were time
restricted on those calls.
ROBERT: I just warn you, I have a meeting I have to get to
shortly after.
RON: There is a chance we might finish by (inaudible).
JASON: Let's crack on.
55
SSLO000129
SSL0000129
ROBERT: I will just duck out.
JASON: Were the Post Office or Fujitsu able to access
transactions remotely? Now, we have taken this in two
different ways. Either the remote control of what was
going on at the branch to affect transactions that would
appear in the subpostmasters' name or, in the
alternative, not necessarily remotely but back at
Fujitsu's base and having an impact on branch
accounts -—
IAN: Cloning the subpostmaster's ID and generating sort of
transactions --
JASON: Less about the ID and more about the -- having some
impact on the branch --
RON: (inaudible) I think under old Horizon, pre-Horizon --
IAN: No. What Gareth Jenkins told me was they had the
ability to log onto a terminal at branch level,
irrespective of old or new Horizon, and they would
sometimes get the subpostmaster to log off, Fujitsu
would then take control of that [overspeaking] remotely.
JASON: That's how (inaudible) every single help desk --
CHEVAUGHN: So the subpostmasters would be aware then
because they would have to come out of the system.
IAN: Where it was a bit sort of a grey area was what
happens overnight, when the postmasters isn't at the
branch, but they left the machine on and I think they
were required to leave the said machine on overnight for
updating or so on --
RON: Or it was one of the assistants because the
subpostmaster has the contractual legal
responsibilities, but it wouldn't necessarily be the
subpostmaster who would be the person who was told: can
you leave the system on.
IAN: Yes. The default position was that the machines
generally were left on. If they are left on, connected
to the network, what Gareth Jenkins said to me was
Fujitsu had the ability to remotely connect to those
machines and control those machines.
CHEVAUGHN: And you saw those out of hours transactions?
56
SSL0000129
$SL0000129
IAN: That was a separate issue because connecting remotely
to a machine opens up all sorts of issues. Quite
separately, what I saw within the XML data, was
transactions occurring outside of core hours. At this
stage removed, I can't remember what user IDs were
associated with that. The significant issues to my mind
at the moment was the Post Office shuts at 5.30,
11 o'clock at night I'm seeing transactions going
through.
JASON: So the possible scenarios there is, whilst the Post
Office is shut, the postmaster or his assistant is
putting through legitimate transactions.
RON: They deny that. They would say: I locked up, the
building was off and I came back in and saw transactions
had gone through while I was [overspeaking] and nobody
was there.
IAN: No. What they would often see is that their opening
balances were different from the closing balances. They
would not necessarily at that stage be able to identify
the transactions.
RON: There was one that did. But you are generally right,
they would say: I closed Saturday lunch time, ran
a balance snapshot, everything was in order. Opened it
up again at 8.30 am on Monday morning and I have got
a shortfall.
CHEVAUGHN: Did they report these ones or were they to you?
RON: They would report that saying something had
happened --
IAN: Not necessarily. They would start investigating it,
but often that investigation would (inaudible) say that
{overspeaking] .
JASON: Presumably the difference between opening balance
and closing balance at branch level should be something
we can get from the data? Do you think?
IAN: Something I tried to do was to reconcile day to day
using just the XML data and I got pretty close. So in
theory it is --
MALE SPEAKER 4: Did some of that XML data include periodic
balances that you were reconciling --
57
SSLO000129
$SL0000129
IAN: Yes because the XML data incorporated the periodic
balances.
JASON: Was there a running balance?
IAN: This is what I tried to do with the XML data. I
opened it into an Excel spreadsheet and had
an additional sort of column trying to track the net
balance as a result of line-by-line transactions.
I wouldn't say I achieved total success with that but
I got fairly close.
RON: We know Ian, don't we, that where the system recovery
was invoked and the system itself reversed a transaction
that it couldn't complete, it did that in the
identity -- with the identity of the person who
initiated the transaction, even though they had not
initiated the reversal?
IAN: Yes.
RON: The fact that that happened, meant that would have
altered the branch balances after hours. But that
wouldn't account for all of the entries that I think
you --
IAN: No.
JASON: Right. Okay.
CHEVAUGHN: Now, surely, if Fujitsu were doing these things
to carry out fixes without bothering the Post Office, if
the subpostmaster phones on Monday morning and says: my
opening balance is £6,000 different to what it was when
I closed it.
IAN: They wouldn't use to do that. What they would tend to
do in that scenario is produce other reports and try and
investigate it themselves. And that --
CHEVAUGHN: The subpostmasters?
IAN: The subpostmasters. Their attitude towards the help
desk was that it was hopeless. And that actually
reporting something like that, which on the face of it
sounds a perfectly sensible thing to do, in the context
of the Post Office it was a complete waste of time.
RON: Worse than that, a lot of them were fearful. They
said they knew if they raised their head about the
58
IAN:
RON:
SSL0000129
$SL0000129
parapet, they stood a very high likelihood of getting
a cash count and they had heard that that was the
courier of death. So they were reluctant to call --
[overspeaking] they would tend to try and investigate
it themselves and that would often go on for many days
if not weeks. It was only when they were getting close
to the end of a trading period that they would really
start to panic.
Also very, very few of them, I can only think of
a handful, four, had thought through to think that there
could be such a thing as a transaction executed that
they hadn't executed. It just didn't occur to them. So
they immediately suspected themselves as having made
a mistake and that invoked the process Ian described.
CHEVAUGHN: I'm trying to think of a scenario where if
RON:
Fujitsu are carrying out these activities and they are
making a difference, if that is without Post Office
knowledge, how would they investigate or what would they
see?
That was fundamental Chevaughn. What I was used to in
business, in banking certainly, was, whenever an error
occurred, even more importantly if you benefited from
the error, you would dig into it and find the underlying
cause in order to invoke the virtuous circle of finding
the problem, fixing the problem, mending the processes
and systems and training, making sure it didn't happen
again, recovering the money. And that process takes you
to a higher plane in terms of building more robust,
error repellant systems. We were saying because of the
infrequency, put it that way, of investigation and the
fact that the postmasters didn't have investigative
skill or ability, that virtuous circle was never
started.
JASON: (inaudible) motivation to start that circle.
RON:
Precisely. Because in any organisation, where
an error causes losses, the organisation suffers from
it, it funds that process. In this case there is no
such reward for spending money on investigating if
actually you don't need to suffer the loss.
CHEVAUGHN: I know we are coming onto transaction
corrections, but it worries me if there is, on a Monday
morning, a £6,000 discrepancy and on Tuesday you
accidently make £100 discrepancy --
59
SSLO000129
SSL0000129
RON: That's why we say reading a month's transaction is so
much more difficult than reading a week's, because you
then get compensating errors and what was a £6,000
shortfall is now £400 surplus and you think you are
okay, and you can pocket the 400, but you can't, because
then you get all services later, by which time it is too
late to investigate.
JASON: What transaction data reporting functions are
available to -- this is the Post Office.
IAN: The Post Office did some quite clever monitoring.
(inaudible) reports or something.
RON: OCH. Overnight cash holding reports, for example.
IAN: Occasionally you would see signs of semi-brilliance
from the Post Office because one of the -- I thought --
quite intelligent things they did was, presumably, write
a programme that calculated the theoretical balance each
night at every branch [overspeaking].
Let's assume, hypothetically, that transactions
going through the branch follow a normal sort of
pattern. A branch in Hampstead might have an average
cash balance of say £25,000. A branch in deepest
Somerset might have a cash balance of £5,000. What they
would look for is the outliers that were not following
the norm for either that individual branch or indeed
that type or sort of branch. And the intelligence
coming from the overnight cash holdings report would
generator or would trigger audit visits, for example.
RON: They were quite good at spotting falsifications of
cash balances, exaggerations of cash balances, because
you would have a branch that would predominantly in a
poor area be paying out and another one that's normally
receiving in, and that was all quite cleverly put
together.
JASON: Did the postmasters declare their cash holding on
a daily basis?
RON: Yes.
IAN: I'm not sure. They had the facility to declare
holding at any point in time because they had
(inaudible).
RON: Well, the strict requirement was they did it monthly.
60
SSL0000129
$SL0000129
But I guess there were different procedures. That's the
way it operated. But good practice was to --
JASON: It was the submission of that cash holding that
triggered these processes.
RON: Yes.
IAN: But I think my point in fact was a wider one. Because
the Post Office had this overview of the entirety of
Horizon, they could in theory look at anything
everywhere.
RON: Clive is right. The system, centrally Post Office
would know minute by minute with Horizon on line what
the cash balance was meant to be.
MALE SPEAKER 4: One of the reasons they needed to was for
remittances. So they could look at the typical pattern
of branches, some branches made a lot of cash, or they
pay a lot of cash out -- by calculating what actually
happened in that branch, you could revise your estimate
of how much cash needed to be sent to it.
[overspeaking].
IAN: The Treasury [overspeaking] gone into, including
foreign currency. At a corporate level there was a lot
they could potentially do with the billions of cash that
was sloshing around.
JASON: It is also the case that -- we have seen part of the
agreement between Post Office and Fujitsu about the
reports that have to arrive by 8am in the morning and
gives all the names of the reports and what has to be
reported and what time you have got to be there and all
that.
RON: The key complaint wasn't whether the Post Office was
getting reported to centrally, it was that the
postmasters, there was one particular person who is
quite central to the case, said: why can't I have
a report generating facility in the branch, rather than
having to look at a 8cm list, as long as a cricket
pitch.
JASON: We have a question about reporting subpostmasters?
IAN: The next question, top of page 5. I think we have
probably dealt with question 8.
61
SSL0000129
$SL0000129
JASON: Yes, we have.
RON: Our paragraph 13 in the report, limitations to the
transactional audit trail, really goes through that
quite thoroughly. I can say that because Ian wrote that
bit.
CHEVAUGHN: Which paragraph sorry?
RON: Paragraph 13. I will give you this later, this
cross-reference.
IAN: Anyway your question 9, what transaction data
reporting function was available through the Horizon
system to subpostmasters? We have touched on the 42
day, which was then extended to 60 days. I mean, apart
from that, there wasn't a lot, is the short answer.
CHEVAUGHN: One of the things that you (inaudible) was
receipts.
JASON: Yes, there is a certain type of transaction that is
either marked not for subpostmaster retention or --
RON: Yeah, that was the giro pay out. I mention it in the
report, where we say it only produced one piece of paper
and that had to go to the customer, which is really bad
if the customer is colluding with your assistant and
says: when I come in and pay £100, can you credit me
with 10 grand please? And the customer would get the
piece of paper that said 10 grand had been paid in.
There is no evidence of the customer's collusive fraud
because he has not had any cross paying in slips saying
that £10,000 in his own handwriting. The customer has
walked away with a £10,000 deposit in his account and
a slip of paper that says 10,000 and there's nothing in
the branch that says that the actual deposit was only
£100.
IAN: What we were told by some subpostmasters is that
[overspeaking] they would keep a desk diary and they
would write significant transactions into a hard copy
diary because Horizon was so hopeless in terms of
failing to provide them with --
RON: Then, if they were suspended, that diary was
confiscated by the investigations team and they never
saw it again. So that disadvantaged them and you
covered that very well in the report Ian by saying that
it was not very good at the best of times, but if they
62
SSL0000129
$SL0000129
were suspended, the one thing that they wanted was their
notebook, their personal notebook, their own record, but
that had been taken away from them and they never got it
back.
CHEVAUGHN: There was also a discrepancy (inaudible).
JASON: Yes.
CHEVAUGHN: At one point we were aware of some discrepancy
reports that then didn't exist. I have seen it in
a document.
IAN: What often gave rise to a discrepancy being
identified, when they were doing the daily
reconciliations, for want of a better word, there is
a point at which you have to enter the amount of cash on
hand, but there was a report that was run which would
tell you what your cash balance should be. And in
practice what happened with some subpostmasters is that
they would run the cash on hand report and again --
RON: Balance snapshot was the main one. [overspeaking].
IAN: [overspeaking] onto the system.
RON: What the balance snapshot said, that is right.
IAN: Actually it was one of the ways that the Post Office
would detect false declarations because the theory was,
even the best run branch is likely to have some minor
discrepancies and if they always match to the pennies,
that was the red flag.
RON: Interestingly, let's say the balance in my Post Office
tonight should be £12,911. If it was £13,911 I was
meant to enter that figure and then I would be entitled
to keep the thousand pounds. Of course nobody did that.
They would run the balance snapshot, it should be
12,911. So they would say let's keep to the figure of
12,911 and keep the £1,000. We may laugh but that
choked off a critically important source of error
detection. Because it meant that the Post Office only
became aware of shortfalls and it was blind to
surpluses. And that to my mind, in terms of control
design, was extraordinarily significant. But I couldn't
really ever convince the Post Office of that for some
reason.
IAN: Just for completeness, to answer that question, on
63
SSLO000129
SSL0000129
request subpostmasters could ask for this more detailed
reporting from Horizon, but as often as not it was
turned down on grounds of cost.
JASON: And they are the ARQ --
RON: Yes. I think basically the audit team said we have
only got 12 a month. We need 14. The last thing we are
going to do is give it to Jo Bloggs that doesn't know
what he is doing anyway, why should we give him that, so
they didn't do it.
JASON: (inaudible) TC.
RON: Yes, I don't think I came across any cases where that
request was fulfilled.
JASON: Right. Okay.
RON: In the event it has been fulfilled, such as in
instances I'm not allowed to mention, then what was
actually supplied was the distilled Excel spreadsheet
stuff and very few of them had the nouce, only those who
had come from a programme background or background like
yourself who had retired and decided they would run
a Post Office, people did that, they would say: I want
the XML data. But of course that got nowhere. So very
few of them recognised that what they were seeing was
unfiltered data.
JASON: Number 10 is -- we covered that. 11, I think we
covered that as well.
RON: We don't know, do we? The Post Office first of all
said it couldn't be done. Then they said it can be done
but it is subject to [overspeaking].
IAN: Are you talking about 10 or 11?
RON: I'm on 11. If they did, did Horizon (inaudible)
commission controls. We were told, yes. It was
extraordinarily rarely deployed and there were high
security levels over who could deploy it and how that
audit trail.... We never saw that. I don't question
there were but --
JASON: Did you have that demonstration about how it is
done, about how it is a secure terminal through layers
of concrete, things like that? And it has only ever
been used once to create a transaction?
64
SSLO000129
SSL0000129
RON: I think that was the tone of what we heard.
IAN: What would be very interesting would be to ask what
were all these people doing in Fujitsu, including the 60
Post Office staff. The closest I got to understanding
that was when I asked for all the email records and we
got them. I saw the emails but I thought not the
(inaudible) we asked for. But looking at that, it was
clear that there was a lot of what I might call behind
the scenes activity going on that was beginning to cause
me concern. There was a lot of activity that was
unexplained.
RON: You asked for 2008 and you got 2011. Then you
eventually got some of --
CHEVAUGHN: The name (inaudible).
IAN: There was quite a lot of emails in the list, but
I think they were encrypted and at one point we were
told that the Post Office had lost the passwords.
RON: Then they withdrew -- because we had been offered
unlimited access to that stuff under the previous
general counsel. Then she left and then it tightened up
considerably and they said, no, you are not going to
have that anymore.
JASON: I also think (inaudible) the protocol says that
(inaudible).
CHEVAUGHN: No. We are not in the schedule -- we are not --
FEMALE SPEAKER 2: I think there are two things being spoken
of here. In the staff (inaudible). The basis for that
is understandably searching emails (inaudible).
RON: Yes. We said we want to know the names of the people.
We knew the name of somebody Rolf, who is the chap who
met with the postmaster who said he had seen all this
funny stuff going on --
IAN: That was only part of it. We were asking for emails
trying to dig into that specific allegation but once we
discovered there were 60 Post Office people in -- we
were trying to work out what were they doing and we felt
one of the best ways of actually, from a contemporaneous
perspective, finding out what they were doing: well let
us see what they were saying in emails. And we never
got that.
65
SSL0000129
$SL0000129
FEMALE SPEAKER 2: (inaudible).
CHEVAUGHN: Yes.
ROBERT: (inaudible).
JASON: Okay, good, good.
IAN: 12, we don't know what the answer is.
JASON: I think we are going to simply ask the question. We
have got enough documentation to support the process
going on.
IAN: Yes. If it was used it could affect the branch
accounting.
RON: The business model impact, credibility impact was
massive. That's what's reflected in that internal
memorandum that we quote quite extensively in the
report, where they are saying: if this gets out the
impact could be quite disastrous. Because it would
clearly generate copycat claims and that would seriously
undermine the profitability of our system.
JASON: So onto number 14.
IAN: 14 (a) there was a basic reporting function to compare
stock and cash and it was regularly used by
subpostmasters.
JASON: Does that show all of the transactions that --
IAN: No, it wasn't the transactions. It was more of
a balance report showing that, according to Horizon,
your cash balance is x, for example.
JASON: So if it says you have got three first-class stamps,
you can't say: give me all transactions that included
first class stamps?
IAN: I think that is a question for a subpostmaster rather
than us.
JASON: It might be in the operating manual as well.
ROBERT: I think as you say this is a balance report. We
have seen it.
JASON: Okay. Enable/require subpostmasters to decide how
66
IAN:
RON:
SSL0000129
$SL0000129
to deal with dispute, accept or make good discrepancies.
It wasn't so much how to deal with it, it was the fact
that, according to the system, there was a discrepancy.
It was then down to the experience and judgment of the
subpostmaster of how to deal with that and the option
ranged from phoning the help desk to you will be
accounting cash or stock.
Also there was a very widespread perception, which was
incorrect, that unless one closed off balanced and
processed all the -- you couldn't open the following
morning without being in breach of contract. You could
actually because you could continue to operate in the
month that was supposed to be closed. But there was
a limit how long you could do that. Not many people
know that. But then you get into this issue of could
you invoke the settle centrally dispute that you are
referring to and the answer is, yes. But it is limited.
(a) if you have already (inaudible) -- I think it
was the third of net salary. So if you were on £21,000
a year, you could put 7,000 quid of stuff in there. But
once you wrote 7,000 you couldn't put anything else in.
Once you put something in (inaudible) you were
effectively saying: I am making a contractual commitment
to pay this if the dispute doesn't settle. Basically
I'm putting this into my personal account, with you Post
Office.
JASON: [overspeaking].
IAN:
RON:
IAN:
RON:
IAN:
A number of subpostmasters told us they had a petty
cash till and [overspeaking].
That was correct practice.
And if it was £200 that would work, but if it was
suddenly £5,000, it doesn't work.
There was something else I'm trying to bring back to
memory. There was something to do with -- there were
three options. They could pay in in cash; pay a cheque
in and clear that week. Settle centrally. It emerged,
if I were to believe everybody who told me this and
there were a lot, that some of them didn't even know
they could do that. They didn't know there was a settle
centrally function at all.
There was another option that had to be agreed by
67
SSLO000129
SSL0000129
their area manager or something like that.
RON: And you couldn't do that because it was 7 o'clock at
night.
IAN: And you were putting your head above the parapet.
RON: The key issue was, if you had a shortfall larger than
you could -- you were allowed to put in central
settlement, you had to pay it in in cash that day.
That's easy, or you had to pay in a cheque and you
couldn't dodge that. You had to pay in a cheque that
would clear immediately and that was an impossibility.
That was the terrible dilemma that some of these people
faced. Especially when they called the help desk. They
said: don't worry, it will sort itself out. When,
tonight? No, it might take three months. What am
I supposed to do, I am supposed to pay this off tonight?
Frankly, that's what is the core of this case.
JASON: But that only came in with the advent of Horizon?
RON: No, it came in with the closing of the branch suspense
accounts because obviously -- well I don't know, but
(inaudible) imagination to realise that, since they
opened the door to do that, it must also --
IAN: It was made worse when they changed from weekly to
monthly. Because obviously the balance [overspeaking]
were caught much earlier. One weekly accounting.
RON: So I think the branch suspense accounts, the
impression I got, I haven't anything reliable to
evidence it, was it just ballooned out of control and
they said, stop that. The moment they did that, this
whole situation started to get worse.
ROBERT: (inaudible).
RON: You got me. Do you want me to guess?
ROBERT: Give us a guess.
RON: I guess it was between 2012 and 2016, but I'm
guessing. So reliability of about 30%. It is quite
easy for us to detect that. I wouldn't do that in the
witness box, don't worry.
JASON: (inaudible) reflect the consequences of raising
68
SSL0000129
$SL0000129
a dispute. We have talked through that. Does raising
a dispute with the helpline cause a block to be placed
on the value of the alleged shortfall?
IAN: I do not think it was the help desk. I think it
was -- what we have just gone through -- how you deal
with the shortfall, for example, settle centrally, make
a false cash declaration and so on. I do not think the
help desk --
RON: I have never heard that terminology used, so the
answer would be no. The inference of your question is
by putting a block on something, it was subject to
investigation and there would be no punitive action
taken in respect of it.
JASON: Yes. I mean [overspeaking]
RON: No, there was no such [overspeaking].
ROBERT: Many thanks that has been --
RON: Robert, lovely meeting you.
ROBERT: Thanks a lot.
RON: You don't want to take some sandwiches with you?
A large carrier bag.
(Pause) .
JASON: Right. Okay. Is that recorded on the Horizon
system as a debt due to the Post Office?
RON: Yes. The moment you enter something settled centrally
is a debt to the Post Office, which is either disputed
or not disputed, and it can either be paid off over
a period of time through a deduction of salary, provided
it doesn't exceed one-third of salary or you can pay it
off next (inaudible).
JASON: This is something about whether anything changed at
a particular point in time that enabled some
subpostmasters to produce a cash account before 2005 and
then a branch trading settlement after 2005.
RON: Pass.
IAN: (inaudible) we don't know.
69
SSL0000129
$SL0000129
JASON: Enabling subpostmasters to continue to trade if they
RON:
did not complete the branch trading system.
This is the "not many people knew that." They could
but only by extending the trading period that was meant
to have ended and that would trigger a warning bell or
red flag at Post Office centrally. So they were
reluctant to do that because that would bring down
an air strike.
JASON: The last one, they are talking about transaction
RON:
IAN:
RON:
IAN:
RON:
corrections and that process. What we know about
transaction corrections or what I can adduce is that
somebody back in Post Office does some sort of
reconciliation -- a customer, whatever, puts a journal
entry on POL SAP, presses a submit. The following
morning when the till boots up, it drags this
transaction --
Strictly it should be approved by the subpostmaster.
They have to accept or reject --
What I'm getting at is, as far as I can recall, there
was no system check that checked that the identity of
the person in the branch that accepted the transaction
creation was the subpostmaster.
Well, that was more to do with the idea of log on. If
you logged onto the system by default you could --
The reason we raise that, Ian, is because there were
one or two postmasters at several branches and some were
known to be absent from the branch. You were allowed to
do that and you would appoint the manager. The point we
made was, look, if you issue a transaction correction of
substantial size and you send it to the branch, and
muggins accepts it, there is a manager or less in the
branch, did you not think it would be a good idea to
send an email to the actual postmasters saying --
JASON: Who is carrying the liability.
RON:
That's what happened in one of the ATM cases where the
correction -- I mentioned earlier the person was repaid
27,500 -- that was repaid in the form of TC, credit
note, that was misprocessed by -- in fact it triggered
a fraud -- by the manager. The postmaster didn't even
know that after 13 months of fighting he had actually
got his money back. He never saw the TC. So, clearly,
70
in designing the system, you would expect the system to
say wouldn't it be a good idea if the postmaster gets
note of everything material happening in the branch and
it didn't do that. Again that's part of the (inaudible)
story.
CHEVAUGHN: So there's also like a relative description, is
there, this is a section for the banking transaction --
RON: Yes, this relates to Santander --
IAN: It refers to the originating transaction with
a reference number and short description as to what the
TC --
RON: And an invitation to challenge it.
JASON: Have you got any screen shots of that or printouts
of that?
IAN: No, sorry. [overspeaking].
JASON: Might you have had any of those and you returned
those?
IAN: We were told about them but I do not think --
RON: I saw some in the working papers. We saw thousands
and thousands. The 35,000 pages that we returned, there
was a lot more stuff that we saw in the work papers
I think and on the POIRs and that sort of thing.
I looked at the transaction corrections. The most
frequent and largest TCs that we looked at related to
ATMs.
JASON: And that is that the amount that the ATMs says it
should have within it, doesn't match the amount --
RON: The postmaster said was in it.
JASON: Right. Okay.
RON: That's exactly it.
CHEVAUGHN: Were there any corrections that then had to be
corrected?
RON: Yeah, because the invitation to challenge sometimes
resulted in the TC being -- another TC being issued to
cancel out the effect of the first TC.
71
SSL0000129
$SL0000129
SSL0000129
$SL0000129
IAN: We heard of some TCs that were written off.
RON: Yes.
JASON: That leads to more questions really, how many of the
TCs that were issued.
RON: There are all sorts of statistical questions like for
every hundred TCs were issued, how many were credits,
how many were debits and what were the amounts of each?
That is a good question and how many did you reverse?
Did you reverse more debits than credits?
CHEVAUGHN: This is what we discussed with Robert last week
but we didn't know if there were any specific document
names or anything they might --
IAN: The Post Office had reports covering TCs.
RON: There was a lot of this investigative process that we
did not complete because we went onto looking at lots
and lots of individual cases. That took us away from
some of (inaudible).
JASON: There is some TC material arriving this week, isn't
there?
CHEVAUGHN: Yeah. About the number and extent of
transactions issued, TCs issued in (inaudible).
RON: What we found with ATMs frequently was it would just
yoyo, see-saw. A person would get a £20,000 debit TC
and then next month they would get £30,000 credit and
then a £10,000 debit one, and they were swinging all
over the place and that was causing them immense
difficulty in working out other errors that sat below
those because the amount was so huge.
IAN: Yes.
RON: That things were being (inaudible) in plain sight.
MALE SPEAKER 4: Was that because of timing?
RON: Yes.
JASON:
MALE SPEAKER 4: -- examples being taken --
72
RON:
SSL0000129
$SL0000129
This has to do with: do it at exactly 4.30 wasn't --
[overspeaking]. It was just not always achieved by
people who were rushing around putting parcels together
and also of course to do that you have to open the ATM,
which meant you had to shut the branch. [overspeaking].
If you have got a queue of people going out the door --
which often they did -- and you said: do you mind all
clearing off for 10 minutes, while I open the back of
the ATM? Go on.
So they would put off opening the back of the ATM,
by which time the money was taken out of it, and the
report was going to say: that was the figure at 4.30 but
you are doing it at 5.15, by which time the figure is
different and that's what threw me.
JASON: Surely something as simple as that could have been
RON:
IAN:
RON:
IAN:
RON:
IAN:
RON:
corrected by modifying the actual process.
That's a good idea. Why didn't I think of that?
Okay. But again, see, the point fundamental is, again,
if you go back to Tescos or Waitrose, those people
inside have got no responsibility for what's going on in
that ATM. When that decision was taken to involve the
subpostmasters in something extremely risky -- you are
not talking about change, you are talking about £144,000
in that ATM -- that was a profoundly risky thing for
some of these people to take on, way beyond their
(inaudible).
And they didn't have much choice in the matter.
They had no training. The only training they had got
was from (inaudible) who told them about filling
cassettes. (inaudible) were strictly under instruction
to not train them how to deal with the entries into
Horizon and they never got training on that.
It was worse than that because when ATMs were first
introduced, there was a third party that dealt with the
topping up of cash and everything else and --
There were suspicions of step theft by some of those
individuals.
Subsequent to that the Post Office said, no, we can't
(inaudible) for the subpostmasters to do all the work
and a number of them didn't want to do it.
The Post Office itself quoted the numbers in the
73
SSLO000129
SSL0000129
report, I can't remember what page, we quote the number,
it was massive. Prior to improving or streamlining the
process for ATM handling -- sorry -- the handling of
these output reports from the ATMs and input into
Horizon, there was a massive -- Branch Focus reported on
a massive amount -- number of errors of huge magnitude
and they said: when you correct the process to the new
process we are now describing, you will have cash
shortages. They warned the branches about that. So it
was clearly a recognition that the process that had been
in place was not particularly error repellant; subject
to a lot of mistakes that were of serious magnitude and
then they put in the new process, which was better but
it was not full proof.
JASON: It is very helpful from the complex perspective --
RON: You appreciate under every sentence of our report,
every paragraph of our report, there is a mass of
knowledge that is quite carefully worded and minimised
because we were immersed in this for three years.
CHEVAUGHN: Please don't be offended if it is in the report,
I have had that much stuff I have literally lost things.
This reduced reboot clause. What is that?
RON: This was all about the recovery process. When the
system clearly went down through a power failure or
a telecoms failure, the Post Office's position was: no
loss can be incurred unless the postmaster makes
a mistake in carrying out the reboot process. Now,
I can't remember exactly what they meant by the reduced
reboot process, but it was obviously an attempt to
simplify the reboot and recovery process. But Ian made
the point earlier that the real issue was that
following -- to use a subjective word here --
CHEVAUGHN: You can't see the screens.
RON: Not just that but it wasn't easy. When the system has
gone down and you have to do this and do that, the
screen is going to tell you this and then the screen
is --
IAN: [overspeaking] .
RON: Have you lost any giro transactions? And the person
will say: I don't know. So they would say: yeah.
They'd say: which transaction did you lose? They
haven't a clue: let me say no and see what happens.
74
SSLO000129
SSL0000129
CHEVAUGHN: Do you think that this is to handle recoverable
RON:
IAN:
RON:
IAN:
RON:
IAN:
RON:
IAN:
RON:
and non recoverable transactions within the recovery
process?
It is part of it. Yes. Because they did use that
terminology of recoverable and non recoverable
transactions. That's to do with internal processing.
It is also potentially triggering reconciliation
issues because you might have had a bank payment --
Which is not recoverable.
-- which has not been fully processed in Horizon.
In other words, you can't do anything if it has gone
down the pipework to the bank. So you can't recover
that, you can't reverse it. So you have got to do
something about the other side of it.
One of the system errors we have not touched on is pin
pad problems. Again we both remember being told about
problems with pin pads, which was sort of the hardware
fault and, again, often the subpostmaster would be
unaware as to exactly what had happened, whether
transactions had been duplicated and so on.
And it is a source of fraud because time and again,
with the criminally minded postmasters, you can persuade
the poor old lady at the counter, or old chap like me,
who has just drawn down his pension and they say: Did
I draw last week's pension? No. Rather, yes, you did,
when they didn't. And there is no doubt that there was
an opportunity for fraud at the counter against
customers.
Yes.
Actually what we were told was a number of evil minded
postmasters found it quite easy to cover the shortfalls
in the system because they would simply make the money
off customers and that was particularly loathsome.
MALE SPEAKER 4: Surely that was being reconciled with the
RON:
benefits payment system of pension --
You can't. Literally what would happen is the
customer would come in and draw £90 but be two weeks
behind. So would simply say, "I can't remember whether
I came and got the money last week." And they say,
75
SSL0000129
$SL0000129
"Yeah, you did, you are up to date." But, yes, you
would think that would be picked up by the system --
MALE SPEAKER 4: (inaudible) pension in that week --
RON: What they were doing was putting it through twice.
IAN: There was some benefit vouchers that weren't being
cancelled and I think the procedure was [overtalking]
this is before POCA.
RON: Even after POCA some would say I have lost my card can
I use [overspeaking] so they would invoke a backup
process for that.
IAN: There was quite a big investigation into the recycling
of, I don't know whether it was benefits, cheques or
vouchers, because the process was that they were
effectively not being cancelled at the time that they
were being submitted, and they were being processed
through multiple branches.
RON: Referring to pin pads, if a customer was withdrawing
money, it is very easy to say: right, I want to withdraw
£100. “Put your card through. I'm afraid that didn't
go through, could you do it again." There is no doubt
that some daft old people are targeted by some awful
branch staff --
MALE SPEAKER 4: Making them take two transactions?
RON: Yes. "That one didn't go through dear, can you try
again?"
IAN: Even on the screen I think one of the icons was for
number of [overspeaking] say 00 and again that would
give rise to [overspeaking] .
RON: I just said part of the rebalancing you would
ordinarily build in would be to detect a flag to get rid
of the transaction coming in and that isn't in place.
So that is again part of a policy that you would have in
a--
JASON: We saw that with fast cash when we were in the local
office. The fact that you could easily hand £100 to
somebody. If you don't press fast cash complete,
(inaudible) you process it, but then Horizon tells you
it is 200. So you (inaudible) 200. You give them 200.
So you accidentally give out £300.
76
SSLO000129
SSL0000129
RON: With something as inevitable with the complexity of
that nature, we like to say how many transaction types
can you carry out in a typical high street bank? It is
not 170. You can't get a fishing licence in a high
street bank.
IAN: I have tried to do that.
CHEVAUGHN: Do you know, the actual transaction print that
the postmaster would print. So if you have a basket,
these baskets, [overspeaking] yeah. So if I buy three
items, those -- the numbers allocated against that item,
they should all be sequential, shouldn't they? So it
should be my branch ID log on and then it should have
its own transaction ID and that should be 1, 2, 3?
RON: Yes.
CHEVAUGHN: Then if customer 2 comes in and they're served
by a different person, it would be under the second
person's log on and theirs should also be sequential.
So then the person who goes to that second till person,
their basket should effectively follow on from that
previous basket, shouldn't it?
JASON: Yes.
RON: They are sequential by stock unit.
MALE SPEAKER 4: So if you are operating a till, every
transaction you carry out through your machine should be
recorded with a unique sequence number, which is one
higher than the previous one on your PC, and the person
next to you is in a separate series.
JASON: I'm not sure though. They call it a master slate
set up?
RON: This is where you get what is called individual or
separate stock unit balancing. Smart people would from
the get go set up individual stock unit balancing. So
that each till can be checked. So if you have got
a badden, you can identify straightaway which person has
come out short every month.
Most branches were not set up that way and it was
rarely -- sometimes it was recommended that they did
that -- but it does bring extra complications, but sure
as hell brings lots of advantages. We thought it should
be almost standard practice to always do that.
717
JASON: So that -- we saw that when we looked at some of the
IAN:
data. But we saw missing what appeared to be missing
sequence numbers, but then you see it far later on and
it is because that missing number was actually part of
the transaction of another (inaudible).
I seem to remember when I was going through the XML
data, there were some sequences that actually turned out
to be complete, but they weren't in sequence.
JASON: That is right, it is because one transaction might
have been done very quickly on one counter and on
another counter it might have been added to the
transaction stack a fraction of a second afterwards, but
that whole basket might not have been completed
[overspeaking] and therefore it was much later down --
CHEVAUGHN: But there would still be no missing numbers.
JASON: I think that is right.
MALE SPEAKER 4: When the numbers are assigned, the basket
may be completed five or six minutes later, and that's
why, when the other transactions have happened in
between, they appear in that sequence and the next one
after this would be a long way down.
CHEVAUGHN: When it is saying there is a power failure and
that till goes into recovery and that points to those
transaction IDs; that should match what exactly that
transaction was. So if I have bought a stamp or
withdrawn £200 and that has a sequence number 1, then my
recovery ticket should say this is relative to
transaction 1.
MALE SPEAKER 4: You were processing transaction 1.
CHEVAUGHN: It won't increment as its own unique number.
MALE SPEAKER 4: If it did there would be a fault in the
RON:
recovery process.
Later on you ask about how things operated prior to
Horizon. A number -- some people I spoke to, third,
fourth generation of running a Post Office, 30/35 years
running branches -- many of whom spoke highly of the
Post Office and of Horizon. They said it was difficult
in the old days, but one thing we could do was we had
all these envelopes with all the tickets in. So if we
had a shortfall, we had everything in our control and we
78
SSL0000129
$SL0000129
SSLO000129
SSL0000129
could go back and look through them. We can't do that
anymore. That's really what -- another core issue.
That's just (inaudible) technology --
RON: It is. But when you hear somebody, a lady who is
third generation, running the Post Office for 30 years,
the first question I always ask them is: prior to
Horizon, what is the largest shortfall you have ever had
and what was the typical shortfall? It was 30 quid.
Then you say: well what happened? You have got a
£20,000 shortfall. And then they would say, after
running the Post Office for 90 years as a family -- you
would say: right, so why was it so difficult to find it?
And that's when they say the system was working well, it
was fantastic, it was really good, and this is a person,
an old lady sometimes. But when it comes to
investigating things that have gone wrong, "I couldn't
do it".
MALE SPEAKER 4: I want to make sure I have clarified
something because I thought I missed a point. I think
it was you, Ian, who said we missed pin pads
(inaudible). And when we discussed the issue with pin
pads, it wasn't the hardware problem I heard, it was
fraud, getting the old lady to enter her pin in twice.
That isn't a hardware problem.
RON: Correct.
IAN: I do recall being told that there were hardware
problems with pin pads.
RON: There were. Because there was a swap out process. So
the pin pad --
MALE SPEAKER 4: I see.
RON: It wouldn't work.
MALE SPEAKER 4: You type in your pin correctly
[overspeaking].
RON: It wouldn't register so they would do what's called
a swap out. They were outdated, no longer manufactured.
Fujitsu would send a new one. People said it was filthy
when it came out; "I didn't want to touch it".
IAN: This is a general criticism of the hardware. It was
recycled, it was old, it was unreliable.
79
SSL0000129
$SL0000129
RON: Some people would say: we had three sent out before
I got one of them to work.
IAN: Even the hard drive, I think there was no -- they
would often find sort of five year old hard drives in
the terminals. Surprise, surprise, it didn't work.
JASON: Even now the current terminals are still Windows NTL
version 351.
RON: They were using XP for a long time?
IAN: No. NT.
RON: New technology.
JASON: That's 1995. It is quite scary. [overspeaking].
IAN: No anti-virus.
RON: I can remember (inaudible) and 360. [overspeaking].
JASON: Do you want to take us through the other --
MALE SPEAKER 4: I checked with Robert about these. To do
these -- are you thinking of question 3, Jason?
Particular --
CHEVAUGHN: Yes.
JASON: Yes.
MALE SPEAKER 4: I am sure everyone can see from this the
kind of things that Rob was hoping to get at. We
covered quite a few of them. To actually try and go
through each of these thoroughly will probably take
a bit of time, so I just checked with Rob before he left
if there were any particular ones he had to call out and
the answer was, no. So unless there are -- looking at
that list prompts either of you to --
RON: Again, coming back to what Chevaughn said about this
reduced reboot clause that you mentioned here. I can't
remember what exactly the reduced reboot process was.
I can remember the recovery process. But I can't
remember what the reduced reboot process was.
MALE SPEAKER 4: Is that how it is cited in schedule 3
(inaudible).
80
SSL0000129
$SL0000129
CHEVAUGHN: That's taken literally from the protocol that we
are allowed to discuss. So that is from the legal
document.
JASON: It must be (inaudible).
RON: It rings a bell.
MALE SPEAKER 4: I think your guess Ron is probably right,
that it was a simplified --
RON: Improved --
MALE SPEAKER 4: On question 3, just if you wouldn't mind
casting your eyes over those and see if that prompts any
other important comments.
RON: I'm perfectly happy to give up a copy of this. What
I have done is cross referred to the report. For
example, investigate any discrepancies --
IAN: I am not sure we should. I think we need to maintain
(inaudible) not for any adverse or (inaudible) concern,
but you have got your job to do. We are appearing as
a witness of fact. We will probably (inaudible) witness
statements at some point.
RON: Actually it is not complicated to do. I simply went
through our report. By the way, nobody has mentioned
the Part 1 report. Some of your questions relate to
right at the beginning here, where you say the system
architecture, the insulation, Horizon online. The whole
purpose of the Part 1 report was to say how things are
meant to happen. Also sort of commonly account of
errors, things you would expect to see. The Part 2
report which got much more attention because it is in
the public domain is more focused on what we found, as
opposed to statements of what Post Office said was meant
to happen.
IAN: There is really the three reports are the --
RON: Interim.
IAN: Yes, and actually revisiting it, our so-called interim
report, I think, is one of the more interesting sort of
reports because we were focusing on a small number of
very specific issues and we go into quite a lot of
detail and that was when we first learnt about sort of
programme errors.
81
JASON: What did she say we can't have?
IAN: The only reference [overspeaking].
RON: While I was on the train I cross-referenced --
JASON: Can't we just go down the list, and if you don't
want to hand it over, just shout out the references --
RON: Just take a photograph of it.
IAN: There isn't anything else on it?
RON: No.
MALE SPEAKER 4: There is no opinion, no other cases --
RON: Have a look. It is rather untidy because I did it
while the train was bouncing around.
JASON: It is only because after you said I could have it,
I stopped writing down --
MALE SPEAKER 4: So did I.
RON: It is simply and no more than me saying --
CHEVAUGHN: Sorry, Ron, how about you give it to me and
I just literally tidy it up.
RON: Yes, because you might need to check them. It will
say [overspeaking].
IAN: I'm just nervous that if it goes into quite a lot of
detail it is more than just paragraphs and references.
I don't want us to be criticised at some point for
influencing you or telling you what to do.
RON: Fair enough.
CHEVAUGHN: I think the best way is if I --
RON: It is commonsense. I only got this because of
chairing a meeting the last couple of days, so as
I looked down there I thought we have covered that and
that as well. I thought it would be nice to know which
paragraph addresses the point you raise.
MALE SPEAKER 4: We will get a sanitised version of that.
82
SSL0000129
$SL0000129
SSL0000129
$SL0000129
CHEVAUGHN: Literally --
MALE SPEAKER 4: If anything you feel is dodgy --
RON:
IAN:
RON:
IAN:
RON:
IAN:
RON:
Although we looked at 19 thematic issues in the
original master spreadsheet, in the columns across, we
only I think put paragraph headings in the Part 2 report
for about eight of them.
No, I think everything was marked across.
I know one wasn't and that was the assertions that
there had been skullduggery in transfer of branches, for
example. That was under the master spreadsheet. We
never put anything in the report about that.
That's in the unevidenced assertions made by people
that had been quite -- that's in the list of documents
that has now been disclosed.
Yes. Ian prepared a very thorough, very nicely
indexed in section summary of the documents that were
returned. We had a case reference number for every case
and within that all the documents relating to each case.
So, that was the structure of the report --
One of the things we have been unable to do, and I
know you and I are going to discuss this, when I handed
over the 34,000 documents or whatever it was to the Post
Office, the detailed schedules and (inaudible)
documents; the document listing disclosable to the
documents was only around 30,000. Because of the way
that that was produced, which was from the (inaudible)
presumably, it doesn't match the formatting and
description of the original sort of file list that
I produced. Therefore, we haven't been able to
cross-reference the (inaudible), which, as an ex-auditor
or as an auditor, I just felt uncomfortable about.
I would prefer to be able to reconsile the two lists and
we haven't been able to do that at the moment.
Yes.
JASON: I'm not sure there is a great deal we can do about
RON:
that.
One thing that I have suggested is, if the original
documents were handed back to us, we probably could do
that, but we can't do it just from the list of
documents.
83
SSLO000129
SSL0000129
JASON: Yeah, because some of the names are meaningless --
IAN: Yes truncated and everything else.
CHEVAUGHN: (inaudible).
JASON: In a sense, at the moment, they are Post Office
documents, aren't they?
CHEVAUGHN: Yes, Post Office's documents identified in the
Post Office (inaudible) and as per our disclosure
obligations to each other. But I am sure there are some
things we can do to --
JASON: (inaudible).
CHEVAUGHN: Yes.
IAN: At the moment it is about 4,000 documents missing and
we don't know which ones they are, which is not
explained by the unreadable document list.
RON: Some of those unreadable documents are documents which
were encrypted with a password. I do not think there
were any instances where we were unable to read
a document --
IAN: Every encrypted document we were given by the Post
Office we were able to decrypt.
CHEVAUGHN: I think this is probably a lawyer to lawyer
conversation about to what extent we can recover those
documents and the (inaudible) document.
IAN: I'm just mentioning there is a discrepancy and we
don't know what that is at the moment.
RON: Good. All right.
JASON: That has been a reproductive and interesting --
RON: Thank you. You over did it on the catering.
[overspeaking]. I enjoyed meeting you all.
[overspeaking]. (Interference).
84