26 October 2022 – Anthony Oppenheim
Hide video Show video
(10.00 am)
Mr Beer: Good morning, sir. Can you see and hear me?
Sir Wyn Williams: Yes, I can, thank you very much.
Mr Beer: And we can you. Thank you very much.
Can I call Anthony Oppenheim, please.
Sir Wyn Williams: Yes.
Anthony Oppenheim
ANTHONY OPPENHEIM (affirmed).
Questioned by Mr Beer
Mr Beer: Thank you, Mr Oppenheim. My name is Jason Beer, as you know, and I ask questions on behalf of the Inquiry. Can you tell us your full name, please?
Anthony Oppenheim: Anthony Edward Peter Oppenheim.
Mr Beer: Thank you very much for coming to give evidence to the Inquiry and thank you also for the witness statement that you previously provided to us. We’re very grateful for the assistance that you have given and are giving in the course of the investigations by this Inquiry.
You should have a hard copy of the witness statement in the folder behind you in volume 1. Could you take it out, please, and in tab A1 there should be a witness statement which, excluding exhibits, is 85 pages in length and dated 7 September 2022 and, on page 85, there should be your signature.
Anthony Oppenheim: There would have been but it’s got “GRO” on top of it.
Mr Beer: It’s been redacted. Okay, that’s an error by the Inquiry staff. We will correct that later. Does it look like the witness statement that you did sign?
Anthony Oppenheim: Yes, it does.
Mr Beer: Were the contents of it true to the best of your knowledge and belief?
Anthony Oppenheim: Yes, they were.
Mr Beer: A copy of that witness statement will be uploaded to the Inquiry’s website. I’m going to ask you questions, not about every part of it, but just selected parts. Do you understand?
Anthony Oppenheim: Sure.
Mr Beer: Can we start with your background and experience, please. I think you were employed by ICL from 1979 and left Fujitsu in 2018; is that right?
Anthony Oppenheim: That’s correct.
Mr Beer: So you were a company man for the majority of your career, just shy of 40 years?
Anthony Oppenheim: That’s right. It wasn’t the first job, but the majority, certainly.
Mr Beer: By training, you are an engineer and an economist?
Anthony Oppenheim: Yes.
Mr Beer: So far as concerns this Inquiry, would this be right, the most relevant part of your employment occurred between 1994 and 2002?
Anthony Oppenheim: That is correct.
Mr Beer: It began in October 1994 when you joined the Pathway bid team –
Anthony Oppenheim: Yes.
Mr Beer: – and I think you were one of the first to join.
Anthony Oppenheim: That’s correct.
Mr Beer: You were then Pathway’s commercial and financial director; is that right?
Anthony Oppenheim: That’s correct.
Mr Beer: You say in your statement that you became a member of Pathway’s board on 15 June 1995 and, by that, do you mean the board of ICL Pathway Limited?
Anthony Oppenheim: Correct.
Mr Beer: You left ICL Pathway in February 2001, going back to ICL itself; is that right?
Anthony Oppenheim: Yes, it is.
Mr Beer: But you retained some responsibilities for ICL Pathway, namely the commercial and contractual arrangements between ICL Pathway and its customers and its subcontractors; is that right?
Anthony Oppenheim: No, it was a higher level overarching responsibility for the commercials only and not the financials, so just to elaborate briefly, Pathway then was one of a number of major accounts that I was responsible for commercially.
I think the initial title was “commercial and finance for major projects”, but it was quickly reduced to commercial only, so I was brought back in later – you may go to this – to negotiate with POCL, or POL as it was then, but no, I didn’t have day-to-day responsibility.
Mr Beer: I wasn’t suggesting day-to-day responsibility. Perhaps you can tell us exactly the level of responsibility that you had after February 2001 and before December 2002?
Anthony Oppenheim: Virtually none. It was a sort of monthly review of high level reports and that was it, so I was replaced in my previous role by a guy called Colin Lenton-Smith.
Mr Beer: Were you involved in any negotiations after February 2001 and before 31 December 2002 concerning ICL Pathway?
Anthony Oppenheim: No.
Mr Beer: Your involvement with the Horizon System, as it had become, ended entirely, is this right, in December 2002?
Anthony Oppenheim: That is correct.
Mr Beer: Can we have a look at your witness statement, please, at paragraph 14, that’s WITN03770100. It will come up on the screen for you, Mr Oppenheim.
Anthony Oppenheim: Mm-hm.
Mr Beer: Look at page 4, please, and then highlight paragraph 14. You say:
“I was involved in setting up all of the above arrangements …”
That’s the creation of ICL Pathway Limited, the relationships with ICL Pathway’s shareholders and the engagement of the principal subcontractors, that’s what you have been speaking about above?
Anthony Oppenheim: Correct.
Mr Beer: Then you continue:
“… the management of Contract Changes between 1996 and 1999, and then, in 1999, unwinding the … Benefits Payment Card part of the contract.”
Is that a fair summary of the principal parts of your role over time?
Anthony Oppenheim: Yes.
Mr Beer: Can I turn to, in slightly more detail, positions of responsibility and roles within ICL Pathway between October 1994 and February 2001. I wonder whether we could look, please, at FUJ00000060. This is the first exhibit to your witness statement, a document that you will recognise, and, for the note, I think this is part of schedule A14 to the codified agreement of 28 July 1999.
Does that figure, Figure 1, the Pathway board, accurately describe the five members of the Pathway board and their job titles at that time, as at July 1999?
Anthony Oppenheim: Yes, it does.
Mr Beer: So Sir Michael Butler is the chairman, Mr Todd as deputy chairman, you as commercial and finance director Pathway, Mr Bennett as the MD of Pathway and then Mr Christou – it says “ICL legal and [commercial] director”, what’s the significance of ICL being written against his name and Mr Todd’s name, rather than Pathway against yours and Mr Bennett’s names?
Anthony Oppenheim: Because they were not executives of ICL Pathway, they were executives of ICL and they were board members of ICL Pathway.
Mr Beer: On the next page, if we go over the page please, there is an introduction to what is called the Pathway management team. Can you see under paragraph 2 in bold there’s the heading “Pathway Management Team” and the codified agreement says:
“The Pathway team is in place. The management structure has been agreed and the positions filled. The structure of the team is as follows …”
Then it says “Figure 2 – the Pathway Management Board”, and we see a place where a diagram or a figure is supposed to appear but is blank, at least in this version. You will see that the title to the missing figure is, in fact, to a Pathway management board. A couple of questions arising from that. Firstly, was the Pathway board that we saw on the previous page, as it was described, the Pathway board, the same thing or a different thing to the Pathway management board that we see in the title to figure 2 on page 2 of the document?
Anthony Oppenheim: I would say different. It’s a, I agree, slightly confusing combination of management and board. This would have been the operating team, as opposed to the board.
Mr Beer: Sorry, it’s a poor question from me. To start with, was the Pathway management board different from the thing that we saw on the previous page, which was described as the “Pathway board”?
Anthony Oppenheim: I suspect so, but it would be quite helpful to see the diagram, of course. I think it is referred to somewhere else but obviously not here.
Mr Beer: We will go to some other documents in a moment. The second thing: was the Pathway management board different from the Pathway management team?
Anthony Oppenheim: Again, without seeing the diagram, I can’t be sure but I think this is probably meant to be the Pathway management team.
Mr Beer: So that heading might, or might ought to have said “Pathway management team”, okay.
Anthony Oppenheim: Well, the heading and then the beginning of 2.1 talk about “Pathway team”, so I would think that’s just an error in the figure 2 description.
Mr Beer: Can we look at FUJ00000061, please. Again, this is another exhibit to your witness statement. This is an ICL Pathway organogram, a basic organogram, under the heading of “ICL Pathway’s directors” and can you see in the bottom left it appears to date from 2000, right at the foot of the page?
Anthony Oppenheim: Yes, I can see that.
Mr Beer: Notwithstanding the heading to the document indicating that it concerned ICL Pathway’s directors, does it, in fact, depict only directors or other people as well?
Anthony Oppenheim: No, I would say this was – this included, obviously, the managing director and I was a director, but all the others are part of the management team that we were talking about a moment ago.
Mr Beer: So is this in fact a better description of the management team that we saw missing from the version of the codified agreement that we have just examined?
Anthony Oppenheim: It is, except that this is a later version than that –
Mr Beer: Ie 2000?
Anthony Oppenheim: Yes.
Mr Beer: So, thinking back, would you say this is a fair description of the Pathway management team?
Anthony Oppenheim: Yes, as it was at 2000. It had changed slightly, but yes, as at that date, yes.
Mr Beer: We see you are on this organogram, the third box down on the left, and we see that you are in a reporting line straight to the managing director.
Anthony Oppenheim: Yes.
Mr Beer: Is that correct, that your report was straight through to the MD at this time, Mike Stares?
Anthony Oppenheim: Correct, yes, it always was, yes.
Mr Beer: The people on the left-hand side of the organogram underneath – ignoring his PA for the moment – on the left-hand side of the diagram, Mr Foley, Mr Muchow and Martyn Bennett. Again, did they report directly to the MD?
Anthony Oppenheim: Yes, they did.
Mr Beer: It’s only the people on the right-hand side of the diagram that appear to report through Mr Coombs, the deputy MD, to Mr Stares; is that right?
Anthony Oppenheim: That is correct.
Mr Beer: So does it follow that people such as Mr Austin – Terry Austin on the right-hand side – Mr Flynn, in the middle of the right-hand side, people responsible for development and implementation, they did not report to you?
Anthony Oppenheim: Oh, that is correct. They reported to Mike Coombs who, apart from being a deputy MD, was programme director.
Mr Beer: Lastly, can we look at a further version of the codified agreement to see how the Pathway board had changed. This is FUJ00000062 and again this is exhibited to your witness statement. This version of schedule 14 to the codified agreement is dated 21 July 2000 and is version 1.4. I think you can see that from the bottom right.
Anthony Oppenheim: Yes.
Mr Beer: Starting with the Pathway board by then, it says:
“The ICL Pathway board has been set up under chairmanship of Richard Christou, ICL Legal and Commercial Director, with board representatives from ICL.”
We can see in figure 1 the depiction, pictorially, of the ICL Pathway board at this time and just looking how things have changed by now, Mr Christou, who was formerly the legal and commercial director, has become chairman of the board, correct?
Anthony Oppenheim: He was still ICL, legal and –
Mr Beer: I’m sorry.
Anthony Oppenheim: Yes.
Mr Beer: I missed what you said there, “he was still”?
Anthony Oppenheim: He was still legal director of ICL. Previously, he had been just a board member, but his overarching role was still legal and commercial for ICL.
Mr Beer: Back in ICL parent?
Anthony Oppenheim: Yes. So in addition to that role, he had taken on chairmanship from Sir Michael.
Mr Beer: Mr Todd remains the deputy chairman of the board?
Anthony Oppenheim: Yes.
Mr Beer: Mr Stares has taken over from Mr Bennett as Pathway managing director.
Anthony Oppenheim: Correct.
Mr Beer: Mr Bennett is described as “ICL Government Managing Director”, can you help us, what does that mean: ICL government managing director?
Anthony Oppenheim: I think there’s a word missing. It’s probably “Government business unit” or some such. So he had moved out of Pathway, ICL Pathway, and into – back into ICL, taking on a new senior role for a part of ICL’s business, which faced off to or dealt with UK Government.
Mr Beer: So the descriptions that are given underneath each name, one shouldn’t be misled into thinking that’s the role that they are performing in ICL Pathway, that’s a description of their role, in this case, back in ICL, the parent company?
Anthony Oppenheim: Correct. These are their day jobs and in addition they are, in a sense, non-exec directors of ICL Pathway. The same applies to Tim Escudier. Likewise ICL services division, whatever.
Mr Beer: Mr Escudier has been added. He is described as ICL’s financial services managing director.
Anthony Oppenheim: Yes.
Mr Beer: Again, that’s back in ICL itself rather than ICL Pathway.
Anthony Oppenheim: So John Bennett and Tim Escudier were peers running different business units within ICL, correct.
Mr Beer: Can we go over the page please. We now see that in this version of the contract figure 2 has been completed. The rubric is the same, “ICL Pathway management team” is the heading, the announcement that the ICL Pathway team is in place, the management structure has been agreed and:
“The structure of the team is as follows …”
The cross heading still describes this as the Pathway management board and just take a moment to look at the organogram.
Anthony Oppenheim: Yes.
Mr Beer: Does that organogram describe something called “The Pathway Management Board”, or does it describe something called “The Pathway Management Team”?
Anthony Oppenheim: Management team.
Mr Beer: We see in documents, hundreds of documents, the phrase “Pathway Management Team”, capital P, capital M, capital T. That was a term of art, essentially.
Anthony Oppenheim: Yes, and that’s how this organogram should have been described.
Mr Beer: Does that show again that those responsible for, for example, implementation, customer requirements and development did not report to you?
Anthony Oppenheim: Correct.
Mr Beer: Does that represent the position in reality, those responsible for implementation of the programme, the development of the programme and customer requirements didn’t report to you?
Anthony Oppenheim: Correct.
Mr Beer: We’re going to see that later on you had – ie later on today rather than later on in the piece – you had quite some involvement in issues concerning the development of the project, the implementation of the project and the customers’ requirements. You were present at a number of meetings at which those three issues were very much the hot topics?
Anthony Oppenheim: Yes, that’s true. I was involved but I wasn’t responsible for them. If I can just clarify, if I may. There were a lot of tensions around the commercials. My main responsibility here was to take care of the commercials vis-à-vis BA and POCL and –
Mr Beer: Just stopping you there, sorry to interrupt you, you may understand what “The commercials” mean, could you explain it to a naive audience?
Anthony Oppenheim: By all means.
Sir Wyn Williams: Mr Oppenheim, can I interrupt you. Before you give that answer, I hope it won’t take you out of your stride, it would help me if the document could be taken down once we have looked at it so that I can see Mr Oppenheim better. I can see you, but not very well. That’s great. Thank you very much.
Anthony Oppenheim: So commercials was a sort of shorthand form of describing some of the things you talked about in your introduction. So contracts with BA and POCL and the codified agreement was the one that operated through most of the piece but prior to that there were several other contracts, there was the BA contract, the POCL contract and the combined contract because it was a tripartite set of agreements, so that was one piece.
Then there was the piece with subcontractors and we had a lot of subcontractors and so that also was a commercial/contractual matter which I had overall responsibility for and also you mentioned, I think, funding/financing, so I had responsibility for that as well, trying to get the monies lined up for this project because it was a PFI project so we needed that as well.
So I won’t go on, that is essentially what “commercials” mean.
Mr Beer: Thank you.
Anthony Oppenheim: And then the ongoing operation of change control, pursuing agreements to agree and such-like.
Mr Beer: So I interrupted your answer there and you were explaining to me why we see your footprint on a number of the documents, a very high number of the documents, when you had no management, or directorial responsibility for issues such as development, implementation or customer requirements and it is simply because they all impinged on commercial issues; is that right?
Anthony Oppenheim: Absolutely, spot on, correct.
Mr Beer: Not because you had any particular management or directorial responsibility or any technical expertise?
Anthony Oppenheim: I had to acquire sufficient technical expertise to be able to deal with – to understand the issues, to be able to deal with the commercials because a lot of this – I repeat, this was a PFI. There was a lot of tension between the parties as to who would be responsible for what and, in some cases, there was a great deal of detail that needed to be understood in order to get the wording right, to get the terms and conditions right, to do with risk management. So I had to understand the detail at a pretty granular level.
Mr Beer: We will come back to examine that understanding later today. You mention there the PFI contract and the consequences of it. In your statement, you tell us that there appeared to have been a conflict between the Benefit Agency’s and Post Office Counters Limited’s business objectives; is that right?
Anthony Oppenheim: There were conflicts, yes.
Mr Beer: When was that conflict first appreciated or understood by you?
Anthony Oppenheim: Right at the beginning.
Mr Beer: The “beginning” meaning what, from 1994 onwards?
Anthony Oppenheim: Yes.
Mr Beer: So it wasn’t only after you entered the contract that this conflict emerged? It was evident from day one?
Anthony Oppenheim: It was implicit and visible in the terms of reference for the contract. If you thought through what at a second level that meant, in terms of the interactions between the parties, I would say we understood that from very early on and it was part of our risk register from very early on.
Mr Beer: When you say part of your risk – it was written down, was it?
Anthony Oppenheim: I believe it was, but I’m casting my mind back a long time now.
Mr Beer: Was there a document called “risk register”?
Anthony Oppenheim: There were risk registers, yes.
Mr Beer: Who was responsible for maintaining the risk register?
Anthony Oppenheim: Martyn Bennett.
Mr Beer: Can you recall now the format in which they were kept?
Anthony Oppenheim: I think over the period it evolved from probably Excel, at the beginning, during the bid phase to – I can’t remember the particular application that was used, but there was an application which was used in ICL and we used that, but I can’t remember the name.
Mr Beer: It was Mr Bennett who had responsibility for that?
Anthony Oppenheim: Yes.
Mr Beer: Was there any team underneath him that was responsible for feeding into the risk register?
Anthony Oppenheim: He had, from memory, one – at least one person working for him, Graham somebody. I can’t remember his surname.
Mr Beer: Thank you. With responsibility specifically for the risk register?
Anthony Oppenheim: Well, in a sense, they both had responsibility for the risk register. I wouldn’t like to say one was responsible for maintaining it and the other one for inputting into it. It was a team task.
Mr Beer: Thank you. Was that ever escalated to the ICL Pathway board for review and sign off?
Anthony Oppenheim: Sign off – I can’t remember about sign off. Certainly we talked about the major risks at the board and this one would have been one of those, the inherent conflict. The conflict – “conflict” is a bit strong. It’s a conflict when there’s a problem. At the outset, it’s a different set of priorities, perhaps.
Mr Beer: Putting it shortly, we’ve got a lot of evidence on this from other witnesses and in the documents, but one of the purposes of the proposed system was, from the Benefits Agency perspective, to eliminate fraud?
Anthony Oppenheim: Encashment fraud, yes.
Mr Beer: But Post Office Counters Limited’s business goal was to seek to make customer experience as frictionless as possible, I think you describe it as, and therefore to encourage usage; is that right?
Anthony Oppenheim: Yes. I think that’s an accurate description of the difference in priorities.
Mr Beer: So the Benefits Agency wanted not only a different means of payment but tight controls, therefore. Wasn’t, therefore, the Benefits Agency’s withdrawal from the programme always likely?
Anthony Oppenheim: The reason we felt confident that they would go through with it and we were proved wrong was that, at the time, there was – we were assured of a very strong political imperative from the government and, in a sense, we relied on that to push it through.
Mr Beer: Did that, to your recollection, enter the risk register, the risk of the DSS withdrawing from the programme?
Anthony Oppenheim: I don’t necessarily recall – no, I don’t recall it being in the risk register. I do recall discussions, certainly at the board, about that. Were those discussions right from the very beginning? I would say no. I think, at the beginning, the discussion was much more around the success – the success of the programme and the chances of problems on the programme and what those problems might be, what those issues or risks might be.
Mr Beer: Do you think that there is a possibility that the questions, persisting questions, over whether the system that was being developed best suited the objectives of the Benefits Agency, on the one hand, and Post Office Counters Limited, on the other, got in the way or obstructed the delivery of a system that, in fact, best suited the needs of subpostmasters?
Anthony Oppenheim: I understand why you would ask that question. It’s difficult to give you a definitive response. All I would say is this: we are going back, as you said at the outset, 25 years and there was no internet then and, in a sense, the choice was do you have an offline system, so you can’t do any verification of a banking transaction, or do you have a totally nailed up, online system which required lease lines, very, very expensive.
And what we were offering was a distributor system, which is now commonplace but was very, very unusual in those days, and the NAO and the PAC both acknowledged that that was an advantage. It didn’t show up necessarily in the gradations of us versus our competitors at the time, but both the NAO report and the PAC review made the point that, actually, this distributor system, which was kind of a halfway-house of being mostly offline, but it could also go online as and when verification was needed, was a good approach.
Mr Beer: You tell us in your witness statement, it is paragraph 46 for the cross-reference, that the withdrawal of the Benefits Agency from the programme increased the pressure on Post Office Counters Limited to move fast, move at speed.
Anthony Oppenheim: Yes, I did say that, yes.
Mr Beer: You speak about an increase of pressure to move fast. Firstly, was there already pressure on the Post Office to move fast in the development and implementation of the programme?
Anthony Oppenheim: There was. I mean, there was an imperative on all three parties. I would say that, in rank terms, the Benefits Agency wanted the fraud reductions and were instructed to secure the fraud instructions (sic) by HM Government and this was the – you know, the best way to do that, so there was that political imperative on them.
The Post Office wanted to automate for other clients, not just the Benefits Agency, to improve their competitiveness and they also recognised that the Benefit Payment Card, as it was conceived, was going to be their way of securing the maximum footfall, as you said, of Benefits Agency business.
Mr Beer: Because it brings people into the branch?
Anthony Oppenheim: It brings people into the branch and when they’re there, they buy other things, exactly.
Mr Beer: So there was already pressure on Post Office Counters Limited to move fast. Where did that existing pressure come from?
Anthony Oppenheim: Well, as I said in my statement, it was there, for the reasons I just said, their own business case relied on attracting new business and certainly maximising the amount of BA business.
There was a recognition that the BA business would go down over time because of ACT – sorry, that’s bank-to-bank transfers – so instead of someone going into the Post Office, they would get a payment through the bank.
Mr Beer: Automated credit –
Anthony Oppenheim: Automated Credit Transfer. So there was that trend, in any event, and that was plainly what the DSS would have preferred because it’s cheaper and it absolutely eliminates encashment fraud. It’s easier to administer.
So I would say that was always their preference. So POCL wanted to head that off, that trend off, and get the thing automated as soon as possible, but so long as they had the Benefits Agency book business and ACT was on the backburner, actually the incentive on them was not as great as subsequently when BA said “Okay, we’re now going to go to ACT as our mainstream way of delivering – of paying benefits”.
Mr Beer: So why did the withdrawal of the Benefits Agency from the programme increase that existing pressure to move fast?
Anthony Oppenheim: Because when they did withdraw, they said, “Okay, we’re now going to go ACT mainstream and we’re going to move away from the Post Office and we’re going to do that from” – from memory, 2003. So they basically gave a window of opportunity to the Post Office to get themselves automated and also something called Network Banking, which I assume we will come on to later, or Universal Bank in place before the default of moving everybody to ACT kicked in in 2003. So there was a window from 1999 to 2003.
Mr Beer: How do you know this, that the withdrawal of the Benefits Agency increased the pressure – the existing pressure on Post Office Counters Limited to move fast for the implementation and roll-out of the programme?
Anthony Oppenheim: Because of what I just said, which was written down in the exit agreement of the BA from the tripartite set up.
Mr Beer: Do you think there was a risk that this rush to move fast was detrimental to the interests of subpostmasters?
Anthony Oppenheim: Well, firstly, I can’t – I really can’t comment on that – detrimental … okay. Did it make them – did it induce them to go faster than they should have done to deliver a safe system? There was pressure, absolutely there was pressure, but then, again, we had had an agreed rollout plan such – which was not accelerated, in fact it went backwards because there were issues and they needed to be fixed, so from the time that the BA withdrew, I would say that there was at least a three-month slip from what had been contemplated when they withdrew, and when we signed the heads of agreement with the Post Office, which then led to the codified agreement.
So I think POCL – the people I dealt with were very measured and careful and I don’t think that they cut corners. No, I don’t think so.
Mr Beer: So there –
Anthony Oppenheim: (Unclear).
Mr Beer: – wasn’t, in the need to move quickly, the rush to roll out, any detrimental effect on the quality of the system that was delivered?
Anthony Oppenheim: There were – again, I find it difficult – “any”? There’s always a bit of a trade-off. At one level you can only do so much in a test environment. This is a very complex technical system and a lot of the issues that were experienced were operational, where things had gone not according to plan, for some reason. I’m sure you will delve into that later, but –
So you can do so much in a test environment and we had massive amounts of end-to-end testing. There were also issues going across boundaries, between the Pathway piece and POCL, TIP, and so on. So, at some point, you do actually have to go into the live environment and get feedback. The question for me is: what do you do when you get feedback and how well do you respond to that feedback?
Mr Beer: Can we move to a new topic and we’re going to circle back round a little later today to look at some of the answers that you have just given by reference to what, in fact, happened on the ground.
Can you explain to the Inquiry, in your own words, what the PinICL system was?
Anthony Oppenheim: Basically, it was an error fault logging system, so if something had been reported to the helpdesk that indicated an underlying fault, then it would result in a PinICL. A PinICL would be raised and that would go through the support and development team in order to get either a workaround or a clarification, or a fix, a bug fix.
Mr Beer: It’s right, isn’t it, that PinICL was an internal ICL system?
Anthony Oppenheim: It was an internal ICL system but POCL were aware of it and had visibility of it.
Mr Beer: I’m going to test in a moment what “aware of it” and “visibility of it” mean.
Anthony Oppenheim: Okay.
Mr Beer: It was an internal system, in that it was designed by ICL Pathway?
Anthony Oppenheim: By ICL. It was a standard ICL system which ICL Pathway used.
Mr Beer: Okay, so it was an off-the-shelf, as it were, ie a pre-existing system that existed even before Pathway was conceived?
Anthony Oppenheim: My understanding – and, again, I’m going back a long way – is that this was the standard that ICL used right across its business.
Mr Beer: Can you recall who designed it?
Anthony Oppenheim: No, no. I mean, it was pre-existing, is my recollection. We simply adopted it as part of ICL.
Mr Beer: You wouldn’t be able to help us with who developed it?
Anthony Oppenheim: No idea, sorry. As I say, it was pre-existing. It probably existed for years prior to the creation of ICL Pathway.
Mr Beer: In terms of running or operating it, that was done by ICL Pathway, is that right, in the context we’re speaking about?
Anthony Oppenheim: In the context we’re speaking about, yes. All the data that went into it, the entries that went into it and the outputs that came out of it were managed by ICL Pathway, correct.
Mr Beer: Can I turn to whether Post Office Counters Limited staff had direct access to the PinICL system. You tell us in paragraph 160 of your statement – I think we should probably turn that up.
Page 53 of your witness statement, that’s WITN03770100 at page 53, and 160 at the bottom, please. Thank you. If you just scroll up a little bit, please.
This is under the cross heading “POCL awareness of issues within the Horizon System at the time of rollout”. You are dealing with a different issue here, but, in the course of dealing with it, you say in paragraph 160, second line:
“My understanding is that [Post Office Counters Limited] had access to our PinICL system and test data and that, under the aegis of the Joint [Acceptance Incident] Workshop, they were intimately involved in the [Acceptance Incident] rectification plans”, et cetera.
It’s the part of the sentence that says “My understanding is that [Post Office Counters Limited] had access to our PinICL system” that I want to ask about. Are you there intending to refer to a contractual right vested in Post Office Counters Limited to obtain access to data held on PinICL, ie a theoretical right in a contract that could be exercised on demand by Post Office Counters Limited?
Anthony Oppenheim: I don’t recall ever having discussed that. My understanding was that, certainly with respect to the AIs, all of the relevant PinICLs were shared with POCL, so we had a lead on both sides and they shared information between them.
Mr Beer: Putting the AIs to one side for the moment, I’m looking at the PinICL system.
Anthony Oppenheim: Right.
Mr Beer: Are you referring there to what I have described as a theoretical right, a contractual right on demand, “Can we please see what is on a PinICL”, or are you referring to an understanding that, as a matter of fact, the Post Office had direct physical access to PinICLs, just as a matter of course?
Anthony Oppenheim: I think not, as a matter of course. So, in hindsight, I probably would have worded this slightly differently. The point here was specific to the AIs and those PinICLs that related to the AIs, I believe, were shared.
That’s different, I can see that, from having a contractual right to just go through any and all PinICLs. I don’t know, to be honest, whether they did have access, or some members of their team had access. I genuinely don’t know that.
Mr Beer: Are you aware of any policy or procedure, or protocol concerning the issue of access by the Post Office to PinICLs and test data?
Anthony Oppenheim: I don’t, no.
Mr Beer: So, although this is written in an unqualified way, ie it isn’t restricted to those PinICLs that were associated with AIs, albeit you are discussing AIs at the time, you don’t have any evidential basis for saying that Post Office had, as a matter of course, direct access to all and any PinICLs; is that right?
Anthony Oppenheim: That is correct, yes. I mean, this was written in the context of the AIs and I can see that what I said there is probably too broad a sweep. I was thinking specifically of those PinICLs that related to the AIs.
Mr Beer: In relation to the AIs, what is your understanding of how Post Office Counters Limited secured access to those PinICLs that were associated with a AI?
Anthony Oppenheim: To be honest, I don’t know. You would have to ask my technical colleagues, but –
Mr Beer: We will get to those, in due course.
Anthony Oppenheim: Okay, right.
Mr Beer: Can we look at the documents to see whether Post Office Counters Limited did have a contractual right to look at records in PinICLs, so data that happened to be in PinICLs, and could we look, please, at FUJ00000071, the codified agreement. Can we turn to page 49, please, and can we look at paragraph 801.2. I will read it out:
“The Contractor shall grant or procure the grant to POCL, any statutory or regulatory auditors of POCL and their respective authorised agents the right of reasonable access to the records and shall provide all reasonable assistance at all times for six (6) years after the creation of the relevant Records for the purposes of carrying out an audit of the Contractor’s compliance with this Codified Agreement including all activities, Charges, performance, security and integrity in connection therewith. Each party shall bear its own expenses incurred pursuant to this clause. On termination, the Contractor shall within a reasonable time to be agreed by the parties, transfer the Records to POCL or a replacement contractor, as instructed by POCL. The Contractor shall thereafter be released from any further liabilities under this Clause in relation to such Records.”
You will see that “Records” in the third line has a capital R, it’s a defined term.
Can we look at page 89, please, of the document. I think it might, in fact, be the previous page.
(Pause)
Mr Beer: If you just keep going, thank you. “Records” defined as:
“Full and accurate records relating to the performance of the POCL Services.”
I’m not going to turn it up now and chase down what “POCL Services” meant, but it is defined in this codified agreement as:
“The core systems services and all other obligations of the contractor under the Codified Agreement.”
Can we go back to page 49 and paragraph 801.2, please. Thank you. This tends to suggest that POCL had a right of reasonable access to the records as we have defined them but, for the purposes of an audit – if we just scroll up on the page, it’s under the heading “Audit” – would you agree, reading those now, that the primary purpose of the provision appears to be to allow access to the records for the purposes of a financial audit?
Anthony Oppenheim: Well, that would be the normal implication of statutory, regulatory auditors and keeping records for six or seven years would be the norm.
Mr Beer: So you’ve got the heading, you’ve got the time period and then you’ve got the reference to statutory or regulatory auditors, pointing in the direction that the purpose of this clause was to give POCL a right of reasonable access for that purpose.
Anthony Oppenheim: Well, that’s how I would have read it. You have just pointed me to the definition of “Records” which has broadened that.
What I can say with confidence is that certainly at the time of the AI exercise, which I was very much involved in as joint chair with Keith Baines, I was confident that any and all PinICLs that were relevant were being shared.
Now, what I don’t know is whether our POCL colleagues were given direct access into the PinICL system, that’s what I don’t know. So there’s the point about “reasonable access” and what is “reasonable access”? I genuinely don’t know the answer to that. You would have to ask a technical support person.
Mr Beer: That’s what I’m seeking to explore with you at the moment.
Anthony Oppenheim: Yes.
Mr Beer: Would you have – would you read these clauses as permitting Post Office Counters Limited access because they are sufficiently broad to allow access to records and give a right of access to records held within the PinICL system as a matter of course?
Anthony Oppenheim: From the definition of “records” that you reminded me of, I think it’s a reasonable interpretation, but what I would say is that I have no recollection of it being brought up as a contractual matter by Keith Baines or anybody else, ie it was never an issue to my recollection. So either they had the access and that would explain why there was no issue, or alternatively POCL thought they had sufficient sharing of information without direct access, such that it wasn’t an issue for them.
Mr Beer: In terms of physical access, was the – that can be taken down, thank you.
In terms of the situation on the ground rather than the contractual right, on what system was PinICL run, or was the system itself called PinICL?
Anthony Oppenheim: My recollection – and this was not really my bailiwick, is that this was a part of their support suite of applications that we, if you like, adopted from the mothership. I really don’t know the answer to your question.
Mr Beer: Were clients habitually given access to suites of applications provided by the mothership?
Anthony Oppenheim: No, no, I mean you would need to consider security and I would say almost certainly not. They were intended as internal systems and normally if we’re carrying out a project for a client, on an outsourced basis or project basis, I would have thought that there would be an agreement about what information would be shared but it wouldn’t extend to direct access into internal systems. That would be my guess.
Mr Beer: You looked, in the course of your joint chairmanship of the resolution of some particularly complex and problematic AIs, at PinICLs, back in the day, on a relatively regular basis.
Anthony Oppenheim: Yes.
Mr Beer: Did you ever see an entry on a PinICL made by an employee of Post Office Counters Limited?
Anthony Oppenheim: Not a direct entry. What I have seen is a reference to an individual in POCL support team who had “authorised closure” of a particular PinICL and there were at least two, possibly three of those that I have seen and I refer to in my witness statement.
Mr Beer: We’re going to come to those in a moment. You’re not referring there to something that a Post Office Counters Limited employee typed in, this is something that an ICL Pathway employee typed in saying –
Anthony Oppenheim: Yes.
Mr Beer: – “I have spoken to Mr X or Ms X, they authorise closure”, for example?
Anthony Oppenheim: Correct. To repeat, this was an internal system and we gave, I believe, reasonable access to it or extracts from it, but beyond that we didn’t allow POCL people to make direct entries and take control over it, no.
Mr Beer: You said “In my view we gave them reasonable access to it”, did that mean – coming back to some of the answers you gave earlier – you still believed that they had viewing rights of it?
Anthony Oppenheim: I don’t know.
Mr Beer: – that they exercised?
Anthony Oppenheim: I don’t know whether they had direct viewing rights. I will be honest, I’m not sure I ever knew and I certainly can’t remember. What I would say is they had extracts at least which appeared to satisfy them at the time, but again you would need to talk to my technical colleagues who had the direct interaction between themselves and their opposite numbers.
Mr Beer: Can we look at some of the documents that you were just referring to and a convenient way of doing that will be through your witness statement because you actually cut into your witness statement the relevant PinICLs.
Anthony Oppenheim: Okay.
Mr Beer: It is WITN03770100 and it’s at page 41. Just to introduce some context, at paragraph 122 you say:
“To understand better what had been going on in the run-up to the joint decision to start volume Rollout in January 2000, in preparing this witness statement I went through [the] PinICLs raised in late 1999 that related to AI376. I do not recall having seen any of these PinICLs at the time although (as explained above) I had been briefed on the issue.”
Then you set out in paragraph 123 three PinICLs, those ending 552, 884 and 363. You say that they are:
“… examples of PinICLs that identified Reference Data as the cause of issues. The records show that in each case [Post Office Counters Limited] were aware of what had happened and approved closure of the PinICL, as demonstrated by the quotations below …”
You deal firstly with 552 and I think we’ve got the whole of the relevant bits of the PinICL there. It reads:
“This is clearly the result of the missing Primary Mappings on the local travel ticket products in the Southend area. The error in the reference data was corrected on Friday 24th September and therefore [transferred] transactions recorded up to that time [cash accounting periods 26 and 27] will fail to report to the cash account, causing a receipts [and] payments condition.”
Then this:
“Ok to close as per Martin Box of POCL 16/2/00.”
Is it that last entry, under your last bullet point there, that you are referring to in your present answers when you say that it is clear that Post Office Counters Limited had knowledge of what was on some of the PinICLs because they authorised closure of them and this is a record of an authorisation to close?
Anthony Oppenheim: That’s part of what I was trying to describe. This is clearly a little bit later than the actual AI workshops which took place in August/September 1999, so this being dated closure in February 2000, so this would have been an operational PinICL that occurred. At the time there were different PinICLs. There had been reference data related PinICLs that we – as I recall, the first known one was in June 1999. So earlier, I was referring to the approach during the AI workshops where we had a very strong focus on identifying the problems, understanding the root cause and fixing them.
Mr Beer: If we look at the next one please at paragraph 123.2, if we just scroll down. Thank you, yes, that has all of it on there. Again, the first three bullet points don’t matter, but it’s the fourth for present purposes:
“Okay to close as per Martin Box of POCL …”
He was a Post Office Counters Limited employee, Martin Box, and so this is a record made by an ICL Pathway employee of their claim that Mr Box had authorised closure of the PinICL, yes?
Anthony Oppenheim: That’s my understanding, yes.
Mr Beer: Now, of course, that wouldn’t be necessary to make a record like that if Post Office Counters Limited did have direct access to the PinICL because they could type in “We agree closure”?
Anthony Oppenheim: They didn’t have – can I just challenge you a little bit on that. They might have had view access, they might have had, but not write access. They definitely did not have write access.
Mr Beer: By “write access” you mean writing access?
Anthony Oppenheim: Writing access, yes. I’m very confident with that but I don’t know whether they – some individuals may have been given a viewing access, I just don’t know.
Mr Beer: So is your final position on this then, you don’t know one way or the other and we can –
Anthony Oppenheim: In terms of viewing, that’s correct. I do know that they wouldn’t have had write access.
Mr Beer: Thank you. Can we look at – that can come down, thank you – something which is the reverse of – to some extent the reverse or the obverse of what we have just been looking at, namely remote access by ICL Pathway to systems to make changes to them at a counter level, without the relevant subpostmasters’ knowledge and without the relevant subpostmasters’ permission.
To your knowledge, did Pathway have the ability to obtain such remote access without the relevant subpostmasters’ knowledge or permission?
Anthony Oppenheim: No. Let me give you a little bit of – perhaps a longer explanation than you want. The way the architecture worked was that all transactions, all messages, so-called, were exchanged between counters within a branch and then from the branch to so-called correspondence servers. So they were all supposed to be in sync. Now, there was no ability to get access into a branch PC, but what there was was a possibility to get into the correspondence server, make an entry in the correspondence server, which would then propagate back to the branch, so the effect would be the same.
The point though is that it would be clear – should have been clear, I had understood – that any entries made in the correspondence server would show up as entries made on the correspondence server, in other words they would appear as a different counter or some such. There would be a marker in the audit trail that showed that those entries had been made centrally as opposed to within the branch, so if there’s an argument later, the audit trail would have shown where an additional message would have been inserted. And that, for me, was absolutely fundamental, that there would be an audit trail.
The other point I quickly make is that no message that had been created in a branch could be amended, as that message was unique and discrete, a bit like block chain. Riposte was a forerunner to block chain.
Mr Beer: When did you acquire the knowledge that you have just summarised?
Anthony Oppenheim: At the time. I dealt with Riposte technology to the level, as I was saying earlier, that I needed to in order to understand what could happen, what the risks were, and I also managed the contract with Escher, who were the supplier of Riposte, and it was Riposte that was at the heart of what I just described.
Mr Beer: So to be clear, there was remote access by ICL to the correspondence server, which such access would have the effect, or could have the effect, of changing transactions conducted at branch level, but your understanding was that should be identifiable for audit purposes.
Anthony Oppenheim: If I may slightly modify what you stated, the correspondence server sat in Wigan and Bootle, so they were central servers.
Secondly, they would show up with a time stamp as subsequent messages, well after the original – let’s say there was an erroneous message, some kind of doubling up or whatever, there were – I dare say you will go into that later – opportunities for error, let’s put it that way, inadvertently, to occur and this would have been a way to fix those after a – I would have expected a helpdesk call from the postmaster to say he had a problem.
There was also this notion of repaired cash accounts, and so on, and so on, strict rules about that. But they would have all been made in the central service and there would have been, as I say, a separate, completely separate, set of messages associated with those changes, so that if there was an argument later the audit trail would have shown.
Mr Beer: You said that that separation and the separate set of messages was fundamental. Why was it fundamental?
Anthony Oppenheim: Well, for actually the reasons that we’re having to discuss, so that there would be no argument later.
Mr Beer: No argument about what?
Anthony Oppenheim: Well, who had made what changes, who had made what errors. The idea was –
Mr Beer: Ie whether they were the responsibility of a subpostmaster, or as a consequence of action taken by an ICL employee at or in the correspondence layer?
Anthony Oppenheim: Precisely.
Mr Beer: What controls and safeguards were that system, the use of remote access to the correspondence layer, subject to?
Anthony Oppenheim: Well, you would have – I’m sorry to defer on this. You would have to talk to my support colleagues. My understanding from, if you like, my commercial role was that there would be very stringent security controls, access controls for – I think I was expecting third line only, third line support.
Mr Beer: Yes. When you say “stringent access controls”, you mean the barriers or gateways that would have to be passed through in order to obtain access?
Anthony Oppenheim: Yes, correct, and the other thing I say on top of that is that – I’m sure you will come on to it this later – the third supplemental agreement and related service control documents stipulated very clearly that, whenever anybody in ICL made a change, they were to inform POCL, or POL as it became, of whatever those changes were and the reasons for those changes.
Mr Beer: How widely known at board level, ICL Pathway board level, was it known that such remote access existed?
Anthony Oppenheim: I don’t know, to be honest –
Mr Beer: Was it the kind of thing – sorry.
Anthony Oppenheim: Let me carry on and try and answer that. Did we ever talk about it? I don’t remember a minute of it at any of the board meetings, but what I can say is that any system you have to have some kind of third line ability to get into systems to make changes. Now, you want those to be as limited as possible but there is that need. If there’s a corruption, sometimes you just have to go in and fix it. Now, this is beyond my knowledge. You would need to talk to support people on just what they knew and how they actually did it in practice, that’s the other point.
Mr Beer: In terms of the breadth of knowledge at board level, which is what I’m interested in at the moment, was this facility so obvious that it need not be discussed?
Anthony Oppenheim: Yes, because, as I said, any system and all systems, I would contend, have very tightly controlled – they should be very tightly controlled, very limited number of key personnel – sorry, not key personnel in the sense of this contract, but trusted people with particular levels of expertise who could go in, do a very limited number of amendments, which would then be documented, and I stress that they should always be documented.
Mr Beer: When you say “documented”, do you mean separately written up and catalogued or do you mean, by the very operation of the system, there is an audit trail available of the messages?
Anthony Oppenheim: There would be an audit trail of the messages. One would obviously need to go and look for them and to know to go and look for them, which may have been a problem here, I don’t know. But also the process around the third supplemental agreement was that, whenever such a change was made, POCL were to be informed.
Mr Beer: Would have been, how?
Anthony Oppenheim: There was – again, if you were to refer to – I think it was called the TIP incident process, TIP – TIP reconciliation and incident process.
Mr Beer: We’re going to go on to that in detail later.
Anthony Oppenheim: That’s the place –
Mr Beer: Hold on a moment. That’s a very specific issue arising out of a specific problem, AI376.
Anthony Oppenheim: Yes, but this is all to do with, as far as I’m concerned, 376 and –
Mr Beer: The answers that you have been giving are only framed by reference to AI376; is that right?
Anthony Oppenheim: Well, did you say you wanted to get back to it in detail later?
Mr Beer: Yes.
Anthony Oppenheim: My answer is in response to 376 broadly. Maybe when we get to it you will see if it needs to be expanded on but that’s the context I’m referring to, yes.
Mr Beer: To your knowledge, did anyone within Post Office Counters Limited know about ICL’s remote access to the correspondence layer?
Anthony Oppenheim: It was a requirement in the supplemental agreement, so yes. I mean, you say remote access to the correspondence server. This was the support people who, in a sense, are logically sat right on top of the correspondence server, so the remote point I don’t quite fathom. They are logically sitting in the data centre managing these correspondence servers.
Mr Beer: We could knock off the word “remote” and just say “access”?
Anthony Oppenheim: Yes.
Mr Beer: Can I turn – in fact, before we turn to the next topic I wonder whether that’s a convenient moment, sir, for the morning break.
Sir Wyn Williams: Yes, by all means.
Mr Beer: Sir, could we say half past please?
Sir Wyn Williams: Yes, fine. Thank you very much.
(11.14 am)
(Short Break)
(11.29 am)
Mr Beer: Sir, good morning. Can you see and hear me?
Sir Wyn Williams: Yes, I can, thank you.
Mr Beer: Thank you, and likewise.
Mr Oppenheim, can I turn to consider disclosure obligations for the purposes of criminal proceedings.
Anthony Oppenheim: Mm-hm.
Mr Beer: After the Benefits Agency withdrew from the tripartite arrangement, you know, we know, that ICL Pathway and Post Office Counters Limited entered a bilateral agreement.
Anthony Oppenheim: Yes.
Mr Beer: I just want to look, please, at paragraph 277 of your witness statement, that’s page 85, please. It is, in fact, the last paragraph of your statement. I hope by now, if we go down, the page has been replaced and you can now see your signature in there.
Anthony Oppenheim: Yes.
Mr Beer: That is your signature?
Anthony Oppenheim: That is my signature.
Mr Beer: The “GRO”, the general restriction order redaction has been removed.
Anthony Oppenheim: Yes.
Mr Beer: But, anyway, more substantively, at paragraph 277, you say:
“I was aware of [Post Office Counters Limited’s] facility to mount private prosecutions against subpostmasters determined to be acting fraudulently and that the Codified Agreement …”
Just interposing there, the codified agreement is the agreement that I just mentioned:
“… required Pathway to provide audit trails when requested to do so to support such prosecutions. My expectation was that each case would be properly investigated before concluding that the cause of a cash shortfall was indeed fraud rather than some kind of mismatch in the system. To the best of my recollection, I was never asked to look into any of these cases – indeed, I was completely unaware at the time that the prosecutions were going on.”
It’s the first sentence that I’m interested in particularly. You were aware, that’s aware at the time, of Post Office’s facility to mount private prosecutions against subpostmasters?
Anthony Oppenheim: I was. There’s a provision in the contract and there was in the original POCL contract, which was the forerunner to the codified agreement, which was carried forward, that we would support the Post Office in – when requested to do so – in mounting such prosecutions, with the provision of information.
Mr Beer: You have referred to the codified agreement, which we’re going to come to in a second, and the fact that it was carried forward from the original agreement to a provision. Is it by that means that you knew about the facility of the Post Office to bring private prosecutions?
Anthony Oppenheim: That was the original trigger for that awareness and I remember asking Liam Foley, one of the colleagues you will remember, sorry, from the organogram, about it and he explained that that did exist. I was very surprised at the time.
Mr Beer: Surprised about what?
Anthony Oppenheim: That the Post Office had that jurisdiction.
Mr Beer: And why were you surprised?
Anthony Oppenheim: Previously I was just unaware that anybody had that jurisdiction, other than Crown Prosecution.
Mr Beer: So the awareness that you had existed in the period from, would this be right, about 1996 to 2002?
Anthony Oppenheim: That sounds right, yes.
Mr Beer: So you knew that it was the Post Office, unusually, who would be a prosecutor rather than, as you said, the police or the Crown Prosecution Service?
Anthony Oppenheim: As I say, I was aware of it. It never really came up in my working experience over that time.
Mr Beer: Can we look at the second part of the sentence there where you are, is this right, drawing a link between your knowledge of the facility of Post Office to prosecute in the criminal courts its subpostmasters for fraud and a part of the codified agreement that requires the provision of data to support such prosecutions?
Anthony Oppenheim: Yes, I’m trying to make the case that – the point that I was aware of the provision to provide such information and I assumed that it would be a rare thing when it happened and that we would provide the audit trail kind of information that I was referring to earlier.
Mr Beer: Why did you assume that it would be a rare thing?
Anthony Oppenheim: Because I had assumed that inspection of the kind of information that, again, I referred to earlier, whereby we – where there was a mismatch in the system, as referred to here, and in the third supplemental agreement, in particular, and the subsequent operational processes, that there was an acknowledgement that there would be occasional mismatches. I mean, everybody knew that and the scale of the system was such any remote system will have mismatches occasionally.
So the question then was, well, what happens when there is such an event? And my presumption was, wrongly, that the Post Office would look into those and, certainly at the outset, as I say somewhere else, give the postmaster the benefit of the doubt. We needed feedback when these things occurred, in order to find the errors in the system and then fix them.
Mr Beer: Why would you assume that the Post Office would give, in prosecutorial decisions, subpostmasters the benefit of the doubt?
Anthony Oppenheim: Well, I had assumed that, before getting to prosecution, the people that were on, as it were, the other side of the fence from me would look into the evidence, the audit trails that we were talking about earlier, so start with the support people and they would look at it and they would put questions to ICL Pathway and we would respond and we would dig into these things, in the same way as we did with PinICLs. That was the whole point about PinICLs and incidents and also problems, which were combinations of similar incidents.
Mr Beer: You said that you assumed. Is that something that you remember assuming from 25/27 years ago, or is it something that you have looked at now and is an ex post facto rationalisation of what you think you would have thought, had you thought about it at the time?
Anthony Oppenheim: It didn’t occur to me that POCL would rush to prosecution without checking the facts and the fact that we had all of these very, very detailed provisions as to what to do under certain error conditions, operational error conditions, for me was an indication that my opposite numbers understood that these things would occur and that there was a process for dealing with them.
And, on occasion, I write somewhere, there’s a specific statement in the third supplemental agreement, that it would not always be possible to determine what exactly had gone wrong in a particular case and, therefore, if we had to make an assumption about putting something right we would absolutely inform the Post Office of what that was and then it was up to them to determine whether that was a correct assumption or not.
I was very uncomfortable with the pressure that we were under to actually make corrections. We were invited to make all the corrections. We pushed back on that and, in the case of TIP errors, Post Office then made the errors – the error corrections. But, I mean, there was just a general understanding between all the technical and commercial people that there would be occasional errors. There’s something like 10 million transactions a day going through this system: there will be errors.
Mr Beer: You either think now that you would have thought, had you addressed your mind to it, or thought then, that the Post Office in making prosecutorial decisions would, against that context of the likelihood of errors generated by the system itself, have given subpostmasters the benefit of the doubt?
Anthony Oppenheim: Benefit of the doubt, certainly in the early stages when they always have teething problems with any new system. So you asked earlier about did they rush to rollout, did we rush to rollout. There was a judgement call made as to the quality, we passed the tests, but the word of caution was always be on the look out for new things that we didn’t know about, and that’s the same with the introduction of any new, large complex system.
So in the early days, certainly, I would have said, “Let’s listen to the feedback, pay attention, work out what’s going on here”, and, in that circumstance, yes, give the benefit of the doubt.
I’m not sure what – that would necessarily be what I would have said, say, five years in, when the thing should have been completely bedded in, but, even then, there needed to be an inspection of the audit trails and the facts.
Mr Beer: We can take that document down but, in its place, please, put FUJ00000071. Back to the codified agreement and can we look, please, at page 97. If we can highlight/blow up, “Prosecution Support”, 4.1.8 and 4.1.9, please. These provisions in the codified agreement provide that:
“The contractor shall ensure that all relevant information produced by the POCL service infrastructure at the request of POCL shall be evidentially admissible and capable of certification in accordance with Police and Criminal Evidence Act (PACE) 1984, the Police and Criminal Evidence (Northern Ireland) Order 1989 and equivalent legislation covering Scotland.
“At the direction of POCL, audit trail and other information necessary to support live investigations and prosecutions shall be retained for the duration of the investigation and prosecution irrespective of the normal retention period of that information.”
Would you agree that, in order for ICL Pathway to comply with these provisions, it would be necessary for it to understand what is required in order to make information evidentially admissible and capable of certification in England and Wales, in accordance with the Police and Criminal Evidence Act 1984?
Anthony Oppenheim: That’s the requirement as stated, yes.
Mr Beer: It’s the requirement as stated but, in order for compliance to occur, it would be necessary for your company to understand what is required in order to ensure that such relevant information is evidentially admissible, ie how do we go about carrying that provision into effect?
Anthony Oppenheim: I agree, absolutely right. That’s what is required of us and that’s what we should have done. Now, what I can’t speak to is personal knowledge of those details. They are very important details but I was not involved in that. That whole area was, as I recall, Martyn Bennett, risk management – part of his portfolio.
Mr Beer: But would you agree that it would – it, ICL Pathway – only be able to comply with the provision if it knew what the requirements of the law were, so that it could ensure that data was captured, retained and enjoyed sufficient integrity and reliability and be placed in a suitable form evidentially to a court?
Anthony Oppenheim: So my understanding was – I never looked at this in detail, this provision in detail myself, but my understanding was that the information provision that was agreed between ICL Pathway and POCL, specifically around the third supplemental agreement and the related control documents, were designed to deliver precisely this and there was a mass – as I was alluding to earlier – a mass of audit trail information behind that.
So out of all of that, I would have expected all of the substance to be satisfied. What I don’t know about is the form and the detail of those requirements.
Mr Beer: You said in the middle of that answer that you didn’t, I think, concentrate on this requirement in detail at the time. You did tell us in your witness statement that you were aware that the codified agreement required Pathway to provide audit trails when requested to do so to support private prosecutions?
Anthony Oppenheim: Correct. I was aware of these two paragraphs.
Mr Beer: Being aware of those two paragraphs, to your knowledge, did ICL Pathway seek advice on what the requirements that had been placed upon it were, in order to be able to achieve compliance with the contractual provisions?
Anthony Oppenheim: I have to say, I don’t know. I covered a lot of ground but I didn’t cover this ground. This was, as I recall – as I said before, the remit of Martyn Bennett. Whether he took external advice or not, I’m afraid I can’t tell you.
Mr Beer: Would you agree that, in the absence of either such advice or a very good existing understanding of the criminal law, which is perhaps unlikely within IT professionals, compliance with the clause at a practical level would be difficult to achieve?
Anthony Oppenheim: I don’t know. It’s – if all of the basic data was good data, was kept and was made available, then I should have thought that that was what this was pointing to, but I don’t know.
Mr Beer: Well, for example, you wouldn’t, unless you knew what the law required, either because you knew it or because you had been advised about it. You wouldn’t build into your systems a requirement or a process which says if a client ever wishes to use the data, which our system is producing or handling, for the purposes of criminal proceedings, then we would have that data ready for disclosure and for such use in a state that’s evidentially sound. You wouldn’t design your systems that way.
Anthony Oppenheim: You wouldn’t necessarily make any changes to the design of the system which was designed to flag issues and, to the extent possible, identify the root causes and the appropriate course of action and report on them in a day-to-day operational sense.
So if it satisfies those and it satisfied the Post Office requirements, which were very detailed indeed about reporting, then I should have thought that their requirements at the CCD level – sorry, contract control document level – would have encompassed this because they were the people who were basically the custodian of this process for the Post Office. If they weren’t satisfied with what we were doing, I would have expected them to have told us that and if they had looked at it and felt it was wanting, then it would have come to me as a contractual issue, but it didn’t.
Mr Beer: Well, one approach would be to say “Look, we know, or we have been advised that at this time the criminal law, a provision in Police and Criminal Evidence Act 1984, says that it may be necessary for an employee of Pathway to say to a court ‘There are no reasonable grounds for believing that the data produced by our system is inaccurate by improper use of it’, how are we going to be able to say that in a witness statement to a court? Can we design our system in a way that allows an ICL Pathway employee to say such a thing?”
Anthony Oppenheim: So, taking your question in the two parts, taking the second part first, the design of the system was first and foremost to ensure accuracy, but also then operationally, if there was an error identified, identify the error, identify the root cause where possible, what fixes would be needed and the processes for managing that all through and reporting on it. So if you have satisfied those then I can’t imagine, apart from presentation, that there would be anything more that we would need to do to satisfy this condition, but that’s – that statement is a statement out of not knowing the detail of the law.
Now, as I said, Martyn Bennett would have had this responsibility. There were people in probably second or third line support who would have been charged with pulling out the audit trails and producing the evidence.
We also, at the time, had an in-house lawyer. He may or may not have looked at it.
Mr Beer: What was his name?
Anthony Oppenheim: Warren Spencer. You may recall him from the organogram. So what I don’t know is whether these – my colleagues looked into this at that sort of legal level and satisfied themselves that, based on the operational data that we would be producing, that we would be compliant.
Now, as for getting one of our people to talk to the accuracy – and I – I would always hope that there would be a degree of caution inserted in any statement that can guarantee that this is accurate, because with IT systems sometimes they do go wrong, that’s just the nature of them, particularly, as I said, where they’re distributed, you have breaks in communication between the branch and the centre, you can have a printer fail in the middle of a transaction, there are all manner of things – or ran out of paper in the middle of a transaction – all manner of things that can go wrong and if they can then they will, particularly at such a large scale.
So you’ve got to allow for the possibility that something has gone wrong that we don’t actually understand.
Mr Beer: You said that Martyn Bennett had responsibility for ensuring the discharge of this obligation?
Anthony Oppenheim: I thought so. This would logically have come under him. Alternatively it would have come under –
Mr Beer: Just stopping you there. We can take that down from the screen now.
Anthony Oppenheim: Okay. Alternatively, it would have fallen to my service director colleague, Steve Muchow, at the time, so it could have simply been given to him to enact, but in terms of satisfying ourselves that we could satisfy this, I would have expected that to have been Martyn Bennett and possibly Warren Spencer.
Mr Beer: Why would you expect it to have fallen to Martyn Bennett?
Anthony Oppenheim: Because this was viewed as, I think, to the extent I recall it at all, a risk item, but it could also have been a support item which would have made it Stephen Muchow, so I genuinely don’t know.
Mr Beer: Why would it have been viewed as a risk item?
Anthony Oppenheim: Because it’s – risk was his title but he was also head of assurance, audit and the like, so this would have come under his other responsibilities to do with audit.
Mr Beer: Who, if anyone, would have been the liaison point within Post Office Counters Limited in relation to this issue, the design of a system, or the enactment of policies that carry this high level statement into practical effect?
Anthony Oppenheim: I’m afraid I don’t know and it’s possible that it was missed at the outset until it started to happen. I mean I just do not recall this ever having come across my desk, sorry.
Mr Beer: Are you aware of any policy, protocol or other document that does in fact carry this contractual obligation into effect at a practical level?
Anthony Oppenheim: No. As I said, there were lots of service incident problem management, and such-like, documents which talked about what you do when something goes wrong, but not in regard to this, no.
Mr Beer: Yes, there are many, many documents that deal with the operation of the system and the rectification of errors within it at an operational level, as you rightly described it. I’m not looking at this through an operational lens.
Anthony Oppenheim: I understand.
Mr Beer: I’m looking at it through the lens of a contractual provision that says you’ve got to be ready to disclose things in a form, effectively, that’s evidentially secure for the purposes of the criminal law.
Anthony Oppenheim: So “secure” in that context, for me, would mean it’s – it has integrity, it’s accurate and it’s complete and whether that is – those are requirements, in any event under the contract, as far as I’m concerned. So there was nothing that I thought at the time – benefit of hindsight is a wonderful thing – that I needed to look at this provision specifically because I felt that all the other things would, in a sense, provide the detail behind it.
Mr Beer: Did you know Gareth Jenkins?
Anthony Oppenheim: His – I know his name and I don’t recall actually ever having had dealings with him.
Mr Beer: What did you understand, at the time, his role within ICL Pathway to have been?
Anthony Oppenheim: I can’t remember. He was not someone I can recall dealing with. All the material I have gone through to prepare for this session – I mean, his name has obviously come up in the context of these proceedings, but I don’t recall his name being on any of the PinICLs or any of the AIs, so I wouldn’t have dealt with him. He was in the support group and I wouldn’t have dealt with him – sorry, development group.
Mr Beer: Do you know why he was selected as a person to give evidence as a witness with expertise or as an expert witness on the Horizon System?
Anthony Oppenheim: Well, bear in mind when I left the programme there were people like Terry Austin still there, senior people, more senior, as I understand it, than Gareth but, by the time a lot of this happened, I would have said, from what I have seen, that he was probably the most senior person and was, therefore, designated to act for ICL Pathway, but I don’t know.
Mr Beer: Are you aware of a practice where, in the course of a prosecution of a subpostmaster for theft and/or false accounting, a request was made for data by them about the operation of the Horizon System and, by then, Fujitsu representatives asked for payment for producing the documents that the individual requested?
Anthony Oppenheim: No, I’m not aware of that and I would have said that was wrong.
Mr Beer: “Wrong” because it would be in breach of the contractual obligation to provide the data or the evidence?
Anthony Oppenheim: Well, wrong for that reason and wrong morally, as well, I would have thought.
Mr Beer: Can I turn to AI (Acceptance Incident) 376 and the cash account discrepancies issue. Can we look at this issue, and this forms a large part of the evidence in your witness statement, so I’m going to spend some time on it.
Can we start, firstly, by explaining to those who don’t know what a AI is?
Anthony Oppenheim: An Acceptance Incident. So the codified agreement requires that we run a trial, a live trial, for a period of three months on 300 post offices, at the end of which there would be, basically, an Acceptance Review.
Mr Beer: Just stopping there, because that language may be unfamiliar to non-IT professionals: an Acceptance Review?
Anthony Oppenheim: Okay, so an Acceptance Review would be, basically, that POCL would have looked at the system, looked at the data, looked at basically everything they could look at and determine if it was working according to the specification, or the requirements, so was it working properly, or were there defects and, if there were defects, then how serious were the defects. And there was a classification grid, if you will, of A, B, C severity defects and we were allowed so many As, so many Bs, so many Cs – in fact, we weren’t allowed any As, we were allowed up to ten Bs, from memory.
Mr Beer: Zero As, ten Bs.
Anthony Oppenheim: Ten Bs. So, basically, it was a granular review of the performance of the system, as I say, across 300 post offices and three-month trial period.
Mr Beer: So the “acceptance” in the phrase “Acceptance Incident” refers to acceptance by Post Office?
Anthony Oppenheim: Acceptance by Post Office, correct, and an incident obviously means that something was wrong, it was an incident, a bit like an incident as it would be reported from a – again, an operational standpoint.
Mr Beer: So with that helpful introduction, can we look, please, at AI376. That is POL00043691. Can we turn to page 57. Thank you. I’m just going to spend a little bit of time on this because this is the first time the Inquiry, I think, has seen an Acceptance Incident form.
You can see in the top left-hand corner that it is described as an “Acceptance Incident form”, yes?
Anthony Oppenheim: Yes.
Mr Beer: Then on the right-hand side, the Acceptance Incident number is included. This one is 376.
Anthony Oppenheim: Yes.
Mr Beer: Are those numbers generated by ICL?
Anthony Oppenheim: You mean the incidents?
Mr Beer: Yes.
Anthony Oppenheim: They have been raised by TIP. TIP is POCL, so what would have happened there is ICL Pathway would have transferred data, which would have come from the branches into the correspondence servers, moved into our so-called TMS system and, from there, transferred to TIP, and TIP would have compared, in this case, two sets of data and would have identified that they were inconsistent with the cash account.
Mr Beer: My question was much simpler, I think. It was: who attributes the number on the top right-hand side, 376?
Anthony Oppenheim: Oh, I’m sorry. I think that was POCL. The Acceptance Incidents were, as I recall, recorded and flagged by POCL and they led to the AI workshop that we were talking about.
Mr Beer: How did they generate Acceptance Incidents, POCL?
Anthony Oppenheim: I’m not absolutely sure. I mean, they would have identified, if you like, a bundle of similar problems, errors, like these 821, 822, et cetera, et cetera, and they would have recognised that they were all of the same ilk, put them together. We might have called that a problem under normal operational conditions, when you have similar things producing similar bad outcomes, so we would look at that as a problem and, in this context, they were examples of this particular Acceptance Incident, which was designated 376 and we had 218 and others as well.
Mr Beer: Hundreds of them, yes.
Anthony Oppenheim: I’m not sure there were hundreds, but – but logically, with 376, I suppose there must have been, yes.
Mr Beer: Yes. My question again was more basic. How did they physically generate a new Acceptance Incident? So not why would they do it –
Anthony Oppenheim: I don’t know.
Mr Beer: – or what would cause them to do it.
Anthony Oppenheim: I don’t know.
Mr Beer: Would they pick up the phone and say, “We’ve got a series of problems, they are as follows, please generate a new Acceptance Incident”, or could they create this form?
Anthony Oppenheim: They would have created this form. Martin Box –
Mr Beer: I’m sorry?
Anthony Oppenheim: Sorry, they would have created this form. The facility was this form, which they would then fill in, as they have done here. Martin Box is the same Martin Box I recognise from that PinICL that we talked about earlier.
Mr Beer: So are you saying that Martin Box drafted the form?
Anthony Oppenheim: No, we would have agreed the form between us. I can’t remember who instigated it, whether it was them or us, probably POCL, and then they would have populated it and then we would have responded to it.
Mr Beer: So you think that somebody from POCL could get into the system that maintained Acceptance Incident forms and write text into them?
Anthony Oppenheim: Absolutely. This would have been their form, not our form.
Mr Beer: So this is a POCL form, not a –
Anthony Oppenheim: Yes.
Mr Beer: – ICL form?
Anthony Oppenheim: Yes, yes. It was POCL who raised the Acceptance Incidents and we had to deal with them. Correct.
Mr Beer: So we will see that the second box down to the left, the acceptance test name is “TIP Interface”. What does that mean, “Acceptance Test Name”?
Anthony Oppenheim: Sorry, where is that?
Mr Beer: Second box down on the left-hand side, underneath “Acceptance Form” it says “Acceptance Test Name”?
Anthony Oppenheim: Yes, TIP interface, right. So this is what I was trying to describe before, so there’s a daisy chain of data transfers –
Mr Beer: Just stopping you there, I’m not asking about the TIP interface, I’m asking what an “Acceptance Test Name” is?
Anthony Oppenheim: Well, it simply identifies where the problem occurred.
Mr Beer: Okay, so this is locating within –
Anthony Oppenheim: Yes.
Mr Beer: This box is locating in generic terms where in the system the problem exists?
Anthony Oppenheim: Exactly.
Mr Beer: “Source”, box 3. So you see after all of the boxes there is a number in parentheses, and I’m going through them in order. I think each time you are diving down into box 10. I’m just taking this very slowly because you are our first witness on this. What does “Source” mean?
Anthony Oppenheim: Well, the person who would have spotted the problem, so this was, I think, POCL’s business support management, I think.
Mr Beer: Then the “Date Observed”, in this case, 19 July.
Anthony Oppenheim: Yes.
Mr Beer: Box 5, “Witness/Reviewer who observed Incident”, and you have said already that Martin Box was a POCL employee.
Anthony Oppenheim: Yes.
Mr Beer: “Authority” in box 6, what was that authority for or about?
Anthony Oppenheim: I can’t recall. I really don’t know.
Mr Beer: And box 7, the “Incident Type”. Can you tell us the difference between “Criterion not met” and “Substantive fault”?
Anthony Oppenheim: (Inaudible).
Mr Beer: I’m sorry?
Anthony Oppenheim: I would say no, I can’t. I could guess at it, but these were determined by POCL not us. There would have been discussion about them but there was very often something of a disagreement between us as to how severe a given AI was. I mean, there was some debate about that. It wasn’t an acrimonious debate but there was a debate. We would always, obviously, prefer something to be less serious and they would sometimes, you know, argue that it’s more serious than we really thought it was.
Mr Beer: Why would you obviously want something to be less serious? Surely you wanted to do the accurate thing?
Anthony Oppenheim: Absolutely right, but there was a question – if it had no impact on the integrity of the system, then it should be classed as a C category and then it could be swept up, dealt with and released in the next release.
If it’s an A, it’s a show stopper, you can’t go forward, you have to identify it and fix it as an emergency update, in effect, before doing anything else.
If it’s a B, again, it sits somewhere between the two, so you really need to determine the impact or potential impact of whatever it is that’s been flagged as wrong.
Mr Beer: You have already addressed box 9 on the right-hand side. Can we move to box 10, the “Description of the Incident”. As this is our first AI, I’m going to read it as a whole:
“Description of incident
“New Description: AIS contravention/Data integrity – derived cash account not equal to the electronic cash account. Incidents …”
Then there are a series of TIP numbers given:
“… have been raised by TIP in respect of all transactions that constitute a cash account have not been received by TIP or when electronic cash accounts received where transactions that have been conducted and received by TIP are missing from the respective cash account lines. These issues have come to light when comparing a TIP derived cash account with the electronic cash account sent by Pathway. Not all instances of similar occurrences have been logged by TIP as the physical resource to check each occurrence of a difference within the derived versus the electronic is not available. It was expected that this facility would by now be comparing like with like. This is very significant. Missing transactions and missing cash account line entries cause reconciliation failures within POCL back end systems and error resolution is invoked. The cash account produced by the Organisational Unit in these instances must be in doubt and is not a fair reflection of the business undertaken at each Organisational Unit. A subpostmaster may be asked to bring to account an error, but the error was produced via system failure rather than human failure. Many hours of investigation at both the front end and back end have taken place to help resolve these problems. The benefits assigned to POCL back end system in respect of an automated cash account are being questioned.”
So, just looking at that text for the moment, you will see that, about ten lines in, the author, whoever it was, says that the incident that they are describing is very significant. Would you agree with that?
Anthony Oppenheim: Yes, I would.
Mr Beer: Why would you agree that, at this stage, the incident was very significant?
Anthony Oppenheim: Well, for all the reasons set out in that long paragraph. There’s nothing I would disagree with in there.
Mr Beer: It’s very serious because what is described undermines not only the very purpose of the system, it means that the system lacks integrity, it lacks veracity and it lacks reliability, doesn’t it?
Anthony Oppenheim: At that point, 19 July, summarising things that have been found up to that point, yes. That position was untenable and there’s no way we could have gone on and we didn’t.
You then need to look at what actually transpired after that.
Mr Beer: We’re going to spend the next two or three hours, I think, doing that.
Anthony Oppenheim: Okay, fine. But yes, this was a show stopper and I would have had it down as substantive or whatever – this is a category A. I mean, there’s no doubt about it.
Mr Beer: Reading on just after the sentence “This is very significant”, the sentence:
“The cash account produced by the Organisational Unit in these instances must be in doubt and [it] is not a fair reflection of the business undertaken at each Organisational Unit.”
That’s one of the reasons why the issue is very significant, isn’t it?
Anthony Oppenheim: Well, it’s one. It’s also – it then goes on to talk about the impact on the branch and the subpostmaster, so this is, as I said, an absolute show stopper. You’ve got to then look at actually what caused the problems and what was done about them.
Mr Beer: Put in blunter language, that sentence means that it’s not a fair reflection on the subpostmaster because the system is showing a false balance?
Anthony Oppenheim: It is, that’s absolutely right, which is why this needed to be looked at in significant detail.
We had only recently – this was summarised 19 July – only recently really got going with interfacing with TIP on EPOSS transactions. Most of the previous effort had been on the Benefits Agency up until June of 1999. It had been virtually all Benefits Agency, no EPOSS transactions all, so all of the 200, as they were, post offices running Child Benefit in the North East and South West were only doing Child Benefit and order book control.
So this was new and it was, you know, clearly a show stopper, as I say. The question was what was done about it and where did we end up.
Mr Beer: The next sentence:
“The cash account produced by the Organisational Unit …”
You have referred to the branch. That’s another way of referring to the branch, yes?
Anthony Oppenheim: That would be my interpretation. It’s not a term I’m familiar with.
Mr Beer: I will read it as branch for the moment:
“The cash account produced by the [branch] in these instances must be in doubt and [it] is not a fair reflection of the business undertaken at each [branch].”
Then:
“A subpostmaster may be asked to bring to account an error, but the error was produced via system failure rather than human failure.”
That sentence there in a single sentence describes one of the main issues being investigated now, doesn’t it: the Horizon System created the balancing errors by the way that it operated, but suggested that the balancing error was that of a human and not a computer?
Anthony Oppenheim: That was the case then. To what extent did that continue to be the case after all of the remedial work, that – that would be, for me, the key thing, but at this stage it’s a bad indicator, I agree.
Mr Beer: Although the wording of that sentence about accounting is perhaps a little opaque, would you agree that what is being suggested is that a subpostmaster may be asked to account for an error, even though it was not his or her error?
Anthony Oppenheim: Yes.
Mr Beer: Would you understand that “account for” doesn’t just mean provide an explanation for, it means, in context, paying for it or facing the consequences of not paying for it?
Anthony Oppenheim: Yes, and I would simply add “and POCL knew that”, which is – goes to my earlier remarks about their knowledge, that there were, at this stage, unacceptable errors to the point where it shouldn’t rollout, hence the AI process, and subsequently that there was still always going to be a risk that such a thing could occur and it would need to be investigated.
Mr Beer: Moving on, if we scroll down please:
“Severity: POCL – high – would effect POCL’s ability to produce an accurate cash account.”
So POCL are describing the severity of the incident as high:
“PWY [that’s Pathway] – accept the problem exists. Would argue about the severity – would it genuinely affect the accounting integrity as it currently [stands]?”
You have told us this morning that, on the basis of the earlier text, this was “a show stopper”, the point was “made the system untenable”, it was a fundamental issue and was undoubtedly high. Do you know why Pathway are recorded as saying they would question the severity and were asking –
Anthony Oppenheim: I think the –
Mr Beer: – “would it genuinely effect accounting integrity”?
Anthony Oppenheim: So we’re now going back 20-whatever years. I can’t defend the proposition that it should be anything other than a major, high severity fault. I think it – I can only assume that there was an assumption there wouldn’t be very many of these, we’ve got PinICLs that were being fixed and that when those had been fixed – we understood, in other words, the nature of the problem and when they had been fixed that would resolve the problem. Now –
Mr Beer: That’s a different way of looking at it, isn’t it?
Anthony Oppenheim: Well, it’s –
Mr Beer: – as I think you know, Mr Oppenheim. This isn’t saying “We can fix it in the future”, or “We’re developing a fix for it and therefore when that takes effect the severity might be downgraded”; this is at the point of reporting, saying that Pathway were questioning or arguing over the severity, isn’t it?
Anthony Oppenheim: All I can do is give you a view as to the way that my colleagues would have thought about this. So when Steve Warwick says “We understand this, we’re on top of it, we’ve got a fix or fixes in process and there’s a substantive software update in process that will deal with this”, I can imagine they would say, “Look, we’re onto it, it’s not going to be a problem, or not a serious problem, we think it’s a medium-sized problem”, and that would be my interpretation. But it was wrong to assert that, given the facts as they were at that point. I do agree with that.
Mr Beer: Thank you. Moving on, it says:
“Rectification: Steve Warwick …”
He was an ICL employee?
Anthony Oppenheim: Yes, he led the development of the EPOSS team.
Mr Beer: “… to provide rectification of this issue. [Pathway] understand the problem and are currently working on the fix. Steve Warwick to provide details.”
Just stopping there at the moment, and without looking forwards to what happened at the moment, would you agree that if you were a subpostmaster accused of stealing thousands of pounds from the Post Office, and you believed that you had not done so and instead the Horizon System was faulty and was responsible for the imbalance shown, and you were before a criminal court, you would wish to know about this document here, wouldn’t you?
Anthony Oppenheim: What I would say is I’m not sure who Pathway was in this instance. There are no names given other than, at the bottom, Steve Warwick, so I don’t know who asserted that – this argument about severity and, without knowing that, I can’t really answer. I would say it was not representing Pathway because, when it came to the AIs, I represented Pathway and we accepted that this was a high severity issue, so this was on the way to getting there.
I’m not going to excuse it. I don’t agree with it but I don’t know who it was that expressed this view. It would have been at a low-level.
Mr Beer: Putting the issue of the classification of severity to one side, but just looking at the document itself, if you were a subpostmaster accused of stealing thousands or tens of thousands of pounds, and you believed that you hadn’t done so and that the system was responsible for the imbalance shown, you would want to know about this document here, wouldn’t you?
Anthony Oppenheim: Very likely you would. The point about the possibility of error goes to what I was saying earlier, that one would need to look in detail, before mounting a prosecution, at what had actually happened, what had actually gone wrong. This was very, very early, is the point I would emphasise.
I don’t agree with the proposition by whoever it was in Pathway that it would be low severity – I know you suggest that it should be put to one side, but the point is that it triggered a massive amount of work subsequently, on both Pathway’s side and also Post Office’s side because one of the problems was, as you referred to earlier, was reference data. So reference data errors were the reason for quite a lot of these mistakes.
Mr Beer: Can we move to box 11 and display a little bit more of that, please. We will see that box 11 has not been completed. It’s a little difficult for me, at least, to understand who is supposed to complete what here. Under the first box underneath “Signatures”, “Witness/Reviewer”. From which organisation would you believe that the witness or reviewer would come in order to complete that box?
Anthony Oppenheim: POCL.
Mr Beer: The “Horizon Acceptance Test Manager”, from which organisation did that person come?
Anthony Oppenheim: That would be Pathway, I think.
Mr Beer: Then, on the right-hand side, it’s got “Pathway”. Do you know what or who was supposed to complete that box?
Anthony Oppenheim: I don’t. My guess is it would be the – when we came to the AI resolutions, the person designated as lead for a given AI.
Mr Beer: Then, on the far right-hand side, “AIM”. Do you know what that refers to and who would sign and date that box?
Anthony Oppenheim: Sorry, no, I don’t.
Mr Beer: Underneath – underneath the dates, that is – the “DSS Acceptance Manager”. In July 1999, did the DSS acceptance manager have any role to perform?
Anthony Oppenheim: No.
Mr Beer: Is that a relic?
Anthony Oppenheim: This is a relic. This was a form that was devised prior to the DSS dropping out. Bear in mind this was dated July and they only dropped out in May/June.
Mr Beer: “POCL Business Assurance”, on the right-hand side. Do you know who or what that refers to?
Anthony Oppenheim: I can only assume that it was someone in POCL who was looking over the shoulder of the people we were dealing with.
Mr Beer: Then, lastly, on this page, I think a date for entrance into an acceptance database. What was the acceptance database?
Anthony Oppenheim: We had an Excel spreadsheet which listed all the AIs, but I – that’s the only one I can think of that was a database and it tracks day by day every movement and the status, so I’m assuming that’s what it would be.
Mr Beer: So if, in future, any person, whether they are a prosecutor, a defence lawyer or a court wished to examine whether there were issues – to use a neutral term – with the reliability or integrity of the system in its design, implementation and rollout phases, could look at an acceptance database, for example, to see whether such issues were recorded there?
Anthony Oppenheim: So the acceptance database, I know, dealt with the As and Bs and there was reference to the Cs but I don’t think it went into detail around the Cs. At least, it was a level of – if it did exist – probably did – it’s not something that I ever focused on, but the As and Bs definitely and I think that’s probably what we’re concerned with here.
Mr Beer: So, in answer to my question, there would be a ready catalogue of issues –
Anthony Oppenheim: Yes.
Mr Beer: – that such a person could look back on.
Anthony Oppenheim: Yes, certainly the formulation of – this is specifically the Acceptance Incident process, the workshop process. That was all very, very carefully documented and I have seen in my review of the papers I have seen examples of that. I think I got them from Fujitsu, rather than yourselves, but I think I referred to them in my witness statement. If not, I can share them with you.
Mr Beer: Can we go to the second page of the AI, please, so scroll down. We can see in box 4 “Analysed Incident Severity”, “High/Medium/Low”; that should be completed, shouldn’t it?
Anthony Oppenheim: It says in the second box “Low”, so –
Mr Beer: Yes, so this is read in the context of the page before, the reporting of the incident severity, and then this is after analysis; is that right?
Anthony Oppenheim: I –
Mr Beer: Do you remember the previous page?
Anthony Oppenheim: I’m just thinking, sorry. I think that must be logically the case.
Mr Beer: And analysed by who?
Anthony Oppenheim: If this was Fujitsu’s response – sorry, ICL Pathway’s response, which I assume it is, it looks like it, then does it have a name at the bottom? Would it be Steve Warwick?
Mr Beer: No, the form – well, there is a name at the bottom in some of the boxes of somebody called John Pope.
Anthony Oppenheim: Okay, John Pope was the analyst who worked for John Dicks, who you may recall from the organogram, and he was one of those charged with the resolution of these AIs, so he was somebody I worked closely with at the time and he would have gone through with the Steve Warwicks of this world to determine what, you know, the position was. He would have analysed the data.
Mr Beer: Does it follow from the answers that you gave earlier that you would fundamentally disagree with the analysis that the severity of the incident was low?
Anthony Oppenheim: I did say earlier, in fairness, as I recall, that one needs to look at what happened subsequently and this is what happened subsequently. I’m sorry I didn’t remember. So here he is saying that:
“There is no suggestion or indication that there is a fault in the calculation or reporting of the Cash Account …”
Mr Beer: Just before we get to that, you are reading from box 6.
Anthony Oppenheim: Yes, I am.
Mr Beer: Let’s read that together:
“Pathway has analysed all occurrences where the (TIP) derived cash account does not equal the actual cash account … There is no suggestion or indication that there is a fault in the calculation or reporting of the Cash Account; the incidents relate to an occasional missing transaction when reporting to TIP. This had a rate of occurrence of [around] 1% of outlets per week based on an analysis of the reported TIP incidents. It is agreed this would have been unsustainably high when considered against a target population of 20,000 outlets.”
So that’s about 200 a week, yes?
Anthony Oppenheim: Yes.
Mr Beer: “The agent modification referred to in previous analyses has been operational since [3 August] and is operating successfully.
“An updated summary of TIP incidents was supplied [11 August] as actioned. As noted the root problem has been diagnosed in all non ‘serve customer’ transactions leaving one further problem under diagnosis relating to occasional scales transactions, which are all in serve customer mode and are corrected by the agent modification noted above.
“In addition Pathway has established routine monitoring for all harvesting exceptions and should any occur will notify them to TIP in advance and has agreed a suitable procedure with TIP, thereby substantially reducing the TIP effort in handling any exceptions.
“POCL has removed the aspect concerning the reference data change from core to non core from this AI and re-raised it as AI410 … In this case there is no fault within the Pathway system. Pathway has proposed an approach to POCL to avoid this problem through the use of product types within RD”, within reference data.
So can you to a naive audience translate what perhaps Mr Pope has written?
Anthony Oppenheim: Okay, so going back to what was stated at the beginning, that was a very – you know, a very unacceptable – it was an unacceptable position, if confirmed. So if the cash accounts were going wrong, then that was unacceptable. What this is saying is that the cash accounts weren’t going wrong but there were problems with “harvesting” all the transactions and reporting them faithfully to TIP. Transactions are needed by TIP for them to reconcile the – for Post Office to reconcile with their clients. So it’s very important that they all be complete.
Why would some be missing? Because there was a problem with one of the agents, so an agent modification was put in place 3 August. Now, what –
Mr Beer: What’s an agent modification?
Anthony Oppenheim: An agent – an agent basically looks at the data in the – I think the correspondence server, or it could be the branch, I’m not 100 per cent sure, and it pulls that data into the database, into TMS. TMS is transaction management system, which was ICL Pathway’s database that then transferred the data to TIP. So, as I said, this is something of a daisy chain which operates remotely in a world before the internet, when dial-up modems were still, you know, standard.
So you had an ISDN link, had to get the data from the branch to the central data warehouses and then make sure that they were converted into the format that TIP required and we were operating to a draft specification for the TIP interface still, at that stage, by the way, and TIP would sometimes struggle, let’s say, with what was being sent across.
Now, the agent is what sucks in all of that transaction data and there had clearly been a problem which required a modification. The modification had been applied on the 3rd of the 8th, which wasn’t that long after this AI had been raised –
Mr Beer: 19 July.
Anthony Oppenheim: 19 July. So as it said at the bottom of the original paragraph, Steve Warwick’s got a bug fix in process on this issue, which, as I said, I think is why he thought it wasn’t going to be such a big deal.
As reported as a possible, it would have been a big deal. This says, actually when you look at the detail, the cash accounts were okay but there was a problem with harvesting individual transactions, which would have been an issue for the Post Office reconciling with its clients in a timely fashion.
So that’s the most of it. The bottom paragraph:
“POCL has removed the aspect concerning the reference data change from core to non core …”
That was included in the numbers that had been considered at the outset but it was a very particular problem that occurred back in June I believe.
Mr Beer: June 1999?
Anthony Oppenheim: June 1999, which I referred to earlier as being a reference to the first of the reference data PinICLs that we flagged and this had to do with, as I recall, sign change. This will probably come up again later, whereby there’s a convention around signage, plus or minus, and if you get it wrong you get an error times two, in actual fact. You don’t actually nullify it, you just get it the wrong way round, so instead of adding it you subtract it and that’s going to throw out a cash account and that’s potentially very serious, but all of that is driven by reference data.
Should I just describe what reference data –
Mr Beer: No, we know what reference data is.
Anthony Oppenheim: You know what that is.
Mr Beer: Thank you. Can we move down the AI, please, and a bit more please, thank you. “Clearance Action”, block 7:
“The fix to reconstitute missing transaction attributes was introduced [3 August]. Pathway confirms that at the time of completing this analysis no further missing transactions have been noted to date by Pathway internal monitoring.
“Subject to satisfactory processing by TIP of the cash account for week 19 in line with the reduced incident rate proposed by Pathway, and with the above procedure in place to notify any exceptions, Pathway assess the severity of the incident as ‘low’.
“Ongoing monitoring for the next three months should progressively reduce occurrence to a maximum of 0.1 per cent at which point the incident be closed.”
Mr Pope has written his name – or his name is written next to “I propose the clearance action and incident status described above”, incident status “Resolved”, 11 August 1999. So is that essentially Mr Pope signing this AI off as resolved, three weeks after the AI had been opened?
Anthony Oppenheim: He is proposing that it should be regarded as resolved, but it can’t be resolved without the agreement of the Post Office.
Mr Beer: Where should we see their signature?
Anthony Oppenheim: Does it not go on?
Mr Beer: Yes, so underneath “I accept/reject”, can you see that?
Anthony Oppenheim: Yes.
Mr Beer: That’s where we should see –
Anthony Oppenheim: So that’s where you should see a rejection by POCL.
Mr Beer: So the proposal was from ICL Pathway that this can be cleared in three months’ time if incidents progressively reduce to an occurrence of a maximum of 0.1 per cent. Is that 0.1 per cent per week –
Anthony Oppenheim: Yes.
Mr Beer: – per cash accounting period?
Anthony Oppenheim: Yes, it would be. And I’m guessing the reason that there’s no corresponding POCL signature is because who is to say whether it was going to be achieved, this 0.1 per cent proposition, within three months. At the point where this was written, no one would have known that.
Mr Beer: What do you say to the suggestion that a three month monitoring period was shortsighted or ill-advised when the national rollout was yet to commence and so the sample size was small?
Anthony Oppenheim: So the – the sample size was increased by 1,800 in the period September/October 1999, so by the end of the three-month period you were up at 2,100 from memory. So it was a decent sample size and it was a very good thing that the 1,800 were rolled out because it gave a lot bigger sample size and a lot more feedback. It also exercised, in earnest, the reference data system, which had been subject to a freeze for a period and that was possible when you weren’t adding post offices. As soon as you add post offices you have to add new reference data because you have reference data by post office, so you couldn’t freeze it. There had been a moratorium because there had been these reliability issues.
So I personally think a sample size of 2,100 for three months is not unreasonable.
Mr Beer: Do you read this as meaning that after the end of that three-month period it would be acceptable for the full Post Office estate, some 19,000 or 20,000 branches, for the system to continue to operate at an error occurrence rate of 0.1 per cent?
Anthony Oppenheim: If POCL felt they could manage it, because it was not affecting the cash account, subject to that condition I would say yes because, as I said, the practical reality was we were dealing with 25 years ago technology to gather millions of transactions a day and you’re going to get some glitches. Just anybody in – on you know, involved in that programme must have realised on both sides of the fence. So you have to allow for that possibility. You can’t have 100 per cent SLAs and zero incidences of failure, that’s just not the real world I’m afraid. The question is, what you do about it and how you contain it, how you flag it, how you protecting stakeholders when this does happen.
Here, this is not an error. This asserts, in this, there’s no errors in the cash account, and there would be errors in the cash – but that’s a different matter.
Mr Beer: Can I draw your attention to another document, please, POL00083922, at page 5, please, and if we can just enlarge that, please, because it is on a fax and therefore has reduced in size a little. I wonder whether we can display two documents at once, so keep that one and look at the document we were just looking at which was POL00043691 at page 57. Then try and highlight – thank you very much.
The document on the right we can see is another copy of AI376, can you see that?
Anthony Oppenheim: Yes.
Mr Beer: We can broadly see, certainly in box 6 – sorry, on the page on the right can we go back a page, please, and then highlight the relevant section. Thank you.
We can broadly see that they are the same, if you just look at the data on the left-hand side and the right-hand side.
Anthony Oppenheim: Yes. In fact, I think they are the same, aren’t they?
Mr Beer: They are identical. There are some colour differences or shading differences.
Then if we scroll down both of them, please, we can see that the data within them is the same, yes?
Anthony Oppenheim: Yes.
Mr Beer: Then if we go over the page for both of them, please, we can see that box 4 is different. It says “Medium” rather than “Low” and box 6 is entirely different. It has just got completely different text in it.
Anthony Oppenheim: After “20,000 outlets”, yes. So one looks like an update on the other. Firstly, there’s a causal analysis – there are two causes.
Mr Beer: Yes, if we read that:
“There are two causes.
“very occasionally a transaction is recorded at the outlet with a missing attribute (start time or mode). The processing rules specified for the TPS harvester reject any transaction which has a missing attribute, meaning these transactions are not forwarded to TIP. They are however, correctly posted in cash accounting processing.
“The harvester specification is being modified to (i) reconstitute any missing start time attribute by interpolation from immediately preceding transactions within the customer session, or (if none is present) to log an event and (ii) map any …”
I think “full mode”?
Anthony Oppenheim: “Null”.
Mr Beer: “null mode”, thank you:
“… attribute to ‘serve customer’ attribute.”
I will skip the next bit:
“Pathway will monitor occurrences of any such null attributes and work will continue to ensure that all transactions are correctly recorded with all attributes at the outlet. This will eliminate this problem; it is theoretically possible that a very occasional transaction will result with an invalid item transaction mode, although there has been no instance of this detected in any of the analysed cases.
“[Second cause] on one occasion a reference data change from core to non core and the new Reference Data mapping of products to Cash Account may cause transactions conducted within the [Cash Accounting Period] prior to the [Reference Data] change not to be posted to the Cash Account. In this case there is no fault with the Pathway system. Pathway has proposed an approach to POCL to avoid this problem through the use of product types within RD.”
That last sentence bears some similarity to what had happened – what was described in the document that I showed you earlier.
Can you explain, please, is this how these forms worked, that there could be something written in one version of an Acceptance Incident, that could be deleted, and then something new could be written into it, rather than a progressive, chronological account of the development of the problem and the solutions to it?
Anthony Oppenheim: I am surprised to see this. I would have expected exactly what you have just described.
Mr Beer: Why are you surprised to see it?
Anthony Oppenheim: Because the documents I looked at – I didn’t go through all of these. I went through the Excel spreadsheets that I was describing earlier which are the – you know, the register – and those showed day by day, sequentially, everything that happened, who said what, what actions have been taken, what actions were placed, who responded to what actions, how, on both sides, because these were joint activities.
So there was no question there of anything being wiped or written over –
Mr Beer: Deleted or overwritten?
Anthony Oppenheim: Exactly, no question at all. I am surprised to see this here, I must admit.
Mr Beer: Then if we can read on in both documents down to the clearance.
Thank you, and then on the right-hand side, thank you. Just a bit more, thank you.
I think we can see that there’s a different clearance action in this document. We can see that it is signed off by Mr Dicks himself.
You remember that, under the document I showed you earlier, the proposal of acceptable occurrence was 0.1 per cent per week over a three-month period. This proposal was that the relevant period would be a single cash accounting period, I think that’s one week rather than three months, yes?
Anthony Oppenheim: Yes, I’m reading this, I think, for the first time.
Mr Beer: You’re just catching up, okay.
Anthony Oppenheim: Yes, I’m not familiar with this one, I don’t think.
(Pause)
Anthony Oppenheim: So the conclusion – the proposition for what it should be is still the same “Ongoing monitoring for three months … 0.1%”, so that’s no different. But this was clearly an interim position as at 9 August, which was then replaced on 11 August. Now, I don’t know whether the version as at the 9th was shared with POCL.
It’s possible that the reason it was overwritten, as you say, is because it hadn’t been shared, so events have moved on, the bug fix had been applied, it had been successful, whereas on the 9th it was still a work in progress, so that’s the best I can do by way of explanation, I’m afraid.
Mr Beer: In the Clearance section, it says:
“For ongoing monitoring, Pathway believe a target maximum occurrence due to this cause for the next [Cash Accounting Period] should be … (0.67%) at which point the incident should be reduced to Medium.”
Then the ongoing monitoring at 0.1 per cent, “at which point the incident should be closed”.
Anthony Oppenheim: So that implies to me that it was viewed by POCL as high. John Dicks was saying “We have made good headway here, we think it’s now already medium” and, if it proves – if events prove over the next three months that it actually has pretty much gone away and POCL are happy with 0.1 per cent, then it should be closed. That’s my interpretation of this.
Mr Beer: Is that a practical demonstration of ICL considering the cash account discrepancies to be less severe than POCL?
Anthony Oppenheim: No, this isn’t, as I said, to do with the cash account. This is to do with these attributes, these missing attributes and the fact that TIP would reject transactions with missing attributes. That’s why TIP was missing transactions and those transactions had been included in the cash account, is what this makes clear, and there was, as I understand it, no argument about that.
That’s not to say there weren’t other issues, but not in relation to this.
Mr Beer: Okay, we can take both of those documents down from the screen now. Can we turn to what was happening in the midst of this, namely the signing of the first supplemental agreement and look at FUJ00000485. Can you see the date of the first supplemental agreement, 20 August 1999?
Anthony Oppenheim: Yes.
Mr Beer: Can we just read the preamble together, so under “Recitals”:
“This Supplemental Agreement is supplemental to the Codified Agreement between the parties dated 28th July 1999 …
“The Contractor and POCL have been carrying out the Operational Trial and the other Acceptance Procedures in accordance with the Codified Agreement.
“It is agreed that as at the end of the CSR Operational Trial … Period … there were …”
Then if we just scroll down please so we can see them all:
“9 faults (the ‘Agreed Category B faults’) which both parties agree are medium …”
Then they are listed.
“3 faults (the ‘Disputed Category A Faults’) which the Contractor [that’s Pathway] considers to be category (b) faults but which POCL believes are high severity (category (a)) faults …”
They are listed and amongst them is 376. So is it fair to say that at this date, despite what we had read in the AIs of 9 and 11 August, by 20 August there remained a dispute about the severity of AI376?
Anthony Oppenheim: Yes.
Mr Beer: Was that relatively common during the resolution of the AIs because, in part, ICL were permitted no category A incidents and, as you said, only ten category B incidents and, upon which classification acceptance turned and therefore payment to ICL turned?
Anthony Oppenheim: So relatively common, no. They were exceptional. There were three where we didn’t agree and if I may, on 376 there was no disagreement that if the cash account was going to be wrong, that that was a serious issue. The reason that ICL Pathway considered it not to be their serious issue is because they attributed most of the problem to reference data which came from POCL. So that was – if you just go back to the bottom paragraph of the previous report, it was saying “This is excluding the reference data issue”.
The reference data issue was really serious because that would have caused a cash account problem, but ICL Pathway’s position, certainly at the technical level, was “This is not our problem”.
Now, at my level it’s a problem because the end result is going to be wrong for the collective and – you may come on to this later – John Bennett wrote in, I think it was early November, to David Smith about this very issue and he more or less said “Unless you can fix it with us, we can’t do it on our own, we’re going to have to stop rollout”. That was ICL Pathway to POCL on reference data.
Mr Beer: Just on the issue of there only being three disputes, I think we can see underneath there were two faults which were disputed category B faults.
Anthony Oppenheim: Okay, point taken.
Mr Beer: Which the contractor considered to be low but which POCL believed to be B and then over the page, more dispute – so there were two of those – and one fault which ICL believed isn’t an Acceptance Incident at all but which POCL believed is a category B fault.
Anthony Oppenheim: I stand corrected, there were six disputes out of, as you pointed out, scores and quite possibly hundreds –
Mr Beer: Six disputed faults?
Anthony Oppenheim: Yes. I don’t regard that as common out of so many when so much was moving and it was acknowledged that there was a disagreement and, ultimately, we accepted that we hadn’t passed, hence the supplemental agreement.
Mr Beer: Can we just move on over the page, please, to paragraph (D) of the preamble:
“It is agreed that there is no CSR Acceptance Specification in respect of which there are more than 10 category (b) faults.”
Just explain what that means?
Anthony Oppenheim: If there are more than 10 category B faults then we fail.
Mr Beer: So it was recording the agreement that there were not in excess of 10?
Anthony Oppenheim: Yes.
Mr Beer: Then if we can read down, please, to the agreement itself after the preamble, at 1.1 under “CSR Acceptance”:
“The parties agree that CSR Acceptance was not achieved as at the end of the CSR Operational Trial Review Period.”
Anthony Oppenheim: That’s what I just said, absolutely. We accepted that.
Mr Beer: So it was agreed that the core system didn’t meet the acceptance criteria at the end of the operational trial?
Anthony Oppenheim: Correct.
Mr Beer: As we will see after lunch, I think, when we look at pages 7 and 8 of this document, there was, nonetheless, a timetable for new installations to be ramped up in post offices; is that right?
Anthony Oppenheim: There was and I alluded to this earlier. Part of the logic for that was that we needed a bigger sample size, to your point about 200 not being really sufficient – or was it 300 by then? And we needed the experience of the rollout process itself because migrating data from existing paper-based system to the new system, that of itself could generate problems.
So we needed to really test our abilities, jointly with Post Office, to roll this thing out without hitting a wall and that was the proposition – that happened in October/November – sorry, September/October/November, such that we would then have a period of time before January resumption of rollout to fix things that were found. That was the thinking.
Mr Beer: Sir, I wonder whether that’s an appropriate moment to break for lunch. It is for me.
Sir Wyn Williams: Yes, I think it is.
I’m sure you are aware, Mr Oppenheim, but you shouldn’t discuss your evidence while you’re having your lunch. I’m sure you don’t want to but I’m obliged to tell you that.
Anthony Oppenheim: Thank you, sir. Yes, I’m aware of that.
Sir Wyn Williams: All right, 2.00, everyone. Thanks.
(1.00 pm)
(The luncheon adjournment)
(2.00 pm)
Mr Beer: Good afternoon, sir, can you see and hear me?
Sir Wyn Williams: Yes, I can, thank you.
Mr Beer: Thank you, and likewise.
Mr Oppenheim, we were just dealing with the preamble to the first supplemental agreement which was at FUJ00000485. We had gone through the preamble and I think we had identified that there were some 15 outstanding faults, of which six or so were disputed. Can we go forwards, please, to page 7 of this document. Look at the foot of the page, can you see the heading at the bottom “Rollout”?
Anthony Oppenheim: Yes, I can.
Mr Beer: Then if we go over the page, the parties agreed in paragraph 4.1 that:
“… rollout shall not commence until authorised by the Release Authorisation Board in accordance with paragraph 4 of schedule A11.”
What was the Release Authorisation Board, please?
Anthony Oppenheim: This was a joint POCL/ICL Pathway senior management group, which was assembled to make the judgment about whether or not to roll out in the light of AIs and acceptance in general, and anything else.
Mr Beer: Thank you. Paragraph 4.2:
“Notwithstanding [that], the parties agree to install the Core System in additional outlets as follows …”
31 August, Borough High Street, one branch; then 60 branches in the week commencing 6 September; 90 branches in the week commencing 13 September:
“If by 10 September … the parties agree that sufficient progress has been made in resolving the Outstanding Faults (and any other outstanding category A or B [AIs]) the parties may agree to install the Core System in further outlets as follows …”
Then, down the page, please: in the week commencing 20 September, 158 branches; and in the week commencing 27 September, 178 branches.
Anthony Oppenheim: Yes, agreed.
Mr Beer: What would you say to the suggestion that, within a few weeks of the codified agreement being signed, there had been a failure to sign off on the integrity of the core system and yet, nonetheless, there was a planned rollout at scale envisaged by this document?
Anthony Oppenheim: So the driver for this primarily was to increase the sample size, the point that you made, at some point this morning, 200 was judged to be too small, plus there were incidents to do with – or AIs to do with rollout itself, for example training, was it 218? So these needed to be exercised. Now, with the benefit of hindsight, this was too aggressive, too soon and, indeed, as you will show me in a moment doubtless, that was swept away fairly swiftly. But the whole process had started some time earlier, before the codified agreement.
The codified agreement basically codified – hence the term, I think – the memorandum of understanding which was signed in, as I recall, the latter part of May.
Mr Beer: May.
Anthony Oppenheim: And that basically set the roadmap for all the things that had to happen, including the three-month live trial. Otherwise, it wouldn’t have completed in this timeframe.
So looking at the codified agreement in isolation, I agree, it looks like you sign this, you fail then and still you’re going to carry on but, actually, the wheels were set in motion quite some time previously and, in fact, the live trial was in play before DSS dropped out, which is why there was still a reference to the DSS in the Acceptance Incident form.
The nature of the live trial changed and the focus was very much more on POCL. Now, as we recognised pretty quickly, that this wasn’t a sensible thing to do and we agreed to change it.
Mr Beer: Without the benefit of hindsight, could you not see that this was a recipe for disaster, prematurely rolling out a system that wasn’t ready?
Anthony Oppenheim: Well, if it hadn’t have been ready then we wouldn’t have agreed to roll it out, we wouldn’t have been allowed to roll it out and we wouldn’t have wanted to roll it out. But the premise when the supplemental agreement was put together was that a lot of progress had been made, and it had. I mean, the AI we were looking at in detail before lunch showed that what appeared to be a very alarming state of affairs actually was – in respect of the Pathway piece – a much smaller issue – that’s not to belittle it and say it wasn’t of any consequence at all, it was, but it didn’t affect cash accounts.
And so there was a belief that, actually, we were making good progress and, by this future date, we would be – we stood a chance of being in a good place to carry on, to increase the sample size and get more feedback.
Mr Beer: You have said on three occasions, I think, that the purpose of this was to increase the sample size. Is that right, that this was part of an extended exercise to broaden the test bed or was, in fact, this part of rollout?
Anthony Oppenheim: This wasn’t part of rollout, this was – you will find references in various places about the need to increase the size of the operational sample. I can’t pinpoint from memory exactly where those references are, but that was definitely part of the rationale. It wasn’t just to push out a whole bunch of post offices to hit the numbers early.
Mr Beer: In your statement – we need not turn it up, it is paragraph 74 – you say that once the change in commercial terms had been agreed with Treasury, as a result of the withdrawal of the Benefits Agency, both parties, that’s ICL and POCL, were incentivised to proceed as quickly as possible. You say in paragraph 104 that the agreement set an extremely tight timetable and, at paragraph 146, that there was financial pressure on both Pathway and POCL at the time of the rollout.
Bearing those things in mind – incentivisation to proceed as quickly as possible, an extremely tight timetable and financial pressure – do you think the interests of subpostmasters were suborned from the forefront of your company’s mind at this time?
Anthony Oppenheim: I don’t. We readily accepted that we hadn’t hit the hurdle that was required of us and we continued to work on it. We worked on it extremely hard, together with POCL. There were things that weren’t as they should have been and they needed further work.
You asked me a question about the incentives and I answered it honestly in the answer: yes, there were intense incentives but, at the same time, I think I also say the last thing we needed was another false start, given what had happened with the Benefits Agency. So our reputation had taken a hit because it was perceived by many as, really, down to us to have failed in the production of the Benefit Payment Card programme.
Mr Beer: Thank you. That document can be taken down and replaced with FUJ00079169, please. FUJ00079176.
We can see that this is a record of an acceptance workshop held on 17 September 1999 and so over a month after the previous AI forms that we had looked at before lunch. Can you tell us what an acceptance workshop was, please?
Anthony Oppenheim: So an acceptance workshop – that was a workshop which was overarching chaired by Keith and myself and within it each of the AIs was addressed and that process which was written in, I think, two supplemental agreements, or was it in the – yes, in the supplemental agreement – was that we would work jointly through these various issues.
Mr Beer: We can see you’re present at this one.
Anthony Oppenheim: And it is chaired by Peter Copping as expert from PA.
Mr Beer: Yes, we can see that you are present at this one, in the fourth line.
Anthony Oppenheim: Yes, yes.
Mr Beer: The way that this works is it addresses, AI by AI, page by page.
Anthony Oppenheim: Correct.
Mr Beer: I wonder, therefore, if we can go forward to page 6, please. I think at the foot of the page you can see the heading, “AI376 Data integrity”?
Anthony Oppenheim: Yes, indeed.
Mr Beer: Would that be a fair way of describing the issue with AI376, that it was an issue of the integrity of the data?
Anthony Oppenheim: Yes, it’s a fair way to express it.
Mr Beer: Then if we go over the page, please, and then just scroll down a little bit, please, we can see a description on this page of a series of workshops. Are they references to previous workshops that have occurred?
Anthony Oppenheim: Yes.
Mr Beer: Okay, and then if we go over the page please to page 8. Again, reference to further workshops in relation to a different aspect of AI376, yes?
Anthony Oppenheim: Mm-hm.
Mr Beer: Then over the page, please, to page 9 and if we scroll down a little bit, please, we see this recorded:
“POCL’s position is that rollout should not commence until data integrity can be assured. Ruth Holleran …”
Do you remember who she was?
Anthony Oppenheim: Yes.
Mr Beer: Who was she?
Anthony Oppenheim: She was certainly on the POCL side, I think operational.
Mr Beer: “… to consider with the Auditors, and report back to this group, whether the current Pathway checks plus, possibly, continuing POCL checks, would be adequate until Pathway’s full data integrity checks are in place.”
Then skip over the reference, if we may, to the previous workshops and come up to workshop 7, which is this workshop:
“Workshop 7 Update: this issue has now focused on the success criteria for NRO resumption …”
National rollout resumption?
Anthony Oppenheim: Correct.
Mr Beer: “… at the review in November. Pathway had previously proposed four weeks … with [equal to or less than] 1.5% error rate.”
Do you remember that having been proposed by Pathway?
Anthony Oppenheim: To be honest, I don’t. I mean, I see it there recorded but I don’t remember it. It’s not certainly something that we spent a lot of time talking about.
Mr Beer: Why didn’t you spend a lot of time talking about it?
Anthony Oppenheim: Because POCL rejected it and I wasn’t going to argue with them.
Mr Beer: Why was it suggested? I mean, on an estate of 20,000 branches, that would be, what, 300 branches a week showing a discrepancy error.
Anthony Oppenheim: Yes, but the – this would have been on the basis that there would have been continuing improvements after that. That would have been a premise made. Rather than rollout from here, you rollout when you get down to here (indicating) and then there would have been continuing improvements. That would have been the premise behind that, not that it would have stayed at less than 1.5 per cent, or a limit of 1.5 per cent forever.
I agree with you it would have been too high and, indeed, the previous PinICL had acknowledged that such a thing would have been too high.
Mr Beer: Given that the previous PinICL had acknowledged that an error rate of this would be too high, why was Pathway even suggesting it?
Anthony Oppenheim: I can’t remember who suggested it. At a guess it would have been put forward by the lead analyst responsible for 376 but I can’t remember whether that was John Pope or John Dicks directly. It’s not something I recall having had any great discussion about. Bear in mind these were going on on pretty much a daily basis and I did have other duties as well.
Mr Beer: “[Ruth] Baines and Ruth Holleran proposed an error rate of 0.6 per cent (the current average is 1.2 per cent) together with six other conditions, five of which are listed in [Ruth Holleran’s] paper and the sixth being a further two weeks period of live running of the permanent Cash Account fix prior to the actual re-commencement of [national rollout] in January.”
Then you are recorded as responding as follows:
“0.6 per cent error rate [was] agreed subject to this being measured as the average of six weeks from 4th October to mid-November …”
What would you say to the suggestion that this was conscious risk taking here, accepting even an error rate of 0.6 per cent?
Anthony Oppenheim: Yes, but this is the error rate of the type that we were talking about before lunch whereby you could get a missing attribute and a TIP mismatch, not the cash accounts, 0.6 per cent of cash accounts were wrong, that’s not what this was.
Mr Beer: So what was the worst consequence of the error?
Anthony Oppenheim: It would – the third supplemental agreement sets it all out as to – under what failure conditions, what actions would be required, but the generality was that either Pathway – most often Pathway but otherwise POCL – would have to make certain error corrections, either manually into a – key them into the system to correct an imbalance, some missing data, or otherwise, if there were a lot of them, then POCL could require Pathway to provide an update file electronically. So that’s also – I’m getting ahead of myself here.
Mr Beer: Yes.
Anthony Oppenheim: But that’s all set out later, but that was the consequence. It was to do with overwhelming – POCL but not only POCL – Pathway, in terms of the number of errors that will need to be corrected.
Mr Beer: Can we see how this was formalised in the second supplemental agreement and turn up FUJ00079316. Can you see this is a document called “The second supplemental agreement”, dated 24 September and one of the things it does, as we will see, is reduce into contractual terms what was agreed at that part of the workshop that we have just seen.
Can we look again at the preamble, please:
“This Second Supplemental Agreement is supplemental to the Codified Agreement …
“The Contractor and POCL have been carrying out the Operational Trial and the other Acceptance Procedures in accordance with the Codified Agreement.
“By a Supplemental Agreement dated 20th August 1999 (the ‘First Supplemental Agreement’) the parties agreed that [Core System Requirement] Acceptance had not been achieved at the end of the CSR Operational Trial … Period.
“By the first supplemental agreement the parties agreed … a programme of work with a view to achieving Acceptance and Release Authorisation by 24th September 1999, and also agreed that only certain elements of the [CSR] were required to be resubmitted for testing in the Second CSR Acceptance Test and that only certain faults could be raised as Acceptance Incidents in relation to the Second CSR Acceptance Test.
“As at the date of this Second Supplemental Agreement the following Acceptance Incidents … remain outstanding …”
That excludes category C ones:
“Category B faults …”
They are described in part A and I think we will find that’s blank and then:
“Faults not falling within recital (E) above
“… Acceptance … described in Part A of schedule 1.”
I think we will find that at page 9.
So this is a list of the AIs that have rectification plans and we can see that 376 is one of them.
Can we go back to page 3 of the document please. At paragraph 3.1 we can see:
“The Contractor [that’s ICL] undertakes to use its reasonable endeavours to resolve each of the Outstanding Acceptance Incidents referred to in part B of schedule 1 [which we just looked at] in accordance with the rectification plans listed Schedule 2 … and the Rectification Timetable. POCL shall use its reasonable endeavours to comply with the obligations imposed on it in the Rectification Plans.”
Can we go forward to the rectification plans please, they are page 10. We will see that there is a list of rectification plans for each of the AIs. They are called AINs here, is that just AI number?
Anthony Oppenheim: You know I’m not sure. When I read this I couldn’t recall what the “N” stood for.
Mr Beer: Can we go forwards then to pick up the one that we’re interested in, which is on page 13 and down the page to paragraph 20 and at 20.1 and 20.2 we can see the rectification plan for AI376:
“Each of the Contractor and POCL shall complete the steps and achieve the objectives applicable to it … set out in Document …”
It is described:
“… and where that document identifies one party as fulfilling an action, the other party shall assist the aforementioned party to reach a successful conclusion.
“Each of the Contractor and POCL shall complete each of the … Obligations applicable to it by the dates and to the standards set out in [another document].”
Can we go to page 19 please, for the rectification timetable at the foot of the page, schedule 4, part B. Keep going down. We can see “TIP interface accounting integrity (AI376)” and then if we flip over the page, or carry on scrolling – thank you – we can see the timetable and the steps are as follows:
“The criteria to be met by 24th November 1999 shall be as follows:
“(i) during the period from 3rd October 1999 until 14th November 1999 the percentage of Cash Accounts received by POCL across the TIP interface containing Cash Account Discrepancies shall not exceed 0.6 per cent of all such … Accounts …”
That’s essentially reducing into writing what had been agreed at the workshop; is that right?
Anthony Oppenheim: Yes.
Mr Beer: “(ii) during the period from 3rd October 1999 until 14th November 1999, no Cash Account Discrepancy shall arise as a result of a cause previously reported to POCL as having been remedied.”
That’s obvious what it means on its face:
“(iii) all new causes of Cash Account Discrepancies identified after the date of this Agreement shall have been properly analysed by the Contractor and suitable rectification plans therefore submitted to POCL in reasonable detail within ten days of the Contractor becoming aware of such Cash Account Discrepancy.”
Then (iv):
“The Contractor shall have satisfied POCL (POCL acting reasonably) that the Accounting Integrity Control Release would, had it been deployed at the relevant time, have identified all Cash Account Discrepancies reported prior to 24th November 1999 which shall have arisen as a result of any new cause identified after the date of this Agreement …”
No need to read (v).
The reference to the accounting integrity control release, can you explain what that is, please?
Anthony Oppenheim: So this was to basically enhance the controls and the checks three-way between the counter, TMS and TIP, as I recall, so I think otherwise known as a three-way integrity check because, as I have said before, there’s the possibility of timing differences, if a post office isn’t polled, if the communication network goes down, then you have transactions at the post office that don’t get to TIP, basically, and they will catch up in the next period, but in that period they’re missing.
So you needed a mechanism to do that reconciliation, such that you wouldn’t have a situation where TIP simply said “It’s wrong, what I’ve got is wrong”. So the first thing was to identify the discrepancies and next it was to aid the process of fixing the discrepancies, the so-called rectified – sorry, you were going to say?
Mr Beer: We will come back to the accounting integrity control release. That’s a sufficient description for the moment –
Anthony Oppenheim: Okay.
Mr Beer: – and I will ask some questions in a little while about, firstly, whether it should have been there from the start and, secondly, whether it was an adequate remedy when it was introduced.
Anthony Oppenheim: Okay.
Mr Beer: Before we just leave this agreement can we go back to page 4 please and look at 3.6 at the top:
“The contractor shall cooperate and join with POCL in providing such information and explanation to the Post Office’s auditors as such auditors may reasonably require in order to satisfy themselves that the audit reports of the Post Office and POCL should not be qualified or contain a fundamental uncertainty paragraph as a result of the circumstances giving rise to Acceptance Incident 376.”
Can you explain, please, why that was necessary?
Anthony Oppenheim: My recollection of this is hazy. I don’t recall having to spend a great deal of time on it. The point was that obviously there were people within POCL who were very concerned at 376 and that initial description of 376 which painted a very black picture of the likelihood of a lot of errors. As we discovered as we went through it, there weren’t a significant number of errors arising from the system that would have affected cash account but, at that time, that wasn’t known and there was a lot of concern. Plus there were instances which could affect the cash account, notably and in particular around reference data.
So, basically, people had got understandably concerned about it and we were requested to provide, if you like, substantiating evidence of the kind that I’m trying to convey now, to show the auditors that it wasn’t going to be a disaster.
Mr Beer: Because, otherwise, there would have to have been a qualification entered into the accounts, or the auditors may have required a qualification to be entered into the accounts.
Anthony Oppenheim: That is indeed what they were concerned about, which I could well understand.
Mr Beer: Can we turn, moving the story on a little, to FUJ00118169. This is a monitoring report dated 9 November 1999. You can see that in the bottom right at the foot of the page and it’s an update for the meeting the next day, 10 November. You can see that in the top right. Can you see that?
Anthony Oppenheim: Yes, I’m sorry, yes.
Mr Beer: Then, against the third row, AI376/1, which was essentially the first requirement that required to be fulfilled that we have just mentioned in the rectification timetable, namely:
“The percentage of cash accounts containing discrepancies shall not exceed 0.6%.”
I think we can see the figures were, where the target was not exceeding 0.6 per cent for the period from 3 to 6 October, it was just shy of 45 per cent –
Anthony Oppenheim: Yes, correct.
Mr Beer: – for the period 7 to 13 October, it was just shy of 43 per cent; for 14 to 20 October, it was 32 per cent; and then 21 to 27 October it was 2.29 per cent.
Anthony Oppenheim: Indeed.
Mr Beer: Can you recall what accounted for, firstly, the substantial reduction?
Anthony Oppenheim: Well, I can describe what caused the very high numbers: that was bad reference data.
Mr Beer: It was all down to the reference data?
Anthony Oppenheim: Well, not all, but something like 2 per cent would have been other things, but all the rest of it was – I believe was reference data. The vast bulk of that was reference data and it was acknowledged to be by POCL at the time. So you had signage problems that we alluded to earlier, so a 196 reference data update, which we had challenged in June and we were instructed again in October to apply, even though we had said we thought it was likely to create a problem and it duly did and, actually, in one of the documents I have seen, I have seen an acknowledgement that, yes, that’s exactly what did happen.
That was one example. There were other examples. Reference data was a major problem.
Mr Beer: When that’s stripped out and we get to the week of 21 October to 27 October, the figure is nearly four times the so-called acceptable level of cash account discrepancies, isn’t it?
Anthony Oppenheim: It is and I’m not saying that that wasn’t the tale of reference data.
Mr Beer: That could be reference data too, could it?
Anthony Oppenheim: Some of it could be. I really can’t analyse it. All I can say – and you may show me a later version of this, a later dated version of this – is that, by the end of the period, we were either at or very close to the 0.6 per cent, having stripped out these non-data errors, as we referred to them as.
Mr Beer: Can we go forwards, please, to FUJ00058187. This is a “Monthly Progress Report”. I think, is this from ICL to –
Anthony Oppenheim: Yes, this is our –
Mr Beer: – to POCL?
Anthony Oppenheim: This is ours. It’s internal and it’s also to POCL, yes.
Mr Beer: You would have either seen or contributed to the creation of this?
Anthony Oppenheim: I would have seen it. I wouldn’t have contributed.
Mr Beer: Okay. Can we go forward to page 10, please, and have a look at the third bullet point:
“Too many reference data errors are being distributed to the counter. End to end design reviews are being held to establish what action can be taken swiftly to prevent these occurring in the future. These are having a major impact on [AI] 376. In addition, the performance of the data distribution process is inadequate and must be improved before rollout commences in late January 2000.”
So this is October 1999 and we see the reference to too many reference data errors. What does the last sentence mean:
“… the performance of the data distribution process is inadequate and must be improved …”
Anthony Oppenheim: So this is where we have to get reference data updates out to every counter and every branch before the change in reference data is to take effect and, as I said before, this was before internet and broadband. We had to do that using IBM’s Tivoli system, which was state-of-the-art at the time, over ISDN, and the challenge was to be able to get all of these instructions out well in advance, like two days or so in advance, of when they were due to take effect so that there wouldn’t be any missed dates.
Mr Beer: Can we go forward to page 19 of the document. Under “Detailed Plan Activities”, and the “Acceptance Resolution Timetable” and then scroll down. Next to each bullet point is the number of the AI and can we look at what John Pope, I think that is, said in relation to 376. John Pope:
“This area is of particular concern. The six-week observation period has started. The work is in three parts: fixes yielding a target stability figure of merit of a maximum 0.6% of Cash Accounts in error (approximately 42); additional reconciliation facilities; and new Operational Business Change (OBC) procedures. Although all fixes are implemented, problems arising from Pathway Reference Data handling were encountered and are proving difficult to solve without letting through Cash Accounts in error. The definition work for additional reconciliation is on plan and design is in progress. All the OBC procedure work is completed.”
We can stop there. So, again, at this point the finger being pointed towards reference data being the problem?
Anthony Oppenheim: It wasn’t the only problem. I mean, this is a very, very complex multi-layer programme, so it’s – I don’t want to give the impression it’s the only problem, but it was the overwhelmingly largest problem. But, as it says there, we had issues also with Pathway reference data handling. That’s when we received the – sorry, the reference data instructions from POCL, we then needed to “handle it”, turn it around and push it out to the post offices and we were having trouble with that, probably just the volume of that, but that’s what that alludes to.
Mr Beer: Thank you. Can we move to a similar progress report for January 2000, FUJ00058189. You can see the date, similar format to before. Can we go forwards, please, to page 26. The first bullet point at the top of the page:
“The outturn on AI376 was 0.06% Cash Account Discrepancies, exactly an order of magnitude better than the target.”
Obviously 0.06 better than the target of 0.6:
“Under this activity John P [John Pope] made significant contributions to the Third Supplemental agreement, specified the committed CS Repair Facility, aligned the operating agreement on Reconciliation to support the contract, and sorted out the necessary PinICLs to clear.”
This reads as if it’s a job well done and that’s the end of the matter; is that right?
Anthony Oppenheim: No. It’s a job well done, but it certainly wasn’t the end of the matter.
Mr Beer: Why wasn’t it an end of the matter?
Anthony Oppenheim: Because we needed the detailed processes that were then written into the third supplemental agreement and, subsequently, operational documents that flow from that, so that the fact that he had made significant contributions to an agreement that – what was the date of this?
Mr Beer: January 2000?
Anthony Oppenheim: I mean, the third supplemental agreement from memory was signed on the 19th, so I don’t know whether this was before or after.
Mr Beer: It’s just dated January 2000.
Anthony Oppenheim: But, in any event, the work that went into that was very, very significant.
Mr Beer: Can we look forwards then, please, to the statistics. Can we just look back a moment at POL00090590. We see an email here at the foot of the page, dated 6 January 2000:
“In advance of tomorrow’s delivery meeting, find attached the latest spreadsheet that looks at criteria in relation to 376.”
Then the thing that we’re looking at, 376(i), a 0.17 per cent pass rate, so cleared the ceiling of 0.6 per cent, and we see what happened to that by the time of the undated report that we have just read.
How far had the accounting integrity control release contributed to this?
Anthony Oppenheim: I don’t know for sure but I would say it was a major contributing factor.
Mr Beer: The accounting integrity control release, can we understand how it was intended to operate in practice and the function that it was intended to perform. It is set out – and this is just for the transcript, no need to turn it up – in the second supplemental agreement at POL00090428, at pages 135 to 137, the document entitled “Logical design for EPOSS/TIP reconciliation controls”.
I want to try and understand how, in simpler language rather than going through that laboriously, it functioned and the operation that it was intended to perform. Would this be right, that the EPOSS and Transaction Information Processing, TIP reconciliation controls, added some functionality to the system to provide a simple validation, that the transactions and data recorded at the counter, matched the data in the POCL back end systems?
Anthony Oppenheim: Exactly right. That’s a good high level summary, yes.
Mr Beer: The way in which the data and transactions were captured and harvested, in broad summary again, worked as follows – and this is me and my understanding translating what has been read. Firstly, the EPOSS, the Electronic Point of Sale Service transaction data from the counter was captured in something called the office platform service infrastructure?
Anthony Oppenheim: Mm-hm.
Mr Beer: The data is harvested by the transaction processing service, that’s a POCL database, collecting all transactions from the counters. It is passed to TIP, the transaction information processing, which would in turn feed POCL accounting systems.
Anthony Oppenheim: You’re asking me to confirm something that’s a little, perhaps, too technical for me. I mean I was very happy with what you said previously.
Mr Beer: The high level summary but not the one beneath?
Anthony Oppenheim: I’m not 100 per cent sure that it worked like that. My understanding was the harvesting was done from branches to correspondence servers to TMS to TIP. So that was the route that I was familiar with and then once within TIP, then Post Office would push that same data out to clients and there would be reconciliations between them and the clients.
Mr Beer: Okay, let’s look at it a different way round, looking at the object. The object is to ensure that the transaction records from the counter, which are then subsequently transferred by TMS and TIP to POCL, to their accounting systems, reconcile exactly?
Anthony Oppenheim: So, to be precise – yes, but to be precise, TIP is a POCL system so that’s the boundary, TMS/TIP is the boundary.
Mr Beer: Now, the accounting integrity control release introduces, would you agree, some basic checks to ensure that on a daily and then on a weekly basis a certain number of things, collected at counter level, match that that was transferred by TIP?
Anthony Oppenheim: Transferred to TIP I would think, yes.
Mr Beer: To and then by TIP?
Anthony Oppenheim: Yes, correct.
Mr Beer: Firstly, the total number of transactions?
Anthony Oppenheim: Yes, and the value.
Mr Beer: Secondly, the quantity value of them and thirdly the sales value of them.
Anthony Oppenheim: Sounds right, yes.
Mr Beer: They are the three basic data checks that the control release intends to collect and compare?
Anthony Oppenheim: Yes.
Mr Beer: So this new release was intended to ensure that those three data sets, collected at the counter level, matched that data that was transferred via TIP?
Anthony Oppenheim: That’s my understanding, yes.
Mr Beer: Then if the output is such that the numbers don’t match, it generates an alert essentially –
Anthony Oppenheim: It does, yes.
Mr Beer: – and what it generates is identification of the branch code and the discrepancy figures are reported, ie what the discrepancy on any one of those data sets that I mentioned is?
Anthony Oppenheim: Yes, that’s my understanding.
Mr Beer: Would you agree that, from a technical perspective, that would have required, in this new release, firstly ensuring that a clear marker was used to delineate the start and end time period used?
Anthony Oppenheim: You’re asking me for a technical view. I mean there were start times in all of the messages and indeed this was one of the reasons for the missing attribute problem that we talked about earlier, so on occasion –
Mr Beer: We will pick it up with another witness.
Anthony Oppenheim: Yes, I would rather you did.
Mr Beer: Yes. Why was a system of this nature, carrying out rather basic data integrity controls, not built in from the start?
Anthony Oppenheim: That’s a very fair question. There was an element of it before: this didn’t suddenly get rustled up in no time at all. So we had been working on it I think since about June, recognising that there would be a need, which is how it was that it was possible to deliver it for December.
Mr Beer: Can I suggest that –
Anthony Oppenheim: I don’t think that there was a requirement from POCL for it. I don’t recall a requirement.
Mr Beer: Who out of the pair of you in this relationship were the IT experts?
Anthony Oppenheim: We both were. They had a lot of technical people on their side.
Mr Beer: So in your last two answers are you suggesting that it fell to them to suggest that a very basic validation and reconciliation tool should be written into your software code?
Anthony Oppenheim: No, I’m not. I’m simply saying, in answer to your question “why wasn’t it done sooner”, I think there was an element of it before and in fact I can recall a couple of PinICLs talking about – there were – I can’t remember what there were. There were checks but they weren’t organised in the manner that you described and they were more for technical people, so they weren’t as useable and they weren’t as shareable as they were with POCL. So yes, logically I agree I don’t think that it was in a requirement and therefore it got missed. I’m not going to make any excuses for that.
Mr Beer: Can I turn to a related issue: whether this very basic software, as I described it, was capable of identifying and addressing the underlying root causes of the cash imbalances that it detected. Would you agree that the capability of the software release, as we have just described it, was quite limited?
Anthony Oppenheim: Yes.
Mr Beer: That’s because all the release did was to flag batches of transactions that didn’t reconcile?
Anthony Oppenheim: Individual transactions. It would pinpoint those which did not match that three-way check, but it wouldn’t, of itself, identify the root cause, correct.
Mr Beer: Exactly, that was the point I was about to make. It wasn’t capable of identifying the root causes of the cash account imbalances, let alone address the root causes?
Anthony Oppenheim: Absolutely right. What it did do – and there was a process for this, very detailed process. Whenever one of these exceptional events was identified, then there was a routine for looking into the transaction logs, the message files, and so on, and so on, to dig into, you know, what had caused the problem.
Mr Beer: The second limitation, would you agree, was that, even if the release worked properly, it would only highlight a specific set of errors in the system related to harvesting and communication of transactions between the counter and TIP?
Anthony Oppenheim: I agree with you.
Mr Beer: So that, if there was a software or hardware fault at the counter level, that itself prevented transactions from being recorded or lost or duplicated, or miskeyed in EPOSS, for example, they wouldn’t be captured by this release?
Anthony Oppenheim: I think I need to – if you don’t mind – go into each of those in turn because they’re slightly different.
Mr Beer: Yes.
Anthony Oppenheim: I agree the headline principle of what you’re saying. It wouldn’t have addressed those, it would have addressed timing differences, and such-like, mismatches in communication. What it wouldn’t have done is identified if there had been a break in the network, right in the middle of a transaction, such that something was lost.
Now, there should be rejects right up until that point and it should be possible to see that the counter clerk had got to a certain point in the transaction – so, for example, a possible reason for a cash discrepancy, a shortfall, would be there had been a benefits payment made, the cash had been paid out and then, lo and behold, the transaction wasn’t recorded. That would be an obvious cause for there being a discrepancy and a shortfall for the postmaster.
Now, by analysing the messages right up until the point where there would be a record of the break in the network, you would be able to see that, yes, you had got to this point but the receipt hadn’t been printed, or whatever, and it hadn’t been completed – the transaction hadn’t been closed out as it would normally have to be.
The inference of that, we would say, is that transaction actually did complete, the money was paid out and the correction would be to fill in the blanks, as it were, and that would be the correction I would expect my technical colleagues to apply in this – it was referred to in the previous thing, these rectification files, and they would be transferred across TIP and everything would balance, if it was caught before it was identified and, if not, we would send an error correction afterwards. I’m going off memory for the third supplemental agreement.
But – so that’s one cause of failure. Another cause of failure is, let’s say, a printer breaks, or more likely runs out of paper in the middle of a transaction. Now, I think that was fixed. I’m pretty sure that was fixed, such that the transaction would have completed anyway but, in the early stages, if that happened then it would not. I believe that was a PinICL that was resolved, so that’s another one.
There’s – there was the hour glass problem, which you haven’t mentioned but let me mention it. Slow running of the PC.
Mr Beer: Yes.
Anthony Oppenheim: Very understandably, a postmaster would get impatient, he is up against it, he’s got a queue and he might hit – I have done it myself – the key twice. If you hit the key twice then, basically, that breaks that transaction, or it did at the outset. I believe that too was rectified but, at the beginning, that kind of involuntary behaviour could cause a transaction to be either missed or duplicated, I can’t recall.
Mr Beer: Is the point this, Mr Oppenheim, the release identified, at a basic level, a basic data set showing discrepancies. It neither identified nor addressed the root causes of them and the only way properly to do so, to identify, diagnose and deduce root causes, is to have a task force of skilled individuals doing so?
Anthony Oppenheim: I wouldn’t say a task force but you need skilled – a team of skilled individuals who do that for a living, yes, and that’s what second and third line was supposed to be about.
Mr Beer: Just stopping you there. The helpdesk – that’s what the helpdesk was supposed to be about, was it, the second and third line?
Anthony Oppenheim: Helpdesk – when there’s – the helpdesk would register the fact there had been an error and, if there was a correction routine, which it was possible for the postmaster to run for himself, then there should have been a script which had been agreed with POCL that would steer – the helpdesk first line operator would steer the postmaster through it, such that he could effect that fix himself.
I don’t know the proportion of those that could be done that way. There was certainly quite a high proportion that could be done that way. Obviously, it relies on the postmaster making the call, picking it up and being able to follow through and I know there were some instances where that went wrong and then he was unable to put it right afterwards, from what I have read.
Mr Beer: Can we move, please, to the third supplemental agreement, FUJ00118186. This was entered into, we can see on the top of the page there, on 19 January 2000 and, overall, would you agree that it defines, at a relatively high level, the measures that were to be implemented to detect, report and remedy cash account errors by various issues, including software faults, coding errors, reference data errors?
Anthony Oppenheim: I wouldn’t quite characterise it like that. It is actually quite detailed and it went into – there’s a table of, I think, all the known reasons for error at the time and it wasn’t so much to do with software errors. I mean, there was a process for that. This was not to do with software errors. It was identifying, okay, was it one of these or one of those and it set it out in very, very –
Mr Beer: I’m sorry, somebody is drawing something to my attention.
The transcript had stopped so we had better stop speaking.
(Pause)
Mr Beer: Can I suggest that we take an early afternoon break and restrict it to ten minutes or so. I haven’t got long to go in my cross-examination but if we came back at 3.10.
Sir Wyn Williams: Yes, certainly.
Mr Beer: Thank you very much.
(2.58 pm)
(Short Break)
(3.14 pm)
Sir Wyn Williams: Hello.
Mr Beer: Sir, good afternoon. Sorry that has taken a little longer than expected –
Sir Wyn Williams: That’s all right.
Mr Beer: – 15 minutes rather than 10 but just before we pick up, Mr Oppenheim, where we left off in the third supplemental agreement, just two clarificatory points on some questions that I asked and answers that you gave earlier.
Firstly, could we have back up on screen FUJ00058189. This was one of the monthly reports and I have picked the January 2000 monthly progress report. I think, looking back at the [draft] transcript in your answer, you said that this document was ICL’s, ie it was authored by ICL, ICL Pathway, that it was internal and then you added but it is also to POCL.
Anthony Oppenheim: Sorry, I was going to say I was – in a sense both. I wasn’t trying to say “Oh, and by the way it was also POCL”.
Mr Beer: On what basis do you say that this report was addressed to and provided to POCL?
Anthony Oppenheim: I believe it was – I believe it was. I’m not 100 per cent sure now that I think about it.
Mr Beer: What is the basis for your belief?
Anthony Oppenheim: It was my recollection. I can’t say for certainty. If you bring up the distribution – could you do that?
Mr Beer: I don’t think I can. If you look over the page.
Anthony Oppenheim: I haven’t got it in front of me. Ah, there, right.
Mr Beer: One can see a contents page, and then go over the page again, and then go over the page again – we always find these pages upside down – then go over the page again.
Sometimes within these reports one –
Anthony Oppenheim: Oh, I’m sorry, I was referring to a service one. This is the managing director’s – no, I got that wrong. If I may retract that. I thought we were looking at the Acceptance Incident report, not this one. No, this – the managing director’s is internal. My apologies.
Mr Beer: Thank you, that’s the first clarification.
The second clarification, you said a number of times in the course of your evidence today and including this morning that the Cash Account – and I’m going to call it capital C, capital A – was acceptable, was fine and that this was one reason why it was permissible to seek to recategorise AI376 as a category B incident or lower. When you’re referring to the Cash Account here are you referring to it, in a technical sense, to a technical module as part of the system?
Anthony Oppenheim: I’m struggling to understand the point.
Mr Beer: Yes.
Anthony Oppenheim: I’m sorry.
Mr Beer: I have been using the Cash Account problem, describing the Cash Account in a much broader context, ie anything which showed a discrepancy between the cash that a subpostmaster had in branch and the cash value recorded in back office systems –
Anthony Oppenheim: Right, okay.
Mr Beer: – which I had understood the AI376, certainly the first two incident forms, to be referring to it, in the sense that I was using those words: Cash Account Discrepancy.
Anthony Oppenheim: Right, okay. Very important point. I have to say mine is the narrower one, which is more of a technical one I guess, and if we go through aspects of the third supplemental agreement I can point you to how we sought to distinguish between the two, not to belittle the part that it would not identify, but it was never going to identify everything.
All it was going to do was identify any differences between the Cash Account as declared by the subpostmaster, or postmaster, what was in the central TMS system and what was sent across to TIP.
The Cash Account as committed by the subpostmaster may have been “wrong”, and I don’t use the term in a pejorative sense. It’s what he may have been forced pretty much to commit to in order to carry on because there was an inadequate facility for him to say “Just a minute, I’ve got a problem”, if something didn’t balance. And if he made good the imbalance, as I understand it, particularly in hindsight, then the committed Cash Account would have balanced and we would have known nothing about it.
The only way we would have known about it is if he had reported the problem to the helpdesk, which is what I was talking about before the break, in which case, if he says, “Look, I put through a such and such and it broke” – you know, I gave a couple of examples, there are more – “and it didn’t complete properly and I’m pretty sure, I have been through my records, and this £300 discrepancy I can relate to that transaction”, then we from the helpdesk should have gone into that and got a second line support person, an account specialist, to go in to look at the message store and dig out the audit trail for that particular event.
Mr Beer: Just stopping there, that requires the people in the helpdesk, the various tiers of the helpdesk, to do what you have just said –
Anthony Oppenheim: Yes.
Mr Beer: – for the subpostmaster to have persistence and conviction in what they are saying and not to be told “It’s your responsibility to balance the books, make good the difference”?
Anthony Oppenheim: Certainly looking at what’s happened, yes. It shouldn’t have required persistence, it should have required simply an explanation of what had been observed and there should have been, as I said before, a certain amount that he could have done to put it right for himself through a scripted set of instructions. Bear in mind the helpdesk person couldn’t actually get to the terminal in the post office, that wasn’t possible in those days, so he had to steer the subpostmaster through what he would have had to do and some of that would have been quite complicated, and I can imagine some of it –
Well, I have seen some of the evidence, some of it went wrong and you ended up with double the problem that there was in the first place.
So the only way to identify and fix those was through that route.
This reconciliation process, you’re quite right, would not have done that.
Mr Beer: Thank you.
Anthony Oppenheim: And, if I may just one more point, the third supplemental agreement made that clear because it said there’s a thing – it identified a thing called I think – the second one did as well – a “not data error”, which sounds like a very peculiar term but it’s a very deliberate term. In Pathway’s terms it means “It’s not us”, it’s reference data, is one example, or it’s the postmaster making a mistake. I have to say that, you know: easily done, millions of transactions, right.
But it isn’t something that’s a software bug and it’s not something that we can effect and it’s not something that we can fix and there are references in there to, if it’s not clear, we will say it’s not clear, we will report that to the Post Office.
Mr Beer: Thank you. I’m just going to give the cross-reference to that, it’s FUJ00118186. We will chase down in due course the paragraphs within the third agreement. I know that you have been reading it or re-reading it over the break.
Anthony Oppenheim: Yes.
Mr Beer: Lastly, can I ask you please to look at FUJ00118188, please. Thank you very much. This is a letter from your counterpart, Keith Baines, dated 20 March 2000. It reads:
“TIP Integrity Checking:
“The Second Supplemental Agreement (in clause 7.1) provided for a TIP Integrity Checking Period, during which POCL would reconcile transaction and cash account data received in TIP from ICL Pathway. This period was to continue until four consecutive weeks without discovery of any Cash Account Discrepancies not found by the Accounting Integrity Control Release.
“I am pleased to be able to confirm that this condition has now been satisfied, with satisfactory explanations having been received by POCL from ICL Pathway for the small number of apparent discrepancies that were found.”
I think this has been drawn to your attention very recently and I don’t suppose you remember receiving it at the time?
Anthony Oppenheim: That’s my “File”, writing at the top.
Mr Beer: Yes. But now you wouldn’t remember receiving it. What do you now take from it, having had your attention drawn to it?
Anthony Oppenheim: Well, it doesn’t surprise me. I think I do remember it because it was a key event.
Mr Beer: Ah.
Anthony Oppenheim: But, thankfully, you were able to produce it. This was very important because, obviously, if you go back to where we were in July/August it was not looking good, but, by this stage, by doing this – and there was also the attribute checker, which you haven’t mentioned but which we also put in place to help POCL with the reference data issues, we had done it. I mean – but having said that, there were still, inevitably, going to be instances where something went wrong and we have – I tried to write that into the third supplemental agreement and POCL should have known that.
Mr Beer: Thank you very much, Mr Oppenheim. They are the only questions I ask at the moment.
I think, sir, the next set of questions are to be asked by Mr Jacobs on behalf of the Howe & Co Core Participants.
Questioned by Mr Jacobs
Mr Jacobs: Thank you, sir. Can I ask if you can see me and hear me?
Sir Wyn Williams: I can hear you and I now am able to see you as well.
Mr Jacobs: Thank you, sir.
Mr Oppenheim, I’m asking questions on behalf of 153 subpostmasters represented by Howe & Co. Could I ask Frankie, please, to turn up paragraph 59 of your witness statement and that will come up on the screen. That’s at pages 19 to 20 of your statement. It’s there. If we could just expand that at paragraph 59.
Now, this is in respect of Horizon project achievability and you say that in 2001 your confidence in achievability was supported by a statement that the chief executive officer of Post Office made to the effect that the project had been a success and that:
“… we have got a product which is working extremely well …”
Now, we, as I have said, represent 153 subpostmasters and mistresses, most of whom, if not all, have given evidence to the effect that the product routinely created unexplained and erroneous shortfalls, more than occasional mismatches, for which they have been held liable.
Now, my question is: do you accept that there is a disconnect between what the contracting parties were saying at this time and what was actually happening on the ground?
Anthony Oppenheim: Well, with the benefit of hindsight – and I – I don’t know the timelines of your clients’ events. With the benefit of hindsight, clearly, all was not well, but I have been trying to say throughout that we cautioned the Post Office that this would not be 100 per cent foolproof.
Mr Jacobs: Okay, and have you listened, Mr Oppenheim, to what our clients and other people have said in their evidence in this Inquiry from February to May this year?
Anthony Oppenheim: I have listened to some of the videos, yes.
Mr Jacobs: My next question for you is, with hindsight, do you now agree that Post Office and ICL’s confidence in the product was misplaced at the time that this statement was made?
Anthony Oppenheim: That presumes that we thought everything in the garden was rosy and we knew it wasn’t and we knew that there were things that we didn’t know about it. And the point that I made elsewhere in my witness statement was that, with any new programme, you have to look out for the things that you don’t know about. You can’t pick it all up in testing. So, at some point, you have to pull the lever and Go Live and, bearing in mind the volumes, looking at it from that standpoint, from any IT programme – normal IT programme standpoint, I would have said this would have been viewed as a success, except for the fact that your clients were held to account for things that they didn’t do.
Mr Jacobs: Well, I accept that and you have said that you can’t identify everything in testing, but what did they know about the potential for all these shortfalls that were unexplained?
Anthony Oppenheim: Well, I can’t answer that. I mean, the – I would turn it around and say why didn’t the Post Office, and also Pathway, note the feedback that was coming back better through the helpdesk – through the reports of problems back into the helpdesk?
Mr Jacobs: Okay, well, that’s helpful, thank you.
My next questions are in relation to perceived risks prior to rollout and, Frankie, if we could ask for paragraphs 60 and 62 of Mr Oppenheim’s statement and they are at pages 20 and 21 of 97.
So looking then at paragraph 60, these are the perceived risks of ICL Pathway and the first one that I wish to refer you to is 60.2:
“The Rollout to 18,500 post offices on the other (sustaining the flow of preparation work, ISDN provisioning, training and equipment supply over almost two years with few breaks).”
So that was one of Pathway’s perceived risks at this stage?
Anthony Oppenheim: Yes, it was.
Mr Jacobs: Then moving over to the Post Office perceived risks, which is at paragraph 62, if we could move on to that please. So 62.1:
“rolling out 40,000 sets of Counter equipment to 18,500 Post Office branches at a rate of hundreds a week, having first connected each branch to the network via ISDN (or otherwise satellite);
“modifying the branches to accept the installation of PCs and printers …”
Given the state of technology at the time, and then, finally:
“training 67,000 subpostmasters and counter staff (just) before their respective implementation dates ….”
Our clients say that the training they received was ineffective and that there were significant problems when the equipment was installed, quite often major power outages. Do you agree, Mr Oppenheim, that these particular risks – and I’m talking about installation and training – were not adequately mitigated?
Anthony Oppenheim: Well, the evidence would suggest not, particularly around training. I think there’s definitely something to be said about training. Training was one of the AIs – was it 218 – or 298 – no, 218. It was, as I recall, a two-and-a-half-day training exercise and then there was an extra half day or day for the postmaster. A very complex system, a complete change in business practice for most of them, from manual paper based to system. Was that enough? I think probably not and I have seen that Post Office actually had some of their people and, indeed, some of the more IT literate postmasters help others to augment the training, so I think the evidence is incontrovertible that it wasn’t enough.
Mr Jacobs: Okay, well, thank you. I’m just going to ask those who instruct me if they have any more questions they would like me to ask.
(Pause)
Mr Jacobs: Thank you, I don’t have any further questions for you.
Anthony Oppenheim: Okay, thank you.
Sir Wyn Williams: Who is next?
Questioned by Ms Page
Ms Page: Hello, it’s Flora Page here, representing a number of subpostmasters as well.
What I would like to do, if I may, is ask some questions relating to the issue that we have come to speak about as remote access, in other words the capacity for Fujitsu to go into accounts and make changes, and the extent to which Post Office would have known about that.
What I would like to do, if I may, is refer you to POL00089779. This is a document from 2000, an internal audit plan. You can see you are on the distribution list there and this sort of sets out a series of internal audits for ICL to conduct during the year 2000. I don’t know if you have been shown this lately or not.
Anthony Oppenheim: Well, if you take me to the bits you want to talk about I will …
Ms Page: Certainly. If we go to page 4 and we look at paragraph 1, it explains that there is actually a contractual right for POCL to do audits on ICL.
Anthony Oppenheim: Mm-hm.
Ms Page: Do you recall that?
Anthony Oppenheim: Yes, I do.
Ms Page: It also explains that the plan here – if we look at (c) it says there that the “independent audit capability within ICL Pathway, as a service to management” is the one thing but, on the other hand, there’s this idea that there’s the POCL internal audit and it seems to be suggesting there – and you can read it for yourself – that the plan would be for these ICL audits to be something which the POCL audit could trust potentially; is that fair?
Anthony Oppenheim: Yes, I think that’s entirely fair.
Ms Page: So it sort of anticipates, does it, that the ICL internal audits will be shared with POCL and their audit team would be able to review them and hopefully trust them and rely upon them?
Anthony Oppenheim: That’s the logic.
Ms Page: Well, if we could then have a look at page 6 and it is right down the bottom of the page. There’s a paragraph 5.10 and it is sort of at the bottom of that page and it goes over to the next page, so if we just stay there. This refers to an audit of the SSC and is it right that “SSC” is another way of referring to third line support?
Anthony Oppenheim: I think that’s fair.
Ms Page: So this is a planned audit for SSC, or third line support, and I will just read out what it says here, it says:
“This is a particularly sensitive area of Customer Services with unprecedented access to live systems for support purposes. Previous audits have identified potential control weaknesses which management declare have been addressed. The audit will confirm the current arrangements and assess the strength of the controls in place. Will include a site security audit.”
So if we can just sort of unpack that a little. There’s obviously been some concerns about who has the sort of wider access that you get if you’re in third line support; is that fair?
Anthony Oppenheim: It’s an issue – it’s a worry for any programme, where you have to determine who is trusted to make changes and have access to live systems, and it should be, and it’s an obvious area for any audit to focus on.
Now, this said that there had been concerns and potential control weaknesses. I mean, this was –
Ms Page: This is in –
Anthony Oppenheim: This was in July 2000.
Ms Page: That’s right.
Anthony Oppenheim: I would say, by then, we should have got on top of those. This says that they have been addressed, according to management.
Ms Page: Yes.
Anthony Oppenheim: It doesn’t – I’m just reading it as it is written. It doesn’t say that they have audited and verified or confirmed that it has.
Ms Page: No. Well –
Anthony Oppenheim: It says:
“The audit will confirm the current arrangements and assess the strength of the controls in place.”
Seeing that, as I imagine I would have seen it originally, I wouldn’t have been unduly alarmed by that because it’s right that they should be looking and worrying about these and I would too and it would suggest that there had been some weaknesses, management says they have addressed them, the audit will follow up. Sounds okay to me.
Ms Page: I don’t seek to suggest otherwise. This is a planned audit. I haven’t been able to locate the documentation of the actual audit, so it’s unclear what was found when this was followed up. But the point that I would like to sort of tease out, if I may, is that, assuming that audit took place, Post Office would have, according to the plan, then been shown that and it would have been shared with them for their own audit purposes; is that right?
Anthony Oppenheim: Well, I’m afraid I don’t know. The fact that they could rely on an internal audit – I don’t know that – I wasn’t responsible for this. This is Martyn Bennett’s area. I don’t know whether he would routinely have shared these with POCL, particularly in the early days, or whether the intention was that POCL would say “Look, can you – have you done an audit on X and would you share it with me”. In other words, we would produce it if asked, as opposed to just issuing them all to POCL, or without being asked.
I suspect it was – if asked, we would share it as opposed to “here it is”, to be honest.
Ms Page: The only way to resolve any problems that ICL picked up in terms of accounts and reconciliations, the problems that we have been talking about with Acceptance Incident 376 was through SSC going into the accounts and doing these changes; is that fair?
Anthony Oppenheim: No. There was such a spectrum. There is appendix 4 – schedule 4 in the third supplemental agreement goes through a long list. For the kind of problems of breaks and such-like that I was referring to latterly, yes, if the postmaster wasn’t able to do it for himself under instruction – under guidance. There was another whole category where a lot of the 376 discrepancies were going to be not automated but semi-automated and didn’t affect – there wasn’t a Cash Account error, but some other missing transaction or whatever error.
So some but not all, by any means, I think, is the answer. And where it was required, those general provisions, right at the end of the third supplemental agreement, require Fujitsu to inform POCL if we made a judgement, and that was really key to me because then it’s saying, “Look, we’re really not sure”, and if then someone is accused of fraud, that will be the first place to look. We would have provided that information. If he had made a call, on such and such a day that which tied in with that discrepancy, that week’s Cash Account, then that’s at least a starting point for saying, “Just a minute, we knew there was a problem here. This was the assumption we made. Maybe that was a wrong assumption, we should relook at it”.
Ms Page: But at a more routine level, when it wasn’t that sort of “We’re not sure” type situation, somebody in SSC would go in and resolve the problem?
Anthony Oppenheim: I was not expecting that. I – for me, this was more of a technical support thing, as opposed to changing data. I did not expect any change of data, particularly without the agreement of the postmaster, so if the postmaster had been talked through a correction routine and it hadn’t worked, then I would have expected the helpdesk to say “Well, this is what I’m going to do, I’m going to raise an error report, I’m going to declare it to Post Office and I’m going to make these changes and I will share them with you; is that okay?” Right?
They agree what the corrective action should be and he does it on the postmaster’s behalf. That’s what I expected, not that he would do it unilaterally.
Now, I have no direct knowledge of what was actually done, I’m afraid, but that was my expectation.
Ms Page: Have you read the evidence of Richard Roll at all?
Anthony Oppenheim: I have briefly and I – I didn’t know Richard and I found some of what he said – well, a lot of what he said concerning but I also found some of it quite surprising. I wasn’t – I should stop there.
Ms Page: You accept, don’t you, that Horizon data was not infallible?
Anthony Oppenheim: Yes, yes. I have said that all along.
Ms Page: And that the Post Office should not have prosecuted on the basis that it was?
Anthony Oppenheim: You’re asking me for an opinion. Would I have done it? No, not without digging really deep.
Ms Page: Finally, do you accept that it was actually in Fujitsu’s commercial interests for Post Office to prosecute on that basis?
Anthony Oppenheim: No, I don’t accept that at all. I mean it – quite apart from the moral side of things, I don’t understand how even commercially – oh, you mean to keep in their good books? No, no, no, Fujitsu is not that kind of organisation, not in my day anyway.
Ms Page: Thank you, those are my questions.
Mr Maloney: Sir, may I ask some questions now?
Sir Wyn Williams: Yes, of course.
Mr Maloney: Thank you, sir. I know by that answer you can hear me. Can you see me now?
Sir Wyn Williams: There is always a delay but now I can, Mr Maloney.
Questioned by Mr Maloney
Mr Maloney: Thank you.
Mr Oppenheim, the Chair has just given you my surname. I’m Tim Maloney and I also represent a number of subpostmasters and, specifically, I act on behalf of subpostmasters whose convictions have been quashed on referral of their convictions either to the Court of Appeal or the Crown Court.
Anthony Oppenheim: Understood.
Mr Maloney: I have only very few questions really for you and they concern commercial priorities of POCL, as you understood them, when dealing with the development of Horizon in 1999, particularly.
Firstly, did you regard the Benefits Agency’s cancellation of the Benefits Payment Card in May 1999 as an existential threat to POCL?
Anthony Oppenheim: Yes.
Mr Maloney: Why did you regard it as such an existential threat to POCL, Mr Oppenheim?
Anthony Oppenheim: Because the original plan, the raison d’être for the Benefit Payment Card was to modernise the method of payment through the Post Office to claimants and to make it “a good experience for them to continue to do so”, whereas what the Benefits Agency would have preferred was ACT and they actually made no secret of that, so that would have eliminated, at its worst, something like a third, as I recall, of POCL’s revenues.
So in that sense, yes, it was an existential threat, unless something could be done to mitigate that loss and, hence, the Network Banking solution and also OBCS was an aid in the meantime because it cut down on encashment fraud, even with paper, and it stopped the Benefits Agency from rushing to ACT, which otherwise I think they would have wanted to do. Whether the government would have allowed them to do that or not, I don’t know.
Mr Maloney: So there was a necessity to generate alternative revenue streams?
Anthony Oppenheim: Yes.
Mr Maloney: Those alternative revenue streams included Network Banking –
Anthony Oppenheim: Yes.
Mr Maloney: – and OBCS?
Anthony Oppenheim: Not really. OBCS was, in a sense, an interim solution. It was a way of making the old books secure by putting a barcode on them such that BA could put a stop notice on them, which previously they couldn’t have done and that saved, variously estimated, 50 million of the 150 million loss of encashment fraud per annum. So it was a good step towards the way. But, no, that was part of the legacy of books and that was going to go away and what needed to replace it was Network Banking, to attract as many POCL customers to continue to use branches and maintain a footfall.
Mr Maloney: Of course, integral to the movement to Network Banking, would be the development of automation?
Anthony Oppenheim: Yes.
Mr Maloney: Without automation, there could be no movement there, there could be no alternative revenue streams, the existential threat perhaps became an existential reality?
Anthony Oppenheim: Well, it would have been, yes.
Mr Maloney: So was it obvious to you, around 1999 and into 2000, that POCL would be under real commercial pressure if Horizon did not proceed at pace?
Anthony Oppenheim: Yes.
Mr Maloney: That’s all I ask. Thank you, Mr Oppenheim.
Sir Wyn Williams: Is anyone else present who wishes to ask Mr Oppenheim any questions?
Mr Beer: No, that’s a nil return, thank you, sir.
Questioned by Sir Wyn Williams
Sir Wyn Williams: Right. Well, I’m going to go on a little fishing expedition with Mr Oppenheim myself, just for a minute or two.
Mr Oppenheim, it relates to many questions you have been asked about processes whereby Pathway might provide information to POCL to assist in investigating subpostmasters, all right?
Anthony Oppenheim: Mm-hm.
Sir Wyn Williams: I don’t want to discuss the strict contractual provisions with you. I’m going on what I describe as a fishing expedition because I want to try and identify the people who might know most about this in order to ask questions in the future. Do you understand?
Anthony Oppenheim: I do.
Sir Wyn Williams: Will you accept from me, because I have reliable evidence to this effect, that investigations of subpostmasters, in reliance on Horizon data, began almost as soon as the rollout began because we have instances of people being in court in 2001 and therefore being investigated in 2000, all right?
So in the year 2000, if I was the person in POCL who was charged with accumulating the evidence necessary to investigate whether a subpostmaster had committed a crime, I think it’s reasonably obvious that I would have to go to someone in Fujitsu to ask for relevant information.
Anthony Oppenheim: Mm-hm.
Sir Wyn Williams: Yes? Now, I’m not one of the people who were working in the technical teams, I’m now a Post Office investigator, or perhaps even a Post Office lawyer, so I want to locate the right people, if you see what I mean. So can you assist me from your knowledge – because, in this period, you obviously were very knowledgeable – who would it be that would most likely tell me what information Pathway might hold and how I might use it?
Anthony Oppenheim: Firstly, I don’t know the answer, but I’m going to try and give you my best shot. I mean, the information is all operational information, so that comes under the head of services, Steve Muchow, but he is a support function. So support is, by definition, a support function. He is not necessarily the go-to person from within POCL.
As I have said before, my working assumption was that anything to do with prosecutions, to do with audit, would have been Martyn Bennett, within ICL Pathway. So that would be, I would have thought, my headline go-to person, and then he would go to someone in support, third line support, Steven Muchow – I’m thinking maybe the very first of these would be groundbreaking, so probably Steve Muchow, to get the evidence to produce the information that was sought.
Sir Wyn Williams: So my investigation begins with Mr Bennett and we can ask him what he would have done in my supposed scenario, yes?
Anthony Oppenheim: I would definitely put the question to him. I may be wrong in pointing at him, but logically I would have thought that was where it would go.
Sir Wyn Williams: All right.
Anthony Oppenheim: It could have come up through – just depending on how POCL raised the matter. Did it go from their prosecution team, their fraud team, to say Keith Baines as the sort of interface to me contractually, who might then have gone to Steve Muchow without my knowing it. I would be surprised –
Sir Wyn Williams: So Mr Baines is another possibility for asking these questions?
Anthony Oppenheim: Well, I think – I think that’s not going to be possible.
Sir Wyn Williams: No, I’m sorry. Yes, yes, sure. All right –
Anthony Oppenheim: But one of that group of people I would have thought would know because why wouldn’t they go to them first to say “Have you got any data, operational data, that would help us with this?”, before necessarily coming to us, but I don’t know.
Sir Wyn Williams: All right. I can’t be certain about this yet, but no doubt I will get evidence about it, it may be that in that same period there would have been a request, as Mr Beer was putting to you, for a person to give evidence from Pathway about the reliability of Horizon. Who would have been involved in making the decision as to who is best placed to give that sort of evidence, given these two premises: firstly, it would be in the nature of expert evidence where the expert owes duties to the court; but, secondly, also it would be based to a degree on factual evidence, so you would need a suitable person to cover those two things in the Pathway organisation. Who would have made the decision “It’s Mr X”, or Ms Y? Who was the best placed?
Anthony Oppenheim: Can I suggest you ask John Bennett that question. I would have thought this would have been seen as such a major issue that it would have – any such question would have gone to John for determination. I don’t recall discussing it with him, but that may be a lapse of memory on my part.
Sir Wyn Williams: Because on any viewpoint there did come a point in time where the person giving evidence in court about these issues was being challenged about it, so it’s hard to believe that this wasn’t, at least by that stage, though I appreciate this might be after your direct involvement, there wouldn’t have been a good deal of discussion about this sort of evidence.
Anthony Oppenheim: I mean, again, at the risk of repetition, it never came up, it never came across my desk – I cannot believe I would have forgotten had it done so – during my tenure.
Now, the fact that it only came to court in 2001, that could point to it having been discussed after, just after probably I had left in February, it’s possible, but I’m casting around. I’m sorry, I just don’t know.
Sir Wyn Williams: All right. I will leave my fishing rod aside and we will wait for future witnesses.
Thank you very much, Mr Oppenheim, for making a statement and for giving evidence to the Inquiry.
Anthony Oppenheim: You’re welcome. I hope it helps.
Mr Beer: Sir, thank you. That’s all of the evidence for today. We’re back at 10.00 am tomorrow.
Sir Wyn Williams: All right. Thank you very much, Mr Beer.
Mr Beer: Thank you, good night.
(3.57 pm)
(The Inquiry adjourned until 10.00 am on Thursday, 27 October 2022)