POL00364052
POL00364052
From: Jonathan Gribben
Sent: Wed 27/02/2019 4:13:02 PM (UTC)
To: Anthony de Garr Robinso
Ce:
; Lucy
BremnerI ]
Subject: Parker 3 [WBDUK-AC.FID123822914]
Attachment: _DOC_154496823(1)_Third Witness Statement of Steven Paul Parker v9.DOCX
Dear Tony,
We've discussed them with Steve and the explanations are below. Slightly updated version attached. We are just
waiting for the example Major Incident Reports from FJ.
Kind regards
Jonny
Jonathan Gribben
Managing Associate
Womble Bond Dickinson (UK) LLP.
Stay informed: sign up to our e-alerts
) WOMBLE womblebonddickinsen.com
) BOND
DICKINSON min)
From: Anthony de Garr Robinson £7
Sent: 27 February 2019 12:42
To: Jonathan Gribben; Andrew Parsons
Cc: Simon Henderson {
Simmonds
Subject: RE: Data deletion [WBDUK-AC.FID123822914]
; Owain Draper; Katie
Dear Jonny,
Here are my immediate comments on Parker 2, without the benefit of having sight of Godeseth 3. Some of them are
quite fundamental, sadly (in particular, my queries about para 15 and para 18). Hopefully they can all be quickly
answered: this statement (and Godeseth 3) are urgent.
Para 6 —I think Riposte was a piece of software, not a store. If I’m right, please use the proper name for the store. This
has been changed to Riposte message store Is Steve Parker referring to the branch message stores in branches and/or the
Post Office message stores? There is some technical confusion here. A message store was only held in branches during
legacy Horizon. During HNG-X it was held in the branch database
Para 13 — typo at the beginning of the third sentence. Could it be spelt out that APPSUP is only relevant to Horizon
Online — or does Godeseth make this clear? Torstein is trying to find out whether APPSUP could be used in Legacy
Horizon, but he thinks it will take longer than today — he is making a list of points to look into further as part of his
preparation
Para 14 — this may not matter, but what does Steve mean by the word “site”? He meant "branch" and we have replaced
"site" with "branch".
POL00364052
POL00364052
Para 15 — the second sentence indicates that APPSUP can be and has been used to change (alter and delate) transaction
data, i:
is that right? If so, this is inconsistent with Godeseth 1 para 59.1, who says it never happens in practice. Does
Godeseth 3 correct this? If not, we have a problem: Which of Godeseth and Steve Parker is right? Not prepared to make
an unequivocal statement. Also Torstein says "as far as I am aware...".
Para 18 —
1. The usual scenario is deleting the data on a defective counter and replicating it from elsewhere (e.g. another
counter or the branch message store). As I understand it, the message stores held at the branch were not counters
and nor were the Post Office message store. There is confusion here between legacy Horizon and HNG-X. On
legacy Horizon the counter consists of hardware and contains a message store as well. It was only in HNG-X that
it was not at the counter but at the main Horizon data centre. To be clear, though, is Steve saying that message
stores were also sometimes deleted and replicated from another source (presumably, counters)?
2. Regardless of the answer to (1) above:
a. Is Steve saying that one could delete all the transaction data (and other accounting data — e.g. stock and
cash positions) completely from the relevant machine (counter or message store), and then separately cause
the relevant data to be replicated from another source?
b. Or is he saying that one could delete all the data completely from the relevant machine (counter or
message store), and this would automatically cause the relevant data to be replicated from another source?
c. Or is he saying that one could cause a process of replication to one source from another and this would
inevitably result in the deletion of the data on the first source?
I think the answer to this is a or b, because of what Steve says in para 38.1 of Parker 2. Para 19 implies b, but
maybe the answer is usually b but a was possible. I don't know and I would like to understand before approving
this para. . A is the answer. The term message store is used for where Fujitsu put all transactions. It has a
specific meaning on legacy Horizon. In new Horizon the message store is in the data base. The amend to para.
6 clarifies this.
Para 20 is con fusing and frankly looks evasive. The footnote in Parker 2 is incorrect and para. 20 explains why ~ it's a
straightforward technical transactions (they are EPOSS not AP). You asked us to go into banking deposits in more
detail, but Andy was going to speak to you about this. We’ve discussed this before, but I’ll repeat:
1. Parker 2 was commenting on a claim in Parker I that the SSC could not use its remote access powers to cause
payments to be made in bank accounts.
2. Parker 2 appeared to qualify that claim by saying that one could not cause payments to be made in normal bank
accounts but one could cause payments to be made in Giro accounts, because they are different. He did not say so
expressly, but to my mind that is the clear impression achieved by the first two sentences of para 35 and the
footnote to Parker 2.
3. As I understand it, Parker thinks that one could cause payments to be made in normal bank accounts.
4. If that is the position, to avoid looking evasive and willing to mislead, I think he should say so squarely. If you
disagree, feel free to call me.
5. I do not understand the point being made in the last sentence. How is it relevant to any of this?
Best wishes,
Tony
POL00364052
POL00364052
February 2019 11:35
To: Anthony de Garr Robinso!
Cc: Simon Henderson (7
>; Andrew Parsons
ject: RE: Data deletion [WBDUK-AC.FID123822914]
Dear Tony,
Please find attached what should hopefully be the final version of Parker 3 for your final review. By way of
explanation, we have restated the words "seek to" in para. 3 and the word "usually" in para. 5 to avoid making
unequivocal statements.
Steve is lined up to sign this afternoon.
Kind regards
Jonny
Jonathan Gribben
Managing Associate
Womble Bond Dickinson (UK) LLP
Stay informed: sign up to our e-alerts
womblebonddickinson.com
WOMBLE
BOND
DICKINSON Sin)
From: Anthony de Garr Robinson:
Sent: 23 February 2019 15:56
To: Andrew Parsons
Cc: Simon Henderson
Gribben; Katie Simmonds
Subject: RE: Data deletion
Owain Draper; Jonathan
J agree about the need to cover this off in Godeseth 3. Can we check wither Parker agrees on the logic and the
terminology? He will be cross examined on this too.
Here are my thoughts on Parker 3. You will see that my draft includes some paras correcting Parker 2 (we cannot serve
a further statement from him which does not do that, particularly in circumstances where Freeths have asked us to do
that).
My draft also includes some paras dealing with deleting data from counters — I am now confused about this, and not just
because of your email last night: it seems from Parker I para 55.4 that deleting counter data (as opposed to message
store data) was something that used to be done in Legacy Horizon. Query whether Parker and Godeseth should cover
this off in their statements: you are currently in a better position than me to make a decision about this, Andy.
POL00364052
POL00364052
Tony
From: Andrew Parsons
Sent: 23 February 2019 15:28
To: Anthony de Garr Robinson 4
Cc: Simon Henderson{_
Owain Draper Jonathan Gribben
5 Katie Simmonds f°
Subject: RE: Data deletion
All
I've spoken to Torstein.
He is adamant that FJ do not delete transaction data. His words: "it would be so bloody difficult to do, I can't even
imagine how you would do it".
In relation to the specific points raised by Coyne on data deletion, Torstein says that FJ are "deleting" data from the
BRDB, but not transaction data. When conducting a transaction, the BRDB keeps lots of flags in lots of different
database tables (think of each table as a separate database) to record when stuff is happening and when things are
completed. For example, it keeps a flag on when a session starts and ends or when a recovery process needs to run.
Sometimes these flags can get out of sync with what happened at the branch (say because of a comms issue) which
can cause Horizon to become locked ie. there is flag starting a session but no flag ending the session, so the next
session cannot commence. FJ do use privileged user access to go in and change / delete the out of sync bit of a
database table, but this is not the transaction database table. This does not change any transaction data. It just
unblocks the system.
He's not actually sure that they even delete the flags - they may actually insert a missing flag or update the flag to the
correct status. He says it depends on the nature of the problem and he'd have to look at the detailed design
documents to know for sure. But he says people will casually refer to this as "deleting a session". But everyone in FJ
knows what this means and knows that it does not mean deleting transaction data.
In Torstein's view this is not a semantic distinction. Deleting a single marker in a database table is (he says) nothing
like deleting transaction data, and Coyne should know this.
I've attached my updated notes which explain this in more detail - page 20 onwards.
The difficulty is that the above explanation is not obvious on the face value of the Peaks, which talk about "deleting
sessions". I think we need a short couple of paras dropped into Godeseth 3 to cover this off. I'll draft something and
then circulate.
A
Andrew Parsons
Partner
Womble Bond Dickinson (UK) LLP
GRO
et32
-
Stay informed: sign up to our e-alerts
womblebonddickinson.com
POL00364052
POL00364052
)
B
DICKINSON
From: Andrew Parsons
Sent: 23 February 2019 09:54
To: ‘Anthony de Garr Robinson’ .
Cc: Simon Henderson: GRO. . ; Owain Draper; Jonathan
Gribben; Katie Simmonds —
Subject: RE: Data deletion
Torstein sent me a short email last night saying that there is an explanation and he still believes his first statement is
correct.
I'm trying to speak to him to understand how he can say this.
From: Anthony de Garr Robinson
Sent: 23 February 2019 09:41
To: Andrew Parsons
Cc: Simon Henderson
Gribben; Katie Simmonds
Subject: RE: Data deletion
Owain Draper; Jonathan
Dear Andy,
I’ve been reviewing TG’s and SP’s witness statements and summarise below the things that they have each said about
remotely deleting transaction/financial data. In short, I don’t think the problem just lies with para 59 of TG and it
looks to me as if SP may have to correct at least his first statement and possibly his second also.
Until we know how this happened — which requires explanations from TG and Spink as to what they were thinking —
we cannot decide how or even whether we can present this to the court in a way that does not destroy FJ’s credibility.
1G
TG (thankfully?) only deals with this in his first statement. In summary, he says the following things in the following
paras:
17. There are only four sources of transaction data. The fourth is via remote access — he specifies BTs on Horizon
online and transaction injections in Legacy horizon. No reference to remote editing or deleting.
57. He is not aware of any way that FJ could theoretically edit or delete transaction data. He also makes it clear that
this is all largely hypothetical — other than one BT, he is not aware of FJ ever having edited or deleted transaction
data.
58.10 Under the heading “Balancing Transactions”, having dealt with the one BT on Horizon online, he breezily refers
to Legacy Horizon transaction injections, implying that they happened but not saying so clearly and not giving any
sense of how often it happened.
59.1 Under the heading “Privileged Users”, he says (1) that PUs’ editing or deleting transaction data is only a
theoretical possibility which would require circumvention of controls, (2) that there is no policy, process or practice
calling for t Pus to edit or delete transaction data and (3) that as far as he is aware, FJ has never used PU rights to edit
or delete transaction data.
POL00364052
POL00364052
59.2 He says PU editing or deleting data is not part of the functionality of Horizon because other tools such as TCs and
BTs are enough.
59.3 He refers to PU changes to the BRDB as hypothetical only.
61. He indicates that as far as he is aware there is no other way FJ can remotely affect transaction data or other
branch account data.
Parker
In summary, Parker 1 says:
11. Roll’s account of editing and deleting branch data is incorrect and misleading.
19. The suggestion that FJ edited or deleted transaction data is not correct. He confirms TG1 para 37 that in Legacy
Horizon it was not possible to edit/delete messages committed to the message store.
55.4 Interestingly, Parker describes a form of remote data deletion here — deleting all the data in a faulty counter in
Legacy Horizon. So there may be a partially face-saving distinction to be drawn between deleting counter data and
deleting message store data. But I doubt that this distinction will help us with deletion in Horizon online.
55.6 He cannot think of any other incidents of remotely accessing counters.
In summary, Parker 2 says:
34. SSC is hugely reluctant to change financial data — not ther job and they recognised the seriousness of doing so.
Tony
From: Andrew Parsons‘.
Sent: Friday, February 22, 2019 7:55 PM
To: Anthony de Garr Robinson
Cc: Simon Henderson (‘~
Gribben; Katie Simmonds
Subject: Data deletion
Owain Draper; Jonathan
Tony
Below is a summary of the point we discussed earlier.
I've attached:
1. Our long briefing note on remote access — data deletion is covered at page 20. This note is still to vetted by
FJ but is built on all their mini reports.
2. The FJ original report on data deletion (that has been largely carried across into 1).
3. The key Peak with all the horrible stuff about FJ deleting data — which is very messy.
This matter has been escalated to Rob Houghton.
A
Andrew Parsons
Partner
Womble Bond Dickinson (UK) LLP.
POL00364052
POL00364052
womblebonddickinson.com
DICKINSON Yin)
From: Andrew Parsons
Sent: 22 February 2019 17:55
To: 'Matthew.Lenton€=---~Sko Dave.Ibbett@" "GRO
Cc: Jonathan Gribben; Christopher.Jay¢ “{ Rodric Williams
Subject: URGENT - support needed over the weekend
Matthew and all at FJ
I'm sorry to drop this late on Friday but we have come across a point that could be a major problem. We will need this
urgently addressed over the weekend as it may require an amendment to Torstein's evidence on Monday. I'm around
all weekend on my mobile if easier to discuss with someone.
At para 59.1 of Torstein's first statement he says that as far as he is aware a privileged user has never deleted
transaction data from the BRDB.
In the attached note (under Section 2 and Section 4) it appears that SSC are deleting transaction data when there is a
stuck session that is stopping a counter from working. If true this appears to contradict Torstein's evidence because I
understand that "a session" holds transaction data.
The associated Peaks make clear that this is happening using APPSUP, which as we determined yesterday is a form
of Privileged User access.
For example, PC0263716 (attached) says:
From: Gillian Hoyland
sent: Wednesday, November 22, 2017 11:18 PM
To: Post Office Service Desk
(Cc: Paul I Smith
Subject: RE: ATF:17186625 I Session Correction Request
Hi
Due to the circumstances at the branch this session can be removed but the branch must
e made aware that if there are any losses/gains from removing it then they will be
liable.
Please note, in future any requests of this nature that do not have the applicable form
lattached which shows what the transaction was for, date etc will not be actioned by FSC
luntil this form is received as this allows us to investigate the incident.
(Thanks
Gill
Gillian Hoyland
IFSC Operational Support Manager
POL00364052
POL00364052
Date: 20-Dec-2017 13:47:45 User:Joe Harrison
[To resolve this I need to run the following SQL on a BRDB instance
delete from brdb branch user_sessions
here branch accounting code = 111832
land fad hash = 124
land node id = 2
land session_status = 'FAILED' or session_status = 'RECOVERING'
IPLease can you authorise the unix team to grant me the "set role appsup" permission.
Date: 20-Dec-2017 13:48:32 User:Joe Harrison
Ithe Call record has been transferred to the team: Security Ops
Progress was delivered to Consumer
IDate:22—-Dec-2017 10:28:30 User:doe Harrison
operation complete - please transfer Call back to me for closure.
lDate:27-Dec-2017 14:35:15 User:Joe Harrison
[Start of Response]
fhe failed transaction has been deleted so please inform the branch that they should now
able to rollover. We will supply formal closure later.
[End of Response]
IResponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
IResponse was delivered to Consumer
Earlier in the same Peak, there is a comment that makes clear this is not a one-off event.
From: MAC
Sent: 26 October 2017 17:48
To: Post Office Service Desk
Cc: MAC GRO ___
Subject: RE: A17004602 - 17186625
Hi
What is the next course of action then?
POL have previously authorised removal of a session that is not
related to travel money card plenty of times in the past.
Regards
Emma Millman
There even appears to be an established process for this.
2017-10-26 11:39:37 [ Watts, James Marcus]
POL00364052
POL00364052
HDIoutSTU From: Post Office Service Desk
[mailto:! GRO 4
Sent: 26 °
To: MAC GRO
Subject: RE: A17004602 - 17186625
Hi Jackie,
Apologies for this late response.
We already sent to POL the session correction form and just
awaiting for their approval.
We'll let you know as soon as we have receive a response.
In the attached note from FJ (in response to Coyne 3.271), there is the following comment:
"For these types of incident Fujitsu have not affected any transactional information that has
been committed by the branch and therefore will not affect the branch accounts. Session and
Recovery tables use transitory information to provide standard recovery business rules,
however they cannot be exercised in the case when a counter has been removed. The only
option is to remove such information."
Is there a distinction between what Torstein has said and what is happening above? When Torstein refers to
"transaction data" does he mean something different? Or is the above not transaction data?
Earlier in the same note (section 2), the following comment is made in relation to a different incident:
3.267 [Coyne] said: "It has previously been said by Post Office that whilst Fujitsu could modify
transaction data to perform corrective fixes, they would not have delete capabilities (see paragraph
9.24 of my original report)."
In this case the session recovery had to be marked as completed (which removed it from site at
the branch but not from audit)
Again, how is this different, if at all, from Torstein's statement that deletion of transaction data from the BRDB cannot
happen?
I would be grateful if a full explanation could be provided as a matter of urgency. I'd also be grateful for Torstein's
input on whether his statement needs correcting?
Kind regards
Andy
From: Matthew.Lenton¢
Cc: pete.newsomet
Subje:
Andrew Parsons; Ki ; Michael Wharton
ion requests [WBDUK-AC.FID123822914]
Jonny,
POL00364052
POL00364052
1. We havea basis for the paper on the APPSUP question and will be seeking to get that reviewed and returned
to you today if we can.
2. comments on paragraphs 3.249 and 3.266 of Coyne's supplemental report;
a. Attached is a paper relating to 3.249 to 3.265
b. Attached is a paper relating to 3.266 to 3.276
3. comments on WBD's paper on "Peaks with evidence of remote access"; - This is 3.277, I don’t believe I have
received that, can you re-send? We sent the original analysis of this one on 11" Feb, presumably you have a
follow up document to that?
4. comments on the table circulated by WBD — yes, doing that in conjunction with point 1 above.
Regarding Torstein, I will check with him.
Matthew Lenton
Post Office Account Document Manager
PPS, Digital Technology Services
Fujitsu
From: Jonathan Gribber
Sent: 21 February 2019 11
To: Lenton, Matthew
Cc: Newsome, Pett a
Simmonds’. Michael Wharton ¢
Subject: RE: Action requests [WBDUK-AC.FID123822914]
Katie
Matthew, Dave,
Please would you provide an update in relation to the remote access requests below? When can we expect to receive
the information requested?
We intend to use some of the information that we have already requested in relation to remote access to produce an
additional witness statement from Steve and/or Torstein. I'm producing drafts now with a view to circulating them
internally today and sharing them with you shortly after that. Can Torstein be available to review and comment before
Tuesday?
We also need Torstein to consider whether it is necessary for him to correct certain aspects of his first witness
statement in light of Coyne's supplemental report and the Claimants' supplemental witness evidence. I will send you a
note on that shortly. I'm aware that he has Bond Solon training today — can we arrange for him to look at this after
that?
Kind regards
Jonny
Jonathan Gribben
Managing Associate
Womble Bond Dickinson (UK) LLP
POL00364052
POL00364052
Stay informed: sign up to our e-alerts
womblebonddickinson.com
DICKINSON Ain)
From: Jonathan Gribben
Sent: 20 February 2019 11:36
To: Matthew.Lenton@.........GR0......., Dave. Ibbett¢ GRO
Cc: 'pete.newsome '; Andrew Parsons
Simmonds; Emma Campbell-Danesh ¢ GRO
Subject: Action requests [WBDUK-AC.FID123822914]
Matthew, Dave,
Further to our call this morning here's an updated action list, in order of priority. I'll pick up the commercially sensitive
documents point in a separate email.
Let me know if you want to discuss.
Kind regards
Jonny
Action Current Status
Remote access:-
® —apaper which explains what the APPSUP tool is, who New requests — top priority.
could use it, what they could do and how it was audited;
* comments on paragraphs 3.249 and 3.266 of Coyne's
supplemental report;
* comments on WBD's paper on "Peaks with evidence of
remote access", and
* comments on the table circulated by WBD at 18:35 on
19/2 (call or email)
Papers on Coyne's 22 bugs Ongoing — WBD and FJ working to
produce papers on each of the 22
bugs cited by Jason Coyne
Release Notes Requested by WBD on 15/02
We are due to write to Freeths re this
— can this be provided today please?
1. Further comments on Coyne 2 Requested by WBD on 18/02 at
17:57
POL00364052
POL00364052
DI email on 19/02 at 15:24
WBD response 20/02 at 11:21
2. Cross-examination of Richard Roll (document/information Requested by WBD on 18/2 at 14:45
request)
JG email of 24 January re issues relating to Steve's second With Steve - update requested
statement Email sent with first 4 sections
14/02/19
Please consider the environment! Do you need to print this email?
The information in this e-mail and any attachments is confidential and may be legally privileged and protected by law. matthew lenton} “} only is authorised to
access this e-mail and any attachments. If you are not matthew.Jentong” notify jonathan. gribbent “has soon as possible and delete any copies.
Unauthorised use, dissemination, distribution, publication or copying of this communication or attachments is prohibited and may be unlawful. Information about how we use
personal data is in our Privacy Policy on our website
Any files attached to this e-mail will have been checked by us with virus detection software before transmission, Womble Bond Dickinson (UK) LLP accepts no liability for any
loss or damage which may be caused by software viruses and you should carry out your own virus checks before opening any attachment.
Content of this email which does not relate to the official business of Womble Bond Dickinson (UK) LLP, is neither given nor endorsed by it.
This email is sent by Womble Bond Dickinson (UK) LLP which is a limited liability partnership registered in England and Wales under number 0C317661. Our registered office
is 4 More London Riverside, London, SE1 2AU, where a list of members’ names is open to inspection, We use the term partner to refer to a member of the LLP, or an employee
or consultant who is of equivalent standing. Our VAT registration number is GB 123393627.
Womble Bond Dickinson (UK) LLP is a member of Womble Bond Dickinson (International) Limited, which consists of independent and autonomous law firms providing
services in the US, the UK, and elsewhere around the world. Each Womble Bond Dickinson entity is a separate legal entity and is not responsible for the acts or omissions of, nor
can bind or obligate, another Womble Bond Dickinson entity. Womble Bond Dickinson (Intemational) Limited does not practice law. Please see
www.womblebonddickinson.com/legal notices for further details.
Womble Bond Dickinson (UK) LLP is authorised and regulated by the Solicitors Regulation Authority.
Unless otherwise stated, this email has been sent from Fujitsu Services Limited (registered in England No
96056); Fujitsu EMEA PLC (registered in England No 2216100) both with registered offices at: 22 Baker
Street, London W1U 3BW; PFU (EMEA) Limited, (registered in England No 1578652) and Fujitsu
Laboratories of Europe Limited (registered in England No. 4153469) both with registered offices at: Hayes
Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE.
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may
be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is
virus-free.
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
POL00364052
POL00364052