This is the transcript of Day 16 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 Tuesday 6 June 2019.
Jason Coyne, independent IT expert for the claimants spent the third of four scheduled 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:
Jason Coyne, independent IT expert for the claimants spent the third of four scheduled 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:
Thursday, 6 June 2019
(10.30 am)
MR JASON PETER COYNE (continued)
Cross-examination by MR DE GARR ROBINSON (continued)
MR DE GARR ROBINSON: My Lord, good morning.
MR JUSTICE FRASER: Good morning.
MR DE GARR ROBINSON: Mr Coyne, good morning again.
A. Good morning.
Q. I'm going to talk about remote access today and for that
purpose I would just like to spend a few minutes looking
at the issues relating to remote access. Can I ask you
to go to bundle {C1/1/1}, please. If we go to page
{C1/1/3}, I will pick it up at Issue 10 under the
heading "Access to and/or Editing of Transactions and
Branch Accounts", and we will see the issue there:
"Whether the defendant and/or Fujitsu have had the
ability/facility to: (i) insert, inject, edit or delete
transaction data or data in branch accounts; (ii)
implement fixes in Horizon that had the potential to
affect transaction data or data in branch accounts; or
(iii) rebuild branch transaction data."
And then is it at all; is it without the knowledge
of the SPM; and without the consent of the SPM?
A. Yes.
Q. So this is really a theoretical question. It is what
could in theory be done based on the system
configuration, yes?
A. Yes, but there are practical examples that will help
answer those.
Q. I'm going to come to that. And transaction data or data
in branch accounts. Let's get some terms clear. When
I talk about transaction data I'm talking about records
of transactions: price, date, quantity, money paid, that
kind of thing. Do you understand?
A. Yes.
Q. That would be a practical and useful definition for that
kind of term?
A. Yes.
Q. So shall we agree that that's what transaction data
means for the purposes of our conversation today?
A. Yes. There's also session data, and within session data
is often contained transactional data.
Q. Then data in branch accounts. A branch account, it is
true, isn't it, is an aggregation of transactions from
a given starting point, correct?
A. Yes.
Q. So your starting point is your opening position?
A. Yes.
Q. Which is itself an aggregation of prior transactions,
yes?
A. Historical, yes.
Q. So when you start from time T0, the beginning of the
branch, you will have a series of transactions, there
will be a calculation at an accounting date, then you
will have a closing balance which is your opening
balance for the next period?
A. Yes.
Q. And on you go. And on each occasion what the system
does is it does an aggregation, a calculation, based
upon the transactions that have happened since the
previous opening position, yes?
A. Yes.
Q. So if the opening position is a genuine aggregation of
all the transactions that went before then the branch
accounts will be right at that starting point, correct?
A. They should be, yes.
Q. You can change your accounting date or period. For
example, you could have an accounting date that starts
at 1 June and finishes at 20 June, and then you can
change your mind and decide to finish the accounting
period on 30 June.
A. I understand you can, yes.
Q. But that won't create a shortfall in your accounts, will
it? It just means you have a different accounting
period.
A. It shouldn't do, no.
Q. Thank you. When we talk about accounting data, for the
reasons that we have discussed really it is the
transaction data that would concern the account holder
most of all, wouldn't it?
A. Yes.
Q. Any change to the transaction data is something that the
user would want to know about because it might affect
his balance at the next accounting date, yes?
A. Yes.
Q. Whether it is in his favour or against him?
A. Indeed.
Q. The user is much less likely to be concerned about
changes to operational data that don't affect the
aggregation of transactions that build up and aggregate
into his balance, yes?
A. If it has little or no impact on his balance then, yes,
that is right.
Q. The same goes for Post Office, doesn't it? It will be
concerned about the accuracy of the branch accounts
which of course are then transmitted and become part of
its own accounts?
A. Mm.
Q. It will be much less concerned about adjustments, for
example, to opening dates or matters of that sort, yes?
A. It is possible that it might have more impact on the
Post Office if dates are changed. I'm not sure of the
entire process and the back end of --
Q. That's fair. But in relation to postmasters, they will
be concerned about the transactions being right, but
form the aggregation resulting in whatever the balance
is at the relevant balance date?
A. Yes.
Q. Let's agree some more nomenclature. When I talk about
remote access today I'm going to be talking about
injecting, editing or deleting accounting data in branch
accounts, okay?
A. Yes.
Q. Maintained either in Legacy Horizon in messagestores or
in Horizon Online in the BRDB? Do you understand?
A. Yes, I do.
Q. I won't be talking about access to other systems which
may contain similar information, do you understand?
A. I do, yes.
Q. Thank you.
Let's move on to Issue 11. Issue 11 is if the
defendant or Fujitsu had these abilities:
"... did the Horizon system have any permission
controls upon the use of the above facility, and did the
system maintain a log of such actions and such
permission controls?"
Permission controls, they are a protection against
error or abuse, aren't they?
A. Yes.
Q. The types of controls that one has, a permission that
anyone at Fujitsu -- because we are essentially talking
about Fujitsu here, aren't we?
A. I believe so. I don't believe anyone else at
Post Office had access to --
Q. So permission from your superiors at Fujitsu and
permission from Post Office, yes?
A. Yes. The permissions on a technical level are more
about settings within the system that allowed certain
users or user groups in or out. I'm not sure whether
you are referring to sort of an oral permission.
Q. Yes, I'm referring to the business systems within which
Horizon was operated, and I think you would accept,
wouldn't you, that Post Office consent was always
required for any remote access data changes of the sort
that we have been talking about, yes?
A. No, I'm not sure that was the case. There is a number
of examples where there was a blanket or an annual
permission that was given for critical access that was
required by Fujitsu. So they didn't need to ask for it
each and every time.
Q. That surprises me, Mr Coyne. It may be my fault. Are
you suggesting there was an annual blanket consent given
by Post Office for the making of changes to accounting
data in branches by way of remote access?
A. There were certainly blanket authorisations given for
a number of tasks, I would have to go back and have
a look at what specific tasks they were, but I'm
reasonably sure that that included quite a widely worded
one that allowed Fujitsu to undertake any -- I think it
either said emergency or critical actions that were
required.
Q. I see. And are you aware of any occasion when that
authorisation was exercised so as to make a change to
branch accounting data of the sort we discussed?
A. Yes, I think that's likely. Because what typically
happens, or certainly there's evidence of it happening,
is that there will then be a retrospective document
that's created.
Q. I see. So what you are saying then is there were -- in
critical cases there were occasions when changes were
made and consent, as it were, was recorded
retrospectively. Is that what you are talking about?
A. What I'm saying is there was a blanket consent for
whenever Fujitsu decides that an element is critical,
that they need to deal with it, so they didn't have to
request permission. And I have also seen evidence that
after certain tasks have been undertaken, that
a retrospective document has been created. Whether
there is a retrospective document for every incident,
there is really no way of knowing.
Q. And how many of these retrospective documents have you
found in your researches?
A. Hundreds.
Q. Hundreds?
A. Hundreds, yes.
Q. Well, that takes me somewhat by surprise. Is this dealt
with in one of your reports, Mr Coyne?
A. No, I think this is typically seen from the OCRs or the
OCPs, so that's after the report was completed.
Q. Well, I'm not in a position to ask you any questions
about that because it comes as news to me. Is there any
reason why that hasn't been revealed to the defendant
beforehand?
A. I would have thought the defendant would have already
known, would they not?
Q. So what you are saying is this isn't something that was
mentioned in your first report, yes?
A. Yes.
Q. And it wasn't mentioned in your second report?
A. Yes.
Q. You have become aware of it since then?
A. Yes.
Q. But you have taken no step to inform the defendant that
you are aware of it and that it might form part of your
evidence today?
A. It is a question that was put to me that I'm answering.
I presumed that the defendant would be aware that
Fujitsu operated like that and created retrospective
documents.
Q. And have you discussed it with Dr Worden, Mr Coyne?
A. No.
Q. Well, do you agree with me that given that it may be
relevant to the issues that we are canvassing today,
given that it may be relevant to the issues arising in
this trial, do you agree with me that as an expert it
would have been helpful if you had broached it with
Dr Worden so that an agreed position -- so that the
relevant documents, which you haven't identified, could
be reviewed and an agreed position could be arrived at?
A. It didn't appear -- they were late documents -- sorry,
they were documents that were disclosed after I had
finalised my report, and it didn't appear to be any
particular issue. You asked me the question then and
I answered it. I didn't believe it would be
a revelation to anyone within Post Office that --
Q. Mr Coyne, you do understand how litigation works? You
are an experienced expert witness, yes?
A. Yes.
Q. And you know when counsel is cross-examining you,
counsel doesn't have the familiarity which all the other
individuals in the case do. What counsel does is
counsel looks at the material which he is facing and
decides upon questions that he is going to ask in
relation to that material.
A. Yes.
Q. Now, what you have just said comes as a complete
revelation to me and there's no way in the world I'm
going to be able to ask you any questions about it and,
if I may say so, I suggest to you that it is obvious to
you that that would be the position. Did you not
appreciate that that would be the position?
A. No, because it would be my perception that that would
already be known. It is only on the documents that have
been disclosed to me. The documents say that they are
created retrospectively.
Q. Well, Mr Coyne, I'm not going to ask you any questions
about that because none of this material has been put
forward or explained or identified and I'm not in
a position therefore to seek to test it, so I'm going to
lay that question aside and I'm going to continue with
the rest of my cross-examination, okay?
MR JUSTICE FRASER: Just before you do, can you just
describe to me the title of the documents you have just
explained?
A. Yes, there's a couple of documents that go together,
OCRs and OCPs, and they are requests for a change to
data and then the permission being granted.
MR JUSTICE FRASER: But those are the documents you are
referring to, are they?
A. Yes, my Lord, and --
MR JUSTICE FRASER: Hold on. And when do you say you got
them?
A. I believe that there was a request --
MR JUSTICE FRASER: No, no. When do you say, when are you
telling me, you got them?
A. Without looking at my records, my Lord, I'm not sure,
but --
MR JUSTICE FRASER: Ballpark.
A. Either when my report had been completed or just before.
The report was 1st February, so it was in or around that
period.
MR JUSTICE FRASER: All right.
Back to you, Mr de Garr Robinson.
MR DE GARR ROBINSON: Mr Coyne, there are two categories of
documents, aren't there, that relate to the process by
which consent is obtained or recorded in relation to
remote access. There are MSCs, aren't there?
A. Yes.
Q. And there are OCPs and also OCRs for less important
changes, yes?
A. Mm.
Q. And the MSCs were disclosed to you on 21 December,
weren't they?
A. Yes.
Q. And the OCPs and OCRs were disclosed to you on
24th January, weren't they?
A. That could well be the time I'm referring to. The
report was 1st February.
Q. And your report was served on 1st February, wasn't it?
A. Yes, so a week after the documents were disclosed.
Q. So in terms of the Fujitsu process for making changes,
the permission controls applied within Fujitsu, do you
accept that the sort of changes we are talking about,
remote insertions, edits or deletions of accounting data
held in branch accounts in the BRDB or the messagestore,
do you accept that Fujitsu applied a rule that changes
of that sort could only be made with another colleague
reviewing and approving the change that was going to be
made, yes?
A. Yes. There is often a record that you will see that
will say authorised by somebody and witnessed by
somebody.
Q. And there are in the trial bundles a consistent series
of documents which were produced and updated by Fujitsu
imposing this four eyes requirement for any change, yes?
A. Yes.
Q. Were you in court when Mr Roll confirmed in
cross-examination that the four eyes approach was
applied quite strictly?
A. Yes, it was, although I have noted documents that appear
to have the same name in the box of authorisation and
witness, I don't really know how that could occur, but
I do accept --
Q. Well, Mr Coyne, again that's something which you haven't
said in any of your reports, isn't it?
A. No, I don't believe I have.
Q. Do you not think it would have been helpful to have
revealed these points before your cross-examination
started so that the matter could be considered and
addressed?
A. I mean, to be fair, there might be other things that
arise that we could say the very same thing about.
There has to be a cut-off point by which time the report
gets sent.
Q. So you don't agree it would have been helpful to
reveal -- bearing in mind that permission controls are
specifically referred to in the Horizon Issues, you
don't believe it would have been helpful even to discuss
with Dr Worden what you had found in the documents?
A. As I said before, I agree that you have asked me the
question now and I have told you something and I can see
how that would be helpful to include within the report,
but there has to be a cut-off time when the report gets
sent or you could literally spend days and days and days
adding things to the report.
Q. But Mr Coyne, your fourth joint statement was made on
4th March, wasn't it, over a month after your second
report?
A. Yes.
Q. And that fourth statement contains a number of
references to OCPs and OCRs, doesn't it?
A. Mm.
Q. And yet nowhere -- and it also contains a number of
assertions of your own view. It is not as if it is
simply a statement of matters are agreed, actually there
are a considerable number of things that you assert
unilaterally?
A. Yes.
Q. But nowhere is there any hint of the two revelations
that you have just produced in court today. Is there
a reason for that?
A. Well, I don't believe they are revelations, I'm just
simply answering the questions that you are putting to
me.
Q. Perhaps I could suggest this: you take the view that it
is not relevant to any of the Horizon Issues that arise
for determination in this trial, is that your view?
A. No, no, it may well be relevant.
Q. Let me move on.
It is important to distinguish, isn't it, between
two questions in relation to permission controls. The
first one is whether controls could sensibly be tighter,
and the second is whether any weakness in the controls
has created adverse effects because, for example,
something was done wrongly or done too often?
A. Yes.
Q. So imagine, for example, some very lax controls around
the use of a tool that was never in fact used. That
would be regrettable but it wouldn't actually have
a practical impact in a case of this sort, would it?
A. If there were lax controls but there were no actions
that were used to exploit that lax control, then yes,
I agree.
Q. The same goes if the tool is used, but it is fair to see
from the evidence that the tool was used rarely and it
was used in a careful way. Again, the fact that
permission controls weren't as strict as perhaps some
people might think, that wouldn't adversely affect the
net outcome, the practical impact of the existence and
use of the tool, would it?
A. I think the problem with permission controls is that it
allows somebody into a system and on that system there
could be a number of different tools, so they may not
have used the prescribed tool but they're then into the
system so they could use other tools. That is the
danger with --
Q. Mr Coyne, I would ask you -- I have limited time and
your reports are really huge and contain a vast number
of claims which I can't possibly deal with in the time
that I already have available. I would ask you, please,
to focus on my question and answer my question rather
than to go off, turn left, and give me an answer which
you conceive may assist some other aspect of your
analysis.
My question was: in circumstances where the tool is
used, but it is used rarely and it is used carefully,
that won't have a practical impact, for example, on the
reliability of the overall system and the reliability of
the accounting data contained in the branch accounts,
would it?
A. No.
Q. Thank you. If we move on to Issue 12 which is on page
{C1/1/3}, the next issue is how often was any facility
used, if at all? That is a practical question -- the
previous one we looked at is a theoretical question --
it is a practical question of scale. Now, you have seen
over 220,000 PEAKs, haven't you?
A. Yes.
Q. And we know from the answers you have previously given
you have also seen many tens of thousands of OCPs, OCRs
and MSCs, haven't you?
A. Yes.
Q. And they are a rich source of material to interrogate to
ascertaining the answer as to whether and how frequently
facilities were used to remotely access branch accounts
and change the accounting data in those branch accounts,
yes?
A. They are a good source of information that would
indicate what steps were taken. They very, very rarely
outline what was done within the branch accounts.
Q. Well, is that right? Let's take it in stages. PEAKs --
if there is some remote access by Fujitsu, it will be
mentioned in a PEAK, won't it?
A. Yes, if there is a need to conduct some remote access
then, yes, that's often --
Q. And the PEAK, as well as identifying the fact of some
remote access, will give a fair indication of the sort
of remote access that's being exercised, yes?
A. Often, yes.
Q. It won't -- it may not give you the SQL lines that have
actually been written if that is the form of remote
access being used, but it will give you a fair
assessment of the nature of the change that's being done
and the effect of that change, yes?
A. From reading it you can often see what is going to be
done but you can't often see the effect. That's the
issue that I have.
Q. Could I suggest to you, Mr Coyne, that you can usually
see the nature of the change that's being affected?
A. The nature of it but not necessarily the number of it.
If it is a value, you don't often see the value --
Q. So you are suggesting that you can see a change is being
made to a particular kind of value but it may not tell
you what the numerical number of the change is, is that
what you are saying?
A. Yes.
Q. And as well as PEAKs, you have the ability to search
OCPs and OCRs and MSCs as well?
A. Yes.
Q. And they give you further information relating to the
question whether any remote access has been exercised so
as to affect branch accounting data, correct?
A. Yes.
Q. So between the PEAKs on the one hand and the OCPs, OCRs
and MSCs on the other, you do have a rich resource, if
you choose, to go through them and form an assessment of
the scale of the exercises of remote access that have
happened in the last 15 or 16 years, yes?
A. You get an indication of what was occurring, yes.
Q. As we have already discussed, you are capable of using
search functions to look for cases where that form of
remote access has been exercised, where there has been
remote access affecting branch data. You are well
capable of -- by looking for FAD codes or the word "FAD"
and by looking for other technical terms that often go
hand in hand with the exercise of remote access, you are
well capable of finding -- doing intelligent searches
with a view to finding documents indicating the overall
scale of the remote access that has been exercised,
would you agree with that?
A. No, that's not a very easy task, to identify remote
access and how it took place. You can't very easily
search for things like SQL statements, you can't
actually search really for FAD code because FAD is a box
at the top of most of the PEAKs, it is just often not
filled in, so that isn't a very good thing to search
for. We recently found out that there was -- I think
the word Riposte import or something was an indication
of -- so that helped us with our searching.
So it is true that we have identified things that
would indicate remote access but I don't believe we are
advanced in that.
Q. What I would suggest to you, Mr Coyne, is that where
there is an exercise of remote access in relation to
a branch's account, the PEAK will identify the branch by
its FAD code, yes?
A. There are certainly occurrences of that, yes.
Q. Mr Coyne, you are understating the position, aren't you?
It will invariably be the position that where there is
a problem at a branch which requires some form of remote
access to be exercised, the PEAK will identify the
branch that is concerned. That's just how the system
works, isn't it?
A. It will sometimes say a correction or an adjustment
needs to be made at the branch and that might be the
terminology. There will sometimes be a FAD code, there
will sometimes be the name, so Dalmellington for
example, but it is not always consistent.
Q. And in the same way, the OCPs and MSCs, you will have
corresponding OCPs and MSCs relating to the exercises of
remote access, they will identify the branches. Where
there is a form of remote access dealing with branch
data --
A. They certainly should do, yes.
Q. -- they will identify the branches. So with intelligent
search functions it is possible to form a view, isn't
it, of the nature of the branch -- the scale of the
exercise of remote access to affect branch accounts?
A. I mean that is a hugely complex task to start from the
large number of PEAKs, attempt to determine which within
those PEAKs suggest remote access, and then go from the
PEAKs into the OCRs and OCPs. Yes, you could do it for
one or two examples, but you couldn't do that for all,
that would be --
Q. You could do it for a sample, couldn't you? You could
choose a sample of particular branches with particular
names and FAD codes and you could use your search
function to see how often those branches have been the
subject of exercises of remote access, couldn't you?
A. Yes, you could do that. Yes.
Q. And that would be a very easy way of forming
an assessment of scale, the scale or the extent to which
remote access has been exercised, wouldn't it?
A. If you were confident that you had all of the search
terms that would confirm remote access has taken place
then you would use those search terms.
Q. You could just choose a group of FAD codes and a group
of branch names that correspond with those FAD codes.
You would identify a series of PEAKs and a series of
OCPs, OCRs or MSCs with those FAD codes in them and you
would be able to go through them and form an assessment
of how often that happened?
A. From the starting point of a particular number of FAD
codes?
Q. Yes.
A. Yes, that would be possible to do.
Q. And it would have been a suitable and helpful thing to
have done that, wouldn't it?
A. Yes, I think it would be. If we could identify
particular FAD codes and try and analyse the entire
movements of what has gone on with that particular FAD
code, that might be an exercise to do.
Q. 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?
A. 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.
Q. 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?
A. Can we go to the RFI and have a look at that?
Q. Let's do it after a break, shall we?
MR GREEN: My Lord, I'm concerned about fairness about what
was said and things being put to a witness which are
just not right, but then it is a matter for my learned
friend.
MR DE GARR ROBINSON: Let me discuss it with my learned
friend because if I have gone wrong, I will be the first
to apologise.
MR JUSTICE FRASER: Do you mean about the existence of the
RFI?
MR GREEN: No, my Lord, the fact that at an early stage
attempts to look at aspects of claimants were met with
a rebuff that it was not about these claimants
specifically.
MR JUSTICE FRASER: All right.
MR DE GARR ROBINSON: See, that's exactly --
MR JUSTICE FRASER: All right. I'm not going to have a spat
during a cross-examination. Mr de Garr Robinson says he
is going to perhaps return to it after the break and you
have got your re-examination.
MR DE GARR ROBINSON: So I have suggested to you, Mr Coyne,
that it would be possible. I mean, you have been aware
of the FAD codes of the claimant branches for a very
considerable time, haven't you?
A. No, I haven't.
Q. The FAD codes I'm informed were included in Dr Worden's
first report. Do you recall that?
A. The FAD codes are certainly included in one of
Dr Worden's reports, I'm not sure whether it was his
first one or not.
Q. So it isn't the position that the FAD codes for the
claimant branches are things you have only just become
aware of recently, it wouldn't be right to say that,
would it?
A. I haven't concerned myself with claimant branches
because it was made quite clear to me that there was no
interest in this matter about particular claimants.
MR JUSTICE FRASER: Did you have the FAD codes before
Dr Worden's report?
A. No.
MR JUSTICE FRASER: All right.
MR DE GARR ROBINSON: It needn't be the claimant FAD codes,
one could just take a sample, a random sample of
branches, and perform an analysis which would give you
an indication of the sort of scale of remote access
that's happened over the past 15 or so years, yes?
A. If you were aware of the things that you should be
searching for then, yes, that would be possible.
Q. Well, if you were aware of the FAD codes of your sample
group, Mr Coyne, yes?
A. Yes, and then look at the whole history of support
across the FAD codes, yes.
Q. Moving on. Two elements to the extent, the potential to
affect liability in issue -- well, let's move on to
issue 13:
"To what extent did the use of any such facility
have the potential to affect the reliability of
branches' accounting positions?"
That involves two distinct questions, doesn't it?
It involves how often it happened in the first place,
which is raised in Issue 12, yes?
A. Yes.
Q. And it also involves a question as to how carefully any
remote access was done, whether there are reasons for
thinking it was done casually and without proper regard
to the accuracy of any changes made, or whether it was
done extremely carefully in accordance with procedures
that we have already discussed, yes?
A. Yes.
Q. So if one were to get to a position where one is aware
that remote access has happened on some occasions but
doesn't happen thousands and thousands of times
a year -- I mean, you have no evidence to think, do you,
that remote access has happened thousands of times
a year?
A. No.
Q. Do you have a sense, bearing in mind the documents you
have seen, as to the likely scale of annual remote
access?
A. No. It would appear that the access in Legacy Horizon
was higher than it would be in Horizon Online but
I don't really get an indication of scale.
Q. You have not found hundreds of PEAKs or hundreds of OCPs
or MSCs showing that remote access affecting branch
accounts has happened in this case, have you?
A. No, there won't be hundreds that refer to adding
messages or things like that.
Q. I have read your reports -- I have tried to read your
reports quite carefully, it is always a dangerous thing
to make a claim of that sort, but my apprehension from
the reports I have read, particularly your second
report, is you had found relatively few occasions when
remote access had been used to affect branch accounts,
would that be fair?
A. There's often talk about the need to make a correction
or to address a discrepancy and there's often a couple
of ways of doing that. Sometimes you will see in the
PEAK that the question will be asked -- sorry, the
statement will be made: this can either be corrected by
inserting a message or do Post Office want to issue
a transaction correction to make the adjustment? So you
often see that. So you don't know what the outcome of
that was.
Q. Mr Coyne, you have referred to some of those PEAKs and,
so far as I can tell from having read them myself, where
there has been an exercise of remote access that's
recorded in the PEAK. The PEAK doesn't go quiet once
the possibility is mooted, it only goes quiet when
remote access hasn't been exercised because it has been
dealt with by different means. Surely you would agree
that?
A. When it goes quiet and you don't know what it is, the
two options are given in there. So it is either that
Post Office has been asked to correct it or remote
access has taken place, there's no evidence either way.
Q. Mr Coyne, I think we agreed yesterday that Fujitsu in
the production of PEAKs are quite process driven, yes?
A. Yes.
Q. When they do something, when they do a piece of work in
relation to a particular PEAK they will write down, they
will indicate in the PEAK what work they have done?
A. Yes, that's fair.
Q. And what I would like to suggest to you is that it is
clear that in circumstances where you have a PEAK and
someone at the SSC is wondering whether a change or
a remedy should be applied either by Post Office issuing
a transaction correction or perhaps by doing some form
of remote access, in circumstances where the transaction
correction or other manual approach is adopted, there
will be no suggestion of any remote access being adopted
later on in the PEAK, yes?
A. Yes.
Q. But where some remote access is done, where a decision
is made that the person at the SSC is actually going to
make a change, that will always be documented in a PEAK,
will it not? That's how Fujitsu work?
A. Yes, I would agree that that would appear to be their
typical process.
Q. Thank you. Bearing in mind that you have now agreed
I think on two occasions that where there has been some
remote access there will be a PEAK indicating that it
has happened, if I could go back to my earlier question:
I would be right in thinking, wouldn't I, that of the
PEAKs you have seen you found relatively few examples of
remote access having been exercised? Would the answer
to my question be right?
A. I don't know exactly what the number will be, but it is
tens, twenties --
Q. Looking at your report it would be low tens, wouldn't
it? You haven't found hundreds?
A. No, I haven't found evidence of hundreds, no.
Q. So you have found, as I say, a relatively small number;
relative to the fact that we are talking about 3 million
branch accounts over the last 20 years, all you have
actually found is a very small number which is less than
20 or 30, let's call it less than 30, would you agree
with that?
A. Yes.
Q. Thank you. Just to finish off on Issue 13, if the
evidence indicates that remote access is really
relatively rare and over a period of, say, 15 years it
has only happened on perhaps 100 or so occasions, and if
the evidence shows, that's so far available, that when
remote access is exercised, it is exercised very
carefully and people check the change being made and so
on, would you accept that the chances of remote access
being affected in a way which adversely affects branch
accounts, in other words which creates false shortfalls,
is vanishingly small compared with the 3 million branch
accounts that we know have been produced during the life
of Horizon?
A. It would be fair to say that it would be reasonably
small. I don't know about saying it was vanishingly
small.
Q. It would be what Dr Worden calls in his report a second
order issue, yes?
A. I mean there is evidence of mistakes being made in
remote access --
Q. Really? Is there evidence -- have you seen a single
document indicating the form of remote access we are
talking about, namely remote access, affecting branch
accounts, as opposed to remote access affecting, say,
the TPS system or something? Are you aware of a single
instance where that form of remote access has ended up
in creating a false figure in a branch's accounts?
A. Yes, we saw one, one was put on a witness in the early
stages with the £1,000 that was left.
Q. Is that the only example that you have seen?
A. Well, I have seen that example. Again that's something
that's incredibly difficult to search for or audit
because you don't have the values into the PEAKs, so
if --
Q. But I --
A. Sorry, let me finish. So if remote access is recorded
the outcome isn't often recorded.
Q. But going back to my question, I think you have answered
a different question. You have indicated that errors
might sometimes happen?
A. Yes.
Q. And I'm not seeking to suggest that perfection can ever
be achieved, so I'm not seeking to dispute the
possibility of errors happening. What I am seeking to
suggest to you is that all the evidence you have seen
indicates that when Fujitsu did remote access they did
it carefully, yes?
A. Yes.
Q. And that it is fair to infer that when that careful
remote access was done, the chances of a false figure
being introduced into a postmaster's account was very
small?
A. It was small.
Q. It would be less than 1%? Certainly less than 5%, yes?
A. I would be uncomfortable trying to put a percentage on
it. I'm happy to say it would be small.
Q. So in circumstances where you are aware of a relatively
small number of cases where remote access has actually
happened, and where you accept that the chances of
remote access being done incorrectly so as to produce
false figures is quite small, then the overall chance of
an account -- any particular branch account being
adversely affected by remote access is absolutely tiny,
isn't it, because it is a small chance multiplied by
a small chance, correct?
A. By this particular form of remote access then I do agree
it is small.
Q. That's what Dr Worden calls a second order issue, and
would you therefore agree with me that that
characterisation is correct? In the scheme of this
case, where the overall decision to be made by the court
is how robust Horizon was in the 3 million-odd or so
accounts that it produced over its 20-year life, this
particular issue is not of great practical significance
because it is a second order issue, yes?
A. I mean, what we have talked about here is the insertion
of messages and editing in BRDB. We have excluded
certain elements of remote control there, we haven't
talked about rebuilding or anything like that. Are we
going to come onto those later?
Q. Yes, we are. You are talking about rebuilding. Are we
going to talk about the process by which messagestores
in Legacy Horizon will be trashed and then replicated
from back up copies on the mirror server --
A. Yes, because they actually have an impact on messages at
the branch which do have an impact on --
Q. We are going to come to that. But just taking that very
briefly, the process we have just discussed, that form
of rebuilding where a counter for some reason has
a problem and its messagestore is deleted, what that
does is it triggers an automatic system in Riposte, yes?
A. Right.
Q. Which causes the mirror server, which contains all the
data, to be replicated to the particular machine whose
messagestore has been deleted, yes?
A. That is the process, how it should work, but there is
evidence of that failing and messages having to be
extracted from hard drives of failed counters, the
actual messages being taken out there and then rebuilt
on another counter. So I agree that what you have
outlined there is the position that should happen.
Q. We will come to those examples, I will ask you about
those if I have got time. But they are relatively few,
yes? We are talking about a very small number of
examples that you are aware of, is that right?
A. There is quite a few where that --
Q. When you say quite a few, how many are you aware of?
A. I have certainly found ten or so.
Q. Okay. So ten occasions over the ten-year period up to
Horizon Online. But laying those aside, the standard
form of messagestore deletion with automatic
replication, that is a form of a back up. That's
actually a form of robustness, isn't it, because what
happens is when that system is invoked, it is invoked
automatically, the system is designed --
A. It is designed to do that, yes.
Q. -- to operate in that way. And what then happens is you
have a machine which actually has the right data on it
after all?
A. That's absolutely the way that it should happen, yes.
Q. So let's now look at the forms of remote access you have
addressed in your report. Can we go to the fourth joint
statement, please, that's at {D1/5/4}. If I could pick
it up at page 4, paragraph 10.2. This is addressing the
ability/facility to insert, inject, edit or delete
transaction data or data in branch accounts, so this is
what I call proper remote access, yes?
A. Yes.
Q. What you have done there is you have set out the forms
of remote access of which you are aware, is that right?
A. Yes.
Q. Are there any other forms of remote access of which you
are aware that are not set out in the this joint
statement?
A. No.
Q. Thank you. So what I need to do today is cross-examine
you on the forms of remote access that I will find in
this joint statement, correct?
A. Yes. You started this session by reducing what remote
access meant.
Q. I started this session by defining what remote access
was, Mr Coyne, which was what's referred to in Horizon
Issue 10 --
A. Yes, and you said this excluded --
Q. -- which is inserting, injecting, editing or deleting
transaction data or data in branch accounts.
A. Yes.
Q. What I'm doing, I'm not seeking to pull a fast one, I'm
simply seeking to ensure that that's what we are talking
about in the course of today, because if we talk about
too many other things we will never finish. Okay?
A. Okay.
Q. Thank you. Laying aside whether the forms of remote
access you describe here do account as forms of remote
access, would you agree that the forms you have
identified in the joint statement are consistent with
the basic forms discussed in Mr Godeseth's and
Mr Parker's witness statements?
A. Yes.
Q. You have not discovered any forms of remote access that
they haven't discussed, have you?
A. No. There is modification to back end systems.
Q. Yes.
A. And it is often blurred whether people describe that as
being remote access or not.
Q. Yes. But on the basis of the definition I very
carefully and at somewhat boring length tried to
establish with you over the past hour, then that doesn't
count as remote access within the meaning of Horizon
Issue 10, does it?
A. Yes, okay.
Q. Thank you. Let's try and establish some other important
distinctions about data that may be contained in
accounts but isn't accounting data. Could you tell me
what recovery flags are?
A. Yes, it is what we talked about yesterday when we talked
about flagging the ground whenever a recoverable
transaction starts, and then at the end of it, if that
transaction is completed, the flag will then be removed.
But if a counter reboots and attempts to restart it
looks to see whether there is a recovery flag there, and
if there is a recovery flag there then rather than just
allow the subpostmaster to serve the next customer it
attempts to deal with that recoverable situation.
Q. So a recovery flag is not of itself a branch accounting
data? It is not transaction data and it is not a branch
accounting data, is it?
A. It is not, but it indicates that there is a situation
that has occurred, that a transaction might be part
complete. So it is an indication that something needs
to be looked at very carefully to see if there is
something that's out of balance.
Q. But it is not the data that's referred to in Horizon
Issue 10, is it?
A. No. It has an impact on the data that is Horizon
Issue 10 but it isn't in itself transaction data.
Q. And it is not recorded in the tables that constitute
a branch's accounts in the messagestore or the BRDB, is
it?
A. I think it is in the BRDB.
Q. It is in -- I was quite careful in my question. Let's
just talk about the BRDB which is Horizon Online. The
tables that the recovery flag are contained in are not
tables which contain transaction data within the meaning
of Horizon Issue 10, are they? They are not data that's
in the branch's accounts. It is a different -- there
are hundreds of tables in the BRDB, yes?
A. Yes.
Q. And the recovery flags, and there will be other tables
containing the data relating to the transaction to which
the recovery flag relates, yes?
A. Yes.
Q. Both the tables containing the recovery flags and the
tables containing the data relating to recoverable
transactions, those tables do not form a part of
a branch's accounts, do they?
A. Yes, that is right. There is a danger, I think we are
probably splitting hairs, but there's a difference
between tables and fields within a table. But taking
your point at face value, yes, it is in a slightly
different place.
Q. Absolutely. The recovery flag is a field actually.
I do accept there is this concept of fields. But it
doesn't affect the answer to my questions, does it?
A. That is right.
Q. The tables we are talking about and the various fields
in those tables do not form part either of transaction
data in branch accounts or of other accounting data in
branch accounts, do they?
A. No. They are an indicator that something needs to be
checked in the branch accounts.
Q. And there is other data also, which I think is often
called configuration data, which are in other tables as
well which could be of great use to Post Office in its
accounting systems, or can be of great use in relation
to defensive programming or redundant storage of data
and comparison of copies of the same data in the system.
Things like time stamps where the system records all
sorts of time stamps, there can be hundreds of them for
one transaction recording the particular moment in time
at which the information relating to a transaction moved
from one table to the other or something was done with
it, yes?
A. I'm sorry, you have conflated so many different issues
there I'm not with you, sorry. I'm really not with you.
Q. It would take too long, let me move on.
When we talk about inserting or injecting data,
again can we agree that what we are talking about is
manually creating and inserting either accounting data
or transaction data, yes?
A. Yes.
Q. So a human being exercising some discretion and judgment
to produce some transaction data, for example, and then
inserting that transaction into a branch's accounts,
yes?
A. Yes, the process will be assembling all the characters
that are required for that transaction and then pushing
it into the database.
Q. An example of that happening would be what Mr Godeseth
calls balancing transactions, yes?
A. Yes.
Q. You are aware that Mr Godeseth restricts the definition
of balancing transactions to a form of transaction
insertion by using the transaction correction tool, yes?
A. Yes, there was a tool that was created for
Horizon Online for that purpose.
Q. Just to be clear, I'm going to follow the same practice.
So when I talk about balancing transactions, I'm going
to be talking about transactions that are a result of
the exercise of the transaction correction tool in
Horizon Online, okay?
A. And not any transactions that are outside of that --
Q. Yes. It is important to make that clear because in your
reports you often use the term "balancing transactions"
to refer to other forms of insertion, don't you?
A. But they are balancing transactions.
Q. I appreciate that that's how you think of them, but the
term "balancing transaction", the technical meaning of
the term "balancing transaction", is a transaction that
is inserted as a result of the exercise or the use of
the transaction correction tool. And there are other
forms of injection or insertion. For example, there
were transaction insertions that could be made in
Legacy Horizon, and Mr Godeseth is quite clear in his
witness statement, isn't he, that those aren't properly
to be regarded as balancing transactions, yes?
A. I accept that's the term that has been accepted by
Mr Godeseth, but in general accounting terms "balancing
transaction" is not just within Horizon, it is in
general accounting. It is a transaction that is
inserted to make something balance.
Q. Okay. For the purposes of this discussion let's adopt
IT terminology, let's not adopt what you regard as
ordinary accounting terminology. So just to be clear,
shall we first of all agree that when we talk about
balancing transactions we are talking about the
transaction correction tool, could we do that?
A. I can accept that.
Q. Can we also agree that there are a large number of
references in your report to balancing transactions that
have nothing to do with the transaction correction tool,
yes?
A. They are balancing transactions but outside of the
balancing transaction tool.
Q. Mr Coyne, I'm not seeking to criticise you, I'm just
seeking to get you to agree that in your report, when
you refer to balancing transactions, the judge shouldn't
think that you are talking about exercises of the
transaction correction tool?
A. Yes.
Q. My understanding is that you agree with that?
A. Yes, I do.
Q. Editing now. Editing again is manually manipulating
data that's already in the branch accounts, yes?
A. Yes.
Q. And deleting. With deleting there is an important
practical distinction to be drawn, isn't there, between
deleting a whole set of messages to allow -- the whole
messagestore to allow automatic replication to take
place, yes?
A. Mm.
Q. And manually deleting lines of transaction data, yes?
A. Yes.
Q. And those two are very different things?
A. Yes.
Q. Both involve deletion but they have different
implications. The first is an automatic process which
actually enhances robustness, it doesn't detract from
it. Would you agree?
A. Could you put that first one to me again, please.
Q. The process by which machines which have problems in
their messagestores, have their messagestores deleted so
that there is an automatic Riposte-generated process by
which a copy of the messages that have been created are
replicated back to that machine --
A. Yes.
Q. That enhances robustness, it doesn't detract from it?
A. That is right, yes.
Q. Thank you.
Now let's get some issues out of the way. First of
all, transaction corrections and transaction
acknowledgements. In your reports you treat transaction
corrections and transaction acknowledgements as remote
access facilities, don't you?
A. That was because there was a witness statement, perhaps
it was Mr Godeseth, where he outlined the ways that
branch accounts could be affected, and transaction
acknowledgements and transaction corrections were in
that list.
Q. But that approach leads to a very curious result,
doesn't it, Mr Coyne? It means that when Post Office
used to send error notices up to 2005, your view is that
that's not a form of remote access, yes?
A. Not for the purposes of the remote access that you
described before, no.
Q. But when the system was changed to transaction
corrections in 2005, you take the view that that is
a form of remote access?
A. Well, it is somebody remote from the branch having
an impact on branch accounts.
Q. I could go to the pleadings but I'm not sure I have ...
I could go to the pleadings, but if I simply suggest to
you -- would you recognise that the forms of remote
access that the Horizon Issues are getting at aren't
concerned with transaction corrections and transaction
acknowledgements, and indeed that the Horizon Issues
were drafted with a view to excluding the process by way
transaction corrections and transaction acknowledgements
were arrived at --
A. All right, okay.
Q. Can we agree that for the purposes of this debate it
really doesn't assist matters to include transaction
corrections and transaction acknowledgements, yes?
A. Okay.
Q. Would you give me a moment?
I'm sorry, I think I may have misheard you. I'm
told that in answer to my question you indicated that
error notices itself, in your view, would constitute
a form of remote access. Is that true?
A. No -- well, an error notice has been issued by
Post Office to make a change to branch accounts. So
depending on what definition we are using at the moment,
then it is somebody remote from the branch making
a change.
Q. My understanding of your report, Mr Coyne, was that you
were indicating that error notices didn't constitute
remote access but TCs did, because TCs were transmitted
electronically whereas error notices were transmitted by
post. Is that not your evidence? Have I misunderstood?
A. Could you take me to that paragraph --
Q. I'm not sure I can but it might be at paragraph 5.421 in
your second statement. I'm sorry to take time up with
this. It might be at bundle {D2/4.1/242}.
Yes, here we go, page 242 on the trial bundle copy,
and it is paragraph 5.422.
Here you:
" ... disagree with Dr Worden that TCs are not
inserted transactions ..."
You pick up at paragraph (b), you say:
"TCs - whilst these are visibly acknowledged and
accepted by the Subpostmaster ..."
And by the way, Mr Coyne, what we say in this case
is that remote access is all about transactions -- data
that is directly inserted into branch accounts without
the SPM having the ability to stop it?
A. Right.
Q. That's what the Horizon Issues, I will be submitting to
the court in due course, that's what the remote access
Horizon Issues were designed to address.
A. Yes.
Q. But be that as it may, you say whilst they have to be
accepted they are still inserted.
Then over the page {D2/4.1/243}, at paragraph (c)
you say:
"Prior to TCs, I do not consider manual entry of
error notice amounts to be inserted transactions, as the
Subpostmaster is responsible for entering them on their
system, which differs from TCs as they are resident
within the accounts electronically."
Do you see that?
A. Yes.
Q. So your view then was error notices weren't but TCs
were?
A. Yes, because one is created remotely and one is the
transaction is actually created at the branch.
Q. But your view now is that both error notices and TCs,
they also form a part of remote access, do they?
A. Well, the remote access that we just agreed to talk
about here excluded those and just talked about the
insertion of messages.
MR JUSTICE FRASER: Mr de Garr Robinson, I think someone,
maybe one of your juniors, might have set a hare
running. But looking at the -- is this question
an interpretation of the answer at {Day16/43:21}?
MR DE GARR ROBINSON: Thank you, my Lord.
MR JUSTICE FRASER: Is that the point you are pursuing? You
put a question at line 17, which was then answered:
"Not for the purposes of the remote access that you
described before ..."
Is that the point you are pursuing?
MR DE GARR ROBINSON: I was pursuing a suggestion that in
Mr Coyne's view --
MR JUSTICE FRASER: Based on that answer, though, I mean?
MR DE GARR ROBINSON: Yes. Is that right? Yes.
MR JUSTICE FRASER: The easiest way might be to deal with it
like this: do you treat error notices either in your
report or today as constituting remote access?
A. No.
MR JUSTICE FRASER: Right.
MR DE GARR ROBINSON: Very good.
MR JUSTICE FRASER: Back to you, Mr de Garr Robinson.
MR DE GARR ROBINSON: Again in terms of -- well, you accept
it would be reasonable and sensible, bearing in mind the
nature of the Horizon Issues, just to lay TCs and TAs to
one side?
A. Yes.
Q. Because at least the SPM is aware of them and has to
press a button to allow them into his branch accounts?
A. Yes.
Q. Now let's talk about Post Office back office systems.
We have discussed several times already how Horizon --
for example, in Horizon Online it would be the BRDB --
feeds data to various parties including Post Office, so
Post Office systems like POLFS, POLSAP and Credence and
so on, but also to other systems.
A. Yes.
Q. And that's via what's known as the transaction
processing system, yes?
A. Yes.
Q. Often known as TPS.
A. Yes.
Q. And an aspect of the transaction processing system is
what's called TIP, yes?
A. Yes.
Q. Do you remember what that acronym stands for? A
slightly unfair question.
A. No. It will be ...
Q. Transaction information --
A. Processing, yes.
Q. And the TIP system is an interface, isn't it, with the
TPS system, so it allows files to be accessed and
perhaps -- I'm looking around to make sure I'm saying
the right thing -- so it is fair to say that TIP and TPS
are aspects of each other?
A. Yes.
Q. Or they are so closely related we can treat them --
A. They have an interconnection, yes.
Q. And both of them are not part of the BRDB, are they?
A. No, they take inputs from data which has been in the
BRDB and extract it and decide what to do with it.
Q. And branch accounting data is the data which is held in
the relevant tables within the BRDB?
A. Yes.
Q. What happens is copies are taken from those tables?
A. Yes.
Q. And they are transmitted into the TPS?
A. Yes.
Q. Once they are in the TPS they are held, reconciliations
are done, all sorts of things, they are looked at by all
sorts of people for all sorts of purposes, and also they
are propagated to various Post Office management
information systems and elsewhere?
A. And the clients and things like that.
Q. Yes. So it follows, doesn't it, that any change made to
any data in the TPS system or in the TIP aspect of the
TPS system, that is not a change to data held in branch
accounts in Horizon, yes?
A. It is not, but any changes made in there can have the
impact on branch accounts.
Q. And what you are suggesting there is a mechanism by
which a change is made to some data that's held in TPS?
A. Yes.
Q. That data is then transmitted to Post Office?
A. Mm.
Q. Post Office looks at it and thinks that must be correct,
looks at the data that's in branch accounts and sees
that the data is different?
A. Yes.
Q. And then decides to issue a transaction correction?
A. Yes.
Q. So what we are talking about is a situation where
a change has been made to the TPS, data in the TPS?
A. Yes.
Q. And has been made wrongly?
A. Yes.
Q. And that error has then caused Post Office itself to
make an error?
A. Yes.
Q. Which results in a transaction correction decision being
made, yes?
A. Yes.
Q. Would you agree with me, Mr Coyne, that that also is
a second order issue of the sort that we discussed
earlier?
A. Could I please have a definition of that second order
issue?
Q. Let me just take it in stages. One of the main purposes
of the TPS system or one of the main aspects of the TPS
system is the harvesting and reconciliation processes
that are operated within it?
A. Yes.
Q. And the purposes of those operations is to ensure that
the data in the TPS system -- TPS stands for, I'm saying
"system" twice but you will forgive me if I make that
mistake. That data is then compared with other
available forms of data with a view to checking to see
whether it is correct or not?
A. Yes.
Q. And in circumstances where the data in the TPS system is
wrong because it has been changed, it will create
a discrepancy, won't it?
A. It will, yes.
Q. Between the data that's in TPS and the client data that
it is being compared with?
A. Yes.
Q. So for the scenario that you are suggesting, what would
have to happen is some human being would have to make
a deliberate change to the information in the TPS --
A. Using the TIP correction tool.
Q. And it would throw up a reconciliation error exception,
wouldn't it?
A. To Post Office, yes.
Q. What you are suggesting then is Post Office would see
a discrepancy but prefer the TPS version of truth
compared to the client data version of truth, yes?
A. Yes.
Q. Secondly, that would be a necessary condition before
there's any possibility of Post Office issuing
a transaction correction, yes?
A. Yes. So it is either a correction that's been made with
the TIP correction tool, which is the tool -- I think we
saw a screen shot of it earlier on within the trial,
where a copy of the data is brought up and then the user
can make modifications to that data, either the value or
where it is destined for, so the change is made. You
can either do it on one transaction or it can be done on
many transactions if the same fault occurs with all
transactions. You can fix lots at once and the tool
then sends the data on its way.
Q. Are you approaching an answer to the question I actually
asked you, though, which is: the chances of a change to
the TPS data, it would be picked up as a reconciliation
exception, wouldn't it?
A. Yes.
Q. And what would be necessary is for Post Office to decide
that the TPS erroneous data was right as compared with
the client data that's direct from the branch --
A. Yes, the Post Office would have to make a decision on
that.
Q. And that is quite an unlikely eventuality, isn't it?
A. I don't understand why you would ask that. The
Post Office would need to make a decision on which set
of data is correct.
Q. Let's take it in stages. You would accept, I am sure,
that when changes are made by human beings to the TPS it
is to correct problems that have become apparent in the
TPS, yes?
A. Yes.
Q. No one would make a change in the TPS in order to
introduce an incorrect figure?
A. I agree.
Q. So the purpose of any change that's made using the TIP
repair tool, that's what we are talking about, and I am
sure your Lordship is familiar with that tool, the
purpose of the TIP repair tool is actually to ensure
that there is coherence in the data in the TPS system as
compared with the data in the branch accounts and the
data held by clients. That's the general purpose of
making changes?
A. Yes.
Q. You would only use the TIP repair tool where you thought
there was a problem in the TPS because it is not
consistent either with branch accounts or with client
data, yes?
A. Yes.
Q. So we are talking about a scenario where a change is
made for the purpose of ensuring that data is consistent
with branch accounts but being done erroneously so that
it becomes inconsistent with branch accounts?
A. Yes.
Q. Would you accept that that's quite an unlikely
eventuality, in practice?
A. It certainly shouldn't occur that people make mistakes
with the tool but it is possible that it can occur.
Q. Mr Coyne, you do seem to be struggling to accept
something which in my respectful suggestion is
blindingly obvious, which is that in the vast majority
of cases, given the purpose with which the TIP repair
tool is always used, the chances of the TIP repair tool
being used in a way which introduces an error -- which
actually introduces an inconsistency with branch
accounts when the whole purpose of the tool is to ensure
that doesn't happen, usually it is to ensure coherence
between the accounts and the TPS system -- the chances
in the real world of the use of a TIP repair tool which
introduces a discrepancy is very small?
A. All that can be fairly said about that is that it would
require human error.
Q. That's all you are willing to say about it. But could
I suggest that someone applying commonsense to the
situation would readily say, yes, the chances are very
small?
A. It's whatever the chances are of a human making an error
with that.
Q. You really don't want to talk about extent, do you,
Mr Coyne?
And where that kind of error happens, the chances of
that error then not being picked up when Post Office
looks at the client account and looks at the client
data, the chances of Post Office favouring the erroneous
TPS data over the alternative sources of data that are
available, would you accept the chances of that
happening are very low?
A. No, I don't accept that.
Q. Why don't you accept that? Isn't it commonsense again?
A. It's not, because when you see suggested adjustments
coming in from the third parties, and one of the
examples was the Santander corrections that arrived from
the client, many of those it was said got sent on to the
postmasters as TCs and they had to dispute those TCs.
Q. Mr Coyne, are you referring to the evidence that was
given in Mr Smith's first witness statement about
Santander transaction corrections and the disputes in
relation to that?
A. Yes, quite possibly.
Q. And have you forgotten the evidence that's given in
Mr Smith's second witness statement explaining that
those figures don't actually represent what, entirely
fairly, you understood them to represent in his first
witness statement?
A. Yes, I think what he changed it to was that they were
mistakes made by Santander that the Post Office
disputed. Is that the correction that he made?
Q. Santander were operating a system, as I recall, in which
paper had to be sent from the branch to Santander and
Santander often wouldn't get the paper, so it would take
the view that a transaction either had or hadn't
happened in a particular way. What would then happen,
it would send its figures through, there would be
a discrepancy between its figures and Post Office's
figures, and Post Office would then go to the branch and
say "Have you sent the paperwork?" And quite often the
branch would then provide the paperwork which
Post Office could show to Santander in order to
demonstrate what the true position was. Does that ring
a bell?
A. It does ring a bell, yes.
Q. Right. That has nothing to do with changes made by use
of the TIP repair tool to the TPS system, does it?
A. No, I think that's probably right. But what my
illustration was, you asked the question whether it is
more likely that Post Office would accept the
postmaster's position rather than another set of data,
and I said that I don't believe it is unlikely because
there is evidence that Post Office have taken the other
party's position as to what the data should appear as
rather than the postmaster and --
Q. Okay.
A. Sorry let me finish, please. And that's what's led to
some of the TCs being disputed by the subpostmasters and
that that dispute has been accepted by the Post Office.
Q. Let me get this straight then. We have a scenario where
data that is correct in the BRDB goes into the TPS and
Fujitsu decides to change it. Yes?
A. Yes, Fujitsu intervened on that data and made some
correction.
Q. And I think you have accepted already that when Fujitsu,
using the TIP repair tool, decides to change some data
it will be for the purpose of ensuring coherence between
the BRDB and the information that is in the TPS system?
A. I would have thought that was the way --
Q. Yes. So what you are suggesting is a situation where
the intention of Fujitsu is to ensure that the figures
are the same, but something goes wrong such that a false
figure is injected into the TPS system?
A. Yes.
Q. So we have the correct figures in the branch accounts?
A. Mm.
Q. We have an incorrect figure in the TPS system, which
then goes -- which is then harvested and, as part of the
process, is compared with lots of other forms of data
including client data?
A. Mm.
Q. And what you are suggesting is -- let's say the Fujitsu
person who made the change wrote down £10 instead of
£100. What you are suggesting is because client
reconciliation data can be erroneous too, there's
a chance that the client will itself have written down
£10 instead of £100 and in those circumstances
Post Office will accept both sets of figures. That is
the scenario you appear to be suggesting, yes?
A. No, not that two people will have the erroneous sets of
figures. That there will be an error introduced using
the TIP repair tool by Fujitsu but that the external
client has a different view of that data.
Q. What I was seeking to ascertain from you, Mr Coyne, is
whether you are willing to accept that in the real world
the chances of Fujitsu making a mistake so as to create
a discrepancy rather than to create one or affirm one by
its use of the TIP repair tool, which is its intention,
and the chances of when that happens of Post Office
looking at that error and looking at the client data and
deciding to accept the erroneous figure rather than the
client data and what's already in the Horizon branch
accounts, what I'm suggesting to you is that that
scenario is obviously a very unlikely one. I'm not
saying it is impossible, but in the real world the
chances of those different kinds of errors all combining
together to result in a false transaction correction is
very low?
A. I do accept that it is low but it isn't that many errors
that's required. It is only really required that
an error is made by Fujitsu either on the value or
potentially the transaction type, because if the
transaction type is altered the transaction could go
somewhere differently or be dealt with differently. And
then the only other decision that needs to be taken is
that Post Office accept that data rather than the
branch's version of the data.
Q. And you are suggesting that in circumstances where the
transaction is properly undertaken in the branch and
an error is introduced, and you accept it is going to
happen only in a small minority of cases, an error is
introduced, don't you accept that the circumstances in
which Post Office is likely to prefer that erroneous
figure than the figure that is correctly held in branch
accounts and correctly held by the client, the chances
of that happening in practice are very small?
A. Yes.
Q. And then of course there is a further chance it has to
happen, there is a further box that needs to be ticked
in order for branch accounts to be affected, because
once of course the transaction correction goes through
it gets sent to the postmaster?
A. Yes.
Q. And the postmaster says, "Hang on a second, I didn't
receive £90,000, this isn't right", and phones up the
helpline because that's what you do when you don't agree
with the transaction correction?
A. Yes.
Q. So again there is a further protection, there is
a further filter that needs to be got through, namely
either the postmaster not objecting or the postmaster's
objections being overruled?
A. Yes.
Q. And do you not accept that in the real world, given the
scale of the changes -- well, what is the scale of
changes made to the TPS system by using the TIP repair
tool? It is relatively small, isn't it?
A. It is relatively small in comparison with the number of
transactions per day, but it is a high number of repairs
that are made each day.
Q. How many?
A. I don't know precisely but I think it has been
mentioned. It is in the thousands, I believe.
Q. Thousands a day?
A. Of TIP repairs, yes.
Q. Okay. That comes as a surprise to me. But you are
saying it is small relative to the number of
transactions that are actually passing through the
system in the day?
A. Yes, but it is still quite a big number that he has
done. I do believe it is in evidence somewhere.
Q. I will have to look at that.
My Lord, I see it is 11.50, and this isn't
a convenient moment but in fairness --
MR JUSTICE FRASER: All right. Would you like to pursue it
for a couple more minutes?
MR DE GARR ROBINSON: Yes, if that's agreeable.
MR JUSTICE FRASER: As long as it is only a couple of
minutes then that's fine, otherwise we can break now.
MR DE GARR ROBINSON: Last question before -- or last
series, couple of questions. Where the TIP repair tool
is exercised there will be a PEAK relating to its
exercise, yes?
A. There should be, yes.
Q. Are you suggesting that there are PEAKs numbering in the
thousands per day reflecting the exercise of the TIP
repair tool in the PEAKs that you have seen?
A. No, I don't believe there is one, there isn't one PEAK
per TIP repair that's undertaken. You don't have a one
to one relationship.
Q. Have you seen a significant number of PEAKs relating to
the exercise of the TIP repair tool?
A. I don't know what the number will be, but there are
PEAKs that talk about the TIP repair cool.
Q. Could you give me a sense of scale? Are you talking
about a dozen, are you talking about a thousand, are you
talking about a smaller number?
A. What I'd prefer to do, because I'm pretty sure the
number of tips that are done per day or per month is in
the evidence somewhere, I would prefer to find that and
give you the number.
MR DE GARR ROBINSON: Very good. My Lord, perhaps that
would be a convenient moment.
MR JUSTICE FRASER: All right. You might not be able to do
that in ten minutes, though, I imagine, Mr Coyne?
A. No, I wouldn't imagine so, my Lord.
MR JUSTICE FRASER: No. So just to be clear, he's not being
asked to do that now.
MR DE GARR ROBINSON: That's a shame.
MR JUSTICE FRASER: Well, he doesn't have the trial bundle
apart from anything else.
We will have a 10-minute break. We will re-visit
that question at 1 o'clock about whether the witness
statements should just be given to the witness in a hard
copy for him to flick through over lunchtime.
MR DE GARR ROBINSON: My Lord, I'm afraid I'm very
old-fashioned. I'm in favour of hard copy bundles.
MR JUSTICE FRASER: No, I just mean whether it is the sort
of exercise you want done for 2 o'clock or whether you
want done this evening. You have still got tomorrow.
MR DE GARR ROBINSON: What, referring the witness to
particular witness statements?
MR JUSTICE FRASER: No, not you referring him to anything.
Him looking for the number that he says is there which
he says he will give you. But we will just address it
briefly at 1 o'clock, whether you would like it done
this evening or at lunchtime.
10 minutes.
(11.55 am)
(A short break)
(12.05 pm)
MR DE GARR ROBINSON: So Mr Coyne, just to finish up with
the line of questions we were exploring before the
break.
First of all you referred to the fact that
sometimes, let me put it this way, bulk changes were
made by means of the TIP repair tool, yes?
A. Yes.
Q. So changes were made to more than one item of data?
A. Yes.
Q. Would you accept that inevitably those changes are not
going to be changes to transaction data because of
course each transaction has its own individual
characteristics. Those changes will be changes to
attributes, you know, adding missing fields or flags of
some sort. Those would be the kind of changes that
would be done in bulk, yes?
A. Yes.
Q. So when we are talking about erroneous transaction data
being created as a result of the TIP repair tool in the
TPS system, we are not really worried about, we don't
need to be concerned about, bulk changes of that sort
because the basic transaction details will not be
changed.
A. Unless there were bulk changes made to things like
the transaction type or something like that.
Q. Have you seen any changes of that sort being done?
A. No.
Q. I'm grateful. Then just to finish up, the kind of
scenario that you are suggesting would require, first of
all, Fujitsu to make a mistake in its use of the TIP
repair tool, effectively to do the opposite of what it
intended to do, yes?
A. Certainly to make a mistake, yes.
Q. And Post Office to make a mistake in its review of the
relevant data and its comparison of that data with other
independent data, yes?
A. Yes, but I'm not sure what data Post Office actually has
to be able to make that determination.
Q. But Post Office would have to make a --
A. They would have to make a determination based on
something, yes.
Q. Then the postmaster would have to make a mistake either
in not objecting or in not objecting enough to the TC
that he has been provided with, yes?
A. Yes.
Q. So would it be fair to say that the scenario you are
talking about, if the scenario we were talking about
before was a second order issue, this is a third order
issue, isn't it? It requires a series of unfortunate
events, all of which are not particularly likely to
combine together, yes?
A. Yes.
Q. So in the real world, the overall likelihood of those
three things all happening at the same time again is
extremely small, yes?
A. It would be a small percentage of the millions or
billions of transactions, yes.
Q. It would be a fraction of a percent, wouldn't it?
A. Yes.
Q. Okay, one final question in relation to the TIP repair
tool. Could we go to your second report {D2/4.1/72},
please. I would like to pick it up at page 72.
A. Is that 72 on the face of the document?
Q. It is the trial bundle reference. All I'm taking you to
is the heading, you see the heading above
paragraph 3.220, "Evidence of Insertions/Deletions
within Branch Accounts ..."
A. Yes.
Q. So what you are talking about in this section is changes
to data which is held within branch accounts?
A. Yes.
Q. So what you are signalling to the reader is that the
changes being discussed in this section are all changes
being made to data that is held in the BRDB that
constitutes the branch accounting data, yes?
A. Or that has an impact on branch accounts, yes.
Q. No. You say your "Evidence of Insertion/Deletions
within Branch Accounts ...". What you are talking about
is insertions and deletions made to accounting data held
in branch accounts.
A. Yes.
Q. Surely you accept that that's what that heading conveys?
A. Yes.
Q. If we can go forward to page {D2/4.1/78}, perhaps
I could ask you to read paragraphs 3.247 through to
paragraph 3.248. {D2/4.1/79}
No, I'm so sorry, 3.243 through to 3.248, please.
A. 3.243?
Q. Yes.
MR JUSTICE FRASER: On page 78.
(Pause)
A. Yes.
Q. I am sure you know where I'm going, Mr Coyne, but in
those paragraphs you are talking about changes made to
data in the TPS, aren't you?
A. Yes.
Q. And yet you finish up with 3.248 which says:
"The PEAK above therefore indicates that Fujitsu
support had the capabilities to manually rebuild data."
This is all under the heading I took you to before.
So by data, you meant data held in branch accounts.
Would you accept that your entire approach to the TPS
system as exemplified in these paragraphs is actually
rather misleading?
A. I think the heading is misleading because it is talking
about modifications that have an impact on branch
accounts.
Q. Well nowhere, Mr Coyne -- correct me if I'm wrong -- but
nowhere in the section from 3.220 all the way through to
3.248 do you discuss the third order issue of
Post Office making a mistake as a result of what's in
the TPS, that mistake somehow getting through the
reconciliation process, a TC being sent to a postmaster,
the postmaster accepting it or not being able to dispute
it. You don't discuss any of that in this section at
all. You present this entire section as if you are
talking about changes being made to data in branch
accounts, don't you?
A. Yes.
Q. Do you not think it would have been helpful and balanced
to have made clear the fundamental distinction to be
drawn between remote access of the sort that is actually
raised in the Horizon Issues, namely remote access to
data held in branch accounts in the BRDB, and this kind
of data activity which is in a completely -- well, not
completely, but in a different system from the system
which holds branch accounting data. Do you not think it
would have been helpful to have made that clear?
A. But this separation between what remote means is
something that you wanted set out for the purposes of
questioning.
Q. So would I be right in inferring from your answer that
you didn't want to make that distinction? You were
quite happy for the distinction between changes made to
data in branch accounts and changes made to data held
elsewhere, you weren't interested in that distinction,
you just wanted to talk about changes made to data, full
stop?
A. That were remote from the branch. That it isn't changes
to data that's been made at the branch counter.
Q. But Mr Coyne, the branch can't change data that's held
in the TPS. So the notion that changes to data being
made in the TPS is being made remotely from the branch
makes no conceivable sense, does it?
A. But I think it does when the question being asked here
is whether data that was being modified or created was
created at the branch or not at the branch.
Q. What I would like to suggest to you, Mr Coyne, is that
in large portions both of your first report and of your
second report you gloss over the distinction between
changing data that's actually in branch accounts and
changing data elsewhere that may have other
consequences, that may indirectly one day, possibly,
depending on certain contingencies, have an effect on
what the branch accounts ultimately say. And what I'm
suggesting to you is it would have been helpful for
an expert seeking to address the Horizon Issues to have
made that distinction very clear. Do you accept that?
A. I don't accept that, no.
Q. Right, let's move on to global branches. You deal with
that in sections 4 and 5 of your second report. And in
that report you maintained that remote access was
possible for people with global user permissions
operating out of global branches?
A. Mm.
Q. You will recall that Mr Godeseth responded to that
suggestion in his third witness statement and explained
that that isn't the case because global branches can't
be used for the conducting of business and, if they
could, the business that would be done would be recorded
against the branch, the FAD code of the global branch
out of which the business was being done. Do you
remember that?
A. I do.
Q. I wonder whether we could therefore save some time if
I simply ask you whether, in the light of what
Mr Godeseth has said, you now accept that global users
can't remotely access the branch accounts of individual
branches when sitting at the screen of a global branch?
A. Yes. The information that I got was from the manual,
and the manual does suggest that that would be possible,
but I accept from the evidence of Mr Godeseth that that
is unlikely to be the case.
Q. You accept that in fact the way the system is designed
is that no business at all can be done at a global
branch?
A. Yes, that makes complete sense.
Q. And that even if business could be done at a global
branch, because it is intrinsic to the way that Horizon
is designed, that business would belong to, it would be
recorded as business being done by, the global branch?
A. Yes.
Q. Thank you. That has saved a great deal of time. I'm
very grateful to you.
If we could go now to the joint fourth statement at
bundle {D1/5/8}, paragraph 10.15. A short question
only. Here you say -- this is one of your personal
statements, it is not an agreed statement. At page 8,
paragraph 10.15, you say:
"The controls around branch account data do not
specifically consider if the monies within the
transaction actually go to the correct accounts. It
would be possible through simple changes to alter the
sort code and account number of the destination account
and unless this was spotted by the PM or the client,
Post Office system would not detect this."
Now, you then go on to talk about defects in Horizon
reference data, yes?
A. Yes.
Q. Just to be clear, the second paragraph there has nothing
to do with remote access, does it?
A. It has nothing to do with the way that you have set out
that you want remote access dealing with in this
section, no.
Q. Thank you. Now the first paragraph, I don't need to ask
you much, but is the scenario you are suggesting here
that a criminal working in Fujitsu could, if he wanted
to, spot that a payment was being, an electronic payment
was being made by a customer at an branch, identify the
payment that was being made, hack into the system to
change the sort code and account number of the
destination account, and by that means secure that the
payment, instead of being made in payment of a bill to
British Gas, it goes into his own bank account. Is that
the scenario you are raising there?
A. Yes. It doesn't require the hacking that you suggest
but, yes, that's what I'm --
Q. You are quite right, when I said "hacking", I'm speaking
in a -- I need to be more --
A. Yes. But the rest of that scenario is --
Q. So someone with privileged user abilities?
A. Yes.
Q. And which -- presumably he wouldn't be doing this in the
branch accounts, he would not be changing the data in
the branch accounts. If you are talking about the sort
code and destination account, he would be changing the
data that's passed through to Post Office, wouldn't he?
A. Yes.
Q. So we are not talking about data in the branch accounts
because that doesn't contain that sort of data, does it?
A. No, if this was going to go on it would go on at
Fujitsu's back office --
Q. It would be some sort of change to some Post Office
system, yes?
A. Yes.
Q. And it would be -- so what happens is a bill payment
transaction is done at the branch. It is transmitted
through to Post Office's back systems, so it goes out of
BRDB and goes into Post Office's systems. It waits
there for a while before it is then transmitted onwards
to the bank to actually make the payment?
A. Yes.
Q. And what you are suggesting is that a clever criminal
who happens to have privileged user rights would, in
that limited period of time, while the data is waiting
there ready to be sent off to the bank, use his
privileged user rights. Would he be doing this with
SQL?
A. He could do it with SQL. He might be able to do it
using the TIP repair tool, I'm not --
Q. Right. And by that means he would ensure that the
payment goes to himself rather than --
A. It would go to a different bank account.
Q. And in that scenario, of course, the customer who had
actually made the bill payment would immediately go back
to the branch and say "What the hell has happened?
I have paid my phone bill but I have just been cut off".
We have seen examples of that happening, haven't we?
A. Yes, there are a couple of scenarios where payments have
gone to wrong parties because of erroneous --
Q. So the kind of criminal that we are talking about, as
well as being a master criminal because he has got
privileged user rights and has the ability to use them,
so he is obviously of some seniority within Fujitsu, he
would also have to be an idiotic criminal, wouldn't he,
because that would be a step which would be bound as
night follows day to get detected because there would be
an investigation, wouldn't there, as to what happened to
the payment?
A. Yes.
Q. And on that investigation it would be discovered where
the money actually went and why it was that it got
there?
A. That bit is not as easy as you suggest, but yes, there
would be an investigation.
Q. And it would be possible, it may not be easy, but in
circumstances where money has gone in completely the
wrong direction, that would absolutely be something --
you have seen this with Fujitsu themselves, with the
Highland Council, it is something they took very
seriously indeed and they acted on it very quickly,
didn't they?
A. Mm.
Q. There would be an in-depth investigation to make damn
sure they knew what had happened, yes?
A. Yes.
Q. So in practice anyone working at Fujitsu would know very
well that it would be professional suicide to try
a stunt like that, yes?
A. Yes.
Q. And you would need to be quite well qualified. You say
simple, I think, but you would really have to have
a good understanding of the system and know which tables
to be looking at and what changes are to be made in a
way that didn't create some reconciliation error
somewhere else in the system. It would be quite
a sophisticated process. Your knowledge of the system
would have to be quite substantial, yes?
A. I have seen two or three of these and investigate them
and have a look at what has been actually done, in some
they have got away with it and in others they have been
caught.
Q. In the real world you have no reason for thinking that
has ever happened in Post Office, have you?
A. No.
Q. If I can ask you to look back at your report at page 245
{D2/4.1/245}, paragraph 5.427, this is where -- perhaps
we can go to the previous page so we can see the heading
{D2/4.1/244}. It is all under the heading "Global
Users", do you see? And you very fairly indicated that
in the light of the evidence you changed your mind, and
that is extremely helpful.
A. Yes.
Q. If we go to page 245, having addressed the question
whether global users have the ability to undertake
remote access, you then say:
"Also it is not (in my opinion) a question of
whether DBAs misused their powers, it is more important
to consider (in respect of their actions) whether they
might have erroneously (without intent) modified data."
That's true, isn't it? In the real world that's
what we should be focusing on. We don't need to focus
on hypotheses as to master criminals seeking to steal
someone's gas bill, do you agree?
A. Yes.
Q. Let's move to what I call remote access proper. Let's
take Legacy Horizon first. If we can go to bundle D1,
the joint statement again {D1/5/4}. This is where you
set out the form of remote access that you are aware of.
A. Yes.
Q. "In Legacy Horizon, rebuilding transaction data in the
branch, by replication from some other copy of the
data."
Stopping there, I think we have already agreed that
that -- first of all, it is certainly possible, it is
discussed by all the witnesses, but that's something
which enhances robustness rather than detracts from it,
yes?
A. There's two separate elements in there. There is the
automated way, which I agree is the way that the process
should work, but when the automated way sometimes fails,
there is a manual way where Fujitsu need to copy the
messages from the broken till or the till that has been
removed from site -- the counter that's been removed
from site. They need to get the messages from there.
They make a modification to those messages and they then
import those messages that they have recovered onto the
live systems.
Q. So what you are referring to is what Mr Parker discusses
I think in his third witness statement, is that right?
A. That may be right.
Q. Let's see if we can find it. Would you give me
a moment.
A. It might be Parker 2.
Q. Say again?
A. It might be Parker 2.
Q. His second witness statement. Thank you very much,
that's very helpful. Let me see if I can find it there.
My learned friend Mr Draper suggests it is in
paragraph 38 so he gets the blame if it is wrong. It is
at page {E2/12/12}. I apprehend this is what you are
thinking of.
38:
"For completeness, in the rare circumstances where
it was necessary for Fujitsu to rebuild transaction data
in Legacy Horizon [Mr Parker says] there were three
possible scenarios."
38.1:
"When a counter failed and there was a complete
replication of that counter's transactions elsewhere,
Fujitsu simply deleted the message (transaction) store
on the faulty counter and used the standard facilities
of the Riposte software to re-build the data from the
replicated copy."
And we have discussed that.
38.2:
"Where no replicated copies of the transactions
existed on the network, Fujitsu would physically
retrieve the disk from the faulty counter. The disc
should hold all of the transactions that had taken place
on the counter. At its own office, the SSC would
extract the transaction data and deliver it to the
replacement counter without amending that data. The SSC
would need the Subpostmaster's memory card (AKA PMMC) to
de-crypt the data."
Is that right?
A. Yes.
Q. "This was a physical card ... and Fujitsu would have to
borrow one so the subpostmaster would know what was
happening."
Would that be fair?
A. Yes.
Q. "If Fujitsu were to change anything, it would be to
remove the envelope around the transaction data."
Do you see that?
A. Yes.
Q. Do you accept that?
A. Yes. They go through a process of stripping the CRC off
and then recreating it afterwards.
Q. "The envelope contains the system admin data, i.e. the
sequence number of the data and its ID. Fujitsu would
not change the transaction data itself and in removing
the envelope data, they would simply be allowing the
system to automatically re-number the transactions when
they were re-inserted."
Does that make sense?
A. I'm not sure about the automatically renumber them. The
documents that I have seen make reference to a manual
renumbering of the transactions before --
Q. You have seen documents which talk about manual
re-numbering, have you?
A. Yes.
Q. Do you recall where those documents are?
A. The reference is to using the tool Text Pad, the text
editor to make the changes.
Q. Are we talking about PEAKs or --
A. It is a PEAK, I believe.
Q. Is this discussed in any of your reports? I'm not
building a big criticism, it is just this comes as news
to me and I'm wondering if I missed it?
A. I don't know if it is referenced in my reports or not.
If I could search, I could find it for you.
Q. Shall we give you some quick homework? Would that be
acceptable, my Lord, overnight?
MR JUSTICE FRASER: I have no objection. Are you able to
look at it after hours today?
A. Certainly, my Lord, yes.
MR JUSTICE FRASER: You might want -- so that is your
second, I think. That's his second. I see you are
taking a list. Have you got a list?
A. Yes, I have got it on here.
MR DE GARR ROBINSON: So what you are suggesting is it
wouldn't be automatic, the numbering would be manual.
A. I have certainly seen a document when the messages in
the messagestore have been taken from a disk that has
failed, editing is suggested using Text Pad, some
numbering is changed. Then Fujitsu use a tool called
Message Factory and that creates the CRC check to go
round the messages, and then they use the Riposte import
command, I believe it is, and that imports it back into
the branch.
Q. Well, perhaps we could see the document you are
referring to before -- I don't want to take up time
unnecessarily now. But you would accept, would you,
that for this to have a detrimental impact on branch
accounts there would have to be some quite surprising
error made. I mean there would have to be some change
actually made to the underlying transaction data and
that change would be erroneous?
A. Yes.
Q. And you see Mr Parker saying that Fujitsu's practice was
not to make changes to transaction data?
A. Yes.
Q. Are you aware of anything in the system, in the design
documents or other documents that you have seen, which
would indicate that -- or any PEAKs that you have seen
which would indicate that that had actually happened,
that any changes had been made to transaction data?
A. Well, the one that I'm referencing at the moment, there
is a change being made to the --
Q. To the number of the transactions, yes?
A. There's a couple of elements. I think the counter code
is changed to make it appear that it had been entered on
a different counter than it actually had been done on,
and there was a change to some sort of -- it might have
been a serial number or a transaction number that was
on.
Q. But not a change to any basic transaction detail, price,
product or anything of that sort?
A. No. The PEAK was suggesting which elements of the
messages should be changed before the upload takes
place. The PEAK didn't say change a value, so it would
have to be a mistake. The real mistake with that would
be not getting all of the transactions, or accidentally
duplicating a transaction.
Q. Wouldn't you just be taking a copy of what's in the
messagestore?
A. Yes, but you are then opening up the messagestore in
a text editor, and whenever you are moving data between
an environment where it has some structural integrity
into a text editor then there's always the danger that
things --
Q. So you are suggesting that -- the intention wouldn't be
to change anything, but you're saying there might be
a mistaken change of something, yes?
A. I think the necessity is you do have to change something
because I do not think you can import the data into
another counter in the same way, because it has
a counter ID in there and I think that has to be
changed.
Q. You are right, my question was too loose. There
wouldn't be an intention to change transaction data but
you are saying there might be a mistake made which
results in a change to transaction data that was held on
a machine?
A. Yes, or an omission of a message.
Q. Would you accept that -- first of all, how many
occasions of that are you aware of? Have you just seen
one PEAK or is it more?
A. There's not many PEAKs -- there are quite a few PEAKs
that talk about the Riposte import commands that suggest
throughout --
Q. That is different though. That is transaction
insertions, yes? We are not talking about rebuilding
data now.
A. But that's the process that you rebuild the data.
Q. I see.
A. You get them from another counter or a failed disk, you
edit them and then you import them, you insert them into
a working counter.
Q. But the particular process that we are talking about
now, involving taking data off the machine and injecting
those transactions, how many occasions of that are you
aware of in the documents you have reviewed and --
A. I haven't searched specifically for that. I almost
tripped over that document. But I have only seen
a handful.
Q. Would it be possible for you to bring a list of the
handful to court tomorrow?
A. Yes.
Q. Thank you. I think, and you may already have accepted
this but I ought to put it just in case you haven't, you
would accept, wouldn't you, bearing in mind the evidence
you have heard and the documents you have seen relating
to Fujitsu's own processes, that that process would
involve careful review by two pairs of eyes, yes?
A. Yes, I believe so.
Q. So in the real world again would you accept that the
chances of that happening, going wrong and causing
an erroneous entry in branch accounts that were not
intended, would be very, very low. Would you accept
that?
A. It would be low, yes.
Q. Thank you. Now are there any other forms of data
rebuilding that you believe ought to be discussed in
this context or shall I move on to a different form
of --
A. Yes, I'm happy for you to move on.
MR JUSTICE FRASER: Do you mean off the list, back to the
list?
MR DE GARR ROBINSON: Yes. Shall I move to a different form
of remote access, or is there another aspect to
rebuilding transaction data in the branch that Mr Coyne
is aware of and would wish to discuss?
MR JUSTICE FRASER: Mr Green, either stand up and make
an objection or don't, but sotto voce exchanges across
court are really not very helpful.
MR GREEN: I apologise, my Lord.
MR JUSTICE FRASER: They also put witnesses in a difficult
position.
MR GREEN: When Mr Roll was cross-examined he was taken to
38.1 and 38.2 and not 38 -- the same thing is about to
happen again.
MR JUSTICE FRASER: But if Mr de Garr Robinson doesn't want
to put a particular point then he is not putting
a particular point. But if you are laying a flag down
that he ought to --
MR DE GARR ROBINSON: I think that's very helpful. I'm glad
my learned friend has talked about that.
MR JUSTICE FRASER: Can I just make it clear to both of you
generally, although it is really aimed at you, Mr Green,
I have a very light touch on how counsel conducts
cross-examination in a time-limited trial.
MR GREEN: I'm grateful, my Lord.
MR JUSTICE FRASER: That sort of exchange is not helpful.
MR GREEN: I'm most grateful, my Lord.
MR DE GARR ROBINSON: If you look at the witness statement,
the next page {E2/12/13}, then there's what Mr Parker
describes as the rare case:
38.3:
"... where Fujitsu was not able to access a portion
of the transaction data from the desk then we would
replicate transactions as far as we were able to and
would notify Post Office and Subpostmaster of this and
any information we had on the extent and potential
timing of any missing transactions."
So in relation to that then, that possibility
obviously would involve a debate, wouldn't it, including
the subpostmaster and Post Office, yes?
A. Yes, it would.
Q. And because the transaction -- the data couldn't be
obtained, presumably because the machine doesn't work,
then everyone would know that the data couldn't be
obtained and they would be addressing what should happen
as a result of that data being missing, yes?
A. Although this does remind me of another one that I will
find for you overnight, and that's where I believe the
subpostmaster was told that they couldn't recover the
transactions, so the subpostmaster put the transactions
back in manually from his or her own paper copy, and
then Fujitsu did manage to recover the transactions and
inserted them, which caused a doubling of the
transactions.
Q. Right. We are talking about -- so you found one
occasion when something like that happened?
A. That I was reminded of from that, yes.
Q. Whenever these things happen they are recorded in PEAKs,
yes?
A. This was recorded in a PEAK, yes.
Q. But by virtue of the way we all know Fujitsu works, if
it happens it would be recorded in a PEAK?
A. It should be recorded in a PEAK, yes.
Q. It would be very surprising if it wasn't recorded
somewhere in a PEAK, yes? And you are aware of one
occasion where that happened, yes?
A. Yes.
Q. If you could let me have a copy of the PEAK tomorrow
that would be very helpful, thank you.
A. Just with regard to the PEAK. PEAKs are raised at third
line Fujitsu. So when you say Fujitsu would do whatever
they would do, it would be effectively the SSC. So if
the call gets to the SSC level then that's when the PEAK
would be created. There might be other elements of
Fujitsu that they do other things.
Q. But of course if a call didn't get to the SSC, then
there wouldn't be any question of any remote access,
would there?
A. No, not necessarily. If a call didn't get to SSC then
Post Office has decided that it would deal with it using
some of its own methods, so issuing a TC --
Q. I'm sorry, I'm really confused, Mr Coyne. When you say
deal with "it", what are we talking about?
A. Deal with the situation --
Q. The purpose of the discussion we are having today is to
discuss remote access. Remote access, correct me if I'm
wrong, is what can be done by the SSC when seized of
a problem, yes?
A. Yes, but you then took me --
Q. If I could just -- yes, is that right?
A. Yes.
Q. So in the context that we are discussing it now, we are
always talking about something in relation to which the
SSC is already involved, yes?
A. Yes.
Q. And so when you suggest now that there are situations
when the SSC isn't involved, I don't know what those
situations are, but what I want to suggest to you, and
to save some time, is that whatever those situations
involve, they don't involve remote access of the sort
with which I'm concerned today. Would you accept that?
A. I would accept that. The answer that I gave is because
you asked me about whether something would be recorded
in a PEAK or not.
Q. Yes.
A. And I give you the answer that if the subpostmaster
called Post Office to tell them that there was then
a doubling of their transactions as a result of this,
that that in itself would not raise a PEAK until that
call went all the way through to Fujitsu SSC and the
PEAK would be raised then.
Q. Yes. Are you suggesting -- so you are suggesting
a situation where a branch has already got through to
the SSC and the SSC has done some rebuilding of data.
The branch then has a problem -- the branch knows there
has been some rebuilding of data, I think we discussed
that, yes? And the branch then sees there has been
a doubling of transaction and phones up the helpline.
Now in that hypothetical call the postmaster would say
"This has just happened. The Fujitsu -- the third tier
support has been helping me with my data but I have this
problem because now I have a duplicate transaction".
You are not suggesting, are you, that that call wouldn't
get passed back to SSC to be looked at by the people who
did the original whatever the transaction insertion was?
A. I'm not suggesting any of that. I'm answering your
question as precisely as possible. You asked me whether
it would be recorded in a PEAK and I explained the
process to you when the PEAK gets raised.
Q. So in the scenario you have just hypothesised, the
overwhelming likelihood is that it would get through
back to the SSC and it would be picked up in a PEAK,
probably the same PEAK, yes?
A. That is the process that should be followed, but
initially the call would go into the Post Office and the
Post Office would investigate it and they would make
a decision whether that call should go through to
Fujitsu or not. And then it would be recorded in
a PEAK.
Q. Thank you. Now, no other forms of data rebuilding that
are in your mind that you wish to talk about? Why don't
I give you an opportunity to look through
paragraphs 10.2 -- perhaps pages 4 through to 6. Is
there any other aspect of rebuilding of data that we
haven't covered, in your expert view? {D1/5/4} {D1/5/6}
(Pause)
A. No, I'm happy with what's covered in that statement.
Q. Thank you. If we could then go back to page 4 and look
at the next item {D1/5/4}. The second form of remote
access. You say:
"In Legacy Horizon, injection of an additional
message in the branch messagestore."
A. Yes.
Q. The standard way of doing it, I believe you will accept,
is doing it via the correspondence server which, when
a transaction is inserted, would leave an indication
that the counter on which the transaction was done was
greater than the number of 32, correct?
A. Well, it depends really at what time of day the message
is inserted. Messages are not always at the
correspondence server --
Q. I'm trying to explore that there is a standard way of
doing it and then an alternate way of doing it that
doesn't involve doing it through the messagestore, yes?
A. I don't believe it is a case of one is standard and one
is nonstandard. It depends on whether you are making
a modification after messages have been sent to the
correspondence server or whether they haven't yet gone
from the branch to the correspondence server.
Q. Let's look at what Mr Parker says about that. It is at
{E2/12/9}. Perhaps I could ask you to read what he says
in paragraphs 27 through to 28, please.
(Pause)
A. Yes, I can see that.
Q. You have read it?
A. Yes.
Q. And you will see at the end of paragraph 27, he says:
" ... it would have been injected into the
correspondence server ([this was] the default option
which was followed in the vast majority of cases)."
Are you in a position to disagree with that?
A. No.
Q. Thank you. Then he discusses a PEAK, PC0175821. You
are familiar with that PEAK, it is referred to in your
reports.
A. Yes.
Q. Is his treatment of that PEAK fair?
A. We probably should just check on that PEAK. Could I see
that PEAK?
Q. Yes. It is at {F/485/1}.
There you are, Mr Coyne.
A. Can we go on to the next page please {F/485/2}. Next
page, please {F/485/3}. And again, please {F/485/4}.
Sorry go back one, please {F/485/3}.
Yes, okay, so it looks as if -- yes, messages
prepared for insertion. Yes, I think what Mr Parker
said --
Q. So it is a fair account of what happened. And it is
true, isn't it, that the messages were inserted with the
additional property comment PC0175821 to allow them to
be identified in the audit trail. Do you accept that?
A. Yes.
Q. And do you accept Mr Parker's evidence that that was the
practice that was adopted when using transaction
insertions which wouldn't be automatically identifiable
because of the high number of the counter that would be
recorded?
A. Sorry, with the high number of?
Q. Transactions that are entered into at the correspondence
server are easily identifiable because the counter
number that you see in the transaction log and the
events log is a counter number that doesn't exist in the
branch, yes? It is a counter number that is greater
than 32?
A. I believe that that's the process, but I have seen
occurrences where the counter number of not 32 has been
used. Less than 32.
Q. When it is done by the correspondence server the
evidence that has been given is that that records
a counter number that is greater than 32. Are you
saying you have seen instances where the correspondence
server has been used but a lower counter number has been
recorded?
A. Yes.
Q. Why isn't that in any of your reports?
A. It was a recent -- it was since this report has been --
Q. It is quite difficult -- this time I'm not blaming you,
Mr Coyne, but it is very difficult to conduct
a cross-examination in circumstances where the goalposts
seem to be moving all the time.
Let me just move on. Perhaps I will say this --
A. Should I include that in the homework?
Q. Yes. I'm sorry to burden everyone with this. I'm
anxious that I'm not giving you an opportunity to put in
a supplemental report by the provision -- I don't mean
this as a criticism, you are doing this in answer to my
questions, but in effect we are in a situation where new
evidence is being given which it would have been helpful
to have seen in a supplemental report. But yes, please:
MR JUSTICE FRASER: All you are being asked to do is
actually identify the document that you are talking
about.
MR DE GARR ROBINSON: Yes.
A. Yes, my Lord.
MR DE GARR ROBINSON: I would really not have an exegesis.
MR JUSTICE FRASER: Yes. There's nothing other than the
documents.
MR DE GARR ROBINSON: My Lord, yes.
Would you accept that the thrust of Mr Parker's
evidence that Fujitsu's practice, when there was a risk
of the nature of the transaction insertion not being
readily identifiable, that steps would be taken to make
it identifiable such as by adding comments of the sort
he refers to there?
A. Yes, that's certainly the process.
Q. You would accept, wouldn't you, that Fujitsu was not in
the business of making changes that weren't readily
identifiable at least when a close look is taken, yes?
A. I agree that wouldn't be their desire.
Q. From all the PEAKs and so on that you have seen, you
would accept that their approach is consistent with
wanting to make the changes that they make readily
identifiable, yes?
A. There are a number of anomalies but, yes, I accept that
they --
Q. I'm not going to ask you about anomalies, Mr Coyne.
You will see that in paragraph 29 of his witness
statement Mr Parker had asked one of his colleagues to
search the incident management system, that's the PEAK
database, for incidents that required injecting data
into the counter --
MR JUSTICE FRASER: Just hold on one second. We were on 39,
you want paragraph 29?
MR DE GARR ROBINSON: It is paragraph 29 at page {E2/12/10}.
I'm sorry.
MR JUSTICE FRASER: Yes, thank you. We have caught up.
That's all right.
MR DE GARR ROBINSON: You will see what he says in
paragraph 29.
A. Yes.
Q. I presume you reviewed the documents that he refers to
in his footnote?
A. Yes, I did.
Q. And do you accept that he correctly characterises the
impact of those documents or the effect of those
documents?
A. What does he say is the impact of the documents?
Q. Paragraph 29.
A. Yes.
Q. There was fixing a Riposte index at the counter. 29.2,
removing a historic message that was influencing the
balancing process. And so on. And he says in
paragraph 30:
"In total, data was injected into the counter on 14
occasions. However transactions were injected in only
one of these cases, namely the case described in
paragraph 29.5 above."
And that's PC0175821.
A. This witness statement was very helpful because this is
the first time that we see how the message injection was
actually done and the terms were suggested what we could
search for. I haven't been and looked at these
documents and benchmarked them specifically whether they
were against those particular characteristics that were
pointed out in 29.1 and 29.6.
Q. So would I be right in thinking you are not in
a position to dissent from what Mr Parker says in
paragraph 29?
A. That is the position, yes. I believe that this report
was only the day before my report was due. This witness
statement.
Q. You seem to have considered quite a lot of things since
you produced your second report. Did you not consider
what Mr Parker says here and the documents he refers to?
A. No, I hadn't got the information to be able to ask the
question that you put to me then, whether these specific
PEAKs address those six things.
Q. And you are not in a position to suggest that the search
that he describes in paragraph 29 yielded 14 occasions
on which only one involved an insertion of transaction
data? You are not in a position to challenge that?
A. I'm not in a position to challenge that.
Q. Would you accept that the search that is described in
paragraph 29, that is a sensible set of terms to use
when searching for the kind of transaction insertion we
are talking about?
A. Well, I didn't know that at the time, that these were
the sort of words that you should use to search for
message insertion. That is something that both myself
and Dr Worden had been looking for for a little while so
it was good to have that confirmed. And after looking
at the messages, that Riposte, and I think there is
Riposte import as well, that's one that I found as well,
so it was helpful. The search terms do look to be --
Q. Do you accept, though, that those search terms are
likely to capture the sort of transactions that we are
talking about now?
A. They do. They don't include the word "Riposte import"
or "message import", which is the one that I have since
used, so whether that brings back additional messages,
I'm not sure.
Q. So you have done your own searches now, have you?
A. After seeing these words here I have looked at those
documents and found the command Riposte import in some
of those documents, so I have gone back to search for
that across the whole database.
Q. And are you in a position to suggest that the basic
thrust of what he says in paragraphs 29 and 30, that the
number of occasions where this happened and involved
injecting transaction data was very low?
A. The number will be relatively low, yes.
Q. It's always dangerous to ask but we are talking about
a handful of occasions, no more than that, yes, during
the life of Legacy Horizon?
A. It is probably best for me to actually run the searches
and give you the actual numbers.
Q. I really don't want you to be doing more research,
Mr Coyne. I understood you to be telling me that you
had already done it, and I'm simply asking you whether
in the course of doing that search you found more than
a handful. Perhaps we will leave it at that question.
Perhaps you could answer it now?
A. It will be in the tens but I don't know how many tens.
Q. You mean in the low tens? Between ten and twenty?
A. In all honesty, I would prefer to run the answers and
give you a proper answer. If I had had sight of this
document in enough time before preparing my report, then
I would have provided a proper response to it.
MR DE GARR ROBINSON: Yes. My Lord, is this a convenient
moment?
MR JUSTICE FRASER: I think it is.
MR DE GARR ROBINSON: This is going slower than
I anticipated. Your Lordship may appreciate.
MR JUSTICE FRASER: I had noticed.
MR DE GARR ROBINSON: It is a voyage of discovery in certain
respects.
MR JUSTICE FRASER: I can tell.
MR DE GARR ROBINSON: I wonder whether your Lordship would
be willing to sit at 1.50 pm as you were yesterday?
MR JUSTICE FRASER: I would rather sit past 4.25/4.30/4.35,
for the reason I explained yesterday, and we can start
at 10.15 in the morning.
MR DE GARR ROBINSON: I'm much obliged to your Lordship.
MR JUSTICE FRASER: What we are going to do, I'm just going
to have a stock take with you very briefly now, because
junior counsel doubtless between them will be doing this
but I just want to check. How many items have you got
on your list?
A. Three.
MR JUSTICE FRASER: Right. The first one is looking for the
evidential references or the evidential reference to
a number?
A. Yes.
MR JUSTICE FRASER: Just pause there.
I did say to you at the morning break that I would
come back to you at 1 o'clock about whether you wanted
that done at the short adjournment or whether you would
be happy to have it in the morning?
MR DE GARR ROBINSON: Bearing in mind my timing concerns,
I suspect it is very unlikely that I will be
cross-examining Mr Coyne on any of the material that he
produces.
MR JUSTICE FRASER: Understood.
MR DE GARR ROBINSON: So it doesn't have to be done by --
MR JUSTICE FRASER: Understood.
All right, Mr Green, can you just make arrangements
insofar as necessary that a bundle of the witness
statements in hard copy is available for Mr Coyne by
4.30 pm so he can take it with him to look through and
find that reference.
MR GREEN: My Lord, I do not think it is in the witness
statements.
MR JUSTICE FRASER: Well, the expression used was "in the
evidence", so that was where I assumed it would be.
MR GREEN: Yes. I think that's where the misunderstanding
arose.
MR JUSTICE FRASER: Right. I'm not going to say anything
else and we will come back at 2 o'clock.
(1.02 pm)
(The short adjournment)
(2.00 pm)
MR DE GARR ROBINSON: Mr Coyne, good afternoon.
A. Good afternoon.
Q. We were talking about transaction insertions in
Legacy Horizon and I recall that you mentioned earlier
on the $1,000 PEAK, and that was a transaction injection
so this may be a good moment to talk about it.
Could I ask you to go to {F/432/1}, please. This
is -- do you recall this PEAK?
A. Yes, I think I do.
Q. It has been cited quite a lot by Mr Green. In your
second report, we don't need to go to it but it is at
paragraph 3.232, I think, or it may be 3.234, my note
isn't clear, but it doesn't matter. {D2/4.1/75}
You make two essential points about this PEAK.
First of all you say there was no settlement value for
the transaction and this was corrected by a transaction
insertion, and then you say but a $1,000 loss was
identified afterwards. Would I be right in thinking
that your implication was that that loss may have been
caused by the transaction insertion, yes?
A. Yes.
Q. Secondly, you point out that in the PEAK the view is
expressed that it is best that the postmaster be not
informed about the problem because it was resolved
before roll-over, do you remember that?
A. Yes, I think this is the one. Yes.
Q. So here is an apparent exception to the general practice
of telling postmasters what's going on. Are you aware
of any other exceptions?
A. No, I don't believe so.
Q. Let's look at the PEAK. It is dated 10th December,
2007. The call logger on the top right-hand side is
MSU-Indt Mgt. What does that signify? What does MSU
signify?
A. Management support unit?
Q. Yes. And so this is therefore a report that comes in
not from the postmaster but from the MSU, because some
kind of exception has been thrown up, some kind of
report has been generated?
A. Yes.
Q. In the automatic monitoring processes that are operated
by MSU?
A. Yes.
Q. If we go down to the first box, it is dated
7th December. About four lines down:
"Summary: branch [there is the FAD code] TPSC257."
You will recall what TPSC257 is, won't you? It is
POLFS incomplete summaries report, yes?
A. Yes.
Q. And do you remember, it is a report which shows -- which
indicates that the information going into Post Office
through the TPS is incomplete?
A. Yes.
Q. Something has either been missed or wasn't there in the
first place.
A. Yes.
Q. And it is picked up automatically, yes?
A. Yes.
Q. And it is fair to say that that's one of the
countermeasures which exists within the Horizon system.
Where there are problems of this sort, this is
an automatic process which flags it and ensures that it
is investigated by the SSC?
A. Yes.
Q. Then, if we go down to 7 December at 10.35, it says:
"OCR 17493 has been raised. Sending to EDSC for
progression. While returning call, please include file
name in which outstanding data was sent to POLFS."
It is not difficult to ascertain what's happening
there. The OCR, what would that be designed to do?
A. I think it is operational change request. So it is
a request to change some data. Or correction request.
Q. It's a request to change some data in the TPS, isn't it?
There has been a problem with the TPS system and what
they are requesting is permission to make some change to
that data to deal with the problem, yes?
A. Yes.
Q. Then you see at 10.41, that's two boxes down, the
request is approved?
A. Yes.
Q. That's not the end of the problems. If we were stopping
there, that would just be a use I imagine of the TIP
repair tool, yes? That wouldn't be something that would
be particularly interesting, do you agree?
A. Possibly, yes.
Q. But we don't stop there. If we go to page {F/432/2}, at
the top it is said by Andy Keil:
"This is due to a single SC line written for $1,000
(£484) with no settlement in the middle of two RISP
transactions."
So translating that into English, it appears to be
saying this is due to a single customer service line.
A. Served customer, I think.
Q. Written for $1,000 with no settlement in the middle of
two remittance transactions?
A. Remittance in, yes.
Q. "On call ... the harvester exception was corrected and
now the transaction for the day don't zero, hence this
issue with the incomplete summaries report."
A. Yes. Something, so has gone wrong with Horizon at this
point because the top line there about the single SC
line being written with no settlement is an indication
that something has failed and this report has picked up
that --
Q. Yes, it is not simply that there has been a harvesting
problem in transmitting the data into the TPS, actually
there is a problem with the data in the BRDB itself in
the final accounts, in that the accounts seem to contain
a transaction which has no settlement line --
A. Yes.
Q. -- which can't be right.
A. Yes.
Q. The writer says:
"Am currently retrieving the messagestore for this
branch, we will then be inserting a new message on the
counter to remove the effects of this."
It refers to:
"OCP 17510 has been raised."
Do you see that?
A. Yes.
Q. Now, on roll-over what is being described here would
produce a receipts and payments mismatch, wouldn't it?
A. Yes.
Q. I think you have already agreed, but if you haven't
I would invite you to agree now, that on roll-over those
mismatches are always picked up automatically and
referred to the SSC for investigation, correct?
A. I'm not sure whether that is an automated process or not
or requires somebody to --
Q. Well, it arises that there are various TPSC reports, for
example 268A, 257, that are triggered when there is
a receipts and payments mismatch on roll-over, are you
familiar with that?
A. I was not sure of that process. I believed on roll-over
if there was a receipts and payments mismatch then
there's various options that then can be used. I didn't
know whether there was an automated process.
Q. What I'm suggesting to you, Mr Coyne, and perhaps you
will agree this and perhaps not, if a receipts and
payment mismatch appears on the roll-over of a branch it
will get referred to the SSC, it doesn't have to be
referred by a postmaster?
A. Right.
Q. The SSC will be seized of the matter --
A. Yes.
Q. -- even if the postmaster himself doesn't phone in, yes?
A. Okay.
Q. Do you accept that?
A. I accept that that's a reasonable process. I --
Q. You are not sure?
A. I'm not entirely sure that it is automated as suggested,
but that's perhaps --
Q. But the MSC produces reports to the SSC which explain
that these exceptions have arisen on various TPSC
reports. You must have seen --
A. The MSC?
Q. Sorry, the MSU, I do apologise. The MSU sends in,
rather as happens here actually, a report saying
an exception has arisen in this report and then the SSC
looks into it. You have seen a large number of PEAKs of
that sort, haven't you?
A. Yes. So there is an automated report produced and then
somebody would look at that report.
Q. Thank you. So what happens is the system picks it up
and a PEAK is created and then people start looking into
what should happen, what has happened, yes?
A. Nearly right. I think the PEAK would be created after
somebody looks at it and decides a PEAK is required.
Q. The PEAK is created when the MSU sends a report in to
the SSC, correct?
A. I'm not sure that is correct. I think the report is
sent, somebody looks at the report, and then creates
a PEAK if a PEAK is required.
Q. I see. So what you are suggesting is a report is sent
in and a human being looks at the report and then
creates the PEAK?
A. Yes.
Q. That is the process which is followed?
A. Yes.
Q. There is no process by which a report is sent in and
then people sit on their hands and do nothing about it?
A. I would hope not, no.
Q. If we go down to 12 o'clock on 12th December:
"As was suggested by Anne Chambers yesterday, there
is a new exception on the TPSC257 (Incomplete Summaries
Report) for 11/12/2007. The report shows further
entries for this branch ..."
Then down the page to 12.33 on 12th December -- I'm
so sorry, down to right at the bottom of the page,
17.19, I do apologise, and this is by Andy Keil again:
"Worth noting that the branch didn't have any issues
with the mismatched transactions because this was fixed
before they did the roll. The branch is not aware of
this and it is best that the branch is not advised."
This is something that has been drawn attention to
and I think you kindly said that this is the only
example of something like this happening of which you
are aware, yes?
A. Yes, I can't think of anywhere else where it said
expressly: don't contact the customer.
Q. Then if we go to page {F/432/3} at 16.13:
"As detailed above the two POLS incomplete summaries
issues have been resolved.
"The counter problem which caused the first issue
has been corrected by inserting a message into the
messagestore, for equal but opposite values/quantities,
as agreed with POL (OCP ...)"
So we see there that the OCP was approved, yes?
A. Yes.
Q. "As a result of this corrective action, the net effect
on POLFS is zero, and POLFS figures are in line with the
branch."
Do you see that?
A. Yes.
Q. Which reflects the general principle that Fujitsu were
concerned to ensure that there aren't discrepancies
between the TPS system and the branch's own accounting
position, yes?
A. Yes.
Q. "POLMIS ..."
That's Post Office Management Information System.
"... received both the original message and the
corrective message.
"Once the problem was corrected, there should have
been no impact on the branch."
Do you see that?
A. Yes.
Q. And you understand why, don't you?
A. Yes.
Q. It is correct, isn't it, that where you have
a transaction that involves no settlement value then
once that is cancelled out the branch will properly
balance?
A. Yes.
Q. "However it has been noted that the stock unit BDC had a
loss of $1000, which was generated after the correction
was made. We have already notified Gary Blackburn at
POL ... This appears to be a genuine loss at the branch,
not a consequence of the problem or correction."
Would I be right in thinking that you question that
and that you are suggesting that in fact the $1,000 loss
was caused by the OCP, the transaction insertion?
A. Yes.
Q. And why do you say that?
A. Because I believe that the transaction insertion was
done incorrectly. I think the message that was inserted
did not reflect the right amount.
Q. Is this -- we will come to it in a minute, but there is
a document referring to 2,080. Is that the document you
are referring to?
A. I think that is the document.
Q. You think that that document indicates that a change of
2,080 was made rather than the $1,000 or £484 change
that should have been made?
A. Yes.
Q. And that that would have caused the $1,000 loss, yes?
A. Yes.
Q. Now would you accept, stopping there, that the process
that we have just seen of Fujitsu changing -- inserting
a settlement line -- inserting a transaction to cancel
out this unbalanced transaction, that is a relatively
rare occurrence?
A. Yes.
Q. It is not something which we see very much at all in the
PEAKs which we have all seen, correct?
A. That is correct.
Q. We see at the bottom of page 3, this is by Anne Chambers
who you have heard of before, she says:
"A single SC line was written for $1,000 (£484) with
no settlement, in the middle of two RISP transactions."
The line was missing some AdditionalData so it
wasn't harvested properly, but the main problem was the
lack of settlement. POL authorised us to insert an
equal but opposite message, to prevent a discrepancy (in
theory anyway) and to avoid problems on POLFS. Please
note that this is exceptional and must not be seen as
a convenient avoidance in place of a fix."
You would accept, would you, that what she says
there, which is that this is exceptional, don't expect
us always to be dealing with points of this sort, that's
fairly reflected in the PEAKs that you have seen, isn't
it? This is something that happens quite rarely?
A. Yes.
Q. You will see Ms Chambers says here that what was
inserted as a result of the OCP was an equal but
opposite message?
A. Yes.
Q. But you are suggesting that she is wrong about that and
in fact a larger amount was inserted, is that right?
A. Yes. Could I just ask, can we just go through this and
have a look at whether we see the message insert command
in this PEAK, please.
Q. I don't believe we do, but we do have the OCP and the
OCR.
A. If that is the case, that highlights one of the
difficulties that you have with identifying from a PEAK
when a message has been inserted.
Q. That's why we have OCPs and OCRs, isn't it, so you can
see -- the purpose of those documents is to record
precisely that information, would you agree?
A. The purpose of those documents is to request permission
from Post Office to do something, but that in itself may
not contain any search terms that would indicate that
a message has been inserted. There is no --
Q. In any event, it is the case, isn't it, that there are
OCPs and OCRs in this case which cause you to conclude
that there was an error made in the level of the
transaction insertion into the branch accounts, correct?
A. Yes.
Q. So let's look at that. First of all, let's look at the
OCP. That is at {F/432.2/1}. You will see what it says
here:
"A single SC message ... was written in error on
26th November ... selling 1,000 US dollars, with no
corresponding settlement line. To remove the effects of
this message at both the branch and on POLFS, we will
insert a new message to negate the effects of the
original message."
"Justification: If the change is not made in the
counter messagestore (before the stock unit is balanced
on Wednesday), the branch will have an unexpected gain
of £484 (or thereabouts - depends on exchange rate), and
a receipts and payments mismatch. This gain would have
to be resolved at the branch. There would also be an
inconsistency between the branch and POLFS to be
resolved. By correcting the problem locally, the branch
may not be aware of the problem, and there will be no
inconsistency between the branch and POLFS."
Do you see that?
A. Yes.
Q. And all those things are true, yes? If the right figure
is entered in, the branch will balance. There will be
no danger to the branch's balancing. The concern is if
the wrong figure is inserted, correct?
A. Yes.
Q. Then:
"Extra detail: The original message ..."
And this is the information I think you were
referring to in your answer previously?
A. Yes.
Q. "The original message had ProductNo:5129, Qty:1,
SaleValue:484, PQty:1000. The new message will have ..."
Then there are some similar words but basically the
opposite of what's in there.
"... with other attributes as before."
Do you see that?
A. Yes.
Q. So you can see precisely what was going to be done with
this transaction insertion, yes?
A. Yes. This isn't the message, this is just describing
here what information they are going to put in the
message when they create it.
Q. And what you are suggesting is that although that was
the intention, in fact the people that did it got it
wrong, yes?
A. Yes.
Q. And you do that on the basis of another document that we
will go to in a minute.
Then it says:
"The message will include a comment to show it has
been inserted to resolve this problem (this will not be
visible to the branch)."
So you will see this is consistent with Mr Parker's
evidence that when insertions are made, comments are
included so that it can be seen. In this case not by
the postmaster but it can be seen, so if anyone looks at
what has happened in the branch they will see there has
been an insertion by the SSC, do you see that?
A. If anyone back at Fujitsu looks at it they will know.
The postmaster wouldn't know though.
Q. Then it says:
"This change will first be applied to a copy of the
messagestore within the SSC environment, and the stock
unit then rolled over to make sure there are no
unexpected consequences. Neither the new nor the old
message will be included in the data sent to POLF."
This indicates that they were effectively going to
test the change before they actually made it, yes?
A. Yes.
Q. So it would be quite surprising, wouldn't it, if they
did a dummy run on a copy of the messagestore held by
the SSC, got a positive result, but then when they did
it in live action they actually produced the wrong
result. That would be quite a surprising mistake to
make, I think you would agree?
A. I'm not sure that the test they conducted would have the
ability to see that level of sophistication because
I think what they are going to test here is that the
message can be successfully inserted. They only have
a copy of the messagestore that they have taken and that
will be probably at maximum 24 hours of transactions.
Q. Are you sure that's fair, Mr Coyne, because they do say:
"... and the stock unit then rolled over to make
sure there are no unexpected consequences."
So what they are going to do is make the insertion
in the dummy account, they are then going to roll the
dummy account over and see what the consequences are.
Wouldn't it be fair to assume that -- aren't they
precisely saying that in those circumstances they are
going to type in what they intend to do, make sure that
it has the intended effect and allows a roll-over with
a proper balance, and then once they have satisfied
themselves that that is right they will then do it in
live use, yes?
A. It could be, yes.
Q. Are you suggesting they mean something else?
A. There isn't a great deal of detail there. I don't know
what the set up of the SSC environment is. We don't
know how much of the messagestore is in there.
Q. So you are saying that because you are seeking to resist
the impression that you perceive I'm trying to give,
that the notion that the transaction insertion involved
an error is quite surprising, and you don't want to
accept that and the way you respond to that is by saying
you don't know precisely what they did, is that right?
A. I do not think either of us now know precisely what that
test did.
Q. I would like to suggest to you, Mr Coyne, that it is
painfully obvious what the test did. They applied the
change they were going to apply on a test rig which had
an identical copy of the messagestore of the branch,
they rolled it forward, and then they saw what the
consequences were. What else could that sentence be
talking about?
A. And would that test environment then have a look at the
impact on what the branch accounts would be?
Q. Yes.
A. Or are they just looking at whether a roll-over can take
place or not?
Q. Very well. Let's go on to the OCR, because it is the
OCR which is the basis of your suggestion that in fact
they inserted the wrong figure, yes?
A. Mm.
Q. It is at page {F/434.1/1}:
"Extra detail: This OCR is being raised so that EDSC
..."
Do you know what EDSC is?
A. I don't. It may appear in the glossary.
Q. You see it in a lot of PEAKs, don't you?
"... is authorised to amend the transaction details
for [that branch] and insert these into
_pol_fs_summaries_incomp table on the host."
You see what's being described here. The consent
that is being sought here is for an insertion into
a POLFS table in the TPS?
A. Yes.
Q. "Comments:
"Andy Keil ... wrote at 12/12/2007 ... Updated POLFS
feed for branch 183227 product 5129 mode SC with
SaleValue=1014.73 and PQty=2080."
Do you see that?
A. Mm.
Q. And what you are suggesting is that that insertion would
have caused an imbalance, would have caused -- could
have caused a loss in the branch?
A. Yes.
Q. If we go down to "Other details", you see the last entry
on "Other details"? It says:
"Change type: TRT."
What does that mean?
A. TIP repair tool?
Q. Yes. So what they are talking about here, what this
change here is, is a change being made by using the TIP
repair tool into the TPS, correct?
A. Right, so this doesn't relate to the creation of the
message then.
Q. It doesn't relate to the branch accounts, Mr Coyne, does
it? This is an OCR which involves an exercise -- well,
the use of the TIP repair tool to change data that is in
the TPS system, yes?
A. Yes, but the PEAK refers to the insertion of a message
into the messagestore.
Q. Yes, the PEAK and indeed the OCP we have just looked at.
It is the OCP which deals with the transaction insertion
into the messagestore. The OCR isn't concerned with the
transaction insertion into the messagestore, is it? The
OCR is concerned with a change made via the TIP repair
tool of the data that's held in the TPS, correct?
A. Right, yes.
Q. So it follows as night follows day that whatever change
was made as a result of this tool, it didn't affect any
change to the branch accounts, it didn't constitute
an insertion into the messagestore for the branch, do
you agree?
A. So if I follow correctly, what you are putting to me
here is that what we see within this OCR is a secondary
form of correction via the TIP repair tool?
Q. Yes.
A. After the message that was inserted into the
messagestore?
Q. It doesn't matter whether it was after or before. What
matters is that this document and the transaction, the
work that it covers, is nothing to do with the
messagestore of the branch and I would like you to
accept that.
A. Whilst it might be nothing to do with it, it is making
an alteration to the branch accounts.
Q. Mr Coyne, I have spent something like 45 minutes this
morning seeking very carefully to get you to agree, and
to be fair to you, you did agree, that when a change is
made using the TIP repair tool it doesn't change the
branch accounts, it doesn't affect the messagestore of
any branch, it only affects the data within the TPS
system.
A. Yes.
Q. If you want to make a change to the accounts you have to
insert a transaction?
A. Yes.
Q. Using the facility in Legacy Horizon?
A. Yes.
Q. That facility is approved pursuant to the OCP we saw
before we looked at this document. However, there were
two problems. There was a problem with the
messagestore.
A. Yes.
Q. And there was also a separate problem with the POLFS
data, the data that was in the TPS system.
A. Yes.
Q. This OCR is concerned with getting authorisation to make
the change to what's in the --
A. TPS system, and the PEAK was to do with making
the change.
Q. The PEAK covered both problems. You will recall that
there are two changes referred to. There are OCRs
referred to in the PEAK and there is an OCP referred to
in the PEAK.
A. Yes.
Q. And I have taken you to the OCP first of all and now we
are looking at an OCR.
A. Right. Could I please have a look at the time within
the PEAK that the observation about the $1,000 was made?
Q. Yes, by all means.
MR JUSTICE FRASER: That's exactly what I'm doing actually.
MR DE GARR ROBINSON: It is F/432 --
MR JUSTICE FRASER: There is page 1 and 2, I think. The
PEAK is {F/432/1}.
MR DE GARR ROBINSON: The reference to the $1,000 loss
though is on page {F/432/3} about four boxes down,
14 December at 16.13.
MR JUSTICE FRASER: I think the OCR that you have just been
putting, Mr de Garr Robinson, is one of the ones
mentioned on page 2, is that right?
MR DE GARR ROBINSON: Yes, my Lord, I believe so.
MR JUSTICE FRASER: Because actually it says on
12th December 2007 at 16.39:
"User: Andy Kiel. Details of how POLFS feed was
corrected 12.12.2007."
Is that the one?
MR DE GARR ROBINSON: My Lord, yes .
MR JUSTICE FRASER: Which appears on the line before. It is
also on page 432/2 in the entry immediately before.
MR DE GARR ROBINSON: Absolutely. Sorry?
MR JUSTICE FRASER: For some reason on my screen the two
entries are highlighted in blue, I thought it was
a hyperlink. It is the antepenultimate entry on page 2
and the one before it, isn't it? Aren't they the exact
documents you have been using?
MR DE GARR ROBINSON: At 12th December 2007 at 15.06 there
is a reference to the OCR.
MR JUSTICE FRASER: Yes, and then underneath --
MR DE GARR ROBINSON: Details of how the feed was corrected.
MR JUSTICE FRASER: Yes, and that's what you have been
putting.
MR DE GARR ROBINSON: Yes.
Does that help you, Mr Coyne?
A. Because we know that the TPS side of the fix to this
problem happened on 12th December at 15.07. The
observation about the £1,000 was on 14th December.
MR DE GARR ROBINSON: Yes, when the roll-over was done or
after the roll over was done.
A. So the bit that's missing is we need to see the message,
so that is the OCP. Can we see the time --
Q. Mr Coyne, when I asked you about this before you said
there was a reason why you thought there was an error
made in the transaction insertion and that's because
there was a document which showed the figure of 2,080
being inserted yes?
A. Yes.
Q. And that figure is on page {F/434.1/1}, it is in the
OCR.
A. Yes.
Q. I can tell you on instructions what that figure means.
If we go under "Comments":
"Updated POLFS feed for branch [blah, blah, blah]
with SaleValue=1014.73 and PQty=2080."
You will recall that the transaction itself was
removed from POLFS. The $1,000 transaction, the £484,
it was removed from POLFS. You remember seeing that in
the PEAK?
A. Yes.
Q. But what's left is the aggregate of all the remaining
dollar conversion transactions which have been
undertaken in the relevant period.
A. Yes.
Q. So on instructions I can tell you that the sale value of
1,014.73 and the quantity of 2,080, those figures relate
to what is the aggregate of the figures that are left in
the system after you remove the one-sided transaction
that the parties were concerned about.
A. Right.
Q. It would be difficult to understand them otherwise,
because 1,014.73 bears no relation to £484 or to $1,000,
does it?
A. No, I agree with that.
Q. I appreciate that I'm telling you this on instructions
because I have to say nobody knew that this suggestion
was going to be made until it was put to Mr Godeseth
when he was being cross-examined, but in actual fact it
follows as a matter of logic, doesn't it, that whatever
the explanation of these figures -- sale value 1,014 and
quantity 2,080 -- whatever the nature of those figures,
those figures actually have no impact on the
messagestore on the branch accounts that could have
caused a $1,000 loss?
A. Well, the $1,000 loss would be because of a difference
between the two, and you are making change to the branch
within the messagestore and you are making a change to
the backing systems to the TPS.
Q. Let's go back to page {F/432/3}, please. This is
Anne Chambers explaining what has happened. She has all
the documents and she has sight of what's going on in
the messagestore, yes?
A. Yes.
Q. She says in the third paragraph -- the second paragraph:
"The counter problem which caused the first issue
has been corrected by inserting a message into the
messagestore, for equal but opposite values/quantities,
as agreed with POL ..."
A. Yes.
Q. She has seen the transaction that is done and it is her
view that what was inserted was an equal but opposite
value, yes?
A. Yes.
Q. And she then goes on:
"As a result of this corrective action, the net
effect on POLFS is zero, and POLFS figures are in line
with the branch. POLMIS received both the original
message and the corrective message."
Do you see that?
A. Yes.
Q. "Once the problem was corrected, there should have been
no impact on the branch. However it has been noted that
the stock unit BDC had a loss of $1000, which was
generated after the correction was made."
A. So between the 12th at midday but before 14th when this
is recorded.
Q. The OCP was made -- the OCP was raised on 10th December,
you see that at the top of page {F/432/2}, and the
correction was made to the messagestore on 11th
December. That's on page 2, six boxes down. Do you see
that?
A. One of the documents said 12th December at 15.07, either
the OCP or the OCR.
Q. 12th December, 15.07?
A. Yes, at the time of 15.07, I believe.
MR JUSTICE FRASER: That is the OCR which is on --
MR DE GARR ROBINSON: Yes, that is the TPS. What happens is
there is an OCP that is done, that's actioned on
11 December, so the messagestore is changed on
11 December.
A. Yes.
Q. Then there is an OCR which changes the TPS on
12th December.
A. Yes.
Q. And then on 14 December Anne Chambers is reviewing
everything that has happened and she said the
transaction insertion goes through fine, but after it's
gone through a $1,000 loss has appeared on a particular
stock unit.
Now you latched onto the OCR with a view to
suggesting that because the figure of 2,080 was used
rather than 1,000, and because the figure of 1,014 was
used rather than 484, you latched onto that and thought,
aha, there must have been an error in this insertion and
that error must have been responsible for the loss.
What I'm suggesting to you, Mr Coyne, is that's not
right, because this is a change that was not made to the
messagestore, it was made to the TPS system, do you
agree?
A. There were two changes, one to the messagestore and one
to the TPS system.
MR JUSTICE FRASER: I think that's agreed.
MR DE GARR ROBINSON: I will move on.
MR JUSTICE FRASER: Just before you do, I appreciate you
have been putting these points on instruction, as you
put it. I would really quite like to understand the
chronology in detail, I'm pretty sure I do, but I'm just
going to tell you what my understanding is because it is
taken from the PEAK.
MR DE GARR ROBINSON: My Lord, yes.
MR JUSTICE FRASER: And it is simply so that you can tell me
if I haven't got it right.
The PEAK is raised, and I find page 2 of the PEAK
most useful because it actually says when the OCPs are
created and when the OCRs are created.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: The OCR is created on 10th December 2007
at 17.25, is that right?
MR DE GARR ROBINSON: The OCP, my Lord, yes.
MR JUSTICE FRASER: I beg your pardon.
MR DE GARR ROBINSON: That is the transaction insertion into
the messagestore.
MR JUSTICE FRASER: On 10th December 2007 at 17.25.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: It actually says "OCR" on here.
MR DE GARR ROBINSON: Your Lordship is absolutely right.
MR JUSTICE FRASER: I was about to come onto the OCP which
I think is 40-odd seconds later.
MR DE GARR ROBINSON: Your Lordship is absolutely right.
I'm sorry to have spoken too soon.
MR JUSTICE FRASER: No, it is just important for me to
understand it. So there is an OCR at 17.25 which is
referenced here on 10th December, and there is also
an OCP literally about a minute later. Am I reading it
correctly?
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: Then we come further down the document
and there is a reference on 12th December, both at 15.06
to the actual OCR and then at 16.39 to details of how it
was corrected, and those two entries should effectively
be read together, is that correct?
MR DE GARR ROBINSON: My Lord, I believe so. So the OCR was
given effect to on the 12th.
MR JUSTICE FRASER: So as at the 12th, whatever is being
done to the system has in fact been done, is that right?
MR DE GARR ROBINSON: My Lord, I believe so, yes.
MR JUSTICE FRASER: Then the review where Ms Chambers says
what she does on 14 December, 16.13, is after those
changes, is that right?
MR DE GARR ROBINSON: My Lord, yes.
MR JUSTICE FRASER: That's all I need to do. I just wanted
to confirm that because I obviously can't go to
a witness statement to look at it. Back to you.
MR DE GARR ROBINSON: So I've spent 40 minutes on this one
document and I rather think I need to get on.
If we could go back to the joint statement, please.
That's {D1/5/4}.
A. Sorry, what page number, please?
Q. I'm sorry?
A. What page number?
Q. Page 4.
A. Yes, I have that.
Q. It is the third bullet point in paragraph 10.2.
A. Yes.
Q. There is the third form of remote access which is
deletion of messagestore data?
A. Yes.
Q. We know that wholesale deletion of the messagestore was
possible as part and parcel of the automatic back up
process that we talked about and of course that involves
no discretionary manual deletions. Could I ask you,
what examples have you found of discretionary manual
deletions of transactions in the messagestore?
Individual transactions?
A. No, it is typically wholesale.
Q. Thank you. So you are not aware of there being any
example of a discretionary deletion of a particular line
of transaction data in Legacy Horizon, are you?
A. No. The typical way of dealing with it will be
an insertion of a balancing --
Q. Thank you. Nor are you aware, are you -- I have gone
through your reports quite carefully and if I have
missed it, it is my fault -- of any edits in
Legacy Horizon of any lines of transaction data? No
example of that has been identified, has it?
A. Yes, messages are transferred to Fujitsu to enable them
to edit the message and then reinsert the message.
Q. So transaction insertions possible?
A. Yes.
Q. But if you have got a piece of data, a line of
transaction data or whatever in the messagestore, you
are not aware of any example of remote access whereby
someone gets into the messagestore and edits that line
of data, are you?
A. Well, they are editing a line of data, they are bringing
the messagestore back to Fujitsu, editing the line of
data and then sending it back.
Q. Mr Coyne, I understand that the practical effect of
inserting a transaction could be -- is a change in the
entirety of the contents of the messagestore, so in
a loose sense you could say the messagestore as a whole
has been edited. But I would like to be really clear.
I'm just asking you the narrow question: have you seen
any example of someone at Fujitsu, or indeed anyone
else, accessing a branch's messagestore remotely, so
from their office, and fiddling about with a transaction
that's currently in the branch accounts, in the
messagestore, so as to change its value or change any
other of its basic transaction details?
A. I have not seen evidence of changing of value but I have
seen evidence of editing other data around it.
Q. I'm being really clear now because I tried to establish
some clear ground rules when we were talking about what
constituted transaction data and what constituted
accounting data. Are you aware of any example of some
transaction data having been changed, having been edited
remotely by someone at Fujitsu?
A. Yes, if we --
Q. In Legacy Horizon?
A. If we go to {F/337.1/1}.
Q. Would you like to talk me through this PEAK?
A. Is this 337.1?
MR JUSTICE FRASER: No, this is 337/1. You want
{F/337.1/1}?
A. Yes, my Lord.
MR JUSTICE FRASER: Can we go to that, please.
MR DE GARR ROBINSON: My Lord, I do not believe there is
a 337.1.
MR JUSTICE FRASER: That is the answer to that then. There
is no 337.1.
MR DE GARR ROBINSON: Let's move on then --
A. Can I give you the PEAK number? I have got the PEAK
number. It is PC0142763.
Q. That's {F/377.1/1}. This is not a PEAK I have seen. Is
it referred to in any of your reports?
A. I'm not sure. I would have to do a search on that and
see. There are many that are referred to in my report.
Q. I'm rather wondering, Mr Coyne, whether you came armed
with this document having found it after you provided
both your reports but without warning anyone in advance
that that's what you were doing. It does seem curious
that you have committed this particular PEAK to memory?
A. No. My Lord set some homework for me and I started it
at lunchtime and that is the first one that I have done
and it relates to this particular --
MR JUSTICE FRASER: I do not think I set you that homework.
A. Sorry.
MR DE GARR ROBINSON: This isn't referred to in any of your
reports, so it is a voyage of discovery for me. Would
you like to talk me through this PEAK? It is rather
difficult, but if you could do it without taking too
much time I would be grateful.
A. Yes, okay. If we go straight to the end, because that
shows the editing process {F/377.1/6}, this is where we
have got the message being edited. So it looks like it
was -- I think the ID is the counter ID and it has been
changed from 1 to 11 and from 2 to 12. And then I think
the fourth line down you see the transaction.
MR DE GARR ROBINSON: Mr Coyne, I have never seen this
document before but I venture to suggest that this is
an example of a transaction insertion, yes?
A. They are inserting a transaction, yes.
Q. So this is an example of a case where the SSC,
I presume, has a transaction that it wishes to insert
into the messagestore which everyone agrees that SSC has
the power to do?
A. Yes.
Q. My question was different. My question was are you
aware of a single example of someone at the SSC sitting
at a screen in his office in a secure area where the SSC
operated, gaining access to someone's messagestore, some
branch's messagestore, looking at a transaction that is
in the messagestore, and then by using his machine
editing the transaction that's on the messagestore?
That was my question.
A. No, because that isn't the process that's done. The
process is that the messagestore is transferred back to
SSC, the edit is made, and then it is transferred back.
Q. So the answer to my question, which was very carefully
formulated, is that you are not aware of any occasion
when a transaction has been edited by a form of remote
access. You are only aware of occasions when
transactions of one sort or another have been inserted,
is that right?
A. This has been inserted but it is a message that was
already in the messagestore that has been brought back,
edited, and pushed back again.
Q. Mr Coyne, I'm just trying to be really clear about
concepts. The Horizon Issues talk about insertions or
injections of transaction data, it talks about deletion
of transaction data, and it talks about editing of
transaction data. You very kindly admitted that you are
not aware of any case where there has been a remote
deletion of transaction data.
A. Right.
Q. And I was suggesting to you that nor were you aware of
any case where there has been an example of remote
editing of transaction data. That means that the only
form of remote access that's left in Legacy Horizon is
transaction insertions.
Now, what you have just brought me to, and we have
taken 10 minutes on it, is an example of a transaction
insertion, yes?
A. It is an insertion but it is insertion of a transaction
that was already there. So effectively it is
a modification. It is not a new transaction.
Q. Let's move on. I'm getting anxious -- I'm already very
anxious about time.
That deals with the facilities for remote access in
Legacy Horizon, doesn't it?
A. Yes.
Q. So let's look at Horizon Online now and let's do it as
quickly as we can. If we go back to page {D1/5/4}, and
I hope I can take this quickly. We have dealt with the
three Legacy Horizon entries at the top of
paragraph 10.2, yes?
A. Yes.
Q. Then there is a Horizon Online form of remote access:
"Injection of a transaction --"
Let's leave that one out.
"In Horizon Online, using the balancing transaction
tool ... as defined below."
A. Yes.
Q. Now, the balancing -- we call it the balancing
transaction tool, just inserts transactions, yes?
A. Yes.
Q. Into particular tables in the BRDB where transaction
data is held, yes?
A. Yes.
Q. I hope I can take this relatively quickly. It is agreed
that that tool writes to a particular audit log, yes?
If we go to page {D1/5/14} of this very document.
A. It writes to a journal file, yes.
Q. If we look at paragraph 12.3, it is agreed that that
tool writes to this journal, yes?
A. Yes.
Q. The audit log for that journal has been disclosed,
correct?
A. I think the journal itself has been disclosed.
Q. That's what I meant. The journal is the audit log,
correct?
A. I don't know if anyone audited it or not, but it is
a record of use. That is the journal of use.
Q. Yes, its purpose is to stand as an audit log so you can
go and see what uses have been made of the relevant
tools?
A. That's its purpose, yes.
Q. Would I be right in thinking you agree there's only been
one use of the transaction correction tool to insert
transactions into the BRDB, is that correct?
A. Using that tool, yes.
Q. If we can now move on. I would like to ask you
a question about your second report, it is at
{D2/4.1/72}. It is paragraph 3.223. Here you refer to
a PEAK which is at {F/594/1}, which I hope we won't need
to go to in light of what you have already said. You
say: it:
"... suggests that the modifications by Fujitsu
support staff to the Horizon Branch Database (BRDB) is
not unusual."
I think we can agree that that PEAK, which is at
{F/594/1}, I'm not suggesting we go to it, is a PEAK
which discusses whether immediately after the one use of
the transaction correction tool that we are aware of --
perhaps let me put it to you this way. Does it ring
a bell that the one use that we are aware of was given
effect to, happened on 11 March 2010, very early on in
the life of Horizon Online, does that ring a bell?
A. Yes.
Q. And this PEAK is opened the day after it on 12th March,
yes?
A. Yes.
Q. And it is opened by the person that made the balancing
transaction in the first PEAK?
A. Right, yes.
Q. Do you remember that?
A. Yes.
Q. And what happens is that person says "We have now used
the tool and I can think of some ways in which we can
improve it"?
A. Yes.
Q. Then there is a debate during the course of the PEAK as
to how it could be improved. No sense of urgency, the
PEAK goes on for quite a long time, do you remember
that?
A. Yes.
Q. Eventually it is agreed that certain changes will be
made, and ultimately after a long time those changes are
made to the transaction correction tool. Do you recall
that?
A. Yes. They talk about typically trying to create
templates, so that when people use it in the future they
fill in a template to make the tool easier to use and to
ensure there are less risk problems when using it.
Q. You say in paragraph 3.223 that this PEAK:
"... suggests that the modifications by Fujitsu
support staff to the Horizon Branch Database ... is not
unusual."
What you are suggesting is having regard to the
PEAK, you think the transaction correction tool to
insert transactions is not unusual, it happens more
often than once. That's what you are inferring from the
PEAK, correct?
A. No, from what the PEAK says, the process of doing it
does not seem unusual or unfamiliar to people.
Q. Yes. I have a series of questions to ask you about that
by reference to the PEAK.
A. Yes.
Q. But I can shortcircuit all of those questions by
indicating that in actual fact you accept that the
transaction correction tool was only used once to insert
transactions into branch accounts, yes?
A. Yes. There are other tools that are written to the same
journal, but only one of those journal entries show this
particular tool being used to edit the BRDB with regard
to transactions.
Q. Just to be clear, here you are suggesting the use of the
tool is not unusual, you're suggesting there's a
significant number of uses of the tool, and I'm really
not suggesting any criticism of you, Mr Coyne, at all,
but just to be clear for his Lordship's note, actually
you accept it only happened once, correct?
A. I accept that this tool was only used once to insert a
balancing transaction.
MR JUSTICE FRASER: That's three times I have now got that.
MR DE GARR ROBINSON: I'm grateful, my Lord.
MR JUSTICE FRASER: I generally have them first time but
three times -- I can understand why you put it again,
but I'm just saying I do have it.
MR DE GARR ROBINSON: Thank you for the clarity, my Lord.
Then if we can go back to {D1/5/4}. These are your
forms of remote access. At the bottom you say:
"In both Legacy and Online, usage of the transaction
repair tool to fix transaction data within the Horizon
..."
We don't need to spend any time on that because you
agreed that that tool isn't used for the purposes of
injecting or deleting or editing any data in any branch
accounts, correct?
A. There is another use of that tool or the journal and
that is to remove the recovery flag.
Q. I'm sorry, Mr Coyne, I think it may have been my fault.
When you say transaction repair tool, I should probably
have said TIP repair tool. You are referring to the TIP
repair tool here, aren't you?
A. No, the balancing transaction tool. Its use -- it
appears its use was widened. This was covered in the
evidence of I think it was Mr Godeseth.
Q. Mr Coyne, I don't understand. You have dealt with the
balancing transaction tool in the previous bullet point.
A. Yes.
Q. My understanding was that in the next bullet point,
where you refer to the transaction repair tool, the only
tool that I'm aware of that has "repair" in its name was
the TIP repair tool. Were you not referring to the TIP
repair tool?
A. Sorry, I was.
Q. So we can agree, can't we, that in accordance with the
definition of remote access that I suggested at the
beginning of this conversation, then that bullet point
can come out, can't it, yes?
A. Following your specification of what remote access is,
yes.
Q. Thank you. So what we are left with is the bullet point
above the balancing transaction tool, which is SQL
injection line editor?
A. Yes.
Q. That's by privileged users, yes?
A. Yes.
Q. And would it include use of the APPSUP role?
A. Yes.
Q. Here's some common ground. Privileged users have strong
powers to add, delete and edit data, don't they?
A. Yes.
Q. You and Dr Worden agree, I think, that the abilities of
that kind are necessary for the administration of any
database of this sort?
A. Yes.
Q. I imagine you are not aware of any big system which
doesn't have such facilities, yes?
A. There needs to be a super user access somewhere, yes.
Q. So the mere existence of this right of access does not
indicate that the system is insecure, does it?
A. It would indicate that it's insecure if that access is
given to too many people, yes.
Q. It doesn't necessarily follow from the existence of
these powers that it was in fact used to alter
transaction data, necessarily?
A. That doesn't -- yes.
Q. So the question is whether and to what extent it
actually happens and in what circumstances, yes?
A. Yes.
Q. Could you explain how an SQL line editor would be used
in a case of this sort? I mean the BRDB has over 250
tables, doesn't it? Is it quite a complex process to
change those tables in a way that doesn't cause problems
within the system as a whole?
A. No, I mean the good thing about the SQL command is that
you can use it to look up information that's in there
and get it to return a value and then change that value.
It is quite easy when you use the SQL tool.
Q. Could I ask you to look, please, in your second report,
{D2/4.1/83}, at paragraphs 3.266 to 3.276. I'm not
going to read them out loud, I'm going to deal with them
as quickly as is humanly possible.
These paragraphs deal with the use of -- is it the
use of SQL to delete certain kinds of data?
A. Yes.
Q. You refer to a number of PEAKs. Let me see if I can
take this in stages without having to go to any of them.
It is inevitable in any network system that you could
get a network outage, yes?
A. Yes.
Q. So systems have countermeasures in place against such
eventualities?
A. Yes.
Q. And one of the systems that Horizon has in place is the
concept of the recoverable transaction?
A. Yes.
Q. And what happens when you are typing a transaction into
the counter is that recovery data is constantly
transmitted to the BRDB and stored in various tables in
case it becomes necessary to use it?
A. Yes.
Q. But all that data becomes irrelevant once the
transaction is entered into the -- once the basket is
committed to the BRDB --
A. Yes.
Q. -- and the transaction enters the account.
Now, there are a number of states that recovery data
has, aren't there? There's active, which is the
recovery data is active and will be returned to the
counter should failure occur?
A. Yes.
Q. And there is completed, that's where the recovery
process has been completed and the transaction is
recovered?
A. Yes.
Q. There is a third state, which is outstanding, which is
that the recovery process was unable to recover the
transaction for some reason and to allow the counter to
proceed, the recovery data is marked as outstanding and
needs to be manually resolved by support staff?
A. Correct.
Q. Now, the PEAKs that you are talking about here relate to
transactions involving recovery data which is stuck in
the outstanding state, don't they?
A. Yes.
Q. So the recovery process was unable to recover the
transaction and the recovery data is therefore marked as
outstanding and needs to be manually resolved by support
staff?
A. Yes.
Q. The effect of that is that it can prevent the branch
from rolling over and sometimes it can prevent counters
from working, I think?
A. Yes. What should happen is that you reboot the counter.
The counter sees the recovery flag, looks at the state
of the data, and hopefully can clear itself up, if you
will, deciding which transactions to proceed with and
which to back out of. The problem that occurs sometimes
is that that process fails and it can't automatically
recover.
Q. Yes.
A. And you end up switching the branch off and back on
again and it just keeps trying to --
Q. One of the examples in one of these PEAKs is where the
clerk was logged on to the counter and then never logged
off and then the counter was taken away. You remember
that? Does that ring a bell?
A. I do, but I don't quite know how it relates to --
Q. Anyway, in these PEAKs there is discussion of deletion
of the session to allow the block that's constituted by
the recovery marker from preventing the branch from
operating and rolling over, correct?
A. Yes.
Q. In those PEAKs, SQL script is used in order to delete
the session so that it will have that effect, do you
agree?
A. Yes.
Q. So in that process, no data that's actually in the
branch accounts is affected at all. In each of these
PEAKs no change is made to any of the transaction data
or other accounting data that's actually already in the
branch accounts, correct?
A. That is where the problem is, that you are deleting
session data without going through the understanding of
what position that session data is in.
Q. And in each of those PEAKs a determination is made that
the relevant transaction hasn't actually been
undertaken, it doesn't need to be inserted, doesn't need
to be included into the branch accounts, and the
subpostmaster is involved and onside and aware of what's
going on, do you agree with that?
A. There isn't a PEAK for every time when that happens.
Q. Why would there not be a PEAK when it happens? Surely
there would always be a PEAK when it happens?
A. The main KEL that covers this scenario is an
Anne Chambers' KEL and that KEL reference is 3/400
PEAKs.
Q. Is it ACHA 959T that you have in mind?
A. It might well be.
Q. I believe it may refer to about 2,000 PEAKs, yes?
A. I do not think it is that high of a number.
Q. Maybe 1,000.
A. I think there is a table in the report that goes to
that, it talks about how many PEAKs are referenced in
that KEL --
Q. I think I was probably trying to be a bit clever,
actually, Mr Coyne, and I think I should apologise for
being incautious in that endeavour.
A. I do not think there is a PEAK for every time that
happens.
Q. Well, Ms Chambers' KEL, ACHA 959T, is a list of
instructions about what to do in various different
scenarios, yes?
A. Yes.
Q. It doesn't concern any bugs in Horizon, it is just if
this happens then this is how it should work, if this
happens then this, and if there is a problem the SSC
should do this. That is the nature of the --
A. Yes, it does result from a bug, error or defect in
Horizon because the process should be that it recovers
itself.
Q. I'm going to suggest to you, but I'm not going to go to
it, that if you go through that particular KEL you will
find that it simply addresses various recovery issues
that can arise in practice?
A. Yes.
Q. And suggests how the SSC and other stakeholders in the
process should deal with them when they do arise?
A. Yes, it does.
Q. And my suggestion to you is that it doesn't actually
consider any bugs in Horizon, it doesn't suggest
workarounds for bugs in Horizon, that's not the purpose
of that KEL?
A. The whole process is a workaround because the system
isn't designed to do that, so something has failed. So
it talks about the various workarounds to get the
counter up and running again.
Q. Mr Coyne, we will have to agree to differ on that. My
suggestion to you is that this is just an explanatory
KEL which explains how the system works. It is actually
describing how the system should work, it is not
describing what should happen when the system fails, but
I can see that we are not going to agree about that.
A. It is inconsistent that users should be expected to go
through to Fujitsu third line report to deal with
a problem that almost should happen. That can't be
right.
Q. I think we agreed -- I must go more quickly -- the other
day that the recovery process, because it involves third
parties, there is inevitably going to be a situation
where a manual inquiry needs to be made as to what
happens on the ground, and then steps need to be taken
to reconcile what happens on the ground with what's
recorded in the accounts, and that is inherent in the
process of having recoverable transactions. Would you
agree with that?
A. Yes, but that isn't a manual process. Typically it is
an automated process which happens thousands of times
per month across the estate. A few of those, but it is
in the thousands, the recovery will not be automatic and
it requires a call to Fujitsu, it goes to third line
support, the Anne Chambers KEL is considered and that
process is used, a SQL command is used to delete some of
the session data, and then the counter is back up and
running.
Q. Mr Coyne, I will just leave it here. I was asking you
about the PEAKs that are referred to in these paragraphs
under the heading "Deletion of Data" in your report.
A. Yes.
Q. And my suggestion to you is that in none of those PEAKs
was there actually any change made to transaction data
contained in any branch accounts, would you agree with
that?
A. There was no change but there was deletion.
Q. Not of data in branch accounts. There was deletion of
data relating to recovery markers which were concerned
with sessions, would you agree with that?
A. Yes, but contained within there is session data that's
in an unconfirmed state that needs dealing with.
Q. Yes. And in each of those cases it was dealt with in
consultation with the subpostmaster to ensure that the
accounts were right, to ensure that nothing was done
which produced an inappropriate result for the accounts.
Would you agree with that?
A. I agree actually with the process, yes.
MR JUSTICE FRASER: I don't want you to go to it now but can
you just give me that reference for that KEL that you
memorised, in due course.
MR DE GARR ROBINSON: It is ACHA --
MR JUSTICE FRASER: No, I mean the trial bundle reference.
Don't spend time now, just mean give it to me whenever.
And we are going to have to have a short break. Is now
a good time?
MR DE GARR ROBINSON: We are, my Lord, and that is a good
time.
MR JUSTICE FRASER: We will come back in at 3.20 pm.
Were you about to give me a reference?
MR GREEN: {F/1700/1}.
MR JUSTICE FRASER: Thank you very much.
3.20 pm.
(3.13 pm)
(A short break)
(3.20 pm)
MR DE GARR ROBINSON: Mr Coyne, one last PEAK to go to in
relation to SQL and that's referred to in your report.
Why don't we have a quick look at your report at
paragraph 3.275. So it is {D2/4.1/84}.
A. Yes.
Q. This is a reference to a PEAK, PC0197592:
"... details an error whereby rollover cannot be
completed due to system error. Gareth Jenkins of
Fujitsu states ..."
Then you quote what he writes there and you say:
"This is indicative that Fujitsu, by creating SQL
scripts, could delete relevant records in order to
negate previous operations."
We both agree that privileged user access is a
powerful thing.
A. Yes.
Q. Then you continue:
"Whilst this is not necessarily deletion of
transaction data, it is the modification to operations
that are all intrinsic to transaction accounting."
I wonder whether we can take this quickly. You
accept, don't you, that the operation that was
undertaken here didn't involve deletion of transaction
data, would you agree with that?
A. It deleted an opening balance.
Q. Yes, but it didn't delete transaction data, it deleted
an opening balance, yes?
A. I do not understand why an opening balance isn't part of
transaction data.
Q. Data relating to a transaction that's done by the
branch. It didn't delete that. I rather thought you
were going to accept that because you said:
"Whilst this is not necessarily deletion of
transaction data ..."
Are you suggesting that deleting an opening balance
is deletion of transaction data?
A. Well, it changes the postmaster's accounting position.
But, no, I can accept that it isn't one of the
transactions of selling things or paying your money or
whatever, but it would have an effect on --
Q. This is the one other example of SQL scripts that you
have seen, privileged user access that you have seen
affecting branch accounts?
A. Yes.
Q. So there are the three PEAKs that we discussed before
the court broke?
A. Yes.
Q. And then there's this one other PEAK?
A. Yes.
Q. And those are the examples of which you are aware,
correct?
A. I believe there are some more, these are examples.
There are other examples of SQL statements --
Q. Which are similar to these ones? Presumably you put
them in your report because you felt these were the ones
that the court should be told about?
A. Yes, there are others but --
Q. These are representative of those others?
A. Yes.
Q. Thank you. So let's go very quickly to {F/611/1},
please. This is dated 15th April 2010, so it is during
the -- it was a branch which had migrated to
Horizon Online during the pilot project, do you
remember?
A. Yes.
Q. So there were a relatively small number of branches that
were sort of being tested, and this was one of them and
it had a problem.
If we could go to the first box on page 1 about
halfway down, it says underneath the double line:
"When rolling over and doing branch trading
statements site gets message unable to connect to the
data centre."
Do you see that?
A. Yes.
Q. So the branch had a problem that it couldn't roll over,
yes?
A. Mm.
Q. If we go over to page {F/611/2}, about two-thirds of the
way down the page, 13th April at 13.33:
"The branch did not complete their office rollover
properly on 17 March so the office is still in TP 11
although all the stock units are in TP 12. There was no
system failure - it looks as if they pressed cancel
instead of confirm at the end of the rollover process."
So at that early stage it appears it might be some
human intervention that's responsible.
Then if one goes to the bottom of page 2 but more
particularly on the top of page {F/611/3}, this is
Anne Chambers again. She says at the top of page 3:
"I've retrieved logs of an attempt to roll the
office from TP 11 to 12, at 9:51 UTC 12th April.
"All looks ok - trading statement is printed, and
they press confirm."
If we go down a couple of paragraphs.
A. So it says something has timed out at the counter,
hasn't it.
Q. "I suspect this may be because there is already a single
entry in BRDB_SU_OPENING_BALANCE for DEF TP 12 BP 1,
inserted during migration. The entry is for cash, zero
value."
A. Right.
Q. So just stopping there, what has happened is that this
branch has newly migrated as part of the pilot scheme,
and as part of the migration there has been a glitch or
something which has resulted in the entry of a false
figure for the next balancing period. There shouldn't
be anything there at all, should there?
A. That is right.
Q. But instead, as part of the process of pilot scheme
migration, a figure of zero has crept in which is
plainly wrong, yes?
A. Yes.
Q. And the fact that there is a zero for the forthcoming
balancing period means that the branch can't roll into
that balancing period, correct?
A. Yes.
Q. So if we go down the page to 14th April at 13.00 hours,
this is Gareth Jenkins:
"I've had a look at this PEAK and agree that we need
an OCP to tidy up BRDB to unstick this branch. Note
that what I'm proposing here is slightly different from
what Anne has suggested above."
He suggests the text that you quoted in your report.
So first of all he wants to update the stock units,
setting the trading period to 11. Yes?
A. Yes.
Q. So the stock units, which are already in trading period
12, the branch isn't but the stock units are, he wants
to re-set the stock units so they are back in trading
period 11, yes?
A. Yes.
Q. And that is an updating operation yes?
A. Yes.
Q. Secondly, he wants to delete the opening figures for the
next period -- the opening balance for the next trading
period --
A. Yes.
Q. -- to get rid of that rogue zero?
A. Yes.
Q. And by that means the stock units and the branch will be
in the same trading period, first of all?
A. Yes.
Q. And secondly, because the zero is no longer in the way,
they will both be able to roll over, correct?
A. Yes.
Q. And as a result of rolling over, what will the opening
position of the branch be?
A. Whatever it should be.
Q. Exactly. It will be an aggregation of all the
transactions that have been undertaken in the branch
since the previous -- the beginning of that trading
period.
A. Yes.
Q. So what's being done here is something that doesn't
change any transaction data, it doesn't insert any new
transactions that have a value and so on in the branch.
It is simply a form of SQL script which allows the
automatic process of aggregation of transactions to be
undertaken in a way that isn't blocked by the glitch
that's introduced as part of the migration process
during the pilot roll out, yes?
A. Yes.
Q. And I think you may agree that there definitely wasn't
a change to transaction data, and there definitely
wasn't any change which in any way modified the
accounting position of the branch, by which I mean --
which raised the risk of the branch having the wrong
accounting position as compared with what it should
have?
A. Yes, I agree.
Q. Thank you. And would I be right in thinking that you
have only seen a relatively few number of PEAKs of this
sort?
A. There are a few PEAKs that do contain SQL statements.
There are other PEAKs that refer to the need to use SQL
but don't contain statements such as this.
Q. Let's move on to -- just to sum up, you have reviewed
thousands of KELs, Mr Coyne, thousands of PEAKs,
thousands of OCPs, OCRs and MSCs, and you have done lots
of intelligent searches through all of those documents,
yes?
A. Mm.
Q. Would I be right in thinking that in that process you
have been looking for instances of remote access
affecting branch accounts of the sort we have been
discussing?
A. Yes.
Q. Given this covers a 20-year period, and given the number
of branch accounts that have been created during that
period and the number of transactions which have been
done during that period, you have found relatively few,
haven't you?
A. From the documents that we have reviewed using the
search terms, yes.
Q. And the evidence that you have seen from the documents
you found shows that Fujitsu is generally reluctant to
make changes that would have an effect on branch
accounts, yes?
A. Yes.
Q. And it is generally -- in fact it is always careful to
ensure it is only done when necessary and that it is
done with great care?
A. I have to say generally, I don't know if it's always --
Q. Generally. Have you seen --
A. Always is just an absolute.
Q. Oh, simply because you don't want to say it never
happened. But the documents you have seen, you have not
seen any documents which clearly show a careless
attitude whether to the transaction being done, to the
particular form of remote access being undertaken, or to
getting the appropriate consent to undertake the
transaction?
A. No.
Q. Thank you. Now you make some criticisms of the
permission control regime applied at Fujitsu and for
that purpose you rely on two documents, don't you, you
rely on the Ernst & Young management letter of 2011 and
you also rely on the minutes of the Risk & Compliance
Committee meeting that we discussed a couple of days
ago.
A. Yes.
Q. The impression that's given in your reports is that
Fujitsu has poor controls which could expose the system
to a risk of poor actions being done, yes?
A. Yes.
Q. But in all the documents you have searched through you
have actually not found any significant evidence of poor
actions being done, have you?
A. No, but in a lot of documents you will see, for example,
the term user APPSUP, but then you don't see what
follows so we don't see what the actions are.
Q. Let's look at the Ernst & Young management letter. We
have already talked about the Risk & Compliance
Committee minutes. Could we go to {F/869/1}, please.
You refer to this a lot in both reports, particularly in
your second report. Could I ask you first of all to go
to page {F/869/3}. This is the executive summary.
Perhaps I could ask you to read it. (Pause)
A. Yes.
Q. I'm going to deal with each of those four key
recommendations but I'm going to start with the change
management process because it is fair to say, isn't it,
that that's the section you focus on mostly in your
reports, wouldn't you say so?
A. Change management and permissions.
Q. If we could go to your second report, it is
{D2/4.1/178}, please. At paragraph 5.196 you say:
"There is evidence of deficiencies in change
management as recorded in the letter."
So you regard this letter as being evidence of
deficiencies, do you?
A. Evidence that the auditors identified deficiencies, yes.
Q. But wouldn't you agree that the word "deficiency" or
"deficiencies" is only mentioned twice in the letter, is
that right?
A. I think with regard to weaknesses.
Q. If we look at page {F/869/11}. This is "Payroll Control
Environment", and do you know, I haven't marked the word
"deficiencies", but somewhere on this page there is the
word "deficiencies". But that's to do with payroll,
correct?
A. Yes, I do not think it will be this section that I've
referred to.
Q. Let's go back to page {F/869/3}, to the second paragraph
of the executive summary.
A. Yes.
Q. They say, the last sentence:
"The recommendations we have made in this report
should be seen as refinements rather than fundamental
control deficiencies in comparison."
Do you see that?
A. Right, yes.
Q. Now, would it not be thought that Ernst & Young are
actually refraining from saying that these are
deficiencies?
A. Yes, but this is the executive summary. I think if you
go to the detailed findings.
Q. I see. It is correct, isn't it, that this letter
doesn't identify any harmful events having taken place
as a result of the change management process, is that
right?
A. Yes.
Q. If we could move on to your second report, I'm sorry to
leap around like this, it is {D2/4.1/195}. At
paragraph 5.264 you say:
"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. I have listed below the four key
recommendations ..."
On what basis do you say in this report that it
appears that Post Office chose not to take the
opportunity to improve the countermeasures as
recommended?
A. This document is -- there was a risk identified to the
Post Office and Post Office chose not to mitigate it in
the way suggested by Ernst & Young.
Q. Hold on, you are talking about recommendations. You are
talking about -- you appear to be talking about the key
recommendations and forgive me, Mr Coyne, but you appear
to be saying that Post Office chose not to act in
response to those recommendations. Is that not the
impression that's given by this paragraph?
A. Yes. I think this is covered -- is it 5.197 in my
report which relates to the document you just took me
to, it was the table at section 2.
Q. 5.197?
A. Yes. {D2/4.1/178} You took me to the executive summary
before, but the section that I comment on in the report
is the table at section 2, points 12 to 15.
Q. So you are saying the table at section 2 supports your
inference or your understanding that Post Office chose
not to take action in response to the recommendations by
Ernst & Young. Is that what you are saying?
A. So section 2 deals with points that were made in the
previous year. Section 4 is specific points made for
the current year.
Q. Yes. So section 2 won't justify an assertion that the
key recommendations that are in section 4, Post Office
chose not to react to them because it is to do with past
events, yes?
A. Can we go to that document?
Q. Yes, it is at {F/869/1}. What I'm proposing to do,
Mr Coyne, but if you would like me to do something else
do tell me, is to take you to the particular provisions
of the letter in which recommendations are made and to
see whether it is fair to say that Post Office chose to
take no action to improve the position in response.
Would that be a fair thing to do?
A. Yes.
Q. Let's do that. If we could go first of all to page
{F/869/23}, this is "Improve governance of outsourcing
application management", and it goes on for two pages,
you see?
A. Yes.
Q. If you look at the far right column entitled "Management
Comment", you will see it starts with the words:
"Work on improving ..."
A. Yes.
Q. "... has already commenced ..."
Do you see that?
A. Yes.
Q. That's work that Post Office and Fujitsu are carrying
out and it runs over to the second page. It is quite
long, isn't it?
A. Yes.
Q. So this doesn't suggest that Post Office chose not to
take action in relation to this particular
recommendation, correct?
A. Yes.
Q. So let's try another one. If we go to page {F/869/25},
this is "Segregation of duties within the manage change
process". If you look at the far right-hand column this
time, "Management Comment", it says -- the very first
line reads:
"A Fujitsu project has been established to review
all user management areas and is being led by the CISO
of the RMG account.
"Fujitsu will provide and agree with POL a clear
segregation of duties guideline for Senior management
and line managers ..."
It goes on for several pages, do you see?
A. Yes.
Q. Would you agree that this doesn't suggest that
Post Office chose not to take action in response to the
second key recommendation. Do you think that's fair?
A. Yes, I think that's fair.
Q. If we move on to page {F/869/29}, this is the third key
recommendation of strengthening the change management
process. I pause to note in the middle column, the
"Recommendation" column:
"Management should enhance the current change
management process ... to include."
The word "enhance" doesn't usually connote
deficiency, it connotes room for improvement, would you
agree with that?
A. Yes.
Q. Then if you look in the far column it starts by saying:
"Work has commenced on the strengthening of the
change management process:
"Centralisation of approvals for change for POL
within Fujitsu is to be established."
It goes on for another page and another page, and
another page and another page. It goes on for pages,
actually, all the way to page {F/869/38}. It finishes
at page 36, I see. So quite a lot of things being done
in relation to the recommendation that there be
a strengthening -- an enhancement of the change
management process, would you agree with that?
A. Yes, one of the recommendations that I recall reading in
this document is that Post Office should be aware that
Fujitsu automatically tell them of changes to Horizon --
Q. That's quite interesting, Mr Coyne, because we discussed
that, do you remember, when we talked about the risk
management committee minutes a couple of days ago.
That's one recommendation. In paragraph -- in the
relevant paragraph of your report you talk about the
recommendations, plural.
The impression that you are obviously seeking to
achieve in your report is that four key recommendations
were made and Post Office chose to do nothing about any
of them. Do you not accept that that was the impression
that was given by the relevant paragraph of your second
report?
A. No, I think what the paragraph in my report says is that
there were recommendations that weren't taken up.
Q. Would you give me a moment, please, Mr Coyne?
A. Certainly.
Q. Mr Coyne, you raised the proposal that was considered at
the Risk & Compliance Committee meeting I think in 2012
and you suggested that that proposal was contained in
the 2011 Ernst & Young management letter. Are you sure
about that?
A. It was my perception that it had came from one of the
Ernst & Young --
Q. It came from the 2012 Ernst & Young audit report. Do
you remember that?
A. Right, yes.
Q. It didn't come, I don't believe, from the 2011 letter?
A. I thought the letter was a distillation of the main
points in the report.
Q. The 2011 Ernst & Young management letter accompanied the
2011 audit, yes?
A. Right.
Q. And the following year there was a 2012 audit.
A. Right.
Q. And in the 2012 audit there was a recommendation that
perhaps the system could be enhanced by adopting
an automatic monitoring system rather than the manual
one that was currently operated. Does that ring a bell?
A. Yes.
Q. I'm just wondering whether you would like to reconsider
your evidence that in 2011 it was proposed that this
automatic monitoring system should be adopted?
A. It might be a mistake, maybe it should be 2012.
Q. This may be slightly unfair to you, and it is a long
document, but let's assume that it doesn't contain that
proposal, that the 2011 management letter didn't contain
that recommendation, and if it is an unfair assumption,
and I will check it overnight, I will come back tomorrow
morning and apologise to you.
But on that assumption which I believe to be
correct, so far we have not seen any proposal made by
Ernst & Young in relation to which Post Office has not
chosen to take any action at all, would you agree?
A. I would agree.
Q. Of course it is to be expected that when an auditor
makes recommendations, there will be a -- I don't want
to say a negotiation, but one doesn't assume that every
single proposal will be accepted in every material
particular. There's always going to be some room for
discussion, "Well, maybe we could achieve that objective
in a different way". That is part of the normal process
by which auditors deal with their appointors and vice
versa, do you agree?
A. Yes.
Q. But subject to points of that sort, are you aware of
anything that was recommended in the 2011 letter that
wasn't addressed in some way by Post Office in response
to that letter, and indeed in the very letter itself in
the "Management Comment" section?
A. It could well be that. It could well be that the 2012
document looks back at the findings of 2011 and provides
an update on that and that's why I say it was 2011.
Q. That's not actually an answer to my question. Let's
finish the list and then we can look at 2012.
If we go to page {F/869/47}, this is the fourth key
recommendation, "Review of generic privileged accounts."
If you look at the far right, "Management Comment",
you will see:
"A Fujitsu project has been established to review
all user management. This is to include all system/s,
accounts and privileges.
"Monitoring and communication will be provided to
POL through the regular embedded BAU ..."
That is business as usual:
"... process to ensure access to control management
is robust."
Do you see that?
A. Yes.
Q. So it wouldn't be fair to say, would it, that no action
was taken in relation to that fourth key recommendation
either?
A. Well, nothing got done or got improved over it, and we
can see that from the PEAK where Fujitsu are trying to
address --
Q. So what you are suggesting is that -- there were
obviously audits in later years?
A. Yes.
Q. And are you suggesting the auditors in later years found
a deficiency in Post Office's approach to the
recommendation they had made in 2011?
A. No, what I'm saying is it might not be the auditors that
found future deficiencies after the initial observation
but that the situation with privileged user access logs
wasn't corrected.
Q. Mr Coyne, would you agree with me that in principle the
best people to judge whether action is being taken to
address recommendations made by auditors is the auditors
themselves rather than you, would you agree with that?
A. Yes.
Q. Let's look to see what the auditors said in later years.
Could I ask you to go to {F/1138/1}, this is the 2013
audit of Post Office. If we could go to page {F/1138/7}
of that document. I'm afraid you are going to have to
give me a moment, Mr Coyne, I haven't marked this piece
of paper. I apologise.
A. That's fine.
Q. Here we are. I'm sorry for wasting time. At the bottom
of the page, item 3, "POLSAP periodic user access
review":
"In the 2011/12 audit ..."
So that's the next year's audit:
"... we recommended improvements to the periodic
user access review process and monitoring controls we
noted the efforts by management to strengthen the
control environment this year by implementing a periodic
user review for Cash Centre POLSAP users. However,
finance users are currently not included in the review."
If you look at the far right column in response,
management says "Complete".
Then if we go back to page 4 --
A. Just before we do so, it is just not included in the
audit any more.
Q. Say again?
A. So what it is saying is it is not being included in the
audit any more.
Q. What's not being included in the audit any more?
A. The review. Can we go back one page, please.
Q. Is this to page {F/1138/7}?
A. Yes. So in 2011/12 improvements were recommended. We
noted efforts. But then it goes on to say:
"However, finance users are not currently included
in the review."
Q. Yes.
A. Should I take that to mean that the scope of the audit
has been reduced not to look at finance any more?
Q. If you look at the far right-hand column there is
an answer to your question:
"Complete.
"Finance undertook a review of their users and
periodic reviews are planned. There will be an
additional monthly user report for finance provided via
service management ..."
So Mr Coyne, the answer to your question is no.
A. Right.
Q. Let me get this straight. You were aware of these
documents when you made your statement in your second
report --
A. Yes.
Q. -- that Post Office had chosen not to take action? You
had seen the later audits by Post Office, hadn't you?
A. Yes.
Q. You wouldn't make a claim of that sort if you hadn't
looked at the later documents to actually see what the
auditors were saying, would you?
A. Yes. And at number 4 is one of the reference about
accepting that the risk exists.
Q. Yes, this is where the proposal is made.
A. Yes.
Q. This is where the proposal is actually made which is
then later on considered by the Risk & Compliance
Committee minutes?
A. Yes.
Q. That has nothing to do with the claim we are currently
addressing, the claim you make in your second report,
that Post Office chose not to take the opportunity to
improve its procedures in response to the key
recommendations made in the 2011 Ernst & Young
management letter, do you see?
A. Right, so this is the 2012 audit and this is the first
time that that issue has arisen, is that what you are
putting to me?
Q. Mr Coyne, I'm not sure whether the proposal was made in
2012 as well as 2013 but I'm not aware that the proposal
was made in 2011.
A. Right, okay. But the principal point is that increased
monitoring was suggested by the auditors to put controls
in place to validate programme changes to Horizon and
POLSAP and that Post Office's decision was to accept
that the risk existed.
Q. Here's what's interesting to me, Mr Coyne. In your
second report you made a criticism which is limited
entirely to the 2011 Ernst & Young management letter.
It is a criticism you repeat many times in your second
report, would you agree?
A. Mm.
Q. And the criticism is these key recommendations were made
and Post Office chose not to take them up, not to react
to them, not to take the opportunity to improve with
regard to the recommendations that were made. That was
the claim that you made. And I think you have agreed
with me that when you made that claim you took the
trouble to look at later audit reports, and did you also
look at the Fujitsu service audit reports that were also
in existence? Did you look at those?
A. Yes.
Q. So you looked at all those documents, and having seen
what was in those documents you felt it appropriate to
say that Post Office had chosen not to take the
opportunity to improve. What I'm suggesting to you is
that the evidence is not consistent with that rather
damning judgment. It might be that Post Office didn't
react immediately and accept every jot and tittle of
every recommendation that was made, but you have already
fairly accepted that in the real world when proposals
and recommendations are made by auditors there is always
room for decision as to how much of the recommendation
should be decided, yes?
A. Yes.
Q. So what I'm suggesting to you, Mr Coyne, is that key
recommendations were made in the 2011 letter and the
criticism that you choose to level at Post Office on the
basis of those recommendations and on the basis of
Post Office's response to those recommendations is not
justified by the evidence that you yourself agree that
you had seen. Now how would you respond to that?
A. It appears that I have made a mistake and should have
referred to the 2012 audit.
Q. And if we go back to page {F/1138/4}. Hold on, are you
making an assertion now about the 2012 audit or are you
making an assertion about this audit here that we are
now looking at which is the 2013 one?
A. I would have to check what the 2012 audit said as well.
MR JUSTICE FRASER: We are in 2013 at the moment and
Mr de Garr Robinson is taking you to page 4.
MR DE GARR ROBINSON: Let's go to page {F/1138/4}. Under
the heading "Summary of IT control observations", do you
see that? If we go to the second paragraph.
A. Yes.
Q. "This year, we have not identified significant
exceptions in our independent testing of POL-operated
controls. We have, nevertheless, identified a small
number of improvement opportunities to enhance the
effectiveness of recently implemented controls and
further improve some of POLSAP s security settings. It
should be noted that these control enhancements did not
have an adverse impact on our ability to place reliance
on the effectiveness of automated controls within HNGX
and POLSAP for financial statement audit purposes."
Do you see that?
A. Yes.
Q. That is quite close to what in the audit world could be
regarded as a ringing endorsement, isn't it, Mr Coyne?
A. Yes.
Q. If we go to page {F/1138/8} to see what small number of
enhancements they are proposing in relation to HNGX ...
(Pause)
Now I'm slowing you down, Mr Coyne. I do apologise.
I should have marked this document properly before
I came to it
(Pause)
So it is page 8 of the document. In column 4, you
will see "Change management monitoring control"?
A. Yes.
Q. They say:
"As part of management s initiative to strengthen
the control environment, we noted that POL implemented a
monitoring control to validate whether program changes
to HNGX and POLSAP have been authorised, tested and
approved prior to migration into the production
environment. However, the monitoring control does not
make use of a list of changes generated directly from
POLSAP or HNGX, and hence there is a risk that some
changes are omitted from the monitoring control."
The recommendation is:
"Management should make use of a system-generated
list of changes in performing the monitoring
control ..."
And the management comment is:
"Accept the risk. Engaged with service management
and Fujitsu. System generated lists are not feasible as
they are based on events that the system generate of
which there are multiple thousands per week change
process for monitoring is considered robust through the
existing ticket based approach that review changes
against the MSC list. This will be noted to the Audit
Committee with the November update and the Risk &
Compliance committee endorsed the recommendation on 18th
September 2013 to accept the risk."
So the recommendation is made in 2013 and the
response given by Post Office is actually it is not
feasible. Do you see that?
A. Yes, I think it is actually based on a misunderstanding
of what the weakness that was identified was.
Q. Let's not worry about misunderstandings. Just take it
in stages. The HNG-X recommendation we have seen is in
order to enhance effectiveness, yes?
A. Yes.
Q. It is not a serious deficiency in relation to which
a key recommendation of serious importance is being
made, would you agree?
A. Agreed.
Q. It is an opportunity for enhancement to improve
something that is already adequate, would you agree with
that?
A. Well, it certainly is an improvement. Whether it was
adequate already I can't say.
Q. But what you can't say then by the same token is that
the situation without the improvement was deficient.
That's certainly something you can't say, would you
agree?
A. In my experience I haven't seen a company that's been in
a situation where programme changes are made to two key
systems and the customer is not aware of those changes.
Q. Mr Coyne, we would be on the same page if the true
position was that there was no communication of changes
by Fujitsu to Post Office, but that's not the position.
We lacked at the Risk and Recommendation Committee
minutes a couple of days ago. We also looked at the
document, was it minutes, that preceded that meeting
which explained in much greater detail what the factors
were and what the cost was and so on.
The fact is there was a system for communicating
changes. It was a manual system that was checked on
a monthly basis and Fujitsu are saying, do you know, it
would be an enhancement if you could make it automatic.
Ernst & Young, I'm so sorry. It would be
an enhancement, not a serious deficiency but it would be
an enhancement, it would be an improvement if you could
make it automatic and it went to the Risk & Compliance
Committee. They worked out that it would cost
£1 million because of the way that the system was
configured and they came to the overall view that the
appropriate thing to do would be to make no change at
this stage but monitor the monitoring process more
closely to see if any adverse events arose and if they
did arise then they would review the recommendation
again. Do you remember our discussing that?
A. Yes.
Q. And I think I'm right in saying that when we discussed
that you indicated that that was not an unreasonable
approach.
A. It is a poor position to be in in the first place but it
is not an unreasonable approach.
Q. Mr Coyne why do you say, in fact how do you feel it
appropriate for you to say it is a poor position for
Post Office to be in when the very people that are
making the recommendation are only doing so on the basis
that it is an enhancement. They are not saying there is
a deficiency that needs to be addressed. So why is it
you are taking it upon yourself to take a much stronger
view of steps that should be taken than Ernst & Young
itself?
A. Because that is the situation that you should be in in
order to be confident about your systems that are being
supplied to you.
Q. Right. One final question in relation to that, the
proposal that we are talking about of course has nothing
to do with the kind of remote access that we are
considering does it?
A. Agreed.
Q. So actually we have just spent the last ten minutes
discussing your criticism of Post Office, it is
a criticism which actually doesn't arise in relation to
the access control programme -- the access control
principles that are applied in relation to Post Office's
business, would you agree?
A. Agreed.
Q. So I would suggest to you Mr Coyne that having regard
not just to the 2011 management letter, which says some
things that read in isolation might be seen as negative,
but having regard also to the 2013 audit reports and
Ernst & Young's views expressed in that, what comes over
is a very different picture from the one that you depict
in your second report?
A. I thought you were going to take me to the part of the
Ernst & Young report that dealt with user access and
privileged users.
Q. The 2011 report?
A. Yes.
Q. Well, do you remember I took you through the table with
each of the recommendations and I took you to each of
the comments as to what Post Office was doing in
response to them. Do you remember that?
A. I do not think that was in regard to privileged user
access.
Q. It was in regard to the four key recommendations that
you refer to in your expert report, which I'm asking you
about. Do you see?
A. Right.
Q. What I'm suggesting to you is that, in order to give
a balanced and fair assessment of Post Office's
position, it would have been not only appropriate but in
fact I would suggest necessary also to refer to the
things that were said in the 2013 audit and I would like
to ask you, Mr Coyne, why you chose not to say anything
about the 2013 audit?
A. I'm confused because this doesn't relate to the remote
access point. So we have talked all about remote
access. My understanding was you were going to take me
to the remote access part of this for me to comment on.
Q. Mr Coyne, I'm not going to debate with you what I'm
going to ask you about and what I'm not going to ask you
about. I would like to ask you -- the question I asked
you is, having felt it appropriate to criticise
Post Office's approach and to claim that Post Office had
chosen to take no action on the basis of four key
recommendations made in the 2011 Ernst & Young letter,
and having repeated that point several times in your
second report, my question to you is why you felt it
appropriate not to mention the 2013 report? Do you not
think that would have been a fair thing to do?
A. I agree that providing any additional material would be
helpful.
Q. So why did you choose to leave it out?
A. It wasn't a conscious decision to leave anything out.
Q. If I may say so, Mr Coyne, it must have been a conscious
decision to report the negative things that were
contained in the 2011 management letter, but are you
saying that was conscious but leaving out the 2013
audit, that wasn't conscious, that was -- what are you
saying?
A. I was attempting to identify areas of lack of control
that could have led to bugs, errors and defects.
Q. What you were trying to do, Mr Coyne, may I suggest, is
that you were trying to find things, trying to find
coconuts to lob at Post Office and you were not very
interested in whether Post Office had some kind of
shield that it could raise to the coconuts that you
would be lobbing, would that be fair?
A. No, it wouldn't be fair because it is not about largely
irrelevant aspects where improvements have made, it is
where aspects that are relevant to this dispute haven't
been dealt with, such as control and change to software.
Q. Would you give me a moment please. (Pause).
I would like to spend a few minutes now, at the end
of my cross-examination in this area, discussing another
set of documents that you didn't refer to in your second
report, which is the service audits that Dr Worden
referred to in his report.
As well as performing financial audits with
Post Office, Ernst & Young also performed audits for
Fujitsu's IT infrastructure services supporting POLSAP
and Horizon Online, didn't they?
A. Yes.
Q. From 2016 these service audits also covered a review of
Credence, didn't they?
A. I think that's right, yes.
Q. Would you agree that service audits by Ernst & Young are
rather more specific than the general financial audits
that would have been done by Ernst & Young for
Post Office's general accounts?
A. Yes.
Q. Now we have the service audits in the trial bundles for
the years 2012, 2013, 2014, 2015, 2016 and 2017.
I don't have time to take you to them all but let's just
look at 2012. Could we go to {F/1041/1} please. So
this is a description of Fujitsu's system of:
"IT Infrastructure Services Supporting Post Office's
POLSAP and HNG-X Applications throughout the period
April 2012 to December 2012 with the independent service
auditor's assurance report including test performed and
results thereof."
Now, have you read those documents?
A. I believe I have, yes.
Q. Let's go -- there are a number of control objectives,
aren't there?
A. Yes.
Q. What Ernst & Young does is it expresses its opinion on
how -- whether there are deviations or not from the
appropriate -- what should be the appropriate approach
to each of those control objectives, would you agree?
A. Yes.
Q. So if we go to access control, which I am sure you will
agree is quite an important one in the present context.
Let's go to page {F/1041/83}. It is control objective
10.
"Control objective 10: Controls provide reasonable
assurance that access to system resources, including
computing platforms and operating systems is restricted
to properly authorised individuals."
You will see that there is a series of, what does
one call them? Tests on the left-hand side from 10.1
through to 10.7.
A. They are statements in which to benchmark against.
Q. Yes. Thank you.
So there are these seven checks/statements and if we
run through them all -- perhaps you could read them to
yourself. (Pause).
A. Yes.
Q. You will see -- I have to say Mr Coyne I'm terribly
impressed by how fast you read, you are much quicker
than I am. I'm rather envious.
But if you look at the right-hand column it is
headed "Results of Tests". You see that for all of
those tests there are no deviations noted except for the
third one.
MR JUSTICE FRASER: I think we need to go back a page.
MR DE GARR ROBINSON: Which is at page {F/1041/83}. There
they say:
We selected a sample of 12 platforms within the
in-scope applications. The Group Policy on failed access
attempts that manages access to all these servers was
set to disable accounts after 6 consecutive failed
access attempts; the POL setting should be to disable
accounts after 3 failed access attempts. The other
settings tested were in line with the POL requirements.
No other deviations noted."
You will see the "Management Response":
"Management accept this deviation and will. Rectify
at the next revision of the Policy document ..."
And they set out what the document is. That's quite
good, isn't it?
A. Yes, there's very little noted there.
Q. And would it be fair to say that there are no other --
in all the later years, 2013, 2014, 2015, 2016, 2017,
there are no deviations of any sort in relation to
control objective 10. Does that ring a bell?
A. I think I have made a mistake here in believing which
document -- which Ernst & Young audit this was.
I thought this was going to be the one that noted the
controls with regard to access to the Horizon back end
systems. I'm not sure this is the document that
I thought it was.
Q. So you think -- what, you think there is another
document that is relevant to the debate we are having,
do you?
A. Yes.
Q. What's that document?
A. Could I take a moment to find it?
Q. Yes, by all means. We are talking about
an Ernst & Young document?
A. I believe so, yes.
MR JUSTICE FRASER: Can we go back to page 7 because it
might actually be the right document and he is just
looking at the Fujitsu part that's attached.
{F/1041/7}, does that help you?
A. It could well do, my Lord. Could we go through?
MR JUSTICE FRASER: I'm not going to control what you look
at. If you want to look forward or back just ask the
operator to do it. Mr de Garr Robinson I just thought I
might help.
MR DE GARR ROBINSON: I'm much obliged to your Lordship.
A. Can you keep going forward please to the point where the
tables start please. {F/1041/10}. I don't think this
is the one that I was thinking it was.
Q. What I took you to was the service audits that Dr Worden
refers to at some length in his supplemental report and
which he refers to again in your joint statement?
A. Yes.
Q. I'm happy for you to tell me there are some other
documents which are relevant to the debate we are
having, but the fact that you thought I was going to
take you to some other documents doesn't really take
matters much further, does it?
A. Okay, I'm happy for you to take me wherever you want to
take me to.
MR JUSTICE FRASER: Can I just make a point generally
because I know you have only got another day.
Although Mr de Garr Robinson does say from time to
time "the debate we are having" and "the discussion we
are having", actually he is cross-examining you. So if
you just focus on his questions. If in order to answer
the question you refer to documents or there is some
wider sphere, well, of course that's understood, but it
is not a general debate.
A. Yes, my Lord.
MR JUSTICE FRASER: Is that clear?
A. Accepted.
MR JUSTICE FRASER: All right.
MR DE GARR ROBINSON: Thank you, my Lord. Let's now go to
control objective 13, it is headed "Remote Access". It
is at {F/1041/88}. To be clear I apprehend that what
this document means by remote access isn't exactly the
same as what I mean when I talk about remote access,
although there is some significant overlap.
A. Yes.
Q. Perhaps you could cast your eye down since you are such
a quick reader. Is it page 88? (Pause). So if you
could just cast your eye down those control objectives.
You will see on the right-hand side of the page "No
deviations noted"?
A. Yes.
Q. Ernst & Young gave Fujitsu a full, clean bill of health
on all the other control objectives, didn't it?
A. Yes. For context the remote access authorisation here
is the connection from the counter to the date centre.
Q. Yes, it is not entirely the same as what we are talking
about. But on all the objectives that are addressed in
this service audit, they cover issues that you have
raised but going much wider than remote access, don't
they? That is a slightly unfair question, let me be
clearer. Control objective 1 {F/1041/70}:
"Controls provide reasonable assurance that access
to data centres and facilities with computer equipment,
storage media and program. Documentation is restricted
to properly authorised individuals."
{F/1041/71}
"Control Objective 2: Controls provide reasonable
assurance that computer equipment and facilities are
protected from damage by fire, flood and other
environmental hazards and maintenance agreements are in
place."
{F/1041/72}
"Control Objective 3: Controls provide reasonable
assurance that programs, files and datasets that have
been identified as requiring periodic backup are backed
up and retained."
{F/1041/73}
"Control Objective 4: Controls provide reasonable
assurance that processing is appropriately authorised
and scheduled and that deviations from scheduled
processing are identified and resolved."
All of these things contribute to robustness, don't
they, of the Horizon system?
A. They do, yes.
Q. {F/1041/74}
"Control objective 5: Controls provide reasonable
assurance that system availability performance and
capacity are routinely monitored to ensure potential
issues are captured and investigated."
{F/1041/76}
"Control Objective 6: Controls provide reasonable
assurance that significant operations incidents are
adequately reported, tracked, monitored through
resolution and resolved timely."
That's quite an important one, isn't it, bearing in
mind the criticisms you make of the processes adopted by
Fujitsu and Post Office in relation to problems, would
you agree?
A. Yes, it is talking about the procedures and policies,
yes.
Q. {F/1041/78}
"Control Objective: 7 Controls provide reasonable
assurances that networks are managed to contractual and
site requirements, monitored for availability and
response times and issues are identified, tracked and
resolved."
{F/1041/80}
"Control Objective 8: Controls provide reasonable
assurance that modifications to system software and
networks are authorised, tested, approved, properly
implemented and documented."
That is quite an important one in the context of
these proceedings, isn't it?
A. Yes.
Q. {F/1041/81}
"Control Objective 9: Controls provide reasonable
assurance that new or modified application software
development efforts are authorised tested, approved,
properly implemented and documented."
Again quite important in the context of these
proceedings.
We have already looked at control objective 10. If
we look at control objective 11 {F/1041/85}:
"Controls provide reasonable assurance that access
to databases, data files, and programs is restricted to
properly authorised individuals."
That is quite important, isn't it?
A. It is and that's why I'm surprised that in 2011
Ernst & Young made the observations that they did in
another audit document.
Q. {F/1041/87}
"Control Objective 12: Controls provide reasonable
assurance that networks and system resources are
protected from external threats and access violations
are detected, reported and investigated."
Now all of those are quite material to many of the
judgments you have made in the course of both your
reports about how the system was operated, about how its
robustness could be improved and so on, aren't they?
A. Yes.
Q. Now in the years 2012 all the way through to 2017,
Mr Coyne, only one other deviation was noted apart from
the one we have already gone to and that was in the 2016
service audit and for fairness I should take you to it.
It is at {F/1562/83}. I may have given the wrong
reference.
MR JUSTICE FRASER: We are going to 2015?
MR DE GARR ROBINSON: Let's hope I have got the right
reference.
If we could go to page {F/1562/83}. Yes.
"Control Objective 9: Controls provide reasonable
assurance that new or modified application software
development efforts are authorised tested, approved,
properly implemented and documented."
A. Yes.
Q. It is said that one POLSAP user could develop and
implement a change for software development and a user
should not be able to do both, do you see that?
A. Yes.
Q. This issue was flagged and resolved before the service
audit was published, do you see that?
A. Yes.
Q. There was only one user, there was no reported incident
in connection with this, yes?
A. Mm.
Q. And no recommendation for improvement, yes?
A. Yes.
Q. So subject to those two deviations over a five-year
period, no other deviations were noted in these service
audits and no recommendations for improvement were made?
A. No.
Q. Now, in your reports you attached importance to audits,
didn't you, saying that auditors are in a better
position than you and Dr Worden to evaluate the change
control processes, yes?
A. Yes.
Q. Do you stand by that?
A. Yes.
Q. Do you accept that in circumstances where you are making
serious criticisms of Post Offices' and Fujitsu's
processes over all or most of these control objectives,
it was really important to provide a balance to account
of where Post Office and Fujitsu stood?
A. The specific observations I made was user access and
change control. A lot of the things you have taken us
through there aren't necessarily about that.
Q. A lot of the things I have taken you through are
terribly about lots of things that you purported to
criticise Post Office for during the course of your two
reports, would you agree with that?
A. No. The majority of the criticism is about change
control and user access.
Q. Do you not think, Mr Coyne, that it would have been fair
for you to have had proper regard to the service audits
and to have mentioned them in your reports when deciding
to criticise Post Office and Fujitsu in the way that you
have?
A. It would have been helpful to provide an overview of
these, yes.
Q. My Lord, I wonder whether that's a convenient moment.
MR JUSTICE FRASER: I think so. Would you like to start at
10.15 am tomorrow?
MR DE GARR ROBINSON: I would love to start at 10.15.
MR JUSTICE FRASER: I think there may only be a couple of
other people in this court who share your exuberance but
luckily I'm one of them.
So Mr Coyne, I know you come from Preston but
I imagine you are staying in London, are you?
A. Yes. I am.
MR JUSTICE FRASER: So there's no problem with you coming
for 10.15 am and did the two of you discuss the
re-examination --
MR DE GARR ROBINSON: My Lord we did.
MR JUSTICE FRASER: Would you like to enlighten me or either
of you?
MR GREEN: My Lord, I'm going to confine myself to 5 to 10
minutes per day of cross-examination, so I said to my
learned friend if he is able to finish by 3.45 pm, but
we haven't factored in any questions from your Lordship.
MR JUSTICE FRASER: That's all right. So broadly 3.45 pm
more or less tomorrow. So 10.15 am tomorrow Mr Coyne.
Thank you all very much.
(4.30 pm)
(The court adjourned until 10.15 am on Friday,
7th June 2019)
(10.30 am)
MR JASON PETER COYNE (continued)
Cross-examination by MR DE GARR ROBINSON (continued)
MR DE GARR ROBINSON: My Lord, good morning.
MR JUSTICE FRASER: Good morning.
MR DE GARR ROBINSON: Mr Coyne, good morning again.
A. Good morning.
Q. I'm going to talk about remote access today and for that
purpose I would just like to spend a few minutes looking
at the issues relating to remote access. Can I ask you
to go to bundle {C1/1/1}, please. If we go to page
{C1/1/3}, I will pick it up at Issue 10 under the
heading "Access to and/or Editing of Transactions and
Branch Accounts", and we will see the issue there:
"Whether the defendant and/or Fujitsu have had the
ability/facility to: (i) insert, inject, edit or delete
transaction data or data in branch accounts; (ii)
implement fixes in Horizon that had the potential to
affect transaction data or data in branch accounts; or
(iii) rebuild branch transaction data."
And then is it at all; is it without the knowledge
of the SPM; and without the consent of the SPM?
A. Yes.
Q. So this is really a theoretical question. It is what
could in theory be done based on the system
configuration, yes?
A. Yes, but there are practical examples that will help
answer those.
Q. I'm going to come to that. And transaction data or data
in branch accounts. Let's get some terms clear. When
I talk about transaction data I'm talking about records
of transactions: price, date, quantity, money paid, that
kind of thing. Do you understand?
A. Yes.
Q. That would be a practical and useful definition for that
kind of term?
A. Yes.
Q. So shall we agree that that's what transaction data
means for the purposes of our conversation today?
A. Yes. There's also session data, and within session data
is often contained transactional data.
Q. Then data in branch accounts. A branch account, it is
true, isn't it, is an aggregation of transactions from
a given starting point, correct?
A. Yes.
Q. So your starting point is your opening position?
A. Yes.
Q. Which is itself an aggregation of prior transactions,
yes?
A. Historical, yes.
Q. So when you start from time T0, the beginning of the
branch, you will have a series of transactions, there
will be a calculation at an accounting date, then you
will have a closing balance which is your opening
balance for the next period?
A. Yes.
Q. And on you go. And on each occasion what the system
does is it does an aggregation, a calculation, based
upon the transactions that have happened since the
previous opening position, yes?
A. Yes.
Q. So if the opening position is a genuine aggregation of
all the transactions that went before then the branch
accounts will be right at that starting point, correct?
A. They should be, yes.
Q. You can change your accounting date or period. For
example, you could have an accounting date that starts
at 1 June and finishes at 20 June, and then you can
change your mind and decide to finish the accounting
period on 30 June.
A. I understand you can, yes.
Q. But that won't create a shortfall in your accounts, will
it? It just means you have a different accounting
period.
A. It shouldn't do, no.
Q. Thank you. When we talk about accounting data, for the
reasons that we have discussed really it is the
transaction data that would concern the account holder
most of all, wouldn't it?
A. Yes.
Q. Any change to the transaction data is something that the
user would want to know about because it might affect
his balance at the next accounting date, yes?
A. Yes.
Q. Whether it is in his favour or against him?
A. Indeed.
Q. The user is much less likely to be concerned about
changes to operational data that don't affect the
aggregation of transactions that build up and aggregate
into his balance, yes?
A. If it has little or no impact on his balance then, yes,
that is right.
Q. The same goes for Post Office, doesn't it? It will be
concerned about the accuracy of the branch accounts
which of course are then transmitted and become part of
its own accounts?
A. Mm.
Q. It will be much less concerned about adjustments, for
example, to opening dates or matters of that sort, yes?
A. It is possible that it might have more impact on the
Post Office if dates are changed. I'm not sure of the
entire process and the back end of --
Q. That's fair. But in relation to postmasters, they will
be concerned about the transactions being right, but
form the aggregation resulting in whatever the balance
is at the relevant balance date?
A. Yes.
Q. Let's agree some more nomenclature. When I talk about
remote access today I'm going to be talking about
injecting, editing or deleting accounting data in branch
accounts, okay?
A. Yes.
Q. Maintained either in Legacy Horizon in messagestores or
in Horizon Online in the BRDB? Do you understand?
A. Yes, I do.
Q. I won't be talking about access to other systems which
may contain similar information, do you understand?
A. I do, yes.
Q. Thank you.
Let's move on to Issue 11. Issue 11 is if the
defendant or Fujitsu had these abilities:
"... did the Horizon system have any permission
controls upon the use of the above facility, and did the
system maintain a log of such actions and such
permission controls?"
Permission controls, they are a protection against
error or abuse, aren't they?
A. Yes.
Q. The types of controls that one has, a permission that
anyone at Fujitsu -- because we are essentially talking
about Fujitsu here, aren't we?
A. I believe so. I don't believe anyone else at
Post Office had access to --
Q. So permission from your superiors at Fujitsu and
permission from Post Office, yes?
A. Yes. The permissions on a technical level are more
about settings within the system that allowed certain
users or user groups in or out. I'm not sure whether
you are referring to sort of an oral permission.
Q. Yes, I'm referring to the business systems within which
Horizon was operated, and I think you would accept,
wouldn't you, that Post Office consent was always
required for any remote access data changes of the sort
that we have been talking about, yes?
A. No, I'm not sure that was the case. There is a number
of examples where there was a blanket or an annual
permission that was given for critical access that was
required by Fujitsu. So they didn't need to ask for it
each and every time.
Q. That surprises me, Mr Coyne. It may be my fault. Are
you suggesting there was an annual blanket consent given
by Post Office for the making of changes to accounting
data in branches by way of remote access?
A. There were certainly blanket authorisations given for
a number of tasks, I would have to go back and have
a look at what specific tasks they were, but I'm
reasonably sure that that included quite a widely worded
one that allowed Fujitsu to undertake any -- I think it
either said emergency or critical actions that were
required.
Q. I see. And are you aware of any occasion when that
authorisation was exercised so as to make a change to
branch accounting data of the sort we discussed?
A. Yes, I think that's likely. Because what typically
happens, or certainly there's evidence of it happening,
is that there will then be a retrospective document
that's created.
Q. I see. So what you are saying then is there were -- in
critical cases there were occasions when changes were
made and consent, as it were, was recorded
retrospectively. Is that what you are talking about?
A. What I'm saying is there was a blanket consent for
whenever Fujitsu decides that an element is critical,
that they need to deal with it, so they didn't have to
request permission. And I have also seen evidence that
after certain tasks have been undertaken, that
a retrospective document has been created. Whether
there is a retrospective document for every incident,
there is really no way of knowing.
Q. And how many of these retrospective documents have you
found in your researches?
A. Hundreds.
Q. Hundreds?
A. Hundreds, yes.
Q. Well, that takes me somewhat by surprise. Is this dealt
with in one of your reports, Mr Coyne?
A. No, I think this is typically seen from the OCRs or the
OCPs, so that's after the report was completed.
Q. Well, I'm not in a position to ask you any questions
about that because it comes as news to me. Is there any
reason why that hasn't been revealed to the defendant
beforehand?
A. I would have thought the defendant would have already
known, would they not?
Q. So what you are saying is this isn't something that was
mentioned in your first report, yes?
A. Yes.
Q. And it wasn't mentioned in your second report?
A. Yes.
Q. You have become aware of it since then?
A. Yes.
Q. But you have taken no step to inform the defendant that
you are aware of it and that it might form part of your
evidence today?
A. It is a question that was put to me that I'm answering.
I presumed that the defendant would be aware that
Fujitsu operated like that and created retrospective
documents.
Q. And have you discussed it with Dr Worden, Mr Coyne?
A. No.
Q. Well, do you agree with me that given that it may be
relevant to the issues that we are canvassing today,
given that it may be relevant to the issues arising in
this trial, do you agree with me that as an expert it
would have been helpful if you had broached it with
Dr Worden so that an agreed position -- so that the
relevant documents, which you haven't identified, could
be reviewed and an agreed position could be arrived at?
A. It didn't appear -- they were late documents -- sorry,
they were documents that were disclosed after I had
finalised my report, and it didn't appear to be any
particular issue. You asked me the question then and
I answered it. I didn't believe it would be
a revelation to anyone within Post Office that --
Q. Mr Coyne, you do understand how litigation works? You
are an experienced expert witness, yes?
A. Yes.
Q. And you know when counsel is cross-examining you,
counsel doesn't have the familiarity which all the other
individuals in the case do. What counsel does is
counsel looks at the material which he is facing and
decides upon questions that he is going to ask in
relation to that material.
A. Yes.
Q. Now, what you have just said comes as a complete
revelation to me and there's no way in the world I'm
going to be able to ask you any questions about it and,
if I may say so, I suggest to you that it is obvious to
you that that would be the position. Did you not
appreciate that that would be the position?
A. No, because it would be my perception that that would
already be known. It is only on the documents that have
been disclosed to me. The documents say that they are
created retrospectively.
Q. Well, Mr Coyne, I'm not going to ask you any questions
about that because none of this material has been put
forward or explained or identified and I'm not in
a position therefore to seek to test it, so I'm going to
lay that question aside and I'm going to continue with
the rest of my cross-examination, okay?
MR JUSTICE FRASER: Just before you do, can you just
describe to me the title of the documents you have just
explained?
A. Yes, there's a couple of documents that go together,
OCRs and OCPs, and they are requests for a change to
data and then the permission being granted.
MR JUSTICE FRASER: But those are the documents you are
referring to, are they?
A. Yes, my Lord, and --
MR JUSTICE FRASER: Hold on. And when do you say you got
them?
A. I believe that there was a request --
MR JUSTICE FRASER: No, no. When do you say, when are you
telling me, you got them?
A. Without looking at my records, my Lord, I'm not sure,
but --
MR JUSTICE FRASER: Ballpark.
A. Either when my report had been completed or just before.
The report was 1st February, so it was in or around that
period.
MR JUSTICE FRASER: All right.
Back to you, Mr de Garr Robinson.
MR DE GARR ROBINSON: Mr Coyne, there are two categories of
documents, aren't there, that relate to the process by
which consent is obtained or recorded in relation to
remote access. There are MSCs, aren't there?
A. Yes.
Q. And there are OCPs and also OCRs for less important
changes, yes?
A. Mm.
Q. And the MSCs were disclosed to you on 21 December,
weren't they?
A. Yes.
Q. And the OCPs and OCRs were disclosed to you on
24th January, weren't they?
A. That could well be the time I'm referring to. The
report was 1st February.
Q. And your report was served on 1st February, wasn't it?
A. Yes, so a week after the documents were disclosed.
Q. So in terms of the Fujitsu process for making changes,
the permission controls applied within Fujitsu, do you
accept that the sort of changes we are talking about,
remote insertions, edits or deletions of accounting data
held in branch accounts in the BRDB or the messagestore,
do you accept that Fujitsu applied a rule that changes
of that sort could only be made with another colleague
reviewing and approving the change that was going to be
made, yes?
A. Yes. There is often a record that you will see that
will say authorised by somebody and witnessed by
somebody.
Q. And there are in the trial bundles a consistent series
of documents which were produced and updated by Fujitsu
imposing this four eyes requirement for any change, yes?
A. Yes.
Q. Were you in court when Mr Roll confirmed in
cross-examination that the four eyes approach was
applied quite strictly?
A. Yes, it was, although I have noted documents that appear
to have the same name in the box of authorisation and
witness, I don't really know how that could occur, but
I do accept --
Q. Well, Mr Coyne, again that's something which you haven't
said in any of your reports, isn't it?
A. No, I don't believe I have.
Q. Do you not think it would have been helpful to have
revealed these points before your cross-examination
started so that the matter could be considered and
addressed?
A. I mean, to be fair, there might be other things that
arise that we could say the very same thing about.
There has to be a cut-off point by which time the report
gets sent.
Q. So you don't agree it would have been helpful to
reveal -- bearing in mind that permission controls are
specifically referred to in the Horizon Issues, you
don't believe it would have been helpful even to discuss
with Dr Worden what you had found in the documents?
A. As I said before, I agree that you have asked me the
question now and I have told you something and I can see
how that would be helpful to include within the report,
but there has to be a cut-off time when the report gets
sent or you could literally spend days and days and days
adding things to the report.
Q. But Mr Coyne, your fourth joint statement was made on
4th March, wasn't it, over a month after your second
report?
A. Yes.
Q. And that fourth statement contains a number of
references to OCPs and OCRs, doesn't it?
A. Mm.
Q. And yet nowhere -- and it also contains a number of
assertions of your own view. It is not as if it is
simply a statement of matters are agreed, actually there
are a considerable number of things that you assert
unilaterally?
A. Yes.
Q. But nowhere is there any hint of the two revelations
that you have just produced in court today. Is there
a reason for that?
A. Well, I don't believe they are revelations, I'm just
simply answering the questions that you are putting to
me.
Q. Perhaps I could suggest this: you take the view that it
is not relevant to any of the Horizon Issues that arise
for determination in this trial, is that your view?
A. No, no, it may well be relevant.
Q. Let me move on.
It is important to distinguish, isn't it, between
two questions in relation to permission controls. The
first one is whether controls could sensibly be tighter,
and the second is whether any weakness in the controls
has created adverse effects because, for example,
something was done wrongly or done too often?
A. Yes.
Q. So imagine, for example, some very lax controls around
the use of a tool that was never in fact used. That
would be regrettable but it wouldn't actually have
a practical impact in a case of this sort, would it?
A. If there were lax controls but there were no actions
that were used to exploit that lax control, then yes,
I agree.
Q. The same goes if the tool is used, but it is fair to see
from the evidence that the tool was used rarely and it
was used in a careful way. Again, the fact that
permission controls weren't as strict as perhaps some
people might think, that wouldn't adversely affect the
net outcome, the practical impact of the existence and
use of the tool, would it?
A. I think the problem with permission controls is that it
allows somebody into a system and on that system there
could be a number of different tools, so they may not
have used the prescribed tool but they're then into the
system so they could use other tools. That is the
danger with --
Q. Mr Coyne, I would ask you -- I have limited time and
your reports are really huge and contain a vast number
of claims which I can't possibly deal with in the time
that I already have available. I would ask you, please,
to focus on my question and answer my question rather
than to go off, turn left, and give me an answer which
you conceive may assist some other aspect of your
analysis.
My question was: in circumstances where the tool is
used, but it is used rarely and it is used carefully,
that won't have a practical impact, for example, on the
reliability of the overall system and the reliability of
the accounting data contained in the branch accounts,
would it?
A. No.
Q. Thank you. If we move on to Issue 12 which is on page
{C1/1/3}, the next issue is how often was any facility
used, if at all? That is a practical question -- the
previous one we looked at is a theoretical question --
it is a practical question of scale. Now, you have seen
over 220,000 PEAKs, haven't you?
A. Yes.
Q. And we know from the answers you have previously given
you have also seen many tens of thousands of OCPs, OCRs
and MSCs, haven't you?
A. Yes.
Q. And they are a rich source of material to interrogate to
ascertaining the answer as to whether and how frequently
facilities were used to remotely access branch accounts
and change the accounting data in those branch accounts,
yes?
A. They are a good source of information that would
indicate what steps were taken. They very, very rarely
outline what was done within the branch accounts.
Q. Well, is that right? Let's take it in stages. PEAKs --
if there is some remote access by Fujitsu, it will be
mentioned in a PEAK, won't it?
A. Yes, if there is a need to conduct some remote access
then, yes, that's often --
Q. And the PEAK, as well as identifying the fact of some
remote access, will give a fair indication of the sort
of remote access that's being exercised, yes?
A. Often, yes.
Q. It won't -- it may not give you the SQL lines that have
actually been written if that is the form of remote
access being used, but it will give you a fair
assessment of the nature of the change that's being done
and the effect of that change, yes?
A. From reading it you can often see what is going to be
done but you can't often see the effect. That's the
issue that I have.
Q. Could I suggest to you, Mr Coyne, that you can usually
see the nature of the change that's being affected?
A. The nature of it but not necessarily the number of it.
If it is a value, you don't often see the value --
Q. So you are suggesting that you can see a change is being
made to a particular kind of value but it may not tell
you what the numerical number of the change is, is that
what you are saying?
A. Yes.
Q. And as well as PEAKs, you have the ability to search
OCPs and OCRs and MSCs as well?
A. Yes.
Q. And they give you further information relating to the
question whether any remote access has been exercised so
as to affect branch accounting data, correct?
A. Yes.
Q. So between the PEAKs on the one hand and the OCPs, OCRs
and MSCs on the other, you do have a rich resource, if
you choose, to go through them and form an assessment of
the scale of the exercises of remote access that have
happened in the last 15 or 16 years, yes?
A. You get an indication of what was occurring, yes.
Q. As we have already discussed, you are capable of using
search functions to look for cases where that form of
remote access has been exercised, where there has been
remote access affecting branch data. You are well
capable of -- by looking for FAD codes or the word "FAD"
and by looking for other technical terms that often go
hand in hand with the exercise of remote access, you are
well capable of finding -- doing intelligent searches
with a view to finding documents indicating the overall
scale of the remote access that has been exercised,
would you agree with that?
A. No, that's not a very easy task, to identify remote
access and how it took place. You can't very easily
search for things like SQL statements, you can't
actually search really for FAD code because FAD is a box
at the top of most of the PEAKs, it is just often not
filled in, so that isn't a very good thing to search
for. We recently found out that there was -- I think
the word Riposte import or something was an indication
of -- so that helped us with our searching.
So it is true that we have identified things that
would indicate remote access but I don't believe we are
advanced in that.
Q. What I would suggest to you, Mr Coyne, is that where
there is an exercise of remote access in relation to
a branch's account, the PEAK will identify the branch by
its FAD code, yes?
A. There are certainly occurrences of that, yes.
Q. Mr Coyne, you are understating the position, aren't you?
It will invariably be the position that where there is
a problem at a branch which requires some form of remote
access to be exercised, the PEAK will identify the
branch that is concerned. That's just how the system
works, isn't it?
A. It will sometimes say a correction or an adjustment
needs to be made at the branch and that might be the
terminology. There will sometimes be a FAD code, there
will sometimes be the name, so Dalmellington for
example, but it is not always consistent.
Q. And in the same way, the OCPs and MSCs, you will have
corresponding OCPs and MSCs relating to the exercises of
remote access, they will identify the branches. Where
there is a form of remote access dealing with branch
data --
A. They certainly should do, yes.
Q. -- they will identify the branches. So with intelligent
search functions it is possible to form a view, isn't
it, of the nature of the branch -- the scale of the
exercise of remote access to affect branch accounts?
A. I mean that is a hugely complex task to start from the
large number of PEAKs, attempt to determine which within
those PEAKs suggest remote access, and then go from the
PEAKs into the OCRs and OCPs. Yes, you could do it for
one or two examples, but you couldn't do that for all,
that would be --
Q. You could do it for a sample, couldn't you? You could
choose a sample of particular branches with particular
names and FAD codes and you could use your search
function to see how often those branches have been the
subject of exercises of remote access, couldn't you?
A. Yes, you could do that. Yes.
Q. And that would be a very easy way of forming
an assessment of scale, the scale or the extent to which
remote access has been exercised, wouldn't it?
A. If you were confident that you had all of the search
terms that would confirm remote access has taken place
then you would use those search terms.
Q. You could just choose a group of FAD codes and a group
of branch names that correspond with those FAD codes.
You would identify a series of PEAKs and a series of
OCPs, OCRs or MSCs with those FAD codes in them and you
would be able to go through them and form an assessment
of how often that happened?
A. From the starting point of a particular number of FAD
codes?
Q. Yes.
A. Yes, that would be possible to do.
Q. And it would have been a suitable and helpful thing to
have done that, wouldn't it?
A. Yes, I think it would be. If we could identify
particular FAD codes and try and analyse the entire
movements of what has gone on with that particular FAD
code, that might be an exercise to do.
Q. 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?
A. 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.
Q. 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?
A. Can we go to the RFI and have a look at that?
Q. Let's do it after a break, shall we?
MR GREEN: My Lord, I'm concerned about fairness about what
was said and things being put to a witness which are
just not right, but then it is a matter for my learned
friend.
MR DE GARR ROBINSON: Let me discuss it with my learned
friend because if I have gone wrong, I will be the first
to apologise.
MR JUSTICE FRASER: Do you mean about the existence of the
RFI?
MR GREEN: No, my Lord, the fact that at an early stage
attempts to look at aspects of claimants were met with
a rebuff that it was not about these claimants
specifically.
MR JUSTICE FRASER: All right.
MR DE GARR ROBINSON: See, that's exactly --
MR JUSTICE FRASER: All right. I'm not going to have a spat
during a cross-examination. Mr de Garr Robinson says he
is going to perhaps return to it after the break and you
have got your re-examination.
MR DE GARR ROBINSON: So I have suggested to you, Mr Coyne,
that it would be possible. I mean, you have been aware
of the FAD codes of the claimant branches for a very
considerable time, haven't you?
A. No, I haven't.
Q. The FAD codes I'm informed were included in Dr Worden's
first report. Do you recall that?
A. The FAD codes are certainly included in one of
Dr Worden's reports, I'm not sure whether it was his
first one or not.
Q. So it isn't the position that the FAD codes for the
claimant branches are things you have only just become
aware of recently, it wouldn't be right to say that,
would it?
A. I haven't concerned myself with claimant branches
because it was made quite clear to me that there was no
interest in this matter about particular claimants.
MR JUSTICE FRASER: Did you have the FAD codes before
Dr Worden's report?
A. No.
MR JUSTICE FRASER: All right.
MR DE GARR ROBINSON: It needn't be the claimant FAD codes,
one could just take a sample, a random sample of
branches, and perform an analysis which would give you
an indication of the sort of scale of remote access
that's happened over the past 15 or so years, yes?
A. If you were aware of the things that you should be
searching for then, yes, that would be possible.
Q. Well, if you were aware of the FAD codes of your sample
group, Mr Coyne, yes?
A. Yes, and then look at the whole history of support
across the FAD codes, yes.
Q. Moving on. Two elements to the extent, the potential to
affect liability in issue -- well, let's move on to
issue 13:
"To what extent did the use of any such facility
have the potential to affect the reliability of
branches' accounting positions?"
That involves two distinct questions, doesn't it?
It involves how often it happened in the first place,
which is raised in Issue 12, yes?
A. Yes.
Q. And it also involves a question as to how carefully any
remote access was done, whether there are reasons for
thinking it was done casually and without proper regard
to the accuracy of any changes made, or whether it was
done extremely carefully in accordance with procedures
that we have already discussed, yes?
A. Yes.
Q. So if one were to get to a position where one is aware
that remote access has happened on some occasions but
doesn't happen thousands and thousands of times
a year -- I mean, you have no evidence to think, do you,
that remote access has happened thousands of times
a year?
A. No.
Q. Do you have a sense, bearing in mind the documents you
have seen, as to the likely scale of annual remote
access?
A. No. It would appear that the access in Legacy Horizon
was higher than it would be in Horizon Online but
I don't really get an indication of scale.
Q. You have not found hundreds of PEAKs or hundreds of OCPs
or MSCs showing that remote access affecting branch
accounts has happened in this case, have you?
A. No, there won't be hundreds that refer to adding
messages or things like that.
Q. I have read your reports -- I have tried to read your
reports quite carefully, it is always a dangerous thing
to make a claim of that sort, but my apprehension from
the reports I have read, particularly your second
report, is you had found relatively few occasions when
remote access had been used to affect branch accounts,
would that be fair?
A. There's often talk about the need to make a correction
or to address a discrepancy and there's often a couple
of ways of doing that. Sometimes you will see in the
PEAK that the question will be asked -- sorry, the
statement will be made: this can either be corrected by
inserting a message or do Post Office want to issue
a transaction correction to make the adjustment? So you
often see that. So you don't know what the outcome of
that was.
Q. Mr Coyne, you have referred to some of those PEAKs and,
so far as I can tell from having read them myself, where
there has been an exercise of remote access that's
recorded in the PEAK. The PEAK doesn't go quiet once
the possibility is mooted, it only goes quiet when
remote access hasn't been exercised because it has been
dealt with by different means. Surely you would agree
that?
A. When it goes quiet and you don't know what it is, the
two options are given in there. So it is either that
Post Office has been asked to correct it or remote
access has taken place, there's no evidence either way.
Q. Mr Coyne, I think we agreed yesterday that Fujitsu in
the production of PEAKs are quite process driven, yes?
A. Yes.
Q. When they do something, when they do a piece of work in
relation to a particular PEAK they will write down, they
will indicate in the PEAK what work they have done?
A. Yes, that's fair.
Q. And what I would like to suggest to you is that it is
clear that in circumstances where you have a PEAK and
someone at the SSC is wondering whether a change or
a remedy should be applied either by Post Office issuing
a transaction correction or perhaps by doing some form
of remote access, in circumstances where the transaction
correction or other manual approach is adopted, there
will be no suggestion of any remote access being adopted
later on in the PEAK, yes?
A. Yes.
Q. But where some remote access is done, where a decision
is made that the person at the SSC is actually going to
make a change, that will always be documented in a PEAK,
will it not? That's how Fujitsu work?
A. Yes, I would agree that that would appear to be their
typical process.
Q. Thank you. Bearing in mind that you have now agreed
I think on two occasions that where there has been some
remote access there will be a PEAK indicating that it
has happened, if I could go back to my earlier question:
I would be right in thinking, wouldn't I, that of the
PEAKs you have seen you found relatively few examples of
remote access having been exercised? Would the answer
to my question be right?
A. I don't know exactly what the number will be, but it is
tens, twenties --
Q. Looking at your report it would be low tens, wouldn't
it? You haven't found hundreds?
A. No, I haven't found evidence of hundreds, no.
Q. So you have found, as I say, a relatively small number;
relative to the fact that we are talking about 3 million
branch accounts over the last 20 years, all you have
actually found is a very small number which is less than
20 or 30, let's call it less than 30, would you agree
with that?
A. Yes.
Q. Thank you. Just to finish off on Issue 13, if the
evidence indicates that remote access is really
relatively rare and over a period of, say, 15 years it
has only happened on perhaps 100 or so occasions, and if
the evidence shows, that's so far available, that when
remote access is exercised, it is exercised very
carefully and people check the change being made and so
on, would you accept that the chances of remote access
being affected in a way which adversely affects branch
accounts, in other words which creates false shortfalls,
is vanishingly small compared with the 3 million branch
accounts that we know have been produced during the life
of Horizon?
A. It would be fair to say that it would be reasonably
small. I don't know about saying it was vanishingly
small.
Q. It would be what Dr Worden calls in his report a second
order issue, yes?
A. I mean there is evidence of mistakes being made in
remote access --
Q. Really? Is there evidence -- have you seen a single
document indicating the form of remote access we are
talking about, namely remote access, affecting branch
accounts, as opposed to remote access affecting, say,
the TPS system or something? Are you aware of a single
instance where that form of remote access has ended up
in creating a false figure in a branch's accounts?
A. Yes, we saw one, one was put on a witness in the early
stages with the £1,000 that was left.
Q. Is that the only example that you have seen?
A. Well, I have seen that example. Again that's something
that's incredibly difficult to search for or audit
because you don't have the values into the PEAKs, so
if --
Q. But I --
A. Sorry, let me finish. So if remote access is recorded
the outcome isn't often recorded.
Q. But going back to my question, I think you have answered
a different question. You have indicated that errors
might sometimes happen?
A. Yes.
Q. And I'm not seeking to suggest that perfection can ever
be achieved, so I'm not seeking to dispute the
possibility of errors happening. What I am seeking to
suggest to you is that all the evidence you have seen
indicates that when Fujitsu did remote access they did
it carefully, yes?
A. Yes.
Q. And that it is fair to infer that when that careful
remote access was done, the chances of a false figure
being introduced into a postmaster's account was very
small?
A. It was small.
Q. It would be less than 1%? Certainly less than 5%, yes?
A. I would be uncomfortable trying to put a percentage on
it. I'm happy to say it would be small.
Q. So in circumstances where you are aware of a relatively
small number of cases where remote access has actually
happened, and where you accept that the chances of
remote access being done incorrectly so as to produce
false figures is quite small, then the overall chance of
an account -- any particular branch account being
adversely affected by remote access is absolutely tiny,
isn't it, because it is a small chance multiplied by
a small chance, correct?
A. By this particular form of remote access then I do agree
it is small.
Q. That's what Dr Worden calls a second order issue, and
would you therefore agree with me that that
characterisation is correct? In the scheme of this
case, where the overall decision to be made by the court
is how robust Horizon was in the 3 million-odd or so
accounts that it produced over its 20-year life, this
particular issue is not of great practical significance
because it is a second order issue, yes?
A. I mean, what we have talked about here is the insertion
of messages and editing in BRDB. We have excluded
certain elements of remote control there, we haven't
talked about rebuilding or anything like that. Are we
going to come onto those later?
Q. Yes, we are. You are talking about rebuilding. Are we
going to talk about the process by which messagestores
in Legacy Horizon will be trashed and then replicated
from back up copies on the mirror server --
A. Yes, because they actually have an impact on messages at
the branch which do have an impact on --
Q. We are going to come to that. But just taking that very
briefly, the process we have just discussed, that form
of rebuilding where a counter for some reason has
a problem and its messagestore is deleted, what that
does is it triggers an automatic system in Riposte, yes?
A. Right.
Q. Which causes the mirror server, which contains all the
data, to be replicated to the particular machine whose
messagestore has been deleted, yes?
A. That is the process, how it should work, but there is
evidence of that failing and messages having to be
extracted from hard drives of failed counters, the
actual messages being taken out there and then rebuilt
on another counter. So I agree that what you have
outlined there is the position that should happen.
Q. We will come to those examples, I will ask you about
those if I have got time. But they are relatively few,
yes? We are talking about a very small number of
examples that you are aware of, is that right?
A. There is quite a few where that --
Q. When you say quite a few, how many are you aware of?
A. I have certainly found ten or so.
Q. Okay. So ten occasions over the ten-year period up to
Horizon Online. But laying those aside, the standard
form of messagestore deletion with automatic
replication, that is a form of a back up. That's
actually a form of robustness, isn't it, because what
happens is when that system is invoked, it is invoked
automatically, the system is designed --
A. It is designed to do that, yes.
Q. -- to operate in that way. And what then happens is you
have a machine which actually has the right data on it
after all?
A. That's absolutely the way that it should happen, yes.
Q. So let's now look at the forms of remote access you have
addressed in your report. Can we go to the fourth joint
statement, please, that's at {D1/5/4}. If I could pick
it up at page 4, paragraph 10.2. This is addressing the
ability/facility to insert, inject, edit or delete
transaction data or data in branch accounts, so this is
what I call proper remote access, yes?
A. Yes.
Q. What you have done there is you have set out the forms
of remote access of which you are aware, is that right?
A. Yes.
Q. Are there any other forms of remote access of which you
are aware that are not set out in the this joint
statement?
A. No.
Q. Thank you. So what I need to do today is cross-examine
you on the forms of remote access that I will find in
this joint statement, correct?
A. Yes. You started this session by reducing what remote
access meant.
Q. I started this session by defining what remote access
was, Mr Coyne, which was what's referred to in Horizon
Issue 10 --
A. Yes, and you said this excluded --
Q. -- which is inserting, injecting, editing or deleting
transaction data or data in branch accounts.
A. Yes.
Q. What I'm doing, I'm not seeking to pull a fast one, I'm
simply seeking to ensure that that's what we are talking
about in the course of today, because if we talk about
too many other things we will never finish. Okay?
A. Okay.
Q. Thank you. Laying aside whether the forms of remote
access you describe here do account as forms of remote
access, would you agree that the forms you have
identified in the joint statement are consistent with
the basic forms discussed in Mr Godeseth's and
Mr Parker's witness statements?
A. Yes.
Q. You have not discovered any forms of remote access that
they haven't discussed, have you?
A. No. There is modification to back end systems.
Q. Yes.
A. And it is often blurred whether people describe that as
being remote access or not.
Q. Yes. But on the basis of the definition I very
carefully and at somewhat boring length tried to
establish with you over the past hour, then that doesn't
count as remote access within the meaning of Horizon
Issue 10, does it?
A. Yes, okay.
Q. Thank you. Let's try and establish some other important
distinctions about data that may be contained in
accounts but isn't accounting data. Could you tell me
what recovery flags are?
A. Yes, it is what we talked about yesterday when we talked
about flagging the ground whenever a recoverable
transaction starts, and then at the end of it, if that
transaction is completed, the flag will then be removed.
But if a counter reboots and attempts to restart it
looks to see whether there is a recovery flag there, and
if there is a recovery flag there then rather than just
allow the subpostmaster to serve the next customer it
attempts to deal with that recoverable situation.
Q. So a recovery flag is not of itself a branch accounting
data? It is not transaction data and it is not a branch
accounting data, is it?
A. It is not, but it indicates that there is a situation
that has occurred, that a transaction might be part
complete. So it is an indication that something needs
to be looked at very carefully to see if there is
something that's out of balance.
Q. But it is not the data that's referred to in Horizon
Issue 10, is it?
A. No. It has an impact on the data that is Horizon
Issue 10 but it isn't in itself transaction data.
Q. And it is not recorded in the tables that constitute
a branch's accounts in the messagestore or the BRDB, is
it?
A. I think it is in the BRDB.
Q. It is in -- I was quite careful in my question. Let's
just talk about the BRDB which is Horizon Online. The
tables that the recovery flag are contained in are not
tables which contain transaction data within the meaning
of Horizon Issue 10, are they? They are not data that's
in the branch's accounts. It is a different -- there
are hundreds of tables in the BRDB, yes?
A. Yes.
Q. And the recovery flags, and there will be other tables
containing the data relating to the transaction to which
the recovery flag relates, yes?
A. Yes.
Q. Both the tables containing the recovery flags and the
tables containing the data relating to recoverable
transactions, those tables do not form a part of
a branch's accounts, do they?
A. Yes, that is right. There is a danger, I think we are
probably splitting hairs, but there's a difference
between tables and fields within a table. But taking
your point at face value, yes, it is in a slightly
different place.
Q. Absolutely. The recovery flag is a field actually.
I do accept there is this concept of fields. But it
doesn't affect the answer to my questions, does it?
A. That is right.
Q. The tables we are talking about and the various fields
in those tables do not form part either of transaction
data in branch accounts or of other accounting data in
branch accounts, do they?
A. No. They are an indicator that something needs to be
checked in the branch accounts.
Q. And there is other data also, which I think is often
called configuration data, which are in other tables as
well which could be of great use to Post Office in its
accounting systems, or can be of great use in relation
to defensive programming or redundant storage of data
and comparison of copies of the same data in the system.
Things like time stamps where the system records all
sorts of time stamps, there can be hundreds of them for
one transaction recording the particular moment in time
at which the information relating to a transaction moved
from one table to the other or something was done with
it, yes?
A. I'm sorry, you have conflated so many different issues
there I'm not with you, sorry. I'm really not with you.
Q. It would take too long, let me move on.
When we talk about inserting or injecting data,
again can we agree that what we are talking about is
manually creating and inserting either accounting data
or transaction data, yes?
A. Yes.
Q. So a human being exercising some discretion and judgment
to produce some transaction data, for example, and then
inserting that transaction into a branch's accounts,
yes?
A. Yes, the process will be assembling all the characters
that are required for that transaction and then pushing
it into the database.
Q. An example of that happening would be what Mr Godeseth
calls balancing transactions, yes?
A. Yes.
Q. You are aware that Mr Godeseth restricts the definition
of balancing transactions to a form of transaction
insertion by using the transaction correction tool, yes?
A. Yes, there was a tool that was created for
Horizon Online for that purpose.
Q. Just to be clear, I'm going to follow the same practice.
So when I talk about balancing transactions, I'm going
to be talking about transactions that are a result of
the exercise of the transaction correction tool in
Horizon Online, okay?
A. And not any transactions that are outside of that --
Q. Yes. It is important to make that clear because in your
reports you often use the term "balancing transactions"
to refer to other forms of insertion, don't you?
A. But they are balancing transactions.
Q. I appreciate that that's how you think of them, but the
term "balancing transaction", the technical meaning of
the term "balancing transaction", is a transaction that
is inserted as a result of the exercise or the use of
the transaction correction tool. And there are other
forms of injection or insertion. For example, there
were transaction insertions that could be made in
Legacy Horizon, and Mr Godeseth is quite clear in his
witness statement, isn't he, that those aren't properly
to be regarded as balancing transactions, yes?
A. I accept that's the term that has been accepted by
Mr Godeseth, but in general accounting terms "balancing
transaction" is not just within Horizon, it is in
general accounting. It is a transaction that is
inserted to make something balance.
Q. Okay. For the purposes of this discussion let's adopt
IT terminology, let's not adopt what you regard as
ordinary accounting terminology. So just to be clear,
shall we first of all agree that when we talk about
balancing transactions we are talking about the
transaction correction tool, could we do that?
A. I can accept that.
Q. Can we also agree that there are a large number of
references in your report to balancing transactions that
have nothing to do with the transaction correction tool,
yes?
A. They are balancing transactions but outside of the
balancing transaction tool.
Q. Mr Coyne, I'm not seeking to criticise you, I'm just
seeking to get you to agree that in your report, when
you refer to balancing transactions, the judge shouldn't
think that you are talking about exercises of the
transaction correction tool?
A. Yes.
Q. My understanding is that you agree with that?
A. Yes, I do.
Q. Editing now. Editing again is manually manipulating
data that's already in the branch accounts, yes?
A. Yes.
Q. And deleting. With deleting there is an important
practical distinction to be drawn, isn't there, between
deleting a whole set of messages to allow -- the whole
messagestore to allow automatic replication to take
place, yes?
A. Mm.
Q. And manually deleting lines of transaction data, yes?
A. Yes.
Q. And those two are very different things?
A. Yes.
Q. Both involve deletion but they have different
implications. The first is an automatic process which
actually enhances robustness, it doesn't detract from
it. Would you agree?
A. Could you put that first one to me again, please.
Q. The process by which machines which have problems in
their messagestores, have their messagestores deleted so
that there is an automatic Riposte-generated process by
which a copy of the messages that have been created are
replicated back to that machine --
A. Yes.
Q. That enhances robustness, it doesn't detract from it?
A. That is right, yes.
Q. Thank you.
Now let's get some issues out of the way. First of
all, transaction corrections and transaction
acknowledgements. In your reports you treat transaction
corrections and transaction acknowledgements as remote
access facilities, don't you?
A. That was because there was a witness statement, perhaps
it was Mr Godeseth, where he outlined the ways that
branch accounts could be affected, and transaction
acknowledgements and transaction corrections were in
that list.
Q. But that approach leads to a very curious result,
doesn't it, Mr Coyne? It means that when Post Office
used to send error notices up to 2005, your view is that
that's not a form of remote access, yes?
A. Not for the purposes of the remote access that you
described before, no.
Q. But when the system was changed to transaction
corrections in 2005, you take the view that that is
a form of remote access?
A. Well, it is somebody remote from the branch having
an impact on branch accounts.
Q. I could go to the pleadings but I'm not sure I have ...
I could go to the pleadings, but if I simply suggest to
you -- would you recognise that the forms of remote
access that the Horizon Issues are getting at aren't
concerned with transaction corrections and transaction
acknowledgements, and indeed that the Horizon Issues
were drafted with a view to excluding the process by way
transaction corrections and transaction acknowledgements
were arrived at --
A. All right, okay.
Q. Can we agree that for the purposes of this debate it
really doesn't assist matters to include transaction
corrections and transaction acknowledgements, yes?
A. Okay.
Q. Would you give me a moment?
I'm sorry, I think I may have misheard you. I'm
told that in answer to my question you indicated that
error notices itself, in your view, would constitute
a form of remote access. Is that true?
A. No -- well, an error notice has been issued by
Post Office to make a change to branch accounts. So
depending on what definition we are using at the moment,
then it is somebody remote from the branch making
a change.
Q. My understanding of your report, Mr Coyne, was that you
were indicating that error notices didn't constitute
remote access but TCs did, because TCs were transmitted
electronically whereas error notices were transmitted by
post. Is that not your evidence? Have I misunderstood?
A. Could you take me to that paragraph --
Q. I'm not sure I can but it might be at paragraph 5.421 in
your second statement. I'm sorry to take time up with
this. It might be at bundle {D2/4.1/242}.
Yes, here we go, page 242 on the trial bundle copy,
and it is paragraph 5.422.
Here you:
" ... disagree with Dr Worden that TCs are not
inserted transactions ..."
You pick up at paragraph (b), you say:
"TCs - whilst these are visibly acknowledged and
accepted by the Subpostmaster ..."
And by the way, Mr Coyne, what we say in this case
is that remote access is all about transactions -- data
that is directly inserted into branch accounts without
the SPM having the ability to stop it?
A. Right.
Q. That's what the Horizon Issues, I will be submitting to
the court in due course, that's what the remote access
Horizon Issues were designed to address.
A. Yes.
Q. But be that as it may, you say whilst they have to be
accepted they are still inserted.
Then over the page {D2/4.1/243}, at paragraph (c)
you say:
"Prior to TCs, I do not consider manual entry of
error notice amounts to be inserted transactions, as the
Subpostmaster is responsible for entering them on their
system, which differs from TCs as they are resident
within the accounts electronically."
Do you see that?
A. Yes.
Q. So your view then was error notices weren't but TCs
were?
A. Yes, because one is created remotely and one is the
transaction is actually created at the branch.
Q. But your view now is that both error notices and TCs,
they also form a part of remote access, do they?
A. Well, the remote access that we just agreed to talk
about here excluded those and just talked about the
insertion of messages.
MR JUSTICE FRASER: Mr de Garr Robinson, I think someone,
maybe one of your juniors, might have set a hare
running. But looking at the -- is this question
an interpretation of the answer at {Day16/43:21}?
MR DE GARR ROBINSON: Thank you, my Lord.
MR JUSTICE FRASER: Is that the point you are pursuing? You
put a question at line 17, which was then answered:
"Not for the purposes of the remote access that you
described before ..."
Is that the point you are pursuing?
MR DE GARR ROBINSON: I was pursuing a suggestion that in
Mr Coyne's view --
MR JUSTICE FRASER: Based on that answer, though, I mean?
MR DE GARR ROBINSON: Yes. Is that right? Yes.
MR JUSTICE FRASER: The easiest way might be to deal with it
like this: do you treat error notices either in your
report or today as constituting remote access?
A. No.
MR JUSTICE FRASER: Right.
MR DE GARR ROBINSON: Very good.
MR JUSTICE FRASER: Back to you, Mr de Garr Robinson.
MR DE GARR ROBINSON: Again in terms of -- well, you accept
it would be reasonable and sensible, bearing in mind the
nature of the Horizon Issues, just to lay TCs and TAs to
one side?
A. Yes.
Q. Because at least the SPM is aware of them and has to
press a button to allow them into his branch accounts?
A. Yes.
Q. Now let's talk about Post Office back office systems.
We have discussed several times already how Horizon --
for example, in Horizon Online it would be the BRDB --
feeds data to various parties including Post Office, so
Post Office systems like POLFS, POLSAP and Credence and
so on, but also to other systems.
A. Yes.
Q. And that's via what's known as the transaction
processing system, yes?
A. Yes.
Q. Often known as TPS.
A. Yes.
Q. And an aspect of the transaction processing system is
what's called TIP, yes?
A. Yes.
Q. Do you remember what that acronym stands for? A
slightly unfair question.
A. No. It will be ...
Q. Transaction information --
A. Processing, yes.
Q. And the TIP system is an interface, isn't it, with the
TPS system, so it allows files to be accessed and
perhaps -- I'm looking around to make sure I'm saying
the right thing -- so it is fair to say that TIP and TPS
are aspects of each other?
A. Yes.
Q. Or they are so closely related we can treat them --
A. They have an interconnection, yes.
Q. And both of them are not part of the BRDB, are they?
A. No, they take inputs from data which has been in the
BRDB and extract it and decide what to do with it.
Q. And branch accounting data is the data which is held in
the relevant tables within the BRDB?
A. Yes.
Q. What happens is copies are taken from those tables?
A. Yes.
Q. And they are transmitted into the TPS?
A. Yes.
Q. Once they are in the TPS they are held, reconciliations
are done, all sorts of things, they are looked at by all
sorts of people for all sorts of purposes, and also they
are propagated to various Post Office management
information systems and elsewhere?
A. And the clients and things like that.
Q. Yes. So it follows, doesn't it, that any change made to
any data in the TPS system or in the TIP aspect of the
TPS system, that is not a change to data held in branch
accounts in Horizon, yes?
A. It is not, but any changes made in there can have the
impact on branch accounts.
Q. And what you are suggesting there is a mechanism by
which a change is made to some data that's held in TPS?
A. Yes.
Q. That data is then transmitted to Post Office?
A. Mm.
Q. Post Office looks at it and thinks that must be correct,
looks at the data that's in branch accounts and sees
that the data is different?
A. Yes.
Q. And then decides to issue a transaction correction?
A. Yes.
Q. So what we are talking about is a situation where
a change has been made to the TPS, data in the TPS?
A. Yes.
Q. And has been made wrongly?
A. Yes.
Q. And that error has then caused Post Office itself to
make an error?
A. Yes.
Q. Which results in a transaction correction decision being
made, yes?
A. Yes.
Q. Would you agree with me, Mr Coyne, that that also is
a second order issue of the sort that we discussed
earlier?
A. Could I please have a definition of that second order
issue?
Q. Let me just take it in stages. One of the main purposes
of the TPS system or one of the main aspects of the TPS
system is the harvesting and reconciliation processes
that are operated within it?
A. Yes.
Q. And the purposes of those operations is to ensure that
the data in the TPS system -- TPS stands for, I'm saying
"system" twice but you will forgive me if I make that
mistake. That data is then compared with other
available forms of data with a view to checking to see
whether it is correct or not?
A. Yes.
Q. And in circumstances where the data in the TPS system is
wrong because it has been changed, it will create
a discrepancy, won't it?
A. It will, yes.
Q. Between the data that's in TPS and the client data that
it is being compared with?
A. Yes.
Q. So for the scenario that you are suggesting, what would
have to happen is some human being would have to make
a deliberate change to the information in the TPS --
A. Using the TIP correction tool.
Q. And it would throw up a reconciliation error exception,
wouldn't it?
A. To Post Office, yes.
Q. What you are suggesting then is Post Office would see
a discrepancy but prefer the TPS version of truth
compared to the client data version of truth, yes?
A. Yes.
Q. Secondly, that would be a necessary condition before
there's any possibility of Post Office issuing
a transaction correction, yes?
A. Yes. So it is either a correction that's been made with
the TIP correction tool, which is the tool -- I think we
saw a screen shot of it earlier on within the trial,
where a copy of the data is brought up and then the user
can make modifications to that data, either the value or
where it is destined for, so the change is made. You
can either do it on one transaction or it can be done on
many transactions if the same fault occurs with all
transactions. You can fix lots at once and the tool
then sends the data on its way.
Q. Are you approaching an answer to the question I actually
asked you, though, which is: the chances of a change to
the TPS data, it would be picked up as a reconciliation
exception, wouldn't it?
A. Yes.
Q. And what would be necessary is for Post Office to decide
that the TPS erroneous data was right as compared with
the client data that's direct from the branch --
A. Yes, the Post Office would have to make a decision on
that.
Q. And that is quite an unlikely eventuality, isn't it?
A. I don't understand why you would ask that. The
Post Office would need to make a decision on which set
of data is correct.
Q. Let's take it in stages. You would accept, I am sure,
that when changes are made by human beings to the TPS it
is to correct problems that have become apparent in the
TPS, yes?
A. Yes.
Q. No one would make a change in the TPS in order to
introduce an incorrect figure?
A. I agree.
Q. So the purpose of any change that's made using the TIP
repair tool, that's what we are talking about, and I am
sure your Lordship is familiar with that tool, the
purpose of the TIP repair tool is actually to ensure
that there is coherence in the data in the TPS system as
compared with the data in the branch accounts and the
data held by clients. That's the general purpose of
making changes?
A. Yes.
Q. You would only use the TIP repair tool where you thought
there was a problem in the TPS because it is not
consistent either with branch accounts or with client
data, yes?
A. Yes.
Q. So we are talking about a scenario where a change is
made for the purpose of ensuring that data is consistent
with branch accounts but being done erroneously so that
it becomes inconsistent with branch accounts?
A. Yes.
Q. Would you accept that that's quite an unlikely
eventuality, in practice?
A. It certainly shouldn't occur that people make mistakes
with the tool but it is possible that it can occur.
Q. Mr Coyne, you do seem to be struggling to accept
something which in my respectful suggestion is
blindingly obvious, which is that in the vast majority
of cases, given the purpose with which the TIP repair
tool is always used, the chances of the TIP repair tool
being used in a way which introduces an error -- which
actually introduces an inconsistency with branch
accounts when the whole purpose of the tool is to ensure
that doesn't happen, usually it is to ensure coherence
between the accounts and the TPS system -- the chances
in the real world of the use of a TIP repair tool which
introduces a discrepancy is very small?
A. All that can be fairly said about that is that it would
require human error.
Q. That's all you are willing to say about it. But could
I suggest that someone applying commonsense to the
situation would readily say, yes, the chances are very
small?
A. It's whatever the chances are of a human making an error
with that.
Q. You really don't want to talk about extent, do you,
Mr Coyne?
And where that kind of error happens, the chances of
that error then not being picked up when Post Office
looks at the client account and looks at the client
data, the chances of Post Office favouring the erroneous
TPS data over the alternative sources of data that are
available, would you accept the chances of that
happening are very low?
A. No, I don't accept that.
Q. Why don't you accept that? Isn't it commonsense again?
A. It's not, because when you see suggested adjustments
coming in from the third parties, and one of the
examples was the Santander corrections that arrived from
the client, many of those it was said got sent on to the
postmasters as TCs and they had to dispute those TCs.
Q. Mr Coyne, are you referring to the evidence that was
given in Mr Smith's first witness statement about
Santander transaction corrections and the disputes in
relation to that?
A. Yes, quite possibly.
Q. And have you forgotten the evidence that's given in
Mr Smith's second witness statement explaining that
those figures don't actually represent what, entirely
fairly, you understood them to represent in his first
witness statement?
A. Yes, I think what he changed it to was that they were
mistakes made by Santander that the Post Office
disputed. Is that the correction that he made?
Q. Santander were operating a system, as I recall, in which
paper had to be sent from the branch to Santander and
Santander often wouldn't get the paper, so it would take
the view that a transaction either had or hadn't
happened in a particular way. What would then happen,
it would send its figures through, there would be
a discrepancy between its figures and Post Office's
figures, and Post Office would then go to the branch and
say "Have you sent the paperwork?" And quite often the
branch would then provide the paperwork which
Post Office could show to Santander in order to
demonstrate what the true position was. Does that ring
a bell?
A. It does ring a bell, yes.
Q. Right. That has nothing to do with changes made by use
of the TIP repair tool to the TPS system, does it?
A. No, I think that's probably right. But what my
illustration was, you asked the question whether it is
more likely that Post Office would accept the
postmaster's position rather than another set of data,
and I said that I don't believe it is unlikely because
there is evidence that Post Office have taken the other
party's position as to what the data should appear as
rather than the postmaster and --
Q. Okay.
A. Sorry let me finish, please. And that's what's led to
some of the TCs being disputed by the subpostmasters and
that that dispute has been accepted by the Post Office.
Q. Let me get this straight then. We have a scenario where
data that is correct in the BRDB goes into the TPS and
Fujitsu decides to change it. Yes?
A. Yes, Fujitsu intervened on that data and made some
correction.
Q. And I think you have accepted already that when Fujitsu,
using the TIP repair tool, decides to change some data
it will be for the purpose of ensuring coherence between
the BRDB and the information that is in the TPS system?
A. I would have thought that was the way --
Q. Yes. So what you are suggesting is a situation where
the intention of Fujitsu is to ensure that the figures
are the same, but something goes wrong such that a false
figure is injected into the TPS system?
A. Yes.
Q. So we have the correct figures in the branch accounts?
A. Mm.
Q. We have an incorrect figure in the TPS system, which
then goes -- which is then harvested and, as part of the
process, is compared with lots of other forms of data
including client data?
A. Mm.
Q. And what you are suggesting is -- let's say the Fujitsu
person who made the change wrote down £10 instead of
£100. What you are suggesting is because client
reconciliation data can be erroneous too, there's
a chance that the client will itself have written down
£10 instead of £100 and in those circumstances
Post Office will accept both sets of figures. That is
the scenario you appear to be suggesting, yes?
A. No, not that two people will have the erroneous sets of
figures. That there will be an error introduced using
the TIP repair tool by Fujitsu but that the external
client has a different view of that data.
Q. What I was seeking to ascertain from you, Mr Coyne, is
whether you are willing to accept that in the real world
the chances of Fujitsu making a mistake so as to create
a discrepancy rather than to create one or affirm one by
its use of the TIP repair tool, which is its intention,
and the chances of when that happens of Post Office
looking at that error and looking at the client data and
deciding to accept the erroneous figure rather than the
client data and what's already in the Horizon branch
accounts, what I'm suggesting to you is that that
scenario is obviously a very unlikely one. I'm not
saying it is impossible, but in the real world the
chances of those different kinds of errors all combining
together to result in a false transaction correction is
very low?
A. I do accept that it is low but it isn't that many errors
that's required. It is only really required that
an error is made by Fujitsu either on the value or
potentially the transaction type, because if the
transaction type is altered the transaction could go
somewhere differently or be dealt with differently. And
then the only other decision that needs to be taken is
that Post Office accept that data rather than the
branch's version of the data.
Q. And you are suggesting that in circumstances where the
transaction is properly undertaken in the branch and
an error is introduced, and you accept it is going to
happen only in a small minority of cases, an error is
introduced, don't you accept that the circumstances in
which Post Office is likely to prefer that erroneous
figure than the figure that is correctly held in branch
accounts and correctly held by the client, the chances
of that happening in practice are very small?
A. Yes.
Q. And then of course there is a further chance it has to
happen, there is a further box that needs to be ticked
in order for branch accounts to be affected, because
once of course the transaction correction goes through
it gets sent to the postmaster?
A. Yes.
Q. And the postmaster says, "Hang on a second, I didn't
receive £90,000, this isn't right", and phones up the
helpline because that's what you do when you don't agree
with the transaction correction?
A. Yes.
Q. So again there is a further protection, there is
a further filter that needs to be got through, namely
either the postmaster not objecting or the postmaster's
objections being overruled?
A. Yes.
Q. And do you not accept that in the real world, given the
scale of the changes -- well, what is the scale of
changes made to the TPS system by using the TIP repair
tool? It is relatively small, isn't it?
A. It is relatively small in comparison with the number of
transactions per day, but it is a high number of repairs
that are made each day.
Q. How many?
A. I don't know precisely but I think it has been
mentioned. It is in the thousands, I believe.
Q. Thousands a day?
A. Of TIP repairs, yes.
Q. Okay. That comes as a surprise to me. But you are
saying it is small relative to the number of
transactions that are actually passing through the
system in the day?
A. Yes, but it is still quite a big number that he has
done. I do believe it is in evidence somewhere.
Q. I will have to look at that.
My Lord, I see it is 11.50, and this isn't
a convenient moment but in fairness --
MR JUSTICE FRASER: All right. Would you like to pursue it
for a couple more minutes?
MR DE GARR ROBINSON: Yes, if that's agreeable.
MR JUSTICE FRASER: As long as it is only a couple of
minutes then that's fine, otherwise we can break now.
MR DE GARR ROBINSON: Last question before -- or last
series, couple of questions. Where the TIP repair tool
is exercised there will be a PEAK relating to its
exercise, yes?
A. There should be, yes.
Q. Are you suggesting that there are PEAKs numbering in the
thousands per day reflecting the exercise of the TIP
repair tool in the PEAKs that you have seen?
A. No, I don't believe there is one, there isn't one PEAK
per TIP repair that's undertaken. You don't have a one
to one relationship.
Q. Have you seen a significant number of PEAKs relating to
the exercise of the TIP repair tool?
A. I don't know what the number will be, but there are
PEAKs that talk about the TIP repair cool.
Q. Could you give me a sense of scale? Are you talking
about a dozen, are you talking about a thousand, are you
talking about a smaller number?
A. What I'd prefer to do, because I'm pretty sure the
number of tips that are done per day or per month is in
the evidence somewhere, I would prefer to find that and
give you the number.
MR DE GARR ROBINSON: Very good. My Lord, perhaps that
would be a convenient moment.
MR JUSTICE FRASER: All right. You might not be able to do
that in ten minutes, though, I imagine, Mr Coyne?
A. No, I wouldn't imagine so, my Lord.
MR JUSTICE FRASER: No. So just to be clear, he's not being
asked to do that now.
MR DE GARR ROBINSON: That's a shame.
MR JUSTICE FRASER: Well, he doesn't have the trial bundle
apart from anything else.
We will have a 10-minute break. We will re-visit
that question at 1 o'clock about whether the witness
statements should just be given to the witness in a hard
copy for him to flick through over lunchtime.
MR DE GARR ROBINSON: My Lord, I'm afraid I'm very
old-fashioned. I'm in favour of hard copy bundles.
MR JUSTICE FRASER: No, I just mean whether it is the sort
of exercise you want done for 2 o'clock or whether you
want done this evening. You have still got tomorrow.
MR DE GARR ROBINSON: What, referring the witness to
particular witness statements?
MR JUSTICE FRASER: No, not you referring him to anything.
Him looking for the number that he says is there which
he says he will give you. But we will just address it
briefly at 1 o'clock, whether you would like it done
this evening or at lunchtime.
10 minutes.
(11.55 am)
(A short break)
(12.05 pm)
MR DE GARR ROBINSON: So Mr Coyne, just to finish up with
the line of questions we were exploring before the
break.
First of all you referred to the fact that
sometimes, let me put it this way, bulk changes were
made by means of the TIP repair tool, yes?
A. Yes.
Q. So changes were made to more than one item of data?
A. Yes.
Q. Would you accept that inevitably those changes are not
going to be changes to transaction data because of
course each transaction has its own individual
characteristics. Those changes will be changes to
attributes, you know, adding missing fields or flags of
some sort. Those would be the kind of changes that
would be done in bulk, yes?
A. Yes.
Q. So when we are talking about erroneous transaction data
being created as a result of the TIP repair tool in the
TPS system, we are not really worried about, we don't
need to be concerned about, bulk changes of that sort
because the basic transaction details will not be
changed.
A. Unless there were bulk changes made to things like
the transaction type or something like that.
Q. Have you seen any changes of that sort being done?
A. No.
Q. I'm grateful. Then just to finish up, the kind of
scenario that you are suggesting would require, first of
all, Fujitsu to make a mistake in its use of the TIP
repair tool, effectively to do the opposite of what it
intended to do, yes?
A. Certainly to make a mistake, yes.
Q. And Post Office to make a mistake in its review of the
relevant data and its comparison of that data with other
independent data, yes?
A. Yes, but I'm not sure what data Post Office actually has
to be able to make that determination.
Q. But Post Office would have to make a --
A. They would have to make a determination based on
something, yes.
Q. Then the postmaster would have to make a mistake either
in not objecting or in not objecting enough to the TC
that he has been provided with, yes?
A. Yes.
Q. So would it be fair to say that the scenario you are
talking about, if the scenario we were talking about
before was a second order issue, this is a third order
issue, isn't it? It requires a series of unfortunate
events, all of which are not particularly likely to
combine together, yes?
A. Yes.
Q. So in the real world, the overall likelihood of those
three things all happening at the same time again is
extremely small, yes?
A. It would be a small percentage of the millions or
billions of transactions, yes.
Q. It would be a fraction of a percent, wouldn't it?
A. Yes.
Q. Okay, one final question in relation to the TIP repair
tool. Could we go to your second report {D2/4.1/72},
please. I would like to pick it up at page 72.
A. Is that 72 on the face of the document?
Q. It is the trial bundle reference. All I'm taking you to
is the heading, you see the heading above
paragraph 3.220, "Evidence of Insertions/Deletions
within Branch Accounts ..."
A. Yes.
Q. So what you are talking about in this section is changes
to data which is held within branch accounts?
A. Yes.
Q. So what you are signalling to the reader is that the
changes being discussed in this section are all changes
being made to data that is held in the BRDB that
constitutes the branch accounting data, yes?
A. Or that has an impact on branch accounts, yes.
Q. No. You say your "Evidence of Insertion/Deletions
within Branch Accounts ...". What you are talking about
is insertions and deletions made to accounting data held
in branch accounts.
A. Yes.
Q. Surely you accept that that's what that heading conveys?
A. Yes.
Q. If we can go forward to page {D2/4.1/78}, perhaps
I could ask you to read paragraphs 3.247 through to
paragraph 3.248. {D2/4.1/79}
No, I'm so sorry, 3.243 through to 3.248, please.
A. 3.243?
Q. Yes.
MR JUSTICE FRASER: On page 78.
(Pause)
A. Yes.
Q. I am sure you know where I'm going, Mr Coyne, but in
those paragraphs you are talking about changes made to
data in the TPS, aren't you?
A. Yes.
Q. And yet you finish up with 3.248 which says:
"The PEAK above therefore indicates that Fujitsu
support had the capabilities to manually rebuild data."
This is all under the heading I took you to before.
So by data, you meant data held in branch accounts.
Would you accept that your entire approach to the TPS
system as exemplified in these paragraphs is actually
rather misleading?
A. I think the heading is misleading because it is talking
about modifications that have an impact on branch
accounts.
Q. Well nowhere, Mr Coyne -- correct me if I'm wrong -- but
nowhere in the section from 3.220 all the way through to
3.248 do you discuss the third order issue of
Post Office making a mistake as a result of what's in
the TPS, that mistake somehow getting through the
reconciliation process, a TC being sent to a postmaster,
the postmaster accepting it or not being able to dispute
it. You don't discuss any of that in this section at
all. You present this entire section as if you are
talking about changes being made to data in branch
accounts, don't you?
A. Yes.
Q. Do you not think it would have been helpful and balanced
to have made clear the fundamental distinction to be
drawn between remote access of the sort that is actually
raised in the Horizon Issues, namely remote access to
data held in branch accounts in the BRDB, and this kind
of data activity which is in a completely -- well, not
completely, but in a different system from the system
which holds branch accounting data. Do you not think it
would have been helpful to have made that clear?
A. But this separation between what remote means is
something that you wanted set out for the purposes of
questioning.
Q. So would I be right in inferring from your answer that
you didn't want to make that distinction? You were
quite happy for the distinction between changes made to
data in branch accounts and changes made to data held
elsewhere, you weren't interested in that distinction,
you just wanted to talk about changes made to data, full
stop?
A. That were remote from the branch. That it isn't changes
to data that's been made at the branch counter.
Q. But Mr Coyne, the branch can't change data that's held
in the TPS. So the notion that changes to data being
made in the TPS is being made remotely from the branch
makes no conceivable sense, does it?
A. But I think it does when the question being asked here
is whether data that was being modified or created was
created at the branch or not at the branch.
Q. What I would like to suggest to you, Mr Coyne, is that
in large portions both of your first report and of your
second report you gloss over the distinction between
changing data that's actually in branch accounts and
changing data elsewhere that may have other
consequences, that may indirectly one day, possibly,
depending on certain contingencies, have an effect on
what the branch accounts ultimately say. And what I'm
suggesting to you is it would have been helpful for
an expert seeking to address the Horizon Issues to have
made that distinction very clear. Do you accept that?
A. I don't accept that, no.
Q. Right, let's move on to global branches. You deal with
that in sections 4 and 5 of your second report. And in
that report you maintained that remote access was
possible for people with global user permissions
operating out of global branches?
A. Mm.
Q. You will recall that Mr Godeseth responded to that
suggestion in his third witness statement and explained
that that isn't the case because global branches can't
be used for the conducting of business and, if they
could, the business that would be done would be recorded
against the branch, the FAD code of the global branch
out of which the business was being done. Do you
remember that?
A. I do.
Q. I wonder whether we could therefore save some time if
I simply ask you whether, in the light of what
Mr Godeseth has said, you now accept that global users
can't remotely access the branch accounts of individual
branches when sitting at the screen of a global branch?
A. Yes. The information that I got was from the manual,
and the manual does suggest that that would be possible,
but I accept from the evidence of Mr Godeseth that that
is unlikely to be the case.
Q. You accept that in fact the way the system is designed
is that no business at all can be done at a global
branch?
A. Yes, that makes complete sense.
Q. And that even if business could be done at a global
branch, because it is intrinsic to the way that Horizon
is designed, that business would belong to, it would be
recorded as business being done by, the global branch?
A. Yes.
Q. Thank you. That has saved a great deal of time. I'm
very grateful to you.
If we could go now to the joint fourth statement at
bundle {D1/5/8}, paragraph 10.15. A short question
only. Here you say -- this is one of your personal
statements, it is not an agreed statement. At page 8,
paragraph 10.15, you say:
"The controls around branch account data do not
specifically consider if the monies within the
transaction actually go to the correct accounts. It
would be possible through simple changes to alter the
sort code and account number of the destination account
and unless this was spotted by the PM or the client,
Post Office system would not detect this."
Now, you then go on to talk about defects in Horizon
reference data, yes?
A. Yes.
Q. Just to be clear, the second paragraph there has nothing
to do with remote access, does it?
A. It has nothing to do with the way that you have set out
that you want remote access dealing with in this
section, no.
Q. Thank you. Now the first paragraph, I don't need to ask
you much, but is the scenario you are suggesting here
that a criminal working in Fujitsu could, if he wanted
to, spot that a payment was being, an electronic payment
was being made by a customer at an branch, identify the
payment that was being made, hack into the system to
change the sort code and account number of the
destination account, and by that means secure that the
payment, instead of being made in payment of a bill to
British Gas, it goes into his own bank account. Is that
the scenario you are raising there?
A. Yes. It doesn't require the hacking that you suggest
but, yes, that's what I'm --
Q. You are quite right, when I said "hacking", I'm speaking
in a -- I need to be more --
A. Yes. But the rest of that scenario is --
Q. So someone with privileged user abilities?
A. Yes.
Q. And which -- presumably he wouldn't be doing this in the
branch accounts, he would not be changing the data in
the branch accounts. If you are talking about the sort
code and destination account, he would be changing the
data that's passed through to Post Office, wouldn't he?
A. Yes.
Q. So we are not talking about data in the branch accounts
because that doesn't contain that sort of data, does it?
A. No, if this was going to go on it would go on at
Fujitsu's back office --
Q. It would be some sort of change to some Post Office
system, yes?
A. Yes.
Q. And it would be -- so what happens is a bill payment
transaction is done at the branch. It is transmitted
through to Post Office's back systems, so it goes out of
BRDB and goes into Post Office's systems. It waits
there for a while before it is then transmitted onwards
to the bank to actually make the payment?
A. Yes.
Q. And what you are suggesting is that a clever criminal
who happens to have privileged user rights would, in
that limited period of time, while the data is waiting
there ready to be sent off to the bank, use his
privileged user rights. Would he be doing this with
SQL?
A. He could do it with SQL. He might be able to do it
using the TIP repair tool, I'm not --
Q. Right. And by that means he would ensure that the
payment goes to himself rather than --
A. It would go to a different bank account.
Q. And in that scenario, of course, the customer who had
actually made the bill payment would immediately go back
to the branch and say "What the hell has happened?
I have paid my phone bill but I have just been cut off".
We have seen examples of that happening, haven't we?
A. Yes, there are a couple of scenarios where payments have
gone to wrong parties because of erroneous --
Q. So the kind of criminal that we are talking about, as
well as being a master criminal because he has got
privileged user rights and has the ability to use them,
so he is obviously of some seniority within Fujitsu, he
would also have to be an idiotic criminal, wouldn't he,
because that would be a step which would be bound as
night follows day to get detected because there would be
an investigation, wouldn't there, as to what happened to
the payment?
A. Yes.
Q. And on that investigation it would be discovered where
the money actually went and why it was that it got
there?
A. That bit is not as easy as you suggest, but yes, there
would be an investigation.
Q. And it would be possible, it may not be easy, but in
circumstances where money has gone in completely the
wrong direction, that would absolutely be something --
you have seen this with Fujitsu themselves, with the
Highland Council, it is something they took very
seriously indeed and they acted on it very quickly,
didn't they?
A. Mm.
Q. There would be an in-depth investigation to make damn
sure they knew what had happened, yes?
A. Yes.
Q. So in practice anyone working at Fujitsu would know very
well that it would be professional suicide to try
a stunt like that, yes?
A. Yes.
Q. And you would need to be quite well qualified. You say
simple, I think, but you would really have to have
a good understanding of the system and know which tables
to be looking at and what changes are to be made in a
way that didn't create some reconciliation error
somewhere else in the system. It would be quite
a sophisticated process. Your knowledge of the system
would have to be quite substantial, yes?
A. I have seen two or three of these and investigate them
and have a look at what has been actually done, in some
they have got away with it and in others they have been
caught.
Q. In the real world you have no reason for thinking that
has ever happened in Post Office, have you?
A. No.
Q. If I can ask you to look back at your report at page 245
{D2/4.1/245}, paragraph 5.427, this is where -- perhaps
we can go to the previous page so we can see the heading
{D2/4.1/244}. It is all under the heading "Global
Users", do you see? And you very fairly indicated that
in the light of the evidence you changed your mind, and
that is extremely helpful.
A. Yes.
Q. If we go to page 245, having addressed the question
whether global users have the ability to undertake
remote access, you then say:
"Also it is not (in my opinion) a question of
whether DBAs misused their powers, it is more important
to consider (in respect of their actions) whether they
might have erroneously (without intent) modified data."
That's true, isn't it? In the real world that's
what we should be focusing on. We don't need to focus
on hypotheses as to master criminals seeking to steal
someone's gas bill, do you agree?
A. Yes.
Q. Let's move to what I call remote access proper. Let's
take Legacy Horizon first. If we can go to bundle D1,
the joint statement again {D1/5/4}. This is where you
set out the form of remote access that you are aware of.
A. Yes.
Q. "In Legacy Horizon, rebuilding transaction data in the
branch, by replication from some other copy of the
data."
Stopping there, I think we have already agreed that
that -- first of all, it is certainly possible, it is
discussed by all the witnesses, but that's something
which enhances robustness rather than detracts from it,
yes?
A. There's two separate elements in there. There is the
automated way, which I agree is the way that the process
should work, but when the automated way sometimes fails,
there is a manual way where Fujitsu need to copy the
messages from the broken till or the till that has been
removed from site -- the counter that's been removed
from site. They need to get the messages from there.
They make a modification to those messages and they then
import those messages that they have recovered onto the
live systems.
Q. So what you are referring to is what Mr Parker discusses
I think in his third witness statement, is that right?
A. That may be right.
Q. Let's see if we can find it. Would you give me
a moment.
A. It might be Parker 2.
Q. Say again?
A. It might be Parker 2.
Q. His second witness statement. Thank you very much,
that's very helpful. Let me see if I can find it there.
My learned friend Mr Draper suggests it is in
paragraph 38 so he gets the blame if it is wrong. It is
at page {E2/12/12}. I apprehend this is what you are
thinking of.
38:
"For completeness, in the rare circumstances where
it was necessary for Fujitsu to rebuild transaction data
in Legacy Horizon [Mr Parker says] there were three
possible scenarios."
38.1:
"When a counter failed and there was a complete
replication of that counter's transactions elsewhere,
Fujitsu simply deleted the message (transaction) store
on the faulty counter and used the standard facilities
of the Riposte software to re-build the data from the
replicated copy."
And we have discussed that.
38.2:
"Where no replicated copies of the transactions
existed on the network, Fujitsu would physically
retrieve the disk from the faulty counter. The disc
should hold all of the transactions that had taken place
on the counter. At its own office, the SSC would
extract the transaction data and deliver it to the
replacement counter without amending that data. The SSC
would need the Subpostmaster's memory card (AKA PMMC) to
de-crypt the data."
Is that right?
A. Yes.
Q. "This was a physical card ... and Fujitsu would have to
borrow one so the subpostmaster would know what was
happening."
Would that be fair?
A. Yes.
Q. "If Fujitsu were to change anything, it would be to
remove the envelope around the transaction data."
Do you see that?
A. Yes.
Q. Do you accept that?
A. Yes. They go through a process of stripping the CRC off
and then recreating it afterwards.
Q. "The envelope contains the system admin data, i.e. the
sequence number of the data and its ID. Fujitsu would
not change the transaction data itself and in removing
the envelope data, they would simply be allowing the
system to automatically re-number the transactions when
they were re-inserted."
Does that make sense?
A. I'm not sure about the automatically renumber them. The
documents that I have seen make reference to a manual
renumbering of the transactions before --
Q. You have seen documents which talk about manual
re-numbering, have you?
A. Yes.
Q. Do you recall where those documents are?
A. The reference is to using the tool Text Pad, the text
editor to make the changes.
Q. Are we talking about PEAKs or --
A. It is a PEAK, I believe.
Q. Is this discussed in any of your reports? I'm not
building a big criticism, it is just this comes as news
to me and I'm wondering if I missed it?
A. I don't know if it is referenced in my reports or not.
If I could search, I could find it for you.
Q. Shall we give you some quick homework? Would that be
acceptable, my Lord, overnight?
MR JUSTICE FRASER: I have no objection. Are you able to
look at it after hours today?
A. Certainly, my Lord, yes.
MR JUSTICE FRASER: You might want -- so that is your
second, I think. That's his second. I see you are
taking a list. Have you got a list?
A. Yes, I have got it on here.
MR DE GARR ROBINSON: So what you are suggesting is it
wouldn't be automatic, the numbering would be manual.
A. I have certainly seen a document when the messages in
the messagestore have been taken from a disk that has
failed, editing is suggested using Text Pad, some
numbering is changed. Then Fujitsu use a tool called
Message Factory and that creates the CRC check to go
round the messages, and then they use the Riposte import
command, I believe it is, and that imports it back into
the branch.
Q. Well, perhaps we could see the document you are
referring to before -- I don't want to take up time
unnecessarily now. But you would accept, would you,
that for this to have a detrimental impact on branch
accounts there would have to be some quite surprising
error made. I mean there would have to be some change
actually made to the underlying transaction data and
that change would be erroneous?
A. Yes.
Q. And you see Mr Parker saying that Fujitsu's practice was
not to make changes to transaction data?
A. Yes.
Q. Are you aware of anything in the system, in the design
documents or other documents that you have seen, which
would indicate that -- or any PEAKs that you have seen
which would indicate that that had actually happened,
that any changes had been made to transaction data?
A. Well, the one that I'm referencing at the moment, there
is a change being made to the --
Q. To the number of the transactions, yes?
A. There's a couple of elements. I think the counter code
is changed to make it appear that it had been entered on
a different counter than it actually had been done on,
and there was a change to some sort of -- it might have
been a serial number or a transaction number that was
on.
Q. But not a change to any basic transaction detail, price,
product or anything of that sort?
A. No. The PEAK was suggesting which elements of the
messages should be changed before the upload takes
place. The PEAK didn't say change a value, so it would
have to be a mistake. The real mistake with that would
be not getting all of the transactions, or accidentally
duplicating a transaction.
Q. Wouldn't you just be taking a copy of what's in the
messagestore?
A. Yes, but you are then opening up the messagestore in
a text editor, and whenever you are moving data between
an environment where it has some structural integrity
into a text editor then there's always the danger that
things --
Q. So you are suggesting that -- the intention wouldn't be
to change anything, but you're saying there might be
a mistaken change of something, yes?
A. I think the necessity is you do have to change something
because I do not think you can import the data into
another counter in the same way, because it has
a counter ID in there and I think that has to be
changed.
Q. You are right, my question was too loose. There
wouldn't be an intention to change transaction data but
you are saying there might be a mistake made which
results in a change to transaction data that was held on
a machine?
A. Yes, or an omission of a message.
Q. Would you accept that -- first of all, how many
occasions of that are you aware of? Have you just seen
one PEAK or is it more?
A. There's not many PEAKs -- there are quite a few PEAKs
that talk about the Riposte import commands that suggest
throughout --
Q. That is different though. That is transaction
insertions, yes? We are not talking about rebuilding
data now.
A. But that's the process that you rebuild the data.
Q. I see.
A. You get them from another counter or a failed disk, you
edit them and then you import them, you insert them into
a working counter.
Q. But the particular process that we are talking about
now, involving taking data off the machine and injecting
those transactions, how many occasions of that are you
aware of in the documents you have reviewed and --
A. I haven't searched specifically for that. I almost
tripped over that document. But I have only seen
a handful.
Q. Would it be possible for you to bring a list of the
handful to court tomorrow?
A. Yes.
Q. Thank you. I think, and you may already have accepted
this but I ought to put it just in case you haven't, you
would accept, wouldn't you, bearing in mind the evidence
you have heard and the documents you have seen relating
to Fujitsu's own processes, that that process would
involve careful review by two pairs of eyes, yes?
A. Yes, I believe so.
Q. So in the real world again would you accept that the
chances of that happening, going wrong and causing
an erroneous entry in branch accounts that were not
intended, would be very, very low. Would you accept
that?
A. It would be low, yes.
Q. Thank you. Now are there any other forms of data
rebuilding that you believe ought to be discussed in
this context or shall I move on to a different form
of --
A. Yes, I'm happy for you to move on.
MR JUSTICE FRASER: Do you mean off the list, back to the
list?
MR DE GARR ROBINSON: Yes. Shall I move to a different form
of remote access, or is there another aspect to
rebuilding transaction data in the branch that Mr Coyne
is aware of and would wish to discuss?
MR JUSTICE FRASER: Mr Green, either stand up and make
an objection or don't, but sotto voce exchanges across
court are really not very helpful.
MR GREEN: I apologise, my Lord.
MR JUSTICE FRASER: They also put witnesses in a difficult
position.
MR GREEN: When Mr Roll was cross-examined he was taken to
38.1 and 38.2 and not 38 -- the same thing is about to
happen again.
MR JUSTICE FRASER: But if Mr de Garr Robinson doesn't want
to put a particular point then he is not putting
a particular point. But if you are laying a flag down
that he ought to --
MR DE GARR ROBINSON: I think that's very helpful. I'm glad
my learned friend has talked about that.
MR JUSTICE FRASER: Can I just make it clear to both of you
generally, although it is really aimed at you, Mr Green,
I have a very light touch on how counsel conducts
cross-examination in a time-limited trial.
MR GREEN: I'm grateful, my Lord.
MR JUSTICE FRASER: That sort of exchange is not helpful.
MR GREEN: I'm most grateful, my Lord.
MR DE GARR ROBINSON: If you look at the witness statement,
the next page {E2/12/13}, then there's what Mr Parker
describes as the rare case:
38.3:
"... where Fujitsu was not able to access a portion
of the transaction data from the desk then we would
replicate transactions as far as we were able to and
would notify Post Office and Subpostmaster of this and
any information we had on the extent and potential
timing of any missing transactions."
So in relation to that then, that possibility
obviously would involve a debate, wouldn't it, including
the subpostmaster and Post Office, yes?
A. Yes, it would.
Q. And because the transaction -- the data couldn't be
obtained, presumably because the machine doesn't work,
then everyone would know that the data couldn't be
obtained and they would be addressing what should happen
as a result of that data being missing, yes?
A. Although this does remind me of another one that I will
find for you overnight, and that's where I believe the
subpostmaster was told that they couldn't recover the
transactions, so the subpostmaster put the transactions
back in manually from his or her own paper copy, and
then Fujitsu did manage to recover the transactions and
inserted them, which caused a doubling of the
transactions.
Q. Right. We are talking about -- so you found one
occasion when something like that happened?
A. That I was reminded of from that, yes.
Q. Whenever these things happen they are recorded in PEAKs,
yes?
A. This was recorded in a PEAK, yes.
Q. But by virtue of the way we all know Fujitsu works, if
it happens it would be recorded in a PEAK?
A. It should be recorded in a PEAK, yes.
Q. It would be very surprising if it wasn't recorded
somewhere in a PEAK, yes? And you are aware of one
occasion where that happened, yes?
A. Yes.
Q. If you could let me have a copy of the PEAK tomorrow
that would be very helpful, thank you.
A. Just with regard to the PEAK. PEAKs are raised at third
line Fujitsu. So when you say Fujitsu would do whatever
they would do, it would be effectively the SSC. So if
the call gets to the SSC level then that's when the PEAK
would be created. There might be other elements of
Fujitsu that they do other things.
Q. But of course if a call didn't get to the SSC, then
there wouldn't be any question of any remote access,
would there?
A. No, not necessarily. If a call didn't get to SSC then
Post Office has decided that it would deal with it using
some of its own methods, so issuing a TC --
Q. I'm sorry, I'm really confused, Mr Coyne. When you say
deal with "it", what are we talking about?
A. Deal with the situation --
Q. The purpose of the discussion we are having today is to
discuss remote access. Remote access, correct me if I'm
wrong, is what can be done by the SSC when seized of
a problem, yes?
A. Yes, but you then took me --
Q. If I could just -- yes, is that right?
A. Yes.
Q. So in the context that we are discussing it now, we are
always talking about something in relation to which the
SSC is already involved, yes?
A. Yes.
Q. And so when you suggest now that there are situations
when the SSC isn't involved, I don't know what those
situations are, but what I want to suggest to you, and
to save some time, is that whatever those situations
involve, they don't involve remote access of the sort
with which I'm concerned today. Would you accept that?
A. I would accept that. The answer that I gave is because
you asked me about whether something would be recorded
in a PEAK or not.
Q. Yes.
A. And I give you the answer that if the subpostmaster
called Post Office to tell them that there was then
a doubling of their transactions as a result of this,
that that in itself would not raise a PEAK until that
call went all the way through to Fujitsu SSC and the
PEAK would be raised then.
Q. Yes. Are you suggesting -- so you are suggesting
a situation where a branch has already got through to
the SSC and the SSC has done some rebuilding of data.
The branch then has a problem -- the branch knows there
has been some rebuilding of data, I think we discussed
that, yes? And the branch then sees there has been
a doubling of transaction and phones up the helpline.
Now in that hypothetical call the postmaster would say
"This has just happened. The Fujitsu -- the third tier
support has been helping me with my data but I have this
problem because now I have a duplicate transaction".
You are not suggesting, are you, that that call wouldn't
get passed back to SSC to be looked at by the people who
did the original whatever the transaction insertion was?
A. I'm not suggesting any of that. I'm answering your
question as precisely as possible. You asked me whether
it would be recorded in a PEAK and I explained the
process to you when the PEAK gets raised.
Q. So in the scenario you have just hypothesised, the
overwhelming likelihood is that it would get through
back to the SSC and it would be picked up in a PEAK,
probably the same PEAK, yes?
A. That is the process that should be followed, but
initially the call would go into the Post Office and the
Post Office would investigate it and they would make
a decision whether that call should go through to
Fujitsu or not. And then it would be recorded in
a PEAK.
Q. Thank you. Now, no other forms of data rebuilding that
are in your mind that you wish to talk about? Why don't
I give you an opportunity to look through
paragraphs 10.2 -- perhaps pages 4 through to 6. Is
there any other aspect of rebuilding of data that we
haven't covered, in your expert view? {D1/5/4} {D1/5/6}
(Pause)
A. No, I'm happy with what's covered in that statement.
Q. Thank you. If we could then go back to page 4 and look
at the next item {D1/5/4}. The second form of remote
access. You say:
"In Legacy Horizon, injection of an additional
message in the branch messagestore."
A. Yes.
Q. The standard way of doing it, I believe you will accept,
is doing it via the correspondence server which, when
a transaction is inserted, would leave an indication
that the counter on which the transaction was done was
greater than the number of 32, correct?
A. Well, it depends really at what time of day the message
is inserted. Messages are not always at the
correspondence server --
Q. I'm trying to explore that there is a standard way of
doing it and then an alternate way of doing it that
doesn't involve doing it through the messagestore, yes?
A. I don't believe it is a case of one is standard and one
is nonstandard. It depends on whether you are making
a modification after messages have been sent to the
correspondence server or whether they haven't yet gone
from the branch to the correspondence server.
Q. Let's look at what Mr Parker says about that. It is at
{E2/12/9}. Perhaps I could ask you to read what he says
in paragraphs 27 through to 28, please.
(Pause)
A. Yes, I can see that.
Q. You have read it?
A. Yes.
Q. And you will see at the end of paragraph 27, he says:
" ... it would have been injected into the
correspondence server ([this was] the default option
which was followed in the vast majority of cases)."
Are you in a position to disagree with that?
A. No.
Q. Thank you. Then he discusses a PEAK, PC0175821. You
are familiar with that PEAK, it is referred to in your
reports.
A. Yes.
Q. Is his treatment of that PEAK fair?
A. We probably should just check on that PEAK. Could I see
that PEAK?
Q. Yes. It is at {F/485/1}.
There you are, Mr Coyne.
A. Can we go on to the next page please {F/485/2}. Next
page, please {F/485/3}. And again, please {F/485/4}.
Sorry go back one, please {F/485/3}.
Yes, okay, so it looks as if -- yes, messages
prepared for insertion. Yes, I think what Mr Parker
said --
Q. So it is a fair account of what happened. And it is
true, isn't it, that the messages were inserted with the
additional property comment PC0175821 to allow them to
be identified in the audit trail. Do you accept that?
A. Yes.
Q. And do you accept Mr Parker's evidence that that was the
practice that was adopted when using transaction
insertions which wouldn't be automatically identifiable
because of the high number of the counter that would be
recorded?
A. Sorry, with the high number of?
Q. Transactions that are entered into at the correspondence
server are easily identifiable because the counter
number that you see in the transaction log and the
events log is a counter number that doesn't exist in the
branch, yes? It is a counter number that is greater
than 32?
A. I believe that that's the process, but I have seen
occurrences where the counter number of not 32 has been
used. Less than 32.
Q. When it is done by the correspondence server the
evidence that has been given is that that records
a counter number that is greater than 32. Are you
saying you have seen instances where the correspondence
server has been used but a lower counter number has been
recorded?
A. Yes.
Q. Why isn't that in any of your reports?
A. It was a recent -- it was since this report has been --
Q. It is quite difficult -- this time I'm not blaming you,
Mr Coyne, but it is very difficult to conduct
a cross-examination in circumstances where the goalposts
seem to be moving all the time.
Let me just move on. Perhaps I will say this --
A. Should I include that in the homework?
Q. Yes. I'm sorry to burden everyone with this. I'm
anxious that I'm not giving you an opportunity to put in
a supplemental report by the provision -- I don't mean
this as a criticism, you are doing this in answer to my
questions, but in effect we are in a situation where new
evidence is being given which it would have been helpful
to have seen in a supplemental report. But yes, please:
MR JUSTICE FRASER: All you are being asked to do is
actually identify the document that you are talking
about.
MR DE GARR ROBINSON: Yes.
A. Yes, my Lord.
MR DE GARR ROBINSON: I would really not have an exegesis.
MR JUSTICE FRASER: Yes. There's nothing other than the
documents.
MR DE GARR ROBINSON: My Lord, yes.
Would you accept that the thrust of Mr Parker's
evidence that Fujitsu's practice, when there was a risk
of the nature of the transaction insertion not being
readily identifiable, that steps would be taken to make
it identifiable such as by adding comments of the sort
he refers to there?
A. Yes, that's certainly the process.
Q. You would accept, wouldn't you, that Fujitsu was not in
the business of making changes that weren't readily
identifiable at least when a close look is taken, yes?
A. I agree that wouldn't be their desire.
Q. From all the PEAKs and so on that you have seen, you
would accept that their approach is consistent with
wanting to make the changes that they make readily
identifiable, yes?
A. There are a number of anomalies but, yes, I accept that
they --
Q. I'm not going to ask you about anomalies, Mr Coyne.
You will see that in paragraph 29 of his witness
statement Mr Parker had asked one of his colleagues to
search the incident management system, that's the PEAK
database, for incidents that required injecting data
into the counter --
MR JUSTICE FRASER: Just hold on one second. We were on 39,
you want paragraph 29?
MR DE GARR ROBINSON: It is paragraph 29 at page {E2/12/10}.
I'm sorry.
MR JUSTICE FRASER: Yes, thank you. We have caught up.
That's all right.
MR DE GARR ROBINSON: You will see what he says in
paragraph 29.
A. Yes.
Q. I presume you reviewed the documents that he refers to
in his footnote?
A. Yes, I did.
Q. And do you accept that he correctly characterises the
impact of those documents or the effect of those
documents?
A. What does he say is the impact of the documents?
Q. Paragraph 29.
A. Yes.
Q. There was fixing a Riposte index at the counter. 29.2,
removing a historic message that was influencing the
balancing process. And so on. And he says in
paragraph 30:
"In total, data was injected into the counter on 14
occasions. However transactions were injected in only
one of these cases, namely the case described in
paragraph 29.5 above."
And that's PC0175821.
A. This witness statement was very helpful because this is
the first time that we see how the message injection was
actually done and the terms were suggested what we could
search for. I haven't been and looked at these
documents and benchmarked them specifically whether they
were against those particular characteristics that were
pointed out in 29.1 and 29.6.
Q. So would I be right in thinking you are not in
a position to dissent from what Mr Parker says in
paragraph 29?
A. That is the position, yes. I believe that this report
was only the day before my report was due. This witness
statement.
Q. You seem to have considered quite a lot of things since
you produced your second report. Did you not consider
what Mr Parker says here and the documents he refers to?
A. No, I hadn't got the information to be able to ask the
question that you put to me then, whether these specific
PEAKs address those six things.
Q. And you are not in a position to suggest that the search
that he describes in paragraph 29 yielded 14 occasions
on which only one involved an insertion of transaction
data? You are not in a position to challenge that?
A. I'm not in a position to challenge that.
Q. Would you accept that the search that is described in
paragraph 29, that is a sensible set of terms to use
when searching for the kind of transaction insertion we
are talking about?
A. Well, I didn't know that at the time, that these were
the sort of words that you should use to search for
message insertion. That is something that both myself
and Dr Worden had been looking for for a little while so
it was good to have that confirmed. And after looking
at the messages, that Riposte, and I think there is
Riposte import as well, that's one that I found as well,
so it was helpful. The search terms do look to be --
Q. Do you accept, though, that those search terms are
likely to capture the sort of transactions that we are
talking about now?
A. They do. They don't include the word "Riposte import"
or "message import", which is the one that I have since
used, so whether that brings back additional messages,
I'm not sure.
Q. So you have done your own searches now, have you?
A. After seeing these words here I have looked at those
documents and found the command Riposte import in some
of those documents, so I have gone back to search for
that across the whole database.
Q. And are you in a position to suggest that the basic
thrust of what he says in paragraphs 29 and 30, that the
number of occasions where this happened and involved
injecting transaction data was very low?
A. The number will be relatively low, yes.
Q. It's always dangerous to ask but we are talking about
a handful of occasions, no more than that, yes, during
the life of Legacy Horizon?
A. It is probably best for me to actually run the searches
and give you the actual numbers.
Q. I really don't want you to be doing more research,
Mr Coyne. I understood you to be telling me that you
had already done it, and I'm simply asking you whether
in the course of doing that search you found more than
a handful. Perhaps we will leave it at that question.
Perhaps you could answer it now?
A. It will be in the tens but I don't know how many tens.
Q. You mean in the low tens? Between ten and twenty?
A. In all honesty, I would prefer to run the answers and
give you a proper answer. If I had had sight of this
document in enough time before preparing my report, then
I would have provided a proper response to it.
MR DE GARR ROBINSON: Yes. My Lord, is this a convenient
moment?
MR JUSTICE FRASER: I think it is.
MR DE GARR ROBINSON: This is going slower than
I anticipated. Your Lordship may appreciate.
MR JUSTICE FRASER: I had noticed.
MR DE GARR ROBINSON: It is a voyage of discovery in certain
respects.
MR JUSTICE FRASER: I can tell.
MR DE GARR ROBINSON: I wonder whether your Lordship would
be willing to sit at 1.50 pm as you were yesterday?
MR JUSTICE FRASER: I would rather sit past 4.25/4.30/4.35,
for the reason I explained yesterday, and we can start
at 10.15 in the morning.
MR DE GARR ROBINSON: I'm much obliged to your Lordship.
MR JUSTICE FRASER: What we are going to do, I'm just going
to have a stock take with you very briefly now, because
junior counsel doubtless between them will be doing this
but I just want to check. How many items have you got
on your list?
A. Three.
MR JUSTICE FRASER: Right. The first one is looking for the
evidential references or the evidential reference to
a number?
A. Yes.
MR JUSTICE FRASER: Just pause there.
I did say to you at the morning break that I would
come back to you at 1 o'clock about whether you wanted
that done at the short adjournment or whether you would
be happy to have it in the morning?
MR DE GARR ROBINSON: Bearing in mind my timing concerns,
I suspect it is very unlikely that I will be
cross-examining Mr Coyne on any of the material that he
produces.
MR JUSTICE FRASER: Understood.
MR DE GARR ROBINSON: So it doesn't have to be done by --
MR JUSTICE FRASER: Understood.
All right, Mr Green, can you just make arrangements
insofar as necessary that a bundle of the witness
statements in hard copy is available for Mr Coyne by
4.30 pm so he can take it with him to look through and
find that reference.
MR GREEN: My Lord, I do not think it is in the witness
statements.
MR JUSTICE FRASER: Well, the expression used was "in the
evidence", so that was where I assumed it would be.
MR GREEN: Yes. I think that's where the misunderstanding
arose.
MR JUSTICE FRASER: Right. I'm not going to say anything
else and we will come back at 2 o'clock.
(1.02 pm)
(The short adjournment)
(2.00 pm)
MR DE GARR ROBINSON: Mr Coyne, good afternoon.
A. Good afternoon.
Q. We were talking about transaction insertions in
Legacy Horizon and I recall that you mentioned earlier
on the $1,000 PEAK, and that was a transaction injection
so this may be a good moment to talk about it.
Could I ask you to go to {F/432/1}, please. This
is -- do you recall this PEAK?
A. Yes, I think I do.
Q. It has been cited quite a lot by Mr Green. In your
second report, we don't need to go to it but it is at
paragraph 3.232, I think, or it may be 3.234, my note
isn't clear, but it doesn't matter. {D2/4.1/75}
You make two essential points about this PEAK.
First of all you say there was no settlement value for
the transaction and this was corrected by a transaction
insertion, and then you say but a $1,000 loss was
identified afterwards. Would I be right in thinking
that your implication was that that loss may have been
caused by the transaction insertion, yes?
A. Yes.
Q. Secondly, you point out that in the PEAK the view is
expressed that it is best that the postmaster be not
informed about the problem because it was resolved
before roll-over, do you remember that?
A. Yes, I think this is the one. Yes.
Q. So here is an apparent exception to the general practice
of telling postmasters what's going on. Are you aware
of any other exceptions?
A. No, I don't believe so.
Q. Let's look at the PEAK. It is dated 10th December,
2007. The call logger on the top right-hand side is
MSU-Indt Mgt. What does that signify? What does MSU
signify?
A. Management support unit?
Q. Yes. And so this is therefore a report that comes in
not from the postmaster but from the MSU, because some
kind of exception has been thrown up, some kind of
report has been generated?
A. Yes.
Q. In the automatic monitoring processes that are operated
by MSU?
A. Yes.
Q. If we go down to the first box, it is dated
7th December. About four lines down:
"Summary: branch [there is the FAD code] TPSC257."
You will recall what TPSC257 is, won't you? It is
POLFS incomplete summaries report, yes?
A. Yes.
Q. And do you remember, it is a report which shows -- which
indicates that the information going into Post Office
through the TPS is incomplete?
A. Yes.
Q. Something has either been missed or wasn't there in the
first place.
A. Yes.
Q. And it is picked up automatically, yes?
A. Yes.
Q. And it is fair to say that that's one of the
countermeasures which exists within the Horizon system.
Where there are problems of this sort, this is
an automatic process which flags it and ensures that it
is investigated by the SSC?
A. Yes.
Q. Then, if we go down to 7 December at 10.35, it says:
"OCR 17493 has been raised. Sending to EDSC for
progression. While returning call, please include file
name in which outstanding data was sent to POLFS."
It is not difficult to ascertain what's happening
there. The OCR, what would that be designed to do?
A. I think it is operational change request. So it is
a request to change some data. Or correction request.
Q. It's a request to change some data in the TPS, isn't it?
There has been a problem with the TPS system and what
they are requesting is permission to make some change to
that data to deal with the problem, yes?
A. Yes.
Q. Then you see at 10.41, that's two boxes down, the
request is approved?
A. Yes.
Q. That's not the end of the problems. If we were stopping
there, that would just be a use I imagine of the TIP
repair tool, yes? That wouldn't be something that would
be particularly interesting, do you agree?
A. Possibly, yes.
Q. But we don't stop there. If we go to page {F/432/2}, at
the top it is said by Andy Keil:
"This is due to a single SC line written for $1,000
(£484) with no settlement in the middle of two RISP
transactions."
So translating that into English, it appears to be
saying this is due to a single customer service line.
A. Served customer, I think.
Q. Written for $1,000 with no settlement in the middle of
two remittance transactions?
A. Remittance in, yes.
Q. "On call ... the harvester exception was corrected and
now the transaction for the day don't zero, hence this
issue with the incomplete summaries report."
A. Yes. Something, so has gone wrong with Horizon at this
point because the top line there about the single SC
line being written with no settlement is an indication
that something has failed and this report has picked up
that --
Q. Yes, it is not simply that there has been a harvesting
problem in transmitting the data into the TPS, actually
there is a problem with the data in the BRDB itself in
the final accounts, in that the accounts seem to contain
a transaction which has no settlement line --
A. Yes.
Q. -- which can't be right.
A. Yes.
Q. The writer says:
"Am currently retrieving the messagestore for this
branch, we will then be inserting a new message on the
counter to remove the effects of this."
It refers to:
"OCP 17510 has been raised."
Do you see that?
A. Yes.
Q. Now, on roll-over what is being described here would
produce a receipts and payments mismatch, wouldn't it?
A. Yes.
Q. I think you have already agreed, but if you haven't
I would invite you to agree now, that on roll-over those
mismatches are always picked up automatically and
referred to the SSC for investigation, correct?
A. I'm not sure whether that is an automated process or not
or requires somebody to --
Q. Well, it arises that there are various TPSC reports, for
example 268A, 257, that are triggered when there is
a receipts and payments mismatch on roll-over, are you
familiar with that?
A. I was not sure of that process. I believed on roll-over
if there was a receipts and payments mismatch then
there's various options that then can be used. I didn't
know whether there was an automated process.
Q. What I'm suggesting to you, Mr Coyne, and perhaps you
will agree this and perhaps not, if a receipts and
payment mismatch appears on the roll-over of a branch it
will get referred to the SSC, it doesn't have to be
referred by a postmaster?
A. Right.
Q. The SSC will be seized of the matter --
A. Yes.
Q. -- even if the postmaster himself doesn't phone in, yes?
A. Okay.
Q. Do you accept that?
A. I accept that that's a reasonable process. I --
Q. You are not sure?
A. I'm not entirely sure that it is automated as suggested,
but that's perhaps --
Q. But the MSC produces reports to the SSC which explain
that these exceptions have arisen on various TPSC
reports. You must have seen --
A. The MSC?
Q. Sorry, the MSU, I do apologise. The MSU sends in,
rather as happens here actually, a report saying
an exception has arisen in this report and then the SSC
looks into it. You have seen a large number of PEAKs of
that sort, haven't you?
A. Yes. So there is an automated report produced and then
somebody would look at that report.
Q. Thank you. So what happens is the system picks it up
and a PEAK is created and then people start looking into
what should happen, what has happened, yes?
A. Nearly right. I think the PEAK would be created after
somebody looks at it and decides a PEAK is required.
Q. The PEAK is created when the MSU sends a report in to
the SSC, correct?
A. I'm not sure that is correct. I think the report is
sent, somebody looks at the report, and then creates
a PEAK if a PEAK is required.
Q. I see. So what you are suggesting is a report is sent
in and a human being looks at the report and then
creates the PEAK?
A. Yes.
Q. That is the process which is followed?
A. Yes.
Q. There is no process by which a report is sent in and
then people sit on their hands and do nothing about it?
A. I would hope not, no.
Q. If we go down to 12 o'clock on 12th December:
"As was suggested by Anne Chambers yesterday, there
is a new exception on the TPSC257 (Incomplete Summaries
Report) for 11/12/2007. The report shows further
entries for this branch ..."
Then down the page to 12.33 on 12th December -- I'm
so sorry, down to right at the bottom of the page,
17.19, I do apologise, and this is by Andy Keil again:
"Worth noting that the branch didn't have any issues
with the mismatched transactions because this was fixed
before they did the roll. The branch is not aware of
this and it is best that the branch is not advised."
This is something that has been drawn attention to
and I think you kindly said that this is the only
example of something like this happening of which you
are aware, yes?
A. Yes, I can't think of anywhere else where it said
expressly: don't contact the customer.
Q. Then if we go to page {F/432/3} at 16.13:
"As detailed above the two POLS incomplete summaries
issues have been resolved.
"The counter problem which caused the first issue
has been corrected by inserting a message into the
messagestore, for equal but opposite values/quantities,
as agreed with POL (OCP ...)"
So we see there that the OCP was approved, yes?
A. Yes.
Q. "As a result of this corrective action, the net effect
on POLFS is zero, and POLFS figures are in line with the
branch."
Do you see that?
A. Yes.
Q. Which reflects the general principle that Fujitsu were
concerned to ensure that there aren't discrepancies
between the TPS system and the branch's own accounting
position, yes?
A. Yes.
Q. "POLMIS ..."
That's Post Office Management Information System.
"... received both the original message and the
corrective message.
"Once the problem was corrected, there should have
been no impact on the branch."
Do you see that?
A. Yes.
Q. And you understand why, don't you?
A. Yes.
Q. It is correct, isn't it, that where you have
a transaction that involves no settlement value then
once that is cancelled out the branch will properly
balance?
A. Yes.
Q. "However it has been noted that the stock unit BDC had a
loss of $1000, which was generated after the correction
was made. We have already notified Gary Blackburn at
POL ... This appears to be a genuine loss at the branch,
not a consequence of the problem or correction."
Would I be right in thinking that you question that
and that you are suggesting that in fact the $1,000 loss
was caused by the OCP, the transaction insertion?
A. Yes.
Q. And why do you say that?
A. Because I believe that the transaction insertion was
done incorrectly. I think the message that was inserted
did not reflect the right amount.
Q. Is this -- we will come to it in a minute, but there is
a document referring to 2,080. Is that the document you
are referring to?
A. I think that is the document.
Q. You think that that document indicates that a change of
2,080 was made rather than the $1,000 or £484 change
that should have been made?
A. Yes.
Q. And that that would have caused the $1,000 loss, yes?
A. Yes.
Q. Now would you accept, stopping there, that the process
that we have just seen of Fujitsu changing -- inserting
a settlement line -- inserting a transaction to cancel
out this unbalanced transaction, that is a relatively
rare occurrence?
A. Yes.
Q. It is not something which we see very much at all in the
PEAKs which we have all seen, correct?
A. That is correct.
Q. We see at the bottom of page 3, this is by Anne Chambers
who you have heard of before, she says:
"A single SC line was written for $1,000 (£484) with
no settlement, in the middle of two RISP transactions."
The line was missing some AdditionalData so it
wasn't harvested properly, but the main problem was the
lack of settlement. POL authorised us to insert an
equal but opposite message, to prevent a discrepancy (in
theory anyway) and to avoid problems on POLFS. Please
note that this is exceptional and must not be seen as
a convenient avoidance in place of a fix."
You would accept, would you, that what she says
there, which is that this is exceptional, don't expect
us always to be dealing with points of this sort, that's
fairly reflected in the PEAKs that you have seen, isn't
it? This is something that happens quite rarely?
A. Yes.
Q. You will see Ms Chambers says here that what was
inserted as a result of the OCP was an equal but
opposite message?
A. Yes.
Q. But you are suggesting that she is wrong about that and
in fact a larger amount was inserted, is that right?
A. Yes. Could I just ask, can we just go through this and
have a look at whether we see the message insert command
in this PEAK, please.
Q. I don't believe we do, but we do have the OCP and the
OCR.
A. If that is the case, that highlights one of the
difficulties that you have with identifying from a PEAK
when a message has been inserted.
Q. That's why we have OCPs and OCRs, isn't it, so you can
see -- the purpose of those documents is to record
precisely that information, would you agree?
A. The purpose of those documents is to request permission
from Post Office to do something, but that in itself may
not contain any search terms that would indicate that
a message has been inserted. There is no --
Q. In any event, it is the case, isn't it, that there are
OCPs and OCRs in this case which cause you to conclude
that there was an error made in the level of the
transaction insertion into the branch accounts, correct?
A. Yes.
Q. So let's look at that. First of all, let's look at the
OCP. That is at {F/432.2/1}. You will see what it says
here:
"A single SC message ... was written in error on
26th November ... selling 1,000 US dollars, with no
corresponding settlement line. To remove the effects of
this message at both the branch and on POLFS, we will
insert a new message to negate the effects of the
original message."
"Justification: If the change is not made in the
counter messagestore (before the stock unit is balanced
on Wednesday), the branch will have an unexpected gain
of £484 (or thereabouts - depends on exchange rate), and
a receipts and payments mismatch. This gain would have
to be resolved at the branch. There would also be an
inconsistency between the branch and POLFS to be
resolved. By correcting the problem locally, the branch
may not be aware of the problem, and there will be no
inconsistency between the branch and POLFS."
Do you see that?
A. Yes.
Q. And all those things are true, yes? If the right figure
is entered in, the branch will balance. There will be
no danger to the branch's balancing. The concern is if
the wrong figure is inserted, correct?
A. Yes.
Q. Then:
"Extra detail: The original message ..."
And this is the information I think you were
referring to in your answer previously?
A. Yes.
Q. "The original message had ProductNo:5129, Qty:1,
SaleValue:484, PQty:1000. The new message will have ..."
Then there are some similar words but basically the
opposite of what's in there.
"... with other attributes as before."
Do you see that?
A. Yes.
Q. So you can see precisely what was going to be done with
this transaction insertion, yes?
A. Yes. This isn't the message, this is just describing
here what information they are going to put in the
message when they create it.
Q. And what you are suggesting is that although that was
the intention, in fact the people that did it got it
wrong, yes?
A. Yes.
Q. And you do that on the basis of another document that we
will go to in a minute.
Then it says:
"The message will include a comment to show it has
been inserted to resolve this problem (this will not be
visible to the branch)."
So you will see this is consistent with Mr Parker's
evidence that when insertions are made, comments are
included so that it can be seen. In this case not by
the postmaster but it can be seen, so if anyone looks at
what has happened in the branch they will see there has
been an insertion by the SSC, do you see that?
A. If anyone back at Fujitsu looks at it they will know.
The postmaster wouldn't know though.
Q. Then it says:
"This change will first be applied to a copy of the
messagestore within the SSC environment, and the stock
unit then rolled over to make sure there are no
unexpected consequences. Neither the new nor the old
message will be included in the data sent to POLF."
This indicates that they were effectively going to
test the change before they actually made it, yes?
A. Yes.
Q. So it would be quite surprising, wouldn't it, if they
did a dummy run on a copy of the messagestore held by
the SSC, got a positive result, but then when they did
it in live action they actually produced the wrong
result. That would be quite a surprising mistake to
make, I think you would agree?
A. I'm not sure that the test they conducted would have the
ability to see that level of sophistication because
I think what they are going to test here is that the
message can be successfully inserted. They only have
a copy of the messagestore that they have taken and that
will be probably at maximum 24 hours of transactions.
Q. Are you sure that's fair, Mr Coyne, because they do say:
"... and the stock unit then rolled over to make
sure there are no unexpected consequences."
So what they are going to do is make the insertion
in the dummy account, they are then going to roll the
dummy account over and see what the consequences are.
Wouldn't it be fair to assume that -- aren't they
precisely saying that in those circumstances they are
going to type in what they intend to do, make sure that
it has the intended effect and allows a roll-over with
a proper balance, and then once they have satisfied
themselves that that is right they will then do it in
live use, yes?
A. It could be, yes.
Q. Are you suggesting they mean something else?
A. There isn't a great deal of detail there. I don't know
what the set up of the SSC environment is. We don't
know how much of the messagestore is in there.
Q. So you are saying that because you are seeking to resist
the impression that you perceive I'm trying to give,
that the notion that the transaction insertion involved
an error is quite surprising, and you don't want to
accept that and the way you respond to that is by saying
you don't know precisely what they did, is that right?
A. I do not think either of us now know precisely what that
test did.
Q. I would like to suggest to you, Mr Coyne, that it is
painfully obvious what the test did. They applied the
change they were going to apply on a test rig which had
an identical copy of the messagestore of the branch,
they rolled it forward, and then they saw what the
consequences were. What else could that sentence be
talking about?
A. And would that test environment then have a look at the
impact on what the branch accounts would be?
Q. Yes.
A. Or are they just looking at whether a roll-over can take
place or not?
Q. Very well. Let's go on to the OCR, because it is the
OCR which is the basis of your suggestion that in fact
they inserted the wrong figure, yes?
A. Mm.
Q. It is at page {F/434.1/1}:
"Extra detail: This OCR is being raised so that EDSC
..."
Do you know what EDSC is?
A. I don't. It may appear in the glossary.
Q. You see it in a lot of PEAKs, don't you?
"... is authorised to amend the transaction details
for [that branch] and insert these into
_pol_fs_summaries_incomp table on the host."
You see what's being described here. The consent
that is being sought here is for an insertion into
a POLFS table in the TPS?
A. Yes.
Q. "Comments:
"Andy Keil ... wrote at 12/12/2007 ... Updated POLFS
feed for branch 183227 product 5129 mode SC with
SaleValue=1014.73 and PQty=2080."
Do you see that?
A. Mm.
Q. And what you are suggesting is that that insertion would
have caused an imbalance, would have caused -- could
have caused a loss in the branch?
A. Yes.
Q. If we go down to "Other details", you see the last entry
on "Other details"? It says:
"Change type: TRT."
What does that mean?
A. TIP repair tool?
Q. Yes. So what they are talking about here, what this
change here is, is a change being made by using the TIP
repair tool into the TPS, correct?
A. Right, so this doesn't relate to the creation of the
message then.
Q. It doesn't relate to the branch accounts, Mr Coyne, does
it? This is an OCR which involves an exercise -- well,
the use of the TIP repair tool to change data that is in
the TPS system, yes?
A. Yes, but the PEAK refers to the insertion of a message
into the messagestore.
Q. Yes, the PEAK and indeed the OCP we have just looked at.
It is the OCP which deals with the transaction insertion
into the messagestore. The OCR isn't concerned with the
transaction insertion into the messagestore, is it? The
OCR is concerned with a change made via the TIP repair
tool of the data that's held in the TPS, correct?
A. Right, yes.
Q. So it follows as night follows day that whatever change
was made as a result of this tool, it didn't affect any
change to the branch accounts, it didn't constitute
an insertion into the messagestore for the branch, do
you agree?
A. So if I follow correctly, what you are putting to me
here is that what we see within this OCR is a secondary
form of correction via the TIP repair tool?
Q. Yes.
A. After the message that was inserted into the
messagestore?
Q. It doesn't matter whether it was after or before. What
matters is that this document and the transaction, the
work that it covers, is nothing to do with the
messagestore of the branch and I would like you to
accept that.
A. Whilst it might be nothing to do with it, it is making
an alteration to the branch accounts.
Q. Mr Coyne, I have spent something like 45 minutes this
morning seeking very carefully to get you to agree, and
to be fair to you, you did agree, that when a change is
made using the TIP repair tool it doesn't change the
branch accounts, it doesn't affect the messagestore of
any branch, it only affects the data within the TPS
system.
A. Yes.
Q. If you want to make a change to the accounts you have to
insert a transaction?
A. Yes.
Q. Using the facility in Legacy Horizon?
A. Yes.
Q. That facility is approved pursuant to the OCP we saw
before we looked at this document. However, there were
two problems. There was a problem with the
messagestore.
A. Yes.
Q. And there was also a separate problem with the POLFS
data, the data that was in the TPS system.
A. Yes.
Q. This OCR is concerned with getting authorisation to make
the change to what's in the --
A. TPS system, and the PEAK was to do with making
the change.
Q. The PEAK covered both problems. You will recall that
there are two changes referred to. There are OCRs
referred to in the PEAK and there is an OCP referred to
in the PEAK.
A. Yes.
Q. And I have taken you to the OCP first of all and now we
are looking at an OCR.
A. Right. Could I please have a look at the time within
the PEAK that the observation about the $1,000 was made?
Q. Yes, by all means.
MR JUSTICE FRASER: That's exactly what I'm doing actually.
MR DE GARR ROBINSON: It is F/432 --
MR JUSTICE FRASER: There is page 1 and 2, I think. The
PEAK is {F/432/1}.
MR DE GARR ROBINSON: The reference to the $1,000 loss
though is on page {F/432/3} about four boxes down,
14 December at 16.13.
MR JUSTICE FRASER: I think the OCR that you have just been
putting, Mr de Garr Robinson, is one of the ones
mentioned on page 2, is that right?
MR DE GARR ROBINSON: Yes, my Lord, I believe so.
MR JUSTICE FRASER: Because actually it says on
12th December 2007 at 16.39:
"User: Andy Kiel. Details of how POLFS feed was
corrected 12.12.2007."
Is that the one?
MR DE GARR ROBINSON: My Lord, yes .
MR JUSTICE FRASER: Which appears on the line before. It is
also on page 432/2 in the entry immediately before.
MR DE GARR ROBINSON: Absolutely. Sorry?
MR JUSTICE FRASER: For some reason on my screen the two
entries are highlighted in blue, I thought it was
a hyperlink. It is the antepenultimate entry on page 2
and the one before it, isn't it? Aren't they the exact
documents you have been using?
MR DE GARR ROBINSON: At 12th December 2007 at 15.06 there
is a reference to the OCR.
MR JUSTICE FRASER: Yes, and then underneath --
MR DE GARR ROBINSON: Details of how the feed was corrected.
MR JUSTICE FRASER: Yes, and that's what you have been
putting.
MR DE GARR ROBINSON: Yes.
Does that help you, Mr Coyne?
A. Because we know that the TPS side of the fix to this
problem happened on 12th December at 15.07. The
observation about the £1,000 was on 14th December.
MR DE GARR ROBINSON: Yes, when the roll-over was done or
after the roll over was done.
A. So the bit that's missing is we need to see the message,
so that is the OCP. Can we see the time --
Q. Mr Coyne, when I asked you about this before you said
there was a reason why you thought there was an error
made in the transaction insertion and that's because
there was a document which showed the figure of 2,080
being inserted yes?
A. Yes.
Q. And that figure is on page {F/434.1/1}, it is in the
OCR.
A. Yes.
Q. I can tell you on instructions what that figure means.
If we go under "Comments":
"Updated POLFS feed for branch [blah, blah, blah]
with SaleValue=1014.73 and PQty=2080."
You will recall that the transaction itself was
removed from POLFS. The $1,000 transaction, the £484,
it was removed from POLFS. You remember seeing that in
the PEAK?
A. Yes.
Q. But what's left is the aggregate of all the remaining
dollar conversion transactions which have been
undertaken in the relevant period.
A. Yes.
Q. So on instructions I can tell you that the sale value of
1,014.73 and the quantity of 2,080, those figures relate
to what is the aggregate of the figures that are left in
the system after you remove the one-sided transaction
that the parties were concerned about.
A. Right.
Q. It would be difficult to understand them otherwise,
because 1,014.73 bears no relation to £484 or to $1,000,
does it?
A. No, I agree with that.
Q. I appreciate that I'm telling you this on instructions
because I have to say nobody knew that this suggestion
was going to be made until it was put to Mr Godeseth
when he was being cross-examined, but in actual fact it
follows as a matter of logic, doesn't it, that whatever
the explanation of these figures -- sale value 1,014 and
quantity 2,080 -- whatever the nature of those figures,
those figures actually have no impact on the
messagestore on the branch accounts that could have
caused a $1,000 loss?
A. Well, the $1,000 loss would be because of a difference
between the two, and you are making change to the branch
within the messagestore and you are making a change to
the backing systems to the TPS.
Q. Let's go back to page {F/432/3}, please. This is
Anne Chambers explaining what has happened. She has all
the documents and she has sight of what's going on in
the messagestore, yes?
A. Yes.
Q. She says in the third paragraph -- the second paragraph:
"The counter problem which caused the first issue
has been corrected by inserting a message into the
messagestore, for equal but opposite values/quantities,
as agreed with POL ..."
A. Yes.
Q. She has seen the transaction that is done and it is her
view that what was inserted was an equal but opposite
value, yes?
A. Yes.
Q. And she then goes on:
"As a result of this corrective action, the net
effect on POLFS is zero, and POLFS figures are in line
with the branch. POLMIS received both the original
message and the corrective message."
Do you see that?
A. Yes.
Q. "Once the problem was corrected, there should have been
no impact on the branch. However it has been noted that
the stock unit BDC had a loss of $1000, which was
generated after the correction was made."
A. So between the 12th at midday but before 14th when this
is recorded.
Q. The OCP was made -- the OCP was raised on 10th December,
you see that at the top of page {F/432/2}, and the
correction was made to the messagestore on 11th
December. That's on page 2, six boxes down. Do you see
that?
A. One of the documents said 12th December at 15.07, either
the OCP or the OCR.
Q. 12th December, 15.07?
A. Yes, at the time of 15.07, I believe.
MR JUSTICE FRASER: That is the OCR which is on --
MR DE GARR ROBINSON: Yes, that is the TPS. What happens is
there is an OCP that is done, that's actioned on
11 December, so the messagestore is changed on
11 December.
A. Yes.
Q. Then there is an OCR which changes the TPS on
12th December.
A. Yes.
Q. And then on 14 December Anne Chambers is reviewing
everything that has happened and she said the
transaction insertion goes through fine, but after it's
gone through a $1,000 loss has appeared on a particular
stock unit.
Now you latched onto the OCR with a view to
suggesting that because the figure of 2,080 was used
rather than 1,000, and because the figure of 1,014 was
used rather than 484, you latched onto that and thought,
aha, there must have been an error in this insertion and
that error must have been responsible for the loss.
What I'm suggesting to you, Mr Coyne, is that's not
right, because this is a change that was not made to the
messagestore, it was made to the TPS system, do you
agree?
A. There were two changes, one to the messagestore and one
to the TPS system.
MR JUSTICE FRASER: I think that's agreed.
MR DE GARR ROBINSON: I will move on.
MR JUSTICE FRASER: Just before you do, I appreciate you
have been putting these points on instruction, as you
put it. I would really quite like to understand the
chronology in detail, I'm pretty sure I do, but I'm just
going to tell you what my understanding is because it is
taken from the PEAK.
MR DE GARR ROBINSON: My Lord, yes.
MR JUSTICE FRASER: And it is simply so that you can tell me
if I haven't got it right.
The PEAK is raised, and I find page 2 of the PEAK
most useful because it actually says when the OCPs are
created and when the OCRs are created.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: The OCR is created on 10th December 2007
at 17.25, is that right?
MR DE GARR ROBINSON: The OCP, my Lord, yes.
MR JUSTICE FRASER: I beg your pardon.
MR DE GARR ROBINSON: That is the transaction insertion into
the messagestore.
MR JUSTICE FRASER: On 10th December 2007 at 17.25.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: It actually says "OCR" on here.
MR DE GARR ROBINSON: Your Lordship is absolutely right.
MR JUSTICE FRASER: I was about to come onto the OCP which
I think is 40-odd seconds later.
MR DE GARR ROBINSON: Your Lordship is absolutely right.
I'm sorry to have spoken too soon.
MR JUSTICE FRASER: No, it is just important for me to
understand it. So there is an OCR at 17.25 which is
referenced here on 10th December, and there is also
an OCP literally about a minute later. Am I reading it
correctly?
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: Then we come further down the document
and there is a reference on 12th December, both at 15.06
to the actual OCR and then at 16.39 to details of how it
was corrected, and those two entries should effectively
be read together, is that correct?
MR DE GARR ROBINSON: My Lord, I believe so. So the OCR was
given effect to on the 12th.
MR JUSTICE FRASER: So as at the 12th, whatever is being
done to the system has in fact been done, is that right?
MR DE GARR ROBINSON: My Lord, I believe so, yes.
MR JUSTICE FRASER: Then the review where Ms Chambers says
what she does on 14 December, 16.13, is after those
changes, is that right?
MR DE GARR ROBINSON: My Lord, yes.
MR JUSTICE FRASER: That's all I need to do. I just wanted
to confirm that because I obviously can't go to
a witness statement to look at it. Back to you.
MR DE GARR ROBINSON: So I've spent 40 minutes on this one
document and I rather think I need to get on.
If we could go back to the joint statement, please.
That's {D1/5/4}.
A. Sorry, what page number, please?
Q. I'm sorry?
A. What page number?
Q. Page 4.
A. Yes, I have that.
Q. It is the third bullet point in paragraph 10.2.
A. Yes.
Q. There is the third form of remote access which is
deletion of messagestore data?
A. Yes.
Q. We know that wholesale deletion of the messagestore was
possible as part and parcel of the automatic back up
process that we talked about and of course that involves
no discretionary manual deletions. Could I ask you,
what examples have you found of discretionary manual
deletions of transactions in the messagestore?
Individual transactions?
A. No, it is typically wholesale.
Q. Thank you. So you are not aware of there being any
example of a discretionary deletion of a particular line
of transaction data in Legacy Horizon, are you?
A. No. The typical way of dealing with it will be
an insertion of a balancing --
Q. Thank you. Nor are you aware, are you -- I have gone
through your reports quite carefully and if I have
missed it, it is my fault -- of any edits in
Legacy Horizon of any lines of transaction data? No
example of that has been identified, has it?
A. Yes, messages are transferred to Fujitsu to enable them
to edit the message and then reinsert the message.
Q. So transaction insertions possible?
A. Yes.
Q. But if you have got a piece of data, a line of
transaction data or whatever in the messagestore, you
are not aware of any example of remote access whereby
someone gets into the messagestore and edits that line
of data, are you?
A. Well, they are editing a line of data, they are bringing
the messagestore back to Fujitsu, editing the line of
data and then sending it back.
Q. Mr Coyne, I understand that the practical effect of
inserting a transaction could be -- is a change in the
entirety of the contents of the messagestore, so in
a loose sense you could say the messagestore as a whole
has been edited. But I would like to be really clear.
I'm just asking you the narrow question: have you seen
any example of someone at Fujitsu, or indeed anyone
else, accessing a branch's messagestore remotely, so
from their office, and fiddling about with a transaction
that's currently in the branch accounts, in the
messagestore, so as to change its value or change any
other of its basic transaction details?
A. I have not seen evidence of changing of value but I have
seen evidence of editing other data around it.
Q. I'm being really clear now because I tried to establish
some clear ground rules when we were talking about what
constituted transaction data and what constituted
accounting data. Are you aware of any example of some
transaction data having been changed, having been edited
remotely by someone at Fujitsu?
A. Yes, if we --
Q. In Legacy Horizon?
A. If we go to {F/337.1/1}.
Q. Would you like to talk me through this PEAK?
A. Is this 337.1?
MR JUSTICE FRASER: No, this is 337/1. You want
{F/337.1/1}?
A. Yes, my Lord.
MR JUSTICE FRASER: Can we go to that, please.
MR DE GARR ROBINSON: My Lord, I do not believe there is
a 337.1.
MR JUSTICE FRASER: That is the answer to that then. There
is no 337.1.
MR DE GARR ROBINSON: Let's move on then --
A. Can I give you the PEAK number? I have got the PEAK
number. It is PC0142763.
Q. That's {F/377.1/1}. This is not a PEAK I have seen. Is
it referred to in any of your reports?
A. I'm not sure. I would have to do a search on that and
see. There are many that are referred to in my report.
Q. I'm rather wondering, Mr Coyne, whether you came armed
with this document having found it after you provided
both your reports but without warning anyone in advance
that that's what you were doing. It does seem curious
that you have committed this particular PEAK to memory?
A. No. My Lord set some homework for me and I started it
at lunchtime and that is the first one that I have done
and it relates to this particular --
MR JUSTICE FRASER: I do not think I set you that homework.
A. Sorry.
MR DE GARR ROBINSON: This isn't referred to in any of your
reports, so it is a voyage of discovery for me. Would
you like to talk me through this PEAK? It is rather
difficult, but if you could do it without taking too
much time I would be grateful.
A. Yes, okay. If we go straight to the end, because that
shows the editing process {F/377.1/6}, this is where we
have got the message being edited. So it looks like it
was -- I think the ID is the counter ID and it has been
changed from 1 to 11 and from 2 to 12. And then I think
the fourth line down you see the transaction.
MR DE GARR ROBINSON: Mr Coyne, I have never seen this
document before but I venture to suggest that this is
an example of a transaction insertion, yes?
A. They are inserting a transaction, yes.
Q. So this is an example of a case where the SSC,
I presume, has a transaction that it wishes to insert
into the messagestore which everyone agrees that SSC has
the power to do?
A. Yes.
Q. My question was different. My question was are you
aware of a single example of someone at the SSC sitting
at a screen in his office in a secure area where the SSC
operated, gaining access to someone's messagestore, some
branch's messagestore, looking at a transaction that is
in the messagestore, and then by using his machine
editing the transaction that's on the messagestore?
That was my question.
A. No, because that isn't the process that's done. The
process is that the messagestore is transferred back to
SSC, the edit is made, and then it is transferred back.
Q. So the answer to my question, which was very carefully
formulated, is that you are not aware of any occasion
when a transaction has been edited by a form of remote
access. You are only aware of occasions when
transactions of one sort or another have been inserted,
is that right?
A. This has been inserted but it is a message that was
already in the messagestore that has been brought back,
edited, and pushed back again.
Q. Mr Coyne, I'm just trying to be really clear about
concepts. The Horizon Issues talk about insertions or
injections of transaction data, it talks about deletion
of transaction data, and it talks about editing of
transaction data. You very kindly admitted that you are
not aware of any case where there has been a remote
deletion of transaction data.
A. Right.
Q. And I was suggesting to you that nor were you aware of
any case where there has been an example of remote
editing of transaction data. That means that the only
form of remote access that's left in Legacy Horizon is
transaction insertions.
Now, what you have just brought me to, and we have
taken 10 minutes on it, is an example of a transaction
insertion, yes?
A. It is an insertion but it is insertion of a transaction
that was already there. So effectively it is
a modification. It is not a new transaction.
Q. Let's move on. I'm getting anxious -- I'm already very
anxious about time.
That deals with the facilities for remote access in
Legacy Horizon, doesn't it?
A. Yes.
Q. So let's look at Horizon Online now and let's do it as
quickly as we can. If we go back to page {D1/5/4}, and
I hope I can take this quickly. We have dealt with the
three Legacy Horizon entries at the top of
paragraph 10.2, yes?
A. Yes.
Q. Then there is a Horizon Online form of remote access:
"Injection of a transaction --"
Let's leave that one out.
"In Horizon Online, using the balancing transaction
tool ... as defined below."
A. Yes.
Q. Now, the balancing -- we call it the balancing
transaction tool, just inserts transactions, yes?
A. Yes.
Q. Into particular tables in the BRDB where transaction
data is held, yes?
A. Yes.
Q. I hope I can take this relatively quickly. It is agreed
that that tool writes to a particular audit log, yes?
If we go to page {D1/5/14} of this very document.
A. It writes to a journal file, yes.
Q. If we look at paragraph 12.3, it is agreed that that
tool writes to this journal, yes?
A. Yes.
Q. The audit log for that journal has been disclosed,
correct?
A. I think the journal itself has been disclosed.
Q. That's what I meant. The journal is the audit log,
correct?
A. I don't know if anyone audited it or not, but it is
a record of use. That is the journal of use.
Q. Yes, its purpose is to stand as an audit log so you can
go and see what uses have been made of the relevant
tools?
A. That's its purpose, yes.
Q. Would I be right in thinking you agree there's only been
one use of the transaction correction tool to insert
transactions into the BRDB, is that correct?
A. Using that tool, yes.
Q. If we can now move on. I would like to ask you
a question about your second report, it is at
{D2/4.1/72}. It is paragraph 3.223. Here you refer to
a PEAK which is at {F/594/1}, which I hope we won't need
to go to in light of what you have already said. You
say: it:
"... suggests that the modifications by Fujitsu
support staff to the Horizon Branch Database (BRDB) is
not unusual."
I think we can agree that that PEAK, which is at
{F/594/1}, I'm not suggesting we go to it, is a PEAK
which discusses whether immediately after the one use of
the transaction correction tool that we are aware of --
perhaps let me put it to you this way. Does it ring
a bell that the one use that we are aware of was given
effect to, happened on 11 March 2010, very early on in
the life of Horizon Online, does that ring a bell?
A. Yes.
Q. And this PEAK is opened the day after it on 12th March,
yes?
A. Yes.
Q. And it is opened by the person that made the balancing
transaction in the first PEAK?
A. Right, yes.
Q. Do you remember that?
A. Yes.
Q. And what happens is that person says "We have now used
the tool and I can think of some ways in which we can
improve it"?
A. Yes.
Q. Then there is a debate during the course of the PEAK as
to how it could be improved. No sense of urgency, the
PEAK goes on for quite a long time, do you remember
that?
A. Yes.
Q. Eventually it is agreed that certain changes will be
made, and ultimately after a long time those changes are
made to the transaction correction tool. Do you recall
that?
A. Yes. They talk about typically trying to create
templates, so that when people use it in the future they
fill in a template to make the tool easier to use and to
ensure there are less risk problems when using it.
Q. You say in paragraph 3.223 that this PEAK:
"... suggests that the modifications by Fujitsu
support staff to the Horizon Branch Database ... is not
unusual."
What you are suggesting is having regard to the
PEAK, you think the transaction correction tool to
insert transactions is not unusual, it happens more
often than once. That's what you are inferring from the
PEAK, correct?
A. No, from what the PEAK says, the process of doing it
does not seem unusual or unfamiliar to people.
Q. Yes. I have a series of questions to ask you about that
by reference to the PEAK.
A. Yes.
Q. But I can shortcircuit all of those questions by
indicating that in actual fact you accept that the
transaction correction tool was only used once to insert
transactions into branch accounts, yes?
A. Yes. There are other tools that are written to the same
journal, but only one of those journal entries show this
particular tool being used to edit the BRDB with regard
to transactions.
Q. Just to be clear, here you are suggesting the use of the
tool is not unusual, you're suggesting there's a
significant number of uses of the tool, and I'm really
not suggesting any criticism of you, Mr Coyne, at all,
but just to be clear for his Lordship's note, actually
you accept it only happened once, correct?
A. I accept that this tool was only used once to insert a
balancing transaction.
MR JUSTICE FRASER: That's three times I have now got that.
MR DE GARR ROBINSON: I'm grateful, my Lord.
MR JUSTICE FRASER: I generally have them first time but
three times -- I can understand why you put it again,
but I'm just saying I do have it.
MR DE GARR ROBINSON: Thank you for the clarity, my Lord.
Then if we can go back to {D1/5/4}. These are your
forms of remote access. At the bottom you say:
"In both Legacy and Online, usage of the transaction
repair tool to fix transaction data within the Horizon
..."
We don't need to spend any time on that because you
agreed that that tool isn't used for the purposes of
injecting or deleting or editing any data in any branch
accounts, correct?
A. There is another use of that tool or the journal and
that is to remove the recovery flag.
Q. I'm sorry, Mr Coyne, I think it may have been my fault.
When you say transaction repair tool, I should probably
have said TIP repair tool. You are referring to the TIP
repair tool here, aren't you?
A. No, the balancing transaction tool. Its use -- it
appears its use was widened. This was covered in the
evidence of I think it was Mr Godeseth.
Q. Mr Coyne, I don't understand. You have dealt with the
balancing transaction tool in the previous bullet point.
A. Yes.
Q. My understanding was that in the next bullet point,
where you refer to the transaction repair tool, the only
tool that I'm aware of that has "repair" in its name was
the TIP repair tool. Were you not referring to the TIP
repair tool?
A. Sorry, I was.
Q. So we can agree, can't we, that in accordance with the
definition of remote access that I suggested at the
beginning of this conversation, then that bullet point
can come out, can't it, yes?
A. Following your specification of what remote access is,
yes.
Q. Thank you. So what we are left with is the bullet point
above the balancing transaction tool, which is SQL
injection line editor?
A. Yes.
Q. That's by privileged users, yes?
A. Yes.
Q. And would it include use of the APPSUP role?
A. Yes.
Q. Here's some common ground. Privileged users have strong
powers to add, delete and edit data, don't they?
A. Yes.
Q. You and Dr Worden agree, I think, that the abilities of
that kind are necessary for the administration of any
database of this sort?
A. Yes.
Q. I imagine you are not aware of any big system which
doesn't have such facilities, yes?
A. There needs to be a super user access somewhere, yes.
Q. So the mere existence of this right of access does not
indicate that the system is insecure, does it?
A. It would indicate that it's insecure if that access is
given to too many people, yes.
Q. It doesn't necessarily follow from the existence of
these powers that it was in fact used to alter
transaction data, necessarily?
A. That doesn't -- yes.
Q. So the question is whether and to what extent it
actually happens and in what circumstances, yes?
A. Yes.
Q. Could you explain how an SQL line editor would be used
in a case of this sort? I mean the BRDB has over 250
tables, doesn't it? Is it quite a complex process to
change those tables in a way that doesn't cause problems
within the system as a whole?
A. No, I mean the good thing about the SQL command is that
you can use it to look up information that's in there
and get it to return a value and then change that value.
It is quite easy when you use the SQL tool.
Q. Could I ask you to look, please, in your second report,
{D2/4.1/83}, at paragraphs 3.266 to 3.276. I'm not
going to read them out loud, I'm going to deal with them
as quickly as is humanly possible.
These paragraphs deal with the use of -- is it the
use of SQL to delete certain kinds of data?
A. Yes.
Q. You refer to a number of PEAKs. Let me see if I can
take this in stages without having to go to any of them.
It is inevitable in any network system that you could
get a network outage, yes?
A. Yes.
Q. So systems have countermeasures in place against such
eventualities?
A. Yes.
Q. And one of the systems that Horizon has in place is the
concept of the recoverable transaction?
A. Yes.
Q. And what happens when you are typing a transaction into
the counter is that recovery data is constantly
transmitted to the BRDB and stored in various tables in
case it becomes necessary to use it?
A. Yes.
Q. But all that data becomes irrelevant once the
transaction is entered into the -- once the basket is
committed to the BRDB --
A. Yes.
Q. -- and the transaction enters the account.
Now, there are a number of states that recovery data
has, aren't there? There's active, which is the
recovery data is active and will be returned to the
counter should failure occur?
A. Yes.
Q. And there is completed, that's where the recovery
process has been completed and the transaction is
recovered?
A. Yes.
Q. There is a third state, which is outstanding, which is
that the recovery process was unable to recover the
transaction for some reason and to allow the counter to
proceed, the recovery data is marked as outstanding and
needs to be manually resolved by support staff?
A. Correct.
Q. Now, the PEAKs that you are talking about here relate to
transactions involving recovery data which is stuck in
the outstanding state, don't they?
A. Yes.
Q. So the recovery process was unable to recover the
transaction and the recovery data is therefore marked as
outstanding and needs to be manually resolved by support
staff?
A. Yes.
Q. The effect of that is that it can prevent the branch
from rolling over and sometimes it can prevent counters
from working, I think?
A. Yes. What should happen is that you reboot the counter.
The counter sees the recovery flag, looks at the state
of the data, and hopefully can clear itself up, if you
will, deciding which transactions to proceed with and
which to back out of. The problem that occurs sometimes
is that that process fails and it can't automatically
recover.
Q. Yes.
A. And you end up switching the branch off and back on
again and it just keeps trying to --
Q. One of the examples in one of these PEAKs is where the
clerk was logged on to the counter and then never logged
off and then the counter was taken away. You remember
that? Does that ring a bell?
A. I do, but I don't quite know how it relates to --
Q. Anyway, in these PEAKs there is discussion of deletion
of the session to allow the block that's constituted by
the recovery marker from preventing the branch from
operating and rolling over, correct?
A. Yes.
Q. In those PEAKs, SQL script is used in order to delete
the session so that it will have that effect, do you
agree?
A. Yes.
Q. So in that process, no data that's actually in the
branch accounts is affected at all. In each of these
PEAKs no change is made to any of the transaction data
or other accounting data that's actually already in the
branch accounts, correct?
A. That is where the problem is, that you are deleting
session data without going through the understanding of
what position that session data is in.
Q. And in each of those PEAKs a determination is made that
the relevant transaction hasn't actually been
undertaken, it doesn't need to be inserted, doesn't need
to be included into the branch accounts, and the
subpostmaster is involved and onside and aware of what's
going on, do you agree with that?
A. There isn't a PEAK for every time when that happens.
Q. Why would there not be a PEAK when it happens? Surely
there would always be a PEAK when it happens?
A. The main KEL that covers this scenario is an
Anne Chambers' KEL and that KEL reference is 3/400
PEAKs.
Q. Is it ACHA 959T that you have in mind?
A. It might well be.
Q. I believe it may refer to about 2,000 PEAKs, yes?
A. I do not think it is that high of a number.
Q. Maybe 1,000.
A. I think there is a table in the report that goes to
that, it talks about how many PEAKs are referenced in
that KEL --
Q. I think I was probably trying to be a bit clever,
actually, Mr Coyne, and I think I should apologise for
being incautious in that endeavour.
A. I do not think there is a PEAK for every time that
happens.
Q. Well, Ms Chambers' KEL, ACHA 959T, is a list of
instructions about what to do in various different
scenarios, yes?
A. Yes.
Q. It doesn't concern any bugs in Horizon, it is just if
this happens then this is how it should work, if this
happens then this, and if there is a problem the SSC
should do this. That is the nature of the --
A. Yes, it does result from a bug, error or defect in
Horizon because the process should be that it recovers
itself.
Q. I'm going to suggest to you, but I'm not going to go to
it, that if you go through that particular KEL you will
find that it simply addresses various recovery issues
that can arise in practice?
A. Yes.
Q. And suggests how the SSC and other stakeholders in the
process should deal with them when they do arise?
A. Yes, it does.
Q. And my suggestion to you is that it doesn't actually
consider any bugs in Horizon, it doesn't suggest
workarounds for bugs in Horizon, that's not the purpose
of that KEL?
A. The whole process is a workaround because the system
isn't designed to do that, so something has failed. So
it talks about the various workarounds to get the
counter up and running again.
Q. Mr Coyne, we will have to agree to differ on that. My
suggestion to you is that this is just an explanatory
KEL which explains how the system works. It is actually
describing how the system should work, it is not
describing what should happen when the system fails, but
I can see that we are not going to agree about that.
A. It is inconsistent that users should be expected to go
through to Fujitsu third line report to deal with
a problem that almost should happen. That can't be
right.
Q. I think we agreed -- I must go more quickly -- the other
day that the recovery process, because it involves third
parties, there is inevitably going to be a situation
where a manual inquiry needs to be made as to what
happens on the ground, and then steps need to be taken
to reconcile what happens on the ground with what's
recorded in the accounts, and that is inherent in the
process of having recoverable transactions. Would you
agree with that?
A. Yes, but that isn't a manual process. Typically it is
an automated process which happens thousands of times
per month across the estate. A few of those, but it is
in the thousands, the recovery will not be automatic and
it requires a call to Fujitsu, it goes to third line
support, the Anne Chambers KEL is considered and that
process is used, a SQL command is used to delete some of
the session data, and then the counter is back up and
running.
Q. Mr Coyne, I will just leave it here. I was asking you
about the PEAKs that are referred to in these paragraphs
under the heading "Deletion of Data" in your report.
A. Yes.
Q. And my suggestion to you is that in none of those PEAKs
was there actually any change made to transaction data
contained in any branch accounts, would you agree with
that?
A. There was no change but there was deletion.
Q. Not of data in branch accounts. There was deletion of
data relating to recovery markers which were concerned
with sessions, would you agree with that?
A. Yes, but contained within there is session data that's
in an unconfirmed state that needs dealing with.
Q. Yes. And in each of those cases it was dealt with in
consultation with the subpostmaster to ensure that the
accounts were right, to ensure that nothing was done
which produced an inappropriate result for the accounts.
Would you agree with that?
A. I agree actually with the process, yes.
MR JUSTICE FRASER: I don't want you to go to it now but can
you just give me that reference for that KEL that you
memorised, in due course.
MR DE GARR ROBINSON: It is ACHA --
MR JUSTICE FRASER: No, I mean the trial bundle reference.
Don't spend time now, just mean give it to me whenever.
And we are going to have to have a short break. Is now
a good time?
MR DE GARR ROBINSON: We are, my Lord, and that is a good
time.
MR JUSTICE FRASER: We will come back in at 3.20 pm.
Were you about to give me a reference?
MR GREEN: {F/1700/1}.
MR JUSTICE FRASER: Thank you very much.
3.20 pm.
(3.13 pm)
(A short break)
(3.20 pm)
MR DE GARR ROBINSON: Mr Coyne, one last PEAK to go to in
relation to SQL and that's referred to in your report.
Why don't we have a quick look at your report at
paragraph 3.275. So it is {D2/4.1/84}.
A. Yes.
Q. This is a reference to a PEAK, PC0197592:
"... details an error whereby rollover cannot be
completed due to system error. Gareth Jenkins of
Fujitsu states ..."
Then you quote what he writes there and you say:
"This is indicative that Fujitsu, by creating SQL
scripts, could delete relevant records in order to
negate previous operations."
We both agree that privileged user access is a
powerful thing.
A. Yes.
Q. Then you continue:
"Whilst this is not necessarily deletion of
transaction data, it is the modification to operations
that are all intrinsic to transaction accounting."
I wonder whether we can take this quickly. You
accept, don't you, that the operation that was
undertaken here didn't involve deletion of transaction
data, would you agree with that?
A. It deleted an opening balance.
Q. Yes, but it didn't delete transaction data, it deleted
an opening balance, yes?
A. I do not understand why an opening balance isn't part of
transaction data.
Q. Data relating to a transaction that's done by the
branch. It didn't delete that. I rather thought you
were going to accept that because you said:
"Whilst this is not necessarily deletion of
transaction data ..."
Are you suggesting that deleting an opening balance
is deletion of transaction data?
A. Well, it changes the postmaster's accounting position.
But, no, I can accept that it isn't one of the
transactions of selling things or paying your money or
whatever, but it would have an effect on --
Q. This is the one other example of SQL scripts that you
have seen, privileged user access that you have seen
affecting branch accounts?
A. Yes.
Q. So there are the three PEAKs that we discussed before
the court broke?
A. Yes.
Q. And then there's this one other PEAK?
A. Yes.
Q. And those are the examples of which you are aware,
correct?
A. I believe there are some more, these are examples.
There are other examples of SQL statements --
Q. Which are similar to these ones? Presumably you put
them in your report because you felt these were the ones
that the court should be told about?
A. Yes, there are others but --
Q. These are representative of those others?
A. Yes.
Q. Thank you. So let's go very quickly to {F/611/1},
please. This is dated 15th April 2010, so it is during
the -- it was a branch which had migrated to
Horizon Online during the pilot project, do you
remember?
A. Yes.
Q. So there were a relatively small number of branches that
were sort of being tested, and this was one of them and
it had a problem.
If we could go to the first box on page 1 about
halfway down, it says underneath the double line:
"When rolling over and doing branch trading
statements site gets message unable to connect to the
data centre."
Do you see that?
A. Yes.
Q. So the branch had a problem that it couldn't roll over,
yes?
A. Mm.
Q. If we go over to page {F/611/2}, about two-thirds of the
way down the page, 13th April at 13.33:
"The branch did not complete their office rollover
properly on 17 March so the office is still in TP 11
although all the stock units are in TP 12. There was no
system failure - it looks as if they pressed cancel
instead of confirm at the end of the rollover process."
So at that early stage it appears it might be some
human intervention that's responsible.
Then if one goes to the bottom of page 2 but more
particularly on the top of page {F/611/3}, this is
Anne Chambers again. She says at the top of page 3:
"I've retrieved logs of an attempt to roll the
office from TP 11 to 12, at 9:51 UTC 12th April.
"All looks ok - trading statement is printed, and
they press confirm."
If we go down a couple of paragraphs.
A. So it says something has timed out at the counter,
hasn't it.
Q. "I suspect this may be because there is already a single
entry in BRDB_SU_OPENING_BALANCE for DEF TP 12 BP 1,
inserted during migration. The entry is for cash, zero
value."
A. Right.
Q. So just stopping there, what has happened is that this
branch has newly migrated as part of the pilot scheme,
and as part of the migration there has been a glitch or
something which has resulted in the entry of a false
figure for the next balancing period. There shouldn't
be anything there at all, should there?
A. That is right.
Q. But instead, as part of the process of pilot scheme
migration, a figure of zero has crept in which is
plainly wrong, yes?
A. Yes.
Q. And the fact that there is a zero for the forthcoming
balancing period means that the branch can't roll into
that balancing period, correct?
A. Yes.
Q. So if we go down the page to 14th April at 13.00 hours,
this is Gareth Jenkins:
"I've had a look at this PEAK and agree that we need
an OCP to tidy up BRDB to unstick this branch. Note
that what I'm proposing here is slightly different from
what Anne has suggested above."
He suggests the text that you quoted in your report.
So first of all he wants to update the stock units,
setting the trading period to 11. Yes?
A. Yes.
Q. So the stock units, which are already in trading period
12, the branch isn't but the stock units are, he wants
to re-set the stock units so they are back in trading
period 11, yes?
A. Yes.
Q. And that is an updating operation yes?
A. Yes.
Q. Secondly, he wants to delete the opening figures for the
next period -- the opening balance for the next trading
period --
A. Yes.
Q. -- to get rid of that rogue zero?
A. Yes.
Q. And by that means the stock units and the branch will be
in the same trading period, first of all?
A. Yes.
Q. And secondly, because the zero is no longer in the way,
they will both be able to roll over, correct?
A. Yes.
Q. And as a result of rolling over, what will the opening
position of the branch be?
A. Whatever it should be.
Q. Exactly. It will be an aggregation of all the
transactions that have been undertaken in the branch
since the previous -- the beginning of that trading
period.
A. Yes.
Q. So what's being done here is something that doesn't
change any transaction data, it doesn't insert any new
transactions that have a value and so on in the branch.
It is simply a form of SQL script which allows the
automatic process of aggregation of transactions to be
undertaken in a way that isn't blocked by the glitch
that's introduced as part of the migration process
during the pilot roll out, yes?
A. Yes.
Q. And I think you may agree that there definitely wasn't
a change to transaction data, and there definitely
wasn't any change which in any way modified the
accounting position of the branch, by which I mean --
which raised the risk of the branch having the wrong
accounting position as compared with what it should
have?
A. Yes, I agree.
Q. Thank you. And would I be right in thinking that you
have only seen a relatively few number of PEAKs of this
sort?
A. There are a few PEAKs that do contain SQL statements.
There are other PEAKs that refer to the need to use SQL
but don't contain statements such as this.
Q. Let's move on to -- just to sum up, you have reviewed
thousands of KELs, Mr Coyne, thousands of PEAKs,
thousands of OCPs, OCRs and MSCs, and you have done lots
of intelligent searches through all of those documents,
yes?
A. Mm.
Q. Would I be right in thinking that in that process you
have been looking for instances of remote access
affecting branch accounts of the sort we have been
discussing?
A. Yes.
Q. Given this covers a 20-year period, and given the number
of branch accounts that have been created during that
period and the number of transactions which have been
done during that period, you have found relatively few,
haven't you?
A. From the documents that we have reviewed using the
search terms, yes.
Q. And the evidence that you have seen from the documents
you found shows that Fujitsu is generally reluctant to
make changes that would have an effect on branch
accounts, yes?
A. Yes.
Q. And it is generally -- in fact it is always careful to
ensure it is only done when necessary and that it is
done with great care?
A. I have to say generally, I don't know if it's always --
Q. Generally. Have you seen --
A. Always is just an absolute.
Q. Oh, simply because you don't want to say it never
happened. But the documents you have seen, you have not
seen any documents which clearly show a careless
attitude whether to the transaction being done, to the
particular form of remote access being undertaken, or to
getting the appropriate consent to undertake the
transaction?
A. No.
Q. Thank you. Now you make some criticisms of the
permission control regime applied at Fujitsu and for
that purpose you rely on two documents, don't you, you
rely on the Ernst & Young management letter of 2011 and
you also rely on the minutes of the Risk & Compliance
Committee meeting that we discussed a couple of days
ago.
A. Yes.
Q. The impression that's given in your reports is that
Fujitsu has poor controls which could expose the system
to a risk of poor actions being done, yes?
A. Yes.
Q. But in all the documents you have searched through you
have actually not found any significant evidence of poor
actions being done, have you?
A. No, but in a lot of documents you will see, for example,
the term user APPSUP, but then you don't see what
follows so we don't see what the actions are.
Q. Let's look at the Ernst & Young management letter. We
have already talked about the Risk & Compliance
Committee minutes. Could we go to {F/869/1}, please.
You refer to this a lot in both reports, particularly in
your second report. Could I ask you first of all to go
to page {F/869/3}. This is the executive summary.
Perhaps I could ask you to read it. (Pause)
A. Yes.
Q. I'm going to deal with each of those four key
recommendations but I'm going to start with the change
management process because it is fair to say, isn't it,
that that's the section you focus on mostly in your
reports, wouldn't you say so?
A. Change management and permissions.
Q. If we could go to your second report, it is
{D2/4.1/178}, please. At paragraph 5.196 you say:
"There is evidence of deficiencies in change
management as recorded in the letter."
So you regard this letter as being evidence of
deficiencies, do you?
A. Evidence that the auditors identified deficiencies, yes.
Q. But wouldn't you agree that the word "deficiency" or
"deficiencies" is only mentioned twice in the letter, is
that right?
A. I think with regard to weaknesses.
Q. If we look at page {F/869/11}. This is "Payroll Control
Environment", and do you know, I haven't marked the word
"deficiencies", but somewhere on this page there is the
word "deficiencies". But that's to do with payroll,
correct?
A. Yes, I do not think it will be this section that I've
referred to.
Q. Let's go back to page {F/869/3}, to the second paragraph
of the executive summary.
A. Yes.
Q. They say, the last sentence:
"The recommendations we have made in this report
should be seen as refinements rather than fundamental
control deficiencies in comparison."
Do you see that?
A. Right, yes.
Q. Now, would it not be thought that Ernst & Young are
actually refraining from saying that these are
deficiencies?
A. Yes, but this is the executive summary. I think if you
go to the detailed findings.
Q. I see. It is correct, isn't it, that this letter
doesn't identify any harmful events having taken place
as a result of the change management process, is that
right?
A. Yes.
Q. If we could move on to your second report, I'm sorry to
leap around like this, it is {D2/4.1/195}. At
paragraph 5.264 you say:
"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. I have listed below the four key
recommendations ..."
On what basis do you say in this report that it
appears that Post Office chose not to take the
opportunity to improve the countermeasures as
recommended?
A. This document is -- there was a risk identified to the
Post Office and Post Office chose not to mitigate it in
the way suggested by Ernst & Young.
Q. Hold on, you are talking about recommendations. You are
talking about -- you appear to be talking about the key
recommendations and forgive me, Mr Coyne, but you appear
to be saying that Post Office chose not to act in
response to those recommendations. Is that not the
impression that's given by this paragraph?
A. Yes. I think this is covered -- is it 5.197 in my
report which relates to the document you just took me
to, it was the table at section 2.
Q. 5.197?
A. Yes. {D2/4.1/178} You took me to the executive summary
before, but the section that I comment on in the report
is the table at section 2, points 12 to 15.
Q. So you are saying the table at section 2 supports your
inference or your understanding that Post Office chose
not to take action in response to the recommendations by
Ernst & Young. Is that what you are saying?
A. So section 2 deals with points that were made in the
previous year. Section 4 is specific points made for
the current year.
Q. Yes. So section 2 won't justify an assertion that the
key recommendations that are in section 4, Post Office
chose not to react to them because it is to do with past
events, yes?
A. Can we go to that document?
Q. Yes, it is at {F/869/1}. What I'm proposing to do,
Mr Coyne, but if you would like me to do something else
do tell me, is to take you to the particular provisions
of the letter in which recommendations are made and to
see whether it is fair to say that Post Office chose to
take no action to improve the position in response.
Would that be a fair thing to do?
A. Yes.
Q. Let's do that. If we could go first of all to page
{F/869/23}, this is "Improve governance of outsourcing
application management", and it goes on for two pages,
you see?
A. Yes.
Q. If you look at the far right column entitled "Management
Comment", you will see it starts with the words:
"Work on improving ..."
A. Yes.
Q. "... has already commenced ..."
Do you see that?
A. Yes.
Q. That's work that Post Office and Fujitsu are carrying
out and it runs over to the second page. It is quite
long, isn't it?
A. Yes.
Q. So this doesn't suggest that Post Office chose not to
take action in relation to this particular
recommendation, correct?
A. Yes.
Q. So let's try another one. If we go to page {F/869/25},
this is "Segregation of duties within the manage change
process". If you look at the far right-hand column this
time, "Management Comment", it says -- the very first
line reads:
"A Fujitsu project has been established to review
all user management areas and is being led by the CISO
of the RMG account.
"Fujitsu will provide and agree with POL a clear
segregation of duties guideline for Senior management
and line managers ..."
It goes on for several pages, do you see?
A. Yes.
Q. Would you agree that this doesn't suggest that
Post Office chose not to take action in response to the
second key recommendation. Do you think that's fair?
A. Yes, I think that's fair.
Q. If we move on to page {F/869/29}, this is the third key
recommendation of strengthening the change management
process. I pause to note in the middle column, the
"Recommendation" column:
"Management should enhance the current change
management process ... to include."
The word "enhance" doesn't usually connote
deficiency, it connotes room for improvement, would you
agree with that?
A. Yes.
Q. Then if you look in the far column it starts by saying:
"Work has commenced on the strengthening of the
change management process:
"Centralisation of approvals for change for POL
within Fujitsu is to be established."
It goes on for another page and another page, and
another page and another page. It goes on for pages,
actually, all the way to page {F/869/38}. It finishes
at page 36, I see. So quite a lot of things being done
in relation to the recommendation that there be
a strengthening -- an enhancement of the change
management process, would you agree with that?
A. Yes, one of the recommendations that I recall reading in
this document is that Post Office should be aware that
Fujitsu automatically tell them of changes to Horizon --
Q. That's quite interesting, Mr Coyne, because we discussed
that, do you remember, when we talked about the risk
management committee minutes a couple of days ago.
That's one recommendation. In paragraph -- in the
relevant paragraph of your report you talk about the
recommendations, plural.
The impression that you are obviously seeking to
achieve in your report is that four key recommendations
were made and Post Office chose to do nothing about any
of them. Do you not accept that that was the impression
that was given by the relevant paragraph of your second
report?
A. No, I think what the paragraph in my report says is that
there were recommendations that weren't taken up.
Q. Would you give me a moment, please, Mr Coyne?
A. Certainly.
Q. Mr Coyne, you raised the proposal that was considered at
the Risk & Compliance Committee meeting I think in 2012
and you suggested that that proposal was contained in
the 2011 Ernst & Young management letter. Are you sure
about that?
A. It was my perception that it had came from one of the
Ernst & Young --
Q. It came from the 2012 Ernst & Young audit report. Do
you remember that?
A. Right, yes.
Q. It didn't come, I don't believe, from the 2011 letter?
A. I thought the letter was a distillation of the main
points in the report.
Q. The 2011 Ernst & Young management letter accompanied the
2011 audit, yes?
A. Right.
Q. And the following year there was a 2012 audit.
A. Right.
Q. And in the 2012 audit there was a recommendation that
perhaps the system could be enhanced by adopting
an automatic monitoring system rather than the manual
one that was currently operated. Does that ring a bell?
A. Yes.
Q. I'm just wondering whether you would like to reconsider
your evidence that in 2011 it was proposed that this
automatic monitoring system should be adopted?
A. It might be a mistake, maybe it should be 2012.
Q. This may be slightly unfair to you, and it is a long
document, but let's assume that it doesn't contain that
proposal, that the 2011 management letter didn't contain
that recommendation, and if it is an unfair assumption,
and I will check it overnight, I will come back tomorrow
morning and apologise to you.
But on that assumption which I believe to be
correct, so far we have not seen any proposal made by
Ernst & Young in relation to which Post Office has not
chosen to take any action at all, would you agree?
A. I would agree.
Q. Of course it is to be expected that when an auditor
makes recommendations, there will be a -- I don't want
to say a negotiation, but one doesn't assume that every
single proposal will be accepted in every material
particular. There's always going to be some room for
discussion, "Well, maybe we could achieve that objective
in a different way". That is part of the normal process
by which auditors deal with their appointors and vice
versa, do you agree?
A. Yes.
Q. But subject to points of that sort, are you aware of
anything that was recommended in the 2011 letter that
wasn't addressed in some way by Post Office in response
to that letter, and indeed in the very letter itself in
the "Management Comment" section?
A. It could well be that. It could well be that the 2012
document looks back at the findings of 2011 and provides
an update on that and that's why I say it was 2011.
Q. That's not actually an answer to my question. Let's
finish the list and then we can look at 2012.
If we go to page {F/869/47}, this is the fourth key
recommendation, "Review of generic privileged accounts."
If you look at the far right, "Management Comment",
you will see:
"A Fujitsu project has been established to review
all user management. This is to include all system/s,
accounts and privileges.
"Monitoring and communication will be provided to
POL through the regular embedded BAU ..."
That is business as usual:
"... process to ensure access to control management
is robust."
Do you see that?
A. Yes.
Q. So it wouldn't be fair to say, would it, that no action
was taken in relation to that fourth key recommendation
either?
A. Well, nothing got done or got improved over it, and we
can see that from the PEAK where Fujitsu are trying to
address --
Q. So what you are suggesting is that -- there were
obviously audits in later years?
A. Yes.
Q. And are you suggesting the auditors in later years found
a deficiency in Post Office's approach to the
recommendation they had made in 2011?
A. No, what I'm saying is it might not be the auditors that
found future deficiencies after the initial observation
but that the situation with privileged user access logs
wasn't corrected.
Q. Mr Coyne, would you agree with me that in principle the
best people to judge whether action is being taken to
address recommendations made by auditors is the auditors
themselves rather than you, would you agree with that?
A. Yes.
Q. Let's look to see what the auditors said in later years.
Could I ask you to go to {F/1138/1}, this is the 2013
audit of Post Office. If we could go to page {F/1138/7}
of that document. I'm afraid you are going to have to
give me a moment, Mr Coyne, I haven't marked this piece
of paper. I apologise.
A. That's fine.
Q. Here we are. I'm sorry for wasting time. At the bottom
of the page, item 3, "POLSAP periodic user access
review":
"In the 2011/12 audit ..."
So that's the next year's audit:
"... we recommended improvements to the periodic
user access review process and monitoring controls we
noted the efforts by management to strengthen the
control environment this year by implementing a periodic
user review for Cash Centre POLSAP users. However,
finance users are currently not included in the review."
If you look at the far right column in response,
management says "Complete".
Then if we go back to page 4 --
A. Just before we do so, it is just not included in the
audit any more.
Q. Say again?
A. So what it is saying is it is not being included in the
audit any more.
Q. What's not being included in the audit any more?
A. The review. Can we go back one page, please.
Q. Is this to page {F/1138/7}?
A. Yes. So in 2011/12 improvements were recommended. We
noted efforts. But then it goes on to say:
"However, finance users are not currently included
in the review."
Q. Yes.
A. Should I take that to mean that the scope of the audit
has been reduced not to look at finance any more?
Q. If you look at the far right-hand column there is
an answer to your question:
"Complete.
"Finance undertook a review of their users and
periodic reviews are planned. There will be an
additional monthly user report for finance provided via
service management ..."
So Mr Coyne, the answer to your question is no.
A. Right.
Q. Let me get this straight. You were aware of these
documents when you made your statement in your second
report --
A. Yes.
Q. -- that Post Office had chosen not to take action? You
had seen the later audits by Post Office, hadn't you?
A. Yes.
Q. You wouldn't make a claim of that sort if you hadn't
looked at the later documents to actually see what the
auditors were saying, would you?
A. Yes. And at number 4 is one of the reference about
accepting that the risk exists.
Q. Yes, this is where the proposal is made.
A. Yes.
Q. This is where the proposal is actually made which is
then later on considered by the Risk & Compliance
Committee minutes?
A. Yes.
Q. That has nothing to do with the claim we are currently
addressing, the claim you make in your second report,
that Post Office chose not to take the opportunity to
improve its procedures in response to the key
recommendations made in the 2011 Ernst & Young
management letter, do you see?
A. Right, so this is the 2012 audit and this is the first
time that that issue has arisen, is that what you are
putting to me?
Q. Mr Coyne, I'm not sure whether the proposal was made in
2012 as well as 2013 but I'm not aware that the proposal
was made in 2011.
A. Right, okay. But the principal point is that increased
monitoring was suggested by the auditors to put controls
in place to validate programme changes to Horizon and
POLSAP and that Post Office's decision was to accept
that the risk existed.
Q. Here's what's interesting to me, Mr Coyne. In your
second report you made a criticism which is limited
entirely to the 2011 Ernst & Young management letter.
It is a criticism you repeat many times in your second
report, would you agree?
A. Mm.
Q. And the criticism is these key recommendations were made
and Post Office chose not to take them up, not to react
to them, not to take the opportunity to improve with
regard to the recommendations that were made. That was
the claim that you made. And I think you have agreed
with me that when you made that claim you took the
trouble to look at later audit reports, and did you also
look at the Fujitsu service audit reports that were also
in existence? Did you look at those?
A. Yes.
Q. So you looked at all those documents, and having seen
what was in those documents you felt it appropriate to
say that Post Office had chosen not to take the
opportunity to improve. What I'm suggesting to you is
that the evidence is not consistent with that rather
damning judgment. It might be that Post Office didn't
react immediately and accept every jot and tittle of
every recommendation that was made, but you have already
fairly accepted that in the real world when proposals
and recommendations are made by auditors there is always
room for decision as to how much of the recommendation
should be decided, yes?
A. Yes.
Q. So what I'm suggesting to you, Mr Coyne, is that key
recommendations were made in the 2011 letter and the
criticism that you choose to level at Post Office on the
basis of those recommendations and on the basis of
Post Office's response to those recommendations is not
justified by the evidence that you yourself agree that
you had seen. Now how would you respond to that?
A. It appears that I have made a mistake and should have
referred to the 2012 audit.
Q. And if we go back to page {F/1138/4}. Hold on, are you
making an assertion now about the 2012 audit or are you
making an assertion about this audit here that we are
now looking at which is the 2013 one?
A. I would have to check what the 2012 audit said as well.
MR JUSTICE FRASER: We are in 2013 at the moment and
Mr de Garr Robinson is taking you to page 4.
MR DE GARR ROBINSON: Let's go to page {F/1138/4}. Under
the heading "Summary of IT control observations", do you
see that? If we go to the second paragraph.
A. Yes.
Q. "This year, we have not identified significant
exceptions in our independent testing of POL-operated
controls. We have, nevertheless, identified a small
number of improvement opportunities to enhance the
effectiveness of recently implemented controls and
further improve some of POLSAP s security settings. It
should be noted that these control enhancements did not
have an adverse impact on our ability to place reliance
on the effectiveness of automated controls within HNGX
and POLSAP for financial statement audit purposes."
Do you see that?
A. Yes.
Q. That is quite close to what in the audit world could be
regarded as a ringing endorsement, isn't it, Mr Coyne?
A. Yes.
Q. If we go to page {F/1138/8} to see what small number of
enhancements they are proposing in relation to HNGX ...
(Pause)
Now I'm slowing you down, Mr Coyne. I do apologise.
I should have marked this document properly before
I came to it
(Pause)
So it is page 8 of the document. In column 4, you
will see "Change management monitoring control"?
A. Yes.
Q. They say:
"As part of management s initiative to strengthen
the control environment, we noted that POL implemented a
monitoring control to validate whether program changes
to HNGX and POLSAP have been authorised, tested and
approved prior to migration into the production
environment. However, the monitoring control does not
make use of a list of changes generated directly from
POLSAP or HNGX, and hence there is a risk that some
changes are omitted from the monitoring control."
The recommendation is:
"Management should make use of a system-generated
list of changes in performing the monitoring
control ..."
And the management comment is:
"Accept the risk. Engaged with service management
and Fujitsu. System generated lists are not feasible as
they are based on events that the system generate of
which there are multiple thousands per week change
process for monitoring is considered robust through the
existing ticket based approach that review changes
against the MSC list. This will be noted to the Audit
Committee with the November update and the Risk &
Compliance committee endorsed the recommendation on 18th
September 2013 to accept the risk."
So the recommendation is made in 2013 and the
response given by Post Office is actually it is not
feasible. Do you see that?
A. Yes, I think it is actually based on a misunderstanding
of what the weakness that was identified was.
Q. Let's not worry about misunderstandings. Just take it
in stages. The HNG-X recommendation we have seen is in
order to enhance effectiveness, yes?
A. Yes.
Q. It is not a serious deficiency in relation to which
a key recommendation of serious importance is being
made, would you agree?
A. Agreed.
Q. It is an opportunity for enhancement to improve
something that is already adequate, would you agree with
that?
A. Well, it certainly is an improvement. Whether it was
adequate already I can't say.
Q. But what you can't say then by the same token is that
the situation without the improvement was deficient.
That's certainly something you can't say, would you
agree?
A. In my experience I haven't seen a company that's been in
a situation where programme changes are made to two key
systems and the customer is not aware of those changes.
Q. Mr Coyne, we would be on the same page if the true
position was that there was no communication of changes
by Fujitsu to Post Office, but that's not the position.
We lacked at the Risk and Recommendation Committee
minutes a couple of days ago. We also looked at the
document, was it minutes, that preceded that meeting
which explained in much greater detail what the factors
were and what the cost was and so on.
The fact is there was a system for communicating
changes. It was a manual system that was checked on
a monthly basis and Fujitsu are saying, do you know, it
would be an enhancement if you could make it automatic.
Ernst & Young, I'm so sorry. It would be
an enhancement, not a serious deficiency but it would be
an enhancement, it would be an improvement if you could
make it automatic and it went to the Risk & Compliance
Committee. They worked out that it would cost
£1 million because of the way that the system was
configured and they came to the overall view that the
appropriate thing to do would be to make no change at
this stage but monitor the monitoring process more
closely to see if any adverse events arose and if they
did arise then they would review the recommendation
again. Do you remember our discussing that?
A. Yes.
Q. And I think I'm right in saying that when we discussed
that you indicated that that was not an unreasonable
approach.
A. It is a poor position to be in in the first place but it
is not an unreasonable approach.
Q. Mr Coyne why do you say, in fact how do you feel it
appropriate for you to say it is a poor position for
Post Office to be in when the very people that are
making the recommendation are only doing so on the basis
that it is an enhancement. They are not saying there is
a deficiency that needs to be addressed. So why is it
you are taking it upon yourself to take a much stronger
view of steps that should be taken than Ernst & Young
itself?
A. Because that is the situation that you should be in in
order to be confident about your systems that are being
supplied to you.
Q. Right. One final question in relation to that, the
proposal that we are talking about of course has nothing
to do with the kind of remote access that we are
considering does it?
A. Agreed.
Q. So actually we have just spent the last ten minutes
discussing your criticism of Post Office, it is
a criticism which actually doesn't arise in relation to
the access control programme -- the access control
principles that are applied in relation to Post Office's
business, would you agree?
A. Agreed.
Q. So I would suggest to you Mr Coyne that having regard
not just to the 2011 management letter, which says some
things that read in isolation might be seen as negative,
but having regard also to the 2013 audit reports and
Ernst & Young's views expressed in that, what comes over
is a very different picture from the one that you depict
in your second report?
A. I thought you were going to take me to the part of the
Ernst & Young report that dealt with user access and
privileged users.
Q. The 2011 report?
A. Yes.
Q. Well, do you remember I took you through the table with
each of the recommendations and I took you to each of
the comments as to what Post Office was doing in
response to them. Do you remember that?
A. I do not think that was in regard to privileged user
access.
Q. It was in regard to the four key recommendations that
you refer to in your expert report, which I'm asking you
about. Do you see?
A. Right.
Q. What I'm suggesting to you is that, in order to give
a balanced and fair assessment of Post Office's
position, it would have been not only appropriate but in
fact I would suggest necessary also to refer to the
things that were said in the 2013 audit and I would like
to ask you, Mr Coyne, why you chose not to say anything
about the 2013 audit?
A. I'm confused because this doesn't relate to the remote
access point. So we have talked all about remote
access. My understanding was you were going to take me
to the remote access part of this for me to comment on.
Q. Mr Coyne, I'm not going to debate with you what I'm
going to ask you about and what I'm not going to ask you
about. I would like to ask you -- the question I asked
you is, having felt it appropriate to criticise
Post Office's approach and to claim that Post Office had
chosen to take no action on the basis of four key
recommendations made in the 2011 Ernst & Young letter,
and having repeated that point several times in your
second report, my question to you is why you felt it
appropriate not to mention the 2013 report? Do you not
think that would have been a fair thing to do?
A. I agree that providing any additional material would be
helpful.
Q. So why did you choose to leave it out?
A. It wasn't a conscious decision to leave anything out.
Q. If I may say so, Mr Coyne, it must have been a conscious
decision to report the negative things that were
contained in the 2011 management letter, but are you
saying that was conscious but leaving out the 2013
audit, that wasn't conscious, that was -- what are you
saying?
A. I was attempting to identify areas of lack of control
that could have led to bugs, errors and defects.
Q. What you were trying to do, Mr Coyne, may I suggest, is
that you were trying to find things, trying to find
coconuts to lob at Post Office and you were not very
interested in whether Post Office had some kind of
shield that it could raise to the coconuts that you
would be lobbing, would that be fair?
A. No, it wouldn't be fair because it is not about largely
irrelevant aspects where improvements have made, it is
where aspects that are relevant to this dispute haven't
been dealt with, such as control and change to software.
Q. Would you give me a moment please. (Pause).
I would like to spend a few minutes now, at the end
of my cross-examination in this area, discussing another
set of documents that you didn't refer to in your second
report, which is the service audits that Dr Worden
referred to in his report.
As well as performing financial audits with
Post Office, Ernst & Young also performed audits for
Fujitsu's IT infrastructure services supporting POLSAP
and Horizon Online, didn't they?
A. Yes.
Q. From 2016 these service audits also covered a review of
Credence, didn't they?
A. I think that's right, yes.
Q. Would you agree that service audits by Ernst & Young are
rather more specific than the general financial audits
that would have been done by Ernst & Young for
Post Office's general accounts?
A. Yes.
Q. Now we have the service audits in the trial bundles for
the years 2012, 2013, 2014, 2015, 2016 and 2017.
I don't have time to take you to them all but let's just
look at 2012. Could we go to {F/1041/1} please. So
this is a description of Fujitsu's system of:
"IT Infrastructure Services Supporting Post Office's
POLSAP and HNG-X Applications throughout the period
April 2012 to December 2012 with the independent service
auditor's assurance report including test performed and
results thereof."
Now, have you read those documents?
A. I believe I have, yes.
Q. Let's go -- there are a number of control objectives,
aren't there?
A. Yes.
Q. What Ernst & Young does is it expresses its opinion on
how -- whether there are deviations or not from the
appropriate -- what should be the appropriate approach
to each of those control objectives, would you agree?
A. Yes.
Q. So if we go to access control, which I am sure you will
agree is quite an important one in the present context.
Let's go to page {F/1041/83}. It is control objective
10.
"Control objective 10: Controls provide reasonable
assurance that access to system resources, including
computing platforms and operating systems is restricted
to properly authorised individuals."
You will see that there is a series of, what does
one call them? Tests on the left-hand side from 10.1
through to 10.7.
A. They are statements in which to benchmark against.
Q. Yes. Thank you.
So there are these seven checks/statements and if we
run through them all -- perhaps you could read them to
yourself. (Pause).
A. Yes.
Q. You will see -- I have to say Mr Coyne I'm terribly
impressed by how fast you read, you are much quicker
than I am. I'm rather envious.
But if you look at the right-hand column it is
headed "Results of Tests". You see that for all of
those tests there are no deviations noted except for the
third one.
MR JUSTICE FRASER: I think we need to go back a page.
MR DE GARR ROBINSON: Which is at page {F/1041/83}. There
they say:
We selected a sample of 12 platforms within the
in-scope applications. The Group Policy on failed access
attempts that manages access to all these servers was
set to disable accounts after 6 consecutive failed
access attempts; the POL setting should be to disable
accounts after 3 failed access attempts. The other
settings tested were in line with the POL requirements.
No other deviations noted."
You will see the "Management Response":
"Management accept this deviation and will. Rectify
at the next revision of the Policy document ..."
And they set out what the document is. That's quite
good, isn't it?
A. Yes, there's very little noted there.
Q. And would it be fair to say that there are no other --
in all the later years, 2013, 2014, 2015, 2016, 2017,
there are no deviations of any sort in relation to
control objective 10. Does that ring a bell?
A. I think I have made a mistake here in believing which
document -- which Ernst & Young audit this was.
I thought this was going to be the one that noted the
controls with regard to access to the Horizon back end
systems. I'm not sure this is the document that
I thought it was.
Q. So you think -- what, you think there is another
document that is relevant to the debate we are having,
do you?
A. Yes.
Q. What's that document?
A. Could I take a moment to find it?
Q. Yes, by all means. We are talking about
an Ernst & Young document?
A. I believe so, yes.
MR JUSTICE FRASER: Can we go back to page 7 because it
might actually be the right document and he is just
looking at the Fujitsu part that's attached.
{F/1041/7}, does that help you?
A. It could well do, my Lord. Could we go through?
MR JUSTICE FRASER: I'm not going to control what you look
at. If you want to look forward or back just ask the
operator to do it. Mr de Garr Robinson I just thought I
might help.
MR DE GARR ROBINSON: I'm much obliged to your Lordship.
A. Can you keep going forward please to the point where the
tables start please. {F/1041/10}. I don't think this
is the one that I was thinking it was.
Q. What I took you to was the service audits that Dr Worden
refers to at some length in his supplemental report and
which he refers to again in your joint statement?
A. Yes.
Q. I'm happy for you to tell me there are some other
documents which are relevant to the debate we are
having, but the fact that you thought I was going to
take you to some other documents doesn't really take
matters much further, does it?
A. Okay, I'm happy for you to take me wherever you want to
take me to.
MR JUSTICE FRASER: Can I just make a point generally
because I know you have only got another day.
Although Mr de Garr Robinson does say from time to
time "the debate we are having" and "the discussion we
are having", actually he is cross-examining you. So if
you just focus on his questions. If in order to answer
the question you refer to documents or there is some
wider sphere, well, of course that's understood, but it
is not a general debate.
A. Yes, my Lord.
MR JUSTICE FRASER: Is that clear?
A. Accepted.
MR JUSTICE FRASER: All right.
MR DE GARR ROBINSON: Thank you, my Lord. Let's now go to
control objective 13, it is headed "Remote Access". It
is at {F/1041/88}. To be clear I apprehend that what
this document means by remote access isn't exactly the
same as what I mean when I talk about remote access,
although there is some significant overlap.
A. Yes.
Q. Perhaps you could cast your eye down since you are such
a quick reader. Is it page 88? (Pause). So if you
could just cast your eye down those control objectives.
You will see on the right-hand side of the page "No
deviations noted"?
A. Yes.
Q. Ernst & Young gave Fujitsu a full, clean bill of health
on all the other control objectives, didn't it?
A. Yes. For context the remote access authorisation here
is the connection from the counter to the date centre.
Q. Yes, it is not entirely the same as what we are talking
about. But on all the objectives that are addressed in
this service audit, they cover issues that you have
raised but going much wider than remote access, don't
they? That is a slightly unfair question, let me be
clearer. Control objective 1 {F/1041/70}:
"Controls provide reasonable assurance that access
to data centres and facilities with computer equipment,
storage media and program. Documentation is restricted
to properly authorised individuals."
{F/1041/71}
"Control Objective 2: Controls provide reasonable
assurance that computer equipment and facilities are
protected from damage by fire, flood and other
environmental hazards and maintenance agreements are in
place."
{F/1041/72}
"Control Objective 3: Controls provide reasonable
assurance that programs, files and datasets that have
been identified as requiring periodic backup are backed
up and retained."
{F/1041/73}
"Control Objective 4: Controls provide reasonable
assurance that processing is appropriately authorised
and scheduled and that deviations from scheduled
processing are identified and resolved."
All of these things contribute to robustness, don't
they, of the Horizon system?
A. They do, yes.
Q. {F/1041/74}
"Control objective 5: Controls provide reasonable
assurance that system availability performance and
capacity are routinely monitored to ensure potential
issues are captured and investigated."
{F/1041/76}
"Control Objective 6: Controls provide reasonable
assurance that significant operations incidents are
adequately reported, tracked, monitored through
resolution and resolved timely."
That's quite an important one, isn't it, bearing in
mind the criticisms you make of the processes adopted by
Fujitsu and Post Office in relation to problems, would
you agree?
A. Yes, it is talking about the procedures and policies,
yes.
Q. {F/1041/78}
"Control Objective: 7 Controls provide reasonable
assurances that networks are managed to contractual and
site requirements, monitored for availability and
response times and issues are identified, tracked and
resolved."
{F/1041/80}
"Control Objective 8: Controls provide reasonable
assurance that modifications to system software and
networks are authorised, tested, approved, properly
implemented and documented."
That is quite an important one in the context of
these proceedings, isn't it?
A. Yes.
Q. {F/1041/81}
"Control Objective 9: Controls provide reasonable
assurance that new or modified application software
development efforts are authorised tested, approved,
properly implemented and documented."
Again quite important in the context of these
proceedings.
We have already looked at control objective 10. If
we look at control objective 11 {F/1041/85}:
"Controls provide reasonable assurance that access
to databases, data files, and programs is restricted to
properly authorised individuals."
That is quite important, isn't it?
A. It is and that's why I'm surprised that in 2011
Ernst & Young made the observations that they did in
another audit document.
Q. {F/1041/87}
"Control Objective 12: Controls provide reasonable
assurance that networks and system resources are
protected from external threats and access violations
are detected, reported and investigated."
Now all of those are quite material to many of the
judgments you have made in the course of both your
reports about how the system was operated, about how its
robustness could be improved and so on, aren't they?
A. Yes.
Q. Now in the years 2012 all the way through to 2017,
Mr Coyne, only one other deviation was noted apart from
the one we have already gone to and that was in the 2016
service audit and for fairness I should take you to it.
It is at {F/1562/83}. I may have given the wrong
reference.
MR JUSTICE FRASER: We are going to 2015?
MR DE GARR ROBINSON: Let's hope I have got the right
reference.
If we could go to page {F/1562/83}. Yes.
"Control Objective 9: Controls provide reasonable
assurance that new or modified application software
development efforts are authorised tested, approved,
properly implemented and documented."
A. Yes.
Q. It is said that one POLSAP user could develop and
implement a change for software development and a user
should not be able to do both, do you see that?
A. Yes.
Q. This issue was flagged and resolved before the service
audit was published, do you see that?
A. Yes.
Q. There was only one user, there was no reported incident
in connection with this, yes?
A. Mm.
Q. And no recommendation for improvement, yes?
A. Yes.
Q. So subject to those two deviations over a five-year
period, no other deviations were noted in these service
audits and no recommendations for improvement were made?
A. No.
Q. Now, in your reports you attached importance to audits,
didn't you, saying that auditors are in a better
position than you and Dr Worden to evaluate the change
control processes, yes?
A. Yes.
Q. Do you stand by that?
A. Yes.
Q. Do you accept that in circumstances where you are making
serious criticisms of Post Offices' and Fujitsu's
processes over all or most of these control objectives,
it was really important to provide a balance to account
of where Post Office and Fujitsu stood?
A. The specific observations I made was user access and
change control. A lot of the things you have taken us
through there aren't necessarily about that.
Q. A lot of the things I have taken you through are
terribly about lots of things that you purported to
criticise Post Office for during the course of your two
reports, would you agree with that?
A. No. The majority of the criticism is about change
control and user access.
Q. Do you not think, Mr Coyne, that it would have been fair
for you to have had proper regard to the service audits
and to have mentioned them in your reports when deciding
to criticise Post Office and Fujitsu in the way that you
have?
A. It would have been helpful to provide an overview of
these, yes.
Q. My Lord, I wonder whether that's a convenient moment.
MR JUSTICE FRASER: I think so. Would you like to start at
10.15 am tomorrow?
MR DE GARR ROBINSON: I would love to start at 10.15.
MR JUSTICE FRASER: I think there may only be a couple of
other people in this court who share your exuberance but
luckily I'm one of them.
So Mr Coyne, I know you come from Preston but
I imagine you are staying in London, are you?
A. Yes. I am.
MR JUSTICE FRASER: So there's no problem with you coming
for 10.15 am and did the two of you discuss the
re-examination --
MR DE GARR ROBINSON: My Lord we did.
MR JUSTICE FRASER: Would you like to enlighten me or either
of you?
MR GREEN: My Lord, I'm going to confine myself to 5 to 10
minutes per day of cross-examination, so I said to my
learned friend if he is able to finish by 3.45 pm, but
we haven't factored in any questions from your Lordship.
MR JUSTICE FRASER: That's all right. So broadly 3.45 pm
more or less tomorrow. So 10.15 am tomorrow Mr Coyne.
Thank you all very much.
(4.30 pm)
(The court adjourned until 10.15 am on Friday,
7th June 2019)