FUJ00160648
FUJ00160648
Gareth Jenkins 4.
<Dave.Ibbett_.
<pete.newsome¢
<Legal.Defence¢
Subject: RE: Post Office Group Litigation: Some points to check please
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.
To: Gareth Jenkin:
Cc: Dave.Ibbett@ I; Matthew.Lenton,
<Katie.Simmonds¢(~ egal.Defence} GRO}
Subject: RE: Post Office Group Litigation: Some points to check please
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
Womble Bond Dickinson (UK) LLP
Stay informed: sign up to our e-alerts
womblebonddickinson.com
FUJ00160648
FUJ00160648
WOMBLE v in)
BOND
/Y BON
DICKINSON
From: Gareth Jenkins
Sent: 16 November 2018 14:00
To: Jonathan Gribbe!
Cc: Dave. Ibbett GRO Matthew.Lenton@”
Legal.Defence@treregreeeneerrr Andrew Parsons
Subject: RE: Post Office Group Litigation: Some points to check please [WBDUK-AC.FID27032497]
pete.newsome@ GRO I Katie Simmonds;
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!)
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 CBU001 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 onea
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. 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.
PON OV PWNE
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.
e 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,
FUJ00160648
FUJ00160648
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 13:04
To: Jonathan Gribben
Cc: 'Dave.Ibbett¢
<Matthew.Lenton:
'Matthew.Lenton€
‘Legal.Defence:
‘Andrew Parsons'
Subject: RE: Post Office Grouip Litigation: Some points to hEck 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.
V'll have a further look after lunch.
Best wishes
Gareth
From: Jonathan Gribben {_
Sent: 16 November 2018 12:34
To: Gareth Jenkins!
Ce: Dave.Ibbett@
Apr a Katie Simmonds
egal.Defence@; GRO I Andrew Parsons <andrew.parsons@
Subject: RE: Post Office Group Litigation: Some points to check please [WBDUK-AC.FID27032497]
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
FUJ00160648
FUJ00160648
Jonny
Jonathan Gribben
Managing Associate
Womble Bond Dickinson (UK) LLP
Stay informed: sign up to our e-alerts
womblebonddickinson.com
WOMBLE
BOND
DICKINSON vy ©
From: Gareth Jenkins
Sent: 16 November 2
To: Jonathan Gribben
Katie Simmonds;
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 [GU]
Best wishes
Gareth
From: Jonathan Gribber
jatthew.Lenton¢_____GRO_____$ pete.newsome¢
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)?
FUJ00160648
FUJ00160648
1) Inrelation 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;
[G1J] 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. I 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 ID being affected?
3) Angela Burke:
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.
[Gl] 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,
FUJ00160648
FUJ00160648
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 showing the transactions in the stack at that point
(which happened in this case: see page 2 of AB1, timed at 9:30).
[G1] 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.
[GJ] 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.
[GJ] 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
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
FUJ00160648
FUJ00160648
Kind regards
Jonny
Jonathan Gribben
Managing Associate
Womble Bond Dickinson (UK) LLP
jonathan.gribbeng GRO :
Stay informed: sign up to our e-alerts
womblebonddickinson.com
/ BOND
DICKINSON tin)
hit
Please consider the en
‘onment! Do you need to print this email?
‘The information inthis e-mail and any attachments igaanlidentik.nl may be le a gi,jenkinsg ly is authorised to access this
e-mail and any attachments. If you are not gijenkinst GRO soon as posstbreamtraretexe zy copies. Unauthorised use,
dissemination, distribution, publication or copying of thi: inlawful. Information about how we use personal data is in our
Privaey Policy on our website.
ation or attachments is prohibited afd fia
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 of
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 (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 Di 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 (International) I imited does not practice law. Please see
swww.womblebonddickinson.com legal notices for further details.
Womble Bond Dickinson (UK) LLP is authorised and regulated by the Solicitors Regulation Authority.