POL00105560
POL00105560
Angela Van-Den-Bogerd
From: Gareth Jenkins f
Sent: 16 November 2018 1
To: Jonathan Gribben
Ce: Matthew.Lenton@~ }
pete.newsomei_.
Andrew Parsons
Subject: RE: Post Office Group Litigation: Some points to check please [WBDUK-
AC.FID27032497]
‘atie Simmonds; Legal.Defence(
Hi Jonny,
We've now found the related Peak that processed the Failed Recovery. It was Peak PC0251333which says in relation
to this Branch:
00~-216321-1-1350900-1:
The £150 cash withdrawal transaction was authorised by the FI and an AUTHORISED
receipt was produced on the counter. However, when the user attempted to settle
the transaction it failed due to the known datacentre issue at the time so
disconnected session receipts were produced and the user was logged off. The
user managed to log back in but recovery also failed. As an AUTHORISED receipt
was produced the user should have handed money over to the customer but we
cannot be certain that they actually did so. Assuming money was handed over the
customer account will be correct but the branch will have a shortage given that
the transaction hasn't been recorded on the system. This will need to be
manually reconciled.
The Peak also says that a Final BIMS was issued.
So it looks like the checks and balances all worked on the Fujitsu side. This info would then have been passed over
to POL via a BIMS for them to generate a TC.
Best wishes
Gareth
Hi Jonny,
OK, I’ve now worked out exactly what happened.
This was all on Counter 1 and the times are GMT so need to add on an hour to get the real time (I’ve not done that
since the spreadsheet of my analysis has the UTC times, but I appreciate that the 4 hour difference may cause
confusion!)
POL00105560
POL00105560
08:27:20 Card Account withdrawal request for £180 which was successful
08:27:57 Card Account withdrawal request for £73 which was successful
08:28:16 Link withdrawal request for £150 which was successful
08:28:45 Attempt to settle the basket which failed
08:29:15 Automatic retry of basket settlement which also failed.
No attempt by Mrs Burke for any further retries so counter logged off.
08:30:39 Log On to counter which failed
08:31:14 Log On to counter which failed
08:32:15 Log On to counter which succeeded (user CBUOO1 which is probably Mr Burke not Mrs Burke)
10. As part of the Log On there were 3 transactions obtained from BRDB that required recovery For each one a
request was sent to the appropriate Banking agent asking what had happened. Both Card Account
transactions were recovered OK. However attempting to recover information form the Link Agent failed, so
the Link transaction was marked as Failed Recovery.
11, 08:34:17 A Recovery basket was sent containing the 2 recovered CAPO transactions and the one failed LINK
transaction with their original timestamps and these are in the ARQ showing the LINK transaction as zero
value. This message also included the event indicating that there had been a failed recovery. This
settlement also failed
12. 08:34:47 Retry to settle the recovery basket which again failed
13. 08:34:53 Another attempt to settle the recovery basket that succeeded. Asa result a recovery receipt was
shown which just included the 2 successful transactions plus the text “recovery failed” (P5 of her attached
evidence)
14. The system then seems to behave OK.
YP ONAN PWNP
This means that Mrs Burke did exactly the right thing at all times.
What should then have happened was as follows:
The Failed Recovery Report should have picked up the failed recovery event, and it should then have been
investigated, initially by Fujitsu and then a BIMS raised with POL.
This transaction should also have been visible on the DRS reconciliation reports showing a zero value at the
counter (or perhaps no info from the counter) while there was a value of £150 from the Link and again a
BIMS issued.
I can’t comment as to whether these processed did or did not pick up the issue. There doesn’t appear to be a Peak
on the issue, but that doesn’t mean that a BIMS wasn’t raised to suggest to POL that there might be an issue.
It could be that Mrs Burke just beat the system. However she was correct in handing over the money, and that
should have been deduced from the investigation of the Failed Recovery and so she should have been reimbursed
(which eventually she was by a TC — the fact it says the wrong bank is irrelevant).
I hope this clarifies things and sorry if I had mislead you before about what had happened.
Happy to discuss further if required.
Best wishes
Gareth
From: Gareth Jenkins,
Sent: 16 November 2018 1:
To: Jonathan Gribben' ¢,
“GRE
'Matthew.Lentoné.
5 'pete.newsome@
POL00105560
POL00105560
}
Simmonds {,
‘Andrew Parsons’
Subject: RE: Post O'
Defence@_
p Litig
points to check please [WBDUK-AC.FID27032497]
IMPORTANT - This email or attached documents contains legal advice (or relates to litigation or anticipated litigation) and is being provided in
circumstances for which Legal Privilege may be claimed. Do not copy or forward this document without permission.
Hi Jonny,
I need to look at this again more closely. The Disconnected recovery receipt (which I hadn’t looked at before) shows
that the transaction for £150 was successful and so she was correct to pay out the money.
That doesn’t match with what I saw in the logs.
Vl have a further look after lunch.
Best wishes
Gareth
From: Jonathan Gribben
Sent: 16 November 2018 12:34
To: Gareth Jenkins!
Dave. lbbett@
Matthew.Lenton@
Gareth,
Thank you for this. In relation to the section that I've highlighted yellow below, can you explain which reconciliation
process should have picked the issue up? Is it possible that the process would have picked this up in due course, but
Mrs Burke was proactive?
Kind regards
Jonny
Jonathan Gribben
Managing Associate
Womble Bond Dickinson (UK) LLP.
tio womblebonddickinson.com
Cee. ___ ¥0
From: Gareth Jenkin:
Sent: 16 November 2018 12:28
To: Jonathan Gribben enn
Cc: Dave. Ibbett@ "] Matthew.Lenton@ wsomet } Katie Simmonds;
POL00105560
POLO00105560
Legal.Defence@ i
Subject: RE: Post Office Group Litigation: Some points to check please [WBDUK-AC.FID27032497]
IMPORTANT - This email or attached documents contains legal advice (or relates to litigation or anticipated litigation) and is being provided in
circumstances for which Legal Privilege may be claimed. Do not copy or forward this document without permission.
Hi Jonny,
Please see comments below prefixed [GJ]
Best wishes
Gareth
From: Jonathan Gribben:
Sent: 16 November 2018 11:29
To: Gareth Jenkins
Cc: Dave.lbbett@”
<Katie Simmonds@
Subject: Post Office Group Litigation: Some points to check please [WBDUK-AC.FID27032497]
Importance: High
Matthew.Lenton@ I pete.newsome@”
‘Katie Simmonds
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)?
1) 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
[GJ] confirmed
ii. should not have caused a discrepancy in a branch's accounts;
[GJ] 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.
2) 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:
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.
[GU] 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.
POL00105560
POL00105560
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?
3) 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.
[G1] I disagree with this. Not sure where this text comes from. The error was due to a failed recovery and was
not her fault. This should have been picked up by the reconciliation process and a BIMS passed to POL to
resolve. The fact she had to chase things up indicates a failure somewhere in that process, but I don’t know
exactly where.
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
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).
[GJ] 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.
[GU] 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
5
POL00105560
POL00105560
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.
[GH] 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 fo do this investigation as it was her original
error that caused the loss. Once Post Office was presented with evidence that the customer had
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.
[GU] 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.
[GI] 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.
womblebonddickinson.com
G yO
Please consider the environment! Do you need to print this email?
The information in this e-mail and any attachments is confi may be legally privileged and protect Jonly is authorised to access
this e-mail and any attachments. Ifyou are not. lease notify jonathan. gribben@ s 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 OC317661. Our registered
6
POL00105560
POL00105560
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 (Intemational) 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
ynuw.womblebonddickinson,com/leeal notices for further details.
office 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 toa member of the LLP. or an,
Womble Bond Dickinson (UK) LLP is authorised and regulated by the Solicitors Regulation Authority,
POL00105560
POL00105560