POL00111371
POL00111371
Message
From: Andrew Parsons
Sent: 16/11/2018 15: .
To: Gareth Jenkins im Honathan Gribber, i
cc: ‘ _} Katie Simmonds
c Legal.Defencel
Subject: RE: Post Office Group Litigation: Some points to check please
Thanks Gareth ~ I get it now!
Andrew Parsons
Partner
Womble Bond Dickinson (UK) LLP
Stay informed: sign up to our e-alerts
. WOMBLE womblebonddickinson.com
“ BOND
DICKINSON wv ©
From: Gareth Jenkins}
Sent: 16 November 2018 14:56
To: Andrew Parsons; Jonathan Gribben
Cc: Dave.Ibbe'
Legal.Defence!
Subject: RE: Post Office Group Litigation: Some points to check please
}; pete.newsomel
Hi Andrew,
The disconnected session receipt did say to hand over the £150. This is the receipt that is produced at the time the
customer is present, and indicates to the SPMR what they should do with the customer.
The recovery receipt is produced when the system is recovered (which may be some time later and the customer is
unlikely to be present). The fact that they differ indicates a problem as does the message “Failed recovery” on the
recovery receipt.
Does that clarify things?
Best wishes
Gareth
From: Andrew Parsons'_
Sent: 16 November 201
POL-0108960
POL00111371
POL00111371
Gareth
The bit I don’t understand is why Mr Burke was correct to handover the £150 to the customer if the Recovery Receipt
doesn't show the transaction for £150?
A
Andrew Parsons
Partner
Wombie Bond Dickinson (UK) LLP.
womblebonddickinson.com
yo
OND
i DICKINSON _
From: Gareth Jenki
Sent: 16 November 2018 14:00
To: Jonathan Gribben
Katie Simmonds;
p Litigation: Some points to check please [WBDUK-AC.FID27032497]
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 1 hour difference may cause confusion!)
1. 08:27:20 Card Account withdrawal request for £180 which was successful
2. 08:27:57 Card Account withdrawal request for £73 which was successful
3. 08:28:16 Link withdrawal request for £150 which was successful
4. 08:28:45 Attempt to settle the basket which failed
5. 08:29:15 Automatic retry of basket settlement which also failed.
6. No attempt by Mrs Burke for any further retries so counter logged off.
7. 08:30:39 Log On to counter which failed
8. 4 Log On to counter which failed
9,
. 115 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
POL-0108960
POL00111371
POL00111371
13. 08:34:53 Another attempt to settle the recovery basket that succeeded. As a 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.
This means that Mrs Burke did exactly the right thing at all times.
What should then have happened was as follows:
e 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.
{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).
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 13:04
To: Jonathan Gribben
Cc: ‘Dave. Ibbett!~
H GRO
i 'Katie
>; ‘Andrew
Simmonds... SRO 3 ‘Legal.Defence, _
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,
{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.
Vil have a further look after lunch.
POL-0108960
POL00111371
POL00111371
Best wishes
Gareth
From: Jonathan Gribben: .
Sent: 16 November 2018 12:
pete.newsom:
__ Andrew Parsons}
please [WBDUK-AC.
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
Wombie Bond Dickinson (UK) LLP.
SN WOMBLE womblebonddickinson.com
Y BOND
SON ye
DICK
From: Gareth Jenkins
Sent: 16 November 2018 12:28
To: Jonathan Gribben
Ce: Dave. Ibbett
Legal. Defer
Subject: RE: Post Office Group Litigation: Some points to check please [WBDUK-AC.FID27032497]
I Matthew, Lenton! GRO tpete.newsome
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 [GU]
Best wishes
Gareth
POL-0108960
POL00111371
POL00111371
From: Jonathan Gribben
Sent: 16 November 2018 11:29
To: Gareth Jenkins
C -
‘Katie Simmonds
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)?
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
[GU] confirmed
ii. should not have caused a discrepancy in a branch's accounts;
[GU] 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.
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 1D 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.
POL-0108960
POL00111371
POL00111371
[GU] 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 Horizons perspective, this would have looked like a
set of transactions relevant to a single customer.
[GU] 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
[GU] 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 snowing the transactions in the stack at that point (which
happened in this case: see page 2 of AB1, timed at 9:30).
[GU] 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 withdrawais 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
compiete 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 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.
[GU] 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
POL-0108960
POL00111371
POL00111371
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 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.
[GJ] I was not aware of this, but it seems reasonable.
j. Mrs Burke states (at paragraph 26) that the TC “had settied the amount to Lloyds bank and not
TSB”. TSB was part of Lloyds bank until Septernber 2013 and I suspect this is the reason for this. The
identity of the financial institution is not relevant from a branch accounts perspective.
[GU] 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
informed: sign up to our e-alerts
womblebonddickinson.com
WOMBLE
BOND
DICKINSON sd ®
Please consider the en aving this emul?
ally priv
POL-0108960