Thursday 6 June 2019

Horizon trial day 16: transcript

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:


                                          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)