WBONO0000285
WBON0000285
From: Katie Simmonds { -
To: Jonathan Gribben
Subject: SRE: Post Office Group Litigation: Some points to check please
Date: Fri, 16 Nov 2018 13:00:08 +0000
Importance: Normal
Attachments: _DOC_152853821(1)__DOC_152849927(1)_DOC_152766498(3)_323_Bates_Draft_
Witness_Statement_of_Angela_Van-Den-Bogerd_(master)_15_Nov_(1)_(3).DOCX
Inline-Images: image001.png; image002.png; image003.png; image02c4b3.PNG; imagede7eel.PNG;
image24eaa3.PNG
Hi — updated as per the attached.
Katie Simmonds
Associate
Womble Bond Dickinson (UK) LLP
WOMBLE womblebonddickinson.com
BOND
DICKINSON Ain)
From: Andrew Parsons
Sent: 16 November 2018 12:39
To: Jonathan Gribben; Katie Simmonds
Subject: RE: Post Office Group Litigation: Some points to check please
I think he means that Burke was not responsible for the failed recovery — which is correct, that is an IT issue. But that
is back-end thing that doesn't affect her branch accounts. From her perspective, Horizon worked and she failed to
follow the process, so the general thrust of what we say is correct. We may just need to tighten the language slightly.
A
Andrew Parsons
Partner
Womble Bond Dickinson (UK) LLP
WBD_000155.000001
WBONO0000285
WBON0000285
‘Stay informed: sign up to our e-alerts
WOMBLE womblebonddickinson.com
BOND
DICKINSON . Ain)
From: Jonathan Gribben
Sent: 16 November 2018 12:32
To: Katie Simmonds
Cc: Andrew Parsons
Subject: FW: Post Office Group Litigation: Some points to check please [WBDUK-AC.FID27032497]
Katie,
Please can you update Angela's statement to reflect Gareth's comments.
Andy — see the section highlighted yellow. I'll ask Gareth to confirm which reconciliation process.
Thanks
Jonny
Jonathan Gribben
Managing Associate
Womble Bond Dickinson (UK) LLP
Stay informed: sign up to our e-alerts
WOMBLE womblebonddickinson.com
BOND
DICKINSON . Ain)
From: Gareth Jenkins [mailto:
Sent: 16 November 2018 12:28
To: Jonathan Gribben
Cc: Dave. Ibbet
Legal.Defence,__
Subject: RE: Post Office Group Litigation: Some points to check please [WBDUK-AC.FID27032497]
pete.newsome}_
Matthew. Lenton¢
Katie Simmonds;
IMPORTANT - This email or attached documents contains legal advice (or relates t
circumstances for which Legal Privilege may be claimed. Do not copy or forward t!
jation or anticipated liti
cument without perm
n) and is being provided in
n.
WBD_000155.000002
WBONO0000285
WBON0000285
Hi Jonny,
Please see comments below prefixed [GIJ]
Best wishes
Gareth
From: Jonathan Gribben [mailto;
Sent: 16 November 2018 11:29
To: Gareth Jenkins; _ GRO. }
Ce: Dave. Ibbett@ GRO: Matthew.Lentoné GRO } pete.newsome( GRO
Simmonds ! . GRO i
Subject: Post Office Group Litigation: Some points to check please [WBDUK-AC.FID27032497]
Importance: High
Good morning Gareth,
Privileged & Confidential — please do not forward
We are in the process of finalising a number of the witness statements for Post Office in advance of Friday's deadline.
Please can you take a look at the points below and let us know if they are incorrect in any way, as soon as possible
(this is a top priority)?
In relation to the "phantom sales" that were reported in around 2000, can you confirm these:
i. appear to have been caused by hardware issues; and
[GIJ] confirmed
ii. should not have caused a discrepancy in a branch's accounts;
[GIJ] provided they related to stock sales (and the examples I have seen all do). In that case there would
be a corresponding stock discrepancy that would cancel out. However it is hard to be definitive.
In terms of transactions not being associated with a Subpostmasters user ID, we believe there are two possible ways
a user ID can be affected as follows:
WBD_000155.000003
WBONO0000285
WBON0000285
i. Sharing of User ID passwords between users/ in branch;
ii. Connectivity issue when user A is processing a transaction. A different user (User B) is
then the first to log into Horizon when the connectivity issue has been resolved. Any recovery action
taken by User B will be logged against their user ID. However, Horizon will also record that User A
undertook the original interrupted transaction, which may appear as if a transaction was completed
by User A when it was not.
[G1J] Sorry, but I can’t remember exactly how this worked on old Horizon. Certainly on HNG-X when a
transaction is recovered, then the User Id is that of the user who is recovering the Txn, but we do also
record in the audit record who the original user was. I suspect that this was also the case on old
Horizon, but cannot be definitive.
There is a further scenario. On Old Horizon if SSC were to insert a transaction at the counter (which
although possible, was very rare), then this would have been associated with the User Id of whoever was
logged on at that counter. If nobody was logged on then the User Id would be missing. Such
transactions should be clearly identified in the audit trail as having been inserted by SSC.
Similarly any transactions inserted by SSC at the Data centre would have no associated User ID, but
should be clearly identified in the Audit Trail and also clearly visible in branch reports such as the
Transaction Log as having originated from the Data Centre rather than a real counter.
Are there any other reasons that Fujitsu are aware of that could result in a user ID being affected?
Angela Burke:
a. Inher statement, Mrs Burke describes suffering a shortfall which arose out of the Horizon system
outage on 9 May 2016. I have described this outage at paragraph XX above. On the basis of the
ARQ Data (exhibit) I believe that this shortfall arose due to Mrs Burke not following the recovery
process after a system outage rather than any error in Horizon.
b. The account provided by Mrs Burke means that it is clear that she did not follow Post Office's
standard processes for processing transactions. Specifically, each customer's transactions should
be separately recorded on Horizon in what is called a "basket" or sometimes referred to as a stack
(because the transactions appear to stack up on the screen). After each customer, the transactions
needed to be submitted to the branch accounts ie the transaction needs to be completed, which is
sometimes called "clearing the stack". Mrs Burke did not do this and bundled together two
customers’ transactions into one basket (see paragraph 14 of her statement). From Horizon's
perspective, this would have looked like a set of transactions relevant to a single customer.
[GIJ] This is true, but is not the reason for the problem.
c. When processing bank withdrawals, Horizon first checks that the customer's bank account has
sufficient funds for the withdrawal. If the bank's system confirms this, Horizon adds the withdrawal to
WBD_000155.000004
WBONO0000285
WBON0000285
the stack and prints an “authorisation receipt" (see page 12 of AB1, timed at 9:28). Multiple
transactions can be added to a stack. It is not uncommon for a customer to withdraw cash and then,
Say, pay a bill or buy some stamps. Once all the transactions are added to the stack, Horizon
calculates the net amount due to or from the customer, the user completes the basket (which submits
the entire basket of transactions into the branch accounts) and cash is physically handed over the
counter. Because there can be multiple transactions in the stack, there can be a delay between a
cash withdrawal being authorised by the bank and the full basket being submitted to the branch
accounts. This raises the possibility of some form of intervening act such as a power outage or loss
of connectivity. If that happens, the bank's system may be showing a withdrawal of cash but Horizon
has no record of the transaction.
[GIJ] correct
d. This is where the recovery process is initiated if there is a connectivity failure, Horizon will make
multiple attempts to complete the basket, but after XX attempts it will record a failure and log out the
user. It will also print a disconnected session receipt showing the transactions in the stack at that
point (which happened in this case: see page 2 of AB1, timed at 9:30).
[GIJ] It will make two attempts (the original request followed by a single retry. The user is then asked if
they wish to retry. If they say “yes” then 2 further attempts are made. If these both fail, the same retry
screen is then shown and the process repeated until the user either gives up or the basket is settled
successfully. The recommendation is that they retry one and then give up (ie after 3 attempts to settle).
The is a 40 sec delay between each retry thus allowing time for any temp issue in the Data Centre to be
resolved. If they say “no” they are logged out and recovery is instigated on the next Log On.
Rest is as described
e. Once Horizon comes back up, it will check whether there are any cash withdrawals logged by the
bank but not on Horizon. Where it gets confirmation from the bank that the cash withdrawal has
gone through, Horizon will then add that cash withdrawal (and any other recovered transactions) to a
new basket and complete that basket so that it forms part of the branch accounts. It will then print a
recovery receipt telling the user what cash to give to the customer.
[GIJ] The check is more general. It checks for an recoverable transactions (all Cash withdrawals are
marked as recoverable). If it finds a recoverable transaction (in this case a Cash Withdrawal) it then
attempts to communicate with the Banking Agent to see what happened to that transaction. In this case
that communication failed (due to the system problems that day) and so recovery failed and it was
marked as such to be resolved manually.
f. In Mrs Burke's case, the first two withdrawals (of £73 and £180) were recovered but the withdrawal
of £150 was not recovered. This is shown on the recovery receipt, at page 5 of AB1 and timed at
9:36, which instructs Mrs Burke to only pay £73 and £180 to the customer. This is also reflected in
the transaction list at page 6 of AB1 which only shows the withdrawals for £73 and £180, and not the
withdrawal for £150.
g. Had Mrs Burke followed the recovery receipt, she would not have given the £150 to the customer
and would have suffered no shortfall.
[GIJ] correct.
h. If Mrs Burke had followed the correct process the failed recovery would have disadvantaged the
customer, whose account would have been debited but who would have not received any cash from
Mrs Burke. From the Subpostmaster's perspective, Horizon accurately recorded the recovered
transactions and told Mrs Burke not to pay the £150 to the customer. The problem was caused by
Mrs Burke not following the procedure which would have instructed her not to pay out the £150
i. Following Mrs Burke's investigation, Post Office generated a transaction correction for the £150
withdrawal. I believe it was quite proper for Mrs Burke to do this investigation as it was her original
error that caused the loss. Once Post Office was presented with evidence that the customer had
WBD_000155.000005
WBONO0000285
WBON0000285
received the cash and the customer's bank had recorded the withdrawal, a transaction correction
was issued to bring the branch accounts back in line thereby correcting Mrs Burke's mistake.
[GIJ] I was not aware of this, but it seems reasonable.
j. Mrs Burke states (at paragraph 26) that the TC "had settled the amount to Lloyds bank and not
TSB". TSB was part of Lloyds bank until September 2013 and I suspect this is the reason for this.
The identity of the financial institution is not relevant from a branch accounts perspective.
[GIJ] Agreed this has no impact on the branch accounts.
Thank you in advance
Kind regards
Jonny
Jonathan Gribben
Managing Associate
Womble Bond Dickinson (UK) LLP.
‘Stay informed: sign up to our e-alerts
WOMBLE womblebonddickinson,
BOND
DICKINSON wv fin]
Please consider the environment! Do you need to print this email?
The information in this,
ail and any attachments is confider nly is authorised to access
and may be legally privileged and protecte
this e-mail and any attachments. Ifyou are not gijenking___ GRO___ please notify jonathan,gribbeng___ GRO __}s soon as possible and delete any copies.
use personal data is in our Privacy Policy, on our website.
Any files attached to this e-
any loss or damage which m:
ked by us with virus detection software bet
ised by software viruses and you should carry out your own virus checks before opening any
ore transmission. Womble Bond Dickinson (UK) LLP accepts no liability for
tachment.
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
-mail is sent by Womble Bond Dickinson (UK) LLP which is a limited liability partnership registered in England and Wales under number OC317661. Our registered
is 4 More London Riverside, London, SEI 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 GB123393627,
Womble Bond Dickinson (UK) LLP is a member of Womble Bond Dickinson (International) Limited, which consists of independent and autonomous law firms providing
the UK, and elsewhere around the world. Each Womble Bond Dickinson entity is a sep: y esponsible for the acts or omissions
of, nor can bind or obligate, another Womble Bond Dickinson entity. Womble Bond Dickinson (International) Limited does not practice law. Please see
for further details
www.womblebonddickinson.comv/legal notice
Womble Bond Dickinson (UK) LLP is authorised and regulated by the Solicitors Regulation Authority
WBD_000155.000006