This is the transcript of Day 17 of the Horizon trial, the second trial in the Bates and others v Post Office group litigation, held at the High Court's Rolls Building on Friday 7 June 2019.Jason Coyne, independent IT expert for the claimants, spent his last of four days being cross-examined on his expert reports by the Post Office's QC, Anthony de Garr Robinson.Mr Coyne's reports can be found here. The transcript follows:
Friday, 7th June 2019
(10.15 am)
MR JASON PETER COYNE
Cross-examination by MR DE GARR ROBINSON (continued)
MR JUSTICE FRASER: Before we start, just formally I'm
handing down judgment number 5, which is the reasons for
the costs and the other orders of 23rd March. The
reference is 2019 EWHC 1373 (QB).
My learned clerk is going to give each party one
hard copy. There are three other hard copies, one of
which is for the press, there are two spare. If anybody
wants it emailing, if they put their email address on
a piece of paper and in the mid-morning break my clerk
will email it and it is going on BAILII later.
The other point, which is just a reminder, can the
two of you, please, between you, make sure that at the
end of the day you remind me to mention to you the PEAKs
and KELs hard copy.
MR DE GARR ROBINSON: Between us.
MR JUSTICE FRASER: There is a good chance during the course
of today excitement will overcome me and I will forget.
MR DE GARR ROBINSON: Between the three of us hopefully
someone will remember.
MR JUSTICE FRASER: Right. Mr de Garr Robinson.
MR DE GARR ROBINSON: My Lord.
Mr Coyne, good morning.
A. Morning.
Q. I believe you have some homework to provide this
morning, is that right?
A. Yes. There was a number of questions that were asked
the other day that I have got the answers to.
Q. Yes. I'm not going to ask for oral answers. Have you
got pieces of paper indicating particular PEAKs and KELs
or whatever it was that you wanted to rely on?
A. Yes, I have got some notes here, they are rather rough.
I thought I would be reading them out rather than
handing --
Q. It is really a matter -- of course it is up to his
Lordship to decide but I would rather not have evidence
read into the record in that way. If you have documents
you wish to rely on then by all means produce them
but --
MR JUSTICE FRASER: Did you bring copies of the documents or
references of the documents that you were asked to
provide?
A. Some of them, my Lord. Some of the other questions were
about how many, so I have got a number of how many,
rather than a reference to all the documents. So, for
example, it was about how many retrospective OCRs and
OCPs, so I have a number for that.
MR DE GARR ROBINSON: Actually I specifically don't want
evidence being read into the record which isn't
supported by document references and which is the
basis -- which is the fruit of work that you have done,
would this be right, this is all the fruit of work that
you have done since your last joint statement with
Dr Worden on 4th March, yes?
A. Yes.
Q. And this is the fruits of clever searches that you did
since that time, correct?
A. It was a simple search for the word "completed
retrospectively", that was the word I searched for.
Q. That's not the only item that you are going to address.
All of those items are matters that you have discovered
looking at the documents since your fourth joint
statement, correct?
A. Yes.
Q. Do you accept that in accordance with your duty as
an expert and as a matter of basic fairness to
Post Office, you should have provided this material to
Dr Worden and indicated the conclusions you were drawing
from it before this evidence started?
A. Mr Worden -- Dr Worden will have this material. These
aren't new documents. They are documents disclosed to
both of us at the same time. I haven't made a point in
my report about these retrospective OCRs. It was as
a result of you asking me the question the other day
about the process that I simply answered that some of
them were completed retrospectively.
Q. That is one particular issue. There are other issues
which I imagine you knew very well you were going to be
asked about when you knew you were going to be giving
evidence, correct?
A. I'm not sure any of the other answers that I have got
here could have been foreseen that I would be asked the
question about.
MR JUSTICE FRASER: I'm not going to stop you, just so that
I can get a summary, all right?
Could either of you tell me where on the transcript
yesterday there was a summary about what the witness was
asked to do last night, because I have just quickly
looked for it and I can't --
MR DE GARR ROBINSON: My Lord, I don't believe there was
a discussion where we listed the specific points. It
was just along the way.
MR JUSTICE FRASER: All right.
Mr Coyne, I'm just going to try and save some of
Mr de Garr Robinson's time. Last night you were asked
to go off and do a particular series of exercises which
you would now, please -- don't give me the answers, but
just tell me what they were as far as you understood
them, and I did make it clear that you had a list.
A. Yes.
MR JUSTICE FRASER: Would you like to give me the things you
went off to do.
A. Yes, it was to report how many OCRs and OCPs were
completed retrospectively. It was to provide the
reference to a PEAK that has been edited where the
branch is less than 32.
MR JUSTICE FRASER: Yes.
A. It is to provide an answer to how many TIP repairs were
conducted.
MR JUSTICE FRASER: Yes.
A. And in how many PEAKs --
MR JUSTICE FRASER: Sorry, have you gone onto another item?
A. Sorry, my Lord, I have.
MR JUSTICE FRASER: So that is the third item I have
identified, answer how many TIP repairs. The fourth
one, please.
A. Fourth item, how many times do we see evidence of
messagestores being rebuilt.
MR JUSTICE FRASER: Right. Therefore at least number 2 on
that list should be a list of references.
A. Yes, my Lord.
MR DE GARR ROBINSON: I have to say, my Lord, my
apprehension was what he was being asked was a list of
references of things.
MR JUSTICE FRASER: I understand that entirely and that's
something that might have to be pursued in a moment, but
at least number 2 on that list should be a list of
references. Have you provided anyone with that list of
references yet?
A. No, but I do have that reference for that one.
MR JUSTICE FRASER: Right. Well at least on that item
Mr de Garr Robinson is entitled to a list of references.
How many are there against that item?
A. I have only extracted one, my Lord, so I only have one.
MR JUSTICE FRASER: Why don't you give us the reference.
A. It is {F/377.1/1}.
MR JUSTICE FRASER: So that is the only reference arising
out of your exercise of last night which has now been
given to Mr de Garr Robinson.
MR DE GARR ROBINSON: And that is a reference for what?
A. That is a reference to a PEAK where it shows an edit
taking place where the branch that it is modified to is
less than 32.
Q. I see. It is the only -- it is a PEAK showing an edit
of messagestore data taking place, full stop. That is
the only PEAK of which you are aware that shows an edit
of the message -- of transaction data in the
messagestore, correct?
A. The question that was asked was -- sorry, the position
that you put to me was that it is always 32 that is the
replacement, and I said that I had seen evidence that
that wasn't the case but I couldn't provide the
reference and that is one of the references of that.
Q. Well, Mr Coyne, as I recall, and it may be my fault and
I'm hesitant in case I might make a mistake, but my
recollection is you were asked for the references you
had showing an editing of transaction data or other
accounting data within the messagestore?
A. Yes.
Q. And would I be right in thinking you are only aware of
one and that's 377.1?
A. No, that's not correct. It is only where the branch
number is modified to be less than 32. The process that
was put to me is that whenever Fujitsu edits a message
they would replace the branch with the number 32, and
I said that that was incorrect and that I had
an example, and that is the example.
MR DE GARR ROBINSON: My Lord, what I'm getting is not what
I'm expecting and I don't believe it would be helpful
for Mr Coyne to read out from the notes he has plainly
obtained statements which actually aren't backed up by
any documents at all, so can't be ascertained or
substantiated in any way. So subject to your Lordship,
I'm going to leave the matter there.
MR JUSTICE FRASER: Well, what I don't want to do today is
I don't want to have a detailed who had said what
yesterday about what he was and wasn't asked to do
because that's just going to use up too much of your
time.
MR DE GARR ROBINSON: We certainly can't do that today.
MR JUSTICE FRASER: Whether we can or not, I'm not prepared
to entertain that today.
MR DE GARR ROBINSON: I'm grateful.
MR JUSTICE FRASER: But so far as any other documentary
references he has, I would like to have them, and I'm
just going to ask you: what other documentary references
do you have?
A. So, my Lord, with regard to --
MR JUSTICE FRASER: No, just tell me the references. What
are the references you have gone away and looked up?
A. Annex A of my second report.
MR JUSTICE FRASER: Okay, well that's -- yes.
A. Specifically it was in the section --
MR JUSTICE FRASER: No, that's fine. It's annex A, I know
where that is, I can go and look at it. Next one.
A. The other two, my Lord, are numbers, a calculation of
numbers, so I don't have the underlying documents.
MR JUSTICE FRASER: As in the number of times you have seen
things?
A. Yes.
MR JUSTICE FRASER: Right.
A. If it would assist I can run that report and get the
numbers out but I wouldn't be able to do that --
MR JUSTICE FRASER: I don't really understand what that
means but don't worry about that.
So Mr de Garr Robinson, are you saying that Mr Coyne
shouldn't tell me and/or you the number of times he has
seen these things based on what you asked him yesterday?
MR DE GARR ROBINSON: Where we are now, my Lord, I say he
should not.
MR JUSTICE FRASER: Right.
MR DE GARR ROBINSON: Because it would then set all sorts of
new hares running. Mr Coyne might have to be recalled.
We would be in a pretty pickle, in my submission.
MR JUSTICE FRASER: And are you objecting to me hearing what
the numbers are on a de bene esse basis?
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: You are.
Mr Green, what do you want to say?
MR GREEN: I don't want to take up time, but your Lordship
will appreciate I don't think that is a very sensible
way. He was asked to do homework. Some of the examples
are easily identifiable on the transcript of what he was
asked, like page 94 yesterday about 32 {Day16/94:1}, and
he has done what he was asked.
MR JUSTICE FRASER: Thank you.
Mr de Garr Robinson, on the basis you asked him, and
you now have explained your position on his answers, I'm
just going to hand the floor back to you, you can
continue your cross-examination.
MR DE GARR ROBINSON: I'm grateful, my Lord.
Now, Mr Coyne, yesterday you may recall that I said
I would check something overnight?
A. Yes.
Q. It relates to the enhancement that was suggested by
Ernst & Young during the 2012/2013 audit that the
monitoring control to validate the proper management of
programme changes in POLSAP and HNG-X be generated
directly from the system, do you recall that?
A. Yes.
Q. You said you thought it was suggested in the 2011
Ernst & Young management letter, and I asked you some
questions on the assumption that it wasn't, saying that
I would check and if that was an unfair assumption
I would come back and apologise. Well, there is
something about it in the 2011 letter so I'm coming back
and apologising to you, Mr Coyne. As a matter of
fairness I should tell you where it is.
If we could go to {F/869/25}, please. There is
a heading on the left-hand side, you see "Segregation of
duties within the manage change process". Do you see
that?
A. Yes.
Q. Then on the second from the right there is a series of
recommendations.
A. Yes.
Q. And they go on. If you go over the page to page
{F/869/26}, there's the second bullet:
"Implementing a change monitoring control for the
in-scope applications whereby system generated list of
changes made to production are independently reviewed by
POL on a periodic basis to determine that changes have
been authorised authorised, tested and approved prior to
migration. This will help POL gain assurance that
changes implemented by third party service providers
have been approved by POL management."
Do you see that?
A. I do.
Q. If we go back to page {F/869/25} we will see "Management
Comment" on the far right-hand side:
"A Fujitsu project has been established to review
all user management areas and is being led by the CISO
of the RMG account."
Do you see that?
A. Yes.
Q. If one then goes over two pages, so this section goes on
for more than one page, {F/869/27}, the last comment in
the "Management Comment" box is that:
"POL is to ensure through a periodic sample and
exception review that changes have been authorised,
tested and approved prior to deployment."
Do you see that?
A. Yes.
Q. This is an example where an auditor suggests one thing
and the client comes back and indicates: I'm not sure
I'm going to do that but I will do this other thing
instead, which I believe you accepted but let me suggest
it again in case I misunderstood, that that sort of
thing happens all the time in these kind of situations,
yes?
A. Yes, it does. There are a number of other things on
other pages which it is suggested should be done by way
of recommendations. But no, I do accept your position.
Q. The recommendation was made and it is only right that
I should correct the position with you and give you the
opportunity to comment. And as I say, I am sorry
I overlooked this yesterday. It is a long document and
I missed that bullet point.
Just to put it in proper context to give you
a proper opportunity to comment, if we could look now at
your second report, please. That is at {D2/4.1/195}.
At paragraph 5.264 you said:
"Regarding the specific recommendations in the 2011
audit it is my opinion that the key recommendations
directly impact on some of the 18 countermeasures
outlined in Dr Worden's report and therefore are
relevant to the question of robustness of Horizon since
they offer an opportunity to improve these
countermeasures which it appears Post Office chose not
to take."
So you are saying there, aren't you, that the four
key recommendations made by Ernst & Young offered
Post Office an opportunity to improve countermeasures
which it did not take, yes?
A. Yes.
Q. The way I read what you are saying is that Post Office
chose not to take any actions to improve in response to
the four key recommendations. Would that be a fair
reading of what you said?
A. Yes.
Q. Now, would you suggest that that claim is justified
because amongst the proposals made there was a proposal
for a system-generated change monitoring process, and
Post Office responded by indicating that it would
enhance its monitoring in a different way?
A. Well, it is saying it wouldn't accept the auditor's
recommendation but would follow an alternative path.
Q. Do you say that justifies the claim that Post Office
chose not to take actions to improve in response to the
four key recommendations made by Ernst & Young? Because
I would suggest to you it doesn't justify that claim,
Mr Coyne, and that the claim is exaggerated.
A. I mean for clarity here, it is correct that I do make
reference to the key recommendations --
Q. It is all you are talking about, isn't it --
A. -- of which there are four, but actually that particular
audit does address a number of other elements. But it
is correct that my report does only reference the four.
Q. Let's move on. Let's talk about the bugs that you have
identified in the bug table in joint statement 2. We
will be referring to this a lot. It is at {D1/2/3}. It
starts at page 3.
Now, as I understand it, your analysis of all the
available evidence has culminated in a table which is
entitled, and we see it here:
"Table of Bugs/Errors/Defects with acknowledged or
disagreed evidence of financial impact."
Would that be a correct summation of what this table
is?
A. Yes. It can't be read completely in isolation of the
report, but it is an attempt to bring together most of
the references from the report into one single table.
Q. Would you accept that it brings together all the
references that you consider important and significant?
A. It may not do. There may be references that still
remain in the report that haven't been distilled into
this joint statement.
Q. Let me ask a slightly different question. This is the
definitive list, isn't it? You are not suggesting that
there are other bugs with evidence of financial
impact -- you are not relying on any other bugs with
evidence of financial impact, it is just the 29 bugs
identified here?
A. These are the ones that I have identified, yes.
Q. Thank you. Obviously in the time available I can't go
through all the bugs and I can't even go through all the
PEAKs and KELs referred to for some of the bugs, but
I can touch on a limited number. That simple fact, that
I can only touch on a limited number, does underline the
importance, doesn't it, of an expert in your position
summarising documents you are relying on accurately and
explaining their significance fairly? I am sure you
would agree.
A. Yes.
Q. Let's first of all talk about some issues that you say
are bugs. Could we go, first of all, please, to bug 15
which is at page {D1/2/13} of the table. Table 13, bug
15, "Phantom Transactions". You will see very helpfully
on the right-hand side of the table there are two F
numbers, there are two documents referred to which are
references for two PEAKs you are relying on for this
proposition, yes?
A. Yes.
Q. Let's look, first of all, at the PEAK which is {F/48/1}
which is PC0052025. Before going to that, while we have
still got the screen, it is worth mentioning that in the
"Identified Year/Year(s) in Effect" column, those two
bugs are referred to, one of them is August 2000 and the
other is April 2001, is that correct?
A. Yes.
Q. So would I be right in thinking that whatever problems
there were in 2000 and 2001 regarding phantom
transactions, the PEAKs indicate that such transactions
have not raised their ugly head for the last 18 years?
A. Yes.
Q. So we are just talking about the early period of
Legacy Horizon, is that right?
A. With regard to this particular --
Q. Yes. Let's look at {F/48/1}, please.
There may be a problem with the system.
MR JUSTICE FRASER: It takes such a long time because there
are so many documents in the folder, I'm afraid. Where
would you like to go? F?
MR DE GARR ROBINSON: F/48. Perhaps one way of doing it is
if you stay on the bug table itself you can click on the
hyperlink, which is probably what I should have
suggested first of all. Thank you.
Right, let's pick it up first of all at the top of
the page, page 1. It happened on 14th August 2000.
Well, actually --
MR JUSTICE FRASER: I think it is the 9th.
MR DE GARR ROBINSON: I'm so sorry, four lines down,
9 August 2000, 9.22. Do you see that, about four lines
down from the top?
A. Yes.
Q. "PM informs that receipt came out of machine at 2:14pm
and it had 3 transactions on it. Was advised that
transactions are cut off automatically if they are not
finished. P&A, BT payment card £5 and British gas bill
payment is also showing for £5, and there is another chq
for £43."
Then there is an entry for later I think in the same
day:
"System has printed ghost transactions before, but
not this severe."
So we see from the size of the amounts involved in
this call that at least some subpostmasters are
perfectly happy to call in when they have got
difficulties with relatively small amounts of money,
would you agree with that?
A. Yes.
Q. And would it be fair to say you have seen a substantial
number of PEAKs where SPMs have phoned in with problems
about relatively small sums of money?
A. Yes.
Q. Thank you. These are described as ghost transactions,
and presumably that's why you have included this as one
half of the evidence you rely on in support of the
suggestion that Horizon had phantom transactions during
this period, yes?
A. Yes.
Q. If we go to page {F/48/2} to 14.12, so that is three
boxes down. It is David Seddon from the SSC and he
writes:
"Messages in the messagestore confirm that the
'phantom' transactions were due to them being in a
suspended session that was later forcefully committed
explained this to PM who was happy with explanation but
she says she is sure she never pressed the suspend icon.
Nevertheless she agrees closure for this problem. Can
only assume that she hit the suspend icon by accident."
Do you see that?
A. Yes.
Q. First of all, these were transactions that were actually
typed into the system. They didn't appear out of
nowhere, would you agree with that?
A. Yes.
Q. What happened, though, was that having been typed in,
they weren't committed to the -- the basket wasn't
committed to the messagestore. Instead the screen was
left for a period of time and after a certain lapse of
time the system forcefully committed them to the
messagestore, yes?
A. Without any user interaction.
Q. Well, that's what you say, Mr Coyne, but isn't a fair
reading of what's in that box that the postmaster
accidentally must have touched "suspend" with her hand
or something with the result that the session was
suspended for that period of time?
A. Yes, that's possible, but it isn't that that was the
reference that I was making to without user interaction.
It is the later event, the automatic commit that would
appear to have been done automatically without a user
being involved.
Q. I see. So what you are suggesting is that if the system
automatically commits an uncommitted basket after
a period of time that's evidence of phantom
transactions, that's evidence of a bug in Horizon that
needs to be corrected, is that what you are suggesting?
A. Well, it is evidence of the system doing something
without the user choosing to do it.
Q. Are you suggesting it is something -- it is evidence of
the system doing something wrong? I think you are,
aren't you?
A. Yes.
Q. Let's look at Mrs Van Den Bogard's witness statement, it
is at {E2/5/1}. To save time, I would ask you simply to
read paragraph 14.2 of her witness statement, please.
I'm so sorry, my note says page 54. Is it page 5? No,
it is paragraph 14.2 which is page 4. {E2/5/4}.
Could you read that paragraph, please,
paragraph 14.2. (Pause)
A. Yes.
Q. So this isn't evidence of Horizon going wrong, is it?
It is evidence of Horizon doing what it has been
designed to do. Yes?
A. It would appear from what's been said here that that was
the design, but I can completely understand the user's
concern. They hadn't committed the transaction and they
might not have wanted to commit the transaction --
Q. It is a standard security measure in many IT systems,
measures of this kind, isn't it?
A. Yes, it is. It suspension of the user session is
certainly standard. A roll back of any work in progress
would be a standard. I have not seen one in a retail
environment or a banking environment where it will
actually complete a transaction that the user didn't
choose to complete just because they weren't at their
screen.
Q. And the receipt -- the system prints a receipt so that
the postmaster knows what has happened and if there is
a problem the postmaster can then reverse the
transaction, correct?
A. Yes.
Q. That's what the system is designed to do. The system
has to decide whether just to delete the entire session
from the system or to commit it. Either way a design
choice has to be made, and either way what's important
is that the subpostmaster knows what happens, and this
system is designed to give the postmaster that
information by printing out a receipt, correct?
A. Yes.
Q. Right. And you knew that, didn't you, when you included
this PEAK as a phantom transaction bug in your second
report?
A. No, I don't believe I did. No.
Q. Well, let's have a quick look at that just to see. It
is at {D2/4.1/114}. Do you have the page? Under the
heading "Angela Margaret Van Den Bogard" it says, 4.69:
"Mrs Van Den Bogard has provided a witness statement
commenting on individual cases and various disparate
factual matters, which I do not attempt to comment on in
detail here. I note the following discrete points."
Then under the heading "Phantom Transactions", you
say {D2/4.1/115}:
"I have seen evidence of phantom sales recorded in
the disclosed documents. PEAKs PC0065021 216 and
PC0052025 ..."
Which is the one we are just looking at?
A. Yes.
Q. "... (documented in further detail at section 3,
'Phantom Transactions (Horizon Issue 4)' above) refer to
phantom transactions in branches, the former which was
observed by an engineer on site at the branch and the
latter which refers to discrepancy arising from them."
A. Yes.
Q. So you did know what Mrs Van Den Bogard was saying
because you identified this very PEAK when you were
responding to that very evidence?
A. Yes.
Q. It is completely wrong, isn't it, Mr Coyne?
A. My understanding is now that it would appear that it is
a design feature, that that happens.
Q. If you don't mind my saying so, Mr Coyne, you appear to
be rather evasive. What I have just shown you is that
Mrs Van Den Bogard set out quite clearly in a witness
statement how the system was designed to operate, and it
was designed to operate in a way that committed
transactions that were left on the machine for a certain
amount of time and a receipt was printed so the
postmaster knew what had happened?
A. Yes.
Q. And you responded to that by saying, well, I have got
some evidence of phantom transactions and half of the
evidence, one of the two PEAKs you rely on for that
purpose, is a PEAK which actually demonstrates the truth
of what Mrs Van Den Bogard is actually saying, doesn't
it?
A. Certainly one of the two examples it would appear that
it is operating in line with the design, but I can
certainly understand how a user would perceive that that
would be a phantom transaction because they didn't
complete it --
Q. Mr Coyne, if we were looking at a table which was a
table of areas where users might get confused, then we
wouldn't be having this conversation.
A. Mm.
Q. We are having this conversation because you have added
this piece of evidence as evidence in support of the
proposition, firstly, that there are bugs in Horizon
and, secondly, that they cause losses, lasting losses to
postmasters. That is right, isn't it?
A. Yes.
Q. And you agree now, do you, that this PEAK is not
evidence either of a bug or of the causing of a lasting
loss to a postmaster?
A. I do agree.
Q. Thank you. So I then come to my final question which is
how is it you came to include this PEAK both in your
report and even in the bug table here on page 13? Did
you not read the PEAK properly?
A. Yes, I did read the PEAK properly, possibly not in full
consideration of the witness statement of Ms Van Den
Bogard.
Q. But you cited the PEAK in response to her witness
statement.
A. I did.
Q. So you must surely have had it in mind when you were
choosing those two PEAKs to refer to. Would I be right
in thinking -- would an outsider be right in thinking
that you were anxious to find evidence in support of the
hypothesis that Horizon generates phantom transactions
and you saw a very helpful reference at the top of the
first page and you thought, I'll have that, let's put it
in. And you then included it in your second witness
statement and you have included it in your bug table.
Would it be reasonable for an outsider to form that
impression?
A. I would certainly have taken it from my report and put
it into the joint statement table, yes, that would be
the case.
Q. Did you not check the PEAKs -- before you lifted the
PEAKs from your report and put them in the bug table did
you not check them, review them, to make sure that they
really were good evidence of the propositions for which
you were citing them?
A. The process that I followed with Dr Worden is we went
through our respective reports, put the text in where it
was a shared text or separate text, and then in order to
assist the court we put as many relevant references as
possible from our reports into this table. That was the
purpose of that. And it would appear that rather than
validating each of the references in the report before
putting them in the table I have lifted the references
out of the report and put them in the table.
Q. So you didn't check them?
A. I haven't checked each and every reference -- I checked
the references in the report, before they went in the
report, but I haven't re-checked and opened all the
documents before we put the references in this
"Supporting Evidence" column. This is a shared column,
the "Supporting Evidence" column at the end. You will
see that Dr Worden has put some references in there and
I have put references in there.
Q. Yes, but you are not suggesting that Dr Worden has
suggested the inclusion of F197, are you?
A. No.
Q. Thank you. Let's go to the other PEAK you rely on.
In the bug table at {D1/2/13}, you say:
"Whilst no specific branch account discrepancies are
noted, many events recorded in the PEAK PC0065021
suggesting multiple 'Phantom Transactions' at branch
during the period of 14th April 2001 to 12th November
2001. It is therefore possible (with the unpredictable
nature of Phantom Transactions) that branch accounts
could have been impacted.
"Observations recorded on 19th June 2001 by
Fujitsu's Patrick Carroll, 'I now have pressing evidence
to suggest that unwanted peripheral input is occurring,
the likely source being the screen… I have observed
system activity corresponding to screen presses
happening with no corresponding [sic] evidence of either
routine system activity or human interference."
So that's what you say about that PEAK in the bug
table?
A. Yes.
Q. Let's have a look at the PEAK. It is at {F/97/1}.
Before I ask you a question about that, I'm reminded,
Mr Coyne, that you already knew that Horizon false
commits transactions which are in a counter for
a substantial period of time. You say that in
paragraph 3.151 of your second report, do you remember
doing that?
A. I would have to go back and refresh myself.
Q. It is at {D2/4.1/56}.
MR JUSTICE FRASER: I think the passage that you have just
been asked about is at the top of {D2/4.1/57}. So 56
and 57.
You say at the top of page 57:
"It appears that Horizon will, after periods of
inactivity ultimately commit transactions a
Subpostmaster has not fully completed themselves."
Actually you say that in relation to, if you look at
3.150, the very PEAK we have been looking at
{D2/4.1/56}. So that makes your inclusion of this PEAK,
as an example of a bug causing a subpostmaster losses,
that makes it even more curious. You did write both
section 3 and section 4 of the report, I am sure?
A. I did, yes.
Q. I would not even suggest to you otherwise, Mr Coyne. So
how is it that you came to such inconsistent results in
two different parts of the same report? Can you
explain?
A. Yes. It is a mistake to include that as a reference as
an example for that phantom transaction.
Q. So let's go back to {F/97/1} and if we pick it up on
page {F/97/4}. It is a very long PEAK. It is a big
yellow box on page 4 and about perhaps a little less
than a third of the way down there is a date 30/4/01,
14.12. Do you see that?
A. Yes, I do.
Q. We have got:
"Information: Romec attended site 23/4/01 carried
out inspection and testing and report no fault found
with the Horizon circuit."
Just for the record, who is Romec?
A. I believe Romec are hardware engineers, or communication
engineers.
MR JUSTICE FRASER: Mr de Garr Robinson, I'm sorry,
I haven't found that part.
MR DE GARR ROBINSON: It is 18 lines down.
MR JUSTICE FRASER: Ah, yes. It is just that there are two
entries at 30/04/01 and the other one is a bit further
down, out of chronological order.
MR DE GARR ROBINSON: It is at 14.12. And if you go down to
just after the bottom third of the same page, there is
01/05/01 at 10.56, do you see that?
A. Yes.
Q. It says:
"Information: Romec are contacting the site to let
them know that they will be attending site 2/5 to fit
suppressors and double sheet flyleads, in order to help
the enviromental fault."
A. Yes.
Q. I am sure you will recall that all sorts of
environmental tests were done at this particular site to
see if the environment was responsible, yes?
A. Yes, and certainly the fitting of suppressors and
sheeted flyleads would suggest that that's what they
suspected.
Q. It is fair to say from reading the PEAK as a whole -- we
don't have time to go through it all -- that the
investigations that Fujitsu carried out were very
thorough, weren't they?
A. Yes. I think they ultimately determined they could not
decide what the fault was but the process seemed to be
a reasonable process to go through.
Q. And they sent engineers from Romec. Do you know what
Romec's familiarity with the system is?
A. I would suspect that they know the hardware and the
communication equipment very well. I don't know if they
will know how Horizon as a software product would work.
Q. That is a very fair answer. You saw where I was going
and that is a very fair answer, Mr Coyne. They might
very well know how to set the system up, make sure
everything is connected and see that everything is
logged on properly, but when it comes to the internal
workings of the system itself they may well not be
familiar, yes?
A. Yes.
Q. Thank you. Anyway, they were sent to inspect and test
the circuit and improve the cabling. We have already
gone to the reference I was taking you to.
If we go to page {F/97/5}, which is 2/5/01, at
14.12. "Information". That's about a third of the way
down, my Lord. Does your Lordship see it?
MR JUSTICE FRASER: Yes.
MR DE GARR ROBINSON: 02/05/01, 14.12.
MR JUSTICE FRASER: With "UK052436" next to it?
MR DE GARR ROBINSON: Yes.
"Information: Romec have been to site today and
fitted shielded cabling and suppressors. Romec engineer
advises that he has witnessed further phantom
transactions whilst on site. He will carry out further
tests and advise results."
So there is the Romec engineer seeing phantom
transactions?
A. Yes.
Q. That's the visit that's referred to in the quote that
I have read out from the joint statement, isn't it?
A. Yes.
Q. So the engineer comes in, he logs the system off, he
fits the suppressors and whatever else he needs to do,
then logs on again. And while he was there he saw what
are described as phantom transactions, yes?
A. Yes.
Q. They could equally be described, I suppose, as ghost
transactions, couldn't they?
A. They could be, yes.
Q. The reason why I ask that question is because we have no
idea what he saw and we have no idea whether he
misinterpreted something, do we?
A. We don't, but it would be reasonable to assume that
an engineer whose particular role it is to service
Horizon equipment, whilst he wouldn't know how to
operate Horizon in detail, would have a reasonable
understanding of how it would work.
Q. Maybe, Mr Coyne, another counter hadn't been used for 59
minutes, it had uncompleted transactions on it, and it
automatically completed them and printed a receipt.
That is possible, isn't it?
A. That is possible.
Q. And it is possible that an engineer with his familiarity
of the hardware would not know that feature of the
operating system of Horizon, so he might be surprised by
that, correct?
A. He might be surprised by that. But I think we have got
to read this in context, that the subpostmaster had
already explained that they perceived that there were
problems with what they said was phantom transactions.
So Post Office and/or Fujitsu would have gone through,
I would presume, their support process, would have
looked at various logs and things like that before
dispatching a hardware engineer to site. So if they
suspected that it was just the simple case of a counter
coming to the end of its 59 minutes of suspension and
doing something automatically, I think they would have
dealt with that before dispatching an engineer.
Q. We can agree, Mr Coyne, that the SSC had experience of
these things and they had access to information that we
don't have. We can agree on that. But just focusing on
the Romec engineer visit, would you not accept that it
is quite possible that the engineer saw something which
was an example of Horizon operating as it should and was
not in fact a phantom transaction at all, and he
misinterpreted it because he didn't have the familiarity
with the system that someone at Fujitsu might have?
Would you accept that that was at least possible?
A. I accept that it was possible if you look at that visit
in isolation, yes.
Q. And then what we know is that there are further
investigations for some months and Mr Carroll is
involved from at least 4th May, I think. You see his
reference. If you go down to the bottom of page 5, you
see 04/05/01 at 9.30?
A. Yes.
Q. "information Ki Barnes has called in. I am unsure as to
what to do with this call now. Romec have been to site
and state that they have actually seen the phantom
transactions, so it is not just the PM's word now. They
have fitted suppressors to the kit but the PM is still
having problems. As yet there has been no recurrence to
the phantom transactions but there still may be
problems. Contacted Pat Carroll for guidance."
So it is fair to infer, isn't it, that Pat Carroll
was someone very experienced and more senior in the
organisation?
A. Certainly his name appears on a number of documents that
I have seen.
Q. And it is fair to assume, isn't it, that he is in a good
place, with the information and the experience that he
has, to form a judgment as to what the likely cause of
these problems are, yes?
A. Yes.
Q. Well, the matter goes on for some months and there are
further investigations. If I could pick it up in
November now at page {F/97/9}. If we go to the bottom
of the page, 12/11/01, at 9.48. This is Patrick Carroll
himself:
"Phantom Txns have not been proven in circumstances
which preclude user error in all cases where these have
occurred a user error related cause can be attributed to
the phenomenon."
{F/97/10}:
"I am therefore closing this call as no fault in
product."
Now, given Mr Carroll's experience and the
information he has available to him, and given that as
you have yourself fairly acknowledged this phantom
transaction problem hasn't re-appeared since
November 2001 in any PEAK, would it be fair to suggest
that the best judgment to trust in relation to what was
going on here is Mr Carroll's judgment?
A. Certainly Mr Carroll would have access to all the
information that should allow him to determine the
position. One thing that I do note from that, there is
no reference to looking at the audit logs or the ARQ
data which may well have confirmed what was going on
while the Romec engineer was on site and would almost
certainly document whether the recovery from
a suspension, as we talked about before, actually
happened at that time, and I don't believe that this
document reflects that that investigation was conducted.
Q. Nonetheless, Mr Carroll formed the judgment that he did.
Do you think that adopting a balanced approach when
explaining this PEAK in your expert report at some
length, for example, it would have been helpful to have
included his conclusion at the end of the PEAK as well
as including the earlier passage that you quote in the
joint statement?
A. I don't believe that would be required. The reference
to the PEAK is there. There's lots of detail in that
PEAK that --
Q. But haven't we already agreed several times, Mr Coyne,
that given that so many documents, I mean a mass of
documents -- if you try to weigh all the documents you
refer to in your two reports it would probably come to
something close to my own body weight, and that's saying
something -- it is simply not humanly possible to read
all the documents you refer to in your report or at
least not in a limited amount of time, and in those
circumstances wouldn't it be helpful, given that we are
all relying on your report for a fair summation of the
document, wouldn't it be helpful and fair to have
included the passage at the end of the PEAK which is
less helpful to your analysis as well as the passage in
the middle of the PEAK which is, you consider, helpful
to your analysis. Do you not think that would have been
an appropriate and fair thing to do?
A. I don't. I accept that it would be an enhancement to
the report but I would not know where to stop if we keep
including all aspects of all documents that are
referenced.
Q. I have got one suggestion for you, Mr Coyne. Why not
try and avoid stopping when you have mentioned the bad
points? Why not try and carry on so that you can
mention some points for balance as well? Do you not
think that would be a good idea?
A. Yes.
Q. Because in your report wouldn't it be fair to say that
that tends to be what you have done? In many cases, you
have mentioned the bad things arising from the document
or what you perceive to be a bad thing, a critical thing
in Horizon arising from a document, but you don't
trouble yourself to mention any of the other points that
may be mitigating or maybe positive?
A. No, I don't think that's fair at all. I think you have
been able to point me to this example but I do not think
that's fair at all.
Q. And one other final question. Do you think you are in
a position now, in 2019, looking at this PEAK nearly
18 years ago, to say that Mr Carroll, with the
familiarity he had with the system and with the
information that he had at his fingertips, he must have
been wrong in his attribution of the cause for the
difficulties experienced at this branch?
A. I think with the ARQ data you would be able to determine
what the position was.
Q. That wasn't my question, though, was it? My question
was do you think you now, with the information you have,
are in a position to say that Mr Carroll was wrong?
A. No.
Q. Thank you. I suggest to you none of us are in that
position. It is impossible at this remove in time and
on the information available to us to come to any view
as to whether this was a phantom transaction or not,
would you agree with that?
A. What I can say is that on balance, because it has been
reported by a subpostmaster, and then somebody with
technical knowledge says that they have observed it as
well and that there hasn't been a full examination done
by Pat Carroll of the data, then I believe that it could
well be the case that it is a phantom transaction. But
I do accept the position that we don't know today.
Q. Let's talk about a different bug. Bug 11, Girobank. If
we could go back to the bug table at {D1/2/9}.
There are just too many documents for me to go
through, it would take hours. Perhaps first of all you
could explain what Girobank transactions are, just to
set it up.
A. I'm just going to go back to my report.
Q. You don't remember. It is impossible to know everything
about this system at every single time. By all means go
back to your report, Mr Coyne.
A. Yes, it is about the timing of the various aspects of
the process of a Girobank transaction.
Q. And a Girobank transaction is?
A. It is similar to a retail banking function.
Q. Okay. Would it be fair to say that you are not really
familiar with what Girobank transactions are?
A. I'm just trying to recall the details of it now.
Q. Anyway looking at the bug table, if we look at column 3,
"Identified Year/Year(s) in Effect", the period
identified is May to September 2000?
A. Yes.
Q. So again very early days in Legacy Horizon?
A. Yes.
Q. Would it be fair to say that whatever problems there
were in 2000, they hadn't manifested themselves in any
PEAKs or KELs since then? Would that be fair?
A. That is right, yes. Sorry, there is one over the page
which is dated 2001 {D1/2/10}.
Q. Yes, you are quite right. So it is 2000 and 2001. Now,
there is a KEL in the right-hand column, A Chambers, on
page 10, 4410R?
A. Yes.
Q. Which is the reference to -- we are not going to it --
actually I don't have it, the reference isn't written
down here. Anyway, I won't go to it.
MR JUSTICE FRASER: Sorry, I can't see where that is, I'm
afraid.
MR DE GARR ROBINSON: My Lord, if one goes to page 10, under
the "Supporting Evidence" column on the right-hand side,
just above "Coyne Supplemental Report", there are two
KELs, M Wright --
MR JUSTICE FRASER: Yes, I have got it.
MR DE GARR ROBINSON: -- and A Chambers 4410R.
You talk about that KEL in your report. And if we
could look at your report, please, it is {D2/4.1/50}.
3.126:
"The KEL related to this PEAK you are talking about
is documented as 'AChambers4410R', this KEL does not
appear to have been disclosed ..."
That's why it doesn't have an F number.
"... therefore it has not been possible to ascertain
what advice might have been given ..."
A. Yes.
Q. If you go up in the earlier table at the top of the page
you will see that there is a reference to a PEAK.
A. There's reference to a number of PEAKs.
Q. Sorry, if you look at 3.127 below, I'm a bit confused:
"Further associated PEAKs that reference [that KEL]
are provided in the table below."
I would like to ask you about those. It is the PEAK
on page 51. It is PC0076065 at {F/118/1}. If we could
look at that please. I should, for completeness,
actually read out what you say immediately below that
table. This is in 3.128, we don't need to go back to it
on the transcript -- on the machine:
"The above PEAKs related to Girobank discrepancies
are clear examples of bugs within Horizon that affect
branch accounts by way of a financial discrepancy and
illustrate, by their interlinking natures, the
complexities of the PEAKs/KELs."
So what you are saying there is that the PEAKs
referred to in that table are clear examples of bugs in
Horizon that affect -- that create financial
discrepancies in branch accounts, correct?
A. Yes, I'm referring to the PEAKs within this section, not
just that particular table. If you read up, there is
a table there and there is a table before it.
Q. What I'm seeking to elicit from you, Mr Coyne, and
I think you have confirmed it, is that it is your
contention, your judgment, your expert opinion that
{F/118/1} is a clear example of a bug which has caused
a financial discrepancy in a branch account?
A. The text in my report is:
"Giro deposit cut off ... Branch unknown."
So a number of other ones in the table actually list
the discrepancy. That one doesn't list the discrepancy
next to it.
Q. Let's look specifically at what you say in
paragraph 3.128 then. It is {D2/4.1/51}.
Paragraph 3.128 says:
"The above PEAKs related to Girobank discrepancies
are clear examples of bugs within Horizon that affect
branch accounts ..."
"The above PEAKs", they include all of those PEAKs
in that table, don't they?
A. Yes. If you go back a page you will see --
Q. Mr Coyne, I just want to ask you about F/118 and what
I'm suggesting to you is in your report -- and I didn't
think this would be controversial -- you are claiming
that, amongst others, F/118 is a clear example of a bug
in Horizon causing branch discrepancies. That is what
you say in your report, isn't it?
A. That is one of the PEAKs that's included in the tables
on the preceding pages, yes. The text for that one that
has been provided doesn't necessarily indicate that for
that one there is a discrepancy. Some of the other
items in the table I do clearly say that there is
a discrepancy.
Q. So I had read paragraph 3.128 as making a claim that all
the PEAKs you refer to in this section above, not only
in the table but in the earlier table as well, were
PEAKs that clearly created discrepancies in branch
accounts. Are you now saying that that PEAK didn't?
A. If you read paragraph 3.127 {D2/4.1/50}, what that is
saying there is at the top of the page there is a table
with all the discrepancies that are listed next to the
particular branches. What 3.127 says is that the PEAKs
above reference a KEL called Anne Chambers, so that is
the link, and by searching for "Anne Chambers" you find
the PEAKs below.
Q. Yes.
A. So they are a different set of PEAKs that reference
Anne Chambers, but it is the --
Q. Mr Coyne --
A. Sorry, it is the table at the top of page {D2/4.1/44},
at the head of it, which are the PEAKs with the
discrepancies in.
Q. So when you say "The above PEAKs", you are not actually
referring to the table below 3.127, you are just
referring to the table below table 3.123, are you?
A. Yes, and that is introduced at 3.127.
Q. Mr Coyne, this is amazing. You are clearly -- when you
say in paragraph 3.128 -- I can't believe I'm having
this discussion. When you say in 3.128 {D2/4.1/51}:
"The above PEAKs related to Girobank discrepancies
are clear examples of bugs within Horizon that affect
branch accounts ..."
The bugs in the table below 3.127 include bugs
relating to Girobank?
A. Yes, but you have to read the paragraph before that
table to understand what that table is. It clearly says
{D2/4.1/50} --
Q. All right. All right.
A. "Further associated PEAKs ... are provided in the table
below."
They are PEAKs that are associated by way of KEL to
those Girobank transactions.
Q. I see.
A. The PEAKs that mention the discrepancies are clearly set
out in the other table --
Q. I see, so --
A. -- which essentially is above, it is just over the page.
Q. So you accept then that {F/118/1} isn't a bug which
creates discrepancies in branch accounts?
A. No, it is linked by way of KEL; the Anne Chambers --
Q. Why do you mention it in your report then? What is its
relevance to the subject that you are considering, which
is bugs creating discrepancies in branch accounts?
A. Because the bugs that create the discrepancies in branch
accounts, many of them reference the KEL Anne Chambers.
So they cite that as being the cause of the problem. So
what I have then done is I have searched for other PEAKs
which also reference Anne Chambers and I found these
others in that table, so I'm providing them.
Q. Even though they don't -- they are not bugs that
actually create discrepancies in branch accounts?
A. Yes, but I don't actually say that they do. It is quite
clear what I'm saying in 3.127, and a few moments ago
you were critical for me leaving out things, so here is
an example where I haven't left something out, I have
put it in for context.
Q. We can save some time then. You accept that {F/118/1},
or the PEAK that is referred to there, isn't a bug at
all, don't you?
A. I have described it here as a cut-off issue, branch
unknown. So it likely isn't a --
Q. Do you remember the PEAK? It is to do with -- could you
remind the court what cut-off means?
A. It is the end of a time period, so it is after a certain
point in the evening.
Q. Yes. And what's the significance of that point in the
evening?
A. That the submission has to be conducted before that.
Anything that's conducted after that I think is shown as
being the following day.
Q. Submission to whom?
A. Girobank.
Q. So there is a time in the evening when a report is sent
to Girobank of all the Girobank transactions in one day?
A. Yes.
Q. And that report will contain all the Girobank
transactions that have been undertaken up to that point
in time?
A. Yes.
Q. We can save some time, we can go to the PEAK if you
want, but this PEAK was a PEAK where the postmaster had
done a report which -- in fact he did two reports. He
did one report, and then he did another Girobank
transaction, then he did another report. And when he
looked at the first report he saw that the later
Girobank transaction that he had done wasn't included
and he was confused so he phoned the helpline and the
helpline put him through to the SSC. Because the
helpline, when they reach a point where they don't think
they can help someone, that's what they do, isn't it?
A. Yes.
Q. They will just pass it straight through. They don't
form some Olympian judgment as to whether it is
a software error or not, they work out whether they can
help the caller and, if they can't, they then just pass
it on up the chain. Would you agree with that?
A. I would indeed.
Q. So they passed it on up the chain to the SSC and the SSC
looked, I believe it was Mr Roll, actually. Yes, it was
Richard Roll. And they saw that the postmaster had been
looking at the wrong report, and as a result of looking
at the prior report he had confused himself. So it was
closed as a category 62, no fault in product. That
wasn't a bug at all, was it?
A. No. And as I fairly say here, it is a cut-off issue,
branch unknown. But contained within that PEAK, that
call, someone has put the reference to Anne Chambers
4410R because they considered it would be another
occurrence of the Girobank defect which caused the
discrepancy, so that is why I have referenced it in this
report. But it is in a different table and made very
clear that it is just another PEAK that references that
Anne Chambers, it's not the --
Q. Forgive me, Mr Coyne, but speaking as someone who has
read your report over a number of deathless hours, and
the same could be said about all the reports in this
case, it has to be said, the strong impression that
a reader might get from this report is that these
paragraphs are a catalogue of problems arising in
Horizon and the table that you include underneath 3.127
adds to the impression of a catalogue of problems
arising in Horizon. Would you accept with me, on the
basis of the account I have given of {F/118/1}, and
I appreciate I haven't taken you to it, but would you
accept it from me that F/118 is not any kind of problem,
and to the extent that your report gives that impression
it gives a false impression?
A. Yes, I accept that that is not a record of a defect, but
I believe you were mistaken when you read my report
because this section is quite clearly introduced at
3.127 to say:
"Further associated PEAKs ..."
Are associated with this KEL. And in the right-hand
box of the observations, none of them do they say
"discrepancy", but on the table above, where I have
managed to work out a discrepancy, I have put it in the
box.
Q. Let's go back to the bug table at page 9 where you talk
about Girobank discrepancies {D1/2/9} and let's pick up
the first one you mention in the right-hand column,
which is PC0044232, and that's at {F/25/1}. Let's go to
it.
At the bottom of page 1 -- let's pick it up at the
top. 5 May 2000. It is reported on 4 May:
"System error. Girobank said there was
a discrepancy on the Giro figures."
So it looks as if this was called in by Girobank
itself, yes?
A. Yes.
Q. Go down three lines:
"Girobank have been in touch to say that there is
software problem as the figures are not correct. Daily
figures when totalled are more than the cash account
giro figures."
A. Yes.
Q. Then an example is given:
"These are for the Giro payments only.
"The PM has checked all dockets and all reversals
that may have been done and cannot find anything
therefore he would like this investigated ..."
Do you see that?
A. Yes.
Q. Let's go down to the bottom of the page at 5 May at
15.02. Mark Wright says:
"This difference (£505.72) between the Cash Account
and the Daily reports is explained by
KEL:MWright531P.htm. There was a giro for this amount
that was entered on the 13th Apr then reversed AFTER
cutoff then re-entered again and reversed again."
Which is a very strange series of events.
"The daily report would have shown the original
£505.72 but the daily reports never show reversals."
Do you see that?
A. Yes.
Q. That explains why Girobank phoned in. That is not
a fault with the system, is it, that is how it is
designed to operate, would you accept that?
A. I'm not sure, because it does say below that:
"It would be nice to close the call as known error,
however while investigate the messagestore I have
identified another problem ..."
This does appear to indicate that there is a system
problem.
Q. Okay. Let's go on with it:
"It would be nice to close the call as known error,
however while investigate the messagestore I have
identified another problem ... there is a Giro Deposit
for £81 (1-17240) that is being calculated in TWO
consecutive cutoffs (18th AND 19th April). I have
attached the full message store as evidence, however the
error happens in message 3-8932 where the tidemark SEQ
number (117240) which in this case relates to counter 1
is GREATER than the Mark calculated for counter 1 in the
same message."
I don't pretend to understand that but you can see
he has seen a symptom.
{F/25/2}:
"It would appear that the report calculation uses
this SEQ number along with the PreviousMark numbers to
generate the total. As this number was larger than the
current mark, it would also be included in the following
days report."
So that is what he explains as happening.
Now, can we agree that the problem here was a fault
in the report that went through to Girobank?
A. Well, it was a problem that occurred in Horizon that
resulted in information being sent to Girobank that was
incorrect. We can certainly agree on that.
Q. Can we agree that the fault was in the report that went
to Girobank, it wasn't a fault that manifested itself in
the branch accounts. It manifested itself in the
figures that Girobank saw, not in the figures the
postmaster saw, because the postmaster says on page 1:
"The PM has checked all dockets and all reversals
... and cannot find anything ..."
He doesn't see anything wrong. Do you see that?
A. Yes.
Q. So would you accept that on a fair reading of this PEAK,
this is a problem that relates to the transmission of
information through to Girobank, it is not a bug that
directly causes a discrepancy in branch accounts?
A. Yes, but any discrepancy can well have an impact on
branch accounts and that's why it is important that
these are highlighted.
Q. Well, I fully agree that it is important that these
issues are fixed, Mr Coyne, but there are two points,
aren't there? First of all, this is being presented as
a bug that creates a discrepancy in branch accounts and
I think we have agreed that it doesn't. Yes?
A. But the support guys here say there is a discrepancy.
Q. It is a discrepancy in the report. It is a discrepancy
between the report sent to Girobank and the true figures
in the branch accounts.
A. So then that is a discrepancy.
Q. Yes. So that is the first point. It is not a bug which
has actually caused a discrepancy in branch accounts, is
it?
A. I struggle to understand why that wouldn't be the case.
Q. Before you said, Mr Coyne, a problem with the report
going to Girobank is still a problem because then there
is a reconciliation error and that could result in a TC
being created.
A. Yes.
Q. But if there is a problem I would like to suggest to you
that the evidence of this PEAK indicates that that's
what the problem would be, yes?
A. Yes. If this fault hadn't been reported by somebody,
this would have likely resulted in a TC.
Q. You see, that's where I come to the second point,
Mr Coyne. It was reported, the problem was spotted.
A. Yes.
Q. There was a reconciliation problem and it went straight
to the SSC, and the SSC worked out what the cause of the
problem was. Do you accept that what this PEAK shows is
not a threat to the robustness of Horizon, actually it
shows the operation, the good and effective operation of
countermeasures to possible threats to Horizon, do you
see?
A. I do, but it is a little obvious that what we are
looking at is PEAKs, so we will only see the times that
somebody calls in and it is recorded. We won't have
records if somebody hasn't reported it.
Q. You are not suggesting, are you, that where there is
a reconciliation exception between a financial
institution and Horizon, that that doesn't result in
an investigation. Surely you do accept that?
A. It should result in an investigation.
Q. Fujitsu has elaborate processes designed to identify
reconciliation exceptions, doesn't it?
A. I don't know whether it would be Fujitsu or Post Office
or who will do that element of it, but they will be
Post Office's clients.
Q. My suggestion to you, Mr Coyne, is that what this report
is evidence of is the robustness of Horizon, it is not
evidence that undermines that robustness, would you
accept that?
A. This is evidence of a defect being identified and
because it was picked up there wasn't -- or if
Post Office handled the next stage of it, then there
needn't be an impact on branch accounts. So there is
a discrepancy that's here, but it is the next stage, but
we don't have evidence of what that next stage would be.
Q. What we do have in this PEAK is evidence of the problem
being raised and being properly diagnosed and resolved.
Surely you accept that in this particular case?
A. Yes. It actually says someone is going to send
a request to the EPOS development team, so that's the
point of sale development -- so new code is going to be
created and that will hopefully fix the problem for the
future.
Q. But also the underlying discrepancy in the report sent
to Girobank, that's also supported. That is the
starting point of the entire inquiry. This is
an example of the robustness countermeasure, RDS and
MID, operating as it should, would you agree with that?
A. What do those two stand for, sorry?
Q. Redundant data storage and manual inspection of data.
A. What does redundant data storage --
Q. It means where you have -- I thought you'd agreed that
this was a standard form of countermeasure in IT
strategies --
A. No, sorry, with regard to this PEAK I'm just trying to
understand why redundant data storage --
Q. It means where you have the same information stored in
different parts of the system and in different systems
and then processes which involve the comparison of that
data to see if there's any discrepancy requiring
investigation, yes?
A. This actually required Girobank to pick up on the
problem.
Q. Yes. I don't know whether it required it, but the fact
it there was a problem and it was picked up because
people look at the figures that they get.
Do you not -- are you not willing to accept that
this is an example of the fact that if lots of different
versions of information are propagated through a system,
and lots of people are looking at that information, that
actually increases the likelihood of any problems in any
data being identified and resolved successfully? Do you
not accept that this is an example of that happening
quite well?
A. Yes, but this is an example of Horizon doing it. This
is Girobank that have picked up on this. So the
information has flown through Horizon, not been picked
up, gone to Girobank, and Girobank have picked up on the
problem. So, yes, their systems must be quite good to
pick that up, but Horizon effectively should have
stopped this before the figure went to them, surely.
Q. Let's move on to another bug. In your table --
MR JUSTICE FRASER: Just before you do, can I have the trial
references for two KELs, please?
MR DE GARR ROBINSON: My Lord, the two KELs, they are so old
they don't exist anymore, I believe.
MR JUSTICE FRASER: They don't exist anymore. Right.
MR DE GARR ROBINSON: This is from 1999/2000.
MR JUSTICE FRASER: Which is why there is no reference in
there. Right.
MR DE GARR ROBINSON: Yes. I wonder whether this would be
a convenient moment. I'm looking very shamefacedly at
the transcript writers.
MR JUSTICE FRASER: Yes, I think it probably is. We will
have 10 minutes. And not wishing to come across as
excessively pedantic, but that means coming back at 48
minutes past.
MR DE GARR ROBINSON: I would be happy to have those extra
two minutes.
MR JUSTICE FRASER: That's why I said 48 rather than 50.
So we will come back at 48 minutes past. A
10-minute break. Thank you very much.
(11.39 am)
(A short break)
(11.48 am)
MR DE GARR ROBINSON: Mr Coyne, we were on the bug table and
we were talking about item 11 on that table which is
Girobank discrepancies.
A. Yes.
Q. And by Girobank discrepancies, you mean discrepancies
within branch accounts, yes?
A. Yes.
Q. Another one of the bugs that you identify over the page
{D1/2/10} is PC0052575, which is at {F/49.1/1}. Could
we have a quick look at {F/49.1/1}, please. This is
a call in on 16 August 2000. This is a call by the
postmaster about three or four lines down -- I should
say 14 August, I'm sorry:
"14/08/00, 16.20:
"Pm has error on giro deposit report. Counter Daily
report does not match office daily report."
So it is right, isn't it, that the reports he is
talking about, these reports are a little bit like
snapshots of the position at the time the report is
taken. Some of them are sent -- maybe all of them are
sent elsewhere, certainly some of them are. And the
postmaster has a problem with the reports because they
aren't consistent with each other, do you see that?
A. Does not match the daily report yes.
Q. Correct me if I'm wrong, but that doesn't mean the
underlying accounts are wrong, it just means that the
reports that have been printed out are wrong, correct?
A. Yes, just reading down. So it tells us there is
a software error and that operator error has been ruled
out. But it may well be the case that it is only the
information that appears on the report is wrong, so it
is misrepresenting what the position is.
Q. If we pick it up at the bottom of that box, 16/08 at
8.51:
"Repeat call: PM has phoned to say his Giro deposits
had a discrepancy between his counter daily and his
office daily reports for yesterday."
Then there are the figures.
MR JUSTICE FRASER: I'm afraid I can't see where you are
reading.
MR DE GARR ROBINSON: My Lord, it is in the big box on page
1, about three-quarters of the way down, 16/08 at 8.51:
"PM has phoned to say his Giro deposits had
a discrepancy between his counter daily and his office
daily reports ..."
Then it sets out the figures.
"PM has produced another transaction log for the
errant amount ... only appears once however shows twice
on office daily printed at 11.08."
So the problem is with the report, not the
transaction log, yes?
A. Yes, it would appear so.
Q. If we go over the page to {F/49.1/3}, the fourth box
down, 31st August at 11.31. This is Alex Kaiser:
"I have looked at this call and found the problem.
It is caused by the window of opportunity that arises
between the points at which a user prints and then cuts
off a Counter Daily\Giro Deposits report on a counter."
So there is a reference to cutting off that we
discussed before.
A. Yes.
Q. "If they are using a shared SU and between the two
points in time another Giro Txn is performed on another
counter, it will NOT be included on that report but it
will be included on the summary record written to the
Messagestore at the point of cut off.
"When the subsequent office daily/Giro deposits
summary report is produced it uses the summary record as
its source and that is why a record that was missed off
the counter report appears on the office one.
"This problem has already been fixed at CI4 by ..."
Then a number of PinICLs are referred to.
What is being described in this PEAK is a problem
that had already been fixed but it is a problem in the
software which generates daily reports, it is not
a problem in the software which generates branch
accounts, would you agree?
A. Yes.
Q. Therefore to the extent that there is a bug at all,
which it appears there is, the bug for which this PEAK
is evidence is not a bug which creates discrepancies in
branch accounts, is it?
A. No, it is a bug that creates discrepancies in branch
reports.
Q. And my final question on this PEAK: what this shows is
that where there are such discrepancies, there will be
an investigation and the true position will be
ascertained, would you agree with that?
A. Where something is logged and we have a PEAK for it,
then that PEAK does typically suggest that it is
investigated correctly.
Q. What I would like to suggest, Mr Coyne, is that where
there are these different pieces of information in the
system being produced and being sent and so on, and
being compared by all sorts of people, including the
postmaster himself or herself, that is a system, the
operation of such an arrangement is in itself
a robustness countermeasure. Would you agree with that?
A. That they have a support process that attempts to
determine the problem? Yes, that's a --
Q. Well, that there are processes which lead to these
problems being exposed and it is the exposition, it is
the exposing of these problems, which lead to
investigations that can assist in increasing the overall
robustness of Horizon?
A. Yes.
Q. What this PEAK shows is not that there was a bug in
Horizon which created a discrepancy in branch accounts.
What it shows is that the Horizon system and all the
support operations surrounding it and supporting it
operated well in identifying if there were any
discrepancies and checking to see if there were any
problems created by those discrepancies, would you agree
with that?
A. I do agree with that. I mean on this example I have
noted in my report that the discrepancy amount was
unclear, and I have also noted that it doesn't appear
that the branch actually appears in this so we don't
know what branch is relates to.
Q. If we could just focus on my particular question. My
question is this really: you cite this PEAK in your
report as evidence of a bug creating discrepancies in
branch accounts, and you then list it triumphantly in
your list of Girobank discrepancy-creating bugs in joint
statement 2, but the discussion we have just had of this
PEAK and the one that preceded it has resulted in your
accepting first of all that it didn't create any
discrepancies in branch accounts, yes?
A. It created a discrepancy which could impact branch
accounts.
Q. It didn't create a discrepancy in someone's branch
accounts, did it?
A. Correct, yes.
Q. What you say is it raised a possibility that some third
party, like Post Office, might generate a TC for some
reason and then the subpostmaster, having received that
TC, might then accept it rather than saying "I don't
know what you are talking about"?
A. Yes.
Q. What you are suggesting is that this countermeasure,
which obviously involves human beings, it is designed to
do that, sometimes, and I would suggest very rarely,
isn't perfect. But nobody is suggesting, Mr Coyne, that
countermeasures are perfect. The really important
question is whether in the overwhelming majority of
times the countermeasure has the effect of increasing
robustness rather than detracting from it. And what
I would suggest to you, Mr Coyne, is that both of the
PEAKs that we have been looking at this morning are
really quite good examples of how these countermeasures
increase rather than detract from the robustness of
Horizon. And that's my question to you, do you agree?
A. I agree from looking at the PEAKs, by the nature of them
being calls, what we see is the investigatory process
when a call is made. So they are a good example.
Q. And I think your -- I mustn't put words into your mouth,
but from evidence you have given on previous days, would
it be fair to say that you think the support process,
the investigation process undertaken by Fujitsu is on
the whole a good one?
A. It is on the whole a good one. There are a number of
weaknesses in the process and for clarity we do need to
be clear on what they are, and one is illustrated here,
that there isn't a branch code in here.
Q. Mr Coyne, could I suggest that if a PEAK were produced
for the purposes of allowing the robustness of Horizon
to be determined by a judge 20 years or 19 years after
the event, then you are absolutely right, this is
a terrible document because it doesn't identify the
branch, it doesn't enable a litigant to demand
disclosure of all the branch records and all the TCs
issued, you are absolutely right. But it is not the
purpose of a PEAK to do that. You regard it as
a limitation of the PEAK. The PEAK is a work process
document which simply records the work being done by the
SSC in relation to a particular call in. It doesn't
need to have that information in order to be
an effective work document, would you agree?
A. I do agree. It has another problem in that this PEAK is
very dependent on the KEL that describes what the flaw
was and the KEL hasn't been disclosed either. So we
don't really know what the determination was.
Q. Forgive me, Mr Coyne, I'm simply asking you to accept
what I would suggest are the obvious implications of the
document that you have got in front of you, and when
faced with a question of that sort you take refuge in
saying "Well, I haven't seen this and I haven't seen
that".
But you are not grappling with the essential point,
are you? Looking at the information contained in these
PEAKs, with all the limitations that that information
has because of the nature of the PEAK and the purpose
for which it was created, looking at the information in
those PEAKs actually it gives you a good basis for
concluding, first of all, that these PEAKs do not relate
to a bug that created any discrepancies in Horizon,
would you agree?
A. That this PEAK did not, I would agree.
Q. And the previous one as well, would you agree?
A. The previous one you took me to, yes. Because it was
picked up, that shouldn't lead to one either.
Q. So first of all we are agreed that both of these PEAKs
are not related to a bug which caused a branch
discrepancy. Secondly we are agreed, aren't we, that
these PEAKs are not evidence that a process was set in
train which led to a TC being issued to the relevant
branch which then foisted a false shortfall on the
branch. Neither of these PEAKs are evidence of that,
are they?
A. No. These are evidence of a part of the process. We
don't know what happened to correct these discrepancies.
Q. So you accept that in both of these cases the relevant
PEAK didn't lead -- the problem identified and dealt
with in each of those PEAKs did not actually lead to
Post Office issuing a transaction correction -- or in
this period it would have been an error notice -- that
would have subjected the relevant subpostmaster to
a risk of loss?
A. No, these documents alone do not show that.
Q. Indeed it would be inconsistent with these documents
because it is quite clear that Fujitsu in these
documents have identified the problem, clarified that it
is nothing that requires any change to any accounts.
There is a problem with the report mechanism, that it is
not ideal in certain very unusual states of
circumstances, yes?
A. It is a little bit more than that. It might be very
misleading for the subpostmaster.
Q. What I would like to suggest to you, Mr Coyne, is none
of that comes out from your report. The clear
impression given by your report is that these two PEAKs
are one of many examples in which there are bugs in
Horizon creating discrepancies in branch accounts, and
my suggestion to you, Mr Coyne, is that these PEAKs are
evidence of the opposite.
A. Bugs, errors and defects is the way that the question
was asked and we --
Q. We are talking about Horizon Issue 1. You don't need me
to go back to Horizon Issue 1, do you?
A. I think that says bugs, errors and defects, doesn't it?
Q. "Bugs, errors and defects to cause apparent or alleged
discrepancies or shortfalls relating to subpostmaster's
branch accounts or transactions."
A. Yes.
Q. And neither of these PEAKs are an example of either of
these things, are they?
A. On their own, no.
Q. Thank you.
A. They are an indication of a discrepancy being
identified.
Q. And yet they are listed in your bug list which you
agreed with me at the beginning of this
cross-examination today was a list of bugs which caused
discrepancies in branch accounts. Could you explain why
you have included those two PEAKs in this list?
A. You need to read it -- as I have said before, for full
context you need to go back to the report. There is
another table in the report that says the discrepancy
amount or whether there was no discrepancy noted, at
page 43.
Q. Page 43 of the report?
A. Page 43 on the face of the report.
MR JUSTICE FRASER: That's page 49 in the bundle. The
bundle reference is 49. I think that's where you were
actually, Mr de Garr Robinson.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: Do you mean the table at
paragraph 3.123?
A. Yes.
MR JUSTICE FRASER: That's the table you are being asked
about, I think. {D2/4.1/49} Or it is an entry within
that table that Mr de Garr Robinson has been asking you
about.
A. I believe, my Lord, he was asking the same within the
reference from the joint statement.
MR DE GARR ROBINSON: Actually, it is very helpful that you
have gone back to that table, Mr Coyne, I would have
overlooked it otherwise. If we could go to page
{D2/4.1/51} and look at paragraph 3.128. I'm sorry to
do this in such inordinate detail. 3.128, this is
a paragraph I took you to before.
A. Yes.
Q. "The above PEAKs related to Girobank discrepancies are
clear examples of bugs within Horizon that affect branch
accounts by way of a financial discrepancy ..."
So you are saying there that the relevant bugs
created a financial discrepancy, yes?
A. Yes.
Q. And I took you first of all to the bug that was
immediately above that paragraph.
A. Yes.
Q. {F/118/1}. And you told me: I didn't put that forward,
you misread paragraph 3.128, I didn't put that forward
as a bug creating discrepancies.
A. Yes.
Q. But you then said that it is not that table I should be
concerned about, it is the previous table.
A. Yes.
Q. Above 3.124, yes?
A. Yes.
Q. If we go back to page {D2/4.1/49} where that table
begins, you will see that the fourth item on that table,
which on your own evidence is a list of bugs that create
discrepancies in branch accounts, is {F/49.1/1},
PC0052575?
A. Yes, with the observation:
"Discrepancy amount unclear. Branch unclear."
Q. Mr Coyne, let's assume that that particular PEAK had
identified the branch and had identified a discrepancy
of £50 or something, just so that I can close off that
escape route when I ask you the next question I'm about
to ask you. So let's pretend. It is the case, isn't
it, that that PEAK is not evidence of a bug which
created discrepancies in branch accounts? You have just
agreed that with me.
A. It created a financial discrepancy within the Horizon
system which could then ultimately have an impact on
branch accounts.
Q. I will move on. Let's take another example that's
contained in your bug table. Going back to the bug
table at {D1/2/10}.
MR JUSTICE FRASER: You want to be in the joint statement
now?
MR DE GARR ROBINSON: Yes. And if you can click on {F/52/1}
on the side of the page that will give us the relevant
PEAK, which is PC0052704.
So just to set the scene. It is your expert
opinion, is it, that this PEAK is another PEAK that is
a clear example of a bug which created discrepancies in
branch accounts, is that your opinion?
A. Sorry, I'm just catching up here. Where are we? Number
12, "Counter Replacement ..."
Q. We are looking at one of the bugs that you refer to in
bug 11, Girobank discrepancies.
A. Right, sorry.
Q. And the particular bug we are looking at is the bug that
you say is evidenced by {F/52/1}, and this is F/52.
A. Right. Okay, yes.
Q. Just for the record, would you confirm that you have
included this PEAK in your report, that you lifted it
from your report and you put it in the joint statement
because it is a PEAK which you say is evidence of a bug
creating discrepancies in branch accounts?
A. A bug, error or defect, yes.
Q. Right. If we could just go over to page {F/52/2} of the
PEAK, the last yellow box. Date 23rd August 2000, 9.30.
This is Martin Harvey at the SSC:
"All these problems occurred while a relief PM was
in place.
"Giro.
"A cut-off was performed between the original
transactions and reversal."
Then there is reference to a KEL.
"A P&A report was produced and then two further
transactions were input before cutoff. The first report
was then mistakenly used to infer that these
transactions had not been performed and so they were
re-input."
Do you see?
A. Yes.
Q. "I could find nothing wrong and when I asked the PM to
re-check his figures neither could he ...
"The PM is happy and has agreed call closure."
On what basis do you say this PEAK evidences a bug
in Horizon that has created a branch account
discrepancy, Mr Coyne?
A. So as a result of the bug, error or defect with the
report that we see on the earlier PEAK, this has led the
subpostmaster to re-enter transactions. It says towards
the end here:
"The first report was then mistakenly used to infer
these transactions had not been performed ..."
So they were re-input. That's because the report
was misrepresenting the true position because of the
defect.
Q. Then the postmaster looks at the end of the day at his
transaction log and he sees that he has got two copies
of the same transaction in his transaction log and he
sees that if there is a discrepancy in his accounts, it
will be in exactly the sum of the repeated transaction
that he has entered a second time in his transaction
log.
The bug itself didn't cause any discrepancy at all,
did it?
A. No, the bug itself led to the report misrepresenting
what the current position was. That's the bug that we
saw before. As a result of that bug, this subpostmaster
has used the information on the face of that report and
entered some transactions that then impacted his branch
accounts.
Q. So just to be clear, you are relying on the passage
that's under the heading "P&A", yes?
A. Yes, which includes the KEL M Wright 531, which appears
to be the common denominator between each of those
Girobank discrepancies.
Q. That KEL is a Girobank discrepancy. We are in P&A now.
What does P&A stand for?
A. I don't know.
Q. It says:
"A P&A report was produced and then two further
transactions were input before cutoff. The first report
was then mistakenly used to infer that these
transactions had not been performed and so they were
re-input."
Mr Coyne, it is not that the system produced a false
report which then induced the postmaster to make
an error. It is that the postmaster looked at a report
that had been done before the two transactions had been
entered. Do you see?
A. Well, on the information given here, Martin Harvey
linked it to the KEL where the Girobank fault was.
Q. Mr Coyne, just look at the words that are written down
in front of me:
"A P&A report was produced and then ..."
Do you see the word "then"?
A. Yes.
Q. "... two further transactions were input before cutoff.
The first report ..."
So the report that was done before the two
transactions were entered into, yes?
A. Yes.
Q. "... was then mistakenly used to infer that these
transactions had not been performed and so they were
re-input."
So what happened was the postmaster -- who it has to
be remembered was a relief postmaster and may not have
been as experienced as he or she might have been, which
is no doubt why that was written down -- had printed
a report that correctly represented the position as at
the time the report was printed, had then entered into
two transactions, had then looked at the report that he
printed, and foolishly he then thought that shows that
I haven't entered the two transactions I have just
entered so I will enter them again. Do you see?
A. I do see but --
Q. That, I would suggest, is not the result of a bug in
Horizon.
A. So if that was right, why would Martin Harvey, when he
wrote that at 9.30 on 23rd August, choose to reference
the KEL for that particular defect? It would make no
sense if he didn't consider that that was part of his
consideration.
Q. Well, I suggest to you, Mr Coyne, that it is plain from
the actual language that he has used, the very language
that you are relying upon, that there was some human
error in this case and the human error was in using the
wrong report, a report that reported on the state of
affairs before the two transactions had actually been
done, and the mistake was that the postmaster thought
that it ought to include those two transactions,
wrongly, and so added them again. And I'm suggesting to
you that that's what Mr Harvey is saying in that middle
paragraph.
A. I don't accept that because Martin Harvey would, in
considering what the issue was, I can't imagine that he
would have referenced the M Wright and the D Rowe KEL if
he didn't believe they were relevant to the situation
that had occurred. That is contra to what the purpose
of these documents are for. They are to lead the next
person that finds the problem, to link these together.
It would be crazy to include a reference to that if it
wasn't relevant to this problem.
Q. Would you excuse me a moment, Mr Coyne. (Pause)
Let's move on to bug 20 now, recovery failures.
MR JUSTICE FRASER: Just before you do, can you tell me what
P&A stands for?
MR DE GARR ROBINSON: My Lord, I can't.
MR JUSTICE FRASER: All right, it doesn't matter.
MR DE GARR ROBINSON: I was hoping Mr Coyne could.
MR JUSTICE FRASER: Do you know what P&A stands for?
A. I don't, my Lord.
MR JUSTICE FRASER: All right.
MR DE GARR ROBINSON: Bug 20, recovery -- it is called
recovery failures. Let's start at your second report,
Mr Coyne, please {D2/4.1/66}. You say in paragraph
3.194:
"PC0197643 created 14 April 2010 refers to branch
166948 in which a.£240.00 transaction failed in
recovery. Whilst a table exists in the database to
potentially capture failed recovery transactions, these
then have to be manually reconciled. The PEAK states:
"'Looking at the PostOfficeCounterLog, the receipt
printed ok for this after authorisation was received,
the receipt that printed for the cash withdrawal [sic]
states 'Authorised', so it's possible that the clerk
handed over the monney [sic].'"
Then you say at 3.195:
"As this was passed to Post Office, it is unclear
what their final resolution was. It is not documented
if Fujitsu removed the transaction and if they did, how
they did it."
{D2/4.1/67}.
This is a PEAK that you also refer to in the bug
table and which we will come to in a moment. Could we
look at that PEAK, please. It is {F/613/1}. So the
PEAK starts on 13th April 2010, which I think must be
during the initial Horizon Online roll out. You agree?
A. Yes.
Q. If you could look at the top right-hand side of the
PEAK, the call logger, you see it is "MSU-IndtMgt". Do
you know what that stands for?
A. Management support unit ...
Q. The other letters you don't know?
A. I don't. Well, management will be the end one but
I don't know what --
Q. Yes. And what does the MSU do?
A. I'm not sure I have seen that set out anywhere.
Q. It receives -- you have seen a great number of PEAKs
that are created as a result of the MSU, yes?
A. Yes.
Q. It monitors things --
A. Right.
Q. -- doesn't it, in the system?
A. Yes.
Q. It monitors all sorts of exceptions?
A. Right.
Q. And when it spots exceptions it passes them through to
the SSC.
A. Right.
Q. That is consistent with your understanding of PEAKs,
isn't it?
A. That sounds reasonable, yes.
Q. And amongst the things that the MSU monitors is recovery
failures, isn't it?
A. Mm.
Q. So all recovery failures of the sort we are discussing
here are in the first instance reported to the MSU, yes?
A. Yes.
Q. Then the MSU will, having identified the problem, pass
it on to the SSC to look into it, correct?
A. Yes. I don't know when this is triggered because there
are -- I have seen PEAKs where it is the subpostmaster
that is attempting recovery and they report that the
counter just keeps re-booting, so perhaps it's --
Q. But sometimes -- and perhaps we can agree on this.
I have thought about that as well and my surmise is that
sometimes the SPM gets the report in first and other
times the MSU does, it is just a timing issue.
A. Yes.
Q. And if the SPM has phoned in first then that is the PEAK
and there doesn't need to be a separate PEAK because the
MSU puts in a call as well, would you say that's fair?
A. Sounds reasonable.
Q. Then it says on the top box "13th April", so we are
really -- Horizon Online is brand new and there are very
few users at this stage:
"Details entered are:
"Summary: Branch ..."
There is the branch FAD code.
"... NB102 Section 5 CAPO - state 4."
That's one of the reports, isn't it, that identifies
when there is a failure, a recovery failure?
A. Yes.
Q. If we go down to 10.06 there is a reference added,
a KEL, that is "dsed2640M". Do you see that?
A. Yes, I do.
Q. If we could have a quick look at that, if we look at
{F/586/1}, please. We will come back to this PEAK,
though.
Have I given you the wrong reference?
MR JUSTICE FRASER: No, that was the reference to the PEAK.
Or did you mean the trial bundle reference?
MR DE GARR ROBINSON: My note, and Homer does nod, I don't
think I'm even Homer for these purposes. My note tells
me that the dsed KEL is at {F/586/1} and if I'm wrong
then I need to move on quickly.
MR JUSTICE FRASER: Don't worry about rushing, it will only
take a moment to find it.
MR DE GARR ROBINSON: It may be 587 {F/587/1}.
So this is the KEL that's referred to. It says:
"Transaction in state 4 on the NB102 Section 5
banking reconciliation report - failed recovery."
Then if we go down to "Symptoms:
"There is a transaction in state 4 on the NB102
Section 5 banking reconciliation report as the
transaction failed to be recovered during recovery."
Of course recoverable transactions will always
involve a bank, won't they, they will always involve
a financial institution, because if it weren't
a three-way transaction involving three parties it
wouldn't be recoverable, it would be cancellable,
wouldn't it?
A. Yes.
Q. So this report will always pick up failed recoveries.
It says under the heading "Problem":
"The transaction in question failed to be settled
due to problems with printing so there was no C1
confirmation. The printing problem was caused by the
failure to print an earlier report/receipt that seemed
to have stuck and caused every print attempt thereafter
to fail. When the user logged off and logged back on
again, the recovery process attempted to recover the
banking transaction but because this in itself requires
a receipt to be produced this failed as well."
Do you see that?
A. Yes.
Q. Then it says:
"The print problem should be evident by 0607 errors
being displayed to the PM and the same error being
recorded in the PostOfficeCounter.log at the time.
There will also be Warnings logged to this log with the
words "Received second print request, before completing
first print request."
So would it be right to infer from what that KEL
says that this problem, as well as going through to the
MSU and being pushed through to the SSC in the normal
way, the problem would also be evident to the postmaster
who was undertaking the transaction at the branch, would
you agree with that?
A. Yes. It is said there will be a 0607 error displayed.
So if the screen is working as a result of whatever this
failure is, then they would probably see that. The
other two things there, PostOfficeCounter.log and
warnings in the log, they won't be visible to the
subpostmaster.
Q. So one way or another, both the postmaster and Fujitsu
independently will know that there's a problem when this
arises, yes?
A. Yes, and at this stage the counter probably hasn't yet
booted back up yet. It is in a failed state obviously.
MR JUSTICE FRASER: Mr de Garr Robinson, can I just make one
observation and it is not to distract you at all. The
number of the PEAK on that KEL is not the number that
you were looking at before.
MR DE GARR ROBINSON: The number of the PEAK on that KEL?
MR JUSTICE FRASER: That's 193463, and the one we were
looking at was 197643.
MR DE GARR ROBINSON: My Lord, yes. The reason why we were
looking at that KEL is because it is referred to in the
PEAK.
MR JUSTICE FRASER: I do understand that, but I just wanted
to make sure that you didn't think it was exactly the
same PEAK. I know the way PEAKs and KELs work so it
wouldn't necessarily be the case.
MR DE GARR ROBINSON: Let me ask a question of Mr Coyne.
The fact that the KEL is referred to in the PEAK
back at {F/613/1}, if we could look at that, please,
that's indicative of the fact that the SSC person who
has received this call has looked at the symptoms and
thought, hang on a second, this displays the symptoms in
this particular KEL. Sometimes they might be wrong,
sometimes it might be an early diagnosis and they may
have a more developed view later. But in general if you
see a KEL referred to in a PEAK it means the person at
that point in time thinks this is a repetition of the
symptoms described in the relevant KEL, would that be
correct?
A. Yes, that is right. And then to balance that when you
look at the KEL, sometimes you do see the back reference
to the PEAKs that use that, other times you will just
see in that scenario just a reference that doesn't refer
back but it might be the first instance of that --
Q. Yes, that's very helpful. So where the KEL refers to
a PEAK, sometimes there might only be one PEAK and it
will be probably the first PEAK that resulted in the
production of the KEL, but other times the KEL could
refer to lots of PEAKs, indeed hundreds of PEAKs. It
depends.
A. Yes. There are a number of KELs that on their own will
refer to many hundreds, and that goes back to the
statement that I made before about the number of likely
PEAKs that could be linked to KELs. You can very
quickly get to very large numbers.
Q. Yes. If we look at this PEAK again at the bottom of the
page, 13th April 2010, at 11.37 it says -- Andy Keil,
who is now dealing with it says:
"Request and authorisation were successful, but no
confirmation or reversal:
"This transaction is in the all branches recovery
table, as per the KEL -'There's a Recovery Table button
on Smiley which shows transactions (for all branches)
where recovery has failed. If your transaction is in
here, it will need manual reconciliation'."
So stopping there. Just to confirm, the way that
Horizon has always worked is that while you are in the
course of typing in a transaction into the counter all
sorts of information is going up the wires into the data
centre which may be the messagestore, in Legacy Horizon
it could be the messagestore at the gateway counter at
the branch, and that would then be replicated in due
course to the correspondence server. And in
Horizon Online it goes straight through to the BRDB, one
of the central data servers, doesn't it?
A. Yes.
Q. On numerous occasions during the course of the
transaction numerous tables -- it is easier if we just
talk about Horizon Online -- in the BRDB are populated
with data relating to the transaction being typed in?
A. Yes.
Q. That is a good thing because it means that if there is
a problem with a transaction, if the transaction goes
wrong before the basket is committed, then there will be
actually several copies of data relating to that
transaction to be found in various tables in the BRDB,
would that be right?
A. There might not be several copies of it but there will
be a stake in the ground somewhere saying you have
commenced a transaction.
Q. So at least if you look for it nothing gets lost, would
that be right?
I don't want to commit you to an extreme
articulation. I understand why you're hesitating.
A. It is a fact that information will have to go from the
counter to the BRDB so theoretically things can get lost
along the way but that's quite unlikely.
Q. Would I be right in thinking that you are not aware of
any PEAK relating to a situation where data relating to
a recoverable transaction has never actually got through
to the relevant tables in the first place?
A. No. There is a number of references to communication
errors have led to situations arising and that often is
seen in recovery, that they determine that the recovery
is required because a communication fault --
Q. But invariably those -- perhaps universally, actually,
those communication problems will be towards the end of
the transaction because that's the point at which the
bank becomes engaged, that is the point at which there
is a risk of the transaction becoming recoverable. At
the relatively early stages where the initial elements
of the transaction are being typed in, if that
information doesn't get through, the system will just
stop, won't it?
A. Yes, that's fair. There is a time by which you are past
the point of no return, if you will, without having to
sort something out.
Q. But my suggestion to you and I'm not trying to fence
with you, Mr Coyne, and I'm not trying to be clever, or
at least no more than usual, but where you have
a recovery scenario, there will always be data relating
to the transaction to be recovered. If there isn't data
in the relevant tables in the BRDB about that
transaction, then you are not in a recovery situation at
all?
A. That is right.
Q. You haven't got far enough in?
A. Yes.
Q. Thank you, that's very helpful. So the way that it
works then is -- what we are talking about is recovery
failures. There will be data in the -- I'm talking
about the BRDB just for simplicity, I appreciate this
is -- actually this is Horizon Online.
A. Yes.
Q. In the BRDB there will be tables containing the data
that relates to the relevant transaction?
A. Yes.
Q. And ideally the system will tell the SPM to try and
recover the transaction but sometimes if there is
a problem with the printer, because the system depends
upon the printer printing out receipts and so on, there
could be a problem which means that although the SPM
knows there's something wrong and he or she has to
address it, there will be a problem that means he can't
on his own, yes?
A. Yes. Because recoveries happen because something has
gone wrong in branch, could be power, could be
communications, could be a whole range of things,
something has gone wrong and therefore the recovery
process needs to start, it is quite possible that
whatever went wrong in the first place is still going
wrong when the recovery attempts and that's why
sometimes the recovery won't be successful because it is
a power problem, you still might have a power problem,
a communication problem, it still might be there.
Q. Yes. So would I be right in thinking it is inherent in
the system in that the fact that any system of this sort
is going to have recovery situations, you can never
guarantee that you won't have recovery failures. The
failure that causes the recoverable transaction in the
first place could be of a nature which is going to
involve a failure of the recovery as well, for example?
A. By design there always would have to be a recovery
process because the risk that there's going to be
a power problem is always going to trigger somewhere on
an estate of this size. If that part of it is designed
well, then the vast majority of all recoveries should be
completely automated.
Q. Yes.
A. There shouldn't be many of the situations --
Q. Well, we can agree that the vast majority of recovery
situations should work well?
A. Yes.
Q. Bearing in mind the vast number of transactions
undertaken at Horizon --
A. Indeed.
Q. -- and a tiny proportion of situations where that
doesn't happen could actually be a quite a large number
over a period of 20 years?
A. Certainly could be.
Q. So would you accept with me that the fact that there
have been a significant number of recovery failures over
20 years, that of itself isn't indicative of a problem
in the recovery process?
A. Of course it has to be accepted that it is a problem
because it shouldn't really happen. Typical recovery
should work on an automatic basis. The manual
intervention that's required when recovery fails, that
shouldn't happen but does happen. It is because it
doesn't know what situation it is and there hasn't been
a recovery scenario created for that and therefore it
requires manual intervention.
Q. I didn't ask the question properly, and it is my fault
not yours. What I meant to ask was it is inevitable
with any system, however well designed, that there will
be a small proportion of cases where the automatic
recovery processes don't work. That's just inevitable,
isn't it?
A. Yes.
Q. Thank you. That's very fair. And that's what happened
here, this is one of those cases?
A. Yes.
Q. You will see that, as I think from the passage we have
already read:
"There's a Recovery Table button on Smiley which
shows transactions (for all branches) where recovery has
failed. If your transaction is in here, it will need
manual reconciliation."
We have agreed that data relating to recoverable
transactions will always be somewhere within BRDB,
I think?
A. Mm.
Q. We have agreed that there will always be cases, a small
proportion of cases, where the recovery process that one
would like to operate automatically for one reason or
another doesn't, and in that small proportion of cases
some form of manual assistance is required, isn't it?
A. Yes.
Q. And the system for example isn't designed -- the
recovery system isn't required to require the counter to
keep trying to log on and log on perpetually, it is
designed to log on only twice?
A. Yes.
Q. That is a design feature, because if it is perpetual you
can't use the machine?
A. Yes.
Q. That is very helpful. So the fact that you have
recovery failures is not of itself a threat to
robustness unless the proportion of the recovery
failures you have is too high?
A. Yes.
Q. Here the system that's operated by Horizon is that where
you have a recovery failure it is always reported both
to Fujitsu and, by error warnings, also to the
subpostmaster, yes?
A. Yes.
Q. So both Fujitsu and the postmaster, where there is
a failed recovery, know there is a problem and they know
they need to deal with it by communicating with each
other, do you agree with that?
A. Yes.
Q. And that's the way that the Horizon system is
constructed, correct?
A. Yes.
Q. One other aspect of the recovery process that's very
important is to know when money changes hands?
A. Yes.
Q. And let me just expand on why that's important. You
have a transaction, ex hypothesi it is a transaction
involving a financial institution making or receiving
a payment, and let's say it is a bank deposit. The
customer hands in £100 at the branch, the branch presses
the buttons so that the customer's bank account goes up
by £100, and the problem that arises with recoverable
transactions is that the bank may have been told to
increase the balance by £100 before the transaction has
actually been committed to the accounts of the branch.
A. Yes.
Q. And in that scenario, the postmaster may have seen
a symbol on his screen saying "Accept the money,
authorised to accept money", yes?
A. Yes.
Q. Or he may not have done. But whether he has or not, you
don't know whether actually money has passed hands, do
you? If you are at Fujitsu you are not going to know
whether money has passed hands and you are going to want
to check, because it might be that the postmaster sees
the transaction stopping and says to the customer "I'm
terribly sorry, I have a problem with the system, I'm
closing it down. You had better keep your money and
come back a bit later". That's always possible, yes?
A. I was in agreement with you until you said if the
message on screen says "Accept the money", because that
should be the very last thing that happens after the
process has been completed. That shouldn't be
an intermediate phase before completion.
Q. So what you are saying is the message "Accept recovery"
never comes up before the transaction is committed to
the database?
A. You said "Accept money", did you? You said "Accept
money"?
Q. Yes.
A. Well, that message -- it would be unsafe if that message
was to appear before the transaction has been
properly --
Q. Right, but -- very good. But sometimes human beings do
accept money a bit early, don't they?
A. Yes.
Q. So it is prudent, isn't it, in the scenario where there
is a transaction, to check with the SPM as to whether
money has been received or not, do you agree?
A. Yes.
Q. There is a danger, if you don't do that, that the SPM
could end up being foisted with a false shortfall, isn't
there? For example, the SPM might say to the customer,
"There is a problem with my system. Ordinarily I would
be taking money from you but you had better come back
later with your money, I'm terribly sorry", and doesn't
take the money, but then finds that his accounts have
been multi-ed(sic) to the tune of £100. The account
thinks he has received the money and there then appears
to be a shortfall. Do you see that?
A. Yes.
Q. So in that kind of scenario it is always prudent, isn't
it, for there to be a conversation with the postmaster
to work out, to ascertain what the postmaster actually
did on the ground, would you agree?
A. Yes, I mean I think if that conversation can go on at
the time that the transaction is taking place, then
I can see how that would work. If it is going to happen
the following day or something like that then there's
very little value.
Q. Why would that be, Mr Coyne? There is a recoverable
transaction, something has gone wrong, the recovery for
one reason or another hasn't operated automatically.
The way that Horizon is set up is that the system is
then made aware of the problem so that there can be
a communication, co-operation between Fujitsu on the one
hand, Post Office on the one hand, and the postmaster on
the other, to work out what happened to make sure that
the branch accounts properly reflect what happened in
the real world.
A. Yes.
Q. What would be better than having such a co-operative
arrangement?
A. Just in practical terms I don't know how that would work
in a large Post Office if it isn't taking place at the
time that the transaction is going on.
Q. As I think we have established, the postmaster -- as
soon as the problem arises the postmaster knows about
it. I think you have already agreed that. So
a postmaster can be expected to keep some kind of note
that I have had a problem or remember that he has had
a problem, yes?
A. If it was the postmaster that was at the counter at the
time, yes.
Q. Or the clerk whom the postmaster employs to do that job.
One way or another, when something goes wrong you would
expect the person at the branch doing the transaction to
remember -- to know that something has gone wrong and to
remember it because it could be important for accounting
purposes later. Postmasters and clerks aren't goldfish,
are they, they do have a memory of these things?
A. That is fair.
Q. They will know the significance of the point and they
will know they ought to remember because it may come up
later, yes?
A. Yes, I think it is going beyond my technical expertise
about what happens physically within the Post Office,
but I can accept the premise that you are putting to me.
Q. If we go back to the PEAK. We are at the bottom of
page 1, middle paragraph of the box at 11.37 {F/613/1}:
"Looking at the PostOfficeCounterLog, the receipt
printed ok for this after authorisation was received,
the receipt that printed for the cash withdrawal states
'Authorised' ..."
So it looks as if the postmaster was authorised.
" ... so it's possible that the clerk handed over
the monney. There is a timeout issue after the receipt
printed."
And timeout issues, we discussed that before, didn't
we, that the system is designed only to try on two
occasions and then it stops because otherwise it makes
the machine hard to use, yes?
A. Yes, so the receipt was printed and then something else
happened. The timeout issue, I'm not sure what --
Q. So if we go down to the next box, 13th April at 11.37:
"The call record has been transferred to the team
..."
MSU again. This time would you agree it is going
back to the MSU so the MSU can contact Post Office and
say "You need to speak to the postmaster to check what
happened and, if necessary, you may need to do a TC",
would you agree with that?
A. Yes, I haven't seen that document.
Q. If we go over the page {F/613/2}, the yellow box at the
top of the page, 13th April at 15.07. Joanne Ball, who
I assume is at MSU, says:
"Thanks Andy."
Andy being Andy Keil at the SSC.
"Final BIMS issued to POL."
Can you explain what a BIMS is?
A. Business incident management? I don't know what the S
is.
Q. Yes. So what do you think that BIMS would be saying?
A. It will possibly be describing the scenario that
occurred and suggesting what actions --
Q. Post Office should take?
A. Post Office should take, yes.
Q. In this case it will be: you need to check with the
branch whether money changed hands, and if it didn't you
might need to issue a TC, if it did then you won't, yes?
A. Yes.
Q. Could I suggest to you, Mr Coyne, that is the system
working as it should. This PEAK isn't a demonstration
of a failure in the Horizon system or in its
countermeasures. It is actually good evidence of the
countermeasures working so as to avoid the risk of any
loss to a subpostmaster. Would you agree with that?
A. As the position stands at the end of this PEAK, there is
a discrepancy within branch accounts which Post Office
may well go on to fix as a result of that BIMS but it is
incorrect at this point in time, or it might be
incorrect at this point in time.
Q. What interests me, Mr Coyne, is that you are quite happy
to describe this PEAK as an example of recovery failures
creating discrepancies in branch accounts. We don't
know whether it did or not actually. But you stop. At
a earlier stage in your cross-examination I think you
accepted that it is important for the expert to consider
not just what the immediate impacts of a bug are but
also what impacts the countermeasures that the system
has would be. It is important therefore to focus on the
ultimate result, not on some transient situation that
may exist for a limited amount of time. I think you
agreed with that before but perhaps I will invite you to
agree with it again.
A. I do agree with that but we have to work off the
technical evidence available, and there isn't technical
evidence available to show that this discrepancy was
resolved.
Q. Here's what interests me, Mr Coyne. What you are saying
is -- let me do it this way. I would suggest to you
that on any fair and reasonable reading what this PEAK
demonstrates is, first of all, that Fujitsu spotted that
there was a failed recovery situation?
A. Yes.
Q. Very reliably. One can reliably assume that's going to
happen, yes?
A. Yes.
Q. Looked into the underlying circumstances at the branch
at the time of the recovery. Again one can reliably
assume that's going to happen?
A. Yes.
Q. Then formed the view it was necessary to work out what
had happened on the ground in order to know whether any
discrepancy had been created or not, yes?
A. Yes.
Q. Then sent through a BIMS to Post Office to tell
Post Office to reach out to the postmaster and ask what
actually happened on the ground?
A. Yes.
Q. And I further suggest to you, Mr Coyne, that the reason
why Fujitsu sent that BIMS and the reason why
Post Office received that BIMS, they don't receive these
documents in order to put them in a pile in some
warehouse and never look at them, they receive them so
that they can be acted upon?
A. Yes.
Q. And on any fair reading of the evidence, it would be
extraordinary in this case to assume that having
received that BIMS, Post Office would not have reached
out to the postmaster, ascertain what had happened and
sent a TC or not depending on the postmaster's answer.
A. Yes, but this is quite clear, when you read the heading
"Recovery Failures", that it is seeking to address
Horizon Issue 4: to what extent has there been the
potential for errors in the data recorded in Horizon?
Q. Mr Coyne, can I remind you we are talking about a PEAK
which is in your bug table. It is in your evidence of
bugs which have caused discrepancies. This table
consists exclusively of what you say are bugs for which
there is good evidence that discrepancies were caused to
branch accounts, am I wrong?
A. There is a table in my report -- this is a joint
statement, remember. There is a table in my second
report. If you look on the face of it, page 12
{D2/4.1/18}, and it is quite clear here that this is
under Horizon Issue 4 rather than Horizon Issue 1. And
Horizon Issue 4 is a different issue talking about the
potential.
Q. Have you finished your answer?
A. Yes.
Q. Mr Coyne, your answer is absolutely astonishing. First
of all, let's look at the table. It is "Recovery
Failures" which is three rows from the bottom. You say
it is relevant to Issue 4. Look at the next column.
The next column says "Evidence of Branch Impact."
A. Yes.
Q. You are there saying that the recovery failures that you
have identified are recovery failures for which there is
evidence they had an impact on branch accounts?
A. They do have an impact on branch accounts until it is
dealt with by Post Office. There is very little doubt
about that.
Q. Secondly, I got this reference not from your table or
from any paragraph of your report, I got this PEAK
reference from the bug list in JS2, and you agreed with
me I think at the beginning of this morning's evidence
that that represents a list of bugs that you think had
branch impact, had an effect on branch accounts. So
I go to the PEAK and I expect to see a bug in there
which has a demonstrated impact on branch accounts.
But we go to this PEAK and what do I see? First of
all, I don't see any bug at all. I see a failure in
recovery which you yourself accepted was inevitable.
Even in the best, most perfect system there are always
going to be recovery failures.
Secondly, I see no evidence of a discrepancy being
created as a result of any bug in branch accounts. What
I see is a system which is designed to avoid any
discrepancy being created in branch accounts?
A. Your questioning there was all about bugs. The actual
Horizon Issue is framed as bugs, errors and defects. It
is quite clear both in my report and in the table within
the joint statement that recovery issues has been
identified as Horizon Issue 4.
Q. If we could go to paragraph 1.15 of the joint statement,
so that's {D1/2/29}, please.
A. The second joint statement?
Q. Second joint statement:
"The number of distinct bugs, for which the experts
have seen strong evidence of the bug causing a lasting
discrepancy in branch accounts, is between 12 and 29."
So your expert opinion is that all 29 of the bugs on
the bug table contain strong evidence of a financial
discrepancy being caused in postmaster's accounts, yes?
A. Sorry, let me --
MR JUSTICE FRASER: I think you have given an incorrect
reference to the joint statement or I can't find where
you are reading from.
MR DE GARR ROBINSON: I'm sorry. Paragraph 1.15 on page 29
of the bug table. Well, it's not the bug table, it's
JS2.
MR JUSTICE FRASER: The joint statement, second joint
statement?
MR DE GARR ROBINSON: Second joint statement, yes.
A. The agreed part of it? Yes.
MR DE GARR ROBINSON: So what you are saying there is your
expert opinion, your considered opinion, is that all 29
of those bugs contain strong evidence of the bug causing
a lasting discrepancy in branch accounts, yes?
A. The statement there is an agreed statement between us.
Q. Yes.
A. That the number is between 12 and 29.
Q. And your view is that it is 29, correct?
A. My view will be whatever the number is in the table --
Q. Yes, it is 29.
A. -- in my report.
Q. Yes. 29 bugs are in the bug table in the second joint
statement, yes? And you confirmed when you started
giving evidence about the bug table this morning that
these 29 bugs represented the culmination of the work
that you have done, they represented bugs that you
considered had caused discrepancies in branch accounts.
You are not withdrawing that evidence now, are you,
Mr Coyne?
A. I'm not. Are you referring to the bug table in my
report?
Q. I'm referring to the bug table in the second joint
statement from which I have been working all morning,
yes.
A. Right, okay. Well, the bug table in my second report
has a column that says "Evidence of Branch Account" and
it has an indicator in there saying yes or no.
Q. I'm looking at paragraph 1.15 which is agreed by you.
A. Yes.
Q. As I understand it, it is an assertion by you that all
29 of the bugs in the bug table caused lasting
discrepancies, that there's strong evidence that they
caused lasting discrepancies. Do you see that?
A. Yes.
Q. And by "lasting", the antithesis of a lasting
discrepancy is a transient discrepancy, correct?
A. Sorry, just put that question again, please.
Q. There are two kinds of discrepancy that can be caused.
There are transient discrepancies and there are lasting
ones.
A. Right.
Q. And the difference between transient discrepancies and
lasting discrepancies is transient discrepancies get
handled by countermeasures. So there is no ultimate
effect, there is no lasting effect. There may be some
short period of time where there is a potential
shortfall, but in the long run the countermeasures
existing in the Horizon system will ensure that the
discrepancy is resolved. Yes?
A. They should ensure if they are all working in position
correctly, yes.
Q. And that's what's meant by the word "lasting" in
paragraph 1.15, yes?
A. Yes.
Q. So what you are saying is for each of the 29 bugs there
is strong evidence that the bugs concerned not only
caused discrepancies but they caused discrepancies which
were lasting, which weren't handled by countermeasures.
You see? That's your expert opinion, isn't it?
A. Yes.
Q. And yet we go to this -- and you cite lots and lots of
PEAKs, I can't go through them all. But we go to this
PEAK and what I suggest to you, Mr Coyne, is first of
all there's not evidence of a bug, but more importantly
for present purposes the evidence constituted by this
PEAK demonstrates that if there were any discrepancy
caused, it would have been picked up in the process, the
BIMS process, that we have been discussing. Do you not
agree?
A. It certainly should pick it up and that will correct the
discrepancy, and therefore it shouldn't be lasting if
that whole process works in the way that you suggest.
But that was offered up as Horizon Issue 4, and Horizon
Issue 4 asked for the potential and that is the area of
potential.
Q. Mr Coyne, I don't want to be discourteous to you, but
I suggest to you that you are evading my question. My
question is, please forget Horizon Issue 4.
A. Right.
Q. We are talking about bugs creating discrepancies in
branch accounts.
A. Yes.
Q. I have closed off that escape route for you, if I may
say so. Okay?
A. Right.
Q. And the purpose of the bug table is to identify
precisely those bugs that had a lasting effect on branch
accounts after taking countermeasures into account, yes?
A. Why are you suggesting that the purpose of this bug
table is what you are suggesting it is?
MR JUSTICE FRASER: All right, I'm actually going to
shortcircuit it this way because it is just past
1 o'clock. There is a joint statement that says you and
Dr Worden agree between 12 and 29.
A. Yes.
MR JUSTICE FRASER: Do you know what your number is between
12 and 29?
A. There is evidence --
MR JUSTICE FRASER: No, no. Do you know what your number
is?
A. 13.
MR JUSTICE FRASER: Right. If you want to pursue this
anymore, Mr de Garr Robinson, do it at 2 o'clock.
Thank you all very much. 2 o'clock.
(1.03 pm)
(The short adjournment)
(2.00 pm)
MR DE GARR ROBINSON: Mr Coyne, good afternoon.
A. Good afternoon. Sorry, Mr de Garr Robinson, before we
start could I please correct the number I provided just
before lunch.
In tallying up the numbers in the column in my
report I missed that the last one is actually a heading
that includes a number of bugs, errors and defects, so
the actual number is 21. They are in the report, they
are just grouped together for the purposes of the table.
Q. 21. So which ones -- if we are looking at the bug
table -- did you mistakenly leave out? Which headings
are we talking about?
A. The very last on on the table in any report.
Q. Network banking bug?
MR JUSTICE FRASER: I do not think you are in the same
please.
Can you just give us a paragraph number?
A. Just above paragraph 3.22 of the second report.
MR DE GARR ROBINSON: So this is {D2/4.1/18}.
A. Yes. The last one on there that talks about bugs,
errors and defects introduced previously by fixes?
Q. Yes.
A. That is actually a group heading, and in the report
there's seven bugs, errors and defects included in that
heading.
MR JUSTICE FRASER: So the number is 21.
A. The number is 21.
MR JUSTICE FRASER: All right.
MR DE GARR ROBINSON: Just before we get to the number,
I would like to just understand where we now stand.
We all understand, I think, we discussed it several
times during the course of the last few days, the
significance of the distinction between transient bugs
on the one hand and lasting bugs on the other?
A. Yes.
Q. The distinction is transient bugs are bugs that will be
caught by countermeasures, lasting bugs are the ones
that the countermeasures may miss, yes?
A. Yes.
Q. So where you say you have identified 21 bugs that are
lasting, you are also saying that the other bugs, such
other bugs as have been identified at any tables or any
lists, those bugs actually in your judgment are bugs
that would not have got past countermeasures, yes?
A. That would not have got past?
Q. Yes, that would have been caught by countermeasures.
That's why they are not lasting.
MR JUSTICE FRASER: I'm afraid I don't understand that
question.
MR DE GARR ROBINSON: A large number of bugs are set out in
the bug table in JS2.
A. Yes.
Q. When I say the bug table, I'm talking about the table
which I thought represented the issues between the
experts on bugs.
MR JUSTICE FRASER: Yes, the one in the joint statement.
MR DE GARR ROBINSON: The one in the joint statement. There
are 29 bugs in that joint statement.
A. Yes, bugs, errors and defects.
Q. I'm not seeking to achieve an advantage by just saying
bugs, I'm simply using the term as a form of shorthand,
Mr Coyne. I understand what you mean when you seek to
make yourself clear. That's entirely reasonable.
That table identifies 29 bugs. You now say 21 bugs
are lasting. And just to be clear, what you are
actually saying is that 8 of the 29 bugs were not
lasting, they are bugs that in your judgment would not
have got past the countermeasures that exist in Horizon,
yes?
A. Not quite. They are bugs which have the potential, so
they could well be caught at a later point in time.
They go to one of the later Horizon Issues.
Q. I'm focusing exclusively, and I would be very grateful
if you would focus exclusively, on bugs having an impact
on branch accounts, okay? I'm not going to be asking
you questions about Issue 4 or other issues. I'm
focusing today exclusively on Issue 1, okay? Just to be
clear.
A. Right.
Q. What I'm suggesting -- what I'm seeking to ascertain
from you, Mr Coyne, is that by saying your expert
judgment is that there are 21 bugs which are lasting, it
follows that eight of the bugs on the bug table in JS2,
eight of those bugs in your view are not lasting,
correct?
A. Yes.
Q. So in your expert view, you do not suggest that those
eight bugs got past countermeasures, would have got past
the Horizon countermeasures?
A. Yes, that's true.
Q. Thank you. That's very kind.
MR JUSTICE FRASER: A different way of putting the same
point is the passage that I asked you about, which is at
1.15 on JS2 on page 29, which said:
"The number of distinct bugs, for which the experts
have seen strong evidence of the bug causing a lasting
discrepancy in branch accounts, is between 12 and 29."
29 is now 21?
A. Yes, my Lord {D1/2/29}.
MR JUSTICE FRASER: Right.
MR DE GARR ROBINSON: That you are now asserting 21 rather
than 29 takes me by surprise, Mr Coyne. If I could ask
you to look at the transcript for this morning.
A. Yes.
Q. Page 15, if we pick it up at line 11 {Day17/15:11}.
"Question: Let me ask a slightly different
question."
And I'm talking now about the bug list in JS2.
"Question: This is the definitive list, isn't it?
You are not suggesting that there are other bugs with
evidence of financial impact -- you are not relying on
any other bugs with evidence of financial impact, it is
just the 29 bugs identified here?"
"Answer: These are the ones that I have identified,
yes."
A. Yes.
Q. I didn't ask you any further questions and moved on
because I had understood you consistently throughout
this case actually since before Christmas -- or
certainly since your second report -- as asserting --
well, actually since JS2 -- that the 29 bugs in JS2 were
bugs with lasting financial effect.
I form that understanding on the basis of the
heading to the table. If we could look at the bug
table, it is {D1/2/3}. So there's the heading. It is
page 3:
"Table of Bugs/Errors/Defects with acknowledged or
disagreed evidence of financial impact."
What I had understood, Mr Coyne, was that this set
out the bugs that you thought had -- and I'm going to
introduce the word "lasting, it is not in the heading --
that you thought had lasting financial impact and those
bugs which Dr Worden thought had lasting financial
impact. My apprehension had been that you said 29 bugs
had lasting financial impact and Dr Worden said only 12
did.
A. Yes.
Q. If we move forward in the table to page {D1/2/27}, there
are various agreements recorded here in relation to
Horizon Issue 1, which of course is to do with
shortfalls.
A. Yes.
Q. If we look at paragraph 1.2, look at "Statement", this
is an agreed statement:
"Referring to the table of bugs above, the experts
agree that the bugs in rows 1, 2, 3, 10, 13, 14, 18, 23,
24, 25, 27 and 28 may have had financial impact on
branch accounts. Other rows, the impact is not agreed
between the experts."
A. Yes.
Q. That's 12 bugs. And I had understood the position, in
fact everyone on this side of the court had understood
the position, that Dr Worden accepted that those 12 bugs
had that financial impact, or there was evidence that
those bugs might have had lasting financial impact, and
the disagreement between you was that you said another
17 did to get you up to 29. Do you see?
A. Right.
Q. Then if we move forward in the table to page {D1/2/29},
please, in the joint statement, and we look at
paragraph 1.15, another agreement:
"The number of distinct bugs, for which the experts
have seen strong evidence of the bug causing a lasting
discrepancy in branch accounts, is between 12 and 29."
I thought -- and I'm telling you this so that you
can explain what my mistake was and how I made it --
that that 12 was the 12 referred to in paragraph 1.2 and
the 29 was the other 17 in the table that you were
asserting. So my understanding of joint statement 2 was
that you were asserting there were 29 bugs with lasting
financial impact and Dr Worden -- or with evidence of
lasting financial impact -- and Dr Worden was asserting
that there were 12 bugs for which there was evidence of
lasting financial impact. Was I wrong?
A. Well, yes, you were wrong. That was a statement that we
agreed to put in because we couldn't get agreement on
how many there actually were, so we ended up putting
a range in for the purposes of --
Q. Here's what I don't understand. I presumed that you
agreed with the 12 bugs that Dr Worden had identified
because they are set out in paragraph 1.2.
A. Yes.
Q. So the point was that you were asserting an extra --
some extra bugs to bring us to a higher total, yes?
A. Yes.
Q. And in paragraph 1.15, forgive me, it appears that that
higher total is given, namely 29?
A. Yes.
Q. Are you suggesting that you have only ever suggested 21
and no one was suggesting anything above 21?
A. No. There are 29 bugs, errors and defects in the list
and in the table starting at number 1, but some of those
go to other Horizon Issues apart from Horizon Issue 1,
and they do say that clearly in the heading.
Q. The reason why I'm confused by your answer is that it
seems to me -- and tell me why I'm wrong -- that in
paragraph 1.15 it is being suggested that someone is
saying there are 29 bugs which have lasting financial
impact.
If what you are now saying has always been your
position, then nobody was ever saying that there were 29
bugs with lasting financial impact. So my question
becomes: how is it you were saying in 1.15 that there
were another seven bugs with lasting financial impact
when no one was saying so?
A. I'm not actually sure who suggested the first draft of
that statement.
Q. It doesn't matter though, does it?
A. No, it doesn't matter, but because it was correct it's
gone in as agreed.
Q. How could it possibly be correct in a world in which
Dr Worden was suggesting there was evidence for 12 bugs
with lasting financial effect, and you were saying no,
there's an extra nine to bring it up to 21, how could it
possibly be correct that there might be 22, 23, 24, 25,
26, 27, 28, 29? Where do the other eight bugs come
from? How is it possible that there could be an extra
eight bugs with lasting financial effect where you have
just told me that neither you nor Dr Worden thought that
there was?
A. Because some of the Horizon Issue 4 bugs, errors and
defects that are reported in here and are reported in
the joint statement could have a lasting impact on
branch accounts but we don't necessarily have evidence
of that.
Q. Mr Coyne, I would like to suggest that that is not any
sensible or fair reading of what's set out in
paragraph 1.15 and that on any sensible reading
Dr Worden was alleging 12 and you were alleging 29.
A. Mm.
Q. And you refute that, do you?
A. No, at the time we were working from that table of 29
bugs, errors and defects. There were 29 in play that
were being discussed.
Q. I have to say your answers are making things more, not
less, clear. I don't know what you mean by "being in
play". You either -- it is a binary situation. It is
almost a set of philosophical statements.
A human being either believes that there's evidence
that a bug has a lasting financial impact or he does
not. In a world in which Dr Worden believes that there
are 12 and you believe that there are 21, and there is
no one else in the room who has a belief because you are
the only two people who are producing the statement, it
makes no sense for anyone to mention an additional
number to bring you up to 29. You should have said: it
is between 12 and 21.
A. No, but what you have said there precisely illustrates
my point. You said there is either evidence of, and the
challenge is with a number of these there is evidence of
there being a defect but there isn't necessarily
evidence of financial impact from that defect.
Q. Mr Coyne, everybody on this side of the court, and
I mean everybody on this side of the court, believed
that your view was that the evidence showed that there
were 29 bugs with lasting financial impact. You are now
saying that we made a mistake, are you?
A. Yes.
Q. Could I ask you to explain where you made it clear what
you were actually saying?
A. Well, as set out in my second report, there is a table
there that quite clearly says whether there is evidence
of branch impact or not. And there is also a list of
which Horizon Issue it specifically relates to. The
only addition to that is when you come to the very last
column, there's other bugs, errors and defects that are
re-introduced and they are only covered in the joint
statements.
Q. Would you give me a moment, I'm so sorry. Because
I wasn't prepared for the discussion we are now having
I'm afraid I'm going to stumble rather.
(Pause)
So what you are suggesting is that there are I don't
know how many ... In your table 1, how many bugs have
you counted from your table 1 that you now say have
evidence of lasting financial impact?
A. How many from your table? Right, okay. So 14 from the
table.
Q. 14. Then an extra seven that come from the last item?
A. The last item, yes. They are covered in the report at
3.211.
Q. So it is the last item on the report. There appears to
be an item corresponding to that item in the bug table.
A. There is, yes.
Q. It is in {D1/2/21}. It is bug 22. So have I made
another error, Mr Coyne? Have I wrongly assumed that
item 22 corresponded with the last item in your table 1
in your joint report? Are you now saying, no, no, that
last item in the joint report actually accounts for
a whole host of other bugs?
A. Yes, let me just turn to that in my report.
Q. I must admit I have been focusing on your bug table
because this represents the last statement, as
I understood it, of the issues between the parties or
between the parties' experts.
A. It does.
Q. I'm not trying to stop you going to your report, please
go ahead, Mr Coyne.
A. Yes. Yes, they are covered in the 22 ... sorry.
(Pause)
So covered at 3.211 in the report.
Q. Yes.
A. You see the PEAKs that are ...
Q. There are two PEAKs in that section, {F/53/1} and
{F/55/1}. I'm not sure how that could account for
another seven bugs.
A. But then if you go on from 22 you have got 23, bureau de
change.
Q. You are saying that is an aspect of bugs, errors and
defects introduced by previously applied PEAK fixes, are
you? Because it is plainly not right, Mr Coyne. What
are you saying?
A. Sorry, I'm drawing a blank now what the cross reference
is for these ... Sorry, I would need to search for that
PEAK reference under the Coyne impact column against 23,
bureau de change, just to see where that features.
Q. The interesting thing is if you look at table 1 in your
second report {D2/4.1/18}, there is an item for bureau
discrepancies. That's different from bureau de change,
is it?
A. I think bureau discrepancies is already covered further
up in this joint statement.
Q. I see. So are you saying that bureau de change were --
they were within your category of bugs, errors and
defects introduced by previously applied fixes? Is that
what you are saying?
A. Yes.
Q. And are you saying that for the others: wrong branch,
customer change? I don't want to put words into your
mouth.
A. Yes, because the original bureau de change is at 14 --
sorry, bureau discrepancies which corresponds --
Q. Sorry, it was a red herring I introduced. I was trying
to help and I do not think I did.
Let me move away from that subject. Perhaps we
could have a think about that, maybe we will have
a break in a few minutes and think about it, but before
we do that, subject to his Lordship of course, I would
like to go back to the first issue I was seeking to
explore with you, which is how wrong we were about what
your expert opinion was, and you told me that on this
side of the court we were wrong to think that your
expert opinion was that there were 29 bugs with lasting
financial impact.
Could you tell me where in any document you have
indicated that your view is in fact not 29 but 21?
Where will I get that from?
A. Throughout the report I have set out next to every
single defect whether it is relating to the test of
Horizon Issue 1 or a later Horizon Issue, and I have
also set out whether I believe there was impact on
branch accounts all the way through report number 2.
Q. Let's not talk about report number 2 because the
statement -- the most up to date statement of the
position, I think you agreed with me at the beginning of
today, the culmination of all your work, including work
you did after your second report, is the bug table in
joint statement 2?
A. Yes, but when you put that to me I said that that can't
be read in isolation, it must be read with the second
report.
Q. Indeed you did. And that was entirely fair because with
particular PEAKs you might need to go back to your
report to see what you said about those PEAKs. But
nonetheless, the bug table had 29 bugs in it which you
said had financial impact. I had thought you were
saying all 29 had lasting financial impact for the
reasons I have already explained because of what was in
paragraph 1.15 of the joint statement.
My question is: where in your joint statement do you
say my view as to lasting financial impact is 21? And
if you say it nowhere, why do you say it nowhere?
A. Can I take you to one illustration of that? If you look
at number 21.
Q. In the bug table?
A. In the bug table. {D1/2/20} So that is transaction
correction issues, and I say there in brackets "(Horizon
Issue 4 & 15)".
Then what my statement says there is:
"Transaction correction bugs/errors and defects do
not cause discrepancies with branch accounts but do:
"(a) Reduce the Subpostmaster's ability to resolve
any discrepancies ..."
Etc. So I make it clear in there that there's not
an impact on branch accounts but it does relate to
Horizon Issue 4.
Q. So you say you make it clear it is not 29. So we have
got down to 28. Where do you make it clear that another
seven should also be excluded from the list?
A. Number 17 {D1/2/16} has Horizon Issue 4.
Q. And where do you say that doesn't have lasting financial
impact?
A. If you read the text it doesn't suggest that it does.
Q. Here's what I find really interesting, Mr Coyne. I'm
looking at your table 1 -- you know you keep wanting me
to go back to look at your second report. If I look at
table 1 of your second report it has an entry for branch
customer discrepancies {D2/4.1/18}, and in the "Evidence
of Branch Impact" column it has the word "Yes". So did
you make a mistake, should you have written "No" there?
Or are you putting a construction on bug 17 in the table
that it doesn't bear?
A. If you read Dr Worden's opinion on that, recovery
messages needed to be dealt with to correct the
discrepancy at the branch. So there was an impact on
branch accounts but it was corrected.
Q. Let's move on. So far we have taken out two of these
items on the list. Where are the others coming from?
Which others should we be taking out?
A. So 19, Post & Go, that's a Horizon Issue 4.
Q. Yes.
A. So on the table I have said that there is evidence of
branch impact on there.
Q. Sorry, which table? What am I looking at?
A. Forgive me. In my second report, on the table, you will
see that Post & Go is listed as a Horizon Issue 4.
Q. Yes, and it is also listed as having evidence of branch
impact --
A. I will take you to that in one second, yes. In the
joint statement table that explains that that's Horizon
Issue 4.
Q. Right.
A. And there is evidence of branch impact. The problem
impacted at least one branch account for 43 days and it
appeared repeatedly on the daily report to the
Post Office from Fujitsu.
Q. Rather than -- I'm not taking you to task or criticising
you for this, and I understand entirely why you are
explaining your reasoning, but in the first instance
could you simply tell me the bugs that you think should
be taken out from the list I thought I was facing and
then we can perhaps talk about them after you have done
that?
A. You want the bugs to take out?
Q. Yes.
MR JUSTICE FRASER: At the moment I have been noting it. We
have got 17, 21 and 19.
A. So phantom transactions, which is number 15 {D1/2/13},
that is a Horizon Issue 4.
Q. Yes. Does it say Horizon Issue 4 somewhere and I have
missed it?
MR JUSTICE FRASER: I think table 1.
MR DE GARR ROBINSON: I see. Yes.
MR JUSTICE FRASER: But you are right, it is not in the
column in the joint statement. Right, so that is
another one.
A. Yes. And branch account impact was noted on that.
Number 16 {D1/2/13}, reconciliation, is Horizon
Issue 4.
Q. You actually say -- in the bug table you say Issues 1, 4
and 5. So I should delete Issue 1, should I?
{D1/2/14}. I will do that.
A. Sorry, in the bug table?
MR JUSTICE FRASER: I don't want to be too pedantic,
Mr de Garr Robinson, but do remember it is a joint
statement. So far as Mr Coyne is concerned --
MR DE GARR ROBINSON: From your perspective --
MR JUSTICE FRASER: -- can number 1 come out in the column
against item 16?
MR DE GARR ROBINSON: Entirely fair, my Lord. Although
Dr Worden has never asserted that this is Issue 1
but ...
MR JUSTICE FRASER: As I said, I don't want to be too
pedantic, but at the moment it is a joint statement. It
might lead to a permanent and agreed deletion but for
the moment.
MR DE GARR ROBINSON: I hadn't thought of that.
A. Yes, I have noted reconciliation issues as Horizon
Issue 4.
MR JUSTICE FRASER: Okay. I will tell you what my number
is: it's 17, 21, 19, 15 and 16.
MR DE GARR ROBINSON: So there's another two to go. Is that
right? No, it's another four to go.
MR JUSTICE FRASER: Mr Coyne, number?
A. So Post & Go is number 4 -- sorry, is Horizon Issue 4.
That can come out.
MR JUSTICE FRASER: Can you give me the item number?
A. Number 19.
MR JUSTICE FRASER: You have given us that already.
A. Recovery failures, number 20 --
MR DE GARR ROBINSON: Right.
A. -- is a Horizon Issue 4. {D1/2/19} Transaction
correction issues is a Horizon Issue 4.
MR JUSTICE FRASER: Item number, please?
A. Sorry, 21.
MR DE GARR ROBINSON: I'm reminded that you indicated that
you got to 21 by treating one of these bugs as actually
counting as seven, is that right? The bugs, errors and
defects introduced by previously applied fixes, was that
right? Or did I misunderstand what you said?
A. There should be seven within that heading.
Q. Right. So does that mean we have to take a lot more
from the index of the bug table to get to the right
number?
MR JUSTICE FRASER: Mr de Garr Robinson, have you been
taking a note of the item numbers in the joint
statement?
MR DE GARR ROBINSON: I have been drawing circles around
them, my Lord.
MR JUSTICE FRASER: I'm just going to tell you what my
numbers are in case I'm wrong, and I'm putting these in
numerical order: 15, 16, 17, 19, 20 and 21. Does that
match your numbers?
MR DE GARR ROBINSON: Mine are 15, 16, 17, 19, 20, and 21.
My Lord, yes. So we are down to 24 bugs. There's
another three to go, is that right?
MR JUSTICE FRASER: I think 29 minus six, yes, 23.
MR DE GARR ROBINSON: Or possibly more if bug 22 is actually
seven.
MR JUSTICE FRASER: If we could for my purposes concentrate
on the 29 subtracting these, because the 29 are
individually set out.
So, Mr Coyne, we started with 29 and you have taken
six out. Mr de Garr Robinson would like to know what
the others are. Are you in a position to tell us?
A. I will certainly try, my Lord.
(Pause)
Just from that tally, my Lord, I have only got six
to take out of the list in here.
MR JUSTICE FRASER: Okay.
Over to you, Mr de Garr Robinson.
MR DE GARR ROBINSON: So we are at 23, are we, not 21?
A. Just going from the joint statement, from what I have
just done, yes.
Q. So how is it you arrived at 21 --
A. I have gone from the bottom up rather than the top down,
so --
Q. I presume you thought of little else during the luncheon
adjournment, which is why when you came back in you were
very quick to explain -- to correct the answer that you
had given his Lordship just before we broke.
A. Yes.
Q. So how is it that the position that you are adopting now
is inconsistent with the position that you were adopting
at 2.01 pm? Can you explain that?
A. What I did over the lunch is I have gone from my table
at page 12 of the joint statement and then added in
seven under the last one, that's how I have got the
number.
Q. When you say seven under the last one, I hesitate to
change the subject, but the bugs, errors and defects
introduced by previously applied PEAKs, which is the
last item on table 1 of your second report, that whole
section of your report only refers to two PEAKs. So how
is it that that section has somehow generated an extra
seven bugs? Could you explain that perhaps?
I'm so sorry, it is four PEAKs.
MR JUSTICE FRASER: I'm not sure -- you might just want to
re-consider that, Mr de Garr Robinson.
MR DE GARR ROBINSON: You are quite right. It is 1, 2, 3,
4 -- yes, it is four PEAKs. Between 3.211 and 3.219
four PEAKs are footnoted.
Would your Lordship let me confer?
MR JUSTICE FRASER: By all means. (Pause)
A. Sorry, what's just struck me about the ones at the tail
end, it could well be the case that these are inclusions
from Dr Worden.
MR DE GARR ROBINSON: Oh, I see. So it isn't the case that
these bugs introduced by fixes do explain another
seven --
A. Or Dr Worden wanted them included into this joint
statement.
Q. Let's just go back for a second and work out how many of
these bugs you say there is evidence to justify the
suggestion that there might have been a lasting
financial impact. You think there's such evidence with
the receipts and payments mismatch, number 1, yes?
A. Let me start again.
Q. Let's go from the front.
MR JUSTICE FRASER: Are we in the joint statement?
MR DE GARR ROBINSON: In the joint statement, yes. So you
think there is evidence for number 1?
A. Yes.
Q. You think there is evidence for Callendar Square?
A. Yes.
Q. This is evidence of a lasting impact, yes?
A. Yes.
Q. You think there is evidence for suspense account bug,
number 3?
A. Yes.
Q. Do you think there is evidence for lasting financial
impact for Dalmellington?
A. There was certainly evidence that not all branches were
resolved.
Q. So you include that as --
A. Yes.
Q. You think there's evidence of lasting financial impact.
Okay. What about remming in bug, number 5? Is there
evidence of lasting financial impact for that?
A. Yes.
Q. Remming out bug, 6/1?
A. Yes.
Q. Remming out bug, 6/2?
A. Yes.
Q. 7, local suspense issue?
A. Yes.
Q. 8, recovery issues?
A. Yes.
Q. 9, evidence of lasting financial impact for reversals?
A. Yes.
Q. 10, evidence of lasting financial impact data tree build
failure discrepancies?
A. Yes.
Q. 11, evidence of lasting impact Girobank discrepancies,
that we discussed this morning?
A. Yes.
Q. 12, counter replacement issues, evidence of lasting
impact?
A. Sorry, you using the word "lasting impact" now. I don't
know whether Post Office went on to make any later
corrections to sort out these discrepancies.
Q. I have sought to establish a degree with you on a number
of occasions now the difference between transient impact
that you think would have been caught by countermeasures
and lasting impact that would not have been caught by
countermeasures. That's what I'm getting at, Mr Coyne.
Because I think you agreed with me on at least one
occasion previously that it is the lasting impact bugs
that really have a material impact on robustness, or are
capable of having an impact on robustness. So that's
what I mean by lasting.
So counter replacement issues, you say there is
evidence of lasting impact?
A. Yes.
Q. 13, do you say there's evidence of lasting impact with
withdrawn stock discrepancies?
A. Yes.
Q. 14, do you say there is evidence of lasting impact with
bureau discrepancies?
A. Yes, I believe so.
Q. Okay. 15, I will let you look at your report.
A. Sorry. (Pause)
Yes.
Q. Okay?
A. Yes.
Q. 15 is out.
A. Yes.
Q. 16 is out. 17 is out.
A. Yes.
Q. 18, do you say there's evidence of lasting impact with
18, concurrent logins?
A. Yes.
Q. I'm interested that you should say that, Mr Coyne,
because if we could go back to your second report at
{D2/4.1/18}.
A. Yes.
Q. Look at the table and look at concurrent logins, for
"Evidence of Branch Impact" you say "No" there. Did you
change your mind?
A. After discussion with Dr Worden, yes.
Q. Okay. Then 19 is out. 20 is out. 21 is out.
What about 22? I infer from what you have already
said that you say there is evidence of lasting impact
for 22, yes?
A. Yes.
Q. And 23, evidence of lasting impact, do you say?
A. Yes.
Q. 24, wrong branch customer change displayed?
A. Yes.
Q. When you say "Yes", you mean evidence of lasting impact,
I should make that clear.
A. Yes.
Q. Then 25, Lyca top up, do you say evidence of lasting
impact for that?
A. Yes.
Q. At 26 do you say evidence of lasting impact on branch
accounts for the TPSC250 report?
A. Yes.
Q. And 27, TPS, do you say there's evidence of lasting
impact on branch accounts for TPS?
A. Yes.
Q. 28, Drop and Go, do you say there is evidence for
lasting impact for Drop and Go? {D1/2/25}
A. Yes.
Q. And 29, network banking bug, do you say there's evidence
of lasting impact for 29?
A. Sorry, I'm just checking the text on that. I have
actually got that down as the potential for bank account
discrepancies.
Q. So is your view that there isn't evidence of lasting
financial impact?
A. Yes.
Q. So that should come out, should it?
A. That should come out and that should be --
Q. That's network banking?
A. Yes.
Q. Very good. Thank you. So we have got from 29 I think
down to 22. Is that your final number?
A. Sorry, I'm still just reading the network banking one.
MR JUSTICE FRASER: While you just read that, are you
counting 6 as one or two, just out of interest, because
you went through it --
MR DE GARR ROBINSON: I'm counting it as one.
MR JUSTICE FRASER: Okay. Counting it as one.
MR DE GARR ROBINSON: I'm using the same numbering system
as --
MR JUSTICE FRASER: But it is just split between 6(a) and
6(b) --
MR DE GARR ROBINSON: I hadn't factored that in, my Lord.
A. Certainly with regard to network banking it is causing
potential for branch impact, but I haven't got evidence
of discrepancies.
Q. So it comes out?
A. Well -- no, it will be a Horizon Issue 4.
Q. Given that today all I'm talking about is Horizon
Issue 1, it is all I have got time to talk about and
I have barely got time to talk about that, and that's
not a criticism, by the way, it is just how things are
these days, we are down from 29 bugs to 22 bugs. Are
you now sure that that's the right number?
A. Yes.
Q. And I would like to ask you why is it you thought there
were 21 bugs at 2 o'clock, whereas you thought -- was it
14 bugs at 1 o'clock? 13 bugs at 1 o'clock.
A. Because I was just counting down the table at number 1
in my report. In the pressure of the situation I just
tallied that column down, I didn't have enough time to
consider it fully.
Q. To go back to a question I asked you earlier, where do
you make this clear in the joint statement?
A. In the heading next to the -- in the bug, error or
defect.
Q. And you are saying that the heading to the bug table,
which is "Table of Bugs/Errors/Defects with acknowledged
or disagreed evidence of financial impact", you say that
heading is sufficient to enable the reader to understand
that of the 29 bugs referred to, in fact we only need to
be concerned with 22 of them, yes?
A. Sorry, I'm talking about in the joint statement.
Q. Yes.
A. Yes.
Q. How is the reader supposed to divine from the heading
that Dr Worden was saying evidence for 12 bugs and you
were saying evidence for 22?
Dr Worden indicates his position in the body of the
joint statement but, as I said, in paragraph 1.15 and in
the bug table itself you appear to be indicating your
position that it was 29, and I would suggest to you,
Mr Coyne, that in that respect the joint statement was
seriously misleading. Why was that?
A. We didn't believe it was misleading when we put the
document together. I mean, it is always a negotiated
position to get the joint statements.
Q. As I say, Mr Coyne, everyone on this side of the court
is taken completely by surprise by the suggestion that
it is 22, not 29. Indeed I venture to suggest that the
claimants' own counsel are taken by surprise that it is
22, not 29. Now why is that?
A. I don't really see why that would be the case when, if
you read the text in the report, it explains what
particular Horizon Issue I'm attempting to deal with.
I know today you have chosen to go through Horizon
Issue 1, but in the report it attempts to deal with all
issues -- all technical issues that were put to me.
Q. Section 1 of the joint statement relates to Horizon
Issue 1, doesn't it?
A. Section 1 of the joint statement? (Pause)
Q. If you look at the joint statement there is the
introductory text, then there's the bug table.
Immediately after the bug table, which is at page --
there is a global agreement section, and then
immediately after that at page 27 there are a series of
propositions relating to Horizon Issue 1. {D1/2/27}
A. Yes.
Q. So section 1 of the joint statement talks about Horizon
Issue 1.
A. Yes.
Q. As I suggested to you, the natural interpretation of
what you say there in Horizon Issue 1, and in particular
paragraph 1.15 on page {D1/2/29}, is that Dr Worden was
saying 12 and you were saying 29 and I would venture to
suggest that everybody on both sides of the court
thought that was the position. How could that possibly
be the case? How can your own counsel, Mr Coyne, have
made that mistake?
MR JUSTICE FRASER: On the basis it is a joint statement,
Mr de Garr Robinson, I think you have to be quite
careful about how you put the question.
MR DE GARR ROBINSON: Could I ask you to go to bundle
{A/1/1}, please. This is the claimants' written
openings.
A. Yes.
Q. Could we go to page {A/1/7}, paragraph 9. It is said:
"The fact that further significant bugs have come to
light, in the way that they have, from the enquiries
that the experts have been able to undertake, is
significant ..."
If we skip down to (4), you will see it says:
"There are a number of further bugs identified so
far, which Post Office had neither admitted nor
volunteered: between 12 (Dr Worden) and 29 (Mr Coyne)
bugs with ..."
And there's a quote:
"... 'strong evidence of the bug causing a lasting
discrepancy in branch accounts'."
That's why I asked that question. How is it your
own counsel thought you were saying there were 29 bugs
with lasting effect if that wasn't the case?
A. It was a statement that was put in there to try and
frame that the number that we would probably ultimately
arrive at would be somewhere between those two
parameters.
Q. I presume, Mr Coyne, that you reviewed the claimants'
opening submissions either before or after they were
filed with the court, would that be right?
A. I'm not sure I did.
Q. Are you suggesting that you didn't read the claimants'
submissions before you came to give evidence today?
A. These are quite historic documents, are they?
Q. These were the submissions that the claimants filed with
the court at the beginning of the trial. It is the
opening submissions. I know you have considerable
expertise in giving expert evidence. The opening
statements of both parties were put into the judge so he
would have an understanding of the issues and where the
parties saw themselves standing. And I'm asking you
whether either before they were submitted, which would
be common, or afterwards you looked at the claimants'
opening submissions.
A. I don't believe I have, no.
Q. So what we have is ships sailing in opposite directions
in the night. You in your own mind thinking I have got
22 bugs. Counsel for the claimants thinking it is 29.
And no one ever discovering the truth until the judge
asked you a question at about 12.59 pm today.
A. My answer is I can't recall reading the openings.
Q. Some people might think that you have adjusted your
position in line with a position that you think it might
be easier to defend in cross-examination this afternoon.
What would you say to that suggestion?
A. That's not true.
MR DE GARR ROBINSON: My Lord, I wonder whether it would be
a convenient moment to break so that I could look at the
list and decide --
MR JUSTICE FRASER: What you are going to do.
MR DE GARR ROBINSON: -- what I'm going to do in the next 45
minutes allotted to me.
MR JUSTICE FRASER: By all means. 3.10 pm.
MR DE GARR ROBINSON: Thank you.
MR JUSTICE FRASER: Thank you very much.
(3.03 pm)
(A short break)
(3.10 pm)
MR DE GARR ROBINSON: Mr Coyne, I have got 35 minutes,
I have promised my learned friend that I will finish at
3.45, so I will start with some bugs and we will see how
far I get in that time.
The first one I want to take you to is obviously
a bug where you say there's evidence of lasting
financial impact and I will go to Dalmellington first of
all.
Could we first of all go to {F/1389/1}, please.
This is the PEAK that relates to Dalmellington and we
can see there is a call in on 13th October 2015. If we
go to the second box on the first page, just underneath
the "Incident Management" text, it says:
"Transfer note: Please can PEAK investigate this
discrepancy issue. NBSC has confirmed that following
discussions and checks with the user that this is not
a user error issue, but an issue within the system
requiring Fujitsu investigation."
Do you see that?
A. Yes.
Q. So that's when the penny dropped that it was not a user
error, it was a system problem?
A. Yes.
Q. If we move on to page {F/1389/5} of the PEAK. At the
bottom of the page Anne Chambers, who we have seen a lot
of, she says at 15 October at 15.56:
"We have found that if there is a logout before a
user has fully logged on, then subsequently a pouch is
remmed in manually (most likely at an outreach branch),
then after the rem in slip has been printed, the same
screen is redisplayed and the user is likely to press
Enter again and duplicate the remittance, possibly
several times. A different screen should be displayed
which would prevent this happening."
So something I put to you I think either Wednesday
or Thursday, and I think you may have not felt able to
agree with it, the nature of the Dalmellington bug is it
was a bug, if you want to call it a bug, which caused
a screen to come up after a rem in had been made, and
users thought that meant they had to press enter again
and so it caused them to make a human error?
A. Yes.
Q. So from the perspective of the outside world, it was
a bug which didn't itself cause a problem with branch
accounts, but it had an effect under which it could
cause subpostmasters to make a mistake which then would
have an impact on branch accounts, yes?
A. Well, they would be following the instructions that they
are given on screen.
Q. So what I'm suggesting to you, Mr Coyne, is that it
mimicked exactly what would happen if a human error was
made.
A. Yes.
Q. If someone remmed in the same thing to an outreach
branch twice by mistake it would look exactly like that?
A. Yes.
Q. So from an outsider's perspective you would not be able
to tell the difference between someone remming in twice
by accident, because they are incompetent, and someone
remming in twice because they had been given a screen
which has made them do it. From an outsider's
perspective, like Fujitsu, it would seem exactly like
a human error, wouldn't it?
A. It would until you looked at the very detailed logs,
because when they did do that they discovered what the
problem was.
Q. If we go back to the text:
"A rem in slip is printed each time, showing the
same details but different session numbers, and a
transaction log search confirms the repeated rems."
So what Anne Chambers is saying there is if you are
the postmaster doing it, you get more than one receipt,
you get more than one session number, you get pieces of
paper and indeed logs which makes it clear that you have
remmed in things more than once. You would see it
fairly quickly, wouldn't you?
A. There's certainly something printed, yes.
Q. Then Ms Chambers says:
"This is not an area that has changed for several
years so it likely to have happened before but we have
no record of it having been reported to us. I can only
check back two months; I've found 4 other instances
(outreach branches 214869, 106444, 110444, 207828) and
all but the last removed the discrepancy by completing a
rem out for the excess, which corrected the system cash
holding branch 224843 may be able to do the same but
NBSC should advise on this.
"We are continuing to investigate the problem ..."
A. Yes.
Q. So it would be right, wouldn't it, that often it would
be obvious to the postmaster that he or she has remmed
in the same thing more than once, and where it is
obvious to the postmaster he or she will be able to rem
the amount out to correct for the error. In other words
it is possible, and indeed would often have happened,
that postmasters would have been able first of all to
identify the problem and, secondly, to exercise self
help to fix it, yes?
A. Certainly a number of them did do that, yes, and that's
reported later.
Q. And the simple fact is that where the Dalmellington bug
caused double rems in, the fact that the same thing had
been remmed in twice would always be visible in the logs
and receipts and other information available to the
postmaster, yes?
A. Yes, if you was to review the detail then typically that
information will be in there, yes.
Q. And if you ran a trial balance for example or a report
on the outreach branch, you would immediately see that
there was a discrepancy and you would immediately see
the amount of the discrepancy is the amount of the
double rem in, yes?
A. No, I do not think it is as simple as that because
typically with trial balances you might have a small
discrepancy one way or the other anyway, so seeing
an extra round £100 would often not be the case.
Q. Why do you say that, Mr Coyne? That seems to me to be
conjecture. Do you have any basis for saying that?
A. Well, a lot of subpostmasters that you see do have small
discrepancies one way or the other.
Q. But when you rem in amounts you wouldn't usually rem in
£3.96, you would be remming in a round sum. That is how
it tends to works.
A. That's exactly my point. If you have already a small
discrepancy of £3.96 on there and then you rem in £100,
what you suggested before is that you would see £100
that was out -- or you wouldn't see £100 that was out,
you --
Q. What I'd suggest to you, Mr Coyne, is you would see the
outreach branch is £97 out and you would try and
understand why that should be and you would see that the
branch has received twice as much as you expected it to
receive. It would not be one of the more difficult
problems to see in the logs and given that also you are
given several receipts, would it?
A. I don't believe it would be as simple as that. I do
agree it is possible to spot it, but reconciliation in
my experience typically isn't as simple as you suggest
there.
Q. Where there are these remming in and remming out
problems they produce receipts and payment mismatches,
don't they?
A. Yes.
Q. And I think we have already agreed that receipts and
payments mismatches are automatically reported through
to Fujitsu, aren't they?
A. Well, it would come up at the monthly -- or it's likely
to come up at the monthly balancing. I don't know
whether it would come up with the receipts and payments
mismatch because it's --
Q. I don't have time to go into the technicalities.
A. Sorry.
Q. And I'm not criticising you for trying to answer
carefully and accurately, I'm really not, but bearing in
mind the time it is sufficient for my purposes if you
will agree with me, as I think you will, that whether on
the day or by the end of the relevant transaction period
there will be an automatic report that is remitted to
Fujitsu, is that right?
A. If not Fujitsu, that will be available in branch.
Q. Not just in branch but also it would automatically go to
Fujitsu, wouldn't it?
A. That is the bit that I'm unsure about, whether in this
scenario it would go automatically to Fujitsu.
Q. Let's look at what happened. If we can go to
{F/1415/1}, please. This is a presentation that was
made by Fujitsu to Post Office after Anne Chambers had
realised that this bug existed.
A. Yes.
Q. It is dated 10th December 2015. Now, so far as we are
aware, the Dalmellington bug affected outreach branches,
didn't it?
A. Yes.
Q. And the SSC reviewed logs to identify where similar
scenarios could have occurred, yes?
A. Yes.
Q. And they did this by identifying duplicate remittances
of unique pouch bar codes, correct?
A. Yes.
Q. The reason they did that was because a branch can't use
the same barcode twice in the same rem in session but it
is possible to use the same barcode in separate
sessions, correct?
A. Right, yes.
Q. And they did this by gathering all the BLE files?
A. Yes.
Q. And the BLE files are the branch data files, data
transfer files sent daily from Horizon to POLSAP?
A. To POLSAP, yes.
Q. Thank you. They checked the BLE files looking for
symptoms of the issue?
A. Yes.
Q. And we can see at page {F/1415/3} that the SSC have
identified 112 occurrences, do you see that?
A. Yes.
Q. So an audit found 112 occurrences over the past five
years, and it would be five years over which this
problem would have operated, correct?
A. Yes.
Q. Then if we move on to the third bullet point, it says:
"108 items were corrected at the time either by:
"Transaction correction by Post Office."
Or by the:
"SPS reversal completed at the time."
A. Yes.
Q. Would you agree with me that what that shows is that
even before the Dalmellington bug was discovered to be
a bug, so even at a time when it was thought it was
inexplicable to human error, in the overwhelming
majority of cases -- in fact in all of the cases that
had been looked at at that time, because they had only
looked at 108, yes? There were four items still to be
confirmed. Do you see that?
A. Yes.
Q. So with all of the occasions that they had looked at one
of two things had happened. Either the SPM had
exercised self help and just fixed it himself or herself
because it was quite easy to do that?
A. Yes.
Q. Or Post Office had issued a transaction correction
because the information about the mismatch would have
got through to the Post Office or perhaps a postmaster
might have phoned in. One way or another, the
information would have got through to Post Office and it
is Post Office's practice to fix errors of that sort by
sending an appropriate transaction correction, yes?
A. Yes.
Q. So would you agree with me that putting those four
branches that hadn't been looked at to one side, and
I want to be absolutely clear about this, I know you
don't want to and we will talk about them, but laying
those to one side, the first 108 branches that they
looked at, the countermeasures in operation in and
around Horizon had caught them all and fixed their
consequences, correct?
A. Yes.
Q. So subject to the four branches that hadn't been looked
at, the countermeasures had 100% success rate, would you
agree?
A. Yes.
Q. So would you agree with me that it is fair to say that
this analysis shows that the relevant countermeasures in
operation here worked very well, yes?
A. We wouldn't know how well they worked without trying to
understand the amount of time between the fault
occurring and its resolution.
Q. Are you suggesting that there is any reason to think
that when an SPM exercises self help, he or she would
only have done it after a considerable time?
A. No, I'm saying we don't know. The evidence isn't there
either way.
Q. So why are you even raising that with me? What's the
relevance of the point you are making?
A. Because you ask me: does it show that the
countermeasures worked well or not?
Q. And you are hypothesising that there might have been
a delay between the problem occurring and the problem
being made good, is that what you are saying?
A. There may have been, and that would help me answer
whether the countermeasures worked well or not.
Q. Do you have any reason to think that there would have
been a delay in this kind of case? Let's take it in
stages. First of all, an SPM exercising self help. Do
you have any reason to think that an SPM would have
delayed in doing that, or do you think it is more likely
that the SPM would have spotted the error quite quickly
and fixed it straightaway when it was fresh in his mind?
A. They would certainly endeavour to fix it as quick as
they had spotted what the issue was.
Q. Do you think there's any reasonable likelihood of the
issue not being fixed within the trading period in which
the error actually arose?
A. It would really depend on how good the SPM is at working
out what has gone wrong from the information that he has
got in front of him.
Q. I suggest to you, Mr Coyne, that it is plain as
a pikestaff -- that's a phrase that lawyers are far too
fond of and I have just used it and I'm really cross --
but it is obvious, isn't it, that the last -- in the
real world if a postmaster hasn't actually spotted the
problem before he balances, before he rolls over, when
he rolls over that's the point at which it is going to
come out and that's the point at which he is going to
exercise self help, wouldn't you accept that?
A. Yes, but at that point in time it could be some time
after the event and there could be quite a lot of data
to consider where the problem is.
Q. Well, here's the interesting thing. We actually have
evidence. We know what happened and we know that the
SPMs were all made good. I think you are suggesting
that delay may cause a state of affairs which ends up
with the SPM not getting the right resolution, but we
know that in relation to the Dalmellington bug that that
isn't what happened. We know that the SPMs were made
good.
So could I suggest to you that you are seeking to
identify problems that are far more theoretical than
real and that in the real world we know that SPMs were
made good?
A. Yes, I accept they are made good. I only introduced
delay when you put to me that the countermeasures worked
well. That was the point in time that I questioned
about the amount of time.
Q. Let me put it a different way. They worked in a way
that ensured that the financial impact of the problem
wasn't lasting.
A. I mean the financial impact was resolved but we don't
know when, I don't know whether it was seven days or 14
days or what it was.
Q. Do you accept that of the 108 items that had been
identified -- or, rather, that had been investigated at
that stage, the evidence shows that the losses caused by
Dalmellington in none of those cases were those losses
lasting, do you accept that?
A. Outwith the four that we're not aware of at this stage.
Q. Do I have to make that clear again? Haven't I made it
clear already that I'm not going to come to those until
we have finished with the 108?
A. Okay.
Q. And of the 108 that were looked at, do you accept that
in 100% of those cases the countermeasures prevented any
lasting loss from being suffered?
A. Yes.
Q. Thank you. Now let's look at the four that were still
to be confirmed. We know that Mrs Van Den Bogard asked
her team to examine what would happen with those
branches, or at least -- in fact we should explain what
the branches were. If I could pick it up -- I'm so
sorry, Mr Coyne. (Pause)
There is a page which identifies them and I'm now
struggling to find it. Could you give me a moment?
MR JUSTICE FRASER: Are you looking in the Fujitsu
presentation?
MR DE GARR ROBINSON: Yes. It is the page which indicates
that the amounts of the four -- I'm terribly sorry not
to have that page at my fingertips.
MR JUSTICE FRASER: Don't worry.
MR DE GARR ROBINSON: I'm so sorry, my Lord. It is one of
those occasions where you know that something is in the
document ... Here we are, it is page {F/1415/8}. I do
apologise to everyone concerned.
"Detailed Preliminary Findings", do you see that?
A. Yes.
Q. 2011, six incidents. 2012, nine. 2013, seven.
By the way, stopping here, you've seen the
methodology that was adopted to identify the branches
that were affected by this issue?
A. Yes.
Q. You don't have any objections to or concerns about that
methodology, do you?
A. No.
Q. Thank you. It would have been relatively easy for
Fujitsu to identify all the affected branches in the
last five years, would you agree?
A. Once they discovered it was an issue, that they worked
out what the profile of the issue was and, as you
explained, they then looked back to the historic files,
yes.
Q. Thank you. Then 2013, seven incidents:
"4 transaction correction completed by POL.
"1 corresponding remittance transaction completed by
PMs.
"2 unknown outcomes FAD 157242 - value £25,000 ..."
That's quite a lot.
"... and FAD 209311 - value £2,500."
Then if we go forward to page {F/1415/9}, 2014, nine
incidents. And the third item under 2014:
"1 unknown outcome FAD 214420 - value £0.01.
I now need to find -- oh, and if we go back to page
{F/1415/8} -- I'm really not covering myself in glory
here -- 2012, nine incidents. The third item:
"1 unknown outcome FAD 120004 - value £1.00."
So we have four branches that hadn't been
investigated at that stage. One had a thumping loss --
or value, I should say, because it wasn't a loss as we
both know, of £25,000. Another one which had a value of
£2,500, and then a third one with a value of £1 and
a fourth one with a value of 1 penny. And steps were
taken to find out about the two big branches, yes?
A. Yes.
Q. If we can go forward to {F/1427.1/1}, please. This was
a subsequent report which was produced as a result of
a request by Mrs Van Den Bogard. We can take it very
quickly. There is a slow way of taking it but
I suspect -- are you familiar with this document now?
A. Is there a title page for it or does it start with this?
MR GREEN: For context, it was disclosed on 4th March this
year.
MR DE GARR ROBINSON: That's very helpful of my learned
friend. It really is useful to know that.
This is a report that was produced by Fujitsu for
Post Office.
A. Right.
Q. And I take it you have read this document. I apprehend
from a discussion we had the other day that you have
read this document?
A. I'm not sure. Has it got a title page? Is that where
it starts?
Q. That's where this document starts, yes.
A. Right, okay.
Q. So "Outreach Branch Issue - Report on Findings":
"Summary:
"As part of the investigation into the issue known
as the branch outreach issue' an audit of the BLE files
was undertaken by Fujitsu. The detailed preliminary
findings were then shared with Post Office. Fujitsu
reported that there were 112 occurrences of Duplicate
Pouch IDs over the past five years where branches could
have been impacted.
"Fujitsu have clarified that their investigations
into duplicate pouches were intended to find instances
when a system issue had resulted in duplication."
The third bullet point reads:
"They have further clarified that the search of the
BLE files entailed looking for any duplicate pouch for
the same day/branch/amount. This is the only reason
that branch 209311 and branch 157242 have been looked at
in detail. There is no indication of any system issue,
or any impact on the branch accounts in these two
branches."
Do you see that?
A. Right.
Q. So whatever happened in those two branches there was no
net impact, there was no discrepancy caused in the
branch. Do you see that?
A. Right, because it was made good.
Q. Well, no. If we go forward:
"Fujitsu have confirmed that this is not an outreach
issue and this correlates with Post Office findings that
neither of these branches operates outreach services.
Fundamentally, in respect of branch 209311 and branch
157242 the remittance transactions were completed on
different counters [while] in the case of the outreach
branch issue, duplicate transactions take place on the
same counter."
Do you see that?
A. Yes.
Q. Then if we go over the page to page {F/1427.1/2}.
A. Sorry, can I read the last bullet point on page 1,
please? {F/1427.1/1}
Q. Sorry. Of course, please do.
(Pause)
A. Right, I see.
Q. So what happened with these two branches is that they
showed the same symptoms because the same pouch number
was remmed in but it wasn't because the machine caused
you to rem the same pouch twice, it was because one
machine remmed it in properly using the barcode and then
for some reason a human being operating on a different
counter remmed it in manually. He or she wouldn't have
been able to do it by using the barcode because the
system would have prevented it, but it is possible if
you type in the numbers manually to do it twice, and it
appears, remarkably, that in both of those branches that
mistake was made.
A. Right.
Q. Do you see? If we go over the page to page
{F/1427.1/2}, second bullet point down:
"Post Office concludes the issues at the branches
have arisen as a result of remittances pouches received
at the branch entered manually which had the same
barcode id. Thus creating duplicate entries which
Fujitsu highlighted as part of the BLE files checks.
However, in these instances from the available evidence
Post Office concludes that the correct amount of pouches
were delivered, accepted and entered on Horizon. This
is supported by the fact that there has been no negative
impact in the branch accounts and no record of an issue
raised by the branches with post Office.
Do you see that?
A. Right.
Q. If one goes over -- there are then conclusions
articulated in each case. So with the first case, if we
go to page {F/1427.1/10}, under the heading
"Conclusion", the first bullet point:
"All transactions were undertaken on 1 March 2013
and within an hour between the first and final entry. It
is assumed, based on the sequence of events that the
branch understood an error was made and took action to
rectify by recording a remittance surplus and
subsequently redeeming the surplus, leaving the branch
in balance."
Do you see that?
A. Yes.
Q. Then if one moves forward to page {F/1427.1/12}, again
under the heading "Conclusion":
"Post Office can conclude that although there has
been a duplicate pouch id recorded this is not related
to the known 'outreach issue' but as a result of a
manual entry of a remittance in. Fundamentally, the
transactions were undertaken on separate tills and the
branch does not offer outreach services.
"Based on the available evidence and absence of any
shortages impacting on the branch accounts, Post Office
concludes that the branch did receive two pouches
containing £25,000.00 with the same barcode together
with three further pouches on 18 February 2013."
Then there is a reference to a £49,500 figure which
was also -- the branch accounts also show.
So you will see that in relation to the two extra
branches that appeared to have significant values, it
wasn't -- neither of them was actually an instance of
the Dalmellington bug, do you see that?
A. Yes.
Q. Do you accept that?
A. This is what the investigation tells, so yes.
Q. And you have no reason to think that the investigation
was wrong, do you?
A. No.
Q. So that leaves the two branches, one branch which
suffered £1 loss -- I'm saying loss, that's quite the
wrong word. One branch where there was a £1 value and
one branch where there was a penny value. Now Mr Coyne
it is quite right to say, and you are entitled to say,
that there has been no investigation about those two
branches and those two amounts of money, but bearing in
mind the evidence that you have seen, in particular
bearing in mind that when they looked at 108 branches
they found that all of them, whether by way of self help
or by way of a TC, had been made good. What do you
think the chances are that those two branches were not
made good?
A. Very small.
MR DE GARR ROBINSON: Thank you. My Lord, I see it is
3.40 pm. If I started another subject I would not be
able to finish it.
MR JUSTICE FRASER: I do not think anyone will hold the 4
minutes against you. So that is the end of your
cross-examination?
MR DE GARR ROBINSON: My Lord, that concludes my
cross-examination.
MR JUSTICE FRASER: Thank you very much.
Right, Mr Green.
Re-examination by MR GREEN
MR GREEN: Now, Mr Coyne, can we please look first at
paragraph 3.128 of your second report which is
{D2/4.1/51}.
A. Yes.
Q. And you will remember, if we go back to the previous
page {D2/4.1/50}.
A. Yes.
Q. This was a section of your report that you were asked
about quite a lot?
A. Yes.
Q. And if we go forward again {D2/4.1/51}, you were asked
about paragraph 3.128 several times.
A. Yes.
Q. You were only taken to the first half of that paragraph.
A. Yes.
Q. In the last clause of that paragraph you say:
" ... and illustrate, by their interlinking natures,
the complexities of the PEAKs/KELs."
What did you mean by that?
A. In that they share a reference to a particular KEL, so
often you will see a different number of PEAKs referring
to one KEL and that would suggest that there has been
a number of occurrences of the same defect.
Q. Thank you very much. You were also asked in
cross-examination about the Ernst & Young reports.
A. Yes.
Q. Can we just bring up the transcript from Day 16 at
page 173, first of all. If you look at line 20, you
were being asked about monitoring basically user
privileges, do you remember? {Day16/173:20}
A. Yes.
Q. You were being criticised for saying nothing had been
done about user privileges?
A. Yes.
Q. It was just an interesting answer at the bottom of the
page there. You say at line 23:
"Answer: Well, nothing got done or got improved
over it and we can see that from the PEAK where Fujitsu
are trying to address --"
A. Yes.
Q. Can we just take this in stages. First of all, can we
go to the Ernst & Young report itself, please, which is
at {F/869/1}. That is the management letter for the
year ended 27th March 2011. If we go forward to page
{F/869/2}, please, that's the letter itself.
A. Yes.
Q. Explaining the work, if you look at the second
paragraph, second line:
"This work is not primarily directed towards the
discovery of weaknesses ...."
A. Yes.
Q. Then on the third page {F/869/3} we can see the part you
referred to in the bottom half of that page?
A. Yes.
Q. Could we now go forward, please, to the reference to --
you were taken to pages {F/869/25} and {F/869/27} of it.
Can we have a look, please, at page {F/869/30}.
A. Yes.
Q. Now, you will see there the heading "HNG-X".
A. Yes.
Q. That's Horizon?
A. Horizon Online, yes.
Q. It is common ground. Did you look at this part?
A. Yes, I did. So the auditors seek to take a sample of
a number of changes that have been made to the system,
so they looked at ten changes to the counter and five
manual changes, and what they report here, that of those
changes there is no record of those changes being
retained -- there's no records available.
Q. Right. I won't go further in relation to the control
environment for changes because you have received
a partial apology for that this morning.
A. Yes.
Q. But if we can look at permission controls on page
{F/869/33}. Again under "HNG-X", which is Horizon?
A. Yes.
Q. "There are inappropriate system privileges assigned to
the APPSUP role and SYSTEM_MANAGER role at the Oracle
database level ...
"There is inappropriate privileged access at the
oracle database level ... System privileges assigned to
the APPSUP role and OPS$TPS account are inappropriate
..."
And so forth.
A. Yes.
Q. That actually continues on, doesn't it?
A. Yes, it is telling us that the auditor found that there
was a number of very powerful roles that were available
that would provide you access to the Horizon database
for both reading and writing to the database and it was
inappropriate.
Q. We see that all the way through to page {F/869/36}?
A. Yes.
Q. And then if we look at page {F/869/39}. Just below
"HNGX" again:
"The “Change of Access to Live Network” form for the
modified user selected for our Walkthrough was not
authorised by a line manager ..."
A. Yes.
Q. So that is a slightly different point. Then at
{F/869/40} over the page, top bullet point:
"Three instances of additional access being granted
to a user without supporting evidence.
"Inappropriate access to the pathways active
directory [and so forth]."
So there is a variety of points which --
A. It is generally very poor control of user privileges,
potentially incorrect privileges being applied to
certain groups of users.
Q. Okay. Now to be fair, go back to page {F/869/33} very
kindly. There is a "Management Comment" that they will
review adequacy and regularity of controls?
A. Yes.
Q. On the face of it, all might be absolutely fine. You
referred in your evidence in the transcript, the part
I just took you to, to a PEAK?
A. Yes.
Q. But you weren't taken to any PEAK.
A. That is right.
Q. Can we look at {F/768/1} please. This is the PEAK
that's come up before in the proceedings, off piste and
so forth.
A. Yes.
Q. Can we take it through, was this the PEAK you were
referring to?
A. Yes, I believe it was. Can we just look at page 2 of
that? I mean what is -- I mean the heading on there is
that the SSC users have more access than is required to
the database resources and this is contrary to
a security policy.
Q. And that had been updated in May 2015?
A. Yes.
Q. And there are several places, we can see here if you
look in the yellow box at the bottom. (Pause).
Item 4:
"Scope: No actual impact/incidents of problems
relating to this issue have been experienced yet (and
not expected)."
That's what they recorded themselves?
A. That is right, yes.
Q. My learned friend asked me to read that out. While we
are there. 2:
"Cost. There is currently no cost though to this
issue."
A. That is correct.
Q. "Perceived Impact: The customer is not aware of this
problem or change."
So Post Office didn't seem to be aware, on the face
of that, while we are reading out those headings, that
they weren't aware of all this going on?
A. No, that is right.
Q. We can take it reasonably shortly, if we may. In the
yellow box at the bottom, effectively what I hope --
this appears to be common ground on the face of the
document, let me try and summarise it. There was
an issue of user creation scripts provided by
development which offered the option to create each user
type. We can see that at (1) in the yellow box?
A. Yes.
Q. Effectively there had been some things created for SSC
users but SSC users still wanted to have APPSUP access?
A. Yes.
Q. And that was the conflict they are trying to resolve?
A. APPSUP appears to be a group and that group provides
a significant amount of privileges and the SSC users are
in that group.
Q. When we look over the page at page {F/768/2} we have the
bit with Anne Chambers halfway down. She is talking
about two different sorts of scripts and says:
"When we go off piste we use APPSUP, can we have
both?"
MR JUSTICE FRASER: Where are you reading?
MR GREEN: Halfway down the page, my Lord, in the yellow
box.
MR JUSTICE FRASER: Yes.
MR GREEN: The point about APPSUP is made in various places
but it is an extremely powerful tool, isn't it?
A. Yes, it could be described as a super user privilege.
Q. If we go to page {F/768/3} please. There is quite a lot
of arguing about what the nature and purpose of the PEAK
is and so forth.
We can see at the third yellow one down,
16th August 2011, 10.08.07:
"The optional role 'APPSUP' is extremely powerful.
The original BRDB design was that 3rd line support
should be given the 'SSC' role ~...and only given the
optional role 'APPSUP' temporarily (by Security Ops
authorisation) if required to make emergency amendments
in BRDB Live. Since then Host-Dev have delivered a
series of auditable amendment tools for known SSC data
amendment operations in Live, and these are assigned by
role to individual SSC user accounts. As such SSC should
not require the APPSUP role in BRDB, unless there is an
unforeseen update required to Live. [etc]."
A. Yes.
Q. Then there is a difference of view from Mr Simpkins
below. If we go down to the bottom we can see there is
quite a lot of detail there and again it is reiterated
that it is extremely powerful in the bottom yellow box:
"Should only be used under extreme circumstances
assist and under MSC supervision... As such the Branch
Database design was that..."
That is all repeated then. Then if we come down to
just under the repeat, do you see about eight lines up
from the bottom:
"It is a security breach if any user write access is
not audited on branch database."
A. That is right.
Q. Then it says:
"... hence the emergency MSC for any APPSUP role
activity = must have session logs attached under the
MSC."
A. Yes, that's the blanket MSC that allows access to
Fujitsu to conduct emergencies pre-approved.
Q. In the event, can we just go to the end, almost the end
on page {F/768/7}. Do you remember that the new people
had not been given APPSUP?
A. Yes.
Q. But the old APPSUP privileges --
A. Weren't taken away, yes.
Q. Is that what you had in mind when you referred to the
PEAK in your cross-examination?
A. That was absolutely the PEAK, yes.
Q. While we are on MSCs, you mentioned in your evidence
that MSCs presented a bit of a challenge?
A. Yes.
Q. When you got them. And you I think referred to that in
your witness statement as well?
A. Yes.
Q. Could we bring up please {F/1844/1} the MSC complete
data spreadsheet. You have explained in your witness
statement it is one of three separate Excel
spreadsheets?
A. That is right.
Q. Which you have to use together?
A. Yes. So it would appear that the MSC database was
a singular database with all the data in it but the way
that it has been provided to us, it would appear that it
has been split into three different Excel spreadsheets
but there's no easy way to try and interrogate across
the three spreadsheets. They aren't all the same
length, so you can't put them together.
One has lots of columns going across and the other
one has literally hundreds of thousands of columns going
down. So it is practically impossible to use for the
purposes of analysis.
Q. Let's just have a look. That's the sort of document --
one of the three documents you have to cross refer to
each other?
A. This is the header document and from there you have to
go to read the detail about it, yes.
Q. Could we go please to row 15024.
A. Yes.
Q. Let's go down to the bottom, just look there.
"MSC emergency master change to cover any essential
SSC adhoc works."
A. Yes. This is the pre-approved MSC. So that if anything
comes up as an emergency, you don't have to effectively
go through the MSC approval process again. It is
pre-approved.
Q. Could we now please look at {F/1834.14/1} please. While
that's coming, did you find these easy to work with?
A. No, they are terrible to work with. I am sure they
could have been provided to us in a database that we
could interrogate rather than being exported to
essentially text files or Excel.
Q. Were they small Excel files or quite big ones?
A. No, they are huge. I don't know precisely what the
numbers are but in megabytes terms they are quite high
and they are hundreds of thousands of lines.
Q. If we look at the document we are now seeing, this is
one of the MSCs produced by Womble's for the trial.
This was actually uploaded on Friday.
A. Yes.
Q. Were you given any -- on 31st May -- MSCs in this form
before the trial started?
A. No, it might well be the case that some of this text
that appears on here might have been found within the
Excel spreadsheets. Certainly not in this format, no.
Q. That's helpful, thank you. Sorry, one more reference if
we can. Can we look quickly at {C5/16/1}. This is
an email from you, on 20 July 2018 to Freeths and
Womble's, copying in Dr Worden.
"Information requests following the first day
looking at PEAKs/Tfs"?
A. Yes.
Q. You say:
"During the first day spent at Fujitsu looking at
the TfS and PEAK systems, both Dr Warden and I noted
information that would be helpful in the drafting of our
respective reports."
A. Yes.
Q. "Whilst the request for some items of information on the
below list may be supported by Dr Worden, I have been
unsuccessful in gaining agreement ..."
Then you mention PEAKs and various other things?
A. Yes.
Q. And at the bottom MSCs, OCRs and OCPs?
A. Yes.
Q. Why did you think those might be useful to see at that
period?
A. Because I thought that they may indicate what changes
had been made to branch accounts or the databases.
Q. Now, yesterday, on Day 16, you were cross-examined
about -- let's have a look please, Day 16 in the
transcript, page 22.
We will look at line 18 {Day16/22:18}, if we may.
It is the bit about the claimant FAD codes. It says:
"Question: And both you and Dr Worden are aware of
the FAD codes that relate to a very helpful sample in
the context of this case, aren't you, which is the FAD
codes of the claimants in these proceedings, yes?"
Then you say:
"Answer: Yes. In one of my early requests for
information the response that I was given is that
I shouldn't be requesting any information that makes any
attempt to identify particular claimant
characteristics."
Then you are met with:
"Question: Mr Coyne, I really don't think you
should be suggesting that Post Office were telling you
not to look at that group as a group. We could have
a discussion about it if you want, but could I caution
you against making that claim because that wouldn't be
an entirely accurate way of characterising what
happened, would it?"
You say:
"Answer: Can we go to the RFI and have a look?"
And you are met with:
"Question: Let's to do it after a break, shall we?"
A. Yes.
Q. You weren't shown the RFI.
A. No.
Q. Can we look please at {C5/21/5}. Thank you very much.
If we look at paragraph 1.3 there.
A. Yes.
Q. You will see you are asking about a document where
there's documentation which might detail any specific
branches that were affected.
A. Yes.
Q. That refers to {F/238/1}. And there is a sort of
standard answer at the top about the technical documents
and: Mr Coyne, Post Office is in no better position to
search the documents.
A. Yes.
Q. And then underneath that, at the bottom four lines:
"It also appears to be an attempt to obtain
documents containing information that could potentially
be tied to individual cases. That is not the purpose of
the Horizon trial."
MR JUSTICE FRASER: You have gone onto the next page.
MR GREEN: Yes, sorry, if you could go on to the next page
{C5/21/6}. Was that what you had in mind?
A. That's exactly -- and I think that's repeated in another
part of the RFI as well.
Q. Let's look at 1.5 on the next page {C5/21/7} please.
This was the Golden Gate replication issue?
A. Yes.
Q. In relation to dix Oracle being aborted and resulting
in a number of branches reporting, over the page, cash
declaration ... Go over the page very kindly. {C5/21/8}.
Stock reporting discrepancies.
A. Yes.
Q. "Were any transaction corrections sent to the 247
affected branches as a result of the discrepancies and
which branches were affected by the incident?"
A. Yes, this was an attempt for me to go from the
information that I see within the PEAK, talking about
discrepancies, to see whether they were made good by
Post Office.
Q. Whether or not they were made good in the end. It is
the bottom paragraph on that second page:
"It also appears to be an attempt to obtain
documents containing information that could potentially
be tied to individual cases. That is not the purpose of
the Horizon issues trial."
A. Again in the end column that's repeated as well.
Q. Yes. Remains of that view, right-hand side. Then if we
can go forward, I'm sorry to be taking this at some
pace, Mr Coyne.
A. It is all right.
Q. {C5/22/1} if we can. On page {C5/22/2} of that
document, which is the response to the email, if we look
in (vi) you are asking for:
"PEAK and/or TfS records for any claimant who has a
record including any audit data for the period (at least
a month) ... Post Office objects to this request.
Mr Coyne is seeking documents relevant to specific
claimants but the Horizon Issues trial will not be
considering the circumstances of individual claimants.
Post Office's solicitors requested an explanation for
this in a letter ... but no response has been received."
Yes?
A. Yes.
Q. Then they say this information hasn't been pooled or
collated and it would be necessary to carry out a review
which they say is disproportionate.
A. Yes.
Q. Do you feel that you should be cautioned from saying
what you said yesterday?
A. Not at all. No. I mean that data would have been very
pertinent to the instruction that we had been given.
Q. Can we move forward to something you were asked to do
and let's look at {F/78.1/1}, please. You were asked to
do some homework specifically and to identify some
PEAKs?
A. Yes.
Q. You identified PEAKs at 78.1, 123.21, 198.2, 271, 338,
345.1, 414.1 and 1115.1 all in bundle F?
A. Yes.
Q. I'm not going to take you to all of them.
A. Right.
Q. Can we just choose one or perhaps two. Let's look at
{F/338/1}, please. That is PEAK number PC0133933 and
you can see this is around March 2006.
A. Yes.
Q. On page 2 of that PEAK {F/338/2}, you can see there are
two reasonably large yellow boxes?
A. Yes.
Q. One halfway down, one three-quarters of the way down?
A. Yes.
Q. And you can see what the PEAK problem was referring to?
A. Yes.
Q. Yes? And then at the bottom of that box:
"I believe this PEAK should therefore be transferred
to Escher-Dev, so this PEAK is being routed to QFP for
their consideration."
Escher were developers for Riposte?
A. That is right.
Q. If you look at the bottom yellow box, 6th April 2006,
14.07:
"This may be a 'well known problem' but this does
not mean it is worth chucking over the fence to Escher!
We need to give them a reasonably high probability
scenario in which the problem arises. If it is only
a tiny percentage or fraction of daily transactions then
they can hardly be expected to investigate it with no
further evidence. Gareth Jenkins confirms that this
logic has been applied all along."
Then if we now go please to {F/414.1/1}. If we
could look please at page {F/414.1/9}. Do you see there
in the bottom -- middle yellow box --
A. Yes.
Q. -- it talks about:
"A possible alternative to the one suggested above
by Mark Scardifield (replacing the Notify timer with an
independent one) would be to tidy up (one-line code
change) NBFramework so that it does not loop when it
times out a component. Then we could be justified in
reducing the configured timeout period for
NBRequestReply from the present ten minutes to say one
minute.
"However this timeout is still rather 'brutal' and
does not provide for any recovery actions such as
resetting the PIN pad or suggesting that the Clerk tells
the customer to retrieve their ICC card. This clumsiness
may be acceptable for a rare occurrence; it can easily
be worked around and the PIN pad can be reset by
subsequent actions.
"However it is not clear whether the transaction
recovery is really adequate in this circumstance. This
could be investigated ..."
Then at the bottom:
"BTW it is not understood in EPOSS Dev why this
whole problem appears only with Banking transactions.
Surely the whole Riposte and comms path is
identical ..."
Do you see that?
A. Yes.
Q. If we go over the page {F/414.1/10}, we can see at the
top of the page, do you see if you come four lines down:
"For 145617 I accept that we are unlikely to get
a fix from Escher, and even if we got one, we are
unlikely to implement it."
A. Yes.
Q. Do you see that?
A. Yes.
Q. Now, this also makes a reference to cost benefit in this
PEAK as well. Now, these were the PEAKs that you found?
A. Yes.
Q. Did they undermine what you felt about the relevance of
cost benefit approach?
A. No.
Q. You were also asked questions about the Riposte message
searching?
A. Yes.
Q. And you mentioned that you had come across Riposte
import which had been helpful to search for?
A. That is right.
Q. Can we look at {H/253/1}, please. This is a letter of
20 March, so this is during the trial.
A. Yes. Is this the letter which points out the suggested
things to search for?
Q. It is. And you see there -- this is the bit where
a SSC -- an unnamed SSC technician has done some
searches as well and Riposte import is mentioned there.
A. Yes.
Q. Can you remember whether you had identified Riposte
import before or because of this letter or after?
A. I think we had only started to use it as a result of
these messages here.
Q. Thank you.
MR JUSTICE FRASER: "These messages", you mean --
A. Sorry --
MR JUSTICE FRASER: The letter?
A. -- the strings, yes, the letter, and knowing that these
are suitable things to search for on our system.
MR JUSTICE FRASER: As a result of the letter?
A. Yes, my Lord.
MR GREEN: You were also asked about the difference of
an hour between the two sets of ARQ data and other data.
A. Yes.
Q. Can you remember when you realised or learnt of that
difference?
A. I believe that I have only really surmised that the
reason for the difference is just a time zone
difference. I do not think I have ever been told that's
what it is.
Q. Can we look at Day 16 of the transcript, please,
page 12, line 7 {Day16/12:7}. It was put to you that
MSCs had been disclosed on the Friday before Christmas,
21 December?
A. Yes.
Q. And OCPs and OCRs on 24th January?
A. Yes.
Q. If we look at {H/263/1} now, this is a letter of
18th April 2019. There was an extra 2,500 OCRs
disclosed on 18th April.
A. Yes.
Q. Mr Coyne, can I ask you whether you have been busy since
the time that the Horizon trial should have ended, had
it gone to plan and not been derailed?
A. Yes, yes, I have got a number of other projects.
Q. Have you had a give oral evidence in any other cases?
A. Yes, I have had to give oral evidence in a case at
Manchester and I have a number of other non-contentious
projects where I'm helping companies go live with big
systems.
Q. How have you found the timing of your receipt of
documents for the purposes of preparing your reports?
A. It has been very problematic.
Q. How does it compare to other cases you have been in?
A. I don't think there has been another case where I have
experienced this level of -- the disclosure being
provided in dribs and drabs, especially after making
a specific request back in June of last year because it
was quite clear then the types of documents that would
be required.
Q. And finally, you were asked what proportion of OCRs had
been granted -- permissions had been granted
retrospectively?
A. Yes.
Q. Do you have that number?
A. I do. I searched last night. There's just over 21,000
OCRs and OCPs and there is 1,450 that are described as
being created retrospectively, that's about 7%.
MR GREEN: Thank you very much.
My Lord, I have no further questions.
MR JUSTICE FRASER: I don't have any -- let me just check.
I do not think I have any, but let me just check.
No, thank you very much, Mr Coyne. You can leave
the witness box because we have a few matters to deal
with, although I do not think very many, or certainly
not very many from me.
Discussion
MR JUSTICE FRASER: The next day of evidence is Tuesday
morning. You are calling Dr Worden, is that right?
MR DE GARR ROBINSON: My Lord, yes.
MR JUSTICE FRASER: So it is Tuesday, Thursday, Friday of
next week?
MR DE GARR ROBINSON: My Lord, yes.
MR JUSTICE FRASER: Mr de Garr Robinson, yesterday you
identified or referred to Ernst & Young audits for
different years going on from 2011 onwards.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: Can you just let me have a list of
references?
MR DE GARR ROBINSON: The trial bundle references?
MR JUSTICE FRASER: Yes, please.
MR DE GARR ROBINSON: My Lord, yes.
MR JUSTICE FRASER: You were also going to just send me on
Monday I think some information, just a summary --
MR DE GARR ROBINSON: A very short note summarising the
redaction position, yes.
MR JUSTICE FRASER: The redaction exercise.
Then the only other thing I have --
MR DE GARR ROBINSON: My Lord, can I just ask, when you say
the Ernst & Young audits, do you mean the service audits
for Fujitsu or do you mean --
MR JUSTICE FRASER: Well, yesterday you put to the witness,
and I can find my note in a moment, I think you said "We
have them for each year 2011, 2012", and you went
through a list of years.
MR DE GARR ROBINSON: Those were the service audits,
my Lord. I will give you the references for those.
MR JUSTICE FRASER: If you can just give me the references.
Then the only other point is the PEAKs and KELs hard
copy file. I remember at the beginning of the evidence
of fact I said could I have one, and I was anxious not
to impose too much of a burden on anyone and I said
I didn't need a detailed index. The indices that came
through were somewhat idiosyncratic, I think that's
because they were not necessarily done by the same
person which is really not a problem, but it makes the
file really quite difficult to follow. I think it was
broken down by per day, per sitting day.
I deliberately haven't marked it because I have been
using the electronic ones. I have got an index for --
well, I have got a document which says it is an index
for week 1 and a document that says it is an index for
week 2. Week 2 does refer to numbered tabs, but the
tabs that are in the file aren't numbered in accordance
with the tabs in the index. For example, one would
start at tab 97 and I can't find tab 97 for the life of
me. I think it is just re-ordering the way the index
and/or the tabs are numbered. I'm not asking for the
actual contents to be re-ordered.
Did it come from the claimants or did it come from
the Post Office?
MR DE GARR ROBINSON: I believe it is a combined process.
MR JUSTICE FRASER: I'm in no way on any sort of a witch
hunt.
MR DE GARR ROBINSON: Everyone is looking around furtively
at the other side.
MR JUSTICE FRASER: It is just to try and get that file in
a usable form. That usefully is the evidence of fact
file. There is as yet no expert evidence PEAK file but
I would like to make it clear that I would like one at
some point.
MR DE GARR ROBINSON: My Lord, could I ask how you would
like that file organised. Are you content that it
should remain in day by day form?
MR JUSTICE FRASER: Yes.
MR DE GARR ROBINSON: It is simply a matter of getting the
right index?
MR JUSTICE FRASER: For example, you put one of the more
important PEAKs to Mr Coyne, which had already been
dealt with. It was impossible for me to find where that
was in the end. I know it is in here somewhere.
MR DE GARR ROBINSON: I see.
MR JUSTICE FRASER: But, for example, if one looks at the
index for week 1, which I will just hand you and then
you will see what I mean. (Handed) You will see that
really is just a total of everything that's in the file
without necessarily telling you where it is or being in
any immediately discernible order.
MR DE GARR ROBINSON: Could I ask, are there markers? Are
there dividers between each PEAK?
MR JUSTICE FRASER: Well, there are, but they don't seem
necessarily to follow.
MR DE GARR ROBINSON: I'm wondering whether your Lordship
would like a paginated bundle -- I don't want to make
work for anyone -- and an index --
MR JUSTICE FRASER: Paginated would be glorious.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: So what it really amounts to,
Mr de Garr Robinson, without spending too long, is this
file in either a different order or a more usable form.
I'm happy for it to stay in the current order, which is
per day, if I could, for example, think well that was
put on Day 3, and actually find where Day 3 is in here
and look at it. And a similar wholly separate file for
the PEAKs that are going to be put to the experts.
MR DE GARR ROBINSON: But ordered in the same way, day by
day.
MR JUSTICE FRASER: Either in the same way or in their own
separate way, I don't much mind.
MR DE GARR ROBINSON: If it is not day by day it is
difficult to think how else one would actually do it.
MR JUSTICE FRASER: I prefer day by day because it makes it
easier.
MR DE GARR ROBINSON: My Lord, does that mean you are happy
for the file to contain duplications?
MR JUSTICE FRASER: Yes.
MR DE GARR ROBINSON: My Lord, I don't have instructions to
do this, but could I volunteer entirely without
instructions to take that file, paginate it, and get
a proper index for your Lordship?
MR JUSTICE FRASER: By all means. You will see I have
flagged the week 2 index in here, which is in
a different form to the one I have just given you, which
is week 1. This is the one that says tab 97.
MR DE GARR ROBINSON: Which doesn't exist.
MR JUSTICE FRASER: No. Unless there is a strange non-base
10 numbering system which I haven't come across. Would
you like this back?
MR DE GARR ROBINSON: If your Lordship is happy --
MR JUSTICE FRASER: It is deliberately not marked. There is
some writing on the index for week 2 but that actually
isn't my writing.
MR DE GARR ROBINSON: Very good.
MR JUSTICE FRASER: It was there when the file came.
MR DE GARR ROBINSON: My Lord, we can do that and we can
produce it by Tuesday. We can produce it by the time we
start on Tuesday next week.
MR JUSTICE FRASER: That would be very helpful. Then after
next week, if the same thing can be done for the
experts, please.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: I think we have achieved consensus.
MR DE GARR ROBINSON: The only thing on my list was to
remind your Lordship about the PEAK files but we've done
that.
MR JUSTICE FRASER: PEAKs and KELs, but that is it, that's
because I remembered.
Anything else?
MR GREEN: My Lord, no.
MR JUSTICE FRASER: One final point, and it is really not
a big point, I got an email from Opus about transcripts
to be moved from one work space of Horizon across to
another. I don't recall asking for that to be done.
I don't mind it being done. I think it flowed from the
point I made about Day 13 and where was it.
I know what day we are on here, this shows 17
sitting days. If between you, you could just agree
which days we have in fact sat and what their numbers
are in terms of the sequential number of the hearing
that would be useful.
MR DE GARR ROBINSON: It's probably easier for me because
I have only been here when we have actually been doing
Horizon business so I will discuss that with my learned
friend.
MR JUSTICE FRASER: Again, it is just to be consistent,
that's all.
MR DE GARR ROBINSON: We can do that on Monday morning.
MR JUSTICE FRASER: Thank you all very much. Tuesday at
10.30.
(4.28 pm)
(The court adjourned until 10.30 am on Tuesday,
11 June 2019)
